Shelly Binding

redwhale240 · November 30, 2020, 11:28pm

This is it! That is the solution, I had over looked the additional channels that were hidden. Thank you for pointing that out, it would be helpful if that was a standard channel.

rickitaly · December 1, 2020, 8:02am

Hi Everyone!
I’m using shellies on OH since 2018 with MQTT, and i’m quite satisified with that; now that my configuration has grown, it’s very easy to make a copy/paste and configure a new device.
I use only text files.
Now that OH3 is getting closer, i setup a test environment and i was thinking to switch to Shelly binding in the new configuration.
I did setup a shelly2 rollershutter very easily. The binding is ok and i could configure simple items:

Thing:
Thing shelly:shelly2-roller:XXXXXX "Shelly 2 Roller XXXXXX" [deviceIp="192.168.1.xyz"]

Item:

Rollershutter Studio_RS "Serranda Studio  [%.0f %%]" {channel="shelly:shelly2-roller:XXXXXX:roller#control"} 
Number Studio_RS_POS "Serranda Studio Pos  [%.0f %%]" {channel="shelly:shelly2-roller:XXXXXX:roller#rollerpos"} 
String Studio_RS_STATE "Serranda Studio Stato  [%s]" {channel="shelly:shelly2-roller:XXXXXX:roller#state"}

Unfortunately i cannot setup a simple shelly1!

if i do the following:

Thing shelly:shelly1:xxxxxx "Shelly 1 Studio" [deviceIp="192.168.1.xyz", userId="", password=""]

Item:
Switch Studio_Light_Bind "Luce Studio Binding" <light> {channel="shelly:shelly1:xxxxxx:relay#output"}

This item is correctly sending command to the switch but not getting updates from the device!
If i configure same device with my classic MQTT configuration it works fine.

All shelly devices have latest firmware (1.9.0 - 1.9.2)

Where am i doing wrong?

Thanks!

markus7017 · December 1, 2020, 1:41pm

Do you have password protection enabled?
Please first try to add the device with the device discovery within OH (rather than using text files)
Shelly 1 is def. working with the build included in the OH milestone build.

karld · December 1, 2020, 1:44pm

Hi

I really enjoy this binding, seems to report my consumption properly. Just having an issue with the debug as it is filling up my logs pretty fast. I’m having lot of messages like this:

2020-12-01 14:37:30.289 [WARN ] [.californium.core.network.UdpMatcher] - error receiving response ACK-2.05 MID=53326, Token=, OptionSet={“Unknown (3332)”:0x5348504c472d53233135454246392332}, "{“blk”:[{“I”:1,“D”:“rela”… 623 bytes for Exchange[L280387, complete]
com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected a string but was BEGIN_ARRAY at line 1 column 205 path $.sen[2].R
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:224) ~[?:?]
at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41) ~[?:?]
at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:82) ~[?:?]
at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:61) ~[?:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:129) ~[?:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:220) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:888) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:853) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:802) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:774) ~[?:?]
at org.openhab.binding.shelly.internal.coap.ShellyCoapHandler.handleDeviceDescription(ShellyCoapHandler.java:252) ~[?:?]
at org.openhab.binding.shelly.internal.coap.ShellyCoapHandler.processResponse(ShellyCoapHandler.java:216) ~[?:?]
at org.openhab.binding.shelly.internal.coap.ShellyCoapHandler$1.onResponse(ShellyCoapHandler.java:884) ~[?:?]
at org.eclipse.californium.core.coap.Request.setResponse(Request.java:711) ~[bundleFile:?]
at org.eclipse.californium.core.network.EndpointManager$ClientMessageDeliverer.deliverResponse(EndpointManager.java:272) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.BaseCoapStack$StackTopAdapter.receiveResponse(BaseCoapStack.java:210) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:89) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.ExchangeCleanupLayer.receiveResponse(ExchangeCleanupLayer.java:93) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.ObserveLayer.receiveResponse(ObserveLayer.java:150) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.BlockwiseLayer.receiveResponse(BlockwiseLayer.java:676) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.ReliabilityLayer.receiveResponse(ReliabilityLayer.java:305) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:89) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.BaseCoapStack.receiveResponse(BaseCoapStack.java:139) ~[bundleFile:?]
at org.eclipse.californium.core.network.CoapEndpoint$1.receiveResponse(CoapEndpoint.java:277) ~[bundleFile:?]
at org.eclipse.californium.core.network.UdpMatcher$4.run(UdpMatcher.java:399) [bundleFile:?]
at org.eclipse.californium.elements.util.SerialExecutor$1.run(SerialExecutor.java:276) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_265]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_265]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_265]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_265]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_265]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_265]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_265]
Caused by: java.lang.IllegalStateException: Expected a string but was BEGIN_ARRAY at line 1 column 205 path $.sen[2].R
at com.google.gson.stream.JsonReader.nextString(JsonReader.java:825) ~[?:?]
at com.google.gson.internal.bind.TypeAdapters$16.read(TypeAdapters.java:401) ~[?:?]
at com.google.gson.internal.bind.TypeAdapters$16.read(TypeAdapters.java:389) ~[?:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:129) ~[?:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:220) ~[?:?]
… 32 more

Has this been corrected already ? I’m using the stock binding Shelly Binding (binding-shelly - 2.5.8) with 4 PLUG-S and one EM

Thank you again for this great work (I can now move away from their cloud)

rickitaly · December 1, 2020, 2:34pm

Hello, thanks for your answer.
There is no password protection and i can correctly act on the relay and turn on/off the light from the switch.
But if i change status from the physical input or from mqtt, this is not reflecting the status of the switch.
I tried also with UI built object but result is the same.
What is the way to debug this communication?
Thanks again

markus7017 · December 1, 2020, 7:03pm

This looks for me that you are using an older binding version on firmware >= 1.8
Do an upgrade to the latest DEV build

Latest DEV build: 2.5.11 - 3.0.0 - README - Installation - Firmware Index - Firmware Archive - API Doc
fyi: The 3.0 release is behing 2.5.11. Let me know if someone needs a 3.0 build due to new device support etc.

markus7017 · December 1, 2020, 7:05pm

open OH console
enter log:set DEBUG org.openhab.binding.shelly
this writes the output to openhab.log

Is the OH system and Shelly device on the same IP Subnet?
Is it never reflected or after 1min? (regular OH polling)
Please make sure to use the latest 1.9.x firmware. Just a few days ago we had a user with a 2.5 reporting a similar issues. After an upgrade to 1.9.2 it was gone.

rickitaly · December 1, 2020, 7:40pm

Yes Shelly are on the same subnet
Yes after 1 min the the status is reflected
I also rebooted the Shelly, no changes.
Firmware is 1.9.0 on Shelly1 (Latest)

I have to add that i think it is something related to the specific device, because i copy/pasted the configuration to another Shelly1 (all the same, just different IP) and it works perfectly!
What can i do on Shelly side?
Any way to troubleshoot this CoAP protocol?

Edit:
tried also a factory reset of this device, behaviour is the same
Actions on mqtt or physical switch are not reflected to Shelly Binding item immediately but only at next minute refresh.

Thanks!

markus7017 · December 1, 2020, 8:47pm

I checked the firmware index and there is a 1.9.2 for SHSW-1

Did you tried the Web App and Mobile App to check if they offer an update to 1.9.2? Sometimes the detection of a new firmware doesn’t work.

You could also download the zip from the firmware repo and install it with curl

I expect 1.9.2 to fix the issue was we had it with the 2.5 (see above)

markus7017 · December 2, 2020, 8:43am

fyi: On 12/5 we’ll have a Virtual Teamup

The following topics will be presented:

The Past, the Present and the Future
A Tour of the New openHAB 3 UI
openHABian Update
Bayesian Presence Detection
Innovative input devices for openHAB

More information: openHAB Virtual Meetup December 5th (Updated)

Oliver2 · December 2, 2020, 9:27am

Hey Basti,
as I have a few CCT LEDs I reworked your script (and simplified the formula for ww channel) and made it generic so that 1 .rules file works for all CCT LED things.
Just in case somebody else has this requirement

//Generic rule for CCT LEDs
//Usage & Requirements:
//Syntax of Items:
	//Prefix: needs to be constant per Thing.
	val String strSuffixSeparator = "_"				//Separator: 1 unique separator
	val String strSuffixBrightness = "brightness"			//Suffix: at your choice
	val String strSuffixTemperature = "temperature"			//Suffix: at your choice
//4 Items per thing required. Example:
	//Group	gCCT_LED		"All CCT LEDs"
	//Dimmer	LED1_brightness		"Brightness"	(gCCT_LED)
	//Dimmer	LED1_temperature	"Temperature"	(gCCT_LED)
	//Dimmer	LED1_cw			"cold white Channel"
	//Dimmer	LED1_ww			"warm white Channel"
//Items "LED1_brightness" and "LED1_temperature" are proxy items and to be used in sitemaps. Both have to be a member of group "gCCT_LED"
//Items "LED1_cw" and "LED_ww" are litems linked to thing channel. Not required in sitemaps. Do NOT include in this group

val String filename = "CCT_LED.rules"
rule "CCT_LED"
when
	Member of gCCT_LED changed
then
	logInfo(filename, "Item '{}' received command {}",triggeringItem.name,triggeringItem.state)
	var Number iNewCwState										//New value for cold white channel
	var Number iNewWwState										//New value for warm white channel
	val String strThing = triggeringItem.name.toString.split(strSuffixSeparator).get(0)		//Get Name of "Thing", i.e. LED1 or LED2 or...
	val String strType = triggeringItem.name.toString.split(strSuffixSeparator).get(1)		//Get Type (brightness oder temperature)

	if ((strType == strSuffixBrightness) && (triggeringItem.state as Number) == 0) {		//no math required. just switch off
		iNewCwState = 0
		iNewWwState = 0
	}
	else {
		var iBrightness = gCCT_LED.members.findFirst[ t | t.name == strThing+strSuffixSeparator+strSuffixBrightness ].state as Number
		var iColor = gCCT_LED.members.findFirst[ t | t.name == strThing+strSuffixSeparator+strSuffixTemperature ].state as Number
		logInfo(filename, "Setting 'Brightness' to {} and 'White Color' to {}",iBrightness,iColor)
		iNewWwState = Math::round ((iColor / 100 * iBrightness).intValue)
		iNewCwState = iBrightness - iNewWwState
	}
	logInfo(filename, "Changing channel 'Cold White' to {} and 'Warm White' to {}",iNewCwState,iNewWwState)
	sendCommand(strThing + "_cw", iNewCwState.toString)
	sendCommand(strThing + "_ww", iNewWwState.toString)
end

Baschtlwaschtl · December 2, 2020, 10:43am

Nice

rickitaly · December 2, 2020, 5:42pm

Updated to 20201202-135844/v1.9.3-rc3 (just released, according to Support FB improving also this problem) and still not solved

markus7017 · December 2, 2020, 6:40pm

Please provide the log as requested above

markus7017 · December 2, 2020, 6:43pm

I would like to add this to the README is this is fine for you. Could you also provide an introductory paragraph explaining the purpose / use case.

Oliver2 · December 2, 2020, 9:27pm

Markus,
sure it is ok.
Here we go - Use Case:
CCT LED Stripes (or tunable white LED) allow users to adjust the white color (temperature) between “cold white (cw)” and “warm white (ww)”. These LED Stripes have only 3 cables: DC, ww and cw. By dimming these two channels independantly from each other results in the desired white color.
However, Shelly RGBW2 dimmer do not support CCT LEDs.

This is how we can integrate it in openHAB anyway:

Put your Shelly RGBW2 dimmer into “white mode” (“Settings” - “Device Type”)
Connect cw cable and ww cable to any of the 4 output channels
Add thing to shelly binding, create 2 items and link them to the 2 channels, create 2 slider in sitemap

Problem now is, that controling these two channels is uncomfortable:

to set the desired color you need to work with 2 sliders and you need to pay attention that both sliders in sum do not exceed 100%. Setting both channels to 100% will damage your LED CCT
Switching off means to separately set both channels to 0

With the following rule you can control CCT LEDs as usual:

1 slider for brightness
1 slider for color temperature

This rule requires two proxy items

Oliver2 · December 2, 2020, 9:48pm

on the long run, do you think it is possible to include this functionality into your binding, maybe as 2 more thing channels (after they are activated in things settings)?

Baschtlwaschtl · December 3, 2020, 7:38am

I have another rule for not going over 100 percent for both led stripes.
But with the cct rule you don’t need it.

rule "panelcheck"
when
Item thpkwhelligkeit changed or
Item thpwwhelligkeit changed
then
var brightness = (thpkwhelligkeit.state as Number) + (thpwwhelligkeit.state as Number)
if (brightness > 100) {
	if ((thpkwhelligkeit.state as Number) > (thpwwhelligkeit.state as Number)) {
	var tmp = 100 - (thpkwhelligkeit.state as Number)
	thpwwhelligkeit.sendCommand (tmp)
	}
		else {
		var tmp = 100 - (thpwwhelligkeit.state as Number)
		thpkwhelligkeit.sendCommand (tmp)
		}
}

end

markus7017 · December 3, 2020, 3:43pm

BETA firmware 1.9.3_RC3 are released. It’s stable to be used for anyone who has a these issues:

All devices (excluding battery powered)

Slow reaction from cloud, Alexa or Google home. Frequently cloud disconnecting.
HomeAssitant, OpenHab, Homey and other 3-th party integration: Unstable connection and delay responses over CoAP

Shelly 2.5

Special test script is added which should fix disconnecting issue. To see the result you can check: http://deviceIP/status
The result should look:
“arpchk_resets”: 3,“arpchk_results”:0
arpchk_resets: how much time device detect that is disconnected
arpchk_results: how much time successfully restore connection
If this is work we will push the fix to official release.
Shelly Bulb
Sunrise and Sunset scheduling do not change brightness is fixed
Shelly Dimmer1 and Dimmer2
Light is switched off and overpower message appear or there is no error message - fixed.

How to update:
Open device by IP. Update it from Settings -> Firmware update->Bera. You can revert it anytime.

Please note: THIS IS A BETA I would just install it when you are affected by one of the the fixed issues. Please provide feedback if the CoAP issues is fixed or not (as I understood it didn’t solved @rickitaly’s Shelly 1 problem). I’m in direct contact with the Alterco/Shelly QA and could forward the information.

markus7017 · December 3, 2020, 4:02pm

Info from Alterco: “We now add 2xCCD leds support to RGBW2 … should be ready in January.”