How can I get the initial state of an MQTT switch?

I am playing with an Orvibo S20 smart switch. I am writing an MQTT wrapper for it so I can use it with OpenHab2.

I have everything working (i.e. I can control the switch and see switch transition) except that I cannot see the initial state of the switch. Until I either command the switch to flip ON/OFF or I flip the switch manually, I do not know the state the of the switch. How is this supposed to work? Can OpenHab2 somehow force the switch to pubilsh the state? If the switch supposed to publish the state when someone subscribes to the topic (I am not even sure if MQTT brokers expose this …)

The way I understand MQTT and the switch, I can’t see how you would be able to get the initial state of the switch. :frowning:

If the publisher publishes to the broker with the retain flag set, a future subscriber will immediately receive the retained message:

A retained message is a normal MQTT message with the retained flag set to true. The broker will store the last retained message and the corresponding QoS for that topic Each client that subscribes to a topic pattern, which matches the topic of the retained message, will receive the message immediately after subscribing. For each topic only one retained message will be stored by the broker.

(From here.)

So if you can get the publisher to publish to topics with the retain flag set, that ought to address your need.

The problem with these switches is when they lose power, the come back with a default state of OFF. Since there was no message sent, or even if the last ON was retained, it does not reflect the current state of the switch.

I’d say that makes the Orvibo S20 smart switch not so smart, if there is no way to query the state of the switch, or no way to publish its correct state on restore of power.

There is one little bit that is ambiguous about that Hive MQ document. It talks about “new” clients subscribing and getting that message. But what if OH gets the message, loses connection, then reconnects? Does the Broker treat that as a “new” client and publish the retained message, or does it recognize that it has already sent this message to that client (presumably based on the client’s ID) and avoid sending the duplicate message?

Does the QoS setting change this behavior? For example, if I set QoS to 2 (Exactly Once) then upon reconnect I shouldn’t receive the retained message because that violates the QoS, at least with one interpretation of how all of this should interact.

When I have time I think I’ll run some experiments but if you know off the top of your head…:slight_smile:

1 Like

I don’t know, but a little experimentation should give a good answer!

1 Like

I have settled for MQTT as the messaging protocol…
All Arduinos ‘talk’ the language :slight_smile:
However, the most used library does not support QoS, which I found not to be a problem…
E.g. I am currently working on my tank refill system… it has three Arduinos: tank, distribution hub, pump… the tank sends a heart beat every 10 seconds, which the hub listens to; and in case it is not received, it switches the pump off. It also listens to the heart beat of the pump; same, here, if it goes missing it switches off. – If the pump does not receive a heart beat for the hub it switches off too.

On a side note: Next step is to intercept the ‘tank demand’ messages in openHAB, and only pass them through when excess solar is available or in a specific time frame.

What I liked most about MQTT: no matter what interface, once a device wrapper is created openHAB and anything else can talk to each other – and I can read it without hex conversions or other cryptic stuff, like serial or RS485 comms.


You’ve found a good work around but it is unfortunate that the Arduino library doesn’t support QoS. Though given the limited memory I suppose they had to cut something. Most of the time, particularly in HA situations one can live with a default QoS, particularly if one sets up heartbeats, acks, queries, and/or other ways to confirm the message made it and write rules and code to handle multiple copies of the same message.

I myself implemented a query (i.e. publish a message which caused the devices to report their current state) and recently implemented a heartbeat.

Also, don’t forget about the LWT. Once I started using those it became almost trivial to detect and identify when devices go offline and depending on actuators in place address the problem.

NOTE: adding a temp/humidity sensor that reports on a set period makes a great heartbeat :slight_smile:

However, I can see some cases, particularly when one is dealing with irrigation and power generation where one might want to use something like QoS 2 on top of some of the other mechanisms described. A missed message or a duplicate message could have bad to catastrophic consequences.

And the more logic that one can push off to MQTT the less I have to write. :wink:

Have a look at the Time Of Day and Separation of Behaviors design patterns. What you are describing is really close to a simple state machine and the ToD plus SoB design patterns get you most of the way to a state machine.

I could see implementing a Switch for when the “tank demand” messages are allowed to pass through or not. Then another rule or set of rules that calculates whether or not the home is in the right state to allow it and set the Switch accordingly.

The tl;dr is that by separating the calculation of state from the logic that cares about state it becomes far easier to control, maintain, and understand the rules logic. And there are tons of ways to develop, model, and understand state machines which can become important as someone’s HA becomes more and more complex. And since you are “automating all the things!” :slight_smile: you might get to the point that using tools to help model your environment might become helpful.

I completely agree. You also get to leverage the work done to set up the broker and comms in the first place. Adding a new device becomes almost trivial. I am very grateful that I set up Mosquitto back when I started to play with Mqttitude (now called OwnTracks).

I’m glad to see you making so much progress. If you have any lessons learned or challenges you have overcome I bet the community would love to read about them.

1 Like