LightwaveRF Heating Controls


I’m looking at getting the LightwaveRF heating controls (home thermostat and boiler switch). Is it possible to integrate these with openHAB?

I see that the radiator valves can be polled and controlled but I’m not sure whether the “whole house” heating controls can be used the same way. Anybody tried it?


I wrote the binding for Lightwave and I use the radiator valved. I don’t have the whole house stuff so not sure what else it can do.



If I get the whole house heating kit, I’ll try to do some reverse engineering to see if the binding can already handle it. If not, I’ll try to work out the protocol and let you know in case you want to incorporate it.

At the moment I need to check out how the heating zoning works in my new house. I have two heating zone values but both driven off the same programmable thermostat. I’m only going to buy a lightwave stat if there’s an advantage to splitting the zones.

Turns out the zone values split the ground floor from the upper two floors. I was hoping that the split would be between the top floor (where the study is and doesn’t need to be heated all the time) from the lower floors, which are the rooms that need to be heated morning and evening.

I am back to looking at the individual rad valves so thanks for the binding for those.

A few reviews say the rad valves are noisy - anyone have any experience of that?

They are really noisy but I bought some lubricant and a special screwdriver to open them and now they are fairly quiet (i.e. aren’t too annoying in a bedroom) but I have nothing to compare them against…

I bought one to try. It is a bit noisy so I like the idea of lubricating it.

When I fitted it, it failed calibration with the error light flashing, however it seems to work fine both with the app and with openHAB. I’ve raised a support request to see what the error light means. If it’s not a problem, I’ll get some more.

Have you considered retrieving the “output” parameter so openHAB can access the position of the valves as well as the current and target temperatures?

Also having second thoughts about splitting the zones in the house so I might end up with a home thermostat.

I’ve not looked at the message recently so it may have changed but when I did there is no parameter for the valve position. Instead it encodes it in the temperature - if you use the app to set a valve position then a “temperature” of 50 is closed, 51 is position 1 etc… you can easily make a SetPoint item that only sends 50 etc to the valve to do that.

If it helps…these are the tools I used to make it quieter.

To do it - I took the battery out and I opened up the four screws on the back.

Then once open laid it down and reinserted the batteries whilst it was calibrating I oiled every moving gear I could see being careful to touch it as little as possible.

It’s a fairly quick job.

Thanks for the link to the screwdrivers.

There’s a parameter in the message called “output”. From the app, it looks like a percentage related to how open the valve is.

If you can run some tests to confirm that then it should be easy to add in.

Mine always seems to go from 0 to 100 most of the time but I do see a few that are not those numbers… so you might be right.

I’ve added the valve position:

I’ve installed the 1.8.0 addon. What type= name are you using for the output? I guessed at OUTPUT but I didn’t get anything in the log and the parameter shows uninitialized in openHAB.

Number RadiatorOutput “Radiator Output [%.1f %%]”(Radiators) { lightwaverf=“room=7,serial=F05102,type=OUTPUT” }

On the subject of the Home Thermostat, I installed one today. Not sure of the best way to let you see the messages so these are from the openHAB log:

2015-12-09 20:13:43.933 [ERROR] [l.internal.LightwaveRfWifiLink] - Error converting message: :033D0F,256,!R2F*s=N5,B25,Y10,T19,S07:00:00,E08:30:00,T19,S17:00:00,E20:00:00

This is a schedule setting message. The 033D0F seems to be the unit serial number. N5 is day of week 5. Y is the setback temperature (ie the temperature when the heating isn’t on). After that are groups of schedule: T19 = temperature 19, S07:00 is start at 07:00. E08:30 is end at 0830.

2015-12-09 20:13:42.999 [WARN ] [.l.internal.LightwaveRfBinding] - No item for incoming message[*!{“trans”:6544,“mac”:“03:3D:0F”,“time”:1449692023,“prod”:“tmr1ch”,“serial”:“D76C02”,“signal”:47,“type”:“temp”,“batt”:3.26,“ver”:33,“state”:“run”,“cTemp”:19.9,“cTarg”:20.0,“output”:0,“nTarg”:18.0,“nSlot”:“22:00”,“prof”:3}]

Not sure what triggers this update. cTemp is the current temperature, cTarg is the current target. output is whether the stat is calling for heat. nTarg is the next target temperature and nSlot is the start time of the next slot.

2015-12-09 20:13:43.802 [ERROR] [l.internal.LightwaveRfWifiLink] - Error converting message: :033D0F,100,!F*p

Not sure what this on is.

2015-12-09 18:39:20.557 [ERROR] [l.internal.LightwaveRFReceiver] - Error converting message: :033D0F,250,!R2DhF*r|Requesting|Temperature

Looks like this one is the call for an update.

If you’re interested in adding this to the binding, let me know and I can do some more experimenting.


I had set it to valve position but I don’t think that will work with the thermostat so a new release here:

For output use: HEATING_OUTPUT.

The thermostat should work just like a valve does.

I’ve not implemented setting schedules or pulling the schedule values out of the message as I didn’t see much use for them.

On this page you can see what is currently available:


I agree about the schedules but I thought it might be useful to see all of the messages.

Not getting anything at all from the thermostat.

I’ll have a bit more of a play.

Sorted the thermostat. I was using the wrong serial number.

I’m having trouble with the thermostat and valves making up their own schedules that match neither the temperature nor the times of the ones that the app shows. I’ve raised a support request with Megaman to explain.

Hey there is an update to the binding here:

The current one has a bug where it will die overnight.

Also if you are happy with the binding can you comment on this Pull Request so changes can be merged into the main repository:

Updates are looking good. The binding works for the thermostat and the output value is coming across successfully.