OpenHAB-2 Z-Wave channel types

Currently, the Z=Wave binding assumes that item types are as defined in the ESH documentation.

There have been a few discussions about this table since not everyone agrees with the definitions…

For the Z-Wave binding, the channels that can be set are defined (here)[]. You should note that with the way that ESH/OH2 works, you MUST use the item type defined in this table - you simply can’t set any item type, despite what you think.

Anyway, as we’re not required to stick to the definitions in ESH referenced above, I’ve now added a channel type called sensor_door. If this type is used, then it will allow a contact type to be used.

So, if you have a device that is a door/window sensor, then please feel free to update the database. To do this, go to the page for the device in the database, scroll down to the endpoints list and edit the endpoint to change the channel to sensor_door. Again, please only do this for this type of device :wink:.

Once I updated the database, you will need to delete the thing, and add it back in again so that it picks up the new channel definition.

1 Like

That sounds good for me :grin:, today i got my first door sensor and you add it to the Z-Wave-database. After the nightly build of OH2-addons i’ll check if it works.

So please give me writing access to the Z-Wave devices database and i’ll try out how it works for me.

After a month of testing OH2 and the bindings for my devices as end-user its not quite easy to understand the differences between OH2 and ESH. But in my opinion and understanding of logic is that contact should be a contact and not a switch like is use it in the moment cause it works :wink:

I tried the Z110 now with the new channel sensor_door…
sorry gotta ask a little

  1. I added the door sensor additionally in the db… was that correct? as I now have “binary” and “door” …
  2. on “HOME” door shows NULL
  3. In log the updates still come as “sensor_binary”

How can I now catch this as sensor_door?

@chris Would it also be acceptable to just use Contact as it already exists, and those devices could be modified in the same way as changing them to sensor_door? Is there something else special about sensor_door? Or some detractor from using Contact? What if I have the device on a window?

1 Like

I’m not sure I understand what you mean… The issue is that the device definition needs to be re-read from the thing files. This is only done when the thing is first added into OH - after that, it uses the information that is persisted within the system. So, if the thing configuration gets updated, you must delete the thing, and add it back in to update it…

Note that this doesn’t apply to config parameters, associations etc - it’s just the main device properties such as the channel configuration…

Did you delete the thing, and add it back in? This is needed to pick up the change in channel configuration.

I did

Maybe you updated the wrong channel then?

You are saying to change it to sensor_door, and I am asking why not change it to Contact, which already existed. I am wondering if there is something special that was needed that made sensor_door unique instead of just using Contact. I realize I may be missing something.

But these are two totally different things. The channel type must be sensor_door. The item type is then Contact. I think people get mixed up between channels and items - they are different (but very close relations).

As stated previously, the channel_type MUST be linked to a corresponding item type - this is just the way ESH works at the moment. So, you MUST use sensor_door as a channel type if you want to use Contact as an item type…

Got it. Thank you.

maybe … I updated the database with a new channel sensor_door for the binary

maybe adding a new channel there was wrong?

now I have both sensor_binary and sensor_door in habmin
and still sensor_binary gets the updates when the sensor is used

Yes - if you’ve added a new channel, then is was wrong. It should only have been necessary to change the existing channel from sensor_binary to sensor_door… That said, in theory they both probably should work…

What do you mean exactly by “sensor_binary” gets the updates? Do you mean the item associated with the old channel, or are you looking at something else (like the log?).

you are right

i only looked in the log and there still “sensor_binary” receives the updates
also on “Home” the Door Channel is NULL always…

that said after your post above I just added it to the sitemap and there the both items are updates:

very odd … since that binding update the temp sensor is far away from the correct temperature…

Yep - we both made a mistake :sunglasses:.

If you can update the database to fix the double definition, I’ll fix the database exporter to use the correct type which I forgot to update yesterday.

has this also impact that the temp is now wrong? :slight_smile:

I tried to update the DB… no delete button for me? just edit … but I would need to delete the sensor_binary channel on
TWO devices I updated:

No - this shouldn’t impact the temperature channel unless you changed that. I forgot to change the database and the binding, so the only thing that changed was the extra channel you added.

No - can you provide me the links to the channels you want deleted (just so I delete the right ones!).

nah didn’t anything else

I updated them to “delete” :wink: on both devices

Thanks. Let’s see if it’s any better (or different at least :slight_smile:) tomorrow…

also (even if you say its not impacted) if the temp is again on normal level tmr… its 5 degrees celsius off today - 5 degrees higher then yesterday. so if its not the binding then the sensor must be defect :frowning: