From the state of this thread, I suppose there is still no solution to this? I have 4 Fibaro FGSD’s, which each have 5 “alarm channels” each (temperature, smoke, tamper, system and battery). These are defined as
Switches in the database (mapped to “OK” or “Alarm”), which makes absolutely no sense to me since they are read-only (you can’t SET the smoke alarm). While they read the state when it changes, if you “touch” one of the switches in the GUI by accident, they will change - even though that has nothing to do with the actual status of the sensor. In addition, they have no way of indicating when the state is “unknown” except that neither of the “buttons” are selected - which isn’t intuitive to anyone but the one that set up the system.
If I transform them into something else in the sitemap, I can’t aggregate them. Also, I can’t show them as “subgroups” in the sitemap, because then I don’t get to control how they look/transform them.
I understand that I can create 20 proxy items and write rules for them all, but this isn’t very tempting as a principle. It lays the groundwork for a system that can easily break sometime in the future when something changes in the network and I don’t remember all the details. In addition, I’d have know and care about the order in which the different rules files would execute, as I would need to use the proxy items in yet other rules (that actually react to the alarms).
I have tried reading around this forum, and I haven’t yet seen a good solution. As I see it, the logic with regards to contacts/switches is lacking.
I’d say that would be needed was 3 abstract “binary” types: read-only (contact), write-only and read/write. I’m not sure where I’d put the current switch, as it seems to behave somewhere between the last two. From what I can see, it is read/write in functionality, but write-only in layout designs.
The read/write item should have a design corresponding to a switch with an indicator light
. The “switch” part would then represent the “write”, ie. what is controllable from the UI, while the “light” part would represent the “read”/state.
Given that this will probably never happen, and that the binding can’t always tell (like with z-wave), wouldn’t it at least make sense if it was possible to define an
Item as read-only so that the UI won’t let you change it?
I don’t quite understand why more people haven’t raised the issue, as I don’t think the current (2.4) behavior is very intuitive. Are there any solutions to this on the horizon, or anything major that I’ve missed?