Shelly Binding

[markus7017 (Markus Michels)]

@MHerbst

it seems that you have somehow connected the channels for Humidity and Battery Level. The Batter Level is always -NaN- but I can see in the log the following messages:

need to check that, please provide a TRACE log by PM

@MHerbst

“Motion detected” does not to work. I have “ColoT” events activated but the switch does not change its value and I don’t see any messages in the log window. Even wit TRACE enabled no message appears.

same, the log will show processing. I theory it’s implemented (checked the code), but obviously something is not working

@MHerbst

The values are displayed here with very high accuracy. It would be better if the check could be limited to 1 or 2 digits after the decimal point.

next build adds scaling for battery, watts, temp, hum, lux for REST API and Coap

@MHerbst

Removal of items in Paper UI does not work. The items are not removed. This works with other bindings, therefore I think that is a problem within the Shelly binding.

Never heard this. Make sure the binding is running, otherwise the remove gets initiated, but doesn’t get processed by the (stopped) binding. You could do this again to force the remove even the binding is not running.

[markus7017 (Markus Michels)]

@MHerbst

One little problem:
the binding provides a channel Meter_Watt. The value is alway 0.0 because the bulb does not provide any watt values. I think it would be better to remove this channel.

ok, the returned JSON has this value, but if it is always 0 it makes no sense to have that channel, removed with next build. Please also verify README from next build.

@MHerbst

I switched from Color to White with the Shelly Android App and this is what the log shows:

The Coap messages doesn’t not include the color/white mode, so nothing gets updated.
Currently I don’t map color values (rgb) from coap, I thought that’s not nessesary, but this could be added if you like.

I’m wondering about the Coap message. If this is received from color to white mode I would expect that RGB values will be set to 0. Could you please provide a TRACE log showing the COAP message when bulb is in color and also after bulb is switch to white mode, so I could see how the values change. Maybe I could detect the change myself there is a change, e.g. brightness in color=0, in white > 0. But if all values are received independent from the mode there is no chance. Again, the Coap implementation is lacking parts of the sesor values to get full control.
The update after 30s happens, because of the next regular status update.

Please always provide some history before the event and some moments after. It’s tricky to understand what happended just having a few lines of trace. If the trace gets bigger (> 50-75 lines) feel free to send me a PM.

[MHerbst (Martin Herbst)]

@markus7017

Never heard this. Make sure the binding is running, otherwise the remove gets initiated, but doesn’t get processed by the (stopped) binding. You could do this again to force the remove even the binding is not running.

The binding was definetly running. I alos tried it after a openHAB restart. But same problem. I also did not see this before. I have tried to remove a item of another binding and that worked. Will try it again after a fresh setup.

I will try to create the TRACE logs for the other problems tomorrow.

[markus7017 (Markus Michels)]

@manolo

P.S.: If somebody requires my thing / item config please let me know.

Sure, so we could include samples of all device types in the README

[markus7017 (Markus Michels)]

@papaPhiL

I have no bugs found in the setup, but I am not using the Shelly EM anymore, as I have found a way to measure my house without shellys.
-Do you want me to test specific things?

Yes, the general function: Do all values show up, right format and get updates as expected a) with regular http events b) with CoIoT events

@papaPhiL

I have noticed some “delay” or even “resets” when playing around with a shelly dimmer.

Do you see any errors / exceptions / warnings in the log?
@Igi and I saw device reboots in some scenarios related to the http events. Maybe this is also an issue in other scenarios (the device went offline for 5-10 sec and then comes back = smells like a reboot). There is a new firmware 1.5.6, which should include fixes for the issues @Igi reported. Maybe this fixes also your issues.

@papaPhiL

Something else I can report is that the ping-delay of some shellys in my house is “huge”… sometimes more than 10sec!

Maybe this is the same root cause. As mentioned 5-10s smells like a device reboot. Did you verified a proper WiFi signal? Did you run a ping test for a while to see if response times are consistent?
Please check wifiRSSI value (WiFi signal strength) in the thing properties

[markus7017 (Markus Michels)]

Nightly build will bring

• All meter attributes will be scaled to 2/3/4 digits depending on the unit type
• channel currentWatts for bulb removed
• brightness = 0 switches Dimmer, RGBW2, and Bulb OFF
• brightness > 0 switches Dimmer, RGBW2, and Bulb ON if light is currently off
• README updated

Switching the light depending on the brightness value allows to use the slider to perform those actions - most left = OFF, anywhere else = ON+selected brightness. The next step will be to removed the channel output for Dimmer, RGBW2 and Bulb to conform to other OH light implementations (like Wemo, Tradfi etc.).

This allows to define

Switch DimmerSwitch     "Light on/off" {channel="shelly:shellydimmer:XXX:relay#brightness"}
Dimmer DimmerBrightness "Garage Light Brightness" {channel="shelly:shellydimmer:XXX:relay#brightness"}
Dimmer DimmerIncDec     "Garage Light +/-" {channel="shelly:shellydimmer:XXX:relay#brightness"}

and include both items in the sitemap

sitemap demo label="Home"
{
        Frame label="Dimmer" {
            Switch   item=DimmerSwitch
            Slider   item=DimmerBrightness
            SetPoint item=DimmerIncDec
        }
}

Comments?

[manolo]

Here is my config for shelly flood and shelly h&t.
shelly.things:

Thing shelly:shellyht:e01691 "ShellyChimenea" @ "lowerground" [ deviceIp="10.0.55.101", userId="", password="", lowBattery=15 , eventsCoIoT=true ]
Thing shelly:shellyht:e01681 "ShellyDormitorio" @ "upperground" [ deviceIp="10.0.55.102", userId="", password="", lowBattery=15 , eventsCoIoT=true ]
Thing shelly:shellyflood:764fe0 "ShellyFlood" @ "cellar" [ deviceIp="10.0.55.103", userId="", password="", lowBattery=15, eventsSwitch=true, eventsButton=true, eventsCoIoT=true ]

shelly.items:

// SHELLY H&T DORMITORIO
Number ShellyHT_Dormitorio_Temp		"Dormitorio Temperature"	<temperature>	(gShelly) {channel="shelly:shellyht:e01681:sensors#temperature"}
Number ShellyHT_Dormitorio_Humid	"Dormitorio Humidity"		<humidity>	(gShelly) {channel="shelly:shellyht:e01681:sensors#humidity"}
Number ShellyHT_Dormitorio_Batt		"Dormitorio Battery"		<battery>	(gShelly) {channel="shelly:shellyht:e01681:battery#batteryLevel"}
// SHELLY H&T CHIMENEA
Number ShellyHT_Chimenea_Temp		"Chimenea Temperature"		<temperature>	(gShelly) {channel="shelly:shellyht:e01691:sensors#temperature"}
Number ShellyHT_Chimenea_Humid		"Chimenea Humidity"		<humidity>	(gShelly) {channel="shelly:shellyht:e01691:sensors#humidity"}
Number ShellyHT_Chimenea_Batt		"Chimenea Battery"		<battery>	(gShelly) {channel="shelly:shellyht:e01691:battery#batteryLevel"}
// SHELLY FLOOD SOTANO
Number ShellyF_Sotano_Temp		"Sotano Temperature"		<temperature>	(gShelly) {channel="shelly:shellyflood:764fe0:sensors#temperature"}
Number ShellyF_Sotano_Batt		"Sotano Battery"		<battery>	(gShelly) {channel="shelly:shellyflood:764fe0:battery#batteryLevel"}
Switch ShellyF_Sotano_Flood		"Sotano Flood Alarm"		<alarm>		(gShelly) {channel="shelly:shellyflood:764fe0:sensors#flood"}

I hope the config is okay. At least it is working fine with OH 2.4.0 as well as with 2.5.0

[Mario_Aerni]

I tested the Shelly H&T today. Humidity, temperature as well as battery looks good so far (with and without CoIotT).
Great work!

[markus7017 (Markus Michels)]

good news, thx

[markus7017 (Markus Michels)]

fyi: Shelly Cyber Monday Special

[MHerbst (Martin Herbst)]

@markus7017

Never heard this. Make sure the binding is running, otherwise the remove gets initiated, but doesn’t get processed by the (stopped) binding. You could do this again to force the remove even the binding is not running.

I have found the reason for this problem: if have only deleted the items but did not “unlink” them from the channel. After unlinking them, they disappeared. This seems to the normal behaviour. I could reproduce the same effect with the astro binding.

[Christian_Brosius]

I have a strange problem with all my Shelly1.

Linking the ‘Auto Off Timer’ is not possible.

After discovery all Channels are linked automatically, except ‘Auto Off Timer’.
Manual linking gives a success message, but it is not linked anyway.

The ‘Auto On Timer’ - Channel is working fine.

Is this a binding bug, or something in my setup (OpenHAB 2.5M5 - Binding 2.5Snapshot 26.11.2019) ?

Kindest regards,
Christian…

[julesx81 (Lorenzo S.)]

sry man, should i repeat same procedure?

• remove all shelly entries from paperui
• stop oh2 service
• openhab-cli clear-cache
• copy jar into addons (set correct permission)
• restart oh2 service

Or simple stop service put jar and restart?

Regards
L.

[markus7017 (Markus Michels)]

@Christian_Brosius

After discovery all Channels are linked automatically, except ‘Auto Off Timer’.
Manual linking gives a success message, but it is not linked anyway.

yes, there was a typo in the item-type

This latest build has several changes to the XML definition (based on Review requirements)

• Some of the channels have to use the system predefined channel types. This makes sense in general. However, this leads to a German/Englisch mix, because system channels are multi-language whereas my defintions are English only. Translating all the stuff - no comment.
• Various channels are tagged as advanced. Those will show up when you click Show Advanced in the channel definition (where you link channels). Improves the overview for new users and then step by step adding advanced channels.
• NEW: There is a new channel group device for each thing type. This was driven by @Igi. We still have the assumption that the REST API calls are not 100% full-filled so that the http request fails and the binding needs to retry. This is ok for status polls, but inacceptable for commands. I saw those myself and also here in the thread. To observe this and also implement some kind of rule-based minitoring the bindings adds the channel uptime, lastUpdated and signnal (RSSI) and deviceEvent. Note: uptime is only updated on a event or once a minute to limit polling so don’t expect uptime to be accurate.
• NEW: In addition the binding adds an observation of Device reboots itself based on currentUptime < lastUptime. The only way this could happen is when the device has been rebooted in between. In this case a deviceEvent is triggered, which could be catched by a rule (I’ll add an example to the README later).
• NEW: Plus the binding observes the WiFi RSSI. If the network connection is not stable it could explain why API calls could fail. The binding checks RSSI < -80, which is already at the limits of a stable connection. Again a device event will be triggered in thise case, which can be catched by a rule. This check is done every 10 minutes.
• NEW: device#lastUpdated will be updated when something changes in the channel values, or a event is received. For this I removed the lastUpdated channels on the component level (e.g. sensors#lastUpdated).
• NEW: Color value (red/green/blue/white/gain/brightness) are mapped from Coap events to channels
• CHANGE: Varios channels like battery-level now use system defined typeIds, which creates a unified user experiece with other bindings. For now this could lead up into some mixed language (DE+EN), because system channels are available bi-ligual whereas the bindings uses only English. However by defining your own sitemap etc. you could overwrite this.
• FIX: Battery, Humidity and Motion Coap updates for the Sense should work now (the problem @mherbst reported)
• README was updated (will provide more information with every new build until the final release)

I’m not sure if the central build system already catched my yesterday’s changes. Wait until you see a build timestamp > 30-Nov-2019 03:49 here JFrog

or use the private build https://github.com/markus7017/myfiles/blob/master/org.openhab.binding.shelly-2.5.0-SNAPSHOT.jar?raw=true

Would be very helpful if you keep and eye on typos, missing channels etc. and of coure cross-device testing is always welcome. You could also contribute to the review.

Make sure to delete existing things and re-discover, because there are changes to the XML definition (channel layout etc.)

[markus7017 (Markus Michels)]

That’s the safe way.

If the XML definition doesn’t change you don’t need to rediscover the things, you could usually just copy the jar into addons - works 9 out of 10 times and the 10th time creates wired side effects.

• remove all shelly entries from paperui
• stop oh2 service
• openhab-cli clear-cache
• copy jar into addons (set correct permission)
• start oh2 service
• re-discover things
• the channel/item linkage should be restored automatically

[alexxio (Alessio)]

Ok I’ve just installed the latest snapshot from your previous post (private build link).
I can confirm I had to install Gson as stated in previous posts (I run OH 2.4 on a rpi3b+).

By now I’ve just added my shellies 2.5 as rollershutters with just the Roller Control (roller#control) channel linked. And one plug-s with just the Power (relay#output) channel. And wifi signal on each dev.

I keep getting this error on “some minutes” basis:

==> /var/log/openhab2/openhab.log <==
2019-11-30 15:31:02.463 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NoSuchFieldError: DECIBEL_MILLIWATTS
	at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.fillDeviceStatus(ShellyBaseHandler.java:420) ~[?:?]
	at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.updateStatus(ShellyBaseHandler.java:376) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]

update: I waited some time and it seems the wifi signal gets not populated

[Christian_Brosius]

new Snapshot ist working great -> Problem with ‘Auto Off Timer’ is solved.

Do you need some help with the translation? If you point me to the correct XML I may be able to do some of the boring translation stuff.

Kindest regards,
Christian…

[loop (philipp)]

Hi everybody
i installed the stable binding and everything worked in paperui.
shelly 1 worked perfectly
shelly dimmer i have a strange behavior. i made one item for the brightness and i want to controll it with only one item, as i use googleassistant
wenn i change the brightness, it works
but whenn i turn it of, the binding sends this:

shellydimmer-db352c ERROR: Unable to process command for channel shelly:shellydimmer:db352c:relay#brightness: Shelly API call failed: Unexpected http response: Bad brightness value!, url=http://192.168.2.78/light/0?turn=off&brightness=0 (class java.io.IOException)

i got a alot of errors and nothing happens, light stay on.

what i discovered, if i change the url to http://192.168.2.78/light/0?turn=off&brightness= thenn it goes off, whenn i do http://192.168.2.78/light/0?turn=off&brightness=0 i got a error (Bad brightness value!)

is this a bug or do i make a misstake? whenn i make a second item in openhab and linkt it to the output (on/off) i can switch it on and of with no problem, but i want to use one item as i want to dim and on/off with googlehome

thanks in advance
philipp

[markus7017 (Markus Michels)]

@alexxio

I can confirm I had to install Gson as stated in previous posts (I run OH 2.4 on a rpi3b+).

How do you installed gson?
I my experiece when doing a bundle:install and later an openhab-cli clean-cache it gets removed and you have to re-install it again

@alexxio

update: I waited some time and it seems the wifi signal gets not populated

What do you mean with “gets not populated”?
Did you linked the channel?

@alexxio

java.lang.NoSuchFieldError: DECIBEL_MILLIWATTS

hmm. that’s strange. DECIBEL_MILLIWATTS is specified for the singal channel and should result in dBMm, but it doesn’t so I added “dBM” to the pattern of the channel. Obviously something is going wrong, this error is an indication.

[markus7017 (Markus Michels)]

@Christian_Brosius

Do you need some help with the translation? If you point me to the correct XML I may be able to do some of the boring translation stuff.

That would be great - simple do do, but a lot of work.

Let’s wait until I integrated the 1.5.6 features

• input states - this is a pre-requisite to control detached mode
• shortpush/longpush as new event types, but http only (missing in the Coap implementation)
• and also improved handling of the brightness channel to support On/Off, Increase/Decrease, and switch of with Brightness=0 - as requested by Review
• this also means that the output channel for light and dimmer gets removed (if it’s working well)

How do you see the list of advanced channels? Is there anyone, which should be non-advanced, because useful for a lightweight setup?

Do someone needs the calibrating and positioning channels? I think I had some in a while ago and then removed them to reduce the number of channels in general.