I am setting up OH3.
I have plenty gen 1 light switches (1,2,3 and 4 port) - but seemingly no ay to directly manage via OpenHab.
As a stopgap solution (and since Gen 1 switches don’t report status anyway) I am simply using the Alexa control Binding to identify the Lightswitches and controlling them via the Alexa binding
The downside is the cloud dependency, but at least it gives me a way to start porting my code over to OH3.
I am using the same approach to manage my Nest Thermostats, since it seems the Google Nest appraoch is to try eliminate home hobbyists from using their tech.
Irrespective, if the binding needs testing at some point, I am happy to help
Hi Dave
Ive moved my system over to OpenHab 3.2 and have an issue that some items on the TRVs dont update very often (even if you have sent a new TRV target temperature), The battery for example can sit with NULL. If I re-link the battery item then I get a value but at the next restart it can be the same and not update.
In my previous version of OH 2.5 I used a things file where polling was defined for the Bridge and I did not have this problem. Can polling be set up through the UI ?
(im using org.openhab.binding.lightwaverf-3.1.0-SNAPSHOT_3.9.jar)
regards
Kevin Oliver
Hi Dave
All had been working well until recently and wanted to know if you know why things may have changed.
My TRVs work fine afer a reboot but after a few hours they stop working properly
I enclose a debug output with some explanations if this helps.
I believe this is a Lightwave issue, the websocket stops sending updates after some time, the connection stays open and will accept state changes, but no state notifications are recieved until the connection is re-established. The lightwave web app suffers from exactly the same problem.
Hi xela
If it was purely a lightwaverf thing then why does restart the binding then make it work ?
If I just start the binding surely thats not impacted the lightwaverf box ?
It’s not a local API, the binding connects to the lightwave hosted API which then sends an event for every state change. When you restart the binding, the connection is re-established
In the DEBUG file I sent I do see a disconnect and a reconnect , i cant say for sure that it was working all the time right upto the disconnect but it appears not to work after the reconnect.
But a hard reset via the bundle:restart does make it work again.
I think lightwaverf have probably updated my box with their latest firmware and that this may be the reason its now stopping after a period
Very timely, I popped on here earlier today just to see if an issue had been spotted by anyone else and didn’t see a mention, then a couple of hours later you post!
Recently (sometime in the last 2 or so weeks), state changes made physically on the sockets/dimmers or via the Lightwave App have setopped getting reflected in OpenHab.
As you have seen, restarting OH or disabling the Account thing and enabling it again, gets it working for a bit but not very long.
The main issue I have is that I was using a spare dimmer gang as a physical button to trigger an OH rule and it was working perfectly after I set it up for a while and I have never had issues with the state changes not reflecting accurately before (well the odd couple of times a year but no LWRF actions worked those times either).
Happy to grab logs or try anything out if that will help.
Hi Paul
Yes it’s useful to know I’m not the only one seeing this problem. I don’t know if Dave will see these postings as he is the developer of the binding. He may be able to find a work around as I shown it does work if you just restart the binding. But it probably a change on the Lightwaverf server that’s causing the problem
I’ve been playing with restarting the binding with a rule every so often (via the REST API) which seems to work half of the time, but at some point when enabling, it gets stuck and it just sits in the INITIALIZING state until eventually going to an ERROR.
Doing bundle:stop and bundle:start or disabling through the UI doesn’t get it working again and it actually it seems to cause issues with lots of other OH activity (unrelated things that rely on remote API calls don’t seem to get their updates even).
The only fix at that point is to restart OH itself, so I don’t think this is even a viable workaround.
Just thought I would post that in case it helps in any way, otherwise going to keep trying to see what I can do, but it’s pretty limited.
Hi Paul
I raised the issue with Lightwaverf and they claim that they have made no changes so we won’t get any support from them. I see David hasn’t posted since December so it looks like we are stuffed. Ive downloaded the developers environment and eclipse but this is a new setup for me and so far with only limited attempts I’ve been unable to get any Adons to compile.
How do we want to handle this for the mean time? I can add a reconnect in every x minutes for instance. @xela i know you been looking at this, any pattern yet?
just added a quick fix.
monitors the websocket every 1 minute.
You can set how often in minutes (account config) you want it to wait with no data before restarting the websocket.
Added an info log every minute for now to show how many minutes its been without a message.
havent got to the point of it actually disconnecting yet so limited testing
3.3/3.4
I just don’t have the time any more to maintain 2.x.
It’s not a bad experience upgrading, prob a few rule changes for time stuff but other than that I had no real issues
Thanks @delid4ve I’m on 3.3 at the moment so just updated the binding and will test it out.
I hadn’t seen any patterns before but is there anything in particular that you would like us to keep an eye out for or check if we see the issue?
Does it also log when it needs to take action and restarts the websocket?
For example, I just saw it get up to 11 minutes since last message and then might have disabled the account but it might not have started it again.
Could just have been something else because I was playing around but left the default 10 mins before restart, so it does seem to line up.
EDIT: This has happened twice now, exact same log messages. The LWRF Account turns to OFFLINE so I had to disable it and then enable it again manually.
2022-07-23 09:12:47.230 [INFO ] [ndler.LightwaverfSmartAccountHandler] - 10 Minutes since last websocket message
2022-07-23 09:13:47.232 [INFO ] [ndler.LightwaverfSmartAccountHandler] - 11 Minutes since last websocket message
2022-07-23 09:13:47.235 [WARN ] [onnections.LightwaverfSmartWebsocket] - LightwaveRF - Closing a WebSocket due to binding shutting down
2022-07-23 09:14:47.248 [INFO ] [ndler.LightwaverfSmartAccountHandler] - 12 Minutes since last websocket message
2022-07-23 09:15:47.250 [INFO ] [ndler.LightwaverfSmartAccountHandler] - 13 Minutes since last websocket message
.................repeated until 28 Minutes when I disabled and re-enabled the LWRF Account manually
Other times it’s got up to 3 or 7 then goes back to 0, so I assume that would be expected and anything over the restart value would have automatically been the restart.
