Hi!
I'm not sure if this is a largely discussed topic, I tried to look for it in the forum but I didn't find anything useful. In case, please forgive me!
I have an actuator that I can command and read the state through the use of two topics in Mqtt: /sensor_generic/state /sensor_generic/command
If I want to turn on the actuator I write "on" in the topic /sensor_generic/command, then I do some stuff in a function in node-red and then node red writes "on" in the topic /sensor_generic/state .
But the actuator can also turned on in a manual way, and since I want everything aligned I read the status through another topic in Mqtt (/sensor_generic/manual ) that acts on /sensor_generic/state .
But I would also that /sensor_generic/command is aligned at the value of /sensor_generic/manual .
Is there an easy way to do it without falling into some fluctuation state?
It isn't clear what exactly goes to the actuator and what comes from it?
Does the publish to /sensor_generic/state go to the actuator or does it come from the actuator?
Similar questions for /sensor_generic/command and /sensor_generic/manual.
I would have expected the command to go to the actuator and the state to come back from it but that does not fit with your description.
By the way it is recommended not to use mqtt topics starting with /. That just wastes a level of topic in the broker. It would be better to use sensor_generic/state etc.
The actuator doesn't directly publish the state to mqtt, it triggers a digital output when the actuators go ON. Then I used another device to read the DO and publish the state on MQTT. The topic is /sensor_generic/manual' .
Repeat the whole question please, in the level of detail of your last post. Telling us exactly what happens where. Then hopefully we will be able to understand the problem.
Apologies if I seem dumb but I still can't envisage the setup.
I know that you have a computer running Node-red and MQTT
Apart from that you have an actuator, a device with a digital output, a device to read the digital output, a keyboard and presumably some sort of switch that can be controlled by MQTT or the keyboard.
Please clarify.
It would be helpful if you could draw a diagram to show the physical setup, all the devices involved and the connections between them.
If it's not disclosing confidential information, please also say what the devices are.
Abstractions like "an actuator", "another device" make it harder to understand the setup. "Arduino" or "Texas Instruments MSP430" etc would tell us more about the device and it's capabilities.
And once we understand the hardware, hopefully we can advise on the best flow of MQTT messages to avoid fluctuation of state!
Apologies, I thought to use generic terms and semplify and I realize I just described a mess impossibile to understand.
The actual situation is the following:
the actuator is an old security alarm that I can query through a webserver (proprietary) with POST request. It doesn't have any MQTT capability but when it applies a scenario it triggers a digital output ON. Then I use another device to publish this digital to MQTT. To know the exact scenario I need to do a POST request.
the physical keyboard is the proprietary keyboard where I can manually apply scenario (scenario 1, 2, etc).
I'm trying to use homebridge and the plugin mqttthing to make the system smarter. It requires two mqtt endpoints, one to read the state of the security system , the other to set the state (scenario).
The problem is that after this second case I don't know how to align the topic system/command and system/state. If I don't do it the app will show the wrong scenario activated. If at the end I wrote the new state on system/command the flow will restart again, taking the system in this fluctuation.
If any change in the actuator status results in an MQTT message from the digital output and you then interrogate the actuator over HTTP to find the actual scenario, I think you can look at it as two discrete flows. One to handle commands from the phone, one to interrogate the actuator and report the status.
There does not seem to be any scope for the output (MQTT topic system/status/scenario) to get out of sync with the actuator because the output is always driven by interrogating the actuator.
But maybe there is an issue when the actuator is off?
You could perhaps repeat the HTTP request at frequent intervals. If there is no response within 5 sec say (a trigger node can do this), it can be reported as OFF.
I don't use Homebridge so I don't know the details of the interface with Node-red. If it was a problem to send the same message on system/state every few seconds, you could pass the output through a filter node to remove duplicates.
homebridge uses system/command as topic to write the command, and system/state to read the status. Problem is they need to be aligned, otherwise it doesn't understand why state and command are different.
When I manually turn the system on I have the update of system/state but system/command remains at the previous state. But if I update it on node-red at the end of the flow then the flows re-triggers, ending in a loop.
Maybe there's a smarter way to implement it but I don't have a big experience in nodered.
