Hi dear community,
I searched for a solution for my problem since I started using NR with HA.
I came from home-bridge with home-bridge-mqtt, an mqtt server and Node-Red, so I am not new to NR.
My problem is that I want a simple and slim solution how I can create switches in HA frontend that I use there to trigger actions in NR BUT also change their state with NR without getting into a loop.
At the moment I am using input_booleans paired with trigger-state nodes which works to get the events from HA and do stuff.
The problem arises when I have to control the state of the input_boolean from NR because calling the service to set its state I get also the event in the trigger-state node just as if I pushed the switch in HA frontend. This creates loops…
I found some posts talking about something similar but I didn‘t get it how to circumvent this.
I read about using MQTT switches but I really don‘t get it that I need to setup a whole parallel infrastructure (MQTT server) and use that as man-in-the-middle while NR seems to be integrated to HA, or am I missing that that current integration is just not covering what I want?
Let me just explain one use case. I want to toggle the power of my 3D printer with HA, the power is controlled with a 433MHz wall plug, 433MHz transmitter is the Raspi also used with OctoPrint to control the printer.
On the other hand I can control the plug manually which I do if I am right in front of the printer.
I created an input_boolean and NR monitors the state with a trigger-state node, if it goes ON then it uses SSH to send the signal to power on the plug and also if it goes off. I can monitor if the printer is on by listing the USB devices on the Raspi. That is done every 10 seconds and if I find the printer then I also want to set the state of the input_boolean because then I turned the printer manually on.
But there is the problem, setting the state of the input_boolean using „call service“ also triggers the trigger_state node again.
I created some advanced flow using „enable“ and „disable“ for the trigger-state node but this is not working so well as there is some time difference between toggling and the monitor reporting back that it is really on. So most of the time I switch the input_boolean it goes on then back off a few seconds later because the monitor still reports off, but then the printer is on.
So as far as I can see using MQTT switches would maybe solve the problem, I think I am going to try to test this out, but still my question remains: do I have to expand my setup that way and make it more complicated just to be able to achieve that? Or is there some attribute to pass to call service that prevents HA from sending the event just as a user toggled that input_boolean?
Hmmm thanks for the idea but if it is off and my monitor flow detects it is on and then calls the service to make the input_boolean in HA show that is on that input_boolean was off before.
If I now set it just to react on the trigger if it was off then this is true.
Here a shot of that flow:
The top turn my printer on and off when I use the input_boolean of HA, the lower checks if the printer is online in case I switch in on or off manually and then sets the input_boolean by calling the service, but that call triggers the upper flow…
Ah ok. I think I understand. When you turn on with the bottom flow, it is just to make sure that HA and your manual action are in sync. Correct ?
In this case, on the top flow, insert a trafic light between “trigger” and “switch”. By default make it green. So, When HA triggers it, it will be activated.
On the bottom flow, before calling the “turn_on” service, send a “red” message to the traffic light of the top flow. Then call turn_on. Wait a bit, eg 5 sec, and then send a “green” message to the trafic light. By doing so, HA will receive the “turn_on”, the trigger will be activated but the traffic light will do its magic, as it will be red, the message will not be sent to the rest of the flow.
GV
I “disable” and “enable” the trigger state node but sometime this seems not to be enough, I tried with longer wait times but when testing 100ms seem to be fine. But in real life when I am not monitoring the flow and debugging then it does not always work as expected.
Basic intention of my question was if there is something I can just tell HA to change the state without doing anything else but all I found is that this is not possible other than on the developer stat page, doing this another way seems not to be possible…
Only other thing is using MQTT. Then MQTT is in charge of what the state is and HA just displays it and if the MQTT topic change to enabled then HA will also change…
From my experience, the trafic light is more reliable that disabling the flow like that. It is about running priority within nodered (I don’t undestand all the details though). Having a trafic light and a longer wait period than 100ms should be more stable. I think.
100ms on a non real time machine is a very short duration. And depending on the load of HA, nodered, cpu, memory you might have weird race condition.
GV
Yeah you might be right… will try that and also test out MQTT which might be better suited for something like that…
It seems to me HA is not built for such a case, it is meant to control devices and communicate directly with them, NR then can being some logic to that, but having no real directly controlled device is a problem, for just some logic and triggering the device-less controls seem not so good. With MQTT I have then the „device“ which has a state and NR then controls the device and HA does it and reacts on changes of the device just by displaying the state when that state changes just like it does for other integrations that have a manual method. For example ESPHOME works great for me controlling the devices manually with hardware switches and from HA…
