Thanks Sanjay, works well !!!
Is this integration still working ?
Im getting errors on init__.py line 27 when i install?
not logged into RSC app and do not own alink.
File â/config/custom_components/solutions3000/init.pyâ, line 27, in async_setup_entry
got it working by changing to entry.data[CONF_HISTORY], but i have no idea what i did.
EDITED: nevermind restarted HS and it stopped ? :S
whats the error? there should be a proper stack trace. I am using it right now so it does work.
also what version of home assistant are you using?
Iâm getting the same error as joeooo.
2022-06-11 09:44:54 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Home for solutions3000
Traceback (most recent call last):
File â/usr/src/homeassistant/homeassistant/config_entries.pyâ, line 339, in async_setup
result = await component.async_setup_entry(hass, self)
File â/config/custom_components/solutions3000/init.pyâ, line 27, in async_setup_entry
entry.options[CONF_HISTORY],
KeyError: âshow_historyâ
No stack trace, using Bosch Solution 2000 and Home Assistant 2022.6.3.
Thanks for your help.
Actually I got it to work. I had to click on Configure in the integrations page and specify the number of records to pull from the history as itâs blank by default and restart HA.
Thanks a lot for this work, this is awesome!
Is anyone getting timeout issues after awhile (ie. after a few weeks of Home Assistant being up, the connectivity times out). Restarting Home Assistant solves the problem immediately.
its interesting because for a while i was getting that but it stopped after a while, i at one point made some changes in the hopes of solving that issue but now that it has stopped happening for me I canât really do a whole lot about it
Hey guys,
Sorry prob a silly question but is this still on HACS?
I canât find itâŚ
Got my self a fresh install
you probably need to add the repository yourself
Thanks for your excellent work! The whole configuration process is so easy!
Just have a question. After my Solution 3000 detected a motion when it was set to âarm awayâ, it entered a 60-second wait time because of the delay setting. During this period, the state of alarm shown in HA changed from âarmed_awayâ to âarmingâ. And it finally changed back to âarmed_awayâ at the moment when the actual alarm went off and sirens started to scream. In the whole process, I didnât see the âtriggeredâ state. Is this normal or not? Thanks.
Unfortunately the API i am using for detecting the state does not actually tell me when it is triggered. Did the log from the alarm itself state that it triggered? If so i may be able to implement something that reads that.
Hi Sanjay, I think the log suprisingly reflects it. In my log, it shows:
code_format: null
changed_by: null
code_arm_required: true
panel_history: 2022-07-08 14:46:12 | PUSH RES. MOD 1
2022-07-08 14:40:40 | PUSH FAIL MOD 1
2022-07-08 14:39:30 | Z2 Alarm Restore
2022-07-08 14:39:30 | User1 Disarm
2022-07-08 14:39:19 | Z2 Alarm
2022-07-08 14:38:43 | Z2 Trouble Restore
2022-07-08 14:38:31 | Z2 Trouble
2022-07-08 14:38:31 | User1 AWAY Arm
2022-07-08 14:10:56 | System reset
2022-07-08 14:10:24 | System reset
friendly_name: Alarm System
supported_features: 15
And this one looks suspicious which happened right before I manually disarmed:
2022-07-08 14:39:19 | Z2 Alarm
What I am assuming is that,
- âZ2â means Zone 2
- âTroubleâ â a zone detects something and enters waiting period before officially going off
- âTrouble Restoreâ (not sure what it means, maybe just represents the countdown gets reset)
- âAlarmâ â alarm goes off
- âAlarm Restoreâ â alarm reset, sirens stop screaming
Unfortunately, I havenât got a chance to try a few more times. Iâll update here once I have chance to do it.
Try the latest version, i think i may have found how to get the API to give me information on the triggered alarms
Not currently able to trigger my alarm and test it, ill give that a go tomorrow maybe if i can.
Interestingly, i put mine into that waiting period and got no trouble logs from it (i didnt really want to trigger the siren as its a bit late here at the moment). Supposedly trouble usually means something went wrong so maybe that was just a weird glitch
Thank you Sanjay! I will give it a go tomorrow.
Hi Sanjay, still no luck, it still act in the same way.
panel_history: |-
2022-07-16 16:40:39 | PUSH RES. MOD 1
2022-07-16 16:35:37 | PUSH FAIL MOD 1
2022-07-16 16:34:37 | User1 Disarm
2022-07-16 16:34:31 | Z1 Alarm Restore
2022-07-16 16:34:31 | Z1 Alarm
2022-07-16 16:33:51 | Z1 Trouble Restore
2022-07-16 16:33:50 | Z1 Trouble
2022-07-16 16:33:50 | User1 AWAY Arm
2022-07-08 14:46:12 | PUSH RES. MOD 1
2022-07-08 14:40:40 | PUSH FAIL MOD 1
not expecting much out of the history, did you find anything happend with the area_alarms property?
code_format: null
changed_by: null
code_arm_required: true
panel_history: |-
2022-07-16 16:40:39 | PUSH RES. MOD 1
2022-07-16 16:35:37 | PUSH FAIL MOD 1
2022-07-16 16:34:37 | User1 Disarm
2022-07-16 16:34:31 | Z1 Alarm Restore
2022-07-16 16:34:31 | Z1 Alarm
2022-07-16 16:33:51 | Z1 Trouble Restore
2022-07-16 16:33:50 | Z1 Trouble
2022-07-16 16:33:50 | User1 AWAY Arm
2022-07-08 14:46:12 | PUSH RES. MOD 1
2022-07-08 14:40:40 | PUSH FAIL MOD 1
area_alarms: ''
friendly_name: Alarm System
supported_features: 15
This is the whole property details. I didnât check âarea_alarmsâ while I was testing the alarm. This " area_alarm: ââ " is what I got after the test.