Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Event State #5

Open
merlinmb opened this issue Feb 6, 2017 · 2 comments
Open

Event State #5

merlinmb opened this issue Feb 6, 2017 · 2 comments

Comments

@merlinmb
Copy link
Contributor

merlinmb commented Feb 6, 2017

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;
@merlinmb
Copy link
Contributor Author

merlinmb commented Feb 7, 2017

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!

@cybertza
Copy link

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.

Great job!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants