That functionality is not supported with the code as it standard at the moment. Can I check I understand the functionality you want… So whilst you can arm it from the physical keypad without a code, you want it to need the code when doing it via HA? What about disarm, I presume you need to enter the code via both HA and keypad at the moment?
@mattsaxon I have an physical keyboard on which I need to enter the code for arming/disarming - no other option without code. I am also using stock Jablotron rf remote now for arming/arming home/disarm but thats not important.
What I am looking for is to use only HA to arm/armhome/disarm (eventually arm_night too) but with only code entered on HA alarm card. Right now I am able to do it without code. The idea is that everybody in my household have different code therefore if they will use they own code I will know it and I will receive notification who is actually controlling the alarm.
After watching this thread with interest for a while, I today decided to join the club. Only problem is that my HASS is running on a virtual server in the garage while the Jablotron (Oasis-80) alarm system is installed in the attic. So I installed a RPI with ser2net next to the alarm control panel and connected the JA-82T Serial2USB to it. Using Ser2Net I’d like to forward this to the HASS (or to a windows machine to use OLink software if needed).
The device turns up as /dev/hidraw0 but unfortunately I don’t know with what settings it should be configured in /etc/ser2net.conf:
9999:raw:600:/dev/hidraw0:9600 8DATABITS NONE 1STOPBIT
For now I’m testing to use it as virtual COM port on a Windows-10 machine using Perle TruePort (based on this thread: https://t0ny.name/2018/02/1424. Unfortunately, that doesn’t work. Also using Socat on another linux box, doesn’t get a working connection…
Can anyone help in deciding what parameters one should use? eg Baud-rate, Databits, Stopbit, Parity?
Edit: from dmesg:
[ 3.433212] usb 1-1.3: New USB device found, idVendor=16d6, idProduct=0007, bcdDevice= 1.00
[ 3.448484] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.459393] usb 1-1.3: Product: JA-82T PC Interface
[ 3.467742] usb 1-1.3: Manufacturer: JABLOTRON ALARMS
[ 3.476200] usb 1-1.3: SerialNumber: 00000000
[ 3.525533] hid-generic 0003:16D6:0007.0001: hiddev96,hidraw0: USB HID v1.11 Device [JABLOTRON ALARMS JA-82T PC Interface] on usb-20980000.usb-1.3/input0
(by the way I have this working to send a Z-Wave stick from raspi over the network to hass)
1 Like
Hi. I can just confirm that I am also interested if someone could advise on this.
Right now I am using the raspberry with second Hassio and Jablotron setup as per this thread which works 
I am forwarding the alarm through the homekit in HA to my old iPad which acts like my home wall control panel. This setup works but I don’t want to use two HA servers. My VM HA server is much more reliable, quick and safe with snapshots than HA on RPi server.
Hi all.
I haven’t been very active here lately, but I just released fixes and new features for JA-100 series owners. Both the alarm control panel and binary sensors work pretty stable here. Not confirmed by others yet, so I’d like to read your comments!
Please read the readme to see how it works and what to expect.
I’d suggest trying these. I don’t know for certain, but this seems to be a common setup and I haven’t needed to change from default in the code we’ve written here.
Baud rate : 9600
Data bits : 8
Stop bits : 1
Parity : None
Flow control : None
Okay I think I got that part working. Using ser2net and socat on the other end didn’t work - as maybe the devide isn’t seen as serial? In the end I ended up on using the usbip package - which was fine on the raspberry but needed some tweaking on the other end (ubuntu LXC container within Proxmox). For reference: you should in that case use the debian package of usbip.
Now, after adding the /dev/hidraw0 device to the lxc container, I can see it within the home-assistant installation. I loaded up Plaksnor’s latest custom_component and I’m seeing the alarm panel, but it can’t detect the system or any of its sensors. Would love to see more debug info to know where to look. Could I for example test communication with the central (Oasis-80) somehow?
I’m on a mobile at the moment so can’t give a very comprehensive reply, but if you’ve got connectivity, just using the ‘echo’ command to start the stream and the ‘cat’ command to view the stream that this thread has on it earlier would be a good start. (My post of May 8)
Well, there is definately coming data from the device:
I can also see the alarm panel in home assistant but it doesn’t seem to work nor do any of the sensors appear. Could it have to do with difference of 80 vs 100 system?
I don’t think this is the difference between 80 and 100 series. I have an 80 series. My dump is vastly different.
As you can see my dump is broken into packets of 64 bytes and all start x82.
Not sure what is causing this; could be a different model, but more likely remote usb tool is changing this
Yeah thought the same so tried to repeat the dump locally on the raspberry pi. Without luck, now hexdump /dev/hidraw0 doesn’t return anything, even after (in another console) issueing echo -ne “\x00\x00\x01\x01” > /dev/hidraw0.
Guess I need some other trick to initiate data…
The way I tested communication with the central: I captured the log while running J/F-link and I tried to analyze its behaviour. I noticed there were a lot 55 01 02 packets sent exactly every second. So I reproduced this interaction in python. So with an interval of 1 second I do get a lot of response back of the alarm system (states of alarm). It’s like there was some kind of conversation going on.
Then there was something else. Like you logon with J/F-link to your central, you somehow also need to authenticate. So there’s another sequence of data you need the central to send you. I decided to echo all kinds of messages to the central until I noticed there were other kind of 55 09 packets send back when triggering a sensor. These 55 09 packets were only getting sent after submitting this authentication/activation code.
As you can see here:
This log is containing the 520102 packets every second.
This los is also containing two lines which were relevant for the 100-series:
8008033939393x3x3x3x (authentication code, containing your alarm code used to login. I marked the code red.)
520213059a (some kind of request for 55 09 packets, which sents even more quicker sensor states)
At this moment, there’s still an investigation going on why not every one is getting these 55 09 packets when using the 100-series.
However, my point is: if you are able to see which data is being sent, then you should be able to reproduce the same packets in order to get a similar behaviour. And keep this in mind: your system is not broadcasting data unless you ask for it. The question is: which packets do I need to send to get the right answer back?
And if you have already some kind of dialog with the central in a log file, you should be able to reproduce that same dialog by asking the same questions (sending the same packets).
I hope this does make any sense to anyone who’s trying to analyze its data.
The Jablotron data (for at least the JA-100 series) consists of two important type of packets which are getting send by the alarm system: packets starting with d8 08 and packets containing 55 09:
The packets starting with d8 08 seem to be some kind of status report.
These packets contain information about which devices are ON and information of the sensor which has been turned ON or OFF recently.
For example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 <====================== byte number
d8 08 00 00 00 00 00 00 00 00 00 10 14 55 00 10 |.............U..| : nothing is activated
d8 08 00 00 01 00 00 00 00 00 55 09 00 88 00 02 |..........U.....| : one or multiple devices has been activated
Byte number:
- 4 and 5 = accumulated sensor ID’s of devices which are ON. They together contain a list of devices which are ON (or open or triggered). Example: If they contain the value 60 00, they exist of two devices: 20 00 and 40 00: together 60 00.
- 11 and 12 = if 55 09, a specific sensor recently caused this d8 packet
- 14 = specific on/off status of a sensor which has changed state. Values for ON are 6d 75 79 7d 80 and 88 (for what has been analized so far)
- 15 and 16 = specific sensor ID of sensor which has changed state
The packets starting with 55 09 also seem to contain sensor data, but they are only getting send as some kind of follow up. These packets contain on/off data for only 1 sensor, not multiple.
For example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 <====================== byte number
55 09 00 8a 00 02 40 cc d2 3b 13 00 0b 00 00 00 |U.....@..;......| : sensor 00 02 became inactive (8a)
55 09 00 80 80 01 60 cc f2 3b 14 00 14 55 00 10 |U.....`..;...U..| : sensor 80 01 became active (80)
Byte number:
- 4 = status (on/off) of device which has changed state. Values for ON are 6d 75 79 7d 80 and 88 (for what has been analized so far)
- 5 and 6 = specific sensor ID of sensor which has changed state
Here you’ll see an example of an incoming d8 08 packet while triggering a PIR motion sensor.
Byte 4 and 5 = 20 00 = device 6 (5th position in table below) is the only device which is on.
Byte 15 and 16 = 40 01, which also represents device 6, but now as the latest device which has been going on (or off).
This is my analysis for the data coming out of my system with code in the JablotronSystem repo, but I’m not sure how generic this is for all of us.
I finally found the time to look at the sensor data stream from Series 80 devices.
Here is my analysis;
- Sensor data is visible in packets beginning x8203, x8204, x8205, x8206, x8207, x8208: x8207 is the most frequent packet, so probably best to scan for
- ID is the 5 & 6th byte; 5th byte = sensor Id, 6th byte is 01 (though is 00 for x8203 packets)
- Status is the 4th byte; 06 = motion, 07 = tamper, 3rd byte is always 00 (useful for pattern matching as there is some spurious data - or some I haven’t fully worked out!)
So my plan to to write the sensors to spot the packets beginning 0782 0600 01, the next byte will be the sensor id.
Note: these were created when the system was in Service Mode, I’ve since noted the pattern is different in normal mode. Ill post further results soon.
Not good news on this. When in unset mode, it appears that there is no movement sensor data in the serial stream. I can see some tamper data, but it is not as clear as my analysis on the previous post. The lack of movement data means that sensors would not be functional for my use case and so I won’t be enhancing the Jablotron 80 code at this stage.
What do you mean with Service mode? The situation when you are logged in with J/F-link? And does your alarm system also work different then?
Marcel and I also noticed the system is automatically sending more data when you’re logged in with J/F-link. So in one of my latest releases I simulated that ‘service mode’ as far as I recognize this as a service mode.
So probably you need to go into service mode first, analyze all send packets. Then try to recreate these, so you get yourself sent data more frequently and also when a sensor is being triggered.
So first of all: do you also see a packet which is being sent every second?
And second: are you able to see some kind of authentication packet (containing your alarm code), followed by some other packets which are not being sent regularly? If so, try to submit all of them and see if you get more data than normally is being sent.
By the way, I’m using the alarm code of an account which is an Administrator (not a normal user or service user).
Service Mode is achieved on a 80 series by using the service code at the keypad (or OLink). It is the mode that is used when adding devices for example. When in this mode, the key pad reports sensor data. I don’t think the majority of what you and Marcel have discovered applies to the 80 series. There is no more data when logged in via OLink. OLink appears to simply simulate the 80 series keypad.
As a result of this divergence, the systems appear to me to behave differently and I think we should split the codebase. I still think there is value in keeping this thread going as we are tackling similar problems, but the code will be very different.
I’ve validated that the sensor codes are in the stream when either in Service Mode or Maintenance Mode, but neither in Set nor Unset modes.
I’m wondering to myself if it would be safe to have the device in this mode when at home. One issue I can think of is that smoke/heat alarms will not trigger whilst in either of these modes. Panic alarms probably also would not trigger.
These concerns might apply to the 100 series too since you are effectively logged onto the device in these modes. Have you tested this?
Matt,
that’s unfortunate but might explain why I wasn’t seeing any data as I wasn’t in service mode.
Another miss in that mode is that the alarm is effectively inactive, where you’d have to reproduce everything from home assistant, including the sms notifications and voice messages on an alarm.
But in your post from april 28th you suggested that some functionality such as arming etc. did work - or was that with the 100-system? I don’t think you can arm the system while in service mode?
My post of today is just relevant for 80 series devices wrt sensor data. Arming & disarming and status works very well… for me at least!
It seems to me that there is lots of confusion on this thread (for me at least) for specific issues and I propose that for issues (as opposed to general discussion) that we move to the relevant GitHub repo. This will allow multiple threads to be discussed without mixing them up.