Hi,
Thanks for the rapid response
No, I use the Supervised version of HA so never got round to it.
I did MANY MANY years ago have a proxy running as back then it was the only way to get Lightwave running, I may if I get time look back and see if I can run-up another Pi (unless you have a better suggestion)
I could send a version of the proxyless code over, if you want to try it.
You have to install manually in the custom_components folder.
It works on my live system, but am seeing issues in my development version due to a race condition.
So no idea how well it will perform (until I find time to fix the race condition).
Yes that would be helpful, am not sure what you mean by race condition but I would be happy to provide feed back on my system performance (8Gb RPi 4). I may need some basic guidance on installation
Here is the code I am using for proxy-less operation in my live environment…
There is a known issue - you may see error messages in your logs when trying to turn switches on/off or change a TRV setting. However 99% of the time the operation will have worked - the error is incorrect. I am working on a resolution.
Once resolved I’ll make a PR into the main HA integration.
Thats Great, all working including the errant TRV, and yes I get the error as described in the logs.
A couple of questions.
the actual sensor (sensor.room_heating) what is this ? I assumed it was battery percentage but it seems odd as I get readings from 93 to 142%.
If this is not the battery sensor is there a possibility of adding it ?
Many thanks for the great assistance
That’s good news. I’ll post here when I fix the error messages (not high on my priority if I am honest - a rainy day job).
The sensor is a guess at the battery level, based on the voltage reading. I occasionally see 110%, but never as high as 142. It’s not a great measure but does give the ability to detect when they may need changing. I have an automation that pops an alert when less than 30%
@Hunterdiver I think I have fixed the error messages.
If you download the latest version form my temporary repo and give it a try, I’d be most grateful.
Im away for a coupe of days ut i will give it a try when i get back to the home base .
i am using all new lithium batteries which may explain the high percentage shown.
Installed OK and so far no errors showing up in the logs, Battery sensors still showing high. Thanks for the updates.
I may have found an issue. It appears to conflict with the Lightwave Energy Monitor from HACS, I noted that it had (Monitor) stopped reporting, and a quick look showed it stopped around the same time I installed your test files.
I removed your files from Custom Components and the Monitor started reporting again.
I replaced your files and the monitor stopped working …
I don’t use the energy monitor, but I can see there being a conflict if it also listens for UDP requests. Both are likely to use the same TCP PORT to listen on.
The monitor guys will probably need to make a change to set the socket option to reuse the port.
Do you which GIT repo their code uses, we can raise an issue and suggest a fix.
is this what you need ?
Thanks, that is what I needed. I have logged an issue with them.
I believe the following change would resolve the issue - but I cannot test.
If you can change custom_components/lightwaverf_energy/sensor.py as follows it might get both working,
From
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(("0.0.0.0", 9761))
To
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
sock.bind(("0.0.0.0", 9761))
I have changed the file as suggested, I tried inserting the Middle line and restarted this did not work.
I then copied all 3 lines over the existing 2 (just in case) but it still did not work.
Oh, I was hoping it would :-).
I going by guesswork, maybe the BROADCAST line is needed too, but think this is clutching at straws.
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 9761))
If this does not work, then we have a fundamental problem that the two cannot work together.
They both try to get the broadcast network data on the same port used by the Lightwave hub.
I don’t know enough about Python threading, but had hoped the SO_REUSEPORT option would allow both to get the data - but your tests suggest not.
The resolution would be an update to GitHub - GeoffAtHome/lightwave: Reliable communication to LightwaveRF hub. to provide a single universal UDP listener for both to use, with some kind of callback. Quite a bit of work, and at the limit of my current Python knowledge. Would also require collaboration from asantaga (Angelo Santagata) · GitHub (and any other Lightwave custom_components providers).
I’ve added the extra line and sadly no luck…
I thank you for all your help, and guess I’ll have to wait for folks wiser than I to see if a solution can be found, For now the TRV info is more useful than the monitor :).
If I can be of any help in the future (for anything) please feel free to give me a shout …
Bill
Ah… an update… we have success and I may be to blame for it not working initially.
I have been commissioning a new HA server and forgot to remove the LW components from my old server.
once I had done this I started to get the data back from the Monitor.
I’m going to remove the 2 additional lines and see if the problem re-occurs.
will update shortly
Hi,
I can confirm that I/We need your first fix as this works now.
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
sock.bind(("0.0.0.0", 9761))
I now have the Monitor reporting and the TRV’s working.
My appologise for forgetting my old HA server and thank you again for your help.
As before please let me know if you need any assistance
That’s great news, thank you for your persistence in trying the fix.
This is now integrated into HA 2023.6