You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi MnrGreg,
The new interpretation of the Alarm state (direct read) seems to be missing the 'Sleep' status which was previously handled as a string - this causes issues as 'Sleep' is ignored and later reported as an invalid Homekit Status (in the getState function on line 116.)
perhaps need to add this to case statement from line 85?
console.log("mqtt Alarm State message received:", status);
switch (status) {
case self.armevent:
status = Characteristic.SecuritySystemCurrentState.AWAY_ARM;
break;
case self.stayevent:
status = Characteristic.SecuritySystemCurrentState.STAY_ARM;
break;
case self.disarmevent:
status = Characteristic.SecuritySystemCurrentState.DISARMED;
break;
case self.triggeredevent:
status = Characteristic.SecuritySystemCurrentState.ALARM_TRIGGERED;
break;
default:
status = null;
break;
The text was updated successfully, but these errors were encountered:
Hi - I've been thinking about this - It may also be related similar issue to one previously reported with the 'initial' state not being set until reported (later). I was working on configuration late last night and my outside area was in "Sleep" mode, so may have been a misdiagnosis.
Thanks for a great implementation - really digging my HomeBridge/Paradox setup!
I believe the initial state is due to the way the plugin works:
It will have no state that it tracks internally until the unit receives a status message, I will have a look at the startup reports of the "polled" it may have an initial report on current state,
I would say an "persistent" message on the mqtt may be a useful way to handle the problem, but that does come with a risk after time, as it actually runs on the normal status thread, maybe I will use node rEd to parse the stream from the alarm, and push data to a new persistent topic that expires somehow.
The legwork and hard work was done so well for this.
Hi MnrGreg,
The new interpretation of the Alarm state (direct read) seems to be missing the 'Sleep' status which was previously handled as a string - this causes issues as 'Sleep' is ignored and later reported as an invalid Homekit Status (in the getState function on line 116.)
perhaps need to add this to case statement from line 85?
The text was updated successfully, but these errors were encountered: