Totally magical. Adding the extra sitemap line should have busted any caching. I cannot think of any way for UI to pluck button names from thin air, there’s a hidden mapping at work somewhere!
channels can come with labels but the Item label is supposed to override that.
Could try sitemap, to see what will override -
Bearing this is mind, we should also note that for zwave it was advised - This binding will require that existing things are deleted, and re-added so that the binding picks up the latest thing definitions .
I wonder if this device has changed from switch to contact model
I have simular situation on my three z-wave motion sensors. And it changed when updating z-wave binding to 2.5. I did deleted my devices and re-added them again.
items file
Switch Node10_BinarySensor "Vision PIR Binary Sensor [%s]" <cum_motion> (gMotion) {channel="zwave:device:512:node10:sensor_binary"}
Switch ZWaveNode5ZW100MultiSensor6_MotionAlarm "Multisensor6 PIR Alarm [%s]" <cum_motion> (gMotion) {channel="zwave:device:512:node5:alarm_motion"}
Switch Node13_AlarmBurglar "Neo Coolcam PIR Alarm (burglar) [%s]" <cum_motion> (gMotion) {channel="zwave:device:512:node13:alarm_motion"}
Good, in a way @lorenzopt will be pleased to know his system has not gone rogue.
Perhaps it is time to summon @chris he may have missed this thread with no zwave tag?
Seeing the [%s] is interesting, it’s no longer ON/OFF is it? I guess the UI auto produces the buttons instead of a slider when the state is given to it as e.g. “untriggered”.
This is all a bit like UoM for Numbers.
No, [%s] just shows the state left of the buttons.
For the NeoCoolcam, it´s OK/ALARM
(the reason why it shows - is because openhab crashed a few minutes ago, and this motion sensor hasnt updated yet).
For the Multisensor6 its OK/ALARM
For the Vision sensor it´s TRIGGERED/UNTRIGGERED.
The sitemap I showed is actually a group items. This is why the buttons/triggers is showen. Normally you wouldnt be using it this way for a motion sensor, since the idea is not a manual trigger control, but a control from the sensor, (ofcouse).
My ordinary sitemap looks like this:
Which is how one would normally show motion sensors.
sitemap looks like this:
Frame label="Andre PIRs" {
Text item=ZWaveNode5ZW100MultiSensor6_MotionAlarm
Text item=Node10_BinarySensor
Text item=Node13_AlarmBurglar
Text item=XiaomiMotionSensorMotion
Text item=HUE_Occu
Text item=TrustMotionPresence
}
Yes, something changed in the binding… I cant say why. And I dont think its wrong… Its just changed. What may seem wrong is, that not all devices report the same.
But @chris may have a better comment on this as to why it has changed. I believe he probably tried to make something which makes some kind of sense, rather than just ON/OFF.
I’m not really sure. The channel is defined as a type Switch, and the binding sets it to ON / OFF states. We also have states that should be used when this is shown as a text item, but if you define an item as a switch, it should work.
<channel-type id="alarm_motion">
<item-type>Switch</item-type>
<label>Motion alarm</label>
<description>Indicates if a motion alarm is triggered
</description>
<category>Motion</category>
<state readOnly="true">
<options>
<option value="OFF">OK</option>
<option value="ON">Alarm</option>
</options>
</state>
</channel-type>
At the end of the day though, it’s down to how the UI decides to present the data.
Hmm… So this would be a change in openhab 2.4 and the z-wave binding in combination? (Or perhaps the 2.4 z-wave binding as well. I can´t remember if this changed from updating openhab or just the z-wave binding, as things went fast just around this period. But to my understanding, the z-wave binding 2.5 is almost a copy of the 2.4 released, right?).
I wonder if an motion sensor should be type Switch rather than type Contact, (no matter if it´s an Alarm sensor or just a PIR, only difference is how fast it can re-trigger and the Alarm beeing a NO contact (Normally Open)). It really doesn´t make any sense beeing a Switch, as it´s not manually controled like a switch usually is. But I dont know if it would make any difference.
Point is though, something has changed either in the z-wave binding or in openhab´s UI.
I don’t know - I don’t think the binding has changed the channel definitions. As I said earlier, this is down to how the UI interprets and presents the information.
Originally there was a table from ESH that stated the types that had to be used - I used that so that it was consistent across bindings (assuming other binding developers did the same!).
I believe you…
It´s just strange that it´s only my 3 z-wave sensors who changed. My Philips Hue motion sensor and the Trust motion sensor (both Zigbee) have not changed. I´m almost pretty sure, this change happened when updating openhab to 2.4. The reason if confused me is, that I updated the z-wave binding to 2.5 a coupple of days after I made the openhab update to 2.4.
OP´s motion sensor is a z-wave device as well.
It has to be a change in the openhab 2.4 then. I wonder who´s to “blame” for this? (I have not checked if its a documented change).
I haven’t found any reference to it yet, but it’s difficult to guess what such a feature might be called.
It seems pretty clear that these options are “leaking” from the bindng through the Switch Item and getting used by the UI. The UI is not plucking these descriptions from thin air, they have somehow attached to the Switch.
It’s qute possible that has always happened, but UI have only recently changed to look for this, umm, property.
zwave is a rare binding with a detailed device “library”, so few other bindings would show up this kind of effect.
I’ll call that is some kind of UoM mechanism related change. I don’t know how Number Items carry their optional unit (like degrees C) but I’ll bet the same mechanism is at work.
It’s actually quite a neat feature … auto suggesting the appropriate label for a binary device, based on device model … if we can figure out how to turn it off !!
Missing from this thead - a demonstration of what the Switch Item gets updated to, in the events.log ?? I’ll bet it’s still ON but half expect to see ON |Alarm
As far as I remember, it still state ON/OFF like it used to. (I´ll check to make sure tonight). And I guess it should as well from Chris´s script. Otherweise it could never show OK/ALARM in the sitemap.
What makes me wonder though, how come my Vision motion sensor (z-wave) is stating TRIGGERED/UNTRIGGERED, and not OK/ALARM like the others…