Switches in .items file?

I have been working on connecting openhab to my alarm system using the DSC Alarm binding. Most of the signals coming from the security zones are binary (open/closed, fault/no fault, etc). In the documentation examples these are set up as switch items:

Switch ZONE1_FAULT (DSCAlarmZones) {dscalarm="zone:1:1:zone_fault"}
Switch ZONE1_TRIPPED (DSCAlarmZones) {dscalarm="zone:1:1:zone_tripped"}

Why are these switches and not contacts? When I add them to a sitemap I just get switches that I can toggle, but that does not make sense in this context (I am not turning on a fault…). Am I missing some part of the setup that makes this work? This is not the only example, my multisensors also use a switch instead of a contact when they detect motion.

The problem is there has been no real enforcement on the binding developers to use Contact for things that are bound to sensors.

However, to put it on your sitemap without the toggle switch where it shouldn’t be controlled, just use Text instead of Switch on your sitemap lines.

If you are using the Group element to build up your sitemap there isn’t anything you can do. That is just the way it is right now.

If it is a real problem for you, you can file an issue on the binding to use Contact instead of Switch for sensor values.

Personally, I would have liked to see either there be just one binary Item or some sort of enforcement on the bindings to use Contact for sensors.

Hello @mudcat,

Pretty much what Rich is saying is correct. Those items are supposed to represent a Boolean (true or false) type flag or trigger for the zone. They don’t represent the actual state of the sensor (OPEN or CLOSED). That is done through the zone_status item. Those items can be triggered when the actual zone_status item (Contact type) changes or a fault condition occurs on the zone. The closest item type to a Boolean type, imho, is the switch (ON or OFF). Those items are probably more useful when creating rules and the such. Hope this helps.

Thanks for the help! So to clarify when you say the switches dont represent the actual state of the sensor… The sensors are not writing their statuses to the switch items? I have not seen any change, but I am not positive that it isn’t due to other problems. Are the switch items just there for rules to toggle to latch the statuses as they come in via the zone_status item?

Hello @mudcat,

The sensors are not writing their statuses to the switch items?

The only item to represent the current state of the sensor is zone_status which is OPEN or CLOSE. The other items are switches that represent other status, for example the zone_fault switch will turn on when the binding receives a fault command from the DSC Alarm system for the zone. The zone_tripped switch on the other hand is kind of redundant in that it mimics the zone_status item but is a switch item instead (ON for OPEN and OFF for CLOSE).

Are the switch items just there for rules to toggle to latch the statuses as they come in via the zone_status item?

The switches are basically there to read the state and do something in a rule, such as send an email.