There is an MQTTv2 action:
Use it like this:
val actions = getActions("mqtt","mqtt:broker:myUnsecureBroker")
actions.publishMQTT("topic", "payload")
I did, but have faced some issues (see posts above)… this should be a workaround for the time being.
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.
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
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é
yes, it works!
However, I do not understand the cause of the problem. with version MQTT v1 I did not have this problem …
As said on the other thread, that migth be a new feature instead of a problem.
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"]
...
}
...
OK. That proves my theory wrong! In this case I can not say why this displays differently.
Thanks!
There’s another thing I’m struggling with: I understand with the postUpdate option I can determine if a state update should be interpreted as a command or just a state.
But on the outbound side - is there any way to also publish state updates of items, not just commands?
At the moment I use a rule like this as a workaround:
rule "MQTT Post State Updtes"
when
Member of gSomeGroup changed
then
triggeringItem.sendCommand(triggeringItem.state.toString)
endIm experiencing the same issue as @911rgt and @bern77. After a while (already after 4 hours last night) it stopped working and I started receiving:
2018-12-26 04:41:33.746 [WARN ] [home.binding.mqtt.action.MQTTActions] - MQTT publish to openHAB/topic failed!
After restarting OpenHAB it starts working again for a few hours.
I’m giving up - I’ll revert back to the mqtt1 Binding for the time being.
For a small installation the 2.4 Binding might be working fine, but in my case I’m just amassing workarounds and still the functionality is not as stable as that of the mqtt1 Binding.
I really appreciate the migration to the openhab2 architecture, but I’m afraid for me the binding is not yet usable.
This action part is apparently not working stable. It has nothing to do with the mqtt binding by the way. This is how all actions in the future are going to be called.
So please open bug reports if that is not working stable enough otherwise openHAB will be really broken when other actions are auto migrated at some point.
Does the new MQTT binding support Persistence?
with the previous version I did something like this:
mqtt-persistence:
broker=solace
# The MQTT topic to which the persistence messages should be sent.
topic=moosecabin/homeautomation/persistence
# A string representing the persistence message content.
message=%1$s, %3$s
mqtt.persist
Strategies {
everyHour : "5 * * * * ?"
default = everyChange
}
Items {
// persist all items every hour and on every change
* : strategy = everyChange, everyHour, every5Minutes
}No, this only works with the MQTTv1 Binding
MQTT persistence is, in fact, an independent addon 
1 Like
I also used the event bus heavily. People use OpenHab for different use-cases; I use it as a device/mqtt bridge for integration into another (homegrown) system. Event bus was awesome and allowed easy integration. The new binding is much much less friendly to this kind of use-case, particularly in terms of work required.
It would be really nice to see something like event bus come back, where I don’t have to do so much [error-prone] work to devices to MQTT. I know I can still use the v1 binding, but the need to use that points to a missing use-case.
I’ve encountered an issue with the binding and rules.
When I want to publish a message to my configured broker I get the following error in the log:
21:55:16.630 [ERROR] [untime.internal.engine.RuleEngineImpl] - Rule 'myRule': Instance is not an MQTTActions class.
My rule is the following:
rule "myRule"
when
Item myItem received command
then
val actions=getActions("mqtt","mqtt:broker:myBroker")
switch(receivedCommand){
case 0: {
actions.publishMQTT("Topic/Payload/Status1","TRUE")
createTimer(now.plusMillis(500))[actions.publishMQTT("Topic/Payload/Status1","FALSE")]
}
case 1: {
actions.publishMQTT("Topic/Payload/Status2","TRUE")
createTimer(now.plusMillis(500))[actions.publishMQTT("Topic/Payload/Status2","FALSE")]
}
}
end
However, when I add the same broker twice in PaperUI, this time with a different name and ID (ID is autogenerated now) It works and messages are beeing published via the rule, even without making use of this ‘dummy’ broker. When I remove the ‘dummy’ broker again, it stops working.
In addition, message published directly via Items do work all the time.