I agree. As a for instance, let’s say I may want to also subscribe to a LWT message to set the Item to UNDEF if the stake goes offline.
That seems reasonable to me.
I apologize in advance for butting in as I have not yet taken the plunge with the new MQTT binding. I guess I’m waiting for the new binding to be capable of addressing all the scenarios I have set up. But here is my use case for one Item subscribing to more than one topic.
Many of my Wi-Fi smart switches are running the TASMOTA firmware. TASMOTA can be set up to periodically send device metrics (i.e., once per Teleperiod). But one can also force TASMOTA to publish metrics based on a command/request. The topic for these two situations is distinct:
tele/<device ID>/STATE (sent automatically every Teleperiod)
status/<device ID>/STATUSnn (in response to cmnd/<device ID>/STATUS<N>)
My MQTT1 Item declaration looks something like this:
Number Bedroom_lamp_RSSI
"Lamp - Bedroom: RSSI [%d%%]" <qualityofservice> (gRSSI)
{ mqtt="
>[broker:cmnd/br_lamp/STATUS:command:*:default],
<[broker:tele/br_lamp/STATE:state:JSONPATH($.Wifi.RSSI)],
<[broker:stat/br_lamp/STATUS11:state:JSONPATH($.StatusSTS.Wifi.RSSI)]
" }
This allows the one Item to be refreshed from whichever “event” causes the update.
Mike
Unfortunately my first Thing is broken now. i Updated to latest 2.4 Build #1418 an got the following error. Unfortunaltely there is no funktion to edit a channel or am i to stupid to do so?
2018-11-09 22:18:53.124 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.eclipse.smarthome.binding.mqtt.generic.internal.handler.GenericThingHandler@d85d0e': ChannelTypeUID not recognised: Number
at org.eclipse.smarthome.binding.mqtt.generic.internal.values.ValueFactory.createValueState(ValueFactory.java:59) ~[?:?]
at org.eclipse.smarthome.binding.mqtt.generic.internal.handler.GenericThingHandler.initialize(GenericThingHandler.java:131) ~[?:?]
2018-11-09 22:18:53.185 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'mqtt:topic:65cee8ac': ChannelTypeUID not recognised: Number
at org.eclipse.smarthome.binding.mqtt.generic.internal.values.ValueFactory.createValueState(ValueFactory.java:59) ~[?:?]
at org.eclipse.smarthome.binding.mqtt.generic.internal.handler.GenericThingHandler.initialize(GenericThingHandler.java:131) ~[?:?]
Hm. Either I implement workarounds for this rather strange topic layout or TASMOTA implements it the right way. I have looked it up just yesterday actually on the TASMOTA repository. Nobody suggested to move to a MQTT convention like Homie so far.
That can be done with OH2 as well with MQTT 2.4. An item can be linked to more than one channel.
That was expected, because of this other problem:
The channel type names needed to be changed, sorry for any inconveniences.
No, if the channel type name changes you have lost. Usually this does not happen. Either edit the json database of openHAB or recreate the channels.
Cheers,
David
Speaking of the ESP frameworks implementing a standard protocol like Homie (which would help all of us with auto-discovery and configuration), there is already a corresponding issue at GitHub for the ESPEasy framework:
I’ve already added my comment/vote for the issue, but we should all do so, to let the maintainers know this is important to us!
1 Like
I am at a loss to comprehend what you are trying to explain to me.
I tried to find the unofficial documentation for your new binding to no avail. I’d like to get in on testing the new binding and setting up my scenarios. Where is it? Does it include any examples?
Thanks.
Mike
I’ve updated to the latest snapshot and my issues with the channels types seems to be resolved 
I do however have another slight issues. As mention I’m using a Philips Hue Dimmer switch with zigbee2mqtt therefore the payloads I’m receiving should be interpreted as command.
I noticed that when I linked the mqtt Thing channel to the item bound to my light brightness, the physical light did not change accordingly. My hypothesis (I haven’t checked the code) is that the mqtt channel is doing a ‘postUpdate’ rather than ‘sendCommand’ - is there a way to configure it so that the payload received triggers a command rather than simply updating the internal state?
If not, could we have a channel configuration option that allows us to set whether we want a state update only or to fire a command?
Thanks
1 Like
That is very much OH1/script speaking 
- A stateful OH2 channel when it gets updated by the binding (MQTT) will do a
postUpdate(updateChannelin code). - A stateful OH2 channel when it gets updated by the user/item will do a
sendCommand.
What you want is an OH2 trigger channel. If that receives a value by the binding (MQTT) it will do a sendCommand instead. It doesn’t have any permanent state / is stateless and acts as a proxy in this particular case.
Could you please try something? In your broker Thing, you can add one type of channel as well. That is the aforementioned trigger channel. Could you please configure one, that listens to the target MQTT topic and link that channel to your item? Maybe that works.
Cheers,
David
Maybe a trigger is what I’m looking for…
Essentially I’m trying to achieve the following:
Dimmer switch (physical device) -> zigbee2mqtt -> MQTT Broker -> MQTT channel -> Item -> Yeelight channel -> Yeelight (physical device)
I tried adding a trigger channel to the broker Thing but that didn’t work out as the profile and item drop downs are blank - not sure if this is a binding issue or UI issue.
Theoretically, if I were to be able to run my JS transformation on the payload and the output the results as the trigger event which then got sent on as a command to an item I think this would work.
However from a modelling point of a view, would it not make more sense to allow the creation of trigger channels from the Generic MQTT Thing rather than creating the trigger channel within the broker? I imagine an MQTT thing representing a device may be capable of to both reporting states (state updates) and issue commands (trigger events).
That works on my system. The profile is default and the item to link shows all items and at the top “Create item”.
Your PaperUI version might be too old, not sure.
No. This trigger channel is for listening to an arbitrary topic on the given broker and trigger an event if something got received. This is mainly there for rules, but could be of use in your use-case.
Theoretically there is a sendCommand API for binding developers that I could call next to updateChannel(). But I wonder If the framework would go into a cyclic loop then.
What version are you running? I use snapshots so currently using build #1421. That modal works correctly when linked an Item to a normal channel, but not the trigger channel.
For now I am using a rule that triggers when the Item state changes and then sends the new state as a command to the same Item.
It would be great if you can implement some workaround until TASMOTA convinced to change. The OH2 binding seems to be working fine for me for everything except Tasmota bases switches.
Prefix works great, unfortunately my NeoPixels colors are out of order. I believe the RGB sequence is incorrect. Not sure if that is my setup or the binding. Thanks for your hard work.
I am on the latest 2.4 #1422 and noew i ám getting the following error in the paper UI for my generic item:
UNINITIALIZED - HANDLER_CONFIGURATION_PENDING
Does anyone lese get this error?
No one else asked this until now, so here we go:
What is the future of the MQTT<->Event Bus integration in the MQTTv2 Binding world?
I assume that it will not be available… correct?
Correct. Is there a need for directly interacting with the event bus?
Same problem as here?
Not really… sometimes I am just too lazy to define a focused MQTT Item so I use the Bus integration 
There was a scenario that you could use this integration to “link” 2 OH2 installations together but this is rare and can be also done with focused items.
Homie looks really interesting and should allow for much easier use of MQTT devices with OH. Awesome.