Sorry to bring up the dreaded MQTT topic again… but I figure 4 days is long enough to struggle with this
I have tried MANY of the solutions that others have been successful with but without resolution
"pi01" is running Node-Red grabbing a python script (3 actually) to get the temperatures from 3 DS18B20 sensors and publishing 3 different topics.
This appears to be working as expected because if I subscribe to any of the 3 topics on any other network device mqtt client... I see the outputs:
/greenhousetemp 72.2
/frontporchtemp 78.0
/garagetemp 83.8
A new pi3 “openhabianpi” is running OH2… the build from maybe a week ago.
I added the following add-ons:
MQTT Binding - binding-mqtt1 - 1.12.0
and
MQTT Action - action-mqtt - 1.12.0
and
I installed the Mosquitto broker on this device.
The section in the home.sitemap shows properly on the phone app as well as from the basic and/or classic WEB.
Text item=frontporchtemp icon=“temperature” label=“Front Porch Temperature”
Text item=garagetemp icon=“temperature” label=“Garage Temperature”
Text item=greenhousetemp icon=“temperature” label=“Greenhouse Temperature”
(Side Note: If I publish any 3 of these topics with another client and type in a number, it populates these fields as I would expect openhabianpi to do)
The section in the home.items
Number frontporchtemp "Front Porch Temperature [%.1f f]" <temperature> { mqtt=">[openhabianpi:/frontporchtemp:command:*:0]" }
Number garagetemp "Garage Temperature [%.1f f]" <temperature> { mqtt=">[openhabianpi:/garagetemp:command:*:0]" }
Number greenhousetemp "Greenhouse Temperature [%.1f f]" <temperature> { mqtt=">[openhabianpi:/greenhousetemp:command:*:0]" }
Note: currently I have just the Output shown, but I have also tested with both in and out like this:
EX: { mqtt="<[openhabianpi:/frontporchtemp:state:default],>[openhabianpi:/frontporchtemp:command:default:0]" }
Finally, if I run this command from the openhabianpi’s console… I return the expected topics with the temperature values into the console screen:
mosquitto_sub -v -h openhabianpi -t “#”
Question… what am I missing? Is this something related to the persistence or rules file(s)?
This REALLY seems like it should be working
Thanks
Todd
Number frontporchtemp [...] { mqtt=">[openhabianpi:/frontporchtemp:command:*:0]" }
> indicates it is an output command.
But I think you want to receive the temp value from mqtt to into the Item.
So you need <.
And the command should look a little different.
I think you need this:
Number frontporchtemp [...] { mqtt="<[openhabianpi:/frontporchtemp:state:default]" }
I wish to suggest you consider restructuring the format of the MQTT topic. For example, the leading slash is not required. In fact, it creates another level in the topic’s hierarchy.
This offers the advantage of being able to subscribe to multiple topics with one subscription. For example, this subscribes to all three temperature topics.
home/*/temp
This subscribes to all topics related to the front porch (assuming you’ll possibly have more than just temperature in the future).
/home/frontporch/*
Although this restructuring might not seem like a huge advantage for your current application with OpenHAB, it may help you in the future should you wish to connect other devices that subscribe to the same topics.
What are you using the MQTT action binding for? This may have been fixed but in the past there were issues using both bindings. If not needed remove the action binding or remove it to test if it may be the cause of issue.
What device are the sensors connected to thats sending the MQTT message? Esp8266, Sonoff, etc…
Here is a Sonoff with tasmota firmware temp example I use.
I will just add my grain of salt here and say that if you don’t use the mqtt persistence service then remove the retain option and set it as false.
By setting retain to false, a client that connects to the MQTT broker will not receive the current value of a subscribed topic. In other words, the client will report the topic’s value is NULL until there’s a change in the topic’s value.
By setting retain to true, a client that connects to the MQTT broker will receive the current value of a subscribed topics. In other words, the client will report the topic’s value immediately upon connection to the MQTT broker.
If you are certain the connection between the client and broker will always be intact (perhaps both are on the same computer) then retain=false is a viable option (however, it doesn’t make anything noticeably faster and the saved overhead is negligible).
If there is a possibility of interrupting the connection between client and broker, then retain=true is the better option. It avoids the situation with retain=false where the connection is dropped, the topic’s value changes in the interim, then the client reconnects and now reports NULL (or the old value).
There’s also a way to ensure the client gets the current topic values upon re-connection by using the same session ID. The retain flag is a simpler concept to employ.
Thanks, I’ll try some of the suggestions above.
I have had the retain=false before to no avail…
As stated in my original post, these are DS18B20 sensors.
The reason I wanted to use 3 subscriptions was for easier troubleshooting in the event that one of them failed for some reason.
I thought the MQTT Action was required, but I’ll remove it IF it really is not needed and can cause problems.
I have tried both input AND output in the items file thinking that it first needed to receive the subscription… THEN publish it to the event bus…wrong way to think of it, maybe?
I have tried it like this:
{ mqtt="<[openhabianpi:/frontporchtemp:state:default],>[openhabianpi:/frontporchtemp:command:default:0]" }
I like the idea of using this format for the topic:
home/greenhouse/temp
home/frontporch/temp
home/garage/temp
And I’ll give REGx a try, too…
Please stand by Must have some coffee first haha
AND THE WINNER IS - Jean-Claude The REGx addition.
I did remove the MQTT ACTION - didn’t change
I tried the home/garage/tmp format… and tho I like that, it didn’t fix the problem… but thanks for that tip
So, for anyone else having this issue, this is what ultimately worked:
Number garagetemp “Garage Temperature [%.1f f]” { mqtt="<[openhabianpi:garagetemp:state:REGEX((.*?))]" }
Many thanks to those that replied!!
Now I get to figure out how to use this to “press the garage door button”
I have a python script that works nicely bringing the relay attached to a GPIO pin to a high state… sleeps for .8 seconds then high again… simulating a 1 second press of the button.
if I publish the topic “pressgaragebutton” it will open and close the garage door.
I’ll have to research what the REGx command is actually doing… maybe that’s what I need for this as well.
Thanks again… you guys ROCK!!
You should be able to use the word “default” in place of the regex which will not apply any transform and is the full string to the item.
Not in every case. Let’s say I have a garage opener that tries on receipt of an mqtt message. If I use retain then the door will open every time the mqtt client reconnects to the broker. You must understand what you want to achieve and the side effects of the Carol’s settings to choose what is appropriate.
Consider another case, let’s say you have thermometer and that reports periodically. Now let’s assume the thermometer broke and isn’t reporting any more. I’d it correct the way you will your rule to keep the stale reading or would a NULL be more appropriate to indicate there to a problem and maybe do something else.
There are lots and lots of similar cases where you absolutely do not want to use retain.
Just want to add one thing, the transformation in the item may or may not be required. Look at the two examples I posted above. The Sonoff used JSON but the ESP8266 didn’t. I suppose its because of different firmware on each device. You can find how to use the proper mqtt format of whatever firmware usually on github.
Rich,
I think I would like to see a null value come across indicating an “issue” with either communication or the sensor… but I guess I’d know something was up if the front porch temperature was 105 f at 12am! (Global warming?) :)
I did try using :default: originally. I usually start off with the simplest, easiest, default settings until something isn’t working… then go up from there. If it wasn’t for this forum, I most likely would have gone out and spent EVEN more $$ on Z-Wave stuff (Thermometers) which I really don’t want to do since I have these sensors already in place that I was using with Domoticz.
And most definitely, for the garage door, I don’t want to retain anything after the command is sent.
I’m hoping that having a button that initiates the publish topic of “pressgaragebutton”, I shouldn’t see the door opening at any inconvenient time (Like if I’m in the garage wearing only my undies) haha
H102:
Great… thanks for the tip!!
I didn’t realize (or even think about) that each device had some associated coding. I’ll start thinking along those lines in the future. All this OpenHAB stuff is new to me and a bunch of new learning will be in my future, no doubt!
I’m new myself. Here is the number one tip I can give. Before you get to deep in setting everything up and writing rules MAKE A BACKUP…TEST that the BACKUP WORKS.
This is worth repeating TEST to make sure the BACKUP WORKS!!!
Now, in the future when you get ready to change or test something and it goes to crap, all the time you’ve invested wont be lost. Just restore the backup and keep learning.
Thanks.
I haven’t setup a backup schedule yet…
But, I use WINSCP to copy everything under /etc/openhab2 to a local PC.
When I see something appears to be working as expected, I copy the whole folder over.
I should make multiple folders on the PC based on the date so I can revert back to a certain backup if needed.
Read this about how to back up. How often is up to you, but this makes it easy, zips it up and dates it. You only need to move the file from that location to your PC. This works well on openhabian. I recently moved my openhab from RPI2 to RPI3 so I could run off an SSD and this made it simple.
Example for openhabian on RPI,
This wil create the backup:
openhab-cli backup
When you need to restore the backup:
sudo systemctl stop openhab2.service
openhab-cli restore var/lib/openhab2/backups (put whatever backup you want to use here first)
sudo systemctl start openhab2.service
This will backup /etc/openhab2/ and /var/lib/openhab2/ folders
One more thing to mention, if your having problems moving the backup folder to your PC just change the permissions. I do this, sudo chmod a+rw backups make the transfer then to change back permissions sudo chmod a-rw backups.
Not in every case. Let’s say I have a garage opener that tries on receipt of an mqtt message. If I use retain then the door will open every time the mqtt client reconnects to the broker.
I don’t think the Garage Door example proves your point. In fact, it reinforces the need for using retain=true. Here’s why:
Example with retain=false.
Publisher: GarageDoor=>Open
Broker: Passes the topic’s value on to all subscribers.
Subscriber: GarageDoor opens.
— The connection between subscriber GarageDoor and Broker is lost. —
Publisher: GarageDoor=>Close
Broker: Passes the topic’s value on to all subscribers.
Subscriber: Garage Door remains open because it lost its connection and does not receive the topic’s value.
— Connection between subscriber GarageDoor and Broker is re-established. —
Subscriber: GarageDoor remains open because retain=false and the Broker has nothing cached to report.
Example with retain=true.
Publisher: GarageDoor=>Open
Broker: Stores topic’s value and passes it on to all subscribers.
Subscriber: GarageDoor opens.
— The connection between subscriber GarageDoor and Broker is lost. —
Publisher: GarageDoor=>Close
Broker: Stores topic’s value and passes it on to all subscribers.
Subscriber: Garage Door remains open because it lost its connection and does not receive the topic.
— Connection between subscriber GarageDoor and Broker is re-established. —
Subscriber: GarageDoor closes because retain=true and the Broker reports the cached value (“Close”).
If no new values are published while the Garage Door has lost its connection, then it doesn’t matter if retain is true or false. Upon reconnection, the Garage Door gets the last retained value, which is the state its currently in, or if retain=false then no value at all and remains in its current state. Same difference.
Consider another case, let’s say you have thermometer and that reports periodically. Now let’s assume the thermometer broke and isn’t reporting any more. I’d it correct the way you will your rule to keep the stale reading or would a NULL be more appropriate to indicate there to a problem and maybe do something else.
Ha! Trick question!
If you set retain=false, even when the temperature sensor is connected and functioning properly, a subscriber will get no value upon connection to the Broker until the sensor reports a value. So the initial Temperature upon connection is zilch until the sensor publishes a value. It can produce an undesirable effect in, say, a UI where the Temperature is unknown until the sensor publishes a value. It’s mitigated by having a sensor report frequently (like temperature every few seconds) but not for security sensors that report on events only. Overall, it’s not an effective strategy to use retain=false to serve as some sort of indirect indicator of sensor health. The advantages of retain=true outweigh it.
haha… this is fun…
I’ll respond separately to each person’s responses.
H102,
I’ll get this setup in a bit.
my question is, can I direct the backup to a network share?
I have a Synology 8 disk raided system that I hope will not lose data… so far so good for the past 4 years (crossing fingers)
I can create an SMB or NFS share, etc to allow access from the openhabian.
Taras,
I’ve only somewhat thought the Garage Door scenario through.
But I’m hoping that I can use just a simple button press, maybe labeled “Press” or “Open” ( a mapping thingy?) that will send the initiation of the publishing topic “pushgaragebutton”. This will have the Other Pi act on seeing that topic publicized and initiate the flow I already have setup and working in Node-Red.
I also have a contact sensor currently placed on the garage door which I HOPE to incorporate into this whole garage door fiasco. Maybe when it sees that the sensor is open (0) it will toggle the display on the Sitemap showing it to be “open.” That will in turn place the map state to Open… maybe? That way I can possibly clear the topic and set to Null… again, but… haven’t quite thought about this deeply.
But hopefully, this can be done, that when the contact for the door is Open, the label will show “Close”
Then, at the press of this button, it will initiate the publishing of the topic again.
Even after a glitch or restart, etc… the topic is not being published in any other way so should not, in theory, publish that topic.
Your thoughts?
I’m hoping to start looking at this today… BUT, it’s my Wife’s BD today. I better spend some time with her or else! lol
Thanks again
I’m sure there is a way to use your existing setup as a backup but I’m still learning. Haven’t reached that grade yet…LOL Just don’t put off the backup, even if ya gotta do it manually a few times.
A bit of searching the post and most likely you’ll find exactly what you need to know. Yes you can and I advise using SMB share. Get VSCode software and use the openhab extension to assist in coding. It’s also an easy way, compared to ssh, to access and edit a file.
Oh Yeah… I just learned about Visual Studio Code about a month ago after taking an Azure Automation class.
I’ll see if I installed the SSH plugin or extension for that.
I’ll let you know how that backup pans-out… sometime :)
