My point is you don’t have to point and click. Open the JSONDB file and copy/paste/find/replace to your heart’s content. Sure, JSON is not as friendly as other formats, but it is still well structures and well defined and most editors will support the syntax.
The only real difference, besides that everything is defined via JSON instead of a custom syntax in .items files, is that you should stop OH before you edit the JSONDB files. Maybe that is a deal killer, but that doesn’t change the fact that everything you mention you want to do is possible and perfectly reasonable to do with the JSONDB files themselves.
Well - I think you’re not aware what kind of effort this means in my case and I apologize if I sounded offending which I didn’t intend to be at all. I just expressed my feeling on a fact. As said, this is not just n items I have to fix in one installation, but I have to deal with half a dozen of machines each with a lot of physical items plus all the virtual items and so we’re roughly speaking about 500-1000 items in this case.
Anyhow, I get it that you put the technical principles above users’ needs. Fair enough. Yet, I look at that a bit different, but here we would end in a philosophical dispute which doesn’t help. I try to think software from the user and the technics just serve the purpose. Still - to me 2 lines in mqtt-eventbus is a much higher value than 1000+ changes just for the sake of not being “old-fashioned”.
Yet, I find @rlkoshak’s post very promising and I hope that this will be a way to go with far less effort.
I upgraded to 2.4 today and wanted to switch to the new MQTT Binding.
I tried it with the example given in the readme-files but i can’t get it to work.
The server shows as online in the Thing section of paper ui and i can publish and subscribe with an external tool.
Here’s my thing and items files:
ITEMS:
Number WoZi_Sensor_Temperatur "Temperatur [%.0f %%]" {channel="mqtt:myBroker:topic:sensor:Temperatur" }
Number WoZi_Sensor_Feuchte "Relative Feuchte [%.0f %%]" {channel="mqtt:myBroker:topic:sensor:Feuchte" , channel="knx:device:bridge:generic:WoZi_Nummer_Feuchte"}
Number WoZi_Sensor_Druck "Druck [%.0f %%]" {channel="mqtt:myBroker:topic:sensor:Druck" }
Number WoZi_Sensor_GefuehlteTemperatur "Gefühlte Temperatur [%.0f %%]" {channel="mqtt:myBroker:topic:sensor:GefuehlteTemperatur" }```
THING:
Bridge mqtt:broker:myBroker @ "Wohnzimmer" [ host="192.168.158.1",secure=false ]
{
Thing mqtt:topic:sensor {
Channels:
Type number : Temperatur "Temperatur im Wohnzimmer" [ stateTopic="WoZi/Sensor/Temperatur" ]
Type number : Feuchte "Feuchte im Wohnzimmer" [ stateTopic="WoZi/Sensor/Feuchte" ]
Type number : Druck "Druck im Wohnzimmer" [ stateTopic="WoZi/Sensor/Druck" ]
Type number : Gefuehlte_Temperatur "Gefühlte Temperatur im Wohnzimmer" [ stateTopic="WoZi/Sensor/GefuehlteTemperatur" ]
}
}
I can’t see where the problem is …
I did also try to change the channel from the items to: {channel=“mqtt:broker:myBroker:topic:sensor:Temperatur” }
and {channel=“mqtt:myBroker:sensor:Temperatur” }
but nothing worked …
I hope you can help!
Ok. Got it fixed.
I did not create another .things-file for the broker configuration as i thought it is done in this Thing-config.
i now have 2 .thing-configs:
the things file i posted above.
Is this really necessary?
another mistake:
in the items definition the correct channel is:
mqtt:topic:sensor:Temperatur (which makes total sense).
but this is incorrect in the readme example (there is a :mybroker that is not correct).
i contacted the maintainer.
You can have all things created in one file!
The syntax you posted is correct. One can always check the actually correct syntax for the channel on PaperUi (the syntax is different when creating the things via PaperUI or files!!)
I’ve played around for quite some time today with the new MQTT binding, trying to find a way to replace the mqtt-eventbus (which I use to link some items between 2 OH instances).
It took me a while to understand what stateTopic and commandTopic do respectively. I think it’s a bit counter-intuitive, considering that if I wanted to send a command to an item via MQTT I would have to post to the stateTopic and vice versa. But that’s fine.
2 things specifically I find still puzzling and would really appreciate your experience with this so far:
How do I actually send a command to an item via MQTT? Because via the stateTopic I can update the state of the item, but this is not interpreted as a command (thus another binding linked to the same item will not react accordingly).
Why doesn’t the commandTopic fire if the state has been updated?
Because there is a clear separation of behaviour between a stateUpdate and a Command.
A state update (as the name implies) only update the state of the item in OH. A bit like changing a variable value.
A Command is different in that it passes the new value to the channels and bindings to activate a physical device (In most cases, some bindings are “virtual” like the expire binding)
That is easy, is the channel configuration click show more and a toggle switch for the paprameter “isCommand” should show up among other extra parameters. Turn it on and any state update from that channel will be passed on to the item as a command.
Thanks, that makes things a lot clearer!
Btw, just in case someone else is looking for this as well: if configuring the Channels in a things file, the parameter to enable the command behaviour is postCommand=true.
Do you have a reference configuration on how to use a trigger channel?
Apparently the ‘stateTopic’ is supposed to be empty but how is the Trigger well, triggered? How am I supposed to attach an MQTT topic to the channel?
If I try to set “trigger” as a Channel type my hope gets crushed by the following log message:
With the hint from yesterday I tackled the migration of my config to MQTT Binding 2.4 today. And I have to say I’m sufficiently frustrated now, having rolled back most of the work after facing some stability issues with the connection to the MQTT broker.
I’m running OH as well as Mosquitto in Docker containers on the same server (HP ProLiant MicroServer Gen8 with 12GB of RAM). In the openhab.log I was flooded with warnings of the kind MQTT publish to <some-topic> failed!. In the mosquitto.log I saw that the MQTT Binding has lost its connection to the broker every few minutes.
Sure, I’ve created a rule to publish updates of all Items which are members of a new Group in order to replace the Event Bus functionality. This does create some traffic. But after all, the same traffic is sustained by the old Binding… and also after removing this rule the issue remained.
Does anyone else have this kind of issues? Is there something I should consider in the configuration?
You are the first person stress testing the binding. The binding itself should handle all kind of loads, it is asynchronous and the only thing that grows with more requests per second is the temporary memory consumption.
The underlying paho library might cause problems though. Oh 2.4 uses paho in a different version than OH 2.3. Can you stress test the mqtt1 binding in OH 2.4 with the “async=true” configuration, too? Maybe it suffers the same issues at the moment?
