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.
@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 
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\
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).
@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.
@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.
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 
@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
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! 
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?
@Matt, I found an issue in the _read_loop function:
2019-05-27 01:07:10 INFO (MainThread) [homeassistant.components.alarm_control_panel] Setting up alarm_control_panel.jablotron,
2019-05-27 01:07:14 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron.alarm_control_panel] ReadLoop: Acquiring lock...,
2019-05-27 01:07:14 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron.alarm_control_panel] ReadLoop: Lock acquired.,
2019-05-27 01:07:14 INFO (ThreadPoolExecutor-0_2) [custom_components.jablotron.alarm_control_panel] StartupMessage: Acquiring lock...,
2019-05-27 01:07:14 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron.alarm_control_panel] ReadLoop: opened connection,
2019-05-27 01:07:14 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron.alarm_control_panel] ReadLoop: trying to read data,
2019-05-27 01:07:14 INFO (MainThread) [homeassistant.setup] Setup of domain alarm_control_panel took 3.9 seconds.,
2019-05-27 01:07:16 WARNING (ThreadPoolExecutor-0_1) [custom_components.jablotron.alarm_control_panel] Data has not been received for 2 seconds, retry startup message,
2019-05-27 01:07:16 INFO (ThreadPoolExecutor-0_1) [custom_components.jablotron.alarm_control_panel] StartupMessage: Acquiring lock...
It’s not able to read data. Here’s a part of my code, debugging while abusing _LOGGER.info:
self._f = open(self._file_path, 'rb', 64)
_LOGGER.info("ReadLoop: opened connection")
_LOGGER.info("ReadLoop: trying to read data")
new_state = self._read()
_LOGGER.info("ReadLoop: succesfully read data")
This is probably the reason why the Startup Message function is not able to acquire a lock (at least for my 100-series, maybe it’s not a problem for @Marcel1)
Hi Everybody,
I am looking at this thread for few weeks (btw very nice work ) and I have a question.
Is there is a possibility to use this integration with Raspberry even if my HA is installed on Freenas VM. Or do I need to migrate my HA to Raspberry?
Did anybody tried to use the JA-80BT Bluetooth adapter instead of the JA-82T cable?
Thanks
Hi @thoky, thanks!
No I haven’t tried using the BT adapter, I’m sorry.
And good question. At the moment, the Jablotron plugin is part of HA, which needs to be installed on the same system which is connected directly to the alarm system. Although I see some ways to workaround this, it’s not implemented yet. For example, there’s a way to run a python script on your RPi sending/reading MQTT messages, so HA (or any other application capable of reading MQTT topics) could control your RPi remotely.
Personally, I think this is a good enhancement when we’ve made some more progress in having better control of the system. Unfortunately, we’re not at this point yet. But I like the way you’re thinking
@thoky, I could see way of using a remote serial port also, using something like this http://ser2net.sourceforge.net/, but as @plaksnor says, we haven’t progressed that far as yet.
Ah I see, for your system, the read blocks, rather than say returning an error or an empty buffer, this never happens for my system. I’ll give some consideration to how to deal with that.
Thanks, that would be cool. I analyzed my USB recordings again and I think using another payload as a startup message would give me faster results. When I disable all acquire and release lines of code, the watcher loop is working much better and sending me something which looks like a continuous stream of data. cat /dev/hidraw0 is showing me more frequently incoming packets.
The new startup message I’m using now is:
80 01 01 52 01 0E
This will keep sending the alarm state every 2 seconds. I hope someone is able to try and confirm.
@plaksnor:
Regarding your question:
Are you saying you’re also getting sensor info when J/F-link is not operational?
No, not what i have seen so far. I tried to capture some data once but, but forgot to start F-link. I noticed that no data was received at all when not running the Jabltoron software on my laptop.
Ok, this looks good. When arming the alarm, it will immediately show the orange/yellow blinking arming icon in HA, which indicates the 15 seconds entrance delay. Never happened to see this before.
So if the script is going to handle locks properly for my system, the three of us are experiencing all the same behaviour.
@Marcel1: maybe you’re able to test my new startup message as well? This would give me more info if I’m the only one who needs to use a different message.
@plaksnor: I just did a very quick 5 min check right now. My version was configured on 5 seconds interval with the startupmessage i mentioned earlier: \x52\x01\x02\x00\x00\x00\
I changed the code to use your new suggested startupmessage. There was no difference notable.
But to be honest, for me was already acceptable. On everage the control panel executes my commands in 5 seconds i think. Can you ellobarate a bit on the kind of delay you are facing?
@mattsaxon @plaksnor Thank you for reply’s 
I will try to get the cable and another RPi for now to see how it work. Btw, I really appreciate your work progress in this topic and wish you all the best 
Yeah sure! Ok, let’s assume we’ve no scripts running at all. Nothing is communicating with your alarm system.
- Start a putty session listening to /dev/hidraw0 (or whatever device you’re using)
sudo cat /dev/hidraw0 | hexdump -C
Results: Here, nothing is happening. I don’t receive any data at all yet.
- Now start a 2nd putty session and submit the default startup message I was using before:
echo -ne "\x00\x00\x01\x01" > /dev/hidraw0
Results: I do see a couple of lines, containing 51 22, which indicates the alarm is off. So far so good.
-
Now try to repeat step 2 every second, like you’re polling the alarm system.
In my case, nothing is happening. I only got a response from the 1st message and I don’t get any response on all other messages. -
Now try to repeat step 2, but every 10 seconds. This starts to work for me, but it’s far from ideal. You don’t want to a 10 seconds delay.
So in one of my last posts I discovered that I was able to send a different message, continiously:
echo -ne "\x80\x01\x01\x52\x01\x0E" > /dev/hidraw0
Even when I am sending it multiple times a second, it’s always responding, immediately, very fast and with smaller payloads. It even seems there’s no header in the package at all.
I’ve tried this one repeatedly, but it reacts the same way as \x00\x00\x01\x01: I still need to pause it about 10 seconds before sending the next message.
@Marcel1: I’d happy to decipher all of your packets, but I’m still unable to find the right payload to trigger all of the \x52\x09\x8a packets. It’s good to see though that your sensor packets start with the same bytes as mine.