Use case:
I publish a time string over mqtt under 2 different topics.
I have some “old” diy ESPs and Arduinos around the house. When I was staring I wrote my own arduino code for these devices. The topic and mqtt broker and WiFi are all hard coded and I can’t do OTA. They work fine and some of them are near inaccessible. So I can’t change the WiFi, the broker address or the topics without “breaking” these devices.
Later on I wrote some more advances code for other devices and by that time I had changed my MQTT topic structure completely. You see, at first I was experimenting but as it was working these “old” devices became operational.
So now I am stuck with legacy devices that can only subscribe to very different topics than my new mqtt structure.
Therefore I need to publish to 2 very different topics.
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:
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.
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!
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?
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?
A stateful OH2 channel when it gets updated by the binding (MQTT) will do a postUpdate (updateChannel in 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.
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.
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.