Is there a straight forward way to find out if the device accepts the value 31 for the mode channel, and subsequently allows direct input on the valve position? E.g. something I could test myself?
My guess is it does - the manual states it does anyway.
What happens if you just set this mode? I can’t remember if the binding will prevent it being set if it’s not in the list or not (I don’t think so, but I don’t recall). Just make sure to grab the debug logs when you try it.
In the first post in this thread, it looks like the binding is reporting an error that the mode is unsupported.
What happens when I set the mode to manual via Paper UI, it stays on Manual, until I move the valve slider to any value, and then the mode jumps back to Hear and the slider moves back to the original value (or a new value because of an updated temperature).
I did that twice in a row, see the log here:
Node32SetManual.log (140.6 KB)
Looking at the manual I think there is not just “THERMOSTAT_MODE” that should be 31 (0x1F) - called MANUAL or DIRECT VALVE or “Manufacturer Specific”. There is also a basic command (basic command class?) “Manufacturer Specific” with the value “0xFE” and this seems to be the first thing it should be sent to access the manual mode - page 17, 6.2 Basic.
Thermostat mode is on page 19 6.8.
Also on the following resource reviewer says it has to be sent with the basic command:
“I was disappointed that direct valve control is not possible unless a command in the basic command class (0xFE) is sent to the thermostat. Neither the Vera Plus nor Homeseer HS3 can do this, so I had to implement a workaround to get the valves to open 100% or close 100% on demand.”
I’m a zwave newbie, so sorry for possible stupid question. Can this be done with OH? Or can it be done some other way and would stay set in OH? As said before, I managed to use direct valve control (manual mode) on this thing with FHEM, but I don’t remember how exactly, I just assumed it can be done everywhere then.
Setting MANUAL mode on paperui or basic UI does not work and log reports:
[ERROR] [lass.ZWaveThermostatModeCommandClass] - NODE 5: Unsupported mode type 31
[WARN ] [nverter.ZWaveThermostatModeConverter] - NODE 5: Generating message failed for command class = COMMAND_CLASS_THERMOSTAT_MODE, endpoint = 0
But can someone tells me, is OH preventing the send of the command because of the XML feature-set or is this a device response with error?
I got the manual heat mode working!!
I bought three of these devices, after I specifically saw in the manual that the valve could be controlled manually (like a dimmer) So I was a bit frustrated that I got the “type 31 not supported” error.
So I did some digging, and noticed in the manual that the “Manufacturer Specific Mode” was set through the BASIC command class, and also the THERMOSTAT_MODE command class. But when I checked the Zwave database for the Eurotronic Spirit I saw the following message:
“Endpoint 0 has no command class linked to the basic class”
So then I took the zwave jar file, and edited the XML file for the device myself.
And added the following to the XML (hoping to get an extra channel for the device):
<channel id="basic_mode" typeId="eurotronic_spirit_00_000_basic_mode">
<label>Basic mode</label>
<properties>
<property name="binding:*:DecimalType">COMMAND_CLASS_BASIC</property>
</properties>
Reinstalled the edited zwave binding manually through the add-on folder, and this created an extra channel called basic_mode. I then linked an item to it. So I had
Number Thermo_Mode "Thermostaat mode" {channel="zwave:device:512:node7:thermostat_mode"}
Number Basic_Mode "Basic mode" {channel="zwave:device:512:node7:basic_mode"}
Then I send a command to set the basic_mode to 254 (0xFE)
And that did the trick:
2019-01-03 00:28:21.976 [nt.ItemStatePredictedEvent] - Basic_Mode predicted to become 254
2019-01-03 00:28:21.991 [vent.ItemStateChangedEvent] - Basic_Mode changed from NULL to 254
2019-01-03 00:28:26.399 [vent.ItemStateChangedEvent] - Thermo_Mode changed from 1 to 31
I can now control the valve through the Multilevel Switch, and set the valve to any percentage I want.
(the THERMOSTAT_MODE was automatically set to 31)
I also added the following to the XML giving me a nice dropdown list for the BASIC_MODE:
<channel-type id="eurotronic_spirit_00_000_basic_mode">
<item-type>Number</item-type>
<label>Basic Mode</label>
<description>Sets the Basic mode</description>
<category>Temperature</category>
<state pattern="%s">
<options>
<option value="15">Off</option>
<option value="0">Economy Heat</option>
<option value="255">Heat</option>
<option value="240">Full Power</option>
<option value="254">Manual</option>
</options>
@chris
Although I am certainly no expert, but I think a permanent fix would be that the device should be updated in the zwave database to add the basic_mode channel (COMMAND_CLASS_BASIC) so you can set this value through an item. But I don’t know the best approach for this?
(disclaimer; I was excited to get this to work, so I wrote this post, but did not do a lot of testing yet but it seems to be working fine)
–EDIT:
I did some testing/thinking, and I don’t see any need for the THERMOSTAT_MODE channel anymore, because the COMMAND_CLASS_BASIC seems to control the THERMOSTAT_MODE. Setting a value for BASIC_MODE automatically changes the THERMOSTAT_MODE. And the options to choose from are the same.
–EDIT2:
On second thought you do need the THERMOSTAT_MODE.
Setting the BASIC_MODE to “Manual” changes the THERMOSTAT_MODE to “Manual”. (but not vice versa)
So changing the THERMOSTAT_MODE to Heating does not change the BASIC_MODE to Heating.(it remains “Manual”) And I think this (changing Thermostat mode) could happen when you press the buttons on the physical device.
5 Likes
I would need to have a think about how to handle this - not so much in the binding which your example seems to show works ok, but in the database where I need to think about how to handle this. Give me a few days to look at this…
Thanks Chris for looking into this. Like I said, I am no expert, but I’m glad that I proved it could work. 
If I can do anything to help, just let me know.
1 Like
Hans - what is your plan right now to control the heating? I constantly see that builtin solution is not working as intended - setpoint is reached and the heater is still on.
When thinking about it - it’s not as simple as On (dimmer 100%) /Off (0%) solution. Currently, the heater keeps the valve at some percentage level. I’m not sure how this could be implemented with something that has such slow response time. I couldn’t find any similar solution on the forum.
I was looking at PID controller in python but such solution would need constant input. I have two thermometers in all the rooms - Xiaomi Aquara and one builtin in spirit. Constant input could be somehow achieved using InfluxDB for storing current values and putting back suggested valve percentage value but I’m not sure if coding it is worth the effort.
I have a Nest Thermostat which does a pretty good job of controlling the temperature in my living-room. But I also spent a lot of time in my study-room (late at night) so I use the Eurotronics Spirits to not needlessly heat rooms when nobody is there. I do this manually with the Openhab app and habpanel. Because I locally edited my zwave datebase, I can control the valve with sliders.
Now I also want to heat my childrens room, in the middle of the night, because it sometimes gets too cold. And that’s where my Aqara temp sensor comes in. I can build a rule that is triggered when the Aqara sensor reports a temp change. If it is below a certain temperature, Openhab can turn on the Nest, make sure all the other radiator valves are closed, and set the children’s radiator to say 20%. When the Aqara sensor reports above my threshold temperature I can program it to turn off slowly. (and turn off the Nest)
Now for your problem:
was looking at PID controller in python but such solution would need constant input. I have two thermometers in all the rooms - Xiaomi Aquara and one builtin in spirit. Constant input could be somehow achieved using InfluxDB for storing current values and putting back suggested valve percentage value but I’m not sure if coding it is worth the effort.
I don’t think you need PID controllers in pyhton. Just a simple rule which is triggered when the Aqara temp changes. So something like this:
rule "Aqara changes temp"
when
Item Aqara_Temp changed
then
if (Aqara_Temp.state < 20) {
// Do something
}
end
You could also set the config parameter of the eurotronic device/thing to let the external temperature regulate the device. Then you could let the Aqara sensor update the Eurotronics sensor each time the temp changes:
Items:
Number Thermo_Manual_Temp "Sensor Temp" {channel="zwave:device:512:node7:sensor_report"}
Rule:
rule "Aqara changes temp"
when
Item Aqara_Temp changed
then
var T = Aqara_Temp.state.toString
Thermo_Manual_Temp.sendCommand(T)
end
Because the sensor in the spirit in some cases showed garbage (temp offset wasn’t working properly) I bought Aquara sensors. Then I set it up that external sensor is controlling the regulator.
Problem is that even with Aquara external sensor - the build in PI regulator is behaving badly. My wife works from home so there is one room that should keep “normal” temperatures during the whole day.
Looking at all my experience in that room - opening the valve at random value won’t do the trick here.
I’m not sure if it will be easy to understand the graph but for now, let us focus on yellow line and light blue - the difference between reported Spirit temp and Xiaomi - is over 5 Celsius. The setpoint is Red and Green is the valve opening %.
Now just after my mark, the balcony was opened and the valve should be closed - well the 1 min graph shows it went down only to 40% just to climb up - so it thought that balcony is closed while it wasn’t. Then even more weird situation happened - setting up the setpoint down caused the valve to open at 100%. It seems that any change in setpoint causes sometimes unpredicted behavior - usually, the valve opens more than it should.
I don’t know if this is only my case or poor regulator design, I had to use setpoint as 24C and with such setup temp in the room is 21.5. Setting it to 22 caused that room temp was around 20C because the valve was opened so slowly. Probably to have a proper dynamic in that room I would have to have a bigger heater or I would have to heat it up constantly (even during the night).
Another bad behavior - setting up setpoint to 18C doesn’t immediately close the valve (as setpoint is way below current temp.) Instead, it slowly closes it but in my case never reaches 0% valve opening this means that even that I would like to temp go down in that room - it’s not doing that as the valve is still being opened for almost the whole night.
At first, I designed it so at 7:30 it should be warm meaning - reach 23 and then drop to 21 - so I have set it up to start heating around 4:00AM. Instead, I had to set it to 28 just to get 100% valve open and do actual heat up.
I know also that ventilating the room by opening the balcony is not helping it at all.
So all in all - this is why I thought that it would be better to figure out something instead and that “//Do something” is the most tricky part.
1 Like
Sorry, I think my solution might have been a bit too simplistic. But I still believe the solution for you, is to directly control the valves. So setting the device to “Manufacture Specific (manual)” So either wait for Chris to update the zwave database or hack you local XML file yourself.
Then you could basically build your own heating algoritm. That’s way more fun then using the faulty algoritm of the Spirit device (and you have more control)
The aqara temp change could be the trigger. And you could declare your own variables, something like TargetTemp, Range and IncreaseValue. When your aqara temperature is above/below the TargetTemp±Range, you can send the command to the valve dimmer (using the IncreaseValue variable)
You can then also populate these variables with Items, so that you can play around changing these items to find the best settings. You can also use timers, to determine if the temperature is stable enough to close the valves. Use weather information/temperature outside to determine how fast to heat.
And buy an aqara door sensor (i have many of those, works great) and build your own rule when the balcony door is opened (for too long)
Many possibilities, sounds like a lot fun (I still have to do this for my daughters room, so don’t have rules examples yet)
Instead of making use of manual mode, i have started to send external temperature with offset.
- if aqaraTemp sensor temp is below spirit desired temp than external temp=aqaraTemp-offset(-8) - valve is fully opened
- if aqaraTemp sensor temp is below spirit desired temp than external temp=aqaraTemp - valve is operating normally - randomly about 0,11,30%, but room is never overheated
It is obvious that it is pretty bad hack, but it works.
Is there any news, if the fix will make it to the zwave database?
Hi, do you think it can be resolve or I have to find other value modul?
Thank you
O.
Hello,
is there already a solution to activate the manual mode?
Hello, January…March… is there a chance that the binding will ever support the Spirit’s manual mode?
Last year I bought the Spirit and spent countless hours to figure out why it behaves to strange when the dimmer-slider is moved. Finally, I’ve returned the Spirit.
Now I bought it again to see if it’s implemented, and tried with a fresh install of version 2.5, build #1715, but there’s still the slider back-moving, and the mode sets itself back, and the same errors in the log:
2019-10-10 09:31:13.136 [ERROR] [lass.ZWaveThermostatModeCommandClass] - NODE 14: Unsupported mode type 31
2019-10-10 09:31:13.137 [WARN ] [nverter.ZWaveThermostatModeConverter] - NODE 14: Generating message failed for command class = COMMAND_CLASS_THERMOSTAT_MODE, endpoint = 0
I found this thread and tried the tipp from Hans Eurotronic Spirit - Unsupported mode type 31 - #35 by Hans_B
But I can’t get it to work. I moved the .jar file to:
/Applications/openhab/addons/Additional add-on files/org.openhab.binding.zwave-2.5.0.M1.jar
Inside the jar I found the XML file:
ESH-INF/thing/eurotronic/spirit_0_0.xml
With BBedit I’ve added into the end of < !-- CHANNEL DEFINITIONS → this:
< channel id=“basic_mode” typeId=“eurotronic_spirit_00_000_basic_mode”>
< label>Basic mode
< properties>
< property name=“binding:*:DecimalType”>COMMAND_CLASS_BASIC
</ properties>
</ channel>
</ channels>
Additionally I changed the help text in the < description> section to
“for at least 5.515 seconds”
to see if changes in the file are recognized at all. But in Paper UI there is still
“for at least 5 seconds”
and no new channel “basic_mode”. I have removed / re-added the Thing, no effect.
Hans wrote “Reinstalled the edited zwave binding manually” and I’m not sure what exactly that means. Is editing & moving the file not enough, but some “install” neccessary? I tried to google that, but only found network-install / github related things, nothing about “installing” a local modified jar file - if that is required??
This is obviously not stuff for common users, and it seems to be a complicated thing (or impossible?) to implement it into the binding. A honest answer if it never will come would be nice, as I have then to search for some other protocoll, and devices. Hopefully not, because I already have 9 zwave devices. 
With the Spirit’s valve control working, I could go on, and finally get rid of my FS20 stuff, and Windows XP. Heeeelp! 
I want to buy this TRV. So there is support for this, is this in the database? And what features exactly not working?
It’s own regulation mode is completely garbage (heats when it shouldn’t and vice versa). But among the very few zwave heating devices it is the only that responds immediately to commands from the controller, and reports back. With other devices it takes several minutes before anything happens, annoying, I have that with my FS20 regulators…
It is also the only device that supports controlling the valve directly, so you can setup some rules to have a regulation that is working very well.
But this is what is discussed in this topic, right? So you can’t really set the MANUAL mode now.
So this is also not the best in this category but there is no better alternative?
So that means that I have to buy additional temp sensors in each room right?