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

Third party integrations
243

Been playing around some and tried to figure out some more of the 5508 packets
on JA-100 serie
Found that Panels and Application are using byte5-6 as ID
Seems like all Apps have the same ID (verified with 2 different users and phones)

byte3 seems to be which alarmstate you are sending from the panel/app (armed_away, armed_home, disarm)

byte4 is the remaining mystery, seems to be related to the user I get 6c from app and 6d from any
of my panels, wife get 70 from app and 71 from any panel

No idea what I can use the info to but maybe someone has an idea.

244

I’m confused a bit, are you talking just about 5508… strings? Do you have any specific examples of what do you mean?

Actually @Horsi and @plaksnor have some “documentation” in the code itself. :slight_smile:

245

Hey there,
I’ve installed this integration for JA-100 and use binary_sensor.py @davidzadrazil’s PR and alarm_control_panel from @hsk-dk’s fork. Thanks to both of you for your work.
However, I found out that @davidzadrazil’s _triggersensorupdate() makes all devices “off” on every call, which he states to be fix for PIRs (works for them), but I also have reed switches connected through JA-118M (8 channel reed switch bus “multiplexer”) in my windows and the fix makes me unable to tell if the windows are currently open or closed (I only get “on” state when the state of the respective window changes).
I found out that all of the JA-118M channels’ 4th bytes are always even. On opening the second lowest bit is 1 whereas on closing the second lowest bit is 0. My PIRs seem to report only on first detection of motion and their 4th byte is odd.
Does anyone sorted this problem out or do I need to find correct byte configurations and recode the thing on my own?

246

Just don’t use the @davidzadrazil pull request then. :thinking:

Modification for 0.103 from @mattsaxon and replacing the BinarySensorDevice for BinarySensorEntity in binary_sensor.py and AlarmControlPanel for AlarmControlPanelEntity in alarm_control_panel.py, should be enough to get it partially working. Then you probably need to watch the logs for “New unknown packet:…” for your sensors and add the missing packets to the line 398.

Or did i miss something from your post?

247

Thanks, I will try it, but i think that without the manual reset by @davidzadrazil my PIRs will get stuck in “on” state as they seem not to send any packet when there is not movement anymore (Do yours do?). And as you said I’ve got it to partialy work (all sensors recognized, added and triggered correctly, alarm control panel working), but I want to know whether my windows are closed or open not just if they were open/closed, I mean their actual current state not just state change.

248

@Nath sure, looking at the 5508 packets in JA-100 the current code only looks at sensors. But there is actually also available info showing interactions with Controlpanels and the MyJablatron app.

By looking at it I found that each panel has their own ID and in that sense the MyJablatron app acts as a controlpanel. Based on this I can see where an alarm was triggered. (byte5 and byte6)

Byte4 which usually shows on and off behaves a little bit different when it comes to the panels/app and seems to show which user has interacted with the panel/app.

Byte3 is giving away the state you are sending to the alarm (Armed_home, armed_away_ disarmed)

Based on this I can get info on who interacted with the alarm and how.

1 Like
249

ok, found a usecase, when my son disarm on weekend mornings, the tv will turn on his favorite channel :slight_smile:

250

Ok, get it now and it’s pretty interesting. I was aware of IDs for panels (and other) but didn’t know about apps (actually i stopped paying… :sweat_smile: )

@vbrenik I noticed in the issues section that somebody was interested in slightly “updated” @plaksnor’s code and there is a recent fork which apparently works. (everything i mentioned above) So you don’t need to do it on your own… :wink:

251

Hi All,

I’m running HA from Docker and I observe odd behavoir with the plugin for JA-100 series. If I reload docker container with HA then all is fine. However, if I restart HA from UI then my “alarm_control_panel.jablotron_alarm” entity becomes unavailable. Yet, “hidraw” device is still reachable from within container. And I can see all Jablotron sensor states and their changes. It’s just the control panel that stops responding.

Here’s relevant section of debug log. There one could see sensor event in between. But otherwise a non-responsive “52 01 02” message.

Did anyone face similar problem?

252

Noticed that @mattsaxon updated his code for j-80 but are the other code owners, @plaksnor and @Horsi not updating anymore for J-100?

253

Hello,
Thank for your work.
Alarm work well in my case with JA-100 ! :slight_smile:
I was wondering, is the trigger for opening/closing a gate or garage door provided for in the roadmap?

254

Not sure if it was covered well enough here. Few of my observations on Jablotorn behavior.

  • alarm can be disarmed from HA only if access code in the plugin matches user with the same or higher level of privileges as the one who armed the Alarm. I.e. you can’t disarm from HA using “User” code if the alarm was armed from panel using “Admin” code.
  • sensor states are not udpated in HA if you use “User” code. It only works with “Admin” or “Service” code.
255

Is there anyone who have sniffed the packages sent when arming/disarming from a controlpanel or application?
I wonder if the bytes i found are same for everyone or depending on the system.

I found byte3 to be
ae :“armed_home”
0c :“disarm”
2e :“armed_away”

256

Hi,
I have a OASIS 80 and i’m debugging with OLINK to improve the HA integration. I want to share some infos.

  • Sending
    \x02\x01\x8E
    \x02\x01\x8E
    (that means # #) can put the alarm into normal mode, exiting service mode or mantainance mode.
  • Sending
    \x02\x01\x8A
    will retreive lot of info about the sensor: this equals to press “Devices” on the Olink software while running in Service mode. Anyone can help me to decipher protocol? Goal is to check battery info on all sensor…
1 Like
257

Dont have the Oasis and O-Link but fun to see that more people still develop on this.
Is your fork available to look at?

258

Hi, I’ve tried to improve Jablotron100 integration: https://github.com/kukulich/home-assistant-jablotron100/

It’s based on https://github.com/plaksnor/HASS-JablotronSystem but rewritted from scratch:

  • It supports HA 0.112
  • It can be added by “New integration” button
  • It supports more sections - max 8
  • It tries to detect model and FW version of the alarm
  • It does not support sensors (they may be added in the future)
  • It does not support YAML configuration (no need for it)
  • It does not support MQTT alarm
1 Like
259

Nice work! Haven’t tried or looked but does your version support also binded sections? (one section “under” another one as a subsection?)

So it’s not armed by b0(for a0/90), b1(for a1/91), etc but it arms other sections/zones as a partially armed (armed_home) or all zones (armed_away)?

260

I don’t have binded sections at home so I cannot sniff packets for them. If you can sniff the packets we will see how complicated can the support be :slight_smile:

1 Like
261

Yes, i have few thousands of lines sniffed (i mean the useful ones…) :grin:

Well, basically it acts (i mean the communication) like a normal section it just needs one alarm panel in case of two or more physical sections (which probably will slightly mix up the code you use - i think it’ll need yaml). So let’s say you hit arm_away, it normaly sends a0 as to “fully” arm the main section and Jablotron do the rest (*you will see all sections are arming/armed/disarmed/pending in 5122*********07 packet), same as if you send 90 it disarm all section (b0 is not in use), on the other hand in case of arm_home, it should send a1/91 which dis/arms only the subsection (packet 5122*********07 reports only the one section armed).

What about triggered? I don’t know if anybody noticed it but @plaksnor’s code not only doesn’t have it but it also interrupts a siren after few seconds. (hadn’t time to find the culprit)

EDIT: I quickly looked into your code and don’t see the triggered bytes neither (i was wondering if it’s same code as mine :thinking:) FYI: In my case from armed 51220300*******07 => 51221b05*******07 (means it uses 1b05 accordingly to the sections position)

EDIT2: Sorry i have to correct myself*. In case of arming/pending/triggered the main section still reports as armed. Btw: bytes 21 and 23 in position of the section reports error, like a dead battery(disarmed 51222100*******07, armed 51222300*******07)

262

Binded sections: Ok, I’ll try to add support in the future. Do I understand correctly that when you partly arm (home/night) the main section, then the binded sections are armed fully (away) ?

What about triggered ?

I didn’t sniff any “triggered” bytes in my alarm…

bytes 21 and 23 in position of the section reports error

Interesting - I think i can add binary “problem” sensors.