[SOLVED] Shelly 1, alternative to Sonoff

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

I found an API reference at

shelly-api-docs.shelly.cloud

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

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

Interesting…

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

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!

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

1 Like

Hi All,
You can found them in France at www.quintium.fr

Hi,

Can you recommend reliable supplier/seller for Shelly 1 in UK ?
Very interested to buy few units for testing, 16A relay looks promising when comparing to 10A used on Sonoff Basic.

Just buy directly from the supplier, https://shelly.cloud is their website. Works fine as long as you still are part of the EU.

It’s also okay if you’re not in the E.U.

Sure, but you might be better of with a local distributor/supplier then due to import duties/taxes.

I have a slightly different requirement and as I don’t “play around” very much with my Openhab set up, I am not so useful at figuring out what I need to do. My situation is as follows:

I have a Sonoff T2 wall switch mounted and working with a EU relay switched light. It has been operating like this for 1 year, however I always had issues with the switch status whenever the power goes off or the Openhab server (Pi) shut down and restarted. I recently purchased a Shelly1 and have incorporated that in to the light relay circuit and when using Shelly Cloud all control is now perfect with either the original manual wall switches or the OpenHab User Interface.

Then I changed the Shelly1 to MQTT (which disconnects the Shelly Cloud interface) and now I want to have the Sonoff T2 switch to send only an MQTT command to operate the Shelly1 and turn on the light. I will physically disconnect the wire to the back of that Sonoff switch so that it becomes only a “virtual” switch.

My current Sonoff default.items is like this:

Switch   GF_Entryway_Light2                  "Entrance Ceiling"            <light>            (gPersist)                               [ "Lighting"   ]   { mqtt=">[broker:cmnd/kitchen/power2:command:OFF:OFF], <[broker:stat/kitchen/POWER2:state:default]", expire="2s,command=OFF" }

…Please note that the expire="2s, command=OFF was only required for the EU lighting relay operation and once the Shelly1 is being used to switch on the light from the SONOFF switch it will no longer be required…

The MQTT command line that works the Shelly1 is like this:

Switch   GF_Shelly_Test                  "Entrance Ceiling"            <light>            (gPersist)                               [ "Lighting"   ]   { mqtt=">[broker:shellies/shelly1-8B19C5/relay/0/command:command:*:MAP(shelly.map)],<[broker:shellies/shelly1-8B19C5/relay/0:state:MAP(shelly.map)]" }

Could someone please assist me to reformat the SONOFF MQTT code so that it works as a virtual switch to operate the Shelly1.

Thank you in advance for your input and assistance

You’re using MQTT binding 1.x, so you won’t be able to use the follow profile feature for channels.

The easiest way is to use a rule. Trigger from Sonoff update and send Shelly command.

1 Like

Dear Rossko57

Thank you for the suggestion I followed your suggestion and now have the rule working.