Notifications for changes in annex status
Closed this issue · 8 comments
I was thinking a bit about the notify() in the context of annex-status. The status of the annex is modeled separately to the status of the main building. Today the notifications only support changes in the status of the main building but not for the annex.
If I where to build support for notification for the annex I could go with one of two approaches.
- Have two separate statuses maintained in site.js and have the two also as parameters to the callback responding triggered by a change in status in either of the two.
- Having two separate notify() functions.
or - Creating a state-class with two properties, one for main building and one for annex. (This is probably a pretty bad option since it would affect the whole API and be a breaking change.)
Without thinking too much about the problem, I see another alternative.
- Having an additional callback as argument to the notify method, annexChangedCallback for example. If callback is not provided as an argument, it would not break current behaviour and it will never be called. The callbacks are the notification that the state changes, but the data in them can be the same. If I implement callback1 i look at armedStatus, if implementing callback2 I look at annexStatus(see below). Just need an additional internal variable to track the change of the annex if the second callback has been provided.
Another thing I just noticed is that perhaps the status properties for the status response should be annexArmingAvailable and annexArmedStatus. So they follow the pattern of the main building?
armedStatus: function(input) {
if (input.Panel.ArmedStatus == 'partialarmed')
return 'partialArmed';
else
return input.Panel.ArmedStatus;
},
partialArmingAvailable: function (input) {
return input.Panel.PartialAvalible;
},
annexAvailable: function (input) {
return input.Panel.AnnexAvalible;
},
annexStatus: function (input) {
return input.Panel.StatusAnnex;
Another topic, is annex information included in the history output?
Without thinking too much about the problem, I see another alternative.
- Having an additional callback as argument to the notify method, annexChangedCallback for example. If callback is not provided as an argument, it would not break current behaviour and it will never be called. The callbacks are the notification that the state changes, but the data in them can be the same. If I implement callback1 i look at armedStatus, if implementing callback2 I look at annexStatus(see below). Just need an additional internal variable to track the change of the annex if the second callback has been provided.
Another thing I just noticed is that perhaps the status properties for the status response should be annexArmingAvailable and annexArmedStatus. So they follow the pattern of the main building?
armedStatus: function(input) { if (input.Panel.ArmedStatus == 'partialarmed') return 'partialArmed'; else return input.Panel.ArmedStatus; }, partialArmingAvailable: function (input) { return input.Panel.PartialAvalible; }, annexAvailable: function (input) { return input.Panel.AnnexAvalible; }, annexStatus: function (input) { return input.Panel.StatusAnnex;
:D option 4. makes good sense. I totally missed that one. I think I might look into it during this week.
I could possibly refactor the names to follow the convention a bit better as well. That will probably be a separate PR though. This is a breaking change for my Homebridge project, but it takes like two minutes to cater for it. :)
Another topic, is annex information included in the history output?
Yes it is included in history output. Would have to look into it a bit to know for sure.
Without thinking too much about the problem, I see another alternative.
- Having an additional callback as argument to the notify method, annexChangedCallback for example. If callback is not provided as an argument, it would not break current behaviour and it will never be called. The callbacks are the notification that the state changes, but the data in them can be the same. If I implement callback1 i look at armedStatus, if implementing callback2 I look at annexStatus(see below). Just need an additional internal variable to track the change of the annex if the second callback has been provided.
Another thing I just noticed is that perhaps the status properties for the status response should be annexArmingAvailable and annexArmedStatus. So they follow the pattern of the main building?
armedStatus: function(input) { if (input.Panel.ArmedStatus == 'partialarmed') return 'partialArmed'; else return input.Panel.ArmedStatus; }, partialArmingAvailable: function (input) { return input.Panel.PartialAvalible; }, annexAvailable: function (input) { return input.Panel.AnnexAvalible; }, annexStatus: function (input) { return input.Panel.StatusAnnex;:D option 4. makes good sense. I totally missed that one. I think I might look into it during this week.
I could possibly refactor the names to follow the convention a bit better as well. That will probably be a separate PR though. This is a breaking change for my Homebridge project, but it takes like two minutes to cater for it. :)
Are you turning this into a HomeBridge plugin? I was googling like a madman trying to find a HB plugin for this, and this is as close I have gotten to find bliss :)
Jupp. I do have an embryo for a Homebridge plugin. The API though is scarily undocumented and furthermore I'm a crap Javascript developer: :D Feel fre to check it out though. https://github.com/frli4797/homebridge-sector/tree/master Right now the plugin only supports main alarm and arming the annex. I'd like to be much more granular and support alarm, annex, partial arming, temperatures and eventually also smart plugs and locks.
Starred, and Watched. Will try it out tonight if time allows. I totally hear you about granularity. Getting stuff like temp and smart plugs and all the other things you mentioned would be an excellent addition.
Anyways, I will not pollute this thread anymore, I will keep an eye out on the other project instead.
This is now in the latest version 1.5.0, together with door lock implementation.