| Extending States - adding state attributes? [message #1759688] |
Sat, 15 April 2017 15:53 |
 Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Currently, we have a single dimension in the state - e.g. ON/OFF, a single value, etc. This is fine for basic information that goes to a user or UI, however, in many cases further information is required (or at least, is provided from the device sending the state) to fully describe an event. While this information may not be of primary concern, and may not be used in a UI, it is useful for triggering rules/scenes and I feel it would be useful to think if this could be attached to the state event.
A few use cases -:
- Z-Wave scene controller can can send a scene 'command' - this usually has a number of attributes - the scene number, but also the keypress type (KEY-DOWN, KEY-UP, etc), and sometimes a time is also provided. This is currently handled by defining a number - (scene number).(type) - e.g. 6.3 might be used for scene 6, keydown - we ignore the time so the device can not be fully utilised.
- An alarm can have a type, and a state. Instead of implementing 25 channels for 25 different alarms, each with an on/off condition, it might be more convenient to provide a single Alarm channel with on/off state and alarm type attribute. The UI can show there's an alarm (i.e. showing the channel and it's state - as we now have) but a rule would be able to look at the attribute and decide exactly what alarm type this is and act with the appropriate response.
- A smoke alarm can go into alarm - we want to show this on the UI, however the notification rule that rings the fire brigade probably doesn't want to do this if it's a test - we could add the "Test=true" attribute so that the system can work around this.
Of course there are always ways around this with the current system - we can concatenate data together(e.g. alarm type number x 100 + alarm value), or we can use two channels, but then the rule has to resynchronise these two streams. However, I'd like to propose an extension to State updates.
Currently, we have -:
updateState(channelUID, state)
I believe (following an extremely quick look at the code!) that this could be extended with another parameter containing an attribute map. eg
updateState("channel.uid", OnOffState.ON, {"keypress":"down", "time":25})
A similar extension to rules would be required to read the attributes. The idea is not to impact the framework - all the generic information required to be system agnostic is still there, but it allows the framework to support the more advanced features that may be provided by systems like Z-Wave (and many more I'm sure).
I've also seen people talking about having things with 1500 channels - I've not looked at why this is, but I do wonder if the above suggest might in some cases allow better channel definition, and possibly reduction in channels (??).
Maybe there's other ways to support this feature and I'd certainly be interested to hear peoples thoughts.
Chris
|
|
|
Powered by
FUDForum. Page generated in 0.02921 seconds
] 
Search
Help
Register
Login
Home
