Alarm panel left in pending state after upgrade to 0.3.4 about sector HOT 16 CLOSED

Does not seem to be a point in doing so given the sensor only updated every 60 seconds (unless you changed it) and given the alarm reported in this case is stuck in pending it seems possibly not to change at all or changes so quickly my api calls doesn't reflect it.
I probably would just make it an attribute on the alarm itself (think it already is) and just leave it out from checking it.
I'll make a new beta with this change and you can run this and see if it works better.

from sector.

I’m also seeing this, so it’s not just you. It does look like significant other portions do work, eg I can arm sector via node-red.

from sector.

I've removed the IsOnline check locally, since debugging showed that it was false for my case. @robinsmidsrod maybe you want to try as well? I'm not sure what this property controls, but I've yet to see it set to true for my house.

Happy to create a PR if folks believe that this property check is no longer needed. Right now I'm not sure if this is the right fix or not, other than my one test case.

from sector.

@alexpomsft I had a look, and it seems the URL used in

[
    {
        "PanelId": "01xxxx67",
        "ArmedStatus": "disarmed",
        "PanelDisplayName": "Hjemme",
        "StatusAnnex": "unknown",
        "PanelTime": "\/Date(1643015236000)\/",
        "AnnexAvalible": false,
        "IVDisplayStatus": false,
        "DisplayWizard": false,
        "BookedStartDate": "\/Date(-62135596800000)\/",
        "BookedEndDate": "\/Date(-62135596800000)\/",
        "InstallationStatus": 3,
        "InstallationAddress": null,
        "WizardStep": 0,
        "AccessGroup": 1,
        "SessionExpires": "\/Date(1643055342400)\/",
        "IsOnline": false
    }
]

And your assumption seems to be correct, the IsOnline: false seems to indicate that the code you referred to is never called. This might be because my alarm system is using mobile data, not my local Wi-Fi, to send information out. This could be why the IsOnline value never changes to true.

Reverse-engineering APIs without documentation is always a guessing-game. My guess is that this value represents whether the given alarm system is always connected (true) or intermittently connected (false).

from sector.

I think we'll need @gjohansson-ST to comment on 7cff37a and it's intention.

from sector.

I didn't consider it as a use case that this could actually always be false but it seems logical that it's perhaps only true for a very short period of time if you are running it over mobile to avoid it to frequently communicate between the device and the cloud.

from sector.

I think we'll need @gjohansson-ST to comment on 7cff37a and it's intention.

It's intention was that if the device is not online you can not know what status there is and therefore simply skip update but as in previous comment might have to reconsider this now then.

from sector.

@gjohansson-ST If the IsOnline value is made into a diagnostic binary sensor, then we can get HA to graph/log it for us, then we can see if it never changes state or if it changes briefly from time to time.

from sector.

@gjohansson-ST The reason I suggested a diagnostic sensor is because HA developer guidelines suggest to not use entity attributes unless they're directly related to the entity in question. So this would be a diagnostic entity attached to the "hub" device.

The reason for avoiding entity attributes is to avoid unneeded state_changed events when the main state of the entity doesn't change.

from sector.

I know given I contribute with quite some things into the core project but this is a custom component so I can just use my own rules 😄
Probably I will just do neither and just put in the debug instead.

from sector.

+1 on the issue, and I'm also using an old alarm system with only mobile connection to the cloud.
Maybe a switch in the configuration to distinguish if system is "always connected" or "mobile connected".
I'll be happy to contribute by testing beta's.

from sector.

+1 Here as well. Also using legacy GSM-only Sector equipment without ethernet or wifi.
All effort put into this project is much appreciated.

from sector.

+1 My alarm panel has been pending the last few months now. Is there a fix planned?

Or is the fix to go back to 0.3.3 ?

from sector.

Sorry. My bad for not making it.
Will do a beta now over the weekend containing a fix for this.

from sector.

Beta now released to address this issue.
https://github.com/gjohansson-ST/sector/releases/tag/v0.3.5-beta1

from sector.

@gjohansson-ST I've just tried v0.3.5-beta1, and I no longer have a yellow, blinking, pending state when the alarm is disarmed. It now works as it did in v0.3.3. Good job!

from sector.