[SOLVED] Weird action after change to MQTT 2.4 Binding

Add-ons Bindings
, ,
1

I recently try to upgrade MQTT binding from 1.x to 2.4, I installed MQTT binding 2.4 on PaperUI (not web download then put to addon folder), I found item status act wired,

item status received correctly but it change to UNDEF right after, any clue why was that?
P.S. not all items on MQTT 2.4 act like this, only part of the items

2019-12-03 22:47:01.987 [ome.event.ItemCommandEvent] - Item 'A_iphone_Proxy' received command ON
2019-12-03 22:47:01.994 [nt.ItemStatePredictedEvent] - A_iphone_Proxy predicted to become ON
2019-12-03 22:47:02.005 [vent.ItemStateChangedEvent] - A_iphone_Proxy changed from UNDEF to ON
2019-12-03 22:47:02.015 [vent.ItemStateChangedEvent] - A_iphone_Proxy changed from ON to UNDEF
2019-12-03 22:47:02.042 [ome.event.ItemCommandEvent] - Item 'A_iphone_Proxy_LastSeen' received command 2019-12-03T22:47:01.000+0800
2019-12-03 22:47:02.065 [nt.ItemStatePredictedEvent] - A_iphone_Proxy_LastSeen predicted to become 2019-12-03T22:47:01.000+0800
2019-12-03 22:47:02.071 [vent.ItemStateChangedEvent] - Ham_iphone_Proxy_LastSeen changed from UNDEF to 2019-12-03T22:47:01.000+0800
2019-12-03 22:47:02.077 [vent.ItemStateChangedEvent] - Ham_iphone_Proxy_LastSeen changed from 2019-12-03T22:47:01.000+0800 to UNDEF

and this issue somehow may happen on other items as well after reboot, any clue?

thing

Bridge mqtt:broker:OpenHabSer "MQTT Broker OpenHabSer"@ "Other" [ host="xxx.xxx.xxx.xxx", secure=false, certificatepin=false, publickeypin=false, url="xxx.xxx.xxx.xxx:1883"  ]
Thing topic PresenceHam "Presence Check:Ham" @ "Other" {
        Channels:
                Type switch : WifiOnline    "Wifi Connectivity"  [ stateTopic="Presence/Ham_iPhone", transformationPattern="JSONPATH:$.Status" ]
                Type datetime : WifiLastSeen  "Wifi Last Seen"   [ stateTopic="Presence/Ham_iPhone", transformationPattern="JSONPATH:$.Time" ]
                Type switch : BTOnline     "BT Connectivity"     [ stateTopic="Presence/Ham_iPhone_BLE", transformationPattern="JSONPATH:$.Status" ]
                Type datetime : BTLastSeen  "BT Last Seen"       [ stateTopic="Presence/Ham_iPhone_BLE", transformationPattern="JSONPATH:$.Time" ]
    }

items

Switch	    Ham_iphone_Proxy	        "Ham [%s]"					(gHam)              { channel="mqtt:topic:OpenHabSer:PresenceHam:WifiOnline", expire="3m,command=OFF" }
DateTime	Ham_iphone_Proxy_LastSeen	"Ham Last Seen:[%1$tH:%1$tM]"	            { channel="mqtt:topic:OpenHabSer:PresenceHam:WifiLastSeen"}
2

MQTT binding 2.4 insists on setting any channels which have no “retained” message at the broker to UNDEF whin it connects to the broker. Next time a “live” message comes along, it will get an ordinary update.

This behaviour has as I understand it been changed somewhere along the 2.5 road.

3

thanks @rossko57 , I think I might found the reason after some further digging, I realized that 2 items actually was not updated by MQTT but I left MQTT channel for in case, it was updated directly by REST API, and another items was empty was due to it’s not online since OH restart, so this might be a bug, if the item never get update on MQTT when OH started, it will force UNDEF status even it got update by other way, should I report it to Github?

4

I think so too. You are late to the 2.4 party, the discussions about this were extensive, so far as I know the behaviour is changed at some 2.5 version, there is nothing more to be done about 2.4.

https://github.com/openhab/openhab2-addons/issues/5879

5

thanks for the link, I roughly read it, so it looks like this behavior is design to rather than bug, will this behavior keep on 2.5? In this case, move to 2.x MQTT need more consideration.

6

I don’t know how else to say, so far as I know this behaviour changed at some time during 2.5 binding development.

7

then I will suspend the migration from 1.x to 2.x, and wait till 2.5
in fact, I found MQTT 2.x not as stable as 1.x, some my few items on 2.x have stop update just 2 hour after OH restart and I don’t know the reason yet.

8

2.5 M5 I believe.

Version 2.4 of the MQTT binding is approaching a year old and it was, IMHO, rushed to release in the first place. Consequently it had a large number of bugs and problems. Most of the serious problems were fixed within the first two months of it’s initial release (i.e. 2.5 M2) and it has continued to receive updates in the many months since then. Any version of the binding after 2.5 M2 is, in my experience, very stable and feature complete with the 1.x version of the binding. The best version so far is 2.5 M6 but I’ve been running with it exclusively at least since 2.5 M1.

9

HI @rlkoshak, been a long while havn’t chat with u, how’s going?

Thanks for your detail explain, I will test again once OH update to 2.5, mean while as I don’t know where to get beta version of it, I am stay on 1.x and put few items on 2.4 for test purpose.

In fact I think for the binding, if it’s not require the new feature from next version OH, binding should just update to repo and keep with ongoing version with difference revision number for identify, then user like us can simply get an update from OH paper UI / apt update, as you said before, MQTT 2.4 have launch 1 year ago and lot of bug still remain on repo version, that is not user friendly.

10

Just install a Milestone/Testing version of OH instead of the release. Or wait a few weeks.

That is not how OH has ever worked. Everything, the core and all the add-ons advance forward in lock step. The 2.5 M6 version of the binding is only known to work properly on OH 2.5 M6. There are frequently changes made between version numbers that make the binding not backwards compatible. Sometimes you can run an OH 2.5 M6 version on OH 2.4 and sometimes you can’t. It all depends on what changes in the core and whether or not a given binding uses it or not.

Currently it is impossible to just update a single add-on on and guarantee it will work so what you recommend is no possible.

11

understood and thanks for detail explain. I didn’t expect to run home system under beta, I 'll rather with stable release, as your explained, I won’t go for a try on next version beta binding, I’ll wait for 2.5 release,

Thanks again for make me more understand about OH.

12

I just installed 2.5.0~M6-1 (Milestone Build) to test with new version binding, I really don’t feel much difference to 2.4 mqtt binding, I found if I make any changes to thing, even log say thing is Online, it’s not pulling, until restart binding by bundle:restart, and I other un-modify things will poll data, but updated/new things won’t untill system restart. this is exactly same as 2.4

second, I got a little confuse on few thing can’t get poll, I can get Rpi4B get poll, but rest 3 won’t, I can’t figure out why, I am 100% sure the topic name is correct, then rest is exactly same, have tried restart OH2 many times, but only 4B works… don’t know why

Thing topic Rpi4B "Rpi 4B Info" @ "BedR" {
		Channels:
				Type number : CPU1Usage		"CPU1 Usage"	[ stateTopic="Sensor/openhabian4B/status", transformationPattern="JSONPATH:$.CPU1" ]
				Type number : CPU2Usage		"CPU2 Usage"	[ stateTopic="Sensor/openhabian4B/status", transformationPattern="JSONPATH:$.CPU2" ]
				Type number : CPU3Usage		"CPU3 Usage"	[ stateTopic="Sensor/openhabian4B/status", transformationPattern="JSONPATH:$.CPU3" ]
				Type number : CPU4Usage		"CPU4 Usage"	[ stateTopic="Sensor/openhabian4B/status", transformationPattern="JSONPATH:$.CPU4" ]
				Type number : CPUTemp		"CPU Temp"		[ stateTopic="Sensor/openhabian4B/status", transformationPattern="JSONPATH:$.CPUTemp" ]
				Type number : CPUFreq		"CPU Frequency"	[ stateTopic="Sensor/openhabian4B/status", transformationPattern="JSONPATH:$.CPUFreq" ]
				Type number : Eth0Tx		"Ethernet Tx"	[ stateTopic="Sensor/openhabian4B/status", transformationPattern="JSONPATH:$.Tx" ]
				Type number : Eth0Rx		"Ethernet Rx"	[ stateTopic="Sensor/openhabian4B/status", transformationPattern="JSONPATH:$.Rx" ]
				Type datetime : LastSeen	"Last Seen"		[ stateTopic="Sensor/openhabian4B/status", transformationPattern="JSONPATH:$.Time" ]
	}

	Thing topic RpiServer "Rpi Server Info" @ "CompuR" {
		Channels:
				Type number : CPU1Usage		"CPU1 Usage"	[ stateTopic="Sensor/OpenhabianPi-Server/status", transformationPattern="JSONPATH:$.CPU1" ]
				Type number : CPU2Usage		"CPU2 Usage"	[ stateTopic="Sensor/OpenhabianPi-Server/status", transformationPattern="JSONPATH:$.CPU2" ]
				Type number : CPU3Usage		"CPU3 Usage"	[ stateTopic="Sensor/OpenhabianPi-Server/status", transformationPattern="JSONPATH:$.CPU3" ]
				Type number : CPU4Usage		"CPU4 Usage"	[ stateTopic="Sensor/OpenhabianPi-Server/status", transformationPattern="JSONPATH:$.CPU4" ]
				Type number : CPUTemp		"CPU Temp"		[ stateTopic="Sensor/OpenhabianPi-Server/status", transformationPattern="JSONPATH:$.CPUTemp" ]
				Type number : CPUFreq		"CPU Frequency"	[ stateTopic="Sensor/OpenhabianPi-Server/status", transformationPattern="JSONPATH:$.CPUFreq" ]
				Type number : Eth0Tx		"Ethernet Tx"	[ stateTopic="Sensor/OpenhabianPi-Server/status", transformationPattern="JSONPATH:$.Tx" ]
				Type number : Eth0Rx		"Ethernet Rx"	[ stateTopic="Sensor/OpenhabianPi-Server/status", transformationPattern="JSONPATH:$.Rx" ]
				Type datetime : LastSeen	"Last Seen"		[ stateTopic="Sensor/OpenhabianPi-Server/status", transformationPattern="JSONPATH:$.Time" ]
	}

	Thing topic Rpi3BPlus "Rpi 3B+ Info" @ "LivR" {
		Channels:
				Type number : CPU1Usage		"CPU1 Usage"	[ stateTopic="Sensor/openhabian3BPlus/status", transformationPattern="JSONPATH:$.CPU1" ]
				Type number : CPU2Usage		"CPU2 Usage"	[ stateTopic="Sensor/openhabian3BPlus/status", transformationPattern="JSONPATH:$.CPU2" ]
				Type number : CPU3Usage		"CPU3 Usage"	[ stateTopic="Sensor/openhabian3BPlus/status", transformationPattern="JSONPATH:$.CPU3" ]
				Type number : CPU4Usage		"CPU4 Usage"	[ stateTopic="Sensor/openhabian3BPlus/status", transformationPattern="JSONPATH:$.CPU4" ]
				Type number : CPUTemp		"CPU Temp"		[ stateTopic="Sensor/openhabian3BPlus/status", transformationPattern="JSONPATH:$.CPUTemp" ]
				Type number : CPUFreq		"CPU Frequency"	[ stateTopic="Sensor/openhabian3BPlus/status", transformationPattern="JSONPATH:$.CPUFreq" ]
				Type number : Eth0Tx		"Ethernet Tx"	[ stateTopic="Sensor/openhabian3BPlus/status", transformationPattern="JSONPATH:$.Tx" ]
				Type number : Eth0Rx		"Ethernet Rx"	[ stateTopic="Sensor/openhabian3BPlus/status", transformationPattern="JSONPATH:$.Rx" ]
				Type datetime : LastSeen	"Last Seen"		[ stateTopic="Sensor/openhabian3BPlus/status", transformationPattern="JSONPATH:$.Time" ]
	}

	Thing topic Rpi3B "Rpi 3B Info" @ "GuestR" {
		Channels:
				Type number : CPU1Usage		"CPU1 Usage"	[ stateTopic="Sensor/OpenhabianPi3B/status", transformationPattern="JSONPATH:$.CPU1" ]
				Type number : CPU2Usage		"CPU2 Usage"	[ stateTopic="Sensor/OpenhabianPi3B/status", transformationPattern="JSONPATH:$.CPU2" ]
				Type number : CPU3Usage		"CPU3 Usage"	[ stateTopic="Sensor/OpenhabianPi3B/status", transformationPattern="JSONPATH:$.CPU3" ]
				Type number : CPU4Usage		"CPU4 Usage"	[ stateTopic="Sensor/OpenhabianPi3B/status", transformationPattern="JSONPATH:$.CPU4" ]
				Type number : CPUTemp		"CPU Temp"		[ stateTopic="Sensor/OpenhabianPi3B/status", transformationPattern="JSONPATH:$.CPUTemp" ]
				Type number : CPUFreq		"CPU Frequency"	[ stateTopic="Sensor/OpenhabianPi3B/status", transformationPattern="JSONPATH:$.CPUFreq" ]
				Type number : Eth0Tx		"Ethernet Tx"	[ stateTopic="Sensor/OpenhabianPi3B/status", transformationPattern="JSONPATH:$.Tx" ]
				Type number : Eth0Rx		"Ethernet Rx"	[ stateTopic="Sensor/OpenhabianPi3B/status", transformationPattern="JSONPATH:$.Rx" ]
				Type datetime : LastSeen	"Last Seen"		[ stateTopic="Sensor/OpenhabianPi3B/status", transformationPattern="JSONPATH:$.Time" ]
	}

Topic as below, it all shows update with MQTT1.x, below topics update every minute(60s), and I use MQTT.fx to real time monitor updates below topics to isolate the problem source

Sensor/OpenhabianPi-Server/status   >> not seeing on 2.5M6
Sensor/openhabian3BPlus/status   >> not seeing on 2.5M6
Sensor/OpenhabianPi3B/status   >> not seeing on 2.5M6
Sensor/openhabian4B/status     >> this work on 2.5M6

content as

{"CPU1":4.08,"CPU2":6.06,"CPU3":6.06,"CPU4":4.95,"CPUTemp":52.1,"CPUFreq":600,"Tx":1.00,"Rx":0.00,"Time":2019-12-09T05:38:02}

Off-topic question, please kindly advise what is the proper way to poll thing status on 2.5?
I used below when 2.2-2.4

var CompuRCeilingLstatus = getThingStatusInfo("miio:basic:0abcdef").getStatus()

after wake up, I find out why not getting update, I made mistake on the items channel link,
after correction, everything work as expect, sorry for wasting everyone’s time here.

13

MQTT is not a polling communication technology.

Target devices might be set up to respond to some command message with a status message; that’s up to the device.

1 Like
14

As rossko57 said, MQTT doesn’t poll nor does it pull. Clients push, or publish messages. And other client that is subscribed to that topic where the message is published to will receive the message. Simple as that.

If you use the retained flag when publishing, even if there is no client subscribed to the topic at the time when the message was published, that client will receive the message when it does connect later on.

So it is not at all clear what you are really talking about here.

The first thing to check is that what ever is supposed to be publishing to those topics that appear not to work are in fact publishing, and that the topics are correct. One usually does this with a third party tool like MQTT Explorer.

That topic appears nowhere in your posted Things.

You can trigger a Rule when a Thing changes status (see the Rules Docs), but it’s important to understand what the status of an MQTT Thing actually means. All it means is that there is a connection to the broker that is alive and working. It has nothing to do with the online status of the remote device. So the only time that the RPiServer will ever go offline is if the Bridge it is using goes offline, which probably means that ALL of your MQTT Things will go to OFFLINE and all your Item’s states set to UNDEF (I don’t think this behavior has changed).

It really seems like you could use a good refresher on MQTT and how it works. It will greatly help your debugging efforts.

15

MQTT doesn’t poll nor does it pull. Clients push, or publish messages. And other client that is subscribed to that topic where the message is published to will receive the message.

Sorry to my bad English, I just try to describe MQTT action as pull or poll as I don’t know how should I describe the action of reading MSG from MQTT channel in English, so as rich said I think It’s call subscribe. Please let me know if I still make it wrong, I am always mistaking the word of some action in English as it’s very similar to me.

I use MQTT since I start using OH 2.0, I think MQTT working way is very similar to telegram, each IOT/client use one(or more for difference sensor) of the channel, and server (OH) subscribe the specific channel to react with specific msg,

Topic as

Sorry that I made mistake again, I was very sleepy while writing that post, it’s right before I went bed,
I will edit again on the previous post regarding topic name,

Off-topic question, please kindly advise what is the proper way to poll thing status on 2.5?

as I said it’s really off-topic question, this rules is not regarding MQTT thing, it’s regarding other binding, as that light sometimes will physically power off by my wife, so before run the rules, I would like to know the thing status, this works before 2.5, and I am very slow/bad on reading doc, it always takes me very long time to look for a specific contents, so I just try to post it here and wish someone would give a hand if someone know it.

sorry for all the misunderstanding cause by my bad English and description

Final, I see MQTT binding on 2.5M6 keep the design way as 2.4 which it will make item status read-only mode if item never get updated from MQTT since binding start to work, as not much time for further test, I will do a bit more test on it.

after wake up, I find out why not getting update, I made mistake on the items channel link,
after correction, everything work as expect, sorry for wasting everyone’s time here.