Shelly Binding

stuetzomat · November 22, 2023, 11:20am

no, I’m using 4.0.4.

markus7017 · November 22, 2023, 11:59am

ok, I created a DEV build for 4.0.x. In general 4.1 would work, but there are various new dependencies (package versions installed by core framework), wich are not fulfilled by 4.0.5
Check READMEbeta how to install this, create a DEBUG log

4.1-DEV | 4.0.-DEV |3.4.5-DEV | README | READMEbeta
Avdanced Users - Shelly Manager - Bugs/Features - API Doc | Firmware Index - Firmware Archive

Note: The DEV build is always newer than the version in the official Distro or Milestone builds. Current development is based on 4.1-SNAPSHOT, 4.0.x and 3.4.x might be outdated.

markus7017 · November 22, 2023, 12:01pm

Please make sure to report bugs or feature requests here
This gives me a to-do list once I’m done with the current PRs and you an overview what’s already know / on the list

stuetzomat · November 22, 2023, 3:04pm

ok, I’ll give it a try. thanks for the quick support!

c0rtez · November 24, 2023, 7:20pm

Hello everyone,

I have a problem again.
I have integrated quite a few Shelly products into Openhab and have never had any problems.
However, I now have my first Shelly Plug S and can’t get it into Openhab.

The Thing always stays on:
Status:
UNKNOWN
CONFIGURATION_PENDING
Initialisierung oder Gerät im Schlafmodus.

I use Openhab 3.3.0 and the Shelly Binding. The Plug S has the latest FW.
The plug works perfectly in the Shelly app.

I have tried it both with and without the Shelly Cloud access data. Both ways had the same result.
I have also activated MQTT and snooped in my broker (which runs in Openhab) and can find the Shelly there accordingly. However, as I currently only use MQTT to read data and use all other shellys via binding, I actually want to do the same with Plug S.

What’s also strange is that I can’t find the Shelly in the Thing system after the scan, whereas this is the case with all other Shellys. I have to select the Plug S manually and enter the IP. It is also strange that in Thing only the two channels for the device status are offered, but not the others from the relay area.

To be on the safe side, I have already assigned a fixed IP via the Fritzbox and set the Shelly to factory settings. All without success.

Does anyone have any ideas what else I could try?

markus7017 · November 25, 2023, 8:35am

All of that os not nessesary (no mqtt, static ips…)
The Plug S should be discovered automatically and supported by the binding. However, when I read „OH 3.3.0“ I‘m not sure if that version is supporting that device, because it‘s really old.
Why are you not moving to 3.4.5 or even better to 4.0 (which brings in some migration effort)?

Otherwise you should enable DEBUG log and get additional information, most likely an init problem

c0rtez · November 25, 2023, 11:45am

Thanks, I updated to 3.4.5 and it’s working now.
Unfortunately my shelly flood is now behaving the same way as the Plug S did before

PS
I dont move to OH4 at the moment as I have a binding running which is very important for me which isn’t working on OH4 anymore.

markus7017 · November 25, 2023, 12:56pm

You need to press the button on Shelly Flood. Then start the discovery in OH, maybe you need to do this 2-3 times.

markus7017 · November 26, 2023, 11:48am

Good news:
PR #15922: Misc changes (small fixes, log improvements, hardened leak prevention on and
PR #15950: Support for Shelly Plus Dimmer 10v
have been merged, thanks @Lolodomo

Only one more is missing to get the list to the feature level of the DEV build: This includes auto-upgrade of channel definitions. OH 4.1 introduced more strict validation of channel units and updates to channels, which brought up several issues around channel definition and updates. This PR will bringt an auto-update: beside missing channels, which will at added at thing initialization time the binding also checks existing ones if they match the current definitions, if not the definition will be updated.

If you want to help testing: I created a pre-PR build having those changes:
org.openhab.binding.shelly-4.1.0-SNAPSHOT_pr.jar

Once this PR is merged I could work on additional features / bug fixes.
Please make sure to create an issue here

markus7017 · November 30, 2023, 8:34pm

I updated the DEV build for 4.1 and 4.0.5, not 3.4.5
details can be found here:

In addition it includes 2 changes where I need feedback from you

I removed a dependency in the 4.1 build. Please install and check if the add-on loads immediately (or delayed)
I change the WebSock interface, which seems to fix a problem with Wall Display not sending sensor updates (or sensor gets only updated once per minute and status poll)

Re Wall Display:

The production firmware version 1.2.4 contains a bug, which prevents the thing to initialize. Allterco has fixed this in 1.2.5-rc6 and newer. Don’t use firmware 1.2.4, we can’t say anything on versions between 1.0.8 and 1.2.4. If you have 1.2.4 give the current beta a chance, which also brings support for the thermostat feature
In some installations we see rapid mDNS announcements (@igi does, not with mine). In older builds of the binding this lead to exceptions and out-of-memory, which have been fixed in between. But each mDNS announcement will be processed by the binding and causes unnecessary overhead. So far we couldn’t narrow this down, but are in investigation with the Allterco team.
In my setup I see the WD web server dying after a while, not accepting any http requests incl. Web UI in a browser. This is not a binding related problem, known by the firmware team, but so far no reason/fix.

Please help to validate the above mentioned changes and share details if you are also bothered by the WD issues listed above.

4.1-DEV | 4.0.-DEV | 3.4.5-DEV | README | READMEbeta
Avdanced Users - Shelly Manager - Bugs/Features - API Doc | Firmware Index - Firmware Archive

Note: The DEV build is always newer than the version in the official Distro or Milestone builds. Current development is based on 4.1-SNAPSHOT, 4.0.x and 3.4.x might be outdated.

WeRo · November 30, 2023, 8:42pm

Hi all,

is it possible to reboot a TRV by a command in a rule?

Problem to solve:
A temperature sensor of one of my TRVs seems to quit working sometimes. When this happens the valve position increases up to 100% and stays there. The only way I can solve this is to reboot the TRV. Therefore I would like to write a rule to reboot the TRV in these cases.

markus7017 · November 30, 2023, 11:04pm

The Shelly Manager has this option, but there is no channel forcing a reboot
You could try to send a “GET http://<device ip>/reboot” to the device using the http binding

WeRo · December 3, 2023, 9:58am

I am still struggling with some problems.
How can I hand over the OpenHAB password?

Update - just right after asking I got it:

First I had to install sshpass

sudo apt install sshpass

and then this works

sudo sshpass -p PASSWORD /usr/bin/ssh -p 8101 openhab@localhost feature:install openhab-transport-coap

d_valchev · December 3, 2023, 4:05pm

Hi, I ran into an issue when installing 4.1.0.202312011056 snapshot.
When I add the file in addons folder I’m getting:

17:14:11.221 [INFO ] [org.apache.felix.fileinstall         ] - Installing bundle org.openhab.binding.shelly / 4.1.0.202312011056
17:14:11.271 [WARN ] [org.apache.felix.fileinstall         ] - Error while starting bundle: file:/openhab/addons/org.openhab.binding.shelly-4.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.shelly [284]
  Unresolved requirement: Import-Package: com.google.gson; version="[2.10.0,3.0.0)"

	at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) ~[?:?]

The rest of the features are:

openhab> bundle:list | grep Shelly
284 │ Installed │  80 │ 4.1.0.202312011056 │ openHAB Add-ons :: Bundles :: Shelly Binding Gen1+2

openhab> feature:list | grep coap
openhab-core-io-transport-coap │ 4.0.4 │          │ Started │ distro-4.0.4 │
openhab-transport-coap         │ 4.0.4 │ x        │ Started │ distro-4.0.4 │ CoAP Transport
openhab.tp-coap                │ 4.0.4 │          │ Started │ distro-4.0.4 │ Californium CoAP library

openhab> feature:list | grep gson
openhab.tp-gson                │ 4.0.4 │          │ Started │ distro-4.0.4 │ Gson

Reverting back to the previous addon file works.

17:22:21.291 [INFO ] [org.apache.felix.fileinstall         ] - Uninstalling bundle 284 (org.openhab.binding.shelly)
17:23:22.093 [INFO ] [org.apache.felix.fileinstall         ] - Started bundle: file:/openhab/addons/org.openhab.binding.shelly-4.1.0-SNAPSHOT.jar

Files

-rwxr-xr-x+ 1 openhab openhab  617237 Oct 21 04:00 org.openhab.binding.shelly-4.1.0-SNAPSHOT.jar
-rwxr-xr-x+ 1 openhab openhab  613523 Dec  3 16:54 org.openhab.binding.shelly-4.1.0-SNAPSHOT.jar.202312011056

Any idea?

markus7017 · December 3, 2023, 4:46pm

are you using OH 4.0 or 4.1?
tr the 4.0 build
Core 4.1-SNAPSHOT switched to a new gson version, which is not available on 4.0 or early 4.1 installations

d_valchev · December 3, 2023, 5:23pm

Thank you for the prompt response @markus7017.
I’m with 4.0 and that was my guess too - new gson version dependancy.
Do you think 4.0 will work with it or i may run into other dependancies issues?

d_valchev · December 3, 2023, 7:22pm

@markus7017, I changed OH to 4.1.0.M4 and the shelly-4.1.0-SNAPSHOT (202312011056). However, looks like the addon channels (Addon is attached to i4DC) still missing.

markus7017 · December 9, 2023, 8:29am

Please create an issue here: Issues · openhab/openhab-addons · GitHub
and attach a DEBUG log of the initialization

d_valchev · December 9, 2023, 11:36am

@markus7017.
I opened this one some time ago. Therefore, I just updated it.
Thanks, Dimitar

wlanrouter1 · December 13, 2023, 8:32am

Hi all, I need help with CoIot Setup. I am disabling a Shelly Dimmer input at night:

rule "rManipulierterSchalterKzAkti" when
	Item kidsSleeping changed to ON
then
	sendHttpGetRequest("http://192.168.81.78/settings/light/0?btn_type=detached");
end

At day, I activate it again.

rule "rManipulierterSchalterKzAkti" when
	Item kidsSleeping changed to OFF
then
	sendHttpGetRequest("http://192.168.81.78/settings/light/0?btn_type=one_button");
end

I want the switch to not turn of itself (main light), but let openhab switch on another (night) light. Therefore I need to catch the button push action. As Shelly Actions with REST API do not work anymore, I want to try CoIot.

My openhab Server has this IP: 192.168.81.11/24
My Shelly has this IP: 192.168.81.78/24

If I want to change CoIot by the Shelly Manager, I see this:

But in the Shelly Webinterface, I had setup up this:

Why does Shelly Manager is choosing 172.20.0.1 ? This is not within my IP subnet!?

What IP should be set up?

Btw. Making an Item is not working. No changes will be logged.

Switch iShKzTasterDecke	{channel="shelly:shellydimmer2:40f5200180c2:relay#button1"}

Catching the Channel is also not working. No changes are logged, nothing get triggered:

rule "Shelly Button 1 Schlafzimmer"
when
  Channel "shelly:shellydimmer2:40f5200180c2:relay#button1" triggered
then
  logInfo("Info", "Shelly Button 2 Schlafzimmer: Trigger: " + receivedEvent.toString())
end

What are my options to catch the push button?

Infos:

Shelly Dimmer2: Current version: 20230913-114008/v1.14.0-gcb84623
Openhab openHAB 4.0.4
Shelly Binding 4.0.4
Binding setup:

image736×614 20.7 KB