OK, messages seem to be gone for now. I removed the binding again then I temporarily removed the *.things file containing all Shellys. Then re-installed the binding. Then I got no error messages.
Then I made the *.things file available again and now all things are back without error messages (so far).
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.
1 Like
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.
1 Like
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.