Following a conversation over on the DSF LPC discord group about using MQTT with DUET, I've had a go at creating a python service for SBC's running DSF, which enables MQTT integration with DSF.

MQTT4DSF (https://github.com/MintyTrebor/MQTT4DSF) has 4 main functions:

1. Subscribe to user defined DSF events and send mqtt msgs to a broker of choice on receipt of event (user configurable)
2. Poll DSF on a timed frequency and send mqtt msgs based on a value delta (user configurable)
3. Send user defined MQTT msgs when specially formatted M117 msgs are received from DSF events.
4. Act as MQTT to GCode proxy - passing GCode commands to DSF and executing them on the machine, by subscribing to a custom MQTT topic.

Short video of features in use - https://www.youtube.com/watch?v=2XwTgxythTE

It runs on the DSF SBC (tested on rpi), using the DSF python API library, and the Duet Rest API. Its user configurable through a json file accessible through DWC.

It's had limited testing but I hope it might be of use to someone here.

I've been running a simple node-red mobile/small screen sized 3d printer status dashboard form some time, which I recently updated to work with the Duet API after upgrading my printers.

Its not very sophisticated - I am posting here in case it is of use to anyone else.

https://github.com/MintyTrebor/Duet-Node-Red-Dashboard

The repo has two flows :

The "universal" flow just requires the duet IP and webcam IP, it will ping the network, and when the printer is turned on check the Duet API version, and start updating the dashboard. Once the printer stops responding to ping it will stop updating the dashboard. The flow has been designed to be easy to follow. It could be significantly more optimised, should it be required. I would recommend reducing the polling frequency once you have it working (currently set for every 5 seconds), it does not need to be real time!

The "example" flow is abstracted from my home automation dashboard, which includes MQTT calls and other automation stuff. It is provided as a reference example. This flow only updates the dashboard when the 3d printer is turned on via MQTT wifi socket.

Background:
I wanted to be able to view both my 3d printers at a glance, control my enclosure temperature, and integrate the power control of my printers through my existing node-red home automation dashboard . Both of my printers are in my garage with external access only, hence I came up with this. It does not replace DWC. But I found status monitoring in DWC is not ideal for mobile/small screen and multiple printers.

How I use the dashboard:

Hope someone finds this useful!

I have been working on a side-project / plugin for a while called NodeDSF. There is the mandatory crappy youtube video showcasing some of what you do with it here : http://www.youtube.com/watch?v=Y6JZ-lblt5w.

In summary, it is a set of custom nodes for Node-red which interface with DSF (on SBC) and enable you to create your own event driven actions.

There is also a plugin for DWC which allows you to embed simple node-red dashboards into DWC.

The project is here : https://github.com/MintyTrebor/NodeDSF.

It's only just been made available today, so assume it has bugs etc (so far it has a test user base of 1 ).

I have attempted to write a wiki and included some examples on github.

I hope its of use!

**V1.1 Update - Connect to Duet boards directly **
I have enabled a new experimental Duet mode which enables a direct connection to Duet control boards (v2/3) running firmware v3+, so you can now choose to connect to DSF on an SBC, or Duet board directly. (I have only tested this on a Duet v2 ethernet board, but it should work for the other versions). Non Duet boards (eg LPC) with onboard wifi modules will not work due to session limitations; An SBC with DSF is still required for these boards.
The plugin remains an SBC only option.

@chrishamm : Not sure if there is anything you can do about this as I suspect it might be a framework version issue but I thought it was better to post than not...

(Testing on 3.3b2)
One of the testers for a plugin I am working on, reported an issue with a v-select in a dialogue box, where clicking the select resulted in the small arrow changing direction, but no options showing :

I was unable to re-create this on my 3.3b2 test system:

After going through the typical browser checks and trying different browsers, with no change - I completely re-wrote the dialogue page and the tester had this result:

If you look at the picture you can see the selection options are rendered behind the dialogue.

None of the plugin code changes any elevation or z-index parameters and I was unable to resolve it, so to avoid this happening for other users I have changed the dialogue to use radio buttons instead (which work fine).

This issue did not happen on 3.2.2 tests with the same source code ( re-compiled).

I went through the 3.3.b2 source and could not find a single instance of a v-select being used in a dialogue box, so I am wondering if this might be a framework version bug/issue that has just gone un-noticed.

It would be great if I could get to the bottom of it, or even find out what I did wrong.

Thanks

Hi @the_dragonlord, I'm the author of the NodeRed Mobile dashboard. Happy to help with any questions you have etc, but I thought it might be worthwhile explaining how it works, as it may not be the ideal candidate for the scenario you describe.

The NodeRed dashboard pulls information from the DSF http rest api at a pre-defined polling interval (5 secs by default). This is fine for status monitoring (temps etc), but not for event monitoring. If the event you wish to monitor happens in-between the polling interval, there is a significant probability that by the time the next polling is completed the event information has been cleared/overwritten by another event, which could result in missing the required event entirely.

Can I suggest you have a look at MQTT4DSF as an alternative. Amongst other things, it can monitor user specified events and send MQTT msgs when triggered. You can then use any rules engine (including NodeRed) to monitor for those MQTT msgs and trigger another set of actions (ie send an email).

Hope this helps.

I have updated the nodes to V1.1 with a new experimental feature which allows connection to Duet boards directly - no SBC+DSF required! (see edited first post for details).

@chrishamm Thanks for getting back to me.

Yes I can give it try, providing I can get my tester to retest (hint hint @jay_s_uk ).

I'll update here with the results.

If the thermal runaway condition creates an error message, then you can detect it and make a web call with my NodeDSF solution.
You can configure NodeDSF to watch for status changes or error/warning messages containing specific text, and then trigger a http post/get, or fire mqtt, or send an email, etc etc.

I know that heater faults create error messages, but I am not sure specifically what happens on a thermal runaway - I have found that normally any issue will create an error or warning message.

(Link in my sig)

@Dakota - Hi. There are written instructions on setting up node-red in the NodeDSF installation wiki pages 😉 ...

If you prefer video instructions for installing node-red, there are many already available on youtube, for quite a few different platforms.

The NodeDSF node-red nodes should work on any Node-Red installation regardless of platform (windows/pi/docker/linux etc).

Edit: I forgot to add. You say that you have a Duet Wifi Board - So can I infer that you are not using the Duet Board + SBC connected over GPIO configuration?... The DWC plugin does not work for stand alone Duet Boards. (please refer to the wiki).

The node-red NodeDSF nodes work for both standalone and board + SBC configurations.

@chrishamm Thanks for getting back to me.

Yes I can give it try, providing I can get my tester to retest (hint hint @jay_s_uk ).

I'll update here with the results.

@chrishamm : Not sure if there is anything you can do about this as I suspect it might be a framework version issue but I thought it was better to post than not...

(Testing on 3.3b2)
One of the testers for a plugin I am working on, reported an issue with a v-select in a dialogue box, where clicking the select resulted in the small arrow changing direction, but no options showing :

I was unable to re-create this on my 3.3b2 test system:

After going through the typical browser checks and trying different browsers, with no change - I completely re-wrote the dialogue page and the tester had this result:

If you look at the picture you can see the selection options are rendered behind the dialogue.

None of the plugin code changes any elevation or z-index parameters and I was unable to resolve it, so to avoid this happening for other users I have changed the dialogue to use radio buttons instead (which work fine).

This issue did not happen on 3.2.2 tests with the same source code ( re-compiled).

I went through the 3.3.b2 source and could not find a single instance of a v-select being used in a dialogue box, so I am wondering if this might be a framework version bug/issue that has just gone un-noticed.

It would be great if I could get to the bottom of it, or even find out what I did wrong.

Thanks

@chrishamm you can get the plugin here https://github.com/MintyTrebor/BtnCmd/releases

I'm creating separate versions for 3.2 & 3.3 - they are both available in the releases.

I think the plugin is almost ready to go - I'm just resolving some dynamic layout issues. So it should functionally work OK.

Thanks for looking at the issue.

When I try to install a new custom plugin I have developed on a Duet2 Ethernet running 3.2.2, I am getting the following error:

Failed to decompress files cannot convert or null to object.

This does not happen when I install the plugin on a Board + DSF/SBC 3.2.2 configuration.

The weird thing is the plugin actually does install, and is fully functional, so the error seems somewhat spurious.

I would like to know if anyone has any ideas what could be causing it before I release the Plugin.

Thanks

Update: I re-compiled the plugin for release 3.3b2 and the error has gone. Must be a 3.2 issue...
Update2: 3.3b2 - Unable to install newer release of plugin without uninstalling existing plugin first. Err = Installation failed!
TypeError: m.dwcFiles is undefined. After uninstalling, plugin installs correctly.

(Not sure if these updates are valuable or should be issues on github - let me know if you would prefer me to move)

@Dakota - Hi. There are written instructions on setting up node-red in the NodeDSF installation wiki pages 😉 ...

If you prefer video instructions for installing node-red, there are many already available on youtube, for quite a few different platforms.

The NodeDSF node-red nodes should work on any Node-Red installation regardless of platform (windows/pi/docker/linux etc).

Edit: I forgot to add. You say that you have a Duet Wifi Board - So can I infer that you are not using the Duet Board + SBC connected over GPIO configuration?... The DWC plugin does not work for stand alone Duet Boards. (please refer to the wiki).

The node-red NodeDSF nodes work for both standalone and board + SBC configurations.

I think (from my spotty memory the last time I looked at the DWC code) that the layer chart is constructed in the client browser over time from the data obtained from the Machine Object Model.

You can get access to the Machine Object Model by using the Rest API.

(I've circled the portion I think is relevant to you - sorry for crappy screen shot)

You may have to pull the info you want on each layer change....

If the thermal runaway condition creates an error message, then you can detect it and make a web call with my NodeDSF solution.
You can configure NodeDSF to watch for status changes or error/warning messages containing specific text, and then trigger a http post/get, or fire mqtt, or send an email, etc etc.

I know that heater faults create error messages, but I am not sure specifically what happens on a thermal runaway - I have found that normally any issue will create an error or warning message.

(Link in my sig)

https://duet3d.dozuki.com/Wiki/Object_Model_of_RepRapFirmware

will get you started.

Is MachineModel a Json structure that will be returned with the request ?
Yes.
The easiest way of seeing it is by entering:

http://[your sbc/dsf ip address]/machine/status

into your browser.

It should just return the full JSON Machine Model as text (if using firefox it will automatically parse for you).

For the avoidance of confusion - the returned data is just text with an enforced structural pattern (JSON)

@ElevenJune If your using the rest api to query the status then you will have to use the machine model. The HTTP GET /machine/status request you can send returns a JSON object which is the Machine Model. If you go the websocket route, it will still be JSON and the machine model. I don't think there is any way around it with the rest api.