Eurotronic Spirit - Unsupported mode type 31

After sending the “254 command” open PAPER UI => Control and check whether your Node 016 is displayed in a similar manner.


The displayed value of the item linked to the basic channel should be 254 and changing the dimmer value should work (new dimmer value should remain).

Same behavior as before:

TRV is off; I send the 254; dimmer remains to 0; I try to move the dimmer; dimmer goes back to 0.

I’m using the original jar files from 2.5.3. The xml is the official one.

Are you using a custom jar file?

The firmware of the TRV is 0.16; device is 0148, 0003:0001.

Any other idea?

I bought 5 of those expecting I could set manually the valve opening…

Thank you for your help

I use the offical zwave binding 2.5.3 as well and my device parameters are the same.

Maybe the following steps will solve the issue:

  • delete the Thing (Z-Wave Node 016) via PAPER UI (Configuration => Things => Node 016 => trash icon)
  • uninstall the zwave binding in PAPER UI (Add-ons => BINDINGS => Z-Wave Binding => UNINSTALL)
  • delete the Thing’s XML file $OPENHAB_USERDATA/zwave/network_xxxx_node_16.xml
  • install the zwave binding via PAPER UI (Add-ons => BINDINGS => Z-Wave Binding => INSTALL)
  • in PaperUI, add the Spirit again from the Inbox. Perform a scan and add Node 016


thanks for the suggestion.

I will try and let you know.


Hi Frank,

I tried your suggestion but I still have the same problem.

What should I do?



I’m on 2.5.2, so what your problem is might be unrelated to mine. But I also couldn’t get it work (deleted Thing & XML files).

On a fresh install it worked for me, so to just find out if it’s a problem with 2.5.3 in general, or something in your installation, you could backup your current installation and try with a fresh 2.5.3 install.

I am on OH 2.5.10 and just installed Eurotronic Spirit.
Binding is also in ver. 2.5.10.
I have been reading this all thread and still don’t know if I can make it run in manual mode.
Thing was added to OH via PaperUI and all items were created in config files.
Item with basic_number is linked to thing channel but value is always -NaN
When changing mode to manual I get: “Unsupported mode type 31”

Can someone explain me in simple words what can I do to run it in manual mode?

As I understand fix was applied to binding but should I edit xml file?

Thanks for any suggestions and help.

Have you followed the binding documentation to enable DEBUG logs to get more information from the system? That should be the first troubleshooting step.

You have to assign the value 254 to the item linked to the basic channel. If you haven’t linked an item do this (including bullet list that I cannot quote):

Then do the following:

1 Like

Does the basic channel show up in the channel list?

if it doesn’t you have to delete the thing and add it again.
After that you just need to set the value 254 for the basic channel and it should work.


The tips with the .jar file, or sending commands manually, or using the Basic-Channel are actually outdated. The current binding should support the Spirit directly.

However, as noted earlier, I couldn’t make it work without a fresh install of OH, and it seems I was not the only one.

So it’s indeed a good idea to enable debug log, to (hopefully) see why it doesn’t work in an existing installation, so @chris can probably fix it.

Or you try in a fresh test install.

This is from my working setup, maybe helpful for your testing:

Enabled channels - “Basic” is no longer necessary, and how knows - probably counterproductive?
You will also not need the “External temperature”.

Item definitions:

Number WZ_Heizung_ReglerEcke_TemperaturSoll "WZ Heizung Soll-°C: [%.1f]"    <temperature>  (WZ_Group, HeizungSollGroup)                                 {channel="zwave:device:xxx:node17:thermostat_setpoint_heating" }
Number WZ_Heizung_ReglerEcke_Temperatur     "WZ Heizung °C: [%.1f]"         <temperature>  (WZ_Group, TemperaturGroup)                                  {channel="zwave:device:xxx:node17:sensor_temperature" [profile="offset", offset="2.1 °C"]}
Dimmer WZ_Heizung_ReglerEcke_Ventil         "WZ Heizung Ventil [%d %%]"     <faucet>       (WZ_Group, HeizungVentilGroup, Chart_TemperaturRoomsGroup)   {channel="zwave:device:xxx:node17:switch_dimmer"}
Number WZ_Heizung_ReglerEcke_Modus          "WZ Heizung Modus: [%d]"                       (WZ_Group)                                                   {channel="zwave:device:xxx:node17:thermostat_mode"}
Number WZ_Heizung_ReglerEcke_Batterie       "WZ Heizung Batterie [%.1f %%]" <batterylevel> (WZ_Group, BatterieGroup)                                    {channel="zwave:device:xxx:node17:battery-level"}
Number WZ_Heizung_ReglerEcke_Protection     "WZ Heizung Tasten sperren"                                                                                 {channel="zwave:device:xxx:node17:protection_local"} // Ohne Group nur in PaperUI verstellbar, ok.

Side note, should’nt matter: I’m still on OH 2.5.6 as I have no reason to update before OH 3 comes.

Thank you guys for your help :slight_smile:

I just missed “magic command” to be executed in console. This thread is so long and I wanted to read it all before posting.
After your suggestions I have managed to solve the problem.

Thank you again!


Winter came and the Spirit started to live with its own life again - my wife is telling mi to get rid of those :face_with_symbols_over_mouth:. I moved to OH3 but it seems that mode 31 is still disabled.

I’m trying to test it using simple rules - I send the command to switch to manual mode but it responds with error about unsupported mode.

Is there a “proper” way of switching it to manual control? Basic channel is not available in OH3.

2021-01-23 18:17:52.027 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'GabinetGrzejnikNode10_Thermostatmode' received command 31

2021-01-23 18:17:52.055 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'GabinetGrzejnikNode10_Thermostatmode' predicted to become 31

2021-01-23 18:17:52.075 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GabinetGrzejnikNode10_Thermostatmode' changed from 1 to 31

==> /var/log/openhab/openhab.log <==

2021-01-23 18:17:52.080 [ERROR] [lass.ZWaveThermostatModeCommandClass] - NODE 10: Unsupported mode type 31

2021-01-23 18:17:52.084 [WARN ] [nverter.ZWaveThermostatModeConverter] - NODE 10: Generating message failed for command class = COMMAND_CLASS_THERMOSTAT_MODE, endpoint = 0

It’s working fine for me in OH3. The basic endpoint should be available.

I’m sending 0xFE to the ‘basic_basic_number’ endpoint:


Number  KitchenTrvThermostatBasic "Basic endpoint" {channel="zwave:device:65ff760b:node6:basic_basic_number"}


logInfo("Kitchen", "Setting TRV to 'Manufacturer specific' mode")

Then I control the TRV by sending the valve open % to the ‘switch_dimmer’ endpoint.

Dimmer KitchenTrvValvePosition "Kitchen TRV valve position"{channel="zwave:device:65ff760b:node6:switch_dimmer"}


You don’t have an old JAR lurking in your addons folder do you?

Or try deleting (NOT excluding from the network) & re-discovering the Thing in OH to be sure it has the latest settings from the binding.

I think I have cleaned up everything although I was migrating from 2.5 not reinstalling from scratch.

I recently was adding new Thing as it went in to locked state and I had to reset it to defaults as nothing else worked. After adding it as fresh it has Basic endpoint (rest of my old migrated things doesn’t have it - seems that starting from scratch would set up things properly).

Anyhow I tried with this channel here are the results:

2021-01-23 20:52:26.424 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LucjaNode017Grzejnik_BasicDeprecated' received command 31

2021-01-23 20:52:26.447 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LucjaNode017Grzejnik_BasicDeprecated' predicted to become 31

2021-01-23 20:53:41.417 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LucjaNode017Grzejnik_Dimmer' received command 50

2021-01-23 20:53:41.430 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LucjaNode017Grzejnik_Dimmer' predicted to become 50

2021-01-23 20:53:41.439 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LucjaNode017Grzejnik_Dimmer' changed from 0 to 50

2021-01-23 20:53:43.014 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LucjaNode017Grzejnik_Dimmer' changed from 50 to 0

This haven’t changed anything it was still in Heat mode.

Then I tried to send raw value

2021-01-23 20:55:59.775 [WARN ] [ule.handler.ItemCommandActionHandler] - Command '0xFE' is not valid for item 'LucjaNode017Grzejnik_BasicDeprecated'.

I’m using this new rules engine for experiments - not sure if this matters


@Morgano thanks for the tip I found the solution! When I went to old rules engine (application/vnd.openhab.dsl.rule)

And I did execute


2021-01-23 21:06:51.273 [INFO ] [openhab.event.RuleUpdatedEvent      ] - Rule '150f3fa9a0' has been updated.

2021-01-23 21:06:56.286 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LucjaNode017Grzejnik_BasicDeprecated' received command 254

2021-01-23 21:06:56.306 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LucjaNode017Grzejnik_BasicDeprecated' predicted to become 254

2021-01-23 21:06:56.319 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LucjaNode017Grzejnik_BasicDeprecated' changed from 31 to 254

Then dimmer started to work!

2021-01-23 21:07:55.521 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LucjaNode017Grzejnik_Dimmer' received command 50.0

2021-01-23 21:07:55.534 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LucjaNode017Grzejnik_Dimmer' predicted to become 50.0

2021-01-23 21:07:55.545 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LucjaNode017Grzejnik_Dimmer' changed from 20 to 50.0

2021-01-23 21:07:57.197 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LucjaNode017Grzejnik_Currenttemperature' changed from 22.56 °C to 22.47 °C

2021-01-23 21:08:09.989 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LucjaNode017Grzejnik_Dimmer' received command 21

Now that it works the question is did anyone implemented already any type of simple controller (kind of PID rule updated every X min). When I looked at implementations the actual PID regulators and started to think about one for heating is not as straight forward compared to usages when there is really quick change output values. With the room of size 12m2 setting up the dimmer to 100% will change the temp after 10min and then there is question how frequently to uptdate the dimmer.

@Dominik_Jeziorski There is a new experimental PID Controller available here:

I have used it on my TRVs and it is working really well. It uses the new GUI Rule Engine but will work in conjunction with Rules DSL rules. Read through the whole thread before doing anything.

I have set my PIDs to loop every 60s which may be too fast but I am still tweaking things at the moment.

Wow! Thanks.

Based on PID implementation I made tutorial how to use Spirits with manual mode - I hope that will be usable for others seeking solution for problems with those.

1 Like