Instead of making use of manual mode, i have started to send external temperature with offset.
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?
A) Yes, setting it to manual mode result in an error.
B) There is no better alternative for zwave.
C) That doesnāt help, I have that. The Spiritās regulation just has itās own life, it is of random behavior, no matter if the internal or an external sensor reports the temperature to the Spirit.
At least the internal temp sensor works reliable? So based on that temperatures can you create a rule which works better than its internal program?
You cannot override the internal device regulation with an OpenHab rule. An OpenHab rule could regulate the valve directly - if the zwave binding would support the manual mode (valve control) of the Spirit.
I guess the PID controller of the Spirit reacts very slowly.
I have two of them working without troubles, but I have a low temp heating system running most of the time between 35Ā° to 45Ā°C only.
I assume the troubles are comming up if you have a heating temp about 60Ā° or more ā¦
These are my experiences with Spirit. My main point: Its a good device as is, it would be even better with manual mode enabled. I hope it gets to that.
I have 6 of them now. It is a great valve for the price. For now I am using the internal temperature sensor and internal valve logic. Itās far from perfect, but it is not useless. It is opening and closing frequently (not very battery friendly), but it does keep temperature quite stable as a result. I mean, it does fluctuate Ā±1Ā°C, but this is expected with radiators, when you close the valve a hot radiator will keep heating, and when you open the valve it will take some time to start heating. Also it is often just partly opened which causes water flow to be loud (whining). This depends on the pump also. In my case its annoying sometimes. Depending on the position of the valve in the room you have to figure out what is required offset of read temperature. You can set this offset to the valve, or just set a degree or two higher/lower setting because of it.
I have 60Ā°C in my radiators.
If you want the valve fully closed or fully opened, you have to set it way below or above the current temperature. I think it is possible to open it fully with a command, and close it fully with another command. This could be used in external valve logic, but it takes some motor action (battery drain) to preform 0->100% and back. If I had manual control of the valve, I would probably also use just open/close states, but I would figure it out when it is already fully open (so no whining). So 0% for close and 20% for open on my valves for instance.
Anyway, I still think this is a good product. Batteries are cheap (2xAA) and in my case they are good for one season/year. It is very responsive. I have it set to report changes for 0.2-0.5Ā°C difference or 5% valve change or 60 minutes (had it 10 minutes for first season even). So this is rather aggressive reporting schedule, and is good enough to compute logic to start/stop pump depending on difference between set temperature and read temperature.
For sure, I see how I could improve the logic with manual mode. I hope we some time find a way to make this happen. But even in its default state this is usable product.
Here is todays graph of set vs current temp in one of my rooms:
External thermometer shows 21Ā°C in the afternoon, within a degree. It is quite good result.
And this is its valve % for the same time period:
It seems smart enough.
It does depend on my logic of starting the pump for hot water, I have it set to require at least 2Ā°C of heat (sum of absolutes of differences of set and current temperature must bi at least 2Ā°C for pump to start). But other than that, I only have cron schedule for this room (green graph), and it can be easily overwritten on the valve itself.
Maybe I add also pump run time for the same period. Other rooms had very small effect on these three graphs. Yesterday at 21:00 some other room needed heat.
I hope I shared some insight that may be useful for somebody.
I also hope that manual mode will be enabled. This is a good device and it could be even better. And they have great price in EU (I got mine from amazon.de over 2 years and the price is stable 35-40ā¬).
BR, Andraz
21.4 Ā°C room temp (the value the Spirit has).
20 set temp.
15% valve open (that already heats 100%).
I set the Set temp back to 19:
Valve opens to 100%.
2 times I set the mode to Off / Heat: switches between 0 and 100%.
Again I switch to Off, and back to Heat: This time the valve opens 15%.
Completely random, unpredictabel, very expensive heating costs, and a room that is too warm. Useless stuff without direct valve control.
Maybe you have something else? My device:
Vendor: 0148 Eurotronics
Type: 0003:0001
Firmware: 0.16
vendor Eurotronics
zwave_deviceid 1
zwave_devicetype 3
manufacturerId 0148
manufacturerRef 0003:0001,0003:0003
zwave_version 0.16
Seems the same. I had to finetune the mounting on my valves with a spacer piece to make sure calibration then had correct 0-100%. I focused on 0%, this should turn off the valve completely. I guess this is OK in your configuration. As I understand, setting the mode to OFF and Full are working correctly, and you manage to completely shutoff or open the valve?
I think that if 15% is completely open already, then this can be a problem for internal algorithm. Iām sure that if you would leave it run for few minutes it would close to 0%. But it would be too hot, for sure.
I also notice that the first reaction of Spirit to setting temperature seems random, but in few minutes it will adjust according to the set/actual temperature. Best way to check its reactions is to have graphs of set/read temp and valve percentages. You have to set the reaction differences to small enough to get good graphs. I have 2-5 for temperature (meaning 0.2-0.5 changes are reported) and 5% for the valve change.
If nothing above explains the difference, then my setup works because my pump is not smart and is not running all the time. I control the pump with the differences between set/read temperature over all Spirits. If the sum is > 2Ā°C I turn on the pump. So even if the valve is still open, if the temperature need is below 2Ā°C radiator will not heat. This could be the key differenceā¦
Anyway. If nothing works, you can still make your logic with the OFF and Full Power settings. You will need a separate SET_TEMP variable (you canāt use Spirits). Do your own calculation of differences between read temp and this variable and send OFF or FULL commands to the Spirit. Itās a workaround that I will maybe use for bedroom to get rid f the whine at low % of the valve.
BR, Andraž
Yes, controlling the pump in parallel could be the difference - I canāt control the water flow in my flat.
In theory I could script a rule for OFF / 30Ā°C, but thatās what I have with my FS20 regulators, and Iām still not sure if that would really do it, and I actually donāt want it that way, for reasons. 
Yesterday the valve even opened while the mode was set to OFF. Restarting OH seems to have cured it.
I also did the adaption process of the Spirit again - which always failed, until I removed the batteries.
I also excluded it, removed it from OH & factory reset, to start over cleanā¦
Side note: Charts (generally) do not really work (one of the many oddities I have with OH / HABmin). Maybe because I run it on a Mac.
I tried to graph the room and SET temp, and the dimmer, but it graphs at best the dimmer, and this is an example what the valve does, although the set temp is 3Ā°C below the room temp:
I also realized that I couldnāt rely on the state shown in OH - I hear the valve moving, but itās not updated in OH, looks like the Spirit does not report when the valve does itās āsecret magicā. So I set the polling time for the device from 1 day to 30 seconds, now the valveās state is updated in OH reliable within 30 seconds and I see the irregularities better.
Actually we are a bit offtopic, explaining WHY direct valve control is desired. The Spirit is quite buggy for sure, and I think version number ā0.16ā is well justified, ha ha. 
This thread should disuss HOW direct valve control is possible (avoiding error 31). The zwave binding has not implemented it, and at least I couldnāt follow @Hans_B description how to implement it to the binding yourself.
So I ask @chris : āA few daysā have passed. 
Is the plan dropped to implement it into the binding?
@Hans_B instructions are not clear enough and his post has some missing lines - xml tags.
For modifying the jar you should read @5iverās post ā Modify a zwave binding jar to add/change a zwave device while waiting for a build
Here are the lines to add to spirit_0.0.xml:
<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>
</channel>
and
<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>
</channel-type>
Iām also attaching the full modified file: spirit_0_0.xml (12.3 KB)
After compiling the jar (jar -uf org.openhab.binding.zwave-2.5.0.M1.jar ./ESH-INF/thing/eurotronic/spirit_0_0.xml as per @5iverās instructions), I uninstalled the zwave binding and put the new jar in /usr/share/openhab2/addons/, removed the thing and discovered it again.
The new basic mode channel was detected:
Here a re the items used ā itās still in the test group 
:
Group gSpirit1 (gTest)
Dimmer Spirit1_Dimmer "Spirit1_Dimmer [%d %%]" (gSpirit1) {channel="zwave:device:1628a3e05cc:node85:switch_dimmer"}
Number:Temperature Spirit1_CurrentTemperature (gSpirit1) {channel="zwave:device:1628a3e05cc:node85:sensor_temperature"}
Number Spirit1_ExternalTemperature (gSpirit1) {channel="zwave:device:1628a3e05cc:node85:sensor_report"}
Number Spirit1_ThermostatMode (gSpirit1) {channel="zwave:device:1628a3e05cc:node85:thermostat_mode"}
Number:Temperature Spirit1_SetpointHeat (gSpirit1) {channel="zwave:device:1628a3e05cc:node85:thermostat_setpoint_heating"}
Number:Temperature Spirit1_SetpointEnergyHeat (gSpirit1) {channel="zwave:device:1628a3e05cc:node85:thermostat_setpoint_heating_econ"}
Switch Spirit1_AlarmSystem (gSpirit1) {channel="zwave:device:1628a3e05cc:node85:alarm_system"}
Switch Spirit1_AlarmPower (gSpirit1) {channel="zwave:device:1628a3e05cc:node85:alarm_power"}
Number Spirit1_BatteryLevel (gSpirit1) {channel="zwave:device:1628a3e05cc:node85:battery-level"}
Number Spirit1_BasicMode (gSpirit1) {channel="zwave:device:1628a3e05cc:node85:basic_mode"}
in openHABās console send the new mode to the basic_mode channel:
openhab> smarthome:send Spirit1_BasicMode 254
and here is the result:
2019-10-31 16:28:35.004 [nt.ItemStatePredictedEvent] - Spirit1_BasicMode predicted to become 254
2019-10-31 16:28:35.006 [vent.ItemStateChangedEvent] - Spirit1_BasicMode changed from NULL to 254
2019-10-31 16:28:36.872 [vent.ItemStateChangedEvent] - Spirit1_Dimmer changed from 38 to 20
Then, I tried the direct control of the valve and set the dimmer to some value - in this case 67:
2019-10-31 16:28:58.676 [ome.event.ItemCommandEvent] - Item 'Spirit1_Dimmer' received command 67
2019-10-31 16:28:58.677 [nt.ItemStatePredictedEvent] - Spirit1_Dimmer predicted to become 67
2019-10-31 16:28:58.684 [vent.ItemStateChangedEvent] - Spirit1_Dimmer changed from 20 to 67
2019-10-31 16:29:00.887 [vent.ItemStateChangedEvent] - Spirit1_ThermostatMode changed from 1 to 31
2019-10-31 16:42:55.038 [vent.ItemStateChangedEvent] - Spirit1_CurrentTemperature changed from 24.17 Ā°C to 24.62 Ā°C
The display of the TRV is displaying the valve opening percent, not the setpoint temp:
EDIT: HERE is the modified 2.5 M1 jar Iām using now
Thanks so much for your detailed instructions @Mihai_Badea. I downloaded your M1 jar, removed the zwave binding via PaperUI, logged out of OH, put your jar into
/Applications/openhab/addons/org.openhab.binding.zwave-2.5.0.M1.jar
and I also tried the ānativeā location:
/Applications/openhab/userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.zwave-2.5.0.M1.jar
I also have a folder āAdditional add-on filesā inside āaddonsā, which also didnāt work.
I was playing with this and that - in all cases OH does not recognize the binding - Things remain āuninitialisiedā, and in the binding list the zwave binding status is ānot installedā. If I click āInstallā it always downloads the official binding, and I donāt get basic mode.
Ok, to answer my own question, I guess I didnāt follow Mihaiās instructions carefully enough (it was late at night). 
Maybe helpful for other tired noobs like me, this is how it worked for me today:
As Iām not using Thing-definition files (yet) Iām in PaperUI only. To find out where to send the āspecial 254 commandā I did this:
And now I can use the slider to directly control the valve. 
@Mihai_Badea: Kisses, beer, roses, hard drugs, whatever you want! 
Your very helpful instructions (and your ready-to-use jar) came on the right second - my plan for today was to try Domoticz, as I read it has valve control for the Spirit implemented ( https://www.domoticz.com/forum/viewtopic.php?f=50&t=21417&hilit=eurotronic+valve&start=20#p202547 ).
Thank you very much!
@chris: I (and probably some other people) still hope valve control will be implemented in the official binding, so we donāt have to hack the binding every time when it updates. 
That would be really great!
