[CLOSED] MQTT binding version 2.4 (Pre-release !)

bern77 · December 23, 2018, 7:21pm

Well, the stress level was just a wild guess. And disabling the workaround rule for the Event Bus behaviour should have reduced the load anyway.
The mqtt1 Binding is using the default setting for the async parameter (which is true). So I’m afraid that won’t help much

I’ve just played around to maybe identify a the reason but so far without success… it seems to be mainly tied to the Action (i.e. usage in rules) though.

milhouse · December 23, 2018, 9:07pm

Thanks a lot! That finally was the deciding clue that helped me after hours and hours of trying…

David_Graeff · December 23, 2018, 11:33pm

The mqtt2 action is a new rule engine action. Support for those kinds of actions within scripts and DSL rules was also just released before OH 2.4. The culprit could as well be in the framework. @Kai how robust (and efficient?) is the getActions API for DSL rules (parallel threads maybe even?) if we are talking about say 10 calls per second?

renes · December 24, 2018, 1:19am

I have a mqtt.things file:

Bridge mqtt:broker:homebroker3 [ host="192.168.1.2",secure=false, username="username", password="password" ]
{
    Thing mqtt:topic:mything {
    Channels:
        Type switch : myswitch "My Switch" [ stateTopic="openHAB/switch/set", command=true ]
    }
}

Im trying the above to trigger a command when a value comes in on the specified topic. When using the UI to configure the corresponding channel there is an attribute called “Is command” with the explanation: “If the received MQTT value should not only update the state of linked items, but command them, enable this option.” This is exactly what I need, but I don’t know how to set it in my mqtt.things file, eg. the above command=true on the channel doesn’t have any effect.

Does anyone know the right attribute to set on the channel?

Nicholas_Waterton · December 24, 2018, 4:12am

HABapp?

Write rules in plain python! No! Rules must be written in an obscure non standard not language with little documentation and difficult debugging support.

If rules were easy, then anyone could do it, and what would all the people answering the “why does my rule not work” questions do then?

Heresy I say!

David_Graeff · December 24, 2018, 5:18am

Why do you thing that the configuration name is “command”? It is documented otherwise

bern77 · December 24, 2018, 8:52am

I also can report that if using MQTT Actions, running mqtt1 and mqtt in parallel doesn’t work (lost broker connections).

renes · December 24, 2018, 8:57am

@David_Graeff I couldnt find it in the documentation on OpenHab website. Can you give me a reference to where you found it?

renes · December 24, 2018, 9:18am

Ahh never mind @David_Graeff I see @bern77 provided the info few posts before it’s postCommand.

bern77 · December 24, 2018, 11:21am

I’ll give it a shot with a workaround.
There’s a simple node.js based HTTP to MQTT bridge (https://github.com/petkov/http_to_mqtt). I’ll replace the MQTT Action calls with HTTP POSTs to the bridge’s URL. Let’s see if this might improve things.

vzorglub · December 24, 2018, 11:51am

There is an MQTTv2 action:

Use it like this:

  val actions = getActions("mqtt","mqtt:broker:myUnsecureBroker")
  actions.publishMQTT("topic", "payload")

bern77 · December 24, 2018, 11:54am

I did, but have faced some issues (see posts above)… this should be a workaround for the time being.

911rgt · December 25, 2018, 1:23pm

After upgrading 2.4 and switching to MQTT 2 I’m facing similar issues as bern77. I used mqtt event-bus before and recreated it with the following rule:

rule “Publish item changes”
when
Member of gTemperature changed
then
var state = “”
if (triggeringItem.state != null) {
state = triggeringItem.state.toString
val actions = getActions(“mqtt”,“mqtt:broker:myBroker”)
actions.publishMQTT("/myserver/"+triggeringItem.name+"/state",state)
logInfo(“log”, "publish: " + triggeringItem.name + " " + state)
}
end

while the rule works as intended it won’t last 24 hours before I the get same error as bern77. After restarting OpenHAB it works again as it should. There are only 20 messages max per minute so the load is minimal.

Curious to see if others had more success with the new Mqtt binding action.

David_Graeff · December 25, 2018, 6:19pm

Could you please open a bug report on Github? So far Kai, who wrote the code, does not yet know that it is failing after a while.

Cheers,
David

Tyrell77 · December 25, 2018, 8:12pm

Hello,
i have the following problem after migrating to mqtt Binding v2:
The State of a Switch (ON/OFF) is shown in the Sitemap, even though i didn’t specify it.
Here is my .thing:

Thing topic sonoff2 "MQTT Sonoff 2" {
Channels:
Type number : mqttSonoff2RSSI "Empfangsstärke" [ stateTopic="tele/sonoff2/STATE", transformationPattern="JSONPATH:$.Wifi.RSSI" ] 
Type string : mqttSonoff2Time "Time" [ stateTopic="tele/sonoff2/STATE", transformationPattern="JSONPATH:$.Time" ] 
Type switch : mqttSonoff2LWT "LWT"[ stateTopic="tele/sonoff2/LWT", on="Online", off="Offline" ] 
Type switch : mqttSonoff2Switch1 "Media" [ stateTopic="tele/sonoff2/STATE", transformationPattern="JSONPATH:$.POWER1", 
                                               commandTopic="cmnd/sonoff2/POWER1", on="ON", off="OFF" ]
Type switch : mqttSonoff2Switch2 "XBox" [ stateTopic="tele/sonoff2/STATE", transformationPattern="JSONPATH:$.POWER2", 
                                              commandTopic="cmnd/sonoff2/POWER2", on="ON", off="OFF" ]
}

My .item:

Switch Sonoff2switch1 "Media" (G_Sonoff2) 
{ channel="mqtt:topic:mosqitto:sonoff2:mqttSonoff2Switch1" }
Switch Sonoff2switch2 "Xbox" (G_Sonoff2) 
{ channel="mqtt:topic:mosqitto:sonoff2:mqttSonoff2Switch2" }

My .sitemap:

Switch item=Sonoff2switch1
Switch item=Sonoff2switch2

How to suppress the ON/OFF State in the Label ?

Regards, René

opus · December 25, 2018, 8:30pm

I’m not sure if that solution works ( I’m on the road, can’t test)., but it’s worth a try.

miwok · December 25, 2018, 8:34pm

yes, it works!

However, I do not understand the cause of the problem. with version MQTT v1 I did not have this problem …

opus · December 25, 2018, 8:40pm

As said on the other thread, that migth be a new feature instead of a problem.

miwok · December 25, 2018, 8:57pm

I’m sorry, I still do not understand it:
I have both versions (v1 and v2) of the MQTT binding installed in parallel (although not recommended):
and the item of MQTT v1 works the way I want, item from MQTT v2 returns a different result for the same sitemap syntax?

MQTT v1 item:

Switch                  sonoff3_Reachable       "sonoff3 TH16"                  <switch>                                { mqtt="<[broker:tele/sonoff3-th/LWT:state:MAP(reachable.map)]" }

result:

an MQTT v2 item:

Switch                  sonoff1_Reachable       "sonoff1 BASIC"                 <switch>                                    { channel="mqtt:topic:Mosquitto:sonoff1Basic:ReachableSonoff1" }

result:

sitemap:

....
Frame label="sonoff1" {
				Switch 	item=sonoff1_Reachable 		mappings=[ON="online ✔"] 		icon="connected" 	visibility=[sonoff1_Reachable=="ON"]
				Switch 	item=sonoff1_Reachable 		mappings=[OFF="offline ✘"] 		icon="error" 		visibility=[sonoff1_Reachable!="ON"]
                ....
			}

Frame label="PC-KELLER" {
				Switch 	item=sonoff3_Reachable 		mappings=[ON="online ✔"] 		icon="connected"	visibility=[sonoff3_Reachable=="ON"]
				Switch 	item=sonoff3_Reachable 		mappings=[OFF="offline ✘"]		icon="error" 		visibility=[sonoff3_Reachable!="ON"]
                ...
			}
...

opus · December 25, 2018, 9:03pm

OK. That proves my theory wrong! In this case I can not say why this displays differently.