Did you set the device 3 as keypad during installation?
Sorry, my bad, device 3 is the outdoor siren. And yes it was set as such.
Ok, it makes sense now. Will fix tomorrow.
Excellent. Thanks!
Fixed in latest master.
Much appreciated!
I managed to interface the Jablotron Oasis 80 alarm system to HA without the JA82T. The serial bus of the Jablotron 80, and I think also of the Jablotron 100, is an RS485 bus. I used an ESP8266 with Tasmota, a level shifter and an RS232 to RS485 interface (total cost less than € 10) as an MQTT bridge to get the raw status to HA and to send commands to the alarm system. It is still work in progress. I would like to decode more of the output from the system on the ESP8266 to prevent sending out he status 4 times per second over the Lan. That would also enable me to have better flow control when sending commands.
For now I have made a simple view of the status in HA, that also needs some refining.
1 Like
Hi plaksnor,
first of all, nice piece of work you guys put together. I am trying to understand what you are doing but I am not there yet 
I did connect my Jablotron 100 system to my Raspberry Pi and did the dmesg command. It gave me the result
4344.302347] hid-generic 0003:16D6:0008.0003: hiddev96,hidraw0: USB HID v1.11 Device [Jablotron ltd JA-100 Flexi] on usb-3f980000.usb-1.3/input0
maybe I am misunderstanding this part but when i check my /dev, I do not see a /dev/hidraw0:
by-id $ ls /dev/hidraw0
ls: /dev/hidraw0: No such file or directory
Am I doing something wrong over here?
Thanks. I will check it.
@kukulich The Jablotron-100 was installed earlier this week and I’ve activated your integration to my Home Assistant, running on a Raspberry PI, which is connected physically to the Jablotron central unit.
First of all, thanks for the integration and all work done on it !
Also special thanks to @mvieleers for the manual on how to set everything up, perfect for a new user like me 
I have two questions:
-
When switched to Service mode, the integration in Home Assistant loses connection and can’t recover (status of all entities becomes “unavailable”):
-
I have a magnetic lock (JA-150M) on two garage doors, but I can’t get the actual status of these locks. I’ve identified them as “door opening detector” when setting up the integration.
-
Within the Jablotron app, a few PG automations have been defined:
Would it also be possible to add these to the interface, so these can be triggered from within Home Assistant?
What could I do to resolve these issue?
Thanks in advance for your feedback and thanks again for the great integration!
I don’t know what means “cannot recover” but that’s a feature that entities are unavailable in service mode.
There’s a guide what to do in the repository README.
Hi,
as it seemed that existing Jablotron80 integrations are abandoned (and maybe a bit hacky) I created my own. It is first version and somewhat not extensively tested but should work.
See jablotron80
Br,
Erkka
As In mentioned earlier, I took a different approach and interfaced directly to the Jablotron bus. The solution is specific to the Jablotron 80. The hardware could be used for the Jablotron 100, but the script would need to be changed.
I made an MQTT bridge that can be connected directly to the Jablotron 80 bus, not using the JA-82T, which is essentially - I think - a USB to RS485 converter. The bridge I made consists of a Wemos D1 mini with the Tasmota software, a level converter and a TTL to RS485 converter. Total cost is about 10 euro and a bit of soldering. It can be powered by a 12v to 5V voltage converter directly from the 12V supply of the Jablotron 80 bus.
If you are not interested in controlling the Jablotron 80, but only wish to import the status, you can interface the D1 mini with only an optocoupler and two resistors.
The script I made publishes the following JSON via MQTT whenever the raw state changes:
In armed state
{
“zones”: “ABC”,
“alarm”: “Normal”,
“alert”: 0,
“device”: 0,
“msgid”: 4,
“raw”: “ED6304000F00000065”
}
In standby:
{
“zones”: “None”,
“alarm”: “Normal”,
“alert”: 0,
“device”: 0,
“msgid”: 0,
“raw”: “ED600000010000006F”
}
The script accepts two commands via MQTT:
Alarm 1 or 0 to set or unset the system
and
Service 1 or 0 to set the system to service mode or normal mode
1 Like
Hi,
I noticed your approach and it was one that I was thinking as well. But I already bought cable and it was not that expensive. One of the reason I published mine to git was to help you :)… I have done quite a lot of deciphering jablotron 80 messages (and documented it to code)…
I have separated reading input and processing it so it should be trivial to combine your work with this if you wish. I’m willing to help.
Br,
Erkka
Hi Erkka,
Main reason to take this approach was that the Jablotron system is downstairs and the HA server up in the attic. This way I can publish via MQTT using WiFi and I don’t need a separate cable to connectthe HA server to the alarm system.
Regards,
Frans
Hi Frans,
yes that obviously helps… I have usb over ip kind of solution for development but I have HA next to alarm system so it is not an issue for me. If you would like to integrate your hardware to my sw setup I would just implement jablotron serial parser on arduino and send only results (= segment) over mqtt (and maybe filter duplicate records following each other out). Same way you could set up input queue for command to alarm system… So basically just replacing JA82TConnection with mqtt send/receive would do it…
Br,
Erkka
I only need a very simple dashboard on HA to control the alarm system. Switch on/off and service mode on/off.
All other settings I manage with the Jablotron OLink software on my PC. That’s what I use the JA-82T for connected to the alarm system by a cable length of about 30 meters via three patch panels. It far exceeds the 10 meter max cable length of 10 meters that is specified for the JA-82T, but has never given any problems.
You have indeed put a lot of work in reverse engineering the Jablotron 80 protocol. I took the easy (lazy) way of emulating the keypad. The only somewhat complex part was getting the confirmation of the input. It turned out that if you do not get a confirmation within 1 second send again is an adequate way. Communication is nearly 100% successful that way.
I have two remarks on your code:
NAME_ID_MAPPING 3 imo is Zone ABC not C. Zone C is never activated on tis own.
MESSAGE_MAIN_TYPES 0xA0 is not just Beep. 0xA0 is an Acknowledge and continue input, 0xA1 is Acknowledge end of input and 0xA4 is a timeout on the input. See the annotated trace on the bus below of setting the system in service mode. The delimiter of 0xFF is never shown as it is stripped by the (modified) Tasmota software
16:27:36 MQT: stat/tasmota-aw/RESULT = {"SERVICE":1} -- Call to the script to set Service mode "*0mastercode" is the command to enter service mode
16:27:36 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED600000010000006F"} -- System in normal mode. Read from RS485, delimiter 0xFF is stripped off in this and all subsequent lines
16:27:36 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"8F"} -- "*" first char being send. This is not received from the system, but it is a local echo on the RS485 interface
16:27:36 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"A0"} -- Response from the system that input is accepted and it is awaiting the next input
16:27:36 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:36 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100001E62"}
16:27:36 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000A02"}
16:27:37 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:37 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:37 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"80"} -- "0" second char being send
16:27:37 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"A0"} -- second character accepted
16:27:37 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:37 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100001E62"}
16:27:37 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:38 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:38 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"8x"} -- first digit of master code being sent
16:27:38 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100001452"}
16:27:38 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"A0"} -- first digit of master code is accepted
16:27:38 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:38 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100001E62"}
16:27:38 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
6:27:39 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100001452"}
16:27:39 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"8x"} -- second digit of master code being sent
16:27:39 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100001E62"}
16:27:39 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:40 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:40 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:40 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"8x"} -- second digit of master code not accepted within 1 second so sent again
16:27:40 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"A0"} -- second digit of master code accepted awaiting further input
16:27:40 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:40 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100001E62"}
16:27:40 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100001452"}
16:27:41 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100001452"}
16:27:41 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:41 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"8x"} -- third digit of master code being sent
16:27:41 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100001452"}
16:27:41 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:42 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:42 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:42 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"8x"} -- third digit of master code not accepted within 1 second so sent again
16:27:42 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"A0"} -- third digit of master code accepted awaiting further input
16:27:42 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000032"}
16:27:42 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED60"}
16:27:42 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"04000100001E62"}
16:27:42 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100000A02"}
16:27:43 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED6004000100001452"}
16:27:43 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"8x"} -- fourth digit of master code being sent
16:27:43 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"A1"} -- fourth digit of master code accepted end of command
16:27:43 MQT: tele/tasmota-aw/RESULT = {"SerialReceived":"ED0001000100001449"} -- System in Service mode
Thanks. Yes my doings are not “complete” and many things are just documented in the code if I need them later on. I will check your findings. Btw have you figured out how is crc calculated? It is among next items in my todo list…