I’ve also managed to get all thermostats working, wrote the story below in case someone else has the same issues.
It’s like you said, I removed all thermostats from the Z-Wave network by excluding them, double checked it in Hass. When all of them were gone, I rebooted Hass just to make sure.
After the reboot they were still gone. Then I made sure all device config files were cleaned up in /config/.storage (they were still there btw… maybe because I edited the entity names earlier)
Then I changed the configuration.yaml with the config_path and updated the open-zwave/config folder with the contents of the DEV repro. (rebooted again)
No errors in the logs and the devices were still gone, looked good.
After this I rejoined the thermostats (all 4) and plugged in the Zwave USB stick into the ASUS Tinkerboard. (rebooted again)
Now all 4 thermostats were visible in the sensors view (climate…) Did had a lot of warnings in the log about the temperature being wrongly reported, this was fixed by changing config parameter 5 to a ‘1’.
After this journey I cleared the log and rebooted again, no more errors!
Tested all the thermostats and setting a temperature works great, do have to say that 2 commands are needed to switch them on. I did a set temperature first and then set the operation mode to heat.
Thanks for the guide for using the Eurotronic Spirit with Home Assistant.
The Eurotronic Spirit offers the option to use an external temperature sensor. The config file has the option to activate this option.
I don’t find a way to send the current temperature to Spirit via zwave. I have a temperature sensor which sends the data via mqtt to Home Assistant. My idea is that the external temperature sensor is the reference for the Eurotronic Spirit. But I have the bad guess that open zwave doesn’t support the function to send a temperature. Could someone confirm my guess?
In my research I found this issue at openhab that tackle this function. And this pull request for this issue. I don’t want to compare the both systems. The two links are only an additional information.
If the developers of Home Assistant read my comment the solution of openhab could help for an implementation in Home Assistant. If I’m right and the function for sending a temperature to the zwave device isn’t implemented yet.
Does everyone has the same situation and found a solution?
I don’t think Home Assistant has this functionality either, although if it did i’ve love to know. Theoretically the only other way you can do it is using a different Z-Wave temperature sensor along with an association group. Unfortunately, it doesn’t seem to be quite working for me. Here’s what i’ve done…
In the settings for my Temperature Sensor (e.g. in my case an Aeotec MultiSensor 6/ZW100), I went to the Node group associations section and added the Spirit TRV as part of the Lifeline Group. This should have instructed my sensor to also send temperature reports to the Spirit TRV as well as the controller.
In the settings for my Spirit TRV, in the Node config options I set the Measured Temperature Offset to be 128. This should have instructed the TRV to use temperature readings that it receives from the sensor to determine the actual room temperature and adjust accordingly.
If anyone has managed to get this working, i’d love to hear - although the Spirit’s sensor is OK, it’s definitely preferable to have an external sensor elsewhere in the room.
Just started with zwave and added the thermostat. It worked out of the box in hassio. Maybe its because of the new OZW fork for HA?
But can someone explain to me why there are three devices?
I have climate.eurotronic_eur_spiritz_wall_radiator_thermostat_furnace / heat / heat_eco
Wouldn’t just one device be more clear?
This is how the Zwave stack exposes the entities, hopefully someone will be able to combine them all into a single entity based on the operation mode rather than breaking them all out for us like you see now.
how do I determine relevance? Only copy the folders that represent zwave hardware included in my network? Do I also need to copy the .xml and .xsd files?
should I create a new folder within my “config” folder and fill it with these files and folders from the open-wave directory? My config folder contains my configuration.yaml
would I then specify that folder as my config_path by adding the following under my zwave component (assuming the folder I created inside my config folder is called “openzwave”:
config_path: /openzwave
4)my version of OpenZwave is 1.4.3245 is that current?
Hello, I am new to HASS.
I’ve got HASS on my Rasberry 3 B+ and one Eurotronic Spirit.
I think the configuration worked out of the box but to be safe I downloaded dev-branch of open zwave and configured the config-path.
Just to be sure: is it right that I see 9 entities of the Eurotronics?
Everything works well. I use …“heat_eco_4” to change temperature and the sensor.temperature to show the current temperature. Just I said above I only wanted to be sure that my configuration is right.
And I want to know why there are so many entities, for example: in every climate-entity I have the options “Full Power”, “Heat”, “Heat Eco”.
So, which entity should I use or is it ok when I only use the Heat-Eco entity?
Hello @tomtom, yes I get same thing with my Eurotronic Spirit. Same amount of entities.
I understood the logic behind these is this: the TRV has 4 modes - off, heat eco, heat, and furnace. Off - closes the valve (but there’s still frost protection, so it’ll open if temperature is too low). Heat eco mode setpoint is stored in heat_eco entity. Heat mode setpoint is stored in _heat entity. That means, that when you set eco mode on any of the entities, instead of heat - heat_eco setpoint is used(18C in my case). And _heat setpoint is used when heat mode is used. Furnace simply opens valve 100% for 5 minutes, and then goes back to normal operation.
For some time I thought, that Heat Eco is working in somehow different than Heat(I thought it’s closing the valve when setpoint temp < ambient temp), but after I set up valve open percentage sensor I understood that it’s not(when setpoint temp< ambient temp, it simply starts to decrease valve open % gradually, same in heat or heat eco modes). So it’s just another setpoint and that’s it.
I only use _heat entity, in heat mode. All others I have hidden from the UI. Instead of eco heating mode (and heat_eco entity), I installed Schedy and it changes the temperature based on family home presence, time of day schedule, and window statuses.
and thanks for your explantation.
But after this description
there is a litte difference between _heat and heat_eco. A small, but I think it can be a different in saving energy.
But I have three other questions:
What do you mean with “…I set up valve open percentage sensor”. Which entity is it?
There is a sensor for power management. But how can I show a readable value of it? The sensor value is at “254”…i think this is around 100%? How can I convert it?
Where can I see what the other sensors are for? i.e. _system, _alarm_type or _alarm_level?
I might have poorly explained my thoughts, but OpenZWave doesn’t contradict to what I meant. Or maybe I’m missing something, but I think this energy saving mode can be implemented only by changing valve open state logic. But this logic is same in both eco heat, and heat modes from my observations.
You have two setpoints, heat, and eco heat. Generally heat would be higher than eco heat, and eco heat is 18C by default. So changing the mode from heat, to eco heat, will simply use _heat_eco setpoint, instead of _heat setpoint, and will save energy by lowering the room temperature from _heat setpoint, to _heat_eco setpoint (which is lower).
You’re not getting this by default, it’s quite a hack to get it currently. You have to use the commit from @rweglarz which basically creates Light entity for Valve Open value and you’ll then get entity light.eurotronic_eur_spiritz_wall_radiator_thermostat_level which will show how much valve is open. Read this thread if you’re willing to get this sensor: https://github.com/home-assistant/home-assistant/issues/14526
Light entity value range is 0-255, so you’ll need to use template sensor to convert that into 0-100%, it’s mentioned in the thread.
Bonus of using this, is that you can code your own logic of TRV and control it in manual mode, but I haven’t come that far yet Just using for information purposes.
No idea what this entity shows, it’s 254 for both my TRVs, and one of my valves is already on 70% battery level. You can see battery level on entity zwave.eurotronic_eur_spiritz_wall_radiator_thermostat, battery_level attribute.
I don’t know, would be happy if someone shared what these entities are for.
Regarding the Eurotronic Spirit, is it supported out-of the box in HA right now? One thing I would like to be able to do is use “current temp” from an external sensor and push it to the TRV via HA. I haven’t been able to find out if this is doable or not.
Sorry for digging up an old topic, but I’ve spent the last few days trying to decide how to proceed with integrating my climate control in HA, I’ve read literally all the forum posts on this topic a few times and I’ve managed to narrow it down to either Eurotronic Spirit or Fibaro TRVs. I’m not using a thermostat, as my boiler is always on and not in my house, so TRVs are the only thing I have to worry about. My goal is to have the temp of each room in HA and be able to set a desired temp for the room.
Eurotronic Spirit is supported out of the box in HA.
“current temp” from an external sensor was not supported in a proper way as I remember from a year ago. I could not set it in HA because my external sensors are Xiaomi sensors. When another ZWave temperature sensor is present, it can be somehow be set as external sensor for Spirit, but I think for that you needed Domoticz or something…
For the time being, in HA Spirit has it’s own ‘temperature sensor’ and ‘offset config’. By utilizing those two, you can use an automation to manage offset from external sensor, so that internal sensor shows the same temp as external one. Here is the code: Eurotronic Spirit Z-Wave - external temperature sensor
Limitation is the offset value, it’s ranging from -5C to +5C with 0.1C step.
Some more reading on external sensor issue here: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098
That’s awesome! Thanks a lot for the fast and detailed reply.
I think the offset feature will do for my needs, for the time being. Regarding the direct valve control feature, while I love that’s even possible, I hope that the set temp algo is good enough for me to not need to use that. While building the algo to open/close/idle the valve based on current and goal temps sounds like fun, I’m 100% I would obsess over it and spent too much time on it.
In the end, I think I’ll go with the Spirit TRV, based on all the threads I’ve red. Even if I was secretly hoping that the Fibaro one is also good and supported in HA, since it’s waaaay sexier hahah.
this works great for me. took me some time to find out the correct path. i did not know that i had to use /config befor. i thougt this is the main folder
If you are interested only in monitoring TRV valve opening percentage and not control of it, I may have a solution, even for Hass.io users. I have created an AppDaemon app that periodically reads OZW log file and parses out values of valve opening percentage. Those values are then used to create entities in HA.
Hi,
after the latest HA Update to 0.103.x I also experience issues when changing the temperature.
I have automated my thermostats with NodeRED and they worked fine until this update. While timer based changes work fine (changing certain temperatures at specific times and eventually turning the radiator off or on depending on the event) I also check for the outside temperature and if it gets to low it turns on the thermostat and should change it to a certain temperature. While the time based events are working the temperature based one does not. When the timer turns off the thermostat while the outside temperature is below 10°C the second trigger should check for that and turn the thermostat on again and setting a specific temperature. Turning it on works, but the temperature is not set correctly. It will use the last temperature used before turning the thermostat off. So eg. if I have the timer turning the bathroom thermostat off when it was set to 24°C the check for the outside temperature should turn it back on again and set it to 20°C.
After the mentioned update it does not work. I checked the call which is identical to the timer ones setting the temp to 24°C but here it does not set it to 20°C. Instead it just starts the thermostat and uses the last set temperature (24°C). It worked before and I didn’t change anything except I had the new mode entity to call. But that also works in all timer based automation and refuses to work properly within the temperature check automation as described.
Does anyone have a similar problem? I checked for days now but cannot find the issue or the cause while this is no longer working after the upgrade.
I have always missed this value in my spirit z-wave plus thermostatat,