[SOLVED] MQTT populating temperature values - no it is not!

[rlkoshak (Rich Koshak)]

@123

A better way

A way to handle this. Not always a better way. Not always even a desirable way.

We can go back and forth on this for many posts. But I already know you will not convinced me. I sent months using retain=true for everything. It caused far more problems then it solved in my use cases.

I’m fully aware of LWT and use it regularly. I’m not talking about detecting a device has failed, though LWT implies that the only failure that occurs is that the device loses connection with the broker.

I have not and will never argue that retain=false shouldn’t be used. But saying it is there only valid option is simply not true.

@123

. It was added to handle precisely the kind of situations I’ve described.

Yes, but your situation isn’t there only use of MQTT. There are tons of use cases and systems models where it makes no sense.

@123

You don’t know which condition is in effect.

But in all of those cases, from OH’s perspective, the state of the Item may properly be undefined (i.e. NULL) until a new value is posted.

Motion sensors, push button actuators, stuff like that.

When the only tool you have is a hammer, all problems look like nails.

@123

If the goal is to have a value that definitely indicates sensor loss, then the Last Will feature serves that purpose.

That isn’t the goal. And as I said, LWT only indicates loss of connection to the broker for a given time. The goal is to let the state of Items remain undefined until a new value is posted. retain=false makes that impossible without a whole lot of extra work.

I’ll close with a few concrete examples from my setup.

1. I chose to model my garage door opener to work just like the physical remote. When the controller received a message it simulates a button press on the door (it’s physically wired to the wall button with a relay). Receipt of the ON message is interpreted as the command to press the button. There is no other message. retain=false would mean the button would be pressed every time there is a reconnection to the broker.

2. I control me house fan based on the temperature readings from 4 different sensors. I do not want to turn the fan on based on any reading more than 10 minutes old. If a sensor hasn’t reported for over ten minutes that Item should be NULL because as far as the algorithm is concerned that is the indicator that the value shouldn’t be used. Oh, and not all of the sensors are MQTT and using retain=false let’s the MQTT sensors behave the same as the Nest and Zwave sensors which also remain NULL until they’re is a new reading. Oh, and if a LWT is receive from over of them then all the Items that get proposed from that device are set to NULL as well.

3. This is one I’ve seen but is not mine. Let’s say I have a mix of zwave and DIY motion sensors. The Zwave ones just report ON when motion is detected, never OFF after a timeout. In order to have the two sets of motion sensors behave the same, retain=false has to be used. Otherwise every time OH connects to the broker it will think the MQTT morning sensors went off.

In all three cases above could I use retain=true? Absolutely. Is it more work? Absolutely. Does retain=true actually provide any value in these use cases? No, it just adds more work.

@123

Anyway, make the UI’s toggle button display a label that is opposite to the door’s current state.

                Switch item=aGarageOpener1 icon="garagedoorclosed" mappings=[ON=Open]  visibility=[vGarageOpener1 == CLOSED]
                Switch item=aGarageOpener1 icon="garagedooropen"   mappings=[ON=Close] visibility=[vGarageOpener1 == OPEN]
                Switch item=aGarageOpener2 icon="garagedoorclosed" mappings=[ON=Open]  visibility=[vGarageOpener2 == CLOSED]
                Switch item=aGarageOpener2 icon="garagedooropen"   mappings=[ON=Close] visibility=[vGarageOpener2 == OPEN]

@123

A timer that starts counting the moment you command the door to close.

Design Pattern: Motion Sensor Timer

Edit: Updates for OH 4 Please see https://community.openhab.org/t/design-pattern-what-is-a-design-pattern-and-how-do-i-use-them/40319 for details on how to use DPs. Problem Statement Many motion detectors only report ON when they detect motion but do not send a corresponding OFF after no motion has been detected after a period of time. In addition, often one wants to control a device like a light for a certain period after the last motion is seen, not after the motion sensor goes to OFF. There…

@123

Now you have to decide what the watchdog should do in this situation

Design Pattern: Separation of Behaviors

Edit: Updated for OH 4. Please https://community.openhab.org/t/design-pattern-what-is-a-design-pattern-and-how-do-i-use-them/40319 for more information on what a DP is and how to use them. Problem Statement Often one will have certain cross cutting code that is used across a many diverse and varied collection of Rules. Such code can include things like calculating time of day to control the behavior of a rule, sending alerts, calculating state to drive a state machine, etc. For example, Lighti…

@123

Basically, it’s nothing more than a timer that, upon expiration, executes some code.

An alternative implementation for Timers using the Expire binding. I can’t remember if the Motion Sensor timer DP includes an example.

Design Pattern: Expire Binding Based Timers

https://community.openhab.org/t/design-pattern-what-is-a-design-pattern-and-how-do-i-use-them/40319 Problem Statement One often needs to schedule some code to execute at some time in the future. The “usual” way to achieve this is by using a Timer which lets you create and schedule a lambda to execute at a given date and time. However, Timers have their drawbacks including: the need to keep track of open Timers so they can be canceled at a later date, often requiring the use of HashMaps or som…

@123

If there was no Last Will feature available, you could probably use a watchdog timer to monitor an MQTT topi

Use the Expire binding to set the Item to NULL or some other value to indicate an error.

There is also the following DP which applies that concept to generically since most technologies OH interfaces with do not support LWT type capabilities.

I need to rewrite this DP so all questions if you use it and have problems. If all you have is MQTT, the logging becomes way easier because of the LWT.

Design Patterns: Generic Is Alive

Edit: Rewritten for OH 4. Please see https://community.openhab.org/t/design-pattern-what-is-a-design-pattern-and-how-do-i-use-them/40319 for a description of what Design Patterns are and how to use them. Problem Statement Many sensors report status to openHAB periodically (e.g. temperature sensor) or unpredictably (e.g. motion sensors) and a subset of these sensors do not have a built in way for openHAB to query whether or not they are alive. The only way for openHAB to detect that these devic…