Edit 4: With v0.1.1 standalone mode is fully supported and so are multiple tools. I also implemented proper setup to prevent duplicated integrations for the same board, so multiple integrations are support now as well.

Edit 3: We are on v0.0.5 now. Added experimental standalone mode. Can’t test it because I am only using SBC.

Edit 2: Released v0.0.2. All sensors are created properly and getting async status updates every 5 seconds. Ill follow up later to make the interval configurable and I also need to take another look at finishing up the setup when the printer becomes available later

Edit 1: Introduced a bug in the version so that the state is not always updated properly. Working on it

Hey folks!
I refactored quite a lot and we now have a proper integration between the DSF and Home Assistant. When you create the integration via ConfigFlow you have some options you can choose from, including the option to add an LED controller, which is handy if you have LED's connected to your Duet.
The Device itself represents the physical Duet board and shows your correct model as well as the firmware version. All entities now have unique id's and should not conflict anymore. All sensors, binary sensors and the send_gcode service should work properly now

Keep in mind that if you have the integration already installed, you need to remove the integration once more and install it again. That is necessary, because I have rewritten the way of how entities are registered in Home Assistant.

You'll find all infos here in the first release: https://github.com/Lyr3x/hass-Duet3D/releases/tag/v0.0.2
@dc42 it would be nice if we can upload the Duet3D logo here: https://github.com/home-assistant/brands/pulls - we can use the logo then with this integration.

I'll look for a better solution for the Position sensor soon.
If you find any issues are need additional sensors, please create a GitHub issue from now on:
https://github.com/Lyr3x/hass-Duet3D/issues

I am also more then happy to accept PRs

Hey folks,
i picked this topic up yesterday and refactored the integration to make it work again with the new /machine/status endpoint.
https://github.com/Lyr3x/hass-Duet3D

Not happy yet with the position entity and the fact that there is no proper config flow and entities are not attached to a device. I will work on that in the next days. Might take some time as I need to dig into that to understand how custom components are built and what the spaghetti code in the integration is doing
I removed the job percentage yesterday temporarily to get this out of my way, because there is not such attribute, but I already spotted that it can be easily calculated with the file size. Contributions are welcomed!

I also removed the password property, as this is not needed for the endpoint. Furthermore, I might need to set up a proper session when the integration has maybe a service to send G/M codes as well. We'll see.

Hope that it is of some help for you as well

@jay_s_uk
3.4.5 on a Duet MB6HC

If I manually edit the active temperature to 0° it is of course updated. Can check tomorrow, but I think when a print finishes successful the temperature is also set to 0°

@nikscha oh the readme is still wrong. It is not Job percentage but Progress

Configflow is still giving me a headache. I need to refactor the code more to get this working properly.
But I added a home assistant service to send gcodes:

service: duet3d_printer.hevors_send_gcode
data:
  gcode: G28

Feedback appreciated!

Edit: Alright, I just released a new version of the integration. ConfigFlow is now working as well as the service. The binary sensor is still dead. You need to remove the configuration from your configuration.yaml and just setup the integration via UI. I unfortunately need to ask you to reconfigure the Integration later again, because I want to attach the entities to a device. But its in a working mode now! Please do not hesitate with feedback.

@nikscha Yep realized that as well, sorry. I decided to stop trying to patch the stuff I want to remove anyway and fix the config flow setup and remove the configuration.yaml code completely. I already have a working unpolished state. Bear with me a little more. Ill update you all here later!

@nikscha said in Home Assistant Integration:

service: duet3d_printer.send_codedata: gcode: M291 P"X" R"X" S3

Ah gotcha. That is specific to the API call. It seems to be synchronous or it times out. If you press the OK button, the request is done. The integration does not validate the GCodes but just send them to the DSF API. If you make a similar call via curl you see the exact same behavior.

Thanks, @T3P3Tony, for the support with the Logos. The integration now appears with a proper icon and the logo!

Unfortunately, I was forced to update the DOMAIN object one last time, which results in the situation where everyone needs to re-install the integration completely. Sorry for that! Will try to avoid future breaking changes

@chrishamm Okay, that is confusing.
Why do we have two objects in place which provide the same information, but maybe they don't in reality?
Currently, I use the heaters to get the heating values for all tools and the bed and besides the described behavior this complies also with the UI values.
But in the end, reflect heat.heaters[1] the heater of the tool#1.

Will check the tools object later and report if the behavior is the same.

[
  {
    "active": [
      0
    ],
    "axes": [
      [
        0
      ],
      [
        1
      ]
    ],
    "extruders": [
      0
    ],
    "fans": [
      0
    ],
    "feedForward": [
      0
    ],
    "filamentExtruder": 0,
    "heaters": [
      1
    ],
    "isRetracted": false,
    "mix": [
      1
    ],
    "name": "Hemera",
    "number": 0,
    "offsets": [
      0,
      5,
      0
    ],
    "offsetsProbed": 7,
    "retraction": {
      "extraRestart": 0,
      "length": 2,
      "speed": 16.7,
      "unretractSpeed": 16.7,
      "zHop": 0
    },
    "spindle": -1,
    "spindleRpm": 0,
    "standby": [
      0
    ],
    "state": "active"
  }
]

Looking at the response, I (as expected) only get the reference to the heater number and not the heater values. So the values from heat.heater[1] do not fit the GCode call, but the gcode also do not show the temperature values, right?
M409 K"heat" show the same IMHO wrong active and standby values.

M409 K"heat"
{
    "key": "heat",
    "flags": "",
    "result": {
        "bedHeaters": [
            0,
            -1,
            -1,
            -1,
            -1,
            -1,
            -1,
            -1,
            -1,
            -1,
            -1,
            -1
        ],
        "chamberHeaters": [
            -1,
            -1,
            -1,
            -1
        ],
        "coldExtrudeTemperature": 160,
        "coldRetractTemperature": 90,
        "heaters": [
            {
                "active": 0,
                "avgPwm": 0,
                "current": 22.47,
                "max": 120,
                "min": -273.1,
                "model": {
                    "coolingExp": 1.4,
                    "coolingRate": 1.112,
                    "deadTime": 2.3,
                    "enabled": true,
                    "fanCoolingRate": 0,
                    "heatingRate": 0.402,
                    "inverted": false,
                    "maxPwm": 1,
                    "pid": {
                        "d": 1.219,
                        "i": 0.0749,
                        "overridden": false,
                        "p": 0.74414,
                        "used": true
                    },
                    "standardVoltage": 0
                },
                "monitors": [
                    {
                        "action": 0,
                        "condition": "tooHigh",
                        "limit": 120
                    },
                    {
                        "condition": "disabled"
                    },
                    {
                        "condition": "disabled"
                    }
                ],
                "sensor": 0,
                "standby": 0,
                "state": "off"
            },
            {
                "active": 220,
                "avgPwm": 0,
                "current": 29.2,
                "max": 300,
                "min": -273.1,
                "model": {
                    "coolingExp": 1.4,
                    "coolingRate": 0.693,
                    "deadTime": 2.2,
                    "enabled": true,
                    "fanCoolingRate": 0.784,
                    "heatingRate": 4.248,
                    "inverted": false,
                    "maxPwm": 1,
                    "pid": {
                        "d": 0.115,
                        "i": 0.0115,
                        "overridden": false,
                        "p": 0.07456,
                        "used": true
                    },
                    "standardVoltage": 24
                },
                "monitors": [
                    {
                        "action": 0,
                        "condition": "tooHigh",
                        "limit": 300
                    },
                    {
                        "condition": "disabled"
                    },
                    {
                        "condition": "disabled"
                    }
                ],
                "sensor": 1,
                "standby": 220,
                "state": "off"
            }
        ]
    }
}

Of course, I am rather new to the Duet and RRF API so please feel free to correct me if I am wrong! I just want to make sure that both the API is delivering correct and consistent values and that my integration is working fine

@dc42 Sorry for the late reply. Was very busy in the last days.

I have a stop.g in my /sys and here's the content. Actually never touched that.

; =========================================================================================================
;
; stop.g
; called when M0 (Stop) is run (e.g. when a print is cancelled)
;
; =========================================================================================================
;
G10 P0 S-274 R-274       ; turn off extruder
M140 S0 R0               ; set bed temperature to 0C
M140 S-274               ; set bed temperature to 0K to turn it off
M107                     ; turn off fan
M150 u255 P255 
G91                      ; relative positioning
M98 P"0:/sys/homex.g"
M98 P"0:/sys/homey.g"
;
; =========================================================================================================
;

I didn't know about that behavior. Do I understand you correctly, that my stop.g is missing, then something like M568 P1 R0 S0?
But why is the API responding then a different state than the RRF ObjectModel in the first place? I thought that the ObjectModel is a real representation of the internal states from RRF and this model is used as a response for the API resources. As you can see below, the ObjectModel itself looks fine if querying with the GCode.

Here is the result for the M409.

M409 K"tools" F"d99vn"
{
    "key": "tools",
    "flags": "d99vn",
    "result": [
        {
            "active": [
                0
            ],
            "axes": [
                [
                    0
                ],
                [
                    1
                ]
            ],
            "extruders": [
                0
            ],
            "fans": [
                0
            ],
            "feedForward": [
                0
            ],
            "filamentExtruder": 0,
            "heaters": [
                1
            ],
            "isRetracted": false,
            "mix": [
                1
            ],
            "name": "Hemera",
            "number": 0,
            "offsets": [
                0,
                5,
                0
            ],
            "offsetsProbed": 7,
            "retraction": {
                "extraRestart": 0,
                "length": 2,
                "speed": 16.7,
                "unretractSpeed": 16.7,
                "zHop": 0
            },
            "spindle": -1,
            "spindleRpm": 0,
            "standby": [
                0
            ],
            "state": "active"
        }
    ],
    "next": 0
}

When we now look at the response of the API, we get a different response:

curl -X GET http://192.168.2.116/machine/status | jq '.heat.heaters[1]'
-> 
{
  "active": 220,
  "avgPwm": 0,
  "current": 31.7,
  "max": 300,
  "min": -273.1,
  "model": {
    "coolingExp": 1.4,
    "coolingRate": 0.693,
    "deadTime": 2.2,
    "enabled": true,
    "fanCoolingRate": 0.784,
    "heatingRate": 4.248,
    "inverted": false,
    "maxPwm": 1,
    "pid": {
      "d": 0.115,
      "i": 0.0107,
      "overridden": false,
      "p": 0.07456,
      "used": true
    },
    "standardVoltage": 24
  },
  "monitors": [
    {
      "action": 0,
      "condition": "tooHigh",
      "limit": 300
    },
    {
      "action": null,
      "condition": "disabled",
      "limit": null
    },
    {
      "action": null,
      "condition": "disabled",
      "limit": null
    }
  ],
  "sensor": 1,
  "standby": 220,
  "state": "off"
}

Here, both active and standby temperatures are not reflecting the internal(?) status. As I rely on the API for the HASS integration, the values are off after canceling a print. Hope that helps and clarifies the situation!

Thanks, @T3P3Tony, for the support with the Logos. The integration now appears with a proper icon and the logo!

Unfortunately, I was forced to update the DOMAIN object one last time, which results in the situation where everyone needs to re-install the integration completely. Sorry for that! Will try to avoid future breaking changes

@jay_s_uk
3.4.5 on a Duet MB6HC

If I manually edit the active temperature to 0° it is of course updated. Can check tomorrow, but I think when a print finishes successful the temperature is also set to 0°

I think I've found a bug regarding updating the object model when canceling a print. I don't know if this is originating from DSF or DWC.
The ObjectModel for the heater is updated perfect fine when starting a print and of course setting the temperatures manually.
However, I have just found out, that if cancelling a print the UI shows 0° for both active and standby tool temperature, but the ObjectModel still says e.g 230°:

[
  {
    "active": 0,
    "avgPwm": 0.003,
    "current": 34,
    "max": 120,
    "min": -273.1,
    "model": {
      "coolingExp": 1.4,
      "coolingRate": 1.112,
      "deadTime": 2.3,
      "enabled": true,
      "fanCoolingRate": 0,
      "heatingRate": 0.402,
      "inverted": false,
      "maxPwm": 1,
      "pid": {
        "d": 1.219,
        "i": 0.1093,
        "overridden": false,
        "p": 0.74414,
        "used": true
      },
      "standardVoltage": 0
    },
    "monitors": [
      {
        "action": 0,
        "condition": "tooHigh",
        "limit": 120
      },
      {
        "action": null,
        "condition": "disabled",
        "limit": null
      },
      {
        "action": null,
        "condition": "disabled",
        "limit": null
      }
    ],
    "sensor": 0,
    "standby": 0,
    "state": "off"
  },
  {
    "active": 230,
    "avgPwm": 0.003,
    "current": 98.29,
    "max": 300,
    "min": -273.1,
    "model": {
      "coolingExp": 1.4,
      "coolingRate": 0.693,
      "deadTime": 2.2,
      "enabled": true,
      "fanCoolingRate": 0.784,
      "heatingRate": 4.248,
      "inverted": false,
      "maxPwm": 1,
      "pid": {
        "d": 0.115,
        "i": 0.0107,
        "overridden": false,
        "p": 0.07456,
        "used": true
      },
      "standardVoltage": 24
    },
    "monitors": [
      {
        "action": 0,
        "condition": "tooHigh",
        "limit": 300
      },
      {
        "action": null,
        "condition": "disabled",
        "limit": null
      },
      {
        "action": null,
        "condition": "disabled",
        "limit": null
      }
    ],
    "sensor": 1,
    "standby": 230,
    "state": "off"
  }
]

I first thought it is a bug in my Home Assistant integration, but the issue seems with the API (tested only SBC) or DWC.

Edit 4: With v0.1.1 standalone mode is fully supported and so are multiple tools. I also implemented proper setup to prevent duplicated integrations for the same board, so multiple integrations are support now as well.

Edit 3: We are on v0.0.5 now. Added experimental standalone mode. Can’t test it because I am only using SBC.

Edit 2: Released v0.0.2. All sensors are created properly and getting async status updates every 5 seconds. Ill follow up later to make the interval configurable and I also need to take another look at finishing up the setup when the printer becomes available later

Edit 1: Introduced a bug in the version so that the state is not always updated properly. Working on it

Hey folks!
I refactored quite a lot and we now have a proper integration between the DSF and Home Assistant. When you create the integration via ConfigFlow you have some options you can choose from, including the option to add an LED controller, which is handy if you have LED's connected to your Duet.
The Device itself represents the physical Duet board and shows your correct model as well as the firmware version. All entities now have unique id's and should not conflict anymore. All sensors, binary sensors and the send_gcode service should work properly now

Keep in mind that if you have the integration already installed, you need to remove the integration once more and install it again. That is necessary, because I have rewritten the way of how entities are registered in Home Assistant.

You'll find all infos here in the first release: https://github.com/Lyr3x/hass-Duet3D/releases/tag/v0.0.2
@dc42 it would be nice if we can upload the Duet3D logo here: https://github.com/home-assistant/brands/pulls - we can use the logo then with this integration.

I'll look for a better solution for the Position sensor soon.
If you find any issues are need additional sensors, please create a GitHub issue from now on:
https://github.com/Lyr3x/hass-Duet3D/issues

I am also more then happy to accept PRs

@nikscha said in Home Assistant Integration:

service: duet3d_printer.send_codedata: gcode: M291 P"X" R"X" S3

Ah gotcha. That is specific to the API call. It seems to be synchronous or it times out. If you press the OK button, the request is done. The integration does not validate the GCodes but just send them to the DSF API. If you make a similar call via curl you see the exact same behavior.

@nikscha Yep do that, maybe there is something cached from previous iterations. I tried that for you on a fresh local installation. Labels are working as intended
There is also no delay here with M291 P"X" R"X" S3 or any other GCode. It's exactly the same as with DWC

@nikscha Interesting. That is not what I see here

Did you remove the integration completely once?
Yeah, the checkbox is the check if you have a hotbed or not

@nikscha what do you mean with naming the fields? They all have labels

I’ll test the gcode tomorrow and see if I can find out what causes the delay!