Hi all,
since I updated to OH 3.4.1 via openHABian my log is flooded with
[WARN ] [.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.
as well. I do not use thing-files. I already removed the binding, cleaned the OH cache, removed the things, installed the binding again, added the things again, but I don’t get rid of the handler warning.
Any help is much appreciated.
Thank you
I read a few times that physically switching off the machine helped.
That did the trick!!!
THX!
switching off and on also on my side removed the log-flood.
No idea why, but all fine now again.
Hi, I just found out that my openhab instance completely loses outbound TCP connections when the issue appears. E.g. It stops updating the date and time object as well as not being able to send updates to the Shellys. The Debian itself is not affected as I can ping external adresses fine and SSH / telnet is working as well… So thanks for trying to troubleshoot the Shelly issue but it is obviously related to something different.
The handler is already disposed message can be fixed by simply restarting the whole device. Binding reset or openhab service restart doesn’t do the trick for me.
I got 3.4.2 installed, thank you for the hint.
Nevertheless still values get mapped “randomely” to 0 or 100 stillm, see also bug report here.
@markus7017: are you probably already working on support of Shelly Plus Smoke Alarm?
https://www.shelly.cloud/en-bg/products/product-overview/shelly-plus-smoke
Good morning!
Has anyone tried to use the range extender functionality of the current generation of Shellys?
I read that when using it, both the device acting as range extender and the device connecting to it would be accessible via the same IP but different ports. Would the binding support such a setup?
So far I cannot get it to work, but that seems to be a different issue, because I can’t even access the device connecting to the range extender in the Shelly app and do not really know how to troubleshoot that.
Hello, I have a question regarding this binding and battery operated shellys.
For example, shelly motion or TRV.
The devices go into sleep mode and commands are not sent sometimes.
shellymotionsensor-60a42386d716: FEHLER: Der Befehl 2 für Kanal shelly:shellymotion:f76253bbaa:sensors#sensorSleepTime kann nicht verarbeitet werden - API Timeout for GET http://192.168.0.225/settings?sleep_time=3
Is the command sent again or is it simply ignored after the timeout?
How can I be sure that a - for example - temperature change for a TRV has also been adopted.
Greets
I don‘t really know how the binding handles this internally, but can say that my TRVs did not miss any temperature change.
I can confirm this.
For TRVs the binding works perfectly.
Unfortunately, this is not the case with me.
shellytrv-60a423d92dd4: FEHLER: Der Befehl 22 für Kanal shelly:shellytrv:TrvBad226:control#targetTemp kann nicht verarbeitet werden - API Timeout for GET http://192.168.0.226/thermostat/0?target_t_enabled=1&target_t=22
There is a ‘window_open’ action in the TRV which isn’t included in the binding.
I wrote a shell script to send the action with check of the answer. And sometimes the script run twice to set the window open/close state.
Maybe @markus7017 can say something about that timeout behavior.
Greets.
Is CoIoT enabled?
Yes
I don’t want to interrupt the discussion but can anyone suggest a configuration for a dw2 sensor that does not drain the battery like crazy? I installed three of them not long ago and thought they broke after two months or so because they did not react anymore but the latest battery level was still at about 60% (which was really bad already). However it turned out that the battery was just too low to wake the device…
Does it make sense to invest in another set of batteries or should I just dump them completely 
Mine have longer life. I have 8 pieces DW2. This one as an example is after 1 year at 91%.
Settings (bold marked are important):
Tilt: enabled
Vibration: enabled
Wake Up By Lighting: disabled
Temperature Treshold: 1.5
no I/O + Sensor Actions
static IP address
current firmware v1.12.1
Batteries: CR123A Kraftmax Pro, 20 pieces for about 30 Euro.
Hi all,
my Shelly Manager doesn’t work anymore.
The screen message in the browser is:
„Exception:java.lang.NullPointerException
Check openHAB.log for details.
[Return to Overview]“
But there isn’t any information in openhab.log and restart didn’t help.
Any hint appreciated.
Which binding version are you on? I recommend dev version which is available here.
Markus might not be that present here anymore and there are definitely reasons for that (e.g. working on a new beta) but the latest dev version was created last week.
Hi,
I installed a Shelly RGBW2 yesterday to replace a Gledopto RGBW controller. The Gledopto worked nicely in conjunction with a Conbee II stick inside openHAB but it dropped off from the Zigbee network in a non-reproduceable way so I decided to go for a WiFi solution.
Now, I made some observations from which I am not sure if they are even bugs:
1. Sending HSB value whereas B=1%
When sending a command like that to the RGB channel:
val String hsb = ("29,74,1")
Farbe_Bett_RGB.sendCommand(hsb)
with the item
Color Farbe_Bett_RGB
"Farbe Bett RGB"
(Bett_RGB)
{ channel ="shelly:shellyrgbw2-color:<ID>:color#hsb",
homekit="Lighting.Hue, Lighting.Saturation, Lighting.Brightness" }
The light does not turn on although even the web page shows it is switched on:
It turns visibly on when sending a brightness value higher than 10:
val String hsb = ("29,74,11")
However, I can use the slider on the shelly web page to put the RGB channel brightness to 1% and then it works.
With deconz it was not problem using values like 1% brightness. Is there maybe an issue in the API of Shelly?
2. Reducing brightness of color channel to 0%
When I reduce the brightness of the colored light via the slider inside the homekit the color changes also and when switching on the light again it is set to a weird value:
Situation before dimming to 0% brightness in homekit
The events.log shows:
2023-01-25 09:25:07.205 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Farbe_Bett_RGB' changed from 0,100,49 to 0,100,0
2023-01-25 09:25:07.231 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Farbe_Bett_RGB' received command 0,100,0
2023-01-25 09:25:07.232 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Farbe_Bett_RGB' predicted to become 0,100,0
2023-01-25 09:25:07.566 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Farbe_Bett_RGB' changed from 0,100,0 to 0,0,0
(...)
2023-01-25 09:25:26.973 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Farbe_Bett_RGB' received command 0,0,49
2023-01-25 09:25:26.974 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Farbe_Bett_RGB' predicted to become 0,0,49
2023-01-25 09:25:26.978 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Farbe_Bett_RGB' changed from 0,0,0 to 0,0,49
Why is not the previous red light?
3. When setting brightness to 0 in the white channel and the color channel was switched off, the color channel is switching on
So, when I only have the white channel switched on and I turn down the brightness to 0 sometimes the colored light switches on to maximum brightness based on the previous color.
Is this maybe due to the fact that the RGBW2 handles both channels (white and color) whithin one power channel?
In deconz both light types were handled as two different lights. A white light and an RGB light which I could also handle separately in openHAB and thus also inside homekit.
The fact that the power channel is for both lights makes the handling it a bit weird.
In case both lights are turned on, how can I turn off one without turning off the other one?
I tried some synchronization mechanism but it does not really work as expected:
Switch Bett_LED_OnState // Shall only be switched off if both lights have been switched off
{ channel ="shelly:shellyrgbw2-color:<ID>:control#power" }
Group:Switch:OR(ON,OFF) gBett_OnState
Switch OnState_Bett_RGB // This is used to show the state of the RGB light in homekit
(Bett_RGB, gBett_OnState)
{ homekit="Lighting.OnState"}
Color Farbe_Bett_RGB
"Farbe Bett RGB"
(Bett_RGB)
{ channel ="shelly:shellyrgbw2-color:<ID>:color#hsb",
homekit="Lighting.Hue, Lighting.Saturation, Lighting.Brightness" }
Switch OnState_Bett_Weiss // This is used to show the state of the white light in homekit
(Bett_Weiss, gBett_OnState)
{ homekit="Lighting.OnState"}
And the syncing rule:
rule "Lichter-Schlafzimmer: OnState synchronisieren"
when Member of gBett_OnState changed
then
val command = if(gBett_OnState.state == ON) ON else OFF
if(Bett_LED_OnState.state != command) {
Thread::sleep(500)
Bett_LED_OnState.sendCommand(command)
logInfo("Lichter-Schlafzimmer: OnState synchronisieren", "gBett_Onstate changed to " + gBett_OnState.state)
}
end
I am using openHAB 3.4.1 Release Build and would really appreciate your support here.
Many thanks,
Oliver