Delay turning Shelly switch off based on power draw


I have a Shelly 1PM controlling an air compressor that lives in a shed behind my workshop. Idea is that via HA I can turn it on when I’m in the shop, and have it turn off again some period of time later so I don’t have to think about it. This in itself isn’t an issue - Switch starts timer, timer runs and then turns switch off.

To add some complexity, I don’t want the compressor to be turned off if it is running - it needs to complete the cycle and unload the compressor head before I turn the power off. Again, I didn’t think this would be too much of an issue - have the output of the timer fed into a “current state node” that would read the power draw from the Shelly PM. If it is drawing power say about 500w, then delay 5 minutes and loop back into the current state node, if below 500w then turn off. This all seems to work ok in theory, but i am struggling to control it from HA.

What I would like to be able to do is use a button / switch to turn the compressor on from the Dashboard in HA. The dashboard would then show me that the compressor had power. If was to turn the switch off from the dash board, and the compressor was running, I would see that the switch was off but the compressor was still running, and then when the cycle had finished, it would show that it was off.

Is this a bridge too far, and should I just use the dashboard to turn it on, and then tell the members of the household not to turn it off via HA but let it time out instead, or is there a way to display both the selected state of a switch, and the current state?

Not a complete solution, but a suggestion.

This reads like a power switch being on / off, and a device being running / idle, with a need to pass through an intermediary state ‘pending off’, which the switch goes from on->off and the device only goes to ‘turned off’ when the power draw stops.

With multiple states, and multiple triggers, why not try a finite state machine (FSM)?

This is a contrib node, found at node-red-contrib-persistent-fsm

I have used it for monitoring blocks of Modbus reads from an inverter. The basics are

  • define a list of states
  • define a list of triggers
  • code the right triggers, for each state to move to another state

In your case, the device is ‘idle’ or ‘run’, the switch is ‘off’ or ‘on’. This leads to four possible (finite) states

  • off (no power, not running)
  • idle (power, but not running)
  • run (power and running)
  • stop (pending turning off)

The triggers are

  • switch on
  • switch off
  • current on
  • current off

For each of the four states there are four possible triggers, some of which are either unlikely or an error. In simple terms, the key state-trigger events could be:
OFF: switch on → IDLE
IDLE: switch off → OFF
IDLE: current on → RUN
RUN: current off → IDLE
RUN: switch off → STOP
STOP: current off → OFF
STOP: switch on → RUN

The state machine node can be set to receive triggers on any msg. value. I use msg.topic, thus you could set msg.topic to the output from the switch as msg.topic = “switch on” from the switch, or “current on” from the ‘current state’.
The node can then output the state at each state change. This can be used to both display the state as you wish (there are, in effect, four states and thus one line of text is perhaps better than two Boolean flags) and to turn on or off the power. Moving from state ‘off’ to ‘idle’ turns on the power, from ‘stop’ to ‘off’ turns off the power.

I set up the node with the basic states and transition rules just to see what the state machine looks like. This amazing node has an interactive diagram to show the FSM - can get messy with too many states and transitions, but it is click and drag to redraw.

I have not added every transition (there are 16 possible paths in all) so you might want to add in the rest and just leave
OFF: current on
as an error to either ignore or report.

The state machine looks like this: the OFF state is the initial state on start up.

Hope this helps.

1 Like