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.
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…
I totally agree!
Since most of us disappointed in this crap product, do anyone know a reliable z-wave/zigbee TRV that just works as expected?
I mean without all the issues/headaches/continuous daily maintenance?
I’d very much send it these back to Amazon, and replace it with a working one if It exists at all.
I’m looking for zigbee TRV, don’t want to buy z-wave dongle only for this 
Another great issue I had this evening:
I manually turned the thermostat off (via HA interface). The thermostat acknowledged and even closed the valve to 0% (also audible). 2 minutes later, the valve opens to 30% by itself… for no reason. The thermostat still showed “off”…
This is in addition to the other bugs concerning closing the valve such as setting the thermostat to “off” and the valve only closes to (a reported) 50% or so (had this yesterday).
Or the other time when “turn off” apparently meant showing “0%” but still having an open valve so that the radiator was hot.
What on earth were they smoking ?
shame though - as I like it apart from the bugs: quiet, can change position fast, not too intrusive looking, not too expensive…
Anyone now of a zwave trv that retains these qualities, but actually has working heating logic?
So I recently noticed that Aeotec is making a very suspiciously same looking TRV.
Since Aeotec support is much-much nicer (they usually answer within a day) and have the ability to upgrade firmware if/when necessary I was thinking if anyone have already tried/or willing to try out Aeotec’s version of this TRV?
I would very much like to know the experience with it, because if they have a better firmware, or willing to make it better I’d replace all mines with those.
This looks exactly like the Eurotronics TRV, as in identical. I wonder what the differences are.
Yes. Hopefully the firmware is the difference. (Since I assume the hardware itself is ok, and only the very bad PID algorithm causing the issues we have)
If you look at the Amazon page linked from the product page there is a review saying that their aeotec trv reset itself sporadically.
I would not bet on it 
That is true, and you can also see their answer there: "This is currently a problem that occurs sporadically.
Unfortunately, we currently do not know what causes this problem. But the developers are already working on a solution.
Please exchange the device at your reseller"
Since I know - from a personal experience with them - that if needed they will provide a firmware which you can use to update your device with, this is a tons more than what eurotronic does (nothing).
I’m pretty sure they will fix that issue. But what I’m curious about is wether the ‘valve not closing fully/temp overshooting issue’ is solved with theirs or not.
Also will the issue be software or hardware? If there is a design fault a firmware update might not be able to solve it. I’ll Keep following this thread and wait for feedback before paying with my money
So someone in this issue: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1933
reported, that they asked Aeotec about this TRV and this was their answer:
"“I can confirm that it is a re-branding of the Eurotronic Spirit TRV in this case, i am unsure about similar issues which i will raise with our team and try to find out of the highlighted problems are present in this current version.”
I hope they will send another answer soon with findings about these issues we have with Eurotronic.