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.