I have been running my system for about a month. Regularly it will not switch on for entire evening (17:30-23:30) but runs ok next morning.
I’m logging all the LAN broadcasts and hoping for a clue.Lightwave Link (930) + 10x TRV (922) + Thermostat + Boiler Switch- London, UK
Getting cold again and same issue has reappeared. Anyone using call for heat?Lightwave Link (930) + 10x TRV (922) + Thermostat + Boiler Switch- London, UK
I bought the Lightwave TRV system substantially because I wanted Call for Heat. However, it doesn’t work, it has never worked and Lightwave support staff agree that “there is a problem” (translation: it doesn’t work). I live in a large house and I only want to heat the parts I am using at anyone time. Also for medical reasons I have to sleep in a bedroom with a very even temperature, so I want the heating on all night, but I don’t want the boiler running when I don’t need it. A boiler running, but all the rads at 0% output is surprisingly expensive, 80 watts for the pump and a lot of gas.
I have 12 922 TRVs, a 930 link and a 934 boiler switch (actually I bought two because with call for heat each switch can only have 8 TRVs attached) but now I only need one.
I was unhappy with the Lightwave call for heat as described (even if it had worked) because it fires the boiler based on how far short of current target the TRV current temp. is. That seems silly to me, I think it should on the percent output – if the rad is open, fire the boiler, if not this rad doesn’t need the boiler on.
So, being a techie I wrote a program in C that runs as a server on my Linux server. I have an ASCII file (flat file) listing my TRVs + Boiler switch with their serial numbers. The program listens for the UDP status broadcasts from the TRVs and records the data in my flat file. It monitors the percent open of each TRV. Each TRV is tagged as Controlling or not – I don’t want to fire the boiler for the hall radiator; if the boiler is on it can have some, if not then too bad. Now I can see the not only the temperature for each rad, but also the voltage of its batteries. TRV communication with the link becomes unreliable at 2.48 volts, so they need recharging. The Lightwave web app will still show them as OK (not red) on that voltage. Another thing about the web app; the Zigbee comms between the TRVs and the link is shout with no handshake and unreliable. Using the web app you have to check that it actually happened. Even if you get the green acknowledgement box, it often hasn’t actually been done. It is seriously frustrating.
I have configured my program so that if any of my Controlling rads are 20% open, the boiler fires. I have checked, and overnight only my bedroom rad is at more than 5 degrees target, and on the coldest nights it only fires the boiler 25% of the time. The room temperature remains stable to within 1 degree.
I also made a TCP/IP client (that talks to my server program) which allows me (using a CLI interface) to set the temp. for each rad. As the UDP interface to the TRVs is unreliable (see above), it will keep trying until the change is successful. I am developing this to rooms. For example, my lounge has two rads. The one on the outside wall should be set to .5 degree less than the desired temp. because it is in a cold area behind the sofa, whereas the other has the TRV in a little micro climate next to the side-board. It should be set 1 degree higher. These biases are listed in my flat file. So I am able to run the command with “lounge evening” and automatically arrange the rad temps to give me 22 degrees. I also can run “bedtime”, which will set all the day time rooms to 5 degrees and set the bedroom to my night time temperature. As an extension I can say “bedtime 30 mins”, which starts the bedroom rad now, and will switch off all the others in 20 mins (no pointing in heating the last 10 minutes). As I am a night owl, this is very useful.
Hello Emrys, Thanks for the reply. Glad its not just me.
My system/call for heat is working most of the time but still requires continuous watching and ocasional intervension.
My problem was potentially lots of things needed heat at 17:30 and a clash made the system think the boiler was on when the command was lost.
Thinking that the boiler was on it would not send the ON again until after it send the an OFF command (usually arround 23:30). I could see via the UDP packets failing to ACK and retrying but no second attempt to ON. Fixed by moving the thermostat within a few feet og the Link, so communications were 100%.
To get call to heat working do not touch thermostat settings ever again, delete call for heat group and re-add it.
I also note that a valve can go to 10% which causes the boiler to run, but I suspect the plunger does not move enough to actually let hot water run.
However it never goes to 20% so the boiler stays on until the sun warms the room. Power reset resolves also.
TRV plunger gets stuck on or off but still reports temperature battery posution ok. Power reset needed.
If I want to force boiler OFF/ON via web I move thermostat temp to 5C or 28C and SET it (numbers help my logging) next TRV event will resume normal opperation. This appears not to change thermostat config or upset CFH.
I have considered doing my own software but keep putting it off (RPi with Python or PHP)
I use Energizer ultimate lithium batteries which i change <2.5 volts as below that they fail to move plunger but still report in. They last 3-4 months.
think thats about itLightwave Link (930) + 10x TRV (922) + Thermostat + Boiler Switch- London, UK
I recently got the whole setup with understanding that we’d depend on the CfH functionality. Last night was the first night where everything was set up and I expected it to work but it didn’t. Perhaps I’ve missed a step?
I’ve set up the TRVs in three rooms, the boiler switch replaced the old thermostat in the hall way and the LW thermostat is in the living room. All devices are linked up to the Link Plus L2 and can be controlled from the app successfully.
I’ve set up a schedule for the thermostat (in the living room) via the Android app such that it targets 22°C from 8am to 10pm, then falls back to 10°C.
The TRV in the bedroom has another schedule such that it’s warm in the mornings and evenings for the kids, and maintain a reasonable temperature through the night.
I haven’t done any packet captures yet, and I’ve only just reached out to support, but I’m wondering whether any of you have figured out how to set up the parent/child relationship. @emrys-jones – is your implementation using this approach or are you entirely managing the logic on the server side? @crivvens – did you do something other than link the devices and set up a schedule?
There’s nothing about the usual steps to link each device to the L2 that suggests the parent/child relationship is configured explicitly, and there’s no apparent options in the Android app nor the Web app to do this either, as far as I’ve been able to see. I have noticed that the Link and Link Plus apps and interfaces are very different, so perhaps it’s just not yet available in the Link Plus environment yet?
I’d really prefer not to craft my own UDP packets for this purpose :/
Link Plus (L2), Thermostat (LW921), Boiler Switch (LW920), 3x TRVs (LW922)Link Plus (L2), Thermostat (LW921), Boiler Switch (LW920), 3x TRVs (LW922)
Hello ixido, As i understand the Link+ does not yet support call for heat. I have the older Lightwave Link (930) and confighte it via the web manager https://manager.lightwaverf.com/
I have both Links and fell back to the old one around May 2018 to get my setup working – have not played with the Link+ since.Lightwave Link (930) + 10x TRV (922) + Thermostat + Boiler Switch- London, UK
In reply to crivvens and ixido:
When I first tried call for heat I needed two switches for 13 TRVs, intending to connect them in parallel to control the boiler. But having discovered that the TRVs were not too reliable on my Danfoss valves, and being an engineer, I tested it all out on the bench. The Danfoss valves were not a problem, they were getting old and I had experienced failures with both types, so I bit the bullet and replaced them all with Myson style ones from Screwfix.
My experience is that the software in the TRVs is very good and I suspect it was written by the engineers who built the valve. The Link software and all their ‘server’ software feels like it was contacted out and they don’t really have it under control.
My initial test showed that call for heat worked in reverse, when any of the TRV on a switch called for heat, it turned the switch off, when none of them needed heat, it turned the switch on. I authorised Lightwave support to play with it, and they did. After that there was no rational pattern of behaviour that I could perceive. The original state could have been made to work with some relays, but, frankly that is too far from spec. to trust. The change to behaviour follow the Lightwave intervention deepened my distrust.
That is why I decided to write my own. It replaces functionality in the link that doesn’t work, it also gives me functionality that I can sort of do on the Android App or the Web interface, but in both cases the UI is clumsy and the functionality falls well short of what is wanted. Putting it bluntly, I don’t want to mess about with silly dials, have to referesh to make sure it happened, do it again, and do that for both rads in the room, I prefer to type “heating k set 20″ and know that when the command comes back without an error it has set both kitchen rads and I am finished.
It also gives me a full log, I can see what happened and when, if the boiler is on and why, if a battery is going flat quickly (that usually means it is in a draft) etc.
@crivvens: indeed, you’re correct. This is the reply from support today: “Unfortunately this feature is not available for the link plus platform. This is something that the development team will be looking to integrate in to the link plus client in the near future but at present is unavailable. ” I have asked for an ETA, but considering it’s nearly a year since you switched back, I’m losing confidence and considering returning the whole set up in exchange for a competitors.
@emrys-jones: i totally agree i’d like something reliable and CLI is fine. Have you considered publishing your app on github or similar? I’m no C dev, but would very much like to have a go at trying it against the L2, though I suspect based on the feedback from support it’s unlikely to work.Link Plus (L2), Thermostat (LW921), Boiler Switch (LW920), 3x TRVs (LW922)
ixido: My stuff is very new and a bit beta. Put my post up partly to see if anyone said “Why? You should be using …”. I have no objection to sharing, but it’s still littered with commeted out printfs (the hallmark of serious debugging).
It should work for the Link+ with a bit of tweaking. It doesn’t use the Lightwave Call for Heat stuff at all, it completely replaces it. The Link+ offers the same UDP API with some variations in syntax. As far as I can remember those are fairly minor and the code if built to deal with changes. As I don’t control what Lightwave do, I the code is built to deal with changes that they might make. I will look into that in the next few days.
I want a few more days to polish it all up, then I can send you a copy by email. I suspect it will run on a Windows box using Cygwin. As it’s not commercial there are no licence problems
@emrys-jones: great – would really appreciate the share when you’re ready as the lack of CfH is pretty much a show stopper. I’m primarily a linux user so no issues there. I believe GitHub and GitLab both support free private repos now so that could be a channel for collaboration. Keybase repos are also an option.Link Plus (L2), Thermostat (LW921), Boiler Switch (LW920), 3x TRVs (LW922)
I have a question in to Lightwave support on how do I force the TRVs to do a statusPush (or whatever) so that I can initialize my record of the state of each TRV on program start up. At the moment I just have to wait for each one to decide to send it. That works, but it’s not good.
There must be such a facility, because the Web interface uses it. I guess I could investigate it with packet snooping but I would rather have an official answer. Anyway, packet snooping is extremely tiresome on a busy LAN.
You must be logged in to reply to this topic.