Bosch Solution 2000 / 3000 Alarm Integration

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 :wink:

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.