Eurotronic Spirit - Unsupported mode type 31

bolemo · February 1, 2020, 2:01pm

FraPi already did that back in December:

While waiting for this to be fixed, the only solution is to patch the .jar file, and a lot of that is described and discussed in this thread. Since the solution (and files) mentioned here are for version 2.5.0M1, I posted updated files for the 2.5.1 that is the actual stable release.

And I also keep this thread alive as it is for now the the only place with a working solution.

chris · February 1, 2020, 2:06pm

I’m actually surprised that this works since the XML defines a channel that does not exist -:

	  <channel id="basic_mode" typeId="eurotronic_spirit_00_000_basic_mode">

I’ll tke a look at this, but it will likely be a different channel type (ie one that exists ).

chris · February 1, 2020, 2:08pm

The channel will be basic_number and it should be in the database tomorrow.

FraPi · February 1, 2020, 2:38pm

Great news! Thank you, Chris!

bolemo · February 1, 2020, 3:20pm

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.

chris · February 1, 2020, 3:23pm

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

Giuseppe_Magnotta · March 23, 2020, 10:41am

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

FraPi · March 23, 2020, 7:31pm

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.

Giuseppe_Magnotta · March 24, 2020, 6:27am

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

FraPi · March 24, 2020, 3:48pm

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).

Giuseppe_Magnotta · March 24, 2020, 4:18pm

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

FraPi · March 24, 2020, 6:21pm

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

Giuseppe_Magnotta · March 27, 2020, 7:52am

Hi,

thanks for the suggestion.

I will try and let you know.

Regards,
Giuseppe

Giuseppe_Magnotta · March 29, 2020, 4:42pm

Hi Frank,

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

What should I do?

Thanks

Regards,
Giuseppe

cris · March 29, 2020, 11:54pm

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.

kristofejro · October 29, 2020, 9:32pm

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.

Bruce_Osborne · October 29, 2020, 10:46pm

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

FraPi · October 30, 2020, 5:40am

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:

SebastianCornea · October 30, 2020, 6:38am

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.

cris · October 30, 2020, 9:31am

@kristofejro

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.