MQTT 2.5 Binding and Broker Syntax

[toddwevans (Todd Evans)]

Sorry to start a new Topic on this… I have read or tried to see what others are doing to correct syntax issues when migrating from MQQT 1.x to MQTT 2.5.x. but am still unable to correct a couple of issues.
Somehow I got my temperature sensors to work, even though there is an additional “WARN” in the Openhab Logs:

2020-06-17 10:37:23.602 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '97.2
' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.97.2
==> /var/log/openhab2/events.log <==
2020-06-17 10:37:23.619 [vent.ItemStateChangedEvent] - greenhousetemp changed from 98.5 to 97.2

Man… as I type this, I see that this could be a very long post… so, in a nutshell:
I have a Raspberry Pi with a PiFace board attached (pi40) to control a relay to activate the Garage Door Button.
And, this same Pi reads the values of 3 Temperature sensors an the Garage Door contact status (Opened or Closed). I have python scripts that run every 2 minutes or so to grab the temperatures and every 10 seconds to check the G-Door Contact status. Using Node-Red and mosquitto on this same Pi, it publishes these values. This has worked quite well for a couple of years now.
The Openhabian Pi Runs openhab2, or course and subscribes to the above topics produced by the python code and Node-Red on Pi40. Now this is broken.
Previous syntax was this for the Temperature Sensors in 'home.items’:

Number	 	frontporchtemp	"Front Porch Temperature [%.1f f]" 	<temperature>	{ mqtt="<[openhabianpi:frontporchtemp:state:REGEX((.*?))]" }
Number	 	garagetemp	"Garage Temperature [%.1f f]" 		<temperature>	{ mqtt="<[openhabianpi:garagetemp:state:REGEX((.*?))]" }
Number	 	greenhousetemp	"Greenhouse Temperature [%.1f f]" 	<temperature>	{ mqtt="<[openhabianpi:greenhousetemp:state:REGEX((.*?))]" }

This is the current Syntax for home.items that works but with additional errors:

Number	 		frontporchtemp		"Front Porch Temperature [%.1f f]"		<temperature>		[ "CurrentTemperature" ]	{channel = "mqtt:topic:pi40:frontporchtemp:temperature"}
Number	 		garagetemp		    "Garage Temperature [%.1f f]" 			<temperature>		[ "CurrentTemperature" ]	{channel = "mqtt:topic:pi40:garagetemp:temperature"}
Number	 		greenhousetemp		"Greenhouse Temperature [%.1f f]" 		<temperature>		[ "CurrentTemperature" ]	{channel = "mqtt:topic:pi40:greenhousetemp:temperature"}

I have the pi40 MQTT defined as this:

So, I’m not sure what “WARN” message is referring to.
~~
Now that this part of my question is out of the way, here is the more complex part of my question.
Before MQTT Update, I was able to change the value of the Garage Door Button based upon the OPEN/CLOSED status of the door contact. That was done here in ‘home.sitemap’:

Frame label=“Doors” icon=“door”
{

  Switch item=gdoor1	icon="garagedoor"					mappings=[ON=OPEN]  	visibility=[gdoor3 == CLOSED]
  Switch item=gdoor1	icon="garagedoor"					mappings=[ON=CLOSE] 	visibility=[gdoor3 == OPEN]
  Switch item=gdoor1	icon="garage_detached_selected"		mappings=[ON=NULL] 		visibility=[gdoor3 == NULL]
  Switch item=gdoor3																visibility=[gdoor3 == nothing]
  
  	Group item=extras label="Garage Door Options" labelcolor=["blue"] icon="zoom" {
  	Frame {
  	Switch item=gdoor2	label="G-Door 2ft"			icon="garagedoor"	mappings=[ON=OPEN]	visibility=[gdoor3 == CLOSED]
  	Switch item=gdoor2	label="Garage Door"			icon="garagedoor"	mappings=[ON=CLOSE]	visibility=[gdoor3 == OPEN]
  	Switch item=gdoor4	label="G-Door 3inches"		icon="garagedoor"	mappings=[ON=OPEN]	visibility=[gdoor3 == CLOSED]
  	Switch item=gdoor3																		visibility=[gdoor3 == nothing]

It would show this:

and this when expanded:

None of this is working properly now because it isn’t able to update the status of the contact properly.
The openhabianPi device should be subscribing to the garagedoor status and change OPEN to CLOSE depending on whether the contact is opened or closed. If Open, it will change the button to CLOSE, if door is closed, it will change to OPEN (the door)
I think in the past, the openhab log would show something like gdoor3 CLOSED or gdoor1 OPEN.
Now, the Log shows this:
2020-06-17 11:39:39.835 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command 'OPEN

' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.OPEN

I have tried setting the MQQT THING to Text and Contact but with the same Log error.

I have tried changing this between String and Contact in the '.items’ file… but still no go:

Contact gdoor3 “Garage Door Status” { channel = “mqtt:topic:c5a4c312:readgaragecontactstatus” }

The bottom line, I just want this new MQQT Binding to do simple MQQT Subscribe and Publish, displaying the Topic and its value. One more note, if I run a MQQT Client on my phone or Windows Desktop, I get the format I want… but not in OpenHab2 anymore.
I see that I was using REGEX before, but I don’t see that it works for the new Binding version??

`

Contact gdoor3 “Garage Door” { mqtt=“<[openhabianpi:readgaragecontactstatus:state:REGEX((.*?))]” }

I’m EXTREMELY Sorry this was so long… but maybe it can help others IF someone can assist with the proper Syntax. I can provide any other info if needed.
Thanks,
Todd

[rlkoshak (Rich Koshak)]

@toddwevans

I’m EXTREMELY Sorry this was so long…

I’d much rather have a long post with sufficient information to help than a terse one that leaves out too much necessary information.

I’ve moved the thread to the Add-ons Bindings category though. Tutorials and Solutions is intended for threads that explain how to do something, not to ask for help.

@toddwevans

Command '97.2
' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.97.2
==> /var/log/openhab2/events.log <==

That indicates that you have configured a Channel as a Switch type Channel but the message received is a Number.

Let’s back up a step. The MQTT 2.x binding works as follows:

• You install and configure an MQTT Broker, usually Mosquitto is used. This you already have and it appears to work.
• Next you create an MQTT Broker Thing. The Broker Thing represents the connection to the MQTT Broker. It replaced the sorts of information you used to put into mqtt.cfg with the 1.x version of the binding. This Thing does not represent your device.
• Next you create a Generic MQTT Thing to represent your device, presumably the Pi40. What you are showing in the post above is the Broker Thing, not a Generic MQTT Thing.
• A newly created Generic MQTT Thing does not provide any Channels. So now you need to create MQTT Channels for each sensor or actuator supported by the device. The Channel has a Type (switch, text, color, number, etc.). Once the Type is selected a form is presented where you can enter the subscription topic, command topic, and any additional transformations and details necessary to process the messages before publishing to the command topic (if any) or from the subscription topic.
• Finally you must link the Channel to an Item. The type of the Channel and the Item must match (e.g. a switch type Channel can only be linked to a Switch Item.

It looks like you just created the Broker Thing and have added a bunch of Channels to the Broker Thing. The problem with that is those are trigger Channels. Trigger Channels are intended to represent momentary events (e.g. button pressed) not states (e.g. temperature).

So you need to create a Generic MQTT Thing and add four Channels to it. One for door Contact and three for the temp readings. Though given that these sensors are so far apart, you might consider creating a separate MQTT Thing for each.

@toddwevans

None of this is working properly now because it isn’t able to update the status of the contact properly.

Not surprising. Your visibility stuff doesn’t handle UNDEF as a state type. UNDEF has always been there but it’s only really since about OH 2.4 that bindings have really started to use this state properly.

• NULL: means the Item has never been initialized since the last time OH started up
• UNDEF: means that the binding cannot determine what state the device is in, in MQTT this often occurs if there is an error in the Channel or Thing config or if the connection to the broker has failed.

You need to account for both NULL and UNDEF.

There is not and never was a “nothing” state for a Contact. Those lines basically do nothing and should be removed.

@toddwevans

I have tried setting the MQQT THING to Text and Contact but with the same Log error.

Not seeing how the Channels are defined for your temperature readings, I’m going to guess that the warning is coming from that, not this Channel.

@toddwevans

I have tried changing this between String and Contact in the '.items ’ file… but still no go:

The Item is a Contact type so you need to choose “Open/Close Contact” as the Channel type. Given it worked before without any real transformation, you don’t need to enter anything for incoming transformation.

Your Channel config should look something like

You’ve not actually shown the MQTT topic for the garage door so just make sure to use the correct topic for the subscription. Presumably the messages sent are OPEN or CLOSED so nothing else is required. Then link that Channel to a Contact Item. Given the above the Channel ID would be mqtt:topic:test:garagedoor.

@toddwevans

I see that I was using REGEX before, but I don’t see that it works for the new Binding version??

The 1.x binding required it but that transformation really wasn’t doing anything. So you don’t need it at all in the 2.x binding. But if you ever do need to apply a transformation, click on “Show More” for the Channel config and you will see

The outgoing format field lets you apply the sorts of formatting that you can use for labels. It can be handy when, for example, you need to convert an OPEN to {"door": "garage", "state":"OPEN" } in which case you would enter {"door": "garage", "state": "%s"} in that field.

[rossko57]

@toddwevans

I have the pi40 MQTT defined as this:

To add a little to Rich’s “you need these” list
An MQTT binding Bridge broker Thing is not the same as a System MQTT broker Thing. (That is about managing the embedded Moquette broker, and is not a usable thing for talking with external MQTT devices/services)

If you are migrating v1 to v2 you already have an MQTT broker, yes? You don’t need System broker or embedded broker or any of that, you just need MQTT binding (v2) and then to configure a Bridge thing pointing to your existing broker.

[toddwevans (Todd Evans)]

Thank you, Gentlemen.
I actually did(do) have the MQTT Broker thing setup and the Generic Broker Thing(s) setup… I didn’t show this because I was getting a little nervous about how long my post was…

But, I think I will delete all my Generic Broker Things then go through your instructions one by one and see if there was a boo boo (lol) that I made along the way, previously.
I’ll Holler one way or another.
Thanks again!
Todd

[toddwevans (Todd Evans)]

OK Guys…
I’m making Progress:
Thus far:

Under Sensor Readings, I now ONLY see what I want to see… that’s good!

2020-06-17 15:48:25.222 [vent.ItemStateChangedEvent] - garagetemp changed from 82.6 to 82.5

2020-06-17 15:48:43.583 [vent.ItemStateChangedEvent] - greenhousetemp changed from 104.6 to 104.8

2020-06-17 15:49:10.312 [vent.ItemStateChangedEvent] - frontporchtemp changed from 95.3 to 95.6

I also noticed that I did NOT need Channel Values in the home.items file (Commented out{I think})… thought that was weird, but YAY!

> //////////////////////////////////Temperatures
> Number	 	frontporchtemp	"Front Porch Temperature [%.1f f]"		<temperature>		[ "CurrentTemperature" ]	//{channel = "mqtt:topic:pi40sensors:frontporchtemp:temperature"}
> Number	 	garagetemp		"Garage Temperature [%.1f f]" 			<temperature>		[ "CurrentTemperature" ]	//{channel = "mqtt:topic:pi40sensors:garagetemp:temperature"}
> Number	 	greenhousetemp	"Greenhouse Temperature [%.1f f]" 		<temperature>		[ "CurrentTemperature" ]	//{channel = "mqtt:topic:pi40sensors:greenhousetemp:temperature"}

Moving on to the Garage Items… I was able to get the buttons to work for each script that runs on pi40 by adding each Channel as a Switch and as a command and linked each to the items file, also removiing the Channel = mqqt link.

AND

But, Finally… I still cannot get the Garage Sensor to report properly.
And really, this is just sending out a MQTT Topic of ‘readgaragecontactstatus’ with the payload of either Open or Closed. Does this need to be set as a contact?
ANYWAY… thanks for the guidance up to this point… I feel like I’m ALMOST THERE!!
More suggestions for this last thingamajig are appreciated!
Todd

[rlkoshak (Rich Koshak)]

@toddwevans

I also noticed that I did NOT need Channel Values in the home.items file (Commented out{I think})… thought that was weird, but YAY!

Unless you have linked the Items to the Channels from within PaperUI, you absolutely do need the channels in your .items file. Did you link them through PaperUI? If you look at the Channel does it show a blue circle with a white dot? When you click on the arrow icons to the right does it show the Channel linked to the right Item?

An unlinked Channel will look like

@toddwevans

with the payload of either Open or Closed.

“Open” and “Closed” or “OPEN” and “CLOSED”? It needs to be the latter. If it’s not all caps, you can put the not all upper case versions in the Channel Config so those are recognized as OPEN and CLOSED.

Also, use an MQTT client to verify that the topic is being published to.

@toddwevans

Does this need to be set as a contact?

Absolutely.

[toddwevans (Todd Evans)]

Ahhh… that’s what I didn’t count on… I was used to doing have the stuff in code and half in the PaperUI.
So with this new MQTT I’ve been setting it up in the UI. So yes, they are linked in the PaperUI.
So… I’ll keep playing around with the readstatus as a Contact and go from there.
Thanks a bunch, rlkoshak.
For the most part I feel this is resolved.
To whom shall I mark this as the Solver as a couple of you fellers contributed?