Jablotron JA-80 series and JA-100 series alarm integration

Third party integrations
41

Thanks @plaksnor. I am familiair with these cables, I am using the same cable to configure my JA-100 series via Jablotron F-Link software.

It surprises me a bit that you are using a standard USB cable, because @mattsaxon explicitly mentioned that he used a JA-82T USB/Serial cable (https://github.com/mattsaxon/HASS-Jablotron80) to connect to his Jablotron 80 panel.

I am not familiair with the Jablotron 80 series, but this might be a difference between the 80 and the 100 series… (80 series requires USB to Serial cable, 100 series doesn’t?)

42

@Marcel1 I’m not sure if a JA-82T USB/serial cable on a 80-series differs from a standard USB cable on a 100-series. I just looked at the ports of my JA-100 system, connected the cable and Windows showed a new device in My Computer (2 new drives actually) containing the J-link app. Since then I thought this might work. However, I’m not sure if another cable would give me better or other results. Worth trying.

But since you also have this cable, would you be able to test the script?

43

I am sure I am doing something wrong. Can’t figure out what though. This is thefirst time I am using a HASS custom component.

What I did so far:

  • created subfolder custom_components in /home/homeassistant/.homeassistant/
  • created subfolder jablotron in /home/homeassistant/.homeassistant/custom_components
  • created alarm_control_panel.py in /home/homeassistant/.homeassistant/custom_components/jablotron
  • script is executable for user homeassistantant
  • added the following to configuration.yaml
alarm_control_panel:
  - platform: jablotron
    serial_port: /dev/hidraw0     
    code: xxxx
    code_arm_required: False
    code_disarm_required: False
  • Also have i added the dubug logger:
logger:
  logs:
    custom_components.jablotron: debug

Only thing i can find in the homeassistant.log related to this is:

2019-05-13 21:44:53 INFO (MainThread) [homeassistant.setup] Setting up alarm_control_panel
2019-05-13 21:44:53 INFO (MainThread) [homeassistant.setup] Setup of domain alarm_control_panel took 0.0 seconds.

Result of: dmesg | grep hid

pi@hassbian:~ $ dmesg | grep hid
[    0.792848] hidraw: raw HID events driver (C) Jiri Kosina
[    0.795322] usbcore: registered new interface driver usbhid
[    0.797627] usbhid: USB HID core driver
[315444.521286] hid-generic 0003:16D6:0008.0001: hiddev96,hidraw0: USB HID v1.11 Device [Jablotron ltd JA-100 Flexi] on usb-3f980000.usb-1.5/input0
[512345.643182] hid-generic 0003:16D6:0008.0002: hiddev96,hidraw0: USB HID v1.11 Device [Jablotron ltd JA-100 Flexi] on usb-3f980000.usb-1.2/input0

Any idea what i might be doing wrong?
alarm_control_panel services are appearing in HASS, but there is no error or whatsover that i can work on. Also the enabling of the debug logging seems not to take effect. I doubt if the alarm_control_panel.py script is even called.

44

@Marcel1 I think your settings look good, although I have my code_arm_required and code_disarm_required both on True. I also have made an empty file
__init__.py
in the custom_components/jablotron folder.
Could you please try both, restart HA and check if that does make any difference?

45

It is finally loading. Changed a few things, I expect that emptying __init__.py was what did the trick (the __init__.py in the Git repro is not empty)

I had another hurdle to take, as the homeassistant account did by default not have permissions on /dev/hidraw0. This is also fixed.

Now it looks like data is not being received.

pi@hassbian:/dev $ tail -f -n 99999 /home/homeassistant/.homeassistant/home-assistant.log | grep 'alarm\|jablotron'
2019-05-14 22:14:17 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for jablotron which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-05-14 22:14:17 INFO (MainThread) [homeassistant.loader] Loaded jablotron from custom_components.jablotron
2019-05-14 22:14:17 INFO (MainThread) [homeassistant.setup] Setting up alarm_control_panel
2019-05-14 22:14:17 INFO (MainThread) [homeassistant.components.alarm_control_panel] Setting up alarm_control_panel.jablotron
2019-05-14 22:14:21 WARNING (Thread-26) [custom_components.jablotron.alarm_control_panel] Data has not been received for 2 seconds, retry startup message
2019-05-14 22:14:22 INFO (MainThread) [homeassistant.setup] Setup of domain alarm_control_panel took 4.3 seconds.

By running sudo cat /dev/hidraw0 it seems that this assumption is correct.
@plaksnor: Did you had to enable something on the Jablotron control panel in order for it to send data?

Any other smart suggestions?

46

@Marcel1 great progress! And thanks for reporting back what went wrong.
I didn’t had to enable something in my Jablotron control panel. But the cause of the error is some of the changes in the original HASS 80 repo, which I reverted yesterday in my 100 series version of the script.

If you try this link, the “Data has not been received for 2 seconds” error wil disappear and things should work. At least, it did here.

47

Thanks @plaksnor. I can read the control panel status correctly now.
I’ve added support for PARTIALLY ARMING and PARTIALLY ARMED for the JA-100 series. These states were missing.
I’ve commited the changes (hopefully i did it correctly).

Setting (arming) and unsetting the control panel via HASS however is not succesfull.
The DEBUG log is not giving away much information to work on…

2019-05-15 21:54:38 DEBUG (Thread-23) [custom_components.jablotron.alarm_control_panel] Sending startup message
2019-05-15 21:54:39 DEBUG (Thread-23) [custom_components.jablotron.alarm_control_panel] Successfully sent startup message
2019-05-15 21:54:52 DEBUG (MainThread) [custom_components.jablotron.alarm_control_panel] sending *2
2019-05-15 21:54:58 WARNING (Thread-24) [custom_components.jablotron.alarm_control_panel] Data has not been received for 10 seconds, retry startup message
48

@Marcel1

I’ve commited the changes (hopefully i did it correctly).

Thanks. Yeah I noticed them when I’m looking at your fork of my repo, but it’s not showing your commit when I’m looking in my repo. I’ve tested your changes, but I’m unable to test it. To me it looks like these packets are never being send.

So with a JA-100KL series I got these 3 packets:

            b'\x01': STATE_ALARM_DISARMED, # unsure which zone
            b'\x83': STATE_ALARM_ARMING, # Setting (Full)
            b'\x03': STATE_ALARM_ARMED_AWAY, # Set (Full)

But your system is receiving other packets:

            b'\x82': STATE_ALARM_ARMING, # Setting (Partial - at home)
            b'\x02': STATE_ALARM_ARMED_HOME  # Set (Partial - at home)

…and probably one of the already known packet for the STATE_ALARM_DISARMED.

  • What kind of JA-100 series do you have? Maybe we should separate the packets for different series.
  • And are you sure you got a STATE_ALARM_ARMED_HOME? Looking at the range of the packets (the 02 packet is near the 03 packet which indicates a STATE_ALARM_ARMED_AWAY state), I would expect the 02 packet is also an ARMED_AWAY state.

I’m not sure if our JA-100 series support a ARMED_HOME state, because how would you arm it home when you’re using at a regular basis? My alarm is disarmed, arming or armed. Not somewhere inbetween I guess, but I might be wrong.

Setting (arming) and unsetting the control panel via HASS however is not succesfull.

For me it takes a while (max 10 seconds) to get HASS showing the latest state of the system. So am I right if you don’t see anything in your history in your Jablotron app? The first time I succesfully armed the system in HASS, I wasn’t realizing I actually armed the system until I noticed the history in the Jablotron app.

The DEBUG log is not giving away much information to work on…

True, my bad. I removed a couple debug lines, which I shouldn’t. I’ll put them back soon, so we could debug your situation in a better way. Thanks for testing though!

49

@Marcel1: Committed changes in latest dev branch, please look here:
Added states, debug lines and redefined actions for control panel

50

@plaksnor
My system is a JA-101K. It definitely supports STATE_ALARM_ARMED_HOME.
I am pretty sure yours does as well. I am using it at night, it only arms my doors and allows my kids to roam through the house without triggering any alarm.
On the keypad it looks like this (orange lights instead of red)
orange red

Probably, because your system was not configured for PARTIAL ARMING, these codes are indeed never sent.

Below you see a screenshot of the Jablotron F-LINK software. The “intern” column shows checkboxes. The devices that are checked will not be armed when you arm your JA-100 series partially (in my case the PIR in the kitchen and livingroom)

Knipsel
Knipsel1107×328 24.3 KB

I initially tested your code (without my modifications). HA gave correct states for ARMING AWAY, ARMED AWAY and UNARMED. When i manually ARMED my system for at home (Partially armed - Orange LED indicator), the Jablotron HA module did not recognize the \x82 and \x02 packages, hence I already assumed you are not making use of the ARMED at HOME (Partially arming) functionality in your system and for that reason I decided to add these states to the project. After adding the modifications locally, my HA did correctly provide the newly added statuses (ARMED AT HOME and ARMING AT HOME).

btw:
I just realized that you might not have the Jablotron F-link software available, probably only J-link. J-link is software with limited capabilities for the customer, and it probably does not allow you to configure a ARMED at home mode, where the F-link software does allow you to configure all parameters of your system. F-link is also exclusively available to the installer company/engineer and not downloadable.

Looking forward to your updated code so that I can further troubleshoot why I can successfully read all the statuses correct in HA now, but why i am not able to set the system via HA in any state.

I will be out of the country for a few days, hence will not be able to get back to you before Monday.
Cheers!

51

Really nice work so far guys! Eager to try this out on my Oasis-80 model soon…
@aryu wasn’t your solution capable of reading out the PIR status? That would be my primary usecase. Maybe you could assist with your lessons from building that?

1 Like
52

@plaksnor
Arming the alarm via HA also works now.
I’ve sniffed the traffic between the J-link software and the control panel and found out that the “Arm at home” action (or *2) is '\x80\x02\x0d\xb0'. I’ve added this to your code, tested it and created a pull request into your DEV branch.

btw: I have found out that when using Windows, the USBPcap tool works great to sniff the serial traffic to and from the Jablotron control panel. Wireshark can be used to read the .pcap files that the command line tool generates

54

Can you submit a Pull Request for my repo and I’ll merge and test to make sure the JA-80 series are still working with you changes. Good progress has been made though by the looks of it!

55

The 80 series doesn’t have a USB on the control panel (it has a 4 pin serial connection, so the JA-82T is a USB to serial device to deal with that difference.

I expected stock ones should work too, but I haven’t tried myself.

56

@plaksnor: I’ve submitted a new pull request into your dev repo.
Maybe good to merge my modifications into yours first, before you merge into @mattsaxon’s repo

My latest version also supports the “Alarm triggered state” for the JA-100 series. Now I can finally flash all my livingroom and kitchen lights upon alarm triggering :clap:

BTW: Strangely enough, the “Alarm Triggered” state does not start with \x51\x22\ like all other states do, but with \x44\x05.

Entire state code for “Alarm Triggered” is \x44\x05\x7f\

Knipsel

57

Sorry all, wasn’t able to catch up on this.

@Marcel1: great progress! Nice to see ‘armed home’ in action. Wasn’t aware of this, because my system has not been configured this way. Thanks for the info! I do not possess F-link, only J-link. And great to read arming the system also works for you now! You even catched a triggered alarm, great!

I was thinking about the activation codes/bytes you are using, which are different. Could it be that there’s a difference between arming the system by control panel or by app or even key tag? Because recently I noticed that the Jablotron app and also the Jablotron web service show different statusses when arming it in different ways. So these actions were probably triggered by different codes. However, we were both sniffing packets in the same way: locally connected, arming the system from the virtual keypad in J-link or F-link. The software was pretty much the only difference.

I’ll try to merge your modifications into mine and then submit a pull request for matt’s repo.

By the way: how is your experience with the latency of the script? I do notice some delay because of the loop of the startup message (since this seemed to be the only way to trigger a response).

58

@mattsaxon: Created pull request https://github.com/mattsaxon/HASS-Jablotron80/pull/2

@Marcel1: Something worth mentioning: a week or two ago I’ve send my sniffing results to Matt. I also discovered that we are able to discipher sensor states.

I was monitoring J-link and noticed that every sensor will light up with a yellow background when it’s triggered, just like you can see in your screenshot of F-link with cell ‘Actie’ in column ‘Status’.
In my case, device/ID/position 6 was triggered. This is the sensor which went on when passing by.

While analyzing the logfile, I wrote down the packet numbers of my recording.
I’m displaying my results as a decimal instead of hex:

315 (packet number in logfile)

82 7 138 1 4 0 0 0 243 0 0 16 244 0 0 0
0 0 0 0 12 41 0 16 0 0 0 0 12 0 0 0
1 0 0 0 217 211 0 0 0 0 0 0 100 4 0 16
11 0 0 0 124 69 0 16 0 0 0 0 151 82 3 0

324

82 9 138 2 4 0 142 0 1 52 8 0 244 0 0 0
0 0 0 0 12 41 0 16 0 0 0 0 12 0 0 0
1 0 0 0 217 211 0 0 0 0 0 0 100 4 0 16
11 0 0 0 124 69 0 16 0 0 0 0 151 82 3 0

328

82 9 138 3 4 32 226 3 1 114 7 0 244 0 0 0
0 0 0 0 12 41 0 16 0 0 0 0 12 0 0 0
1 0 0 0 217 211 0 0 0 0 0 0 100 4 0 16
11 0 0 0 124 69 0 16 0 0 0 0 151 82 3 0

332

82 9 138 4 4 0 206 1 252 19 10 0 244 0 0 0
0 0 0 0 12 41 0 16 0 0 0 0 12 0 0 0
1 0 0 0 217 211 0 0 0 0 0 0 100 4 0 16
11 0 0 0 124 69 0 16 0 0 0 0 151 82 3 0

335

82 9 138 5 4 0 88 0 252 177 10 0 244 0 0 0
0 0 0 0 12 41 0 16 0 0 0 0 12 0 0 0
1 0 0 0 217 211 0 0 0 0 0 0 100 4 0 16
11 0 0 0 124 69 0 16 0 0 0 0 151 82 3 0

339

82 9 138 6 12 0 3 0 252 19 10 0 244 0 0 0
0 0 0 0 12 41 0 16 0 0 0 0 12 0 0 0
1 0 0 0 217 211 0 0 0 0 0 0 100 4 0 16
11 0 0 0 124 69 0 16 0 0 0 0 151 82 3 0

344

82 9 138 7 4 0 31 0 252 148 10 0 244 0 0 0
0 0 0 0 12 41 0 16 0 0 0 0 12 0 0 0
1 0 0 0 217 211 0 0 0 0 0 0 100 4 0 16
11 0 0 0 124 69 0 16 0 0 0 0 151 82 3 0

348

82 9 138 8 4 0 250 0 252 147 10 0 244 0 0 0
0 0 0 0 12 41 0 16 0 0 0 0 12 0 0 0
1 0 0 0 217 211 0 0 0 0 0 0 100 4 0 16
11 0 0 0 124 69 0 16 0 0 0 0 151 82 3 0

351

82 9 138 9 4 0 110 1 252 147 10 0 244 0 0 0
0 0 0 0 12 41 0 16 0 0 0 0 12 0 0 0
1 0 0 0 217 211 0 0 0 0 0 0 100 4 0 16
11 0 0 0 124 69 0 16 0 0 0 0 151 82 3 0

355

82 9 138 10 4 0 223 0 252 20 10 0 244 0 0 0
0 0 0 0 12 41 0 16 0 0 0 0 12 0 0 0
1 0 0 0 217 211 0 0 0 0 0 0 100 4 0 16
11 0 0 0 124 69 0 16 0 0 0 0 151 82 3 0

363

82 9 138 11 4 0 46 0 252 212 10 0 244 0 0 0
0 0 0 0 12 41 0 16 0 0 0 0 12 0 0 0
1 0 0 0 217 211 0 0 0 0 0 0 100 4 0 16
11 0 0 0 124 69 0 16 0 0 0 0 151 82 3 0

and some more.

Let’s take a look at the contents of these packets.

  • It looks like the first device starts with: 82 7 138.
  • All other devices start with: 82 9 138.
  • Then the 4th byte is the device ID.
  • And the 5th byte seems to be the state of the sensor. Value 4 = off. Value 12 is on.

The fact that packet 339 contains device ID 6 and has a different state value (12) than all other packets (4) and was the only sensor here at home which has been triggered, looks like this is the data we’re looking for.
However, I wasn’t able to figure out what’s the right packet to get these packets submitted.

So in short: If we’re only able to get these packets send, I’m convinced we should be able to make sensors for HA.

59

@plaksnor: I think you are correct with regards to the different activation codes. I indeed only sniffed serial traffic when using the J/F-link software. I have a Jablotron system with GSM module. I remember that when I used to dial in via phone on the system and armed the system via the voice menu (Press 1 for arming full, Press 2 for arming partial, etc.) it immediatly got armed without the (in my case) 15 seconds entrance and exit delays. This is not possible via the keypad. That indeed suggests that there are multiple arming/disarming codes. I will see if I can do some investigation on this.

On your second question regarding latency: I have changed your loop from 10 to 5 seconds some time ago, which seems to have improved performance. Based on what exactly was startup package \x00\x00\x01\x01 used?
When sniffing my traffic from J/F-link to the control panel, the software seems to send a sort of keep-alive/ping package exactly every second. This code is 520102 (\x52\x01\x02). See below.

Knipsel
Knipsel1156×666 45 KB

I haven’t really tried it yet, but implementing the loop like this (loop 1 second and different startup code) might improve performance even more.

Good to see that you guys are already working on deciphering the sensor states. Last week I indeed also concluded that technically it probably should be possible to imports the sensors into HA. I am afraid that I am lacking the phython skills, but if you guys are up to it, i am happy to contribute in deciphering and making small changes. I will do a bit of investigation on sensor states coming week myself as well.

One last thing: i’ve noticed that after disconnecting and reconnecting the USB cable between my PI and Jablotron control panel, there is no way to get the module working without a HA restart. This could be a great improvement for future releases :slight_smile:

60

@mattsaxon & @plaksnor:
I think I have figured out all relevant codes for the wireless PIR’s and magnetic door detectors for the JA-100 series.
My system contains of 3 magnetic door detectors. One is wired, the other 2 are wireless. Furtheremore i have three motion detection PIRs, all three are wireless.

I also have an indoor and outdoor siren, both wired. 2 keypads, one wired and one wireless (I haven’t found a uscase in HA for integrating these components. Not yet :-))

The wireless door contacts send two codes upon detecting opening and closing. One in the format I will describe below (starting with 52), and another one in another format starting with 55. The wired door contacts send only the code starting with 55

I have been able to detect the logic in the codes starting with 52 (wireless).
So far I was also not able to detect much logic in the codes that start with 55 (this is the only type of code sent by wired door contacts)

All wireless sensors (both PIR and DOOR CONTACTS) send status messages starting with: \x52\x09\x8a\
The next 2 hex digits represent the device id as displayed by J/F-link. So my frontdoor (device id 6) status codes are sent as \x52\x09\x8a\x06\

For the magnetic door contacts, the next two hex digits represent the actual status:

  • Door opened: 0c
  • Door closed: 04
    So door open is:\x52\x09\x8a\x06\x0c\ and door closed is: \x52\x09\x8a\x06\x04\

For the wireless PIR, I have been able to detect just one status code, which obviously is for movement, this is: 04
To me it appears that the PIR is not sending a code once movement is not detected anymore.

So, above should be sufficient info to work on I guess…

In case you have wired doorcontacts, i’ve added the 55 codes that i captured as well. Maybe someone is able to detect any logic in it?

To elloborate a bit more in the 55 codes:
My wired doorcontact has device id 9
The codes captured for it:

  • Door Open: 5508008c4002804d900800000b0000000800000054290010
  • Door Closed: 5508008e4002a04db00800000b0000000800000054290010

My frontdoor wireless doorcontact (with id 6) next to the 52 codes, also sends the following 55 codes:

  • Door Open: 550901808001104e100914001455001055320500bba30100
  • Door Closed: 550901828001304e300914001455001055320500bba30100

My backdoor wireless doorcontact (with id 7) next to the 52 codes, also sends the following 55 codes:

  • Door Open: 55090184c0017013710e08000b0000000800000054290010
  • Door Closed: 55090186c0019013910e11000b0000001100000054290010
61

Regarding the decreased _watcher_loop interval:
If I set it like this (2 and 5 seconds):

            if not self._data_flowing.wait(2):
                _LOGGER.warn("Data has not been received for 2 seconds, retry startup message")
                self._startup_message()         
            else:
                _LOGGER.debug("Data is flowing, wait 5 seconds before checking again")
                time.sleep(5)

…it will try to send a message every 2 seconds. However, I get a response back every 15 seconds (and definitely not every 2 seconds. Something is holding up and this reminds me to what Matt was wondering before:

Is there any reason for you to rerun the test.py (5 times in your example), for my system once the start message is sent, it just keeps sending data non stop…

So maybe we need to figure out if the 100-series has a different startup message in order to get a stream of data.

Regarding the startup message:
\x00\x00\x01\x01 was the default startup message of Matt. And since my alarm system was not sending some kind of keepalive pulse every th second, Matt decided to make the _watcher_loop function. Which works and is great of course, but isn’t working with a small interval (here).

Regarding the sensor data:
Great work deciphering several sensor types, this is a great peace of work! :smiley: When J/F-link is running and my host is locally connected (by USB) with the alarm system, I do get information about sensors (at least when the ‘Diagnostics’ tab has been opened). But I don’t get this data when I close J/F-link. Are you saying you’re also getting sensor info when J/F-link is not operational?