This list is derived from the device itself. So, either the binding isn’t discovering this mode, or the device is not reporting that it supports this mode.
Please can you provide a debug log from the initialisation of the device - delete this XML file, and restart the binding with debug logging enabled.
@chris, I stopped the Z-wave binding, removed the XML file of one of my Eurotronic Spirit thermostats, Node 35 in this case, and restarted the Z-wave binding. Then I waited until all things in Habmin showed a normal status (so no Request, Ping or anything anymore), and I copied the log from the last stop Debug until that moment, see the link below:
Thanks.
So from the log, it confirms that the reason that MANUAL doesn’t appear in the XML file, is because the device doesn’t report to support this mode.
We see the binding request the list of modes below -:
Below is the data returned - the 88 is the mode list - only 2 bits set
01 0A 00 04 00 23 04 40 05 03 88 18
Bits 3 and 7 are set - so that equates to HEAT and FURNACE.
Thanks chris.
For my understanding, does this mean that the device says it doesn’t support this mode, or does it mean that the device refuses this mode when you try to set it to the manual mode (31)?
And given your answer, should the list (that is also shown in Paper UI) be changed somewhere?
It means that when the binding asks the device for the list of modes it supports, the manual mode is not listed.
Of course, it doesn’t mean that it’s not supported - it might be - but that is why it’s not in the XML. If it IS supported, then we’d need to find a way to override the device report and I can’t remember if the binding allows that at the moment or not.
Possibly - these are the modes that are listed in the database. Arguably they should be updated if it’s wrong, but without more work I can’t be sure if the issue is the report, or the fact that the mode isn’t supported.
The manual refers to it as “Manufacturer Specific”. See this post Eurotronic Spirit - Unsupported mode type 31.
Yes - this is the correct name (it got named MANUAL before the ZWave spec was available), but it doesn’t matter what it’s called. The bottom line is it doesn’t report that it supports mode 31 - we can call mode 31 anything we want, it will not change the fact it’s not reporting it…
Understood. Was merely pointing out that manual says it’s supported (even though the device doesn’t report it).
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.
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.
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.
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)
