There is a dashboard on the NodeRed, which displays the sensors. Now there was a need for a switch, I decided to try espEasy on sonoff on MQTT, everything works, but the problem is that the status of the switch on the dashboard is not updated if I switch through another application from the smartphone.
From the phone I publish: / nameSonoff / gpio / 12
Two messages are published: / nameSonoff / gpio / 12, / nameSonoff / relay / Switch
How do I understand / nameSonoff / relay / Switch is the switch status?
Please tell me how to configure NodeRed, a switch that will track the current state?
Currently in NodeRed: [dashboard switch] -> [output MQTT (subscribed to / nameSonoff / gpio / 12)
If I connect the incoming [input mqtt] signed to (/ nameSonoff / relay / Switch /) to the dashboard switch, then it switches on and switches off immediately when it is switched.
I think you should feed gpio/12 into the front of the switch (and make sure that message pass through is not enabled in the switch). Then the first switch will follow the state of the second. If you make gpio/12 a Retained topic in MQTT then MQTT will remember the state and will restore the current switch state after a reset.
You should try to use debug nodes when your flow doesn’t do what you expect. Then you should be able to track a message through your flows and see where the flow deviates from what you expect.
You are sending a number 1 or 0 from the switch, which gets converted to a string on its way out to MQTT. Then the string “0” or “1” comes back from MQTT but because that does not exactly match what the switch expects then it does not work. Change the 0 and 1 in the switch to strings 0 and 1 and try that.
For me here there is also a small problem to consider, as the MQTT topic in & out is set to the same on ESPeasy it means you will receive the feedback of the change even if has not being send by the ESPeasy module, let say you are feeding directly the feedback from the command.
Correct me if I’m wrong…
For me for a sonoff modules the best is tasmota firmware, ESPeasy is great for using with other esp modules you made.
@davidcgu not sure what you mean. The switch will show the intended state of the output. If you also want to see the actual state of the output then the technique is to pick up the actual state from the sonoff state mqtt topic (is that relay/switch?) and show that also on the dashboard in some way. That topic should not be Retained. Also the LWT topic can be picked up and used to show the state as Offline or something when appropriate.
I also prefer the Tasmota firmware as it is more flexible, but it is also a little more complex I think.
I mean that with configuration done even if ESP module is offline will show on/off state as the in/out topic is the same, what means he is monitoring the real state on the ESP while just feeding the feedback directly from the same command on node-red.
Doing like this is exactly the same than change the status of the switch based on the state of the output and can delete the MQTT node in as is useless as is done right now.
There are options like have different topics for IN/OUT as example i use to remove the / on the topic of the in messages.
I am having difficulty fully understanding your comment, but if I do understand then the purpose of feeding the mqtt in back into the switch is so that if a different client writes to mqtt then the dashboard switch will follow that set by the other client.
Sorry Colin most probably I’m not explaining myself well and even maybe also I’m wrong.
I understand you expect the switch to show the real stated of the output (not the expected state).
Considering this, as soon as you publish a command of 1 on mqtt /example if you use the same mqqt topic to subscribe as feedback /example it means at the same time you publish the command you also feed the feedback what not necessarily should be the real state.
For instance imagine the ESP output drives a light and yo do as the example shown with same topic for subscribe/publish and unit is down, as soon as you publish 1 switch will shown light on state while the light will remain off.
If my assumptions are not wrong I thing is better to use a different topic for publishing that for subscribing, that will makes that as soon as unit is not responding you see directly that switch is also not responding
For instance publish 1 on topic “/cmd/example” (ESP subscribes to this topic) if unit is down and switch is getting the feedback from topic subscribed to mqtt “/state/example” (topic for pushing on ESP) swich will directly not change and this will make you realize directly there is a problem as is not responding.
But now after so many posts I’m started to have doubts… hahahahha
No, I expect the switch position to show the requested state not the actual state. This is consistent with a physical switch controlling a light. One puts the switch to On in order to request the bulb to light. If the bulb has failed or the power is off then it does not light, but one does not expect the switch to automatically return to the off position. One expects to have some sort of feedback to indicate that it is on (one sees the light for example). In the case of a node-red dashboard I expect the switch to act the same way, and I bring the actual state back via another topic and use that to do something like changing the colour of an icon on the dashboard or changing the background colour of the switch, or some On/Off text for example. This way one switches the switch and then the fact that the colour (or whatever) changes shows one that the device has actually switched.
There is too many ways to set up buttons and switches in application to say that done in one way is more correct than another… I think that most important thing is to keep the consistency along the application.
I work with machines and the ideal is to have close loop controls as much as possible, on this direction I prefer the switches to show, not the expected on/off position while better the real position or as much close to this that you can reach, in this case seing with the switch that the ESP unit get and has processed the order is a much closer feedback to the reality state, turning on the light on the phone does not necessarily means you are there to see it.
In my case I have light sensors on all rooms for some other purposes and in parallel I have a check up too, if lights are on on the room and sensor level is not high enough I have a notification that there is some issue in there.
This is the point… the switch will not respond and you directly will see that something is not working, this is the purpose of having different feedback and command topics, otherwise have no sense you directly won’t use the feedback and just publish the command and configure the switch to change base on the state of the output directly.
For me, as soon as you use feedback as he showed on the nodes picture has the sense to have some real feedback that confirm you the action was done as expected.
Having same topic for in & out will mean you will not realize that system doesn’t work when you use it, but this are just different ways to do things, any is correct or incorrect.
In my case on top of that I’m monitoring that stations are connected and if any is not responding then I get a dashboard notification telling me which one is lost.
For me the preferred way is also to use feedback. I don’t like dashboard switch as it kind of doesn’t behave always as expected. I use regular buttons and I change their background color and label according to real state of device. In addition, before i send out the button click, I put my buttons in disabled state to avoid uncontrolled behaviors. If feedback comes in, i manage out correct state (color and label) for button and make it enabled again.
On top of that, with my sonoff devices (with tasmota) I also listen (and use some data from) telemetry. As telemetry interval is known and if messages missing for some time, it indicates problems and I rise alert.
As offtopic, what are monitoring from sonoff (tasmotta) or/& ESPeasy? I have some kind of watchdog on the units and made a template to collect and show info as follows on dashboard, maybe you have some nice stuff to share than I can use
![Node%20red|690x57]
