I switched today from the 1.9 zwave binding to the 2.0 version. After rewriting all my items to use the new ‘channel’ syntax for ‘things’, I’ve noticed that none of my motion sensors are triggering motion anymore. They are reporting battery state and (for those with the functionality) temperature. But, no motion. I think I turned on zwave debug logging in karafe, but it simply looks like the data is no longer being received.
I did not de-associate and re-associate my sensors with my zwave controller. So, theoretically, the topology is unchanged from what worked with zwave 1.9. And, the sensors are reporting battery and temperature, so they are in the network. Just not motion.
I cut-n-pasted the channel definitions verbatim from the paper ui when setting up my items, so there’s no typo there.
I did think it was odd that most of the channels have underscore separators (sensor_binary), except battery has hyphens (battery-level). Weirdly inconsistent.
Anyway, so my installation is now sort of broken because no motion sensors are turning on any lights. Any help would be appreciated.
In the 2.0 version of the zwave binding, the sensor_binary acts like an OnOffType rather than an OpenCloseType (as it did in 1.9). Also, You must map the channel to a Switch item rather than a Contact item, or things won’t work, because it seems that Contact items don’t know how to react to OnOffType messages.
This really should be called out in the 1.x -> 2.x transition documents. It’s a major mysterious headache to figure out.
Also, not exactly sure that it’s correct. Sensors aren’t switches. They’re read-only. You can’t write to them. Making them look like Switches is incorrect. The legacy Contact item type is a bit of a weird match for motion sensors tho. Maybe there should be a new Motion item type? It could continue to take the new OnOffType coming from sensor_binary, or perhaps there could be a YesNoType?
Why? There is no more basic sensor than a pair of contacts, open or closed. The ‘what’ behind the contact action - pushbutton, motion, thermostat, light - doesn’t matter.
In any event, in the zwave implemetation, it’s been changed from open/closed to on/off, now, anyway. On/off is a bit better for motion sensors, (what does ‘open’ motion mean, anyway?), but requiring motion sensors to be represented by switch items seems misguided.
Contacts having an open / closed state are electrical terms. ‘closed’ is just a general term for an electrical short-circuit, ‘open’ an open-circuit. Perfect match for any go/no-go, black/white, 0/1, binary state.
Commonly called a switch in English of course, and equally associated with on/off binary state.
Waffle warning - It just so happens that common types of e.g. intruder alarm door and window switches/contacts just happen to signal an opened door with electrically open contacts. This wasn’t chosen (a century ago probably) because the names happen to line up, but because its useful for the safe/closed/secure/not-on-fire physical state to be the electrically closed/on state - that’s failsafe, a cut wire or broken sensor causes an ‘alarm’ open-circuit. Try to seperate ‘open’ as a meaning for a contact/switch position from the physical cause of that switch/contact position - waffle over
In Openhab, they (arbritarily) chose ages ago to distinguish between Contact - a kind of switch which is purely an input device, a sensor Switch - a kind of switch that controls external things. a light, a relay, primarily an ouput.
It’s very useful to also be able to read back the state of an output, so a Switch Item isn’t exclusively output-only, but the original intent is an output device.
In those OH specific terms, a device like a motion sensor is best represented as a Contact. It has a binary state, it makes no sense for OH to be able to ‘command’ it, it is a passive input.
I agree with you that it is not appropriate for zwave2 to represent them as Switches at all.
Does it matter? Historically, intruder detection wired motion sensors signal with ‘closed’ for dormant and ‘open’ for activated as already discussed.
That way round was copied from older types and originally selected for integrity reasons.
You can map to black and red for the two states if it bothers.
Fine, that’s the way it was in operhab 1.9. It would have been ok if that had just been carried forward, but now, in 2.0, it’s changed for some reason to ON/OFF, which is still not as intuitive as YES/NO would be.
Actually, in OH1 you, as a user, had the flexibility to choose whatever type you wanted. In OH2, this isn’t the case. Since the binding doesn’t know anything about items, it has to choose something for you.
These types are defined by ESH here. There has been some discussion about how to give bindings some visibility of items so that users have this level of configurability again, but so far this is not possible.
Hmm… thx for the link. So, there’s a new ‘read only’ flag attached to channels accessible via the ‘channel category’? It doesn’t seem like openhab is using that, as its rendering motion sensors exactly the same as light switches. Or, is the zwave binding not setting the appropriate ‘channel category’ on items?
