Don‘t have the right code location at hand, but @David_Graeff implemented the homie naming convention, so should be not to difficult to adopt this to the Shellies. Having a separate Binding does not bring any discovery benefits, as I don‘t see a wa to have them sicovered (no MDNS or UPnP).
I was hoping that shelly adopts homie
I found an API reference at
Would it be possible to implement a third convention into your Binding based on that information?
This is one manufacturer only and their convention is not vendor neutral in any way, I see issues adding theirs. But I can imagine to change the interfaces of the mqtt generic binding in a way that it is easy to write additional bindings building on top of it.
I have to agree - mqtt has another steep learning curve, plus an additional daemon to run.
However, with limited capacity this is not the first problem to solve
Rob from The Hook Up did a video review of the Shelly Smoke along with the Shelly H&T.
This kind of capability was incorporated (or rather, the bones of it) in Modbus-2 binding. Because EVERY type of hundreds of Modbus devices is so different (there’s no self-identifying), the necessary flexibility leads to complex manual configuring.
The idea was to have add-on bindings each tailored for common devices that exploited the basic binding as a transport. I don’t know how that plugs together exactly!
In reality, it’s not that difficult to copy-paste successful configurations. While device diversity has mitigated against anyone getting interested in the necessary developments, for a likely field population counted on one hand.
It’s a different approach to say, zwave binding, where there are enough common features and self-identifying devices to allow for a list of simple “templates”.
Yes they looked great and why I ordered 2 of the Shelly Smoke alarms back in the end of July…still waiting for them to be dispatched… This week I was told there is an unknown production delay…
yes, I think kind of an adaption layer would make sense: core functionality is build out of the box and there arenplugins to perform auto-discovery and creating the thing with proper controls and meaningful attributes
thank for this infomation!
Tell me please if i understood one thing right - if i connect shelly with my normal lamp switch, i can get this contact state in OH. I mean if i turn on/off the lamp with normal switch i can get state of it with OH?
Thanks a lot!
Correct. It is possible to get the current state in OpenHab and to change it via
a physical Switch and/or within OpenHab.