As I am quite new to OH3 I am looking for some support or suggestion on how to setup my system properly.
Let me explain my setup first:
OpenHab 3 is running on an raspberry pi 3 (with native rasbian-os)
MQTT broker is running on the same rpi3
I have one ESP32 with two 5V-LED strips attached (~270LEDs on the one + 170LEDs on the other) due to the load I power the ESP and the 2 LED stripes with one 130W-PowerSupply (230V->5V)
As the 130W Power supply consumes ~7Watts in standby if now device is attached to 5V I want to be able to switch the power supply off if I am not using the LEDs, therefore I am using a IKEA Tradfri Switch
OH3 and the ESP32 comunicate via MQTT (and MQTT binding)
The IKEA switch communicates via the tradfri binding (and a IKEA hub)
Problem:
If I want to switch on the lights I now need to power on the switch
Wait for some time (~2-3sec) until the ESP32 is up and connected to my WiFi (+MQTT)
Then activate the LEDs by selecting a color
Idea:
I want to perform this as a kind of a ruleset and hide the “power switch” from the user experience
Currently I defined a rule which allows me to activate the power on a color change, but then the selected color is send by openhab at the same time when the ESP32 is not yet online and therefore the information is lost and the user needs to change the color once more before the LEDs turn on.
So my question is, can I delay the send of the MQTT request?
Or can I resend the MQTT request after some time?
Or my I implement a script in OH3 for this? (Don’t have any experiance with skripts in OH yet)
Also feel free to comment if you have a more elegant way to solve my problem.
Thanks for any hint or guidance how I can solve my problem.
To implement this as described you have to use a rule. That’s what rules are for, to coordinate commands and events for multiple devices.
Send the command to the Tradfri first then schedule a Timer to sendCommand to the MQTT Item after a second or so.
However, for most users that delay makes for a very poor user experience. But there is no way around it. Either you need to keep the thing powered at all times or you need to live with the bad user experience.
Another alternative is to configure the MQTT message to be retained. Then even if the ESP32 isn’t online when the message is sent it doesn’t matter. As soon as it connects it will receive the retained message. That approach will let you shorten the latency as much as possible as the ESP32 will receive the command immediately after connecting to the broker.
However, that message gets retained forever, until another retained message replaces it. That means on a restart of the ESP32 for any reason, it will receive the last message published no matter when it was sent. That may be desirable or it may break the use case entirely.
For example, if you commanded the lights on and then the power was lost. Once everything comes back up the lights will turn back on because that was the last message published.
Thanks for the hint on the “retained” attribute in mqtt, this may help me out and I will test it in my configuration.
Do you know if it is possible to define a kind of a “timeout” for this retained attribute in the mqtt broker? E.g. say it shall be retained for the next 5min or 5days and then it shall be removed from the broker even if no new mqtt request is received?
There is no timeout. There is no way to delay the sending of the message except through OH rules. I think the next version of MQTT may support a timeout for retained messages but that’s not available now.
