[SOLVED] Shelly 1, alternative to Sonoff

Tags: #<Tag:0x00007f0148a40fd8> #<Tag:0x00007f0148a40e70>

(Hans-Jörg Merk) #42

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).

(David Graeff) #43

I was hoping that shelly adopts homie :smiley:

(Hans-Jörg Merk) #44

I found an API reference at


Would it be possible to implement a third convention into your Binding based on that information?

(David Graeff) #45

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.

(Pekka) #46

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 :slight_smile:

(The Squid) #47

Rob from The Hook Up did a video review of the Shelly Smoke along with the Shelly H&T.


(Rossko57) #48

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”.

(Chris Angus) #49

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…

(Markus Michels) #50

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

(Michael) #51

Hi guys,

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!

(Niklas H.) #52

Correct. It is possible to get the current state in OpenHab and to change it via
a physical Switch and/or within OpenHab.