Comments (18)
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.
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
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.
Related Issues (20)
- email used as "changed_by" HOT 4
- Upgraded to latest release and now the integration is not working HOT 1
- Feature request: add doors and windows sensor status
- Feature request: Add smoke detector status
- Door lock HOT 1
- False arming/disarming. HOT 13
- Integration stuck in "Pending" HOT 2
- Attribute changed_by not updated on state change
- Platform sector does not generate unique IDs.
- Retrying setup HOT 1
- Sector Alarm's API called too often! HOT 10
- Sector Yale: Failed to call lock/unlock HOT 13
- Two alarm system on same email/login account HOT 2
- Problems with retrieving temperature readings HOT 1
- Get Temperature HOT 1
- QuickArm without code HOT 8
- Setting up connection with temp sensors fail
- Entity None - Warning
- Need to reconfigure after 24h HOT 1
- New alarm system from Sector does not show alarm status HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sector.