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 .
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.
That sounds good for me , 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
@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?
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…
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…
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?).
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.
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!).
jupp
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
.
, 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.
.
on both devices
) tomorrow…