Bosch Alarm Panel - MQTT Gateway

If you don’t have the installer code (which I also didn’t have), you will need to factory reset the unit.

Thanks Johnty.
I am also interested in how you do your serial connection to Bosch Alarm. Would you mind email me the instruction on how to set up serial communication to the Bosch alarm system? my email is dcvu88 at gmail.com. Many thanks

Hey all, sorry for bumping an old thread, but I’ve been trying to develop a python API for the Bosch Alarm b426 module to integrate with my Home Assistant setup. I’ve had some success, but there are parts of the protocol I haven’t been able to decode.

I’d love to see your code @Johnty or anyone else to figure out what I’m doing wrong (can’t get the arm/disarm commands to work).

My very early stage API is here if anyone is interested: GitHub - nicsuzor/boschalarm: Python API for Bosch b426 alarms (security 2000/3000)

1 Like

Hi Nic,

A while back, Bosch did release a plug-in for Vera Controller. Please go to the URL below and download the ZIP file (at the bottom of the page). There is a file in that ZIP file L_BoschSolutionAlarmPanel1.lua which has what you are looking for. Hope it helps!

1 Like

@nicsuzor how much progress have you had, were you able to see states of sensor and been able to set arm/disarm?

Did you get much from the bosch vera integration?

I’d love to see a hacs integration for Bosch sol 2000/3000

Hi @Johnty,

I too would be interested in understanding how it might be possible to integrate Bosch alarms into home automation (I previously started looking at OpenHab but admittedly have not got very far).

I currently have a 2 x 880 (1 x Ultima? & 1 other ICP-CC488?) and am about to try upgrading to Solution 3000 with B426-M (if I can get the damn thing to connect to A-Link!)

I have also tried connecting the 880 via an Arduino, but tbh wasn’t sure about the pin assignments and couldn’t get a serial connection to work.

Any insights or info you have would be most interesting and appreciated. bazzrington is my gmail.

Cheers

Stephen.

Hi all,

Just wanted to provide some extra info not listed here. I’ve been contributing on other security alarm related forums regarding Bosch/EDM Solution alarms and serial adapters, with the ultimate goal of incorporating web functionality with Bosch 844/862/880 series and earlier Solution panels.

I have detailed previously here: HOW-TO based on Yes Thomas!'s article the pin-out and spec of the Solution alarm serial output (on the “AUXILIARY MODULE” header) and, in turn, the “Direct Link Cable” (part CC816):

5V TTL output from panel - use a USB or RS-232 adapter that supports 5V logic or use a logic level shifter between the panel and your device:

  1. not connected
  2. not connected
  3. Panel TX (RX on your serial interface)
  4. Ground
  5. not connected
  6. not connected
  7. Panel RX (TX on your serial interface)
  8. not connected

I’ve also experimented with monitoring the data between EDM/Bosch’s ALINK and A-Link Plus DOS/Windows software to try to intercept the exchange, including zone status, alarm status and panel status such as faults.

I had already confirmed this works with my Solution 880 with ALINK (via DOSBox) and AL+ software (Windows only) as a direct replacement for the CC816 cable, but I’ve now got a breakthrough - I’ve been able to, in some form, work out the serial parameters.

GOTCHAs: you need 5V serial logic, the installer code in the panel and software must match, and so must one of the subscriber IDs in the dialler settings for the alarm (it also must not be 0).

Messages and commands are sent (at least from the DOS software) as 300 baud 8N1 serial, with no flow control or parity bits.

So far, I’ve managed to control everything available in the ALINK software via serial messages sent from my PC EXCEPT for the “codepad simulator” as I can’t work out the checksum format.

I have the following messages for my particular system, which is strictly for experimentation so if you managed to somehow crack my installer code (hint: it’s the default 1234) then good for you. (all values are in hex)

  • ARM (AWAY mode): 0E 01 00 00 00 00 00 00 00 00 17
  • Get status only: 01 00 49 60 43 21 00 00 00 00 15
  • DISARM (any): 0E 02 00 00 00 00 00 00 00 00 18
  • Request dialler memory*: 0E 07 00 00 00 00 00 00 00 00 1D
  • Siren on: 0E 05 00 00 00 00 00 00 00 00 1C
  • Siren off: 0E 06 00 00 00 00 00 00 00 00 1D
  • Remote output 1 on: 0E 03 00 00 00 00 00 00 00 00 1A - the 3rd byte (after 0E 03) is (2^n)-1 for the output desired
  • Remote output 1 off: 0E 04 … 1A (as above except 0E 04 not 0E 03)
  • Request journal*: 0E 0A 00 00 00 00 00 00 00 00 21
  • Query faults*: 0E 0B 00 00 00 00 00 00 00 00 21

Messages without an asterisk (*) return the panel status after the issued commands, those with a * return the requested data in a different format.

Codepad messages:

  • press 2 key: 0C 02 00 00 00 00 00 00 00 01 17.

I believe (following a lot of trial and error) these messages encode a sequence of up to 8 keystrokes at a time in the following format:

  • 0C aa bb cc dd ee ff gg hh [count] [checksum]

where aa through hh represent keystrokes 1-8, [count] is the number of strokes sent and the checksum closes the message. If you have any idea of what formula the checksum may use, please comment below. I have a rudimentary lookup table of values for each key, where the checksum base value seems to be 0x15 (d signifies a decimal value NOT a hex):

Key: Value / Checksum difference (from single key messages)

  • 1: 01 / +1d
  • 2: 02 / +2d
  • 3: 03 / +4d
  • 4: 04 / +4d
  • 5: 05 / +6d
  • 6: 06 / +6d
  • 7: 07 / +6d
  • 8: 08 / +7d
  • 9: 09 / +10d
  • 0: 00 / +1d
  • */STAY: 1b (27d) / +16d
  • #/AWAY: 1a (26d) / +26d

Messages from panel:

  • Status (example): 04 48 60 AA 00 00 00 AA FF 01 C1 04 CD
    Format: 04 48 ?a bb cc dd ee ff gg hi j? ?? ??

As best as I can determine:

  • 04 is the message type (status)

  • 48 may be the panel type (mine is a CC408/Solution 880)

  • a is the state of each remote output (RCx = [2^x] summed)

  • bb (and possibly cc) is the “open” state of each zone, in groups of 4 zones. bb seems to be 5 = 1, 6 = 2, 7 = 3, 8 = 4 summed for the “left” nibble, 1 = 1, 2 = 2, 3 = 4, 4 = 8 for the “right” nibble. cc is adjacent and may be used on the CC880/Solution 16 (left nibble may be zones 13-16, right may be 9-12).

  • dd (and possibly ee) is the “isolated” state of each zone (i.e. the zone is currently flashing slowly on the keypad due to being isolated). I’m not sure if this includes STAY mode isolation or not. I would suspect this would be encoded the same as bb/cc.

  • ff (and possibly gg) are zones that are currently in alarm or alarm memory (i.e. fast flashing on the keypad), encoded the same as bb-ee. gg is always 0xFF for me, so it could also be a timing bit.

  • h - 0 if not armed STAY, 1 if armed STAY

  • i - 0 if not armed AWAY, 0xA if armed AWAY

  • j - must be some sort of status, I know 4 is added to the value if the sirens are running.

  • ? - NFI

  • Fault list (example): 11 48 03 00 00 00 00 00 09 10 7E
    Format: 11 48 aa ?? ?? ?? ?? ?? ?? ?? ??

As best as I can tell:

  • 11 is the message type (fault list)
  • 48 may be the panel type (as above)
  • aa - like the zones in the status listing, encodes the “on/off” of each fault. 03 in my case was a low battery/time/date fault, faults 1 and 2 (1 = 1, 2 = 2, 3 = 4, 4 = 8). As mine is a non-Ultima panel, I only have the 8 fault types:
  1. Low battery/battery fail
  2. Date/time not set or lost
  3. Sensor watch
  4. Horn speaker fail (when monitoring is enabled)
  5. Telephone line fail
  6. E2 fault (checksum error in memory)
  7. Fuse fail
  8. Communications fail

I’m suspicious that some of the following bytes may encode more detailed fault status on Ultima panels which have the 2 stage diagnosis (for RF).

I’m still working on the journal and dialler but am afraid it may be beyond my knowledge.

I’m hoping the above will help - I suspect that non-CC408 panels (and NOT the ICP-CC40x) may have different message headers and that panel type may change, but can’t confirm this as I only have the one panel.

There is one request I can’t work out what it does, but the software sends it about once every 30-60 seconds:

0E 08 00 00 00 00 00 00 00 00 1E

At one point, the request was returned with:
08 48 00 16 69 8d 08 00 00 00 6b

then the next one came back with:
08 48 00 16 69 8D 09 00 00 00 6D

It almost looks like a status but I’m not certain what any of it is encoding.

This could be some sort of “synchronisation” or “check” as ALINK will detect if the connection fails, possibly even a different status that also includes a timestamp?

Further, here are the header bytes I’ve been able to solve (most requests sent to panel are 13 bytes):
01: Request to panel for status (usually returns 11 bytes)
04: Panel status details
08: ??? (usually returns 11 bytes)
0C: Keystroke to panel
0D: Dialler memory (possibly 0D xx 98?) or journal (possibly 0D xx F2?). Dialler memory returned was 156 bytes, journal returned was 246 bytes, in my case).
0E: Command to panel
11: List of faults (usually 11 bytes)

Example dialler memory (no events I don’t believe):
0d 48 98 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 86

Example journal (unfortunately what came up in it via ALINK escapes me):
0d 48 f2 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 4d d6 82 58 1f 01 01 20 30 4d 01 1f 01 20 00
40 10 00 03 03 80

Just to reply to my own message with something I discovered yesterday:

The status command actually encodes the subscriber ID (or at least, in my case, the last 4 digits) and the installer code.

When I defaulted my panel and set domestic dialling using command 965 in programming mode (which sets the subscriber ID to 000001), I noticed the status command changed. Importantly, I could still ARM/DISARM and issue other commands WITHOUT needing matching sub ID or installer code, which you could argue is a security hole.

I’ve now determined that the status request command is as follows:

01 00 ss ss ii ii 00 00 00 00 cc

ss ss = reversed last 4 digits of sub ID; e.g. if your subscriber ID is 123456 ss ss will be 65 43
ii ii = reversed installer code; e.g. the default 1234 becomes 43 21
cc = checksum which I still can’t quite work out

I will continue to work on decoding this - I may re-upload this command list and structure with default domestic settings so if you want to integrate it you can just borrow the commands verbatim.