Error with simulated notifications #49
Comments
|
And the next one: Exception simulating device alerts from history: ValueError('11 is not a valid G90AlertSources') |
|
@Cimpel , thanks for reporting the issue - I'll focus on first error, 2nd one is due to the component (actually, the Python library it uses) doesn't recognize that event though I might be able to look around to add support for it as well. To help me understanding the issue better:
|
|
The error 'Received alert from wrong device' occurs every time a
window/door sensor is closed and which has the option "Detect Door/Window"
enabled.
Home Assistant is normally operating, no restart or suspicious behaviour
(the system log only reports this error).
I will setup the diagnostics and report later on.
Op do 12 dec 2024 om 18:02 schreef Ilia Sotnikov ***@***.***>:
… @Cimpel <https://github.com/Cimpel> , thanks for reporting the issue -
I'll focus on first error, 2nd one is due to the component (actually, the
Python library it uses) doesn't recognize that event though I might be able
to look around to add support for it as well.
To help me understanding the issue better:
- How often you see the error Received alert from wrong device?
- Does it happen under specific conditions, e.g. right after
HomeAssistant restart, alarm triggered or any other happenings?
- Could you please download the diagnostic data from the component and
post it here? The data won't contain anything sensitive so it is safe to
share it. Settings -> Devices & services -> Golden Security Alarm ->
three dots at the right of your alarm panel -> Download diagnostics
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJDX736XGU6DLSMBXGJ3EWD2FG6TXAVCNFSM6AAAAABTPTPXHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZZGUYTSMZXGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Attached is the debug log from the first error.
(Repeated the same action which produced the first error just a moment ago)
Op do 12 dec 2024 om 18:02 schreef Ilia Sotnikov ***@***.***>:
… @Cimpel <https://github.com/Cimpel> , thanks for reporting the issue -
I'll focus on first error, 2nd one is due to the component (actually, the
Python library it uses) doesn't recognize that event though I might be able
to look around to add support for it as well.
To help me understanding the issue better:
- How often you see the error Received alert from wrong device?
- Does it happen under specific conditions, e.g. right after
HomeAssistant restart, alarm triggered or any other happenings?
- Could you please download the diagnostic data from the component and
post it here? The data won't contain anything sensitive so it is safe to
share it. Settings -> Devices & services -> Golden Security Alarm ->
three dots at the right of your alarm panel -> Download diagnostics
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJDX736XGU6DLSMBXGJ3EWD2FG6TXAVCNFSM6AAAAABTPTPXHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZZGUYTSMZXGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Unfortunately the attachment didn't seem to get through |
|
Tired to paste the log directly into Github.
Did you get it ?
Op do 12 dec 2024 om 20:08 schreef Ilia Sotnikov ***@***.***>:
… Unfortunately the attachment didn't seem to get through
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJDX737XLGV6T7QLX7SQJC32FHNKNAVCNFSM6AAAAABTPTPXHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZZHAYDMNBYHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Still none show up in the issue, sorry for bad news. |
|
Another try , I tested in the preview and it downloaded, fingers crossed |
This one came thru finally, thanks! Although that is from debug logging on the component, while diagnostic data would be needed - you can take it from Settings -> Devices & services -> Golden Security Alarm -> three dots at the right of your alarm panel -> Download diagnostics, please. |
|
You mean this one ? |
|
@Cimpel , thanks much - the last log is very helpful, I see now diagnostics can't be downloaded for the same reason (entity with unrecognized source field). I've made another component version 1.22.1, would be great if you could test it - please note it is marked as pre-release, so you'll need to select it explicitly in HACS ( |
|
Unfortunately the 1.22.1 release didn't solve the problem, see the message
from the logbook.
*Logger: pyg90alarm.device_notificationsBron: runner.py:154Eerst
voorgekomen: 11:43:06 (1 gebeurtenissen)Laatst gelogd: 11:43:06Received
alert from wrong device: expected 'GA180198G000708', got ''*
I will upload the diagnostic log separately.
Op za 14 dec 2024 om 11:31 schreef Ilia Sotnikov ***@***.***>:
… @Cimpel <https://github.com/Cimpel> , thanks much - the last log is very
helpful, I see now diagnostics can't be downloaded for the same reason
(entity with unrecognized source field).
I've made another component version 1.22.1
<https://github.com/hostcc/hass-gs-alarm/releases/tag/1.22.1>, would be
great if you could test it - please note it is marked as pre-release, so
you'll need to select it explicitly in HACS (HACS -> Golden Security
Alarm -> Redownload -> 1.22.1) assuming you've used that method of
component installation.
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJDX73ZVISD5KWGG56F75BD2FQCI5AVCNFSM6AAAAABTPTPXHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBTGA2DMOJQHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
The diagnostics from 1.22.1 |
Apologies for a confusion - the 1.22.1 will only resolve |
|
Actually - just found that proper SOS handling is missing (thanks again for helpful logs!), will try to implement those today and that should cover diagnostics/ValueErrors. |
|
You are welcome. Let me know when to test again.
Op za 14 dec. 2024 12:57 schreef Ilia Sotnikov ***@***.***>:
… Actually - just found that proper SOS handling is missing (thanks again
for helpful logs!), will try to implement those today and that should cover
diagnostics/ValueErrors.
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJDX7345CDETTRT5YYF7VJD2FQMKNAVCNFSM6AAAAABTPTPXHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBTGA3TKMZTGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Just got a new error, something with SOS etc. See the attached log Logger: pyg90alarm.history Can't interpret '6' as alert state (decoded protocol data 'ProtocolData(type=4, event_id=12, source=11, state=6, sensor_name=' Keypad-', unix_time=1734339897, other='')', raw data '(4, 12, 11, 6, ' Keypad-', 1734339897, '')') |
hm, seems related to RFID, the hardware I don't have - I'll try to best guess how panel works with those, but we likely need a few trials and errors. Meanwhile, mostly finished my work re: SOS (sorry it takes longer then I initially committed to) - should be able to finish it today. That will remove failures downloading the diagnostics and errors in the HASS related to simulating events from history - we can then iterate over the remaining issuses. |
|
@Cimpel , 1.22.2 is out (same upgrade process as previously) - hopefully it'd fix wrong device GUID and history processing issues, except source=11 (RFID), will need more help with that, since I don't have that HW. |
|
Nope; got the same error:
Logger: pyg90alarm.device_notifications
Bron: runner.py:154
Eerst voorgekomen: 09:52:06 (1 gebeurtenissen)
Laatst gelogd: 09:52:06
Received alert from wrong device: expected 'GA180198G000708', got ''
Op ma 16 dec 2024 om 23:18 schreef Ilia Sotnikov ***@***.***>:
… @Cimpel <https://github.com/Cimpel> , 1.22.2 is out (same upgrade process
as previously) - hopefully it'd fix wrong device GUID and history
processing issues, except source=11 (RFID), will need more help with that,
since I don't have that HW.
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJDX734NUGNVHQH4XPWVBP32F5GUTAVCNFSM6AAAAABTPTPXHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBWHE3DKMBWGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Herewith the log (seems much better now): |
|
Found some additional messages: Deze fout is ontstaan door een aangepaste integratie. Logger: pyg90alarm.history Can't interpret '6' as alert state (decoded protocol data 'ProtocolData(type=4, event_id=12, source=11, state=6, sensor_name=' Keypad-', unix_time=1733830473, other='')', raw data '(4, 12, 11, 6, ' Keypad-', 1733830473, '')') Strange, because the keypad was not used !? |
|
Thanks much, @Cimpel ! The Other than that , do you still see some issues with the components? I guess at this time you should see sensors (again RFID) reporting their activation/deactivation (though with a slight delay, that is how simulation works) - could you please confirm that? Please don't hesitate to add more details if needed. |
|
I just tested it again: The sensors (components) do not report any state
changes (yet), no statechanges visible in the history of the entities or in
the GS logbook.
As said, in the system logbook I get the message:
*Logger: pyg90alarm.device_notificationsBron: runner.py:154Eerst
voorgekomen: 19:21:21 (2 gebeurtenissen)Laatst gelogd: 19:22:17Received
alert from wrong device: expected 'GA180198G000708', got ''*
As said I checked the entity history and the GS logbook for the
statechanges, the error report is from the system logbook.
Should I look somewhere else ?
Op di 17 dec 2024 om 19:05 schreef Ilia Sotnikov ***@***.***>:
… Thanks much, @Cimpel <https://github.com/Cimpel> ! The Can't interpret
'6' as alert state... should be harmless (would affect diagnostics only,
events simulation doesn't use that code) and likely related to RFID not yet
being supported.
Other than that , do you still see some issues with the components? I
guess at this time you should see sensors (again RFID) reporting their
activation/deactivation (though with a slight delay, that is how simulation
works) - could you please confirm that? Please don't hesitate to add more
details if needed.
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJDX73Y3RGMFVRXZ54UZZHL2GBRWRAVCNFSM6AAAAABTPTPXHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBZGIYTQNBZHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
P.S. in the GS logboek the state changes of the diagnostics (wifi, .. etc.)
and 'armed' etc are reported.
Op di 17 dec. 2024 19:05 schreef Ilia Sotnikov ***@***.***>:
… Thanks much, @Cimpel <https://github.com/Cimpel> ! The Can't interpret
'6' as alert state... should be harmless (would affect diagnostics only,
events simulation doesn't use that code) and likely related to RFID not yet
being supported.
Other than that , do you still see some issues with the components? I
guess at this time you should see sensors (again RFID) reporting their
activation/deactivation (though with a slight delay, that is how simulation
works) - could you please confirm that? Please don't hesitate to add more
details if needed.
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJDX73Y3RGMFVRXZ54UZZHL2GBRWRAVCNFSM6AAAAABTPTPXHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBZGIYTQNBZHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
The message in the system logbook expected 'GA180198G000708', got '' does not appear again (only the keyboard message is there) |
Unfortunately the mode comes with its limitations, basically what ends up in panel's history will be reflected:
Hence, with RFID not yet supported it leaves only wireless door sensors and panel state in the list. Plus, you might want to enable door open alerts in mobile application (alerts section) - that isn't required for normal setup (when panel is in same network segment as HASS), but might be helpful. Hope that clarifies. |
|
I understand the limitations.
I tested with a wireless door sensor (nr 7 in the diagnostic log) which
also has the "detect door&window" alert option in the app enabled.
From these sensors no state changes are detected and are always reported as
"closed".
In order to overcome any delays, I left the door open for half an hour and
closed it after that. No statechange in HA.
Panel state changes like alarm/disarm are reported OK indeed.
I hoped to use your notifications to alert me that one of the windows or
doors were left open on arming the alarm system.
The original alerts I got from the 90B disappeared for some reason a while
ago. Can this have to do because I installed the HA integration ?
Maybe deinstall it to test if they are back again in that case.
I like the HA integration because its a nice backup for the app, as the app
is not available on occasions due to server problems at Golden Security.
The HA integration is local, so in that case it still enables me to control
the alarm system.
RFID is not a big issue for me.
Op wo 18 dec 2024 om 20:07 schreef Ilia Sotnikov ***@***.***>:
… However still no log of the sensor open/close in the GS logbook or history
visible.
Unfortunately the mode comes with its limitations, basically what ends up
in panel's history will be reflected:
- Only wireless door sensors send open/close alerts
- Cord sensors don't send those alerts
- Motion sensors don't send those either
- Panel state changes (alarm/disarm/etc) send corresponding alerts
- There is a slight delay of several seconds before HASS will show
state changes
Hence, with RFID not yet supported it leaves only wireless door sensors in
the list. Plus, you might want to enable door open alerts in mobile
application (alerts section) - that isn't required for normal setup (when
panel is in same network segment as HASS), but might be helpful.
Hope that clarifies.
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJDX736OHIETM3SMGCOICWT2GHBX3AVCNFSM6AAAAABTPTPXHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJSGA3TCNJYHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thanks for testing the changes and sharing your findings, @Cimpel !
My understanding of "detect door&windows" option is slightly different - if enabled on the sensor there will be notification if door/window is left open when panel is armed. While we're looking at enabling 'door open' alert in the panel configuration (iOS app names it 'Alarm alert'), not at the sensor level. Once enabled that should help reacting at wireless sensors at least.
Well, that isn't yet supported unfortunately - I plan to have it added in some near future. Though it poses another challenge - the panel will get armed despite detecting open door/window, we might consider reverting it to disarmed by means of component, doing just notifications etc. I don't think I have a concert solution here yet, just thoughts.
Unlikely because of HA integration, I wouldn't call mobile apps for the panel best in class, to be honest.
Thanks, that is exactly the reason I've implemented the component ;) Although panel occasionally starts to timeout local commands sent by HA when their servers are down (not fatal, just annoys sometimes).
Thanks for sharing, I do plan to have it at least initially implemented so you could test. |
|
Indeed I (mis)interpreted the alert at the sensor level, so you refer to an
alert when armed.
My experience is that when a door/window is left open, the panel will not
arm (from the keypad) until you really close the corresponding door/window
and the voice message will inform that you need to close door/window x.
(sometimes you might need to open and close the door/window as the panel
missed the close signal).
However, if you arm by means of the app, then the panel will arm anyway
despite any open door/window.
Op wo 18 dec 2024 om 20:58 schreef Ilia Sotnikov ***@***.***>:
… Thanks for testing the changes and sharing your findings, @Cimpel
<https://github.com/Cimpel> !
I understand the limitations. I tested with a wireless door sensor (nr 7
in the diagnostic log) which also has the "detect door&window" alert option
in the app enabled. From these sensors no state changes are detected and
are always reported as "closed".
My understanding of "detect door&windows" option is slightly different -
if enabled on the sensor there will be notification if door/window is left
open when panel is armed. While we're looking at enabling 'door open' alert
in the panel configuration (iOS app names it 'Alarm alert'), not at the
sensor level. Once enabled that should help reacting at wireless sensors at
least.
I hoped to use your notifications to alert me that one of the windows or
doors were left open on arming the alarm system.
Well, that isn't yet supported unfortunately - I plan to have it added in
some near future. Though it poses another challenge - the panel will get
armed despite detecting open door/window, we might consider reverting it to
disarmed by means of component, doing just notifications etc. I don't think
I have a concert solution here yet, just thoughts.
The original alerts I got from the 90B disappeared for some reason a while
ago. Can this have to do because I installed the HA integration ? Maybe
deinstall it to test if they are back again in that case
Unlikely because of HA integration, I wouldn't call mobile apps for the
panel best in class, to be honest.
I like the HA integration because it's a nice backup for the app, as the
app is not available on occasions due to server problems at Golden
Security. The HA integration is local, so in that case it still enables me
to control the alarm system.
Thanks, that is exactly the reason I've implemented the component ;)
Although panel occasionally starts to timeout local commands sent by HA
when their servers are down (not fatal, just annoys sometimes).
RFID is not a big issue for me.
Thanks for sharing, I do plan to have it at least initially implemented so
you could test.
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJDX736QPOX5SQO5SBTQDRD2GHHW7AVCNFSM6AAAAABTPTPXHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJSGE2TSMZRG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thanks, @Cimpel - just checking, did it get better if you'd enable door open alerts at the panel level? |
|
I did a test with the panel armed: Both when opening or closing the door
when armed, I get a message in the logbook including the name of the
corresponding sensor.
So far so good. Thumbs up
Like said before it would be nice to also get a "close" message when a
door/window is closed without the panel being armed.
Thus you know proactiv for sure that the panel knows that the door/window
is closed (and doesn't discover that during arming the panel).
The same for a "low battery" message. It would be nice that you could get a
message that the sensor has a low battery so that you can change the
battery timely. (originally these kind of messages were also sent by the
panel to the app)
Op do 19 dec 2024 om 19:04 schreef Ilia Sotnikov ***@***.***>:
… Thanks, @Cimpel <https://github.com/Cimpel> - just checking, did it get
better if you'd enable door open alerts at the panel level?
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJDX732Z2QNAG5RX3F2G4K32GMDBLAVCNFSM6AAAAABTPTPXHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJVGQ2TSNJSGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Nice to hear, thanks!
Will implement such functionality (reacting to a window being open when the panel is being armed), if I understand you right.
It is there already, though likely not well documented ;) each wireless sensor has |
|
The "low battery" attribute I already discovered and developed a template
to detect that and generate a notification.
Till now the batteries seemed OK as I didn't get a message yet ;-)
The "closed" message should be sent immediately after the corresponding
door/window is closed.
Not at the moment the panel is armed, although that would be nice also in
the case we forgot to close a door/window.
Op do 19 dec 2024 om 21:47 schreef Ilia Sotnikov ***@***.***>:
… I did a test with the panel armed: Both when opening or closing the door
when armed, I get a message in the logbook including the name of the
corresponding sensor. So far so good. Thumbs up
Nice to hear, thanks!
Like said before it would be nice to also get a "close" message when a
door/window is closed without the panel being armed. Thus you know proactiv
for sure that the panel knows that the door/window is closed (and doesn't
discover that during arming the panel).
Will implement such functionality (reacting to a window being open when
the panel is being armed), if I understand you right.
The same for a "low battery" message. It would be nice that you could get
a message that the sensor has a low battery so that you can change the
battery timely. (originally these kind of messages were also sent by the
panel to the app)
It is there already, though likely not well documented ;) each wireless
sensor has low_battery attribute - it will be set to true if sensor
reports such condition, though the attribute will reset to false upon HA
restart. With that, you could do a custom automation
<https://www.home-assistant.io/docs/automation/trigger/#triggering-on-attribute-changes>
when attribute changes to true - e.g. adding persistent notification etc.
You can look at those attributes in Developer tools -> states in HA
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJDX73Y3XQXB3ZFMQTBCP2D2GMWFXAVCNFSM6AAAAABTPTPXHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJVG42DGNRVGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Got the next error message:
Logger: pyg90alarm.device_notifications
Bron: runner.py:154
Eerst voorgekomen: 12:46:39 (1 gebeurtenissen)
Laatst gelogd: 12:46:39
Received alert from wrong device: expected 'GA180198G000708', got ''
The text was updated successfully, but these errors were encountered: