Multiple state change triggered about sector HOT 18 CLOSED

I agree. I will implement a counter for making the entities unavailable so it requires ~10 failed attempts before making entities unavailable.

from sector.

Can you check the logbook in HA if it reflects a state change or not.
Can you provide the automation yaml here to be looked at.

Thanks

from sector.

I already put the automation in #43 which you locked hence not able to continue the discussion.

Only one in the logbook

from sector.

Just got a notification about status change when there was no change.

Logs just before the change:

2022-01-18 12:32:38 ERROR (MainThread) [custom_components.sector] Timed out when connecting to Sector
2022-01-18 12:32:38 DEBUG (MainThread) [custom_components.sector] Info retrieved successfully URL: https://mypagesapi.sectoralarm.net/api/Panel/GetLogs?panelId=xxxx
2022-01-18 12:32:38 DEBUG (MainThread) [custom_components.sector] request status: 200
2022-01-18 12:32:38 DEBUG (MainThread) [custom_components.sector] self._changed_by = home
....
2022-01-18 12:32:53 ERROR (MainThread) [custom_components.sector] Timed out when connecting to Sector
2022-01-18 12:32:53 DEBUG (MainThread) [custom_components.sector] Finished fetching sector_api data in 30.193 seconds (success: True)

This resulted in triggering a notification that said the alarm had been activated.

Shortly after I got another notification saying that the alarm was disarmed (logs show it got the correct status after the last timeout).

Seems that if there is a timeout the pannel is updated? Is that correct workflow? Then I adjust my automation. Not sure if it should update the state when it does not actually know what the state is.

from sector.

Update:

Last two days rogue alerts are back multiple times a day.

In addition, almost always the changed by is not right. I was looking at the code a bit but not found the issue yet

from sector.

I've installed the latest beta this week and still rogue alerts.

In addition, every day the alarm is auto activated two state changes are triggered. First tells me the alarm was activated by the person who disabled it previously and secondly notified that it was activated by the automation "user".

from sector.

It's because the first one comes directly from your automation and the second one when it refresh the data from the api "changed by".
The only way to "fix it" is to remove the "changed by" attribute as it triggers the state change a second time.

Not sure what's the best way forward to be honest.

from sector.

There is one automation with one trigger, don't see how changed by is doing anything to this. All the alarm state is returned in one call.

I've even debugged it above and can be seen in the logs that the change_by does not change.

trigger:
  platform: state
  entity_id: alarm_control_panel.sector_alarmpanel_xxxxx

from sector.

So an attribute which changes also trigger a state change even if the state itself does not change. This "habit" changed some versions ago and wasn't there originally. Regardless it's now how it is.

So since I set the state when I push the change to Sector the new state get's there but the attribute is still with the old data.
Later a poll happens and it collects new data, attribute changed and by that also comes a state change.

So there is three potential solutions:

• Remove attribute which then will not trigger a state change anymore
• Only update attributes when state change (then it will have false data so would not recommend)
• Add an option to set the username which HA operates with and update also attribute with state change on command

I guess last option would be cleanest and probably what people would prefer.

from sector.

So since I set the state when I push the change to Sector the new state get's there but the attribute is still with the old data.
Later a poll happens and it collects new data, attribute changed and by that also comes a state change.

I get what you are saying but does not explain why it will be constantly triggering change through the day when the alarm has not been touched in any way.

Seems that some of these attributes have bad data, perhaps time outs result in nulls and updates the state with this.

I've installed the latest update so let's see...

from sector.

I get what you are saying but does not explain why it will be constantly triggering change through the day when the alarm has not been touched in any way.

Seems that some of these attributes have bad data, perhaps time outs result in nulls and updates the state with this.

I didn't get that before, my bad.
Now I start to wonder if it's any off the other attributes which is also affecting, more specifically then the is_online attribute.
Would be interesting to get the last state attribute changes from the database and see what is changing.

from sector.

So latest update is still triggering alerts when it recovers from a failed request.

2022-06-13 14:00:19 DEBUG (MainThread) [custom_components.sector] UPDATE_INTERVAL = {60}
2022-06-13 14:00:19 DEBUG (MainThread) [custom_components.sector] last updated = 2022-06-13 12:00:19.001606
2022-06-13 14:00:27 ERROR (MainThread) [custom_components.sector] Timeout fetching sector_api data
2022-06-13 14:00:27 DEBUG (MainThread) [custom_components.sector] Finished fetching sector_api data in 8.005 seconds (success: False)

...

2022-06-13 14:01:27 DEBUG (MainThread) [custom_components.sector] UPDATE_INTERVAL = {60}
2022-06-13 14:01:27 DEBUG (MainThread) [custom_components.sector] last updated = 2022-06-13 12:01:27.002555
2022-06-13 14:01:35 DEBUG (MainThread) [custom_components.sector] Finished fetching sector_api data in 8.001 seconds (success: False)

....

2022-06-13 14:02:47 DEBUG (MainThread) [custom_components.sector] Info retrieved successfully URL: https://mypagesapi.sectoralarm.net/api/Panel/GetSmartplugStatus?panelId=xxxx
2022-06-13 14:02:47 DEBUG (MainThread) [custom_components.sector] request status: 200
2022-06-13 14:02:47 DEBUG (MainThread) [custom_components.sector] Info retrieved successfully URL: https://mypagesapi.sectoralarm.net/api/Panel/GetLogs?panelId=xxxxx
2022-06-13 14:02:47 DEBUG (MainThread) [custom_components.sector] request status: 200
2022-06-13 14:02:47 INFO (MainThread) [custom_components.sector] Fetching sector_api data recovered
2022-06-13 14:02:47 DEBUG (MainThread) [custom_components.sector] Finished fetching sector_api data in 12.664 seconds (success: True)
2022-06-13 14:02:47 INFO (MainThread) [homeassistant.components.automation.alarm_state_change] Alarm State Change: Running automation actions
2022-06-13 14:02:47 INFO (MainThread) [homeassistant.components.automation.alarm_state_change] Alarm State Change: Executing step call service

Logbook:

History:

Given this API is so poor, I don't think it is right to be changing the status to unavailable. There is already an attribute is_online which could be set to false. I think the actual state should be a concrete value from the API and only change when there has been a measurable change (aka one of the defined states, armed, disarmed etc).

from sector.

Perhaps not even needed?

If someone wants it is easy enough to expose is_online and add any automation like is_online IS false for 10 minutes.

from sector.

I would still prefer to have it as it's a very visual indicator that you can't trust the state of the entity.

The is_online attribute is actually slightly different as it's true or false if the alarm panel has contact with Sector Alarm. It does not tell you if your HA has contact with the api or not.

from sector.

ok, but I don't want to be notified of state I can't trust. If it was once in 4 months that is another thing. This is multiple times per day.

I think it's common to be longer than 10 minutes.

Perhaps then just expose a new attribute like api_failures, set it to 0 on success. User can easily create auotmation based on that number at a level that seems good (or even adjust it them self).

from sector.

Let me consider your proposal.
My take on what you write is that regardless of failed counts you don't want any entity to go unavailable and prefer a separate sensor or something.

So even if it hasn't successfully updated in let's say an hour you still prefer entities to be available?

from sector.

Essentially 100% of the rogue alerts are false positives, alerting there has been a change when there has not.

I can not recall a single time there was a false negative, not alerting when the alarm actually changed. (and I would notice as I have the sector app alerts to compare with)

from sector.

I see some related changes in #118. Was about to post that unavailable should be dictated by the field that says if the alarm is online / offline. We are not tracking the status of the API.

Perhaps the latest version will be more inline with expectations 👍🏻

from sector.