Hello,
Are there any plans to implement support for LightwaveRF thermostat radiator valves (TRV) (gen 1!).
For info, I created my own integration…
https://github.com/ColinRobbins/Homeassistant-Lightwave-TRV
2 Likes
Hi Colin - first up great work, I found your integration and have been trying to get things running, I’m having a few issues and wondered if you could advise at all?
I run a Gen 1 LWRF hub - but only use it for a number of TRVs plus now and again control plug in sockets (for Xmas lights). The key integration for me are the TRVs which you’ve written the proxy for.
I have HA running in a docker container (probably doesn’t matter but for info), I’ve downloaded your proxy and also have this running in a docker container on the same server as HA. The config is as below…
lightwave: host: 192.168.86.93 (LWRF box) trv: proxy_ip: 192.168.86.30 (proxy location, same server as HA) trvs: R8D1: name: Spare Room TRV serial: CC11CC <-- Looked these up from App R3D1: name: Kitchen TRV serial: GGJJGG
I’ve created the above config for two TRVs (they appear in HA) and started the proxy using the -v verbose option.
It seems to be running but there doesn’t seem to be much happening.
I found the new entities in HA after starting - but they don’t seem to be showing temperature, which suggests the proxy isn’t correct? There don’t seem to be any log issues I can find.
So a few questions to hopefully help me track it down and validate my understanding.
- When in the verbose mode should the proxy log anything more than this Starting UDP servers: 127.0.0.1:7878 & 0.0.0.0:9761?
- I understand the proxy is listening to UDP traffic - is this traffic that the LWRF hub is broadcasting, so essentially you’re listening for broadcast traffic from the hub.
- Can I use the above config with only TRVs? I read something that suggested I must have a switch or light configured?
- Where did you find the RxDx - did you get this from LWRF or is it something HA is using - I’m not sure I have this right if it’s from LWRF.
- Once the integration is working am I able to see the current temp and set it from HA devices/entities?
Many thanks in advance, I really hope I can finally get LWRF working with everything else in the house better than I’ve ever been able to previously.
Yes, it should show you the traffic it receives from the broadcast.
So, not seeing anything is probably the challenge here - looks like you are not capturing the broadcast packets.
Are you on the same network subnet as the LWRF hub?
You could try running
ncat -luv 9761
to make sure you are seeing the lightwave broadcast traffic.
Correct.
I think this bug was fixed. If HA starts, and the TRVs are showing as climate.spare_room (or similar), it suggests the config is fine.
This is a bit of black art. it’s used to adjust the TRV. If you are not seeing temperature in HA, then this is not your issue.
The magic number comes from Lightwave, but nowhere in the app, or their web site can you find it. You can have 3 options.
- Guess. The first room you ever added will be
R1D1. The nextR2D1. etc - Handcraft an
ncatrequests and get it out of the API (advanced!) - email their help desk - they seem to be able to get it from somewhere.
BTW - changing a TRV temperature from HA should work, even in the proxy is not capturing the broadcast data.
Yes.
Are you seeing anything in the HA log?
I’d expect an error about not being able to get data from the proxy?
Thanks for getting back to me so quickly, I’ve been able to progress this afternoon and found exactly what you say above - the proxy wasn’t seeing the broadcast traffic. I’ve been able to resolve that by running the proxy in the same container as HA, not 100% sure why this made a difference.
I also was able to get around the auth process by digging out some old plug in switches and use the controlling of those to trigger the auth process.
So I’ve now got to a position that I can control an off/on switch from HA and get current status of TVRs in the HA UI. However I can’t seem to trigger a temp change from HA - I’ve spent quite a bit of time sniffing network traffic today on UDP protocols, but not sure I have the IDs for the TRVs correct. Changing the temperature in the app causes a UDP message to be broadcast that has a room number - so I’ve assumed that they are correct. However given that I can’t alter the temp from HA I’m not so sure.
I wonder if I could ask a couple more questions that may help me narrow it down?
I can control a switch in a room identified as R1D1 this room also has a TRV, however when I look at the sniffed traffic I see it identify as Room 3. So according to your pages this should be identified as R1Dh?
If the identifier is incorrect would this stop the setting - while getting would be fine?
Also, if you have two TRVs in a room what would you expect the RxDx to be?
Once agin thanks so much for you very fast response earlier! If you’d like I can write this up for future reference?
If the TRV and switch are in the same room, the I’d expect the R number to be the same. So R1Dh.
Without wishing to seem flippant, if that does not work, try R3Dh.
Yes - to set the temperature, the R1Dh parameter is used to identify the TRV.
It this is wrong, it won’t work.
Are you seeing anything in the HA logs ?
OR it could still be an auth issue. You may need to run the auth from same container as HA. If you are familiar with ncat you could try:
echo -n “123,\!F*p” | ncat -u -v LWHUB_IP_ADDRESS 9760
Then press the button on the hub.
Sorry, that I don’t know - not a scenario I have come across.
I have in the past found the LIghtware support desk helpful - usually a next day response.
Hi - thanks again for the fast responses, I’ve cracked it, I needed to know those dependencies on the codes and IDs. It looks like a container issue, when I ran the proxy inside the same docker container as HA they shared the host port and IP, it look like the calls out to LWRF were being blocked by the proxy (but oddly not responded too). I’ve created a second container and forced a static IP on it (outside of the normal DHCP range) and pointed HA at that static address.
The SET calls are now going out to LWRF, the proxy is seeing the broadcast UDP traffic and HA has a dedicated IP address for the proxy. I’ve enough networking knowledge to be dangerous - so am struggling to understand the initial failure reason.
Anyhow - that’s your code code appearing to run nicely in Docker containers on a QNAP NAS, I’ve tried one TRV and the setting worked (with the odd RxDx setup). Will test more tomorrow - but at least I now know what I’m looking at.
Once again, many thanks for the Plug-in work and your help today!
1 Like
Hi Colin - sorry to bother you again but could I check one more thing with you?
I’ve got the integration working quite nicely, however, when it comes to controlling the TRVs from scripts or automations I’m failing badly. If I use the TRV control in HA to change the temperature this works, however if I try to do this in an automation it seems to ignore it (temp doesn’t get set on TRV and so reverts in HA on the next update from TRV).
I’ve also tried with with using the call service to set hvac mode etc. but non seem to have ay effect. Am I missing something? Should I be able to set temps and states from automations?
Many Thanks, Rob
Yes, I use automations.
Here’s my action…
action:
- service: climate.set_temperature
data:
temperature: 20
entity_id: climate.bedroom
I use it to replace the Lightwave call-for-heat.
I have recently moved to Home Assistant OS, which make running the LW proxy difficult on the same computer.
So I have set about removing the need for the proxy, with a direct integration into HA.
Anyone able to test it?
You need to create a custom integration with the files below in your config to override the built in integration.
Library update: Integrate UDP Listener, removing need for Proxy by ColinRobbins · Pull Request #8 · GeoffAtHome/lightwave · GitHub
HA updated branch: GitHub - ColinRobbins/Home-Assistant-Core at lightwave
HA Version 2023.2.0 removes the need for a TRV proxy. The capability is directly integrated.
Hi,
I have been using LWRF for a while for my lights and sockets for a while, and have tried a few times to get the TRVs to work with little success.
A few days ago I took another look and found you no longer needed a proxy so tried again and found all but one of my TRVs, however they contain no data, BUT i can control them from HA.
I get the following message in my logs…
Logger: lightwave.lightwave
Source: components/lightwave/sensor.py:55
First occurred: 17 March 2023 at 16:25:19 (9544 occurrences)
Last logged: 02:22:04
TRV proxy not responing.
I have tried with the proxy line in config active and commented out but still no luck
As for the missing TRV I contacted LW to confirm its ID and they say its ( !R2DhF*tP18 ) I had it as R2Dh originally as that is what I worked out, I have tried all variations of the above (the serial No is correct)
Any pointers on the Proxy issue would be great …if you have a clue about missing 1 out of 8 TRVs that would be awesome
Hi,
You still need the proxy.
The new code for a proxyless system had to be rolled back due to issues, I hope to re-release a proxyless version soon.
Do you have the proxy installed?
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.