I first came across openHAB after watching a tv commercial for Danfoss Living Connect thermostats. Looking into the product I realized that it had some major drawbacks in my point of view. The central control touch screen unit was not really what I imagined sitting on my wall. I would probably use the app in all every day use cases anyways. The app seems really good though, but it annoyed me nevertheless, having one proprietary app limited to controlling certain house hold devices when ideally I would control all connected devices as well as doing scenes across different device types on one app. Luckily I soon discovered that these thermostats use the open control protocol z-wave and an open source system called openHAB was there to do automation for all sorts of devices and tie it all together in a single app.
I installed openHAB on a QNAP NAS and began planning the setup I would need to control the heating system in my home. Regrettably this process has gotten me struggling to convince myself that openHAB/LC13 will do all the things I found appealing about the Link Connect.
The Link Connect has Adaptive Learning that “ensures that the comfort temperature is reached at set time.” That would require that a multitude of setpoints could be set in a schedule within the thermostat. I called Danfoss who said that they don’t do end user support and referred me to the seller of the product. They then told me that the open z-wave version does not support scheduled setpoints hence not the adaptive learning feature. I found some sort of data sheet of the LC13 that lists its z-wave command classes including the CLIMATE_CONTROL_SCHEDULE class. This indicates that the seller is wrong and scheduling by multiple setpoints is supported in the LC13 version. One could only hope so.
The next issue is that the Z-wave binding in openHAB does not support the CLIMATE_CONTROL_SCHEDULE command class (citation needed). That could probably be overcome if someone with the plenty developing skills had some time to put into that expansion of the binding.
What the proprietary Danfoss App really does is putting some rule making into the UI. It seems that is not the purpose of the openHAB app. Here rules are made in the backend (Paper UI or in the Designer) and the app is a means of controlling things/items directly, by groups or scenes and read out states of the items. It is not meant for setting the automation of items’ behavior. In that sense, I could not use the openHAB app to control a set of Danfoss thermostats the way I would use the proprietary app. Or at least it would take some heavy tweaking. Please correct me if I’m wrong.
For some reason the LC13 version costs twice as much as the non-open Link Connect version and I don’t get (to use) all the functionality. Suddenly the stand-alone version Link Connect Eco seems the most attractive choice for me. But I’d hate to give op the adventure of customizing in openHAB.
OH does not have adaptive learning out of the box. You would need to implement the learning algorithms yourself.
I do not know much about the CLIMATE_CONTROL_SCHEDULE command class so can’t answer to that, but you can implement the setpoints using OH rules logic.
I’m sure chris would welcome the help. The ZWay binding may support it though so that might be a path you can research.
That is correct. The rules are implemented on the back end. The new Experimental Rules Engine will be supported rules creation in the browser and Habmin has a graphical based rules editor (similar to Scratch).
And setting up schedules in the OH UIs is one of the weak points in OH. However, I recommend that users try to avoid making these sorts of schedules and instead base their hvac (and other automations) on state and events rather than a set schedule. For example, instead of setting a schedule to come to X degrees at 07:00, Y degrees and 15:00, etc. create rules to come to X degrees when the alarm goes off and set to Y degrees when you are home and the window is closed. Stuff like that. This is where one really takes advantage of the automation as it makes it completely adaptive to what is actually happening in the house, not just based on time and temp.
This rather old OP on forum.z-wave.me indicates that Z-Way does support CLIMATE_CONTROL_SCHEDULE but somewhat unstable.
I take it, it’s not something one would do in the course of an afternoon. After all Chris took his time time to do a dummy implementation of the command class. If implementing the real thing was swift I guess it would be done by now. At least trying to implement it myself is probably not how I’m going about this, having close to zero experience in java development.
So I could try to do that. I would prefer though to get a basic setup with devices connected for starters and gradually applying rule logic and more automation as I go along.
Doing my own adaptive learning would require setting up persistence and for each scheduled setpoint change, adjust according to the most likely warm-up-time for the difference between the expected prior room temperature and the setpoint. I would be proud to be able to do that but preferably I would like to utilize the algorithm that Danfoss’ research gave rise to. I may put to much trust in them but I guess they would have an idea as to how to get the room to a certain temperatur in the most energi efficient way.
I do understand and appreciate the dynamic approach to automation. But I’m starting from nothing and right now I have no connected things. (Not true, some SONOS speakers, my cell phone, a ChromeCast and the NAS openHAB runs on). And even if I had access to the alarm on my phone, it would still take som hacking to implement the anticipation of a desired setpoint change to begin warming up before the alarm goes off.
I’m gonna have to take java courses and turn the knob myself for now.
I have used LC13 and openhab2 for about a year now and have gained some experience.
Adaptive learning. Sure this would be great. But for me the alternative works also fine (fixed time schedule experienced by watching the temperature response a couple of times).
CLIMATE_CONTROL_SCHEDULE class would be really nice to get working. I use external temperature sensor, and are constantly updating the setpoints based on the measured bias. It does a fair job controlling the comfort temperature. However i would think that communicating the bias directly via the CLIMATE_CONTROL_SCHEDULE class would improve the control.
When checking the xml files, it’s evident that CLIMATE_CONTROL_SCHEDULE is supported. And more relevant command classes exist (see below) like child protection.
i wonder what it would take to have them included in OH. Unfurtunately i’m a newbee when it comes to OH and Zwave, but if i had the skills i would gladly support.
Does the bias fluctuate significantly or change according to outside temperature? Otherwise I should think it would be easier to just adjust the setpoint according to how you perceive a given setpoint setting. I mean, your idea of a comfort temperature is worth no more than your perception of that room temperaure. That might as well be 22.5 °C on the LC13 unit as say 21.0 °C on your external sensor.
You cannot read the sensed temperature on the LC13 can you? Do you consider the difference between the external sensor and the setpoint to be the bias? Does “constantly” mean, that you deliberately overshoot the setpoint during a heating cycle (say when you go from night setting to comfort temperature)? Just curious.
How would the CLIMATE_CONTROL_SCHEDULE command class improve the control. As far as I can tell it just moves the schedule based automation from OH to the unit. In fact the ability for LC13 to run on schedule offline (through CLIMATE_CONTROL_SCHEDULE) would vanish when depending on an external sensor.
Below you can check out my temperature response. Red is my desired temperature, green is the actual measured. Pink is measured on top of 1 of the 3 radiators in the living room (so the control cycle of the LC13 can be seen.
No, LC13 does unfortunately not show the sensor reading. Yes, bias is the difference between desired and actual measured. I use a simple P-controller with saturation:
TempDiff.postUpdate(3*(Rad_TEMP_SP.state as DecimalType - Temperature_GF_Living2.state as DecimalType))
if(TempDiff.state > 1.5)
if(TempDiff.state < -1.5)
I have not done too much parameter tuning
Well, i guess you are right that there will be no difference in response. Not sure how Danfoss have implemeted their PID controller. But then at least it will look a bit more nice, that the setpoint will be identical with the desired room temp, and the remaning calibration can be kept separate…
Sure. Below you will find the setpoints for the 3 LC13 units in the kitching - living room area.
There is some scatter in the data, i need to look into why it is like this (maybe from some of the aritmetic operations…). But this is the concept.
So if the pink line is the temperature on top of the radiator it seems that for the given temperature setting in the LC13 the actual setting of the valve changes. Is that correct ? In other words, if i would set the LC13 to for example 22C the LC13 would try to keep the temperature on the fixed level (+/- some offset) ? Or it is necessary to implement more complicated algorithm on the openhab side ?
Well, it depends on your expectations i guess. Seems like i can have the batteries running for a season, which i find perfectly OK. I get a report when one battery device is low, and replacement of batteries is a fast job. And with rechargeable batteries not a cost issue either.