I migrated all of my mqtt v1 Items to the new mqtt V2.4 Binding. I created the things changed and linked the items. So far everything is working.
I have installed the mapdb Binding for persisting the MQTT Items states.
Now I have the following problem:
When I restart the Openhab2 System, all of the item states are restored via mapdb binding.
But the mqtt v2.4 is starting after the mapdb binding. After the mqtt v2.4 Binding is started, all MQTT Item states are set to “UNDEF”.
As not every MQTT Device is sending his state frequently I have a lot of Items in “UNDEF” state, which causes errors in rules.
Is it possible to change the start order of the bindings, so that the mapdb binding is starting after the mqtt v2.4 binding?
OR
Is there a other resolution for my problem?
Here’s my “starting order”:
254 │ Active │ 80 │ 2.4.0 │ openHAB REST Documentation
255 │ Active │ 80 │ 1.13.0 │ openHAB MapDB Persistence Bundle
256 │ Active │ 80 │ 1.13.0 │ openHAB RRD4j Persistence Bundle
257 │ Resolved │ 75 │ 2.4.0 │ openHAB Basic UI Fragment, Hosts: 234
258 │ Resolved │ 75 │ 2.4.0 │ openHAB Classic UI Fragment, Hosts: 235
259 │ Active │ 80 │ 2.4.0 │ HABmin User Interface
260 │ Active │ 80 │ 2.4.0 │ HABPanel User Interface
261 │ Resolved │ 75 │ 2.4.0 │ openHAB Paper UI Theme Fragment, Hosts: 236
262 │ Active │ 80 │ 0.9.10.v20160429-1435 │ reflections (wrap)
263 │ Active │ 80 │ 3.1.4 │ Stax2 API
264 │ Active │ 80 │ 1.5.8.v20160511-1038 │ swagger-jersey2-jaxrs (wrap)
278 │ Active │ 80 │ 2.4.0 │ Amazon Echo Control Binding
279 │ Active │ 80 │ 2.4.0 │ GPSTracker Binding
280 │ Active │ 80 │ 1.13.0 │ openHAB PanasonicTV Binding
281 │ Active │ 80 │ 1.2.0 │ Paho MQTT Client
282 │ Active │ 80 │ 0.10.0.oh240 │ Eclipse SmartHome Automation API
283 │ Active │ 80 │ 0.10.0.oh240 │ Eclipse SmartHome MQTT Binding
284 │ Active │ 80 │ 0.10.0.oh240 │ Eclipse SmartHome MQTT Thing Binding
285 │ Active │ 80 │ 0.10.0.oh240 │ Eclipse SmartHome MQTT Transport Bundle
Would it help to reinstall the MAPDB Binding so that it is started after MQTT Binding?
I’ve seen this mentioned elsewhere. First I’d suggest upgrading to get the latest 2.5 snapshot binding as David has added a lot of features and fixes in just the past two weeks. If the problem persists I can think of three solutions:
The first is to modify the senders to set the retained flag on the messages it sends to those topics. When the MQTT binding comes up it will subscribe to the topic and receive whatever was the last message published.
The second is to create a System started Rule configured to wait enough time for the MQTT binding to come up. Then filter through all the MQTT Items you care about for all the ones that are UNDEF and postUpate the previousState.
The third is to adjust your Rules et al to deal with the UNDEF.
From a strict MQTT best practices perspective, if the value posted to an MQTT topic needs to persist for longer than the instant it is published, it should be retained. If there is no retained message on a topic, there is a strong argument that the correct state for the Item should be UNDEF as OH really doesn’t know what state the device is in. So from this perspective the MQTT binding is behaving correctly.
However, retained messages can be a real pain to deal with and as you are seeing, it messes up the restoreOnStartup behavior within OH. I don’t know whether there have been any changes in this regard.
Unfortunately not. I’m exactly in this dilemma of wanting to set channels to a well-defined state, which is UNDEF if nothing has been received yet and at the same time I also like to support a restore on startup feature.
I found no solution so far. The framework would need to solve that actually, by allowing bindings to set initial states and later on overwrite them with stored ones.
thanks for your help
I tried reinstalling persistence binding. It is now started after the mqtt v2 binding. unfourtnately it doesn’t solved my problem at 100% as the persistence binding is starting to slowly.
What I’ve done to solve my issue:
created a second channel on the mqtt thing where the powerstate of my tasmota devices is send in a frequently teleperiod.
changed my rules to deal with “UNDEF” values.
@David_Graff Only a tip from side, maybe it’s helpful. Maybe you should check on startup of the binding, if a persistence binding is installed in the system, if so you should prepend startup until the persistence binding is started. Another question: What must I do to upgrade to the development version (2.5) of your binding?
I’ve had a go at this.
I’ve put the relevant items in their own group, persisted in mapdb. group name MQQTv2
Despite trying different rule, I did achieve the required effect.
Could you give an example, please? (Oh, I really hate asking for this…)
Thanks
Note, I’m not actually using this so can’t promise there are not side effects I’m not aware of. And of course the side effects may heavily depend on how your Rules are written. They will definitely need to be adjusted to handle UNDEF states as we can’t completely avoid them.
Assumption:
All the MQTT2 Items you need to be restored are in the gorup MQTTv2
All the members of MQTTv2 are persisted with at least an everyChange strategy
rule "Update MQTT2 Items"
when
System started
then
createTimer(now.plusSeconds(60), [ | // you may need to experiment to find the optimum wait time
MQTTv2.members.filter[ i | i.state == UNDEF ].forEach[ i | i.postUpdate(i.previousState.state) ] // I can't remember if previousState returns a HistoricState or just the State, I'm assuming HistoricState
])
end
As I said, I’m not really using this. Let me know if it works or not. I do have something similar to reset Expire binding timers on restart since restoreOnStartup doesn’t trigger the binding and it does work.
I never really relied on restoreOnStartup for most of my MQTT Items. I implemented a polling topic where when OH publishes a message to that topic all my self coded stuff will publish their current states. The Sonoffs and Tasmotas (and soon Shellys) I haven’t transitioned to MQTT 2 yet so I’m not sure how I’m going to deal with those.
Ultimately, having seen how the Homie standard and how the ESP Easy uses retained messages, I’m not quite so against their use any more. I am considering using retained messages a bit more for certain things like sensor readings and especially for LWT topics.
I wish the MQTT standard had a “retain for X minutes”. That would be perfect, though I’m sure it would greatly complicate the spec.
Maybe you should check on startup of the binding, if a persistence binding is installed in the system, if so you should prepend startup until the persistence binding is started. Another question: What must I do to upgrade to the development version (2.5) of your binding?