State of support of Eurotronic Sprit Z-Wave Plus

Add-ons Bindings
,
1

Hi

I just started into the world of home automation. So what I write here might just be plain wrong or I’m just lacking proper information to do it right. Please let me know…

So I bought a Eurotronic Spirit Z-Wave thermostat. So far the device seems to work quite well with OpenHAB. (Except for the communication problem on greater distances, discussed in the other thread.) However it seems to me that the support for this device is at least partially somewhat wrong or incomplete. Maybe this can help to improve the support. So here is what I found playing around with the device:

Setpoint for energy heating mode not possible:

Setting temperature for Heat mode works fine (channel thermostat_setpoint_heating). It should also be possible to set the temperature for the Energy Heat mode, but this somehow does not work for me. The channel is called thermostat_setpoint_furnace. Already the name is irritating. Looking into the device database (I’m not sure anymore where I saw this…) Furnace is mode 7, which is also what I see being sent when looking into zwave debug logs. Energy heating in this database is 11, though. This is also what the device manual says. So … it seems there is something wrong in the OpenHAB device specification?

Unsolicited updates for temperature of value position (maybe more) not working

If I understand the device manual or the hints in the OpenHAB UI correctly the device should report changes of temperature or valve position as soon as it changes by a configured amount, like 0.5°C or 1%. However this never seems to happen. All I see are updates at the regular 30min polling frequency. (Although there are sometimes updates missing. Maybe because of the thresholds are still applied to the 30min polls? Or maybe this is just due to the communication problems …)
Not sure if this is related, but I’m seeing this in the logs:

2018-03-15 00:21:59.436 [WARN ] [ore.internal.thing.ThingTypeResource] - Cannot find channel type: zwave:sensor_report

Whatever this means … could this be the reason? In the device manual I see a SENSOR_MULTILEVEL_REPORT… compared to sensor_report.

Maybe being able to reduce the polling frequency could also reduce the somewhat high battery drain I’m seeing. But for this the unsolicited updates should work.

Valve position is called “Brightness”

The channel for valve position is called “switch_dimmer” and when I create a default item from it in PaperUI it’s called “Brightness” and gets the icon “DimmableLight”. Pretty confusing… esp. for newbies. Took me a while to figure out that this is apparently the valve position. Can it be renamed in the device spec to something more suitable?

Setting thermostat modes

I can set thermostat modes Off (0), Heat (1), Energy Heat (11 / 0xB) and Full Power (15 / 0xF) just fine. However, according to the manual there is also a Manufacturer Specific (31 / 0x1F) mode. This one should allow directly setting the valve position. But when I try setting it I just get:

23:51:42.953 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'ZWaveNode2SpiritThermostaticValve_ThermostatMode' received command 31
23:51:42.954 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Command received zwave:device:f06c8080:node2:thermostat_mode --> 31
23:51:42.963 [INFO ] [smarthome.event.ItemStateChangedEvent] - ZWaveNode2SpiritThermostaticValve_ThermostatMode changed from 0 to 31
23:51:42.979 [DEBUG] [class.ZWaveThermostatModeCommandClass] - NODE 2: setValueMessage 31, modeType empty false
23:51:42.991 [DEBUG] [class.ZWaveThermostatModeCommandClass] - NODE 2: Unsupported mode type 31
23:51:42.997 [WARN ] [onverter.ZWaveThermostatModeConverter] - NODE 2: Generating message failed for command class = THERMOSTAT_MODE, endpoint = 0
23:51:43.004 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: No messages returned from converter

Also it would be great if I could see somewhere what are expected and allowed inputs for setting the mode. I didn’t even know whether I should enter numbers or strings, and if so which ones… Like for the configs, there are good hints in PaperUI/Habmin about what are possible values.

Alarms

There are two mysterious alarm channels alarm_system and alarm_power. I have no clue what values to expect from them. And it’s a bit hard to test. Default items created are switches, which means they are just On/Off, right? But according to the device manual there are two different power warnings, at 25% and 15% battery level and for system alarms there are 4 different errors. So, how does that fit together? Also here some documentation in the UI would be helpful. (Or in the device wiki page.) Also default item for alarm_power gets a confusing “Door” icon, alarm_system gets no category at all…

Encryption

The device is supposed to support encrypted communication. Is this used? Can I verify this somehow?

Thanks

Michael

1 Like
2

Hmm… anyone an idea regarding the mentioned points and questions? :slight_smile:

Something I also wonder is where the information regarding the device comes from i.e. where to fix/improve it? What commands are available (or whatever the proper z-wavey term is), how parameters should be interpreted, what values are allowed and what not, where the item names and categories come from etc… I found some device information in the ZWave addon github repo, but this can’t be all the information. At least it doesn’t explain my questions… I came across this cd-jackson.com database, which seems to be related, but it’s not clear to me how.

3

All your points seem valid to me. Most of them are having to do with the definitions of the channels. I’m not sure however whether there are more command class flavours to make things like ‘valve opening position’ more meaningful, since it’s implemented as a “SWITCH_MULTILEVEL”, which is indeed usually used for a dimmable light. (See http://zwavepublic.com/sites/default/files/command_class_specs_2017A/SDS13548-5%20List%20of%20defined%20Z-Wave%20Command%20Classes.pdf for a list of available command classes.)

However besides these seemingly strange command classes, these could at least be explained by the definitions of the Spirit device better. I am not an expert, but I guess there could be descriptions added to make this more clear. For example, the SENSOR_MULTILEVEL command classes list clearly ‘Current temperature’ and ‘External temperature’. And the THERMOSTAT_MODE clearly lists the different options.

The database at http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/710 is amazing. For the Spirit Z-Wave Plus however, I guess it needs to be updated a little? I’m not 100% sure but isn’t OpenHAB’s device list based on this?

4

Yes - the database is directly exported into the binding - so it’s 100% based on this :wink:

If you want to update anything, then please feel free - I’m sure the community would welcome it. Just register and drop me a mail so I can update your access for editing.

http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-database-guide

5

On the other hand the device database says Dimmer, which seems to become the channel label (similar to Setpoint (heat)). Maybe this could also be changed to something like Valve position? Where do the channel names come from? (For the Dimmer it’s switch_dimmer, while for the Setpoint (heat) it’s thermostat_setpoint_furnace…).
And how does OpenHAB know what type an item is of? Why is something a Number, a Switch or a Dimmer? Why has this one alarm a Door icon? That information must come from somewhere, but from where…?

Do you think OpenHAB would be able to show the descriptions for the channels/items (like it does for the config options of the device)?

Great! But up to now I’d have no clue what to change and what would be correct :wink: And how does the update process work, i.e. when and how does an update reach the end user? If I check the Spirit page @Gabri linked above I see Last updated by Roy Jacobs on 2018-02-22 11:19:14 ... and last exported on 2018-03-11 10:51:07. However when I check openhab1-addons/bundles/binding/org.openhab.binding.zwave/database/eurotronic/spirit.xml at main · openhab/openhab1-addons · GitHub the last update is from 3 months ago. Or is this the wrong place? And then when will this be delivered to the end user, together with an OpenHAB release? Or are the addons updated more frequently? Also this XML file seems to contain way less information than the device database page. On the other hand I don’t see this “furnace” setpoint referenced anywhere, also not on the device page. But it’s there… I’m obviously missing something… Still all pretty mysterious for me…

6

I’d like to know as well how automated the process is of including the device database in the master builds (and thus included in the snapshots). This part is not explained at http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-database-guide. Seeing the date discrepancy redm hints at, between the database and Github, is this a manual process?

7

Yes - of course it is manual. I don’t think having a fully automated system where people can type something into the database and it magically appears in the master release is a good idea. There is a review process which dictates a manual step to make sure that people have entered data correctly, and not removed things they shouldn’t that could mess up things for others.

Once this review is done, the data is automatically exported when we click the “approve” button, and then I create the PR manually.

This is done once or twice a week as it takes a couple of hours to review changes and fix issues.

8

Sorry for my ignorance, but the approval process seems very well implemented. So why is automated export not a good idea if things have been approved by you or others anyway? Seems to be quite a waste of your time if it takes you a couple of hours every week. (Just trying to understand.)

I also don’t know what you mean by PR.

9

I didn’t say it wasn’t automatically exported. I said it was -:

It’s not the export that takes the time - this is automatic. What takes the time is the reviewing of the changes and fixing of the issues because people make mistakes etc. This is not meant as a criticism - I appreciate it’s a daunting array of data and without some knowledge it can be difficult. This is still a LOT less time than I used to spend in OH1 when all the XML files were generated by hand.

The PR is the only manual part - it’s the pull request to actually import the data into Github. It takes all the auto-generated files that were exported from the database and creates the import into Github.

I hope that helps explain things. With the database I tried hard to put as much automation in place, with automated error checking, automated generation and export of the files, automated documentation generator. However it still takes time to manually check this and update things when people ignore the warnings (which unfortunately does happen a lot and I’m slowly making more of them errors to try and enforce data entry and consistency).

10

One thing I don’t understand yet. I can’t seem to find the files at https://github.com/openhab/openhab2-addons/tree/master/addons/binding. There seems to be no Z-wave binding…

Quite clear, thanks. It’s a terrific system you made. HABmin too. The whole community thanks you. :slight_smile:

It would be nice though and receive more exposure if the database could be linked on GitHub - openhab/org.openhab.binding.zwave: openHAB binding for Z-Wave, along with your explanation above!

11

It’s in a separate repository - just look in the openhab organisation on Githib. You linked to it already in your message.

12

Yes, I thought as much, but I cannot find the XML files exported from the database there.
edit: didn’t look too well, found it…

13

The XML files are exported into the repository above. As per ESH standards, they are in the ESH-INF folder.

14

Ha! That was the missing piece, now things start to make sense. All I found was GitHub - openhab/openhab1-addons: Add-ons for openHAB 1.x, but that seems outdated, right?

So now the remaining question is: when and how does this hit the masses? Do I see it right, that this is pulled right into openhab-distro and then always released together with openhab releases? I.e. no separate updates of only the zwave binding?

So quickly looking over this XML file it seems some of my points are already fixed in recent versions, like this furnace thing now being correctly economy heating. Cool! Will have a closer look when I have some time.

15

Yes - as the name suggests - it’s the openHAB-1 addons repository :wink: .

It’s all part of OH2 even if it’s a separate repository - it doesn’t matter…

16

I just wanted to comment on this. You should be careful on interpreting these since sometimes people will make a “change” that doesn’t actually result in any changes to the database files that get uploaded into the binding. The database contains a lot of information that is not used in openHAB. Sometimes people will also upload their XML files - this gets logged in the database as a change since the XML is stored into the database, but very often, no change is actually made.

I just checked the database and the version in the binding is consistent with the version in the database so there is no issue.

17

Thanks Chris. Sounds a bit vague though… is it documented somewhere which fields are used in OpenHAB and which are not?

18

Not really, but you can easily see what is used by clicking on the Export button on the database. This will show the actual file that is exported, so you can see what data is included.