It worked because the commandClass:COMMAND_CLASS_BASIC is in the properties. Anyway, updating the database with the right channel is the way to go, and a big THANK YOU for that.
What do you mean?? This has no real bearing on the fact that there is no channel-type defined. Normally OH will throw an error if there’s not channel type defined for a channel and will not instantiate the thing.
The previous XML (at least the one I looked at) used something like basic_mode which is not defined in the channels file in the database. Without this it won’t work. I assume therefore that at least some people using this must have also changed the channel file.
edit: I missed that the channel is defined in the xml, so all’s explained 
1 Like
Hi guys,
I’ve updated the issue on github. I’m on openhab 2.5.3 and I’m still having the issue “Unsupported mode type 31” although I send the basic_numer 254.
Please find attached the log in the github issue.
Please, could you help me?
Thanks
My experience with openhab 2.5.3 using both channels, basic and thermostat mode:
Once a value (number) is assigned to the item that is linked to the basic channel, setting thermostat mode to manufacturer specific (31 decimal) doesn’t cause an error message.
I get “Unsupported mode type 31” only when
- no item is linked to the basic channel
- the value of the item linked to the basic channel is -NaN
by setting thermostat mode to 31.
I guess that there is no need to use basic channel and thermostat channel in parallel. All modes of the Eurotronic Spirit including “Manufacturer Specific” can be set via the basic channel. I propose to deactivate the thermostat mode channel (ensure that no items are linked to the thermostat mode channel) and “Unsupported mode type 31” won’t occur anymore.
Hi Frank,
thank you for your suggestion!
I’ve tried to remove all the channels apart the basic and the dimmer.
I send the 254 command and then I try to update the switch:
2020-03-24 07:23:21.178 [ome.event.ItemCommandEvent] - Item ‘zwave_device_b4728f7c_node16_basic_number’ received command 254
2020-03-24 07:23:21.183 [nt.ItemStatePredictedEvent] - zwave_device_b4728f7c_node16_basic_number predicted to become 254
2020-03-24 07:23:21.212 [vent.ItemStateChangedEvent] - zwave_device_b4728f7c_node16_basic_number changed from 253 to 254
2020-03-24 07:23:32.869 [ome.event.ItemCommandEvent] - Item ‘zwave_device_b4728f7c_node16_switch_dimmer’ received command 30
2020-03-24 07:23:32.872 [nt.ItemStatePredictedEvent] - zwave_device_b4728f7c_node16_switch_dimmer predicted to become 30
2020-03-24 07:23:32.896 [vent.ItemStateChangedEvent] - zwave_device_b4728f7c_node16_switch_dimmer changed from 0 to 30
2020-03-24 07:23:34.619 [vent.ItemStateChangedEvent] - zwave_device_b4728f7c_node16_switch_dimmer changed from 30 to 0
2020-03-24 07:23:36.947 [ome.event.ItemCommandEvent] - Item ‘zwave_device_b4728f7c_node16_switch_dimmer’ received command 61
2020-03-24 07:23:36.949 [nt.ItemStatePredictedEvent] - zwave_device_b4728f7c_node16_switch_dimmer predicted to become 61
2020-03-24 07:23:36.960 [vent.ItemStateChangedEvent] - zwave_device_b4728f7c_node16_switch_dimmer changed from 0 to 61
2020-03-24 07:23:38.660 [vent.ItemStateChangedEvent] - zwave_device_b4728f7c_node16_switch_dimmer changed from 61 to 0
Basically the dimmer returns automatically to 0 ignoring any value I give it!
What should I do?
Thanks
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
strange…
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
Hi,
thanks for the suggestion.
I will try and let you know.
Regards,
Giuseppe
Hi Frank,
I tried your suggestion but I still have the same problem.
What should I do?
Thanks
Regards,
Giuseppe
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 
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!
Hi,
Winter came and the Spirit started to live with its own life again - my wife is telling mi to get rid of those 
. 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 = 0It’s working fine for me in OH3. The basic endpoint should be available.
I’m sending 0xFE to the ‘basic_basic_number’ endpoint:
Item:
Number KitchenTrvThermostatBasic "Basic endpoint" {channel="zwave:device:65ff760b:node6:basic_basic_number"}
Rule:
logInfo("Kitchen", "Setting TRV to 'Manufacturer specific' mode")
KitchenTrvThermostatBasic.sendCommand(0xFE)
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"}
KitchenTrvValvePosition.sendCommand(50.0)
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.