Eurotronic Spirit Z-Wave errors

Tags: #<Tag:0x00007f616ef369a8> #<Tag:0x00007f616ef36778> #<Tag:0x00007f616ef364a8>

Hi there,

I’ve just recently bought a Eurotronic Spirit Z-Wave thermostat. While inclusion an reading values goes quite smoothly I cannot set any values (e.g. temperature setpoint). The logfile shows an error:

2018-04-15 17:36:16.434 [ome.event.ItemCommandEvent] - Item ‘Thermostat_SetpointHeat’ received command 20.5 one
2018-04-15 17:36:16.447 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Command received with no implementation (QuantityType).
2018-04-15 17:36:25.337 [WARN ] [ore.internal.thing.ThingTypeResource] - Cannot find channel type: zwave:sensor_report

I use the latest snapshot version of the zwave binding and OH2. Any ideas?

Regards,

Udo Eisenbarth

Nobody has else has experienced these problems? Any ideas?
The issue still exists with the latest snapshot 2.3.0 #1271. Meanwhile I found out that the problem only shows up for some commands (like the temperature set point). Setting the “Dimmer” value (which is actually the valve position I think) to 0 (Off) works without any problems.

This is a bug in ESH - it is being fixed and I think the change may have already been made.

Thank you for your replay. I’ve checked it in my installation. I am using ESH 0.10.0.201805051943 (the latest I think…). BTW: Is this error the cause for the set point temperature not actually being set? If I set the value e.g. to 19 °C the corresponding item changes its value but the hardware device stays at the old value. After the regular update interval (one hour I think in my case) the hardware sends the real value back the item is set to its true (old) value.
Another point: What is this “zwave:sensor_report”?

If you are still seeing this error, then the issue still exists and has not flowed into the version you are running.

This allows sending of external temperature sensor data to the device. I’m not sure if it has been tested.

Hello folks, I am also having this issue. I was working perfectly with OH 2.3.0’s latest snapshot prior to converting to 2.4.0 yesterday. When I made the leap to the latest snapshot, I lost the ability to set my setpoints for heating and cooling on my thermostat. I am using a Honeywell Z-wave thermostat the boring old green screen looking one but it works really well or at least did until yesterday. Looking through my logs, I see the following

==> openhab.log <==
2018-07-15 20:13:21.892 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Command received with no implementation (QuantityType).

Now everything else on the thermostat is working as expected so I imagine its the same issue as above. I also updated to the latest z-wave binding so I checked everything there. Lastly, I have removed the things and items and rebuilt the entire thermostat but I did not try removing the node from the uzb stick. I really doubt at this point that it would fix anything especially with the comments above. Either way, if anyone can point to a solution that would be great. @chris is this a bug in the new z-wave bindings or am I missing something?

Note that there is no change between these versions, so you might want to look at other factors.

The current master does not (and have never) support the QuantityType. You probably should use Number instead.

That’s the part that gets me, the thing / item is set as a number. I never changed that during the upgrade… Anything you see here that looks wrong? By the way I am using the development binding updated about a day or two ago.

Ok, then it’s a completely different answer! The development binding should support QuantityType - this isn’t a recent change either and it was added a couple of months back (beginning of May).

I would suggest to delete the thing and add it back again so that it picks up the latest thing definition. It’s possible that your thing definition is the old definition, but with the update to the newer runtime, it’s sending the new type.

@chris thanks for getting back to me. I have some odd behavior and wanted to run it by you. I have deleted both the thing and items a few times already and have the same symptoms where everything works except the heating and cooling setpoints. Do I need to remove the node all together and the re-add? When I removed the thing and items, stop OH, clear cache, restart and bring the thing back in, all the items automatically show up a few seconds later which I am not expecting since I deleted them earlier. Any clue on why? Any suggestions? It seems the info isn’t getting removed when I delete the thing and items.

This may depend on how you have OH configured. There are options to automatically approve new things that are added to the inbox, and there is an option to automatically create items for new things. The binding will add any devices it finds on startup in to the inbox - if you have auto approve enabled, and “simple mode” enabled, then this will automatically create the thing and the items.

Maybe this explains it?

That was a good idea to check that as I had not but I have those both off. Adding pic to make sure we are talking about the same thing.


I have also tried adding them via PaperUI and Habmin with same results.

Yes - that’s what I was talking about.

I’m not sure then - sorry. If the thing is coming back after it’s deleted, and adding channels etc,then I guess something in the core is not deleting the data. The only other thing I can think of, which is probably not likely, and that is if the json database isn’t being updated. If it was not re-written when the thing is deleted, then they would re-appear when the system is restarted.

It’s a longshot, but after that, I’m not sure what would cause this.

Ok I can remove now and wait till afternoon to add back. I’ll take a look at the jsondb as well (although I’m not too familiar with an easy way to search in there) to make sure it’s not there and go from there. If that doesn’t work I will try removing the node and see if that works. I’ll let you know how it goes. Thanks again for getting back to me.

Ok so I looked through the jasondb thing and items files and I found nothing. There was no mention of the thermostat which is good. I went ahead and added the thing and again, it populated all the items. So I thought ok its weird but let’s go with it. I tested again and nothing still not working. I deleted all the items and recreated them with different names just I had done with the thing. Still nothing. I then removed all traces of things and items and verified they were gone from the jasondb files. At this point, I was out of ideas so I went ahead and removed the node and then I added it back again. No issues doing that but again everything works except for the setpoints for cooling and heating. Back to square one. Also validated json files are updating correctly as you suspected. The openhab.log shows the same thing only with a different node number now.

2018-07-18 23:03:11.490 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 71: Command received with no implementation (QuantityType).

Either way, if anyone thinks of anything, i’m about to try anything. That’s actually the feature I use most in the thermostat :frowning: . Here is how my item is set up…( by default I must add)

Did you create the items in a file or using PaperUI? If in a file, could you please post them?

Please use the latest binding, and check the debug logs during the binding initialisation to see if there are any errors during the thing handler initialisation.

@5iver I created everything with PaperUI.

@chris The only thing that catches my eye as a warning is this below but it doesn’t seem like that would cause an error as the thermostat value I assume should be a decimal. I messaged you a bigger section of the debug output.

2018-07-19 07:46:43.654 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 71: Invalid item type defined (DecimalType). Assuming DecimalType

Moving to this thread as it seems others are having the same issue. honeywell-zwave-thermostat-in-openhab2

Are you sure you are using the latest development binding? This error should not occur like this in the latest binding, so I’m suspicious that you are using an older one?