Ridiculously complex Modbus dimmer control flow

The latest monster to rise from the slab:

All that, for this:

Screenshot_2021-02-10_20-13-16

This convoluted beast lets me control a 4-channel Modbus controlled PWM/CV dimmer from a Node-RED dashboard, and programmatically - as well as by physical push buttons connected directly to the dimmer, which allows the dimmer to operate stand-alone when the computer (or network) is down. The Modbus registers on the dimmer are used as the definitive source for channel values (read every 5s), but I also store level and "state" for each channel in Node-RED, as well as min/max level allowed, so the UI remembers the slider positions when a channel is off (channel level = 0). The lowest slider setting does not represent "off", but the minimum level at which the connected LEDs produce light. Conversely, the highest slider setting is not necessarily "255", but the level where light output stops increasing - which may save a bit of power. These limits are enforced also for the physical buttons, albeit with a 5s lag - and only as long as the computer is running. UI actions inhibit Modbus polling for a moment, to prevent the state being changed by an incoming update before the UI action has completed. Slider movements are "pared" down to the last message in 500ms windows, to stop bus writes from piling up. An important feature is that it handles all four channels/registers in each Modbus read/write operation - which cuts bus traffic significantly.

Happy to answer questions - and to get suggestions for improvements!

modbus_dimmer_control_flow.json (17.3 KB)

3 Likes

Been playing with this for a while, having a beer (well deserved I think) - just can't stop turning different lights on & off, getting up to push a button, quickly back to screen to see the updated status, trying to break the damn thing, but it just carries on perfectly whatever crazy stuff I do. My neighbours probably think I am insane. Oh wait, I don't have any neighbours!

*gets up to push a button*

Ok, I did find a problem: sliders always pass through the incoming message, and if I set all channels at once (i.e. a "scene") then all sliders pass messages at once, and the "pare" (trigger) node drops most of them, resulting in unpredictable behaviour. Will implement alternative method for limiting bus writes when moving sliders but wish there was a setting which broke the link between slider input & output; a "respect the input but only output when the slide is manually moved" option...

Fixed by moving "pare" node to after the function node which merges input values with stored values:

modbus_dimmer_control_flow.json (19.0 KB)

Isn't that what the pass through checkbox does?

My slider settings look like this (Dashboard v2.23.2):

Screenshot_2021-02-11_11-40-42

No "pass through" checkbox... Maybe you're thinking of the switches, which do have one:

Screenshot_2021-02-11_11-46-26

Update to the latest dashboard.

I stopped the Node-RED system service, subbed to the nodered user, and ran npm update in the .node-red directory. This pulled in a whole bunch of updates, including Dashboard v2.27.0. Exited back to myself, restarted the system service, and refreshed the admin page. Aaaand the slider settings look identical to what I had in v2.23.2. Confirmed v2.27.0 in the "Manage Palette" window. Ah well, at least good to be up to date!

This is what mine looks like (dashboard 2.27). Don't worry about the background colour, that is just the theme.

Try clearing the browser cache.

Yep, a browser restart did it. Still testing the implications of this new function, but so far it looks like exactly what I wanted. Thanks!

It is better to clear the cache. A restart will not necessarily achieve that, though in this case it seems to have been enough.