Thank you very much for the new plugin air conditioning experience. This might be the one thing which might make me move from Home Assistant to Nymea. It is the main reason for using that kind of thing anyway.
I have installed a zone with a thermostat (Ubisys H1) and an interior sensor. I also have defined a schedule. This is the first morning when Nymea is supposed to be heating my office.
However
In the excellent graph I can see that heating started at 9:00 AM. I have set the target temperature to 21°C. Since 9:15 the graph shows 21°C as the actual temperature at the thermostat. The graph also shows a slow rise in the room temperature from 18.78°C to 19.24°C at 11:30.
This seems to imply that the plugin simply sets the target temperature within the thermostat to the temperature I specified in the schedule.
I expected the air conditioning experience to heat my office to 21°C, not merely the thermostat. In order to do that, it is necessary to set the target temperature to a higher temperature than that and then to throttle the heating when the actual temperature in the room has reached the target temperature.
How can I set the air conditioning experience to do that?
But isn’t that exactly the task the thermostat is supposed to do? I mean… The thermostat itself does exactly this. Well, depending on the manufacturer/model, it may behave a bit differently but generally that’s what it is. I suppose your issue is that the 2 sensors you have measure different values and you think the external one is more accurate than the one in the thermostat?
That’s what I thought, too, at first.
But all thermostats mounted on the valve of the radiator have this problem: they sit in the very air heated by the radiator they control.
The air raising to the thermostat is heated not only by the radiator but even by the pipes carrying the hot water to adjoining rooms. My current system produces some beautiful graphs showing a rise in the temperature of the thermostat when the heating starts in the adjoining rooms.
The maker of my thermostat has anticipated this kind of problem, after a fashion. There is a parameter called ‘temperature correction’ which lets you program a bias into the thermostat. But that function is futile as well. The difference between room temperature and the temperature near the thermostat varies with the outside temperature. You can’t precisely control your room temperature that way, either,
My current solution consists of measuring the room temperature with an external thermal probe and overriding the actual function of the thermostat.
I thought the new function in Nymea did it that way, too. What else is the use of specifying an external thermometer?
If it doesn’t, I won’t use Nymea, even when I like it much better than my current solution which has several severe flaws.
This is one of the graphs as produced by my current system. The upper curve shows the temperature as measured by the thermostat. The lower curve shows the actual room temperature as measured by an external thermometer, not quite three meters away from the radiator.
This graph shows it even better:
(not the same time range)
It shows the heating in my bathroom. I need my bathroom to be some 21°C in the morning when we get up and in the late evening when we go to sleep. We don’t mind when it gets a bit cooler in the times between.
Given the current outside temperature, the heating manages to raise the temperature by some 1°K or 2°K per hour; left to its own devices, the temperature drops at a rate of 0.2°K/h to 0.3°K/H.
In my current setup, I manage this using two time slices with a length of 2 and 2.5 hours, respectively, when I set the thermostat to 27°C in order to raise the temperature to the vicinity of 21°C.
I did not have that issue before, when I used mechanical thermostats, for several reasons:
The danfoss thermostats are not graded in °C; they merely show a range of (*, 0-5) and no one knows which setting corresponds to 21°C.
The mechanical thermostats also did not react so fast. In order to get your room to a desired temperature, it could take all day to reach its target.
I now want to heat my rooms only when they are in use, and they are not in use for hours on end.
So: I like the new air conditioning experience very much, as it does nearly everything right, but I won’t be able to use it when it does not use a thermometer external to the thermostat.
So far, I have no bullet-proof procedure to determine the target temperature for the thermostat. Using a constant value seems OK. A simple formula would seem useful, multiplying the difference between the actual and the target temperature for the room by - say - 2.5.
How did you connect those thermostats to nymea? Afaik there’s no plugin for danfoss thermostats. Did you use the generic thermostat thing and translate data using a nymea script? If so, I suppose you could add that formula in there.
Sorry, there’s a small misunderstanding.
My current thermostats are by Ubisys and the model is H1. The protocol is ZigBee, and Nymea connects to the thermostats right away.
Danfoss also makes ZigBee thermostats by the name of Ally, and I presume that they would connect to Nymea equally well.
The problem I described above is not specific to my particular brand. All thermostats directly mounted on the valve of the radiator are prone to that problem. People have written ‘integrations’ for Home Assistant which address the same problem.
I’d rather not write any scripts for Nymea right now. I don’t do Javascript and I haven’t written any programs in decades. The solution I have ‘programmed’ for Home Assistant works after a fashion, even when it’s very ugly, and I was just hoping to be able to install a better solution.
Now I do understand your problem, but as you said yourself, there isn’t really a good solution to this, given that nymea can’t know how much your thermostats temperature measurement is off. Seems like in your case it would require to set your thermostat to more that 5 °C too high and even then it’s likely still not good enough. It would require a ton of settings which would make it rather complex to configure for every particular situation.
Do you have the thermostat mounted in a place with low air circulation? Like hidden behind the couch and clogged the air circulation with that?
One other possibility I could think of, would be to add a generic thermostat thing and use that in the AC zone. Then create a script which syncs the target temperature to the actual thermostat, adding your preferred offset and stuff.
Yes, that’s exactly my issue, and you’re not likely to notice if you’re heating each room to a constant temperature.
My current solution (using HA) does exactly what you propose:
I have an external thermal sensor which determines the actual room temperature.
I have one rule which determines the desired room temperature depending on the heating schedule and stores it into a variable ‘office target temperature’. During office hours, it’s at 19.5°C (for instance), and in the off hours it’s at 17°C. Your heating schedule does this very nicely as each time slice holds a temperature and not only a boolean value for ‘on’ or ‘off’.
I have another rule which permanently compares the actual room temperature to the desired ‘office target temperature’ mentioned above. If it’s too low, it sets the target temperature for the thermostat to a fixed arbitrary value, 27°C in this case. If it’s too high, it sets it to another arbitrary value, 7°C in my case. This tends to overshoot while warming up, but I can live with that.
It works actually quite well with only a few shortcomings even if it’s very ugly and hard to maintain.
I was hoping that the new air conditioning thing in Nymea handled it in a similar fashion, given that I could specify an external room thermometer.
A mere side issue: My thermometer is a Lumi.airmonitor. It measures the temperature and the humidity. The humidity readout seems to be stuck at a constant 48.55% ever since it went online. The readout on the actual device says 52% right now.
As you are using a Zigbee radiator thermostat, maybe a direct binding with a suitable Zigbee temperature sensor might help in this case.
Nymea supports direct bindings and you can look, if the H1 and a temperature sensor supports the temperature measurement cluster.
You have to see if your Lumi sensor is using standard clusters and some Zigbee devices cannot have a direct binding together with being connected to a coordinator, but maybe its worth a try.
I’ve checked the code for this and while Lumi devices mostly don’t follow the ZigBee spec and are sending data whithout any configuration effort, what you describe sounds like maybe some newer models now actually do require the attribute reporting configuration as per ZigBee spec. I’ve added that and it’s currently building in the experimental repository. Please try if that fixes it and report back. Note that you’ll have to re-add the device to the network as this attribute configuration only happens when the node is initially added to the network.
It took three rounds:
(1) enabled experimental repository, found 51 updates, applied all of them, detached and re-attached Lumi.airmonitor to ZigBee network
No apparent difference. Temperature being tracked, humidity is not tracked after first measure.
(2) found still 51 updates; it appears that Nymea went through the motions but did not actually apply the 51 updates. Applied the zigbee.lumi update alone.
Before I removed the device from the ZigBee network, it was spontaneously connected, took one temperature measurement and two humidity points.
After removing and addiing again to the ZigBee network: no apparent change. Repeatedly takes temp. measures, takes humidity measure only once.
(3) found another update for ZigBee.Lumi from today morning (2023.03.19, about 10:41, I believe). Applied update, removed and added again to ZigBee network.
Takes and logs two temperature readings, three humidity readings within the first three minutes, which accurately reflected the values shown on the display of the device (I blew on the thing in order to raise both temperature and humidity). In the following half hour, the display of the device flashes from time to time (reason unknown). The values shown on the display change steadily. No new entries whatsoever in the log. The values shown in the app remain the same, even when restarting the app. Didn’t restart core, though.
The device has a button. When I press the button, the device updates the display. None of those changes are reflected in Nymea.
Now, both the temperature and the humidity reading are stuck, instead of only the humidity one. The update did not solve the issue.
Thanks. Turns out that this device was not yet supported by the Lumi plugin and was handled by the generic H/T sensor. That one indeed had a bug which would not configure attribute reporting for humidity. I’ve fixed that.
However, this device also supports VOC measurements so I’ve added a specific handler for this in the Lumi plugin. If you re-add the device from scratch once again (after the next experimental build is done), it should appear as a TVOC Air Quality Monitor and also give VOC along with temperature and humidity. Also there’s a setting in the thing settings which allows to configure the display units on the display.
Please test it and let me know if everything works, also if the VOC values are correct (should be somewhere in between 100 and 660 for a reasonably fresh air).
Yes, everything works. The only thing that seems a little strange is that the humidity again seems to be stuck at a constant value. However, as I don’t need that information, I don’t mind at all.
thanks for testing. The device also supports battery level reporting, I’ve added that too now. And I’ve done a change in the humidity reporting config. Perhaps that fixes it. Looks indeed strange that it didn’t change for 9 hours at all.
The device now reports a battery level of 0% (associated with the warning that the battery was nearly exhausted). This is clearly false. HA reports for the same device a battery level of 100%.
Temperature and VOC are reported live. Humidity is still stuck at the value first encountered when connecting to the device. (Again, for my current application I don’t need the humidity data, so it’s all right with me.)
Does the direction in which I setup a binding matter? I.e., in order to bind a temperature sensor to a thermostat, do I establish the binding in the sensor thing or in the thermostat?
I tried with different temp sensors. Sometimes the binding was accepted, sometimes an error in the ZigBee network was reported and sometimes Nymea claimed one or the other device was asleep.
Even when I finally succeeded in establishing a binding, it did not have an apparent or observable effect. The thermostat still turns the valve on and off according to its own built-in thermometer and completely ignores the external temperature sensor.
Binding ZigBee devices in Nymea basically works, however. I could bind a control button to a power plug and the button switches the plug on and off even when neither Nymea nor the gateway are running.
