MQTT Generic - retained flag not working

[Kirill-SPB (Kirill)]

@JimT

Is your item’s autoupdate set to false?

I don’t have this parameter set, apparently by default - it’s true

Bridge mqtt:broker:mqtt [
    host="192.168.77.100", 
    port="1883", 
    secure=false, 
    qos=0,
    clientID="openhab",
    keep_alive_time=30000,
    reconnect_time=60000,
    username="openhabian", 
    password="Mqtt5335"
    ]
{
    Thing topic Home "Home" @ "Main home"  {
    Channels:
        Type switch : lightHallway "Light hallway" [
            stateTopic = "home/esp/Lolin32main/control/0",
            commandTopic = "home/esp/Lolin32main/control/0",
            on = "1",
            off = "0",
            retained = true
        ]
......

Switch                      lightHallway        "Свет прихожая"             <light>     (gLightHouse)                { channel="mqtt:topic:mqtt:Home:lightHallway" }

[rlkoshak (Rich Koshak)]

@Kirill-SPB

in my opinion, it would be more logical if OH read the state from the topic to which it is subscribed and not from which it sends commands

That is in fact how it works. At least that is how it works for all of my MQTT Things.

@Kirill-SPB

            stateTopic = "home/esp/Lolin32main/control/0",
            commandTopic = "home/esp/Lolin32main/control/0",

Your Thing is configured to subscribe to and publish to the same topic. It’s not reading from the command topic, it’s reading from the state topic. You are just using the same topic for both, which is almost certainly going to cause problems.

[Kirill-SPB (Kirill)]

Rich, I also did my best to avoid duplicating topics, but as I wrote earlier, OH when connected, displays the state from the command topic in the site map and not from the state topic.
I check this by completely deleting the broker’s database, then using the ESP I send in the statTopic and commandTopic.
When I connect the ESP, I see that it reads both topics correctly.
OH when connecting to the broker puts the position in siteMap from the command topic

[rlkoshak (Rich Koshak)]

Your original posted problem as stated:

@Kirill-SPB

My saving of an item only works when the commandTopic topic is changed from the sitemap, but when changed from outside, for example, using my ESP through stateTopic, the element in the sitemap changes, but when the ESP is rebooted, the old state appears in the saved topic. Accordingly, the light on this element is not restored, although it remains on on the sitemap.

1. commanding the Item from OH works
2. controlling the ESP from outside of OH works, OH gets the updated state
3. when the ESP reboots, “the old state appears in the topic”. It’s not clear what you mean by that. But if the ESP comes up to some default state, it should report that state after it boots to the state topic.

Later you say:

@Kirill-SPB

but when changing my thing using stateTopic, the recording does not happen

Which I do not understand. What recording?

Later on you say

@Kirill-SPB

I implemented a code in my ESP that when one contact changes, it changes the state of the relay and sends the state to stateTopic.
Algorithm 1 - openhub commandTopic changes this state; everything is recorded and restored when power is applied to both devices.
Algorithm 2 - the esp itself changes the state and informs openhub using stateTopic.
also works, the state in sitemap is turned on, exactly the same actions occur in the log as with algorithm 1
but recovery does not occur on reboot; the ESP returns to the old state, and in sitemap the switch is on

It’s not clear. Is Algorithm 1 not working then?

No matter how you look at it though, in order for the ESP to return to the old state when it reboots:

1. the ESP needs to remember, somehow, what it’s old state was and return to that state on a reboot
2. OH needs to know that the ESP rebooted, somehow, know that it has not returned to the state OH currently thinks it is in, somehow, and send a command message to return the ESP to the last known state.

You seem bound and determined to not use 1. So you need to answer the “somehow” statements in 2. Hint, MQTT works by sending messages. So:

“OH needs to know that the ESP rebooted by the ESP sending a message, know that it has not returned to the state OH currently thinks it is in by sending a message (probably to the state topic) and send a command message to return the ESP to the last known state using the command topic.”

Does the ESP send a message when it boots?
Does the ESP send it’s current state when it boots?

I’m not sure how to state it more clearly. Maybe with a sequence.

Step	State	MQTT messages
ESP boots	Relays are OFF	ESP publishes that it booted to some topic
OH receives the boot message	Relays are OFF	OH runs a rule and publishes the current Item’s state to the command topic
ESP receives the commands	Relays change to match the state in OH	ESP publishes the new states of the relays to the state topic

Another alternative

Step	State	MQTT messages	Note
ESP boots	Relays are OFF
ESP receives retained messages on command topic	Relays return to last commanded state, publishes the new states of the relays to the state topic	Only works if the only way to change the relays is through the MQTT command topic and the messages command messages are always retained
ESP
OH receives state change messages	Relays are at last commanded states	OH updates the Items

Another alternative

Step	State	MQTT messages	Note
ESP boots	Relays are OFF	ESP publishes that the relays are OFF to the state topics
OH receives the state messages	Relays are OFF	OH updates the Items to OFF	The relays do not return to their last state but at least OH’s Items match the actual state of the ESPs

[Kirill-SPB (Kirill)]

@rlkoshak

1. the ESP needs to remember, somehow, what it’s old state was and return to that state on a reboot
2. OH needs to know that the ESP rebooted, somehow, know that it has not returned to the state OH currently thinks it is in, somehow, and send a command message to return the ESP to the last known state.

You seem bound and determined to not use 1. So you need to answer the “somehow” statements in 2.

It turns out I’m building a third option)
in case of no connection -
neither OH nor the ESP know about each other and about each other’s states.
but! when connecting to the broker, they read the saved topics and ESP puts up its relays, OH puts up its sitemap. that’s all I want

Everything works fine but provided that:
The ESP is signed and sends everything to one “command” topic
OX is signed and sends everything to one “commands” topic

if I do what I think is more correct:
OH is subscribed to one stateTopic and issues commandTopic to another.
ESP is subscribed to the topic: (OH commandTopic) and sends commands to: (OH stateTopic)
everything works well again, with the exception that OH, when connected to the network and, accordingly, to the broker, makes a site map in accordance with the (OH commandTopic), although according to the correct scheme, the true states of the ESP are recorded in the (OH stateTopic)

Rich looks like I’m trying to do what you say in the second alternative.

Only works if the only way to change the relays is through the MQTT command topic and the messages command messages are always retained

[rlkoshak (Rich Koshak)]

@Kirill-SPB

when connecting to the broker, they read the saved topics and ESP puts up its relays, OH puts up its sitemap. that’s all I want

If the messages sent to the command topic and the state topic are retained then:

1. when the ESP connects to the broker it will receive the command and process it switching the relays as necessary; when the ESP changes it’s relays it publishes a message to the state topic

2. when OH connects to the broker it receives what ever message is on the state topic and updates the Item states as necessary

@Kirill-SPB

ESP is subscribed to the topic: (OH commandTopic) and sends commands to: (OH stateTopic)

The ESP never sends commands. It is the thing that is commanded. The ESP must always publish it’s current state to the state topic.

Commands go from OH to the ESP.
States go from the ESP to OH.

@Kirill-SPB

that OH, when connected to the network and, accordingly, to the broker, makes a site map in accordance with the (OH commandTopic), although according to the correct scheme, the true states of the ESP are recorded in the (OH stateTopic)

OH only receives messages from the state topic. You can look at the code for the MQTT Binding and see that it’s impossible for it to receive a message from the command topic.

If you are receiving messages from the command topic, you’ve something misconfigured.

Note that this approach is only going to work as long as under all circumstances, the ESP publishes the state of it’s relays. That means during boot and that means when ever the relays change for any reason.

Using retained on the command topic is really just a way for the ESP to store it’s current state and restore it when it restarts (i.e. approach 1 above). But that will only work if the only way to change the relays is through a message to this command topic.

Using retained on the state topic, and making sure that the ESP always ensures that the message on the state topic matches the current state of the relay is what ensures that OH’s Item always matches the state of the relay. But OH never reads the command topic.

Broken down like this, a better approach would be as follows:

1. The ESP always ensures that the current state of it’s relays get published to the state topic.
2. The message on the state topic is retained.
3. During startup, the ESP subscribes to the state topic to retrieve only that retained message and sets the relays accordingly. Do this before subscribing to the command topic.
4. OH subscribes to the state topic and because of 1, the Item always reflects the current state of the relay.
5. Messages to the command topic are always sent without retained.

1-3 is how the ESP restores it’s previous state of the relays when it boots. 4 ensures that the OH Item(s) always reflect the current state of the relay.

5 avoids weird timing issues where a command sent 20 minutes ago starts causing stuff to happen, or a message sent to the command topic interferes with the ESP starting up. But as long as you implement 3 as written, it doesn’t really matter if the command messages are send retained.

But notice, we are back to “the ESP should remember it’s own state”. We are just using the state topic to remember it.