I am pretty new to home assistant, I got the thermostat to work but fighting with the automations.
Would you be so kind to post an example of your automation with setting the temperature?
Thanks
Chris
After several hours I got the automation to work 
I have 8 of these Spririt thermostats operational. I observed that the valves are opening too slow. As a result, the target temperature is not reached or it takes too long before the target temperature is reached. I fixed this by introducing controlling intelligence in home Assistant.
This is done by comparing the current temperature with the target temperature. If difference is large, home assistant increases the target temperature in the Spirit to 28 degrees which result in valve being opened completely. By contionously finetuning the target temperature, I reached exactly the temperature that I want and in the fast possible manner.
I use appdaemon and programmed this in Python. Works quite well.
I would have prefered to command the valves directly, but I do not know if this is possible. By setting a high or low target temperature, I obtained the same result.
I would like to learn about other approaches for this issue if people have similar experience.
Hi jo-me,
Unfortunately, I can’t find current_position value in the Devices and in the Developers menu (I have enabled the valve reporting).
What should I do for reaching the current_position property like you?
I am having the same and few issues with my Spirit TRV.
I have no “cuurent_position” even after enabling the valve reporting.
and few of the TRV sensors are not working; the battery is not reporting and few others as shown in the pic.
even that the battery reporting is enabled; I am an old user of HA, but this is my first run with Z-wave; so I don’t know how to get a configuration file for the device or how to modify it and whether there is custom configuration for this device on the community or not.
Thanks
1 Like
Just got couple of these and main issue for me is that when I set them to Off sometimes it’ll not close the valve and radiator is still heating. I found that if I set it to 28C and then off (sometimes I need to repeat On/Off cycle) it will eventually shut the radiator completly. I’m considering sending them back to Amazon if I’m not going to be able to remedy this issue.
@artkrz I have the same issue.
Directly after installation it seems to work fine (when its freshly calibrated) but after a while it loses orientation apparently.
Even with manual valve control setting it to 0% does sometimes not close it completely. The motor turns on but not long enough until the valve is closed (you hear it in the motor noise because it becomes harder to close the last bit) Only after setting the valve to 100% and then back to 0% a couple of time it works.
See my post above with the code snippet. current_position is just a template sensor based on the cover entity.
Same here - the problem seems to occur mainly if the valve is already almost closed (<10% or so) when turning it off, it then seems to get confused how much further to close it. I think I’m going to make an automation that shortly switches it to boost mode before turning off, that seems to help…
Not that happy with it’s temperature regulation anyway, it closes the valve way to quickly before reaching target temp, or doesn’t open it at all (combine that with overshooting if the valve opens because it thinks it closed it but didn’t, as described), even when the wanted temp is 1.5 degrees higher then the current temp measured by the device, so was thinking of regulating it with automation anyway.Good thing is that in case of computer outage it can then still be controlled manually with the buttons, and still have “some” intelligence in temp control
So has anyone built something to work around the overheating issue?
What is even a reliable way to get the thermostat to acknowledge that the setpoint is reached and act accordingly? Turn Off and On? Boost, Off, On?
I was thinking about using a PID controller (there are python implementations in github and even on the forum here) that runs in HA / AppDaemon at first, but I just don’t trust Zwave to deliver all commands reliably. Same goes for the “Boost-to-Turn-off” workaround. If the “off” command is lost the thermostat will stay on “boost” forever.
Even having the logic part in HA is a very bad design choice (single point of failure) but I’m not aware of alternatives solutions (aside from returning /selling the thermostats asap)
Btw. I found Zwave to not be reliable at all - at least in HA - to trust basic node connectivity data let alone reliable command transfer - especially for the nodes not directly communicating with the controller. A custom component would need to keep track of the commands sent and repeat it if necessary (and alert eventually).
No, because boost auto deactivates after (I think) 3 minutes (the manual says 5, but I’m quite sure it’s shorter) - it then returns to it’s previous state. So either boost-off (shortest period of extra heating) or off-boost (but then it stays in boost for 3 minutes) or off-boost-off (most paranoia proof, but extra commands and extra valve activation, so worse for the battery) should work. I haven’t yet implemented this though.
For me z-wave is pretty reliable, so I don’t have too much issues with having the logic in HA. If HA fails, the thermostat will still have it’s own setpoint (and it isn’t so terrible that it will let the room freeze over or get massively hot - it just isn’t good enough maintainig comfort on it’s own) and can then still be controlled manually through it’s buttons if need be.
So, are you doing this boost-off action every day to keep up the calibration?
Does that affect the overshoot issue at all - in other words: does it keep the setpoint better if a daily calibration is happening via boost-off?
Well, I haven’t much automated them yet, but whenever I notice the issue of the valve not closing when it reports being closed I have done a boost-off manually, and that does solve it at that time. I wouldn’t consider that a recalibration though, as the issue may re-occur quite quickly, it seems (I think it occurs almost every time the valve has been opened on a low percentage for some time. Might be interesting to get some feedback from the manufacturer too). I think I will just go to boost mode for a short time before turning it off, and maybe set up some kind of overshoot detection. I may well setup a virtual thermostat to control the real one, and then apply some “behind the scenes” logic to actual setpoints (eg set it higher then the wanted temp to make sure heating starts + boost-off when needed…) Still thinking about it, and haven’t had the time to set it up yet. If I do, I will report on results
Well, for me this is too much maintenance. I got 8 of these and apart o connectivity issues (z-wave plus issue maybe and not spirit) some of them worked better some were shit. Apart of valves not closing I also had an issue where they were going into INS mode even though they were tightly fitted. I did make a script to do boost => off => on and it did help but issue reappeared on daily basis, just on different valve. Anyway, for me it is goodbye Eurotrinic and goodbye z-wave. Sending all of them back to Amazon. Good luck to all of you, hope it will work for you.
Hello, I just bought 4 of them but their behaviour seems a little strange.
They stay too much time “a bit open”, even if setpoint is reached.
Why?
I immediately created an automation that shuts down my main heater if the sum of all thermostat valves position is less than 50, and I turn it back on again if it’s more than 99 (a single full open radiator should be enough to turn on the heater).
This way they should act a little smarter.
Next will be calibration, they seems 0.5 off at least.
1 Like
seems like after the last update helper stopped picking valves positions
2020-01-17 17:09:00.040680 WARNING AppDaemon: ------------------------------------------------------------
2020-01-17 17:11:00.006976 INFO eurotronic-trv-valvepos: Using OZW log file /config/OZW_Log.txt
2020-01-17 17:11:00.041863 WARNING AppDaemon: ------------------------------------------------------------
2020-01-17 17:11:00.042225 WARNING AppDaemon: Unexpected error in worker for App eurotronic-trv-valvepos:
2020-01-17 17:11:00.042410 WARNING AppDaemon: Worker Ags: {'name': 'eurotronic-trv-valvepos', 'id': UUID('6930b976-7045-45db-a8ec-4bbf7a4cb046'), 'type': 'timer', 'function': <bound method EurotronicTRVValvePos.read_valvepos_from_log of <eurotronic-trv-valvepos.EurotronicTRVValvePos object at 0x7fca10133fd0>>, 'kwargs': {'interval': 120}}
2020-01-17 17:11:00.042550 WARNING AppDaemon: ------------------------------------------------------------
2020-01-17 17:11:00.042952 WARNING AppDaemon: Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/appdaemon/appdaemon.py", line 586, in worker
funcref(self.sanitize_timer_kwargs(app, args["kwargs"]))
File "/config/appdaemon/apps/eurotronic-trv-valvepos/eurotronic-trv-valvepos.py", line 28, in read_valvepos_from_log
if (v["attributes"]["product_name"] == self.args.get("look_for_productname", "EUR_SPIRITZ Wall Radiator Thermostat")):
KeyError: 'product_name'
So, I’ve finally come around to testing some workarounds.
My assumption is that for some reason (most likely poor engineering) the temp overshoot and the valve closing issues are caused when the thermostats do not get a reliable reaction when they change valve positions. So, in my heating system, the living room is the “leading room” and only if that room is not ok will it turn on the heating. So the other rooms are heated only if the living room requires heat. This means, that a thermostat in another room can be on 100% and sometimes it will get warmer and sometimes not.
In turn, the Eurotronics TRVs may never reach their setpoint in some rooms if the living room is warm enough, but its not their fault. It is, however, their fault if they do not turn off when they exceed their setpoint.
So, to “recalibrate”, I’ve added an automation that does the “boost-off-on” thing once a day.
It is quite simple as the entity ids of all thermostats can be given in the service calls. Example for the boost:
data:
entity_id:
- climate.spirit_room1_heat
- climate.spirit_room2_heat
- climate.spirit_room3_heat
preset_mode: boost
service: climate.set_preset_mode
The off/on calls look similar. I also put a 30s delay between the calls.
In addition, I used the Appdaemon app “Schedy” to set up a schedule that resembles the schedule from my central thermostat. So, it has a lower setpoint at night and different times on weekdays and weekends.
That way the Eurotronic thermostats will not go through the night with e.g. their normal 20° setpoint even though the rooms cool off until morning.
I’ve tested this for 2 days now and I did in fact see a different behavior now. The dramatic overshoots (> 2° too high) are gone now. It seems to regulate more sensible now. Of course, given heating setup it will not be perfect but thats ok.
I have been fighting with communcation issues, though. I have an awful lot of failed commands and missing status responses - less for TRVs that are connected directly to the controller but a LOT for 2 TRVs that have to use a different node (Fibaro wall plug) as router.
In the zwave node info it looks like this:
(Even the TRV with 3m direct line-of-sight distance to the controller shows some "sentFailed"s.)
So, maybe what @artkrz saw and what I’m seeing are the same thing and a general issue with the TRVs. Do other people have issues with lost commands / status messages?
Unfortunately, my workarounds described above rely on good communication. So, if one part of the boost-off-on sequence is lost, the TRVs may remain turned off. And sure enough, every morning I find that some part of the automations failed for one or more thermostats (or it worked fine and HA just did not get the response).
Luckily, Schedy has a means of repeating the commands, so most TRVs will recover from this after a couple of minutes. Since schedy does not support activating the presets (e.g. boost) I have to find a way to get that part reliable as well.
I must say I’m tempted to scrap the zwave stuff altogether as it just continues to cause unnecessary headaches. For a certified standard it sure works like crap.
I’ve noticed another issue with the valve position reporting … I had mine set to report at 5% intervals, but it seems that it only ever reaches a max of 99% open.
I had my boiler set to turn off overnight, so the spirits open all the way to 99 overnight. For some reason, this causes the Spirit to send a report every minute with the same 99 value all night, and it has heavily affected the battery life. Has anybody else seen this?
It seems counter-intuitive, but I’m going to try changing to 1 and see if this fixes the issue. Though I guess for my case, I should probably shutdown the TRVs overnight via an automation.
This is the behaviour:
2020-01-18 07:15:27.746 Detail, Node004, Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x04, 0x03, 0x26, 0x03, 0x63, 0xb3
2020-01-18 07:15:27.747 Detail,
2020-01-18 07:15:27.747 Info, Node004, Received SwitchMultiLevel report: level=99
2020-01-18 07:15:27.747 Detail, Node004, Refreshed Value: old value=99, new value=99, type=byte
2020-01-18 07:15:27.747 Detail, Node004, Changes to this value are not verified
2020-01-18 07:15:27.747 Detail, Node004, Notification: ValueChanged
2020-01-18 07:16:28.731 Detail, Node004, Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x04, 0x03, 0x26, 0x03, 0x63, 0xb3
2020-01-18 07:16:28.731 Detail,
2020-01-18 07:16:28.731 Info, Node004, Received SwitchMultiLevel report: level=99
2020-01-18 07:16:28.731 Detail, Node004, Refreshed Value: old value=99, new value=99, type=byte
2020-01-18 07:16:28.731 Detail, Node004, Changes to this value are not verified
2020-01-18 07:16:28.731 Detail, Node004, Notification: ValueChanged
2020-01-18 07:17:29.717 Detail, Node004, Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x04, 0x03, 0x26, 0x03, 0x63, 0xb3
2020-01-18 07:17:29.717 Detail,
2020-01-18 07:17:29.717 Info, Node004, Received SwitchMultiLevel report: level=99
2020-01-18 07:17:29.717 Detail, Node004, Refreshed Value: old value=99, new value=99, type=byte
2020-01-18 07:17:29.717 Detail, Node004, Changes to this value are not verified
2020-01-18 07:17:29.717 Detail, Node004, Notification: ValueChanged
I have set the valve opening percentage report to 1 and I receive correct reports . The reports are not repeated unless the value changed.
I had 6 of these around the house but ended up returning them as they were too unreliable. Constantly one or more of them just didn’t stop heating when target temperature was reached.
Tried contacting Eurotronic but they never answered.
Too bad as they seem so promising. But I couldn’t live with my bedroom turning into a sauna every second day…
2 Likes