Sec2way to MQTT Gateway (Home Assistant Blueprint and Firmware)

This repository provides a Home Assistant automation blueprint that converts unencrypted (868 MHz) radio telegrams received via a serial JeeLink radio device into native Home Assistant devices using MQTT Discovery.

It also contains firmware binaries (and sources) for a compatible JeeLink (e.g. JeeLink v3), which must be flashed manually.

This project is not affiliated with or endorsed by any vendor. It has been tested with ABUS Secvest 2WAY sensors; it may also work with other devices that use the same on-air telegram format/behavior.

What you get

• Serial → MQTT pipeline (no custom HA integration required)
• MQTT Discovery: sensors appear as proper HA devices/entities
• A central Gateway device in Home Assistant
• Stable device identifiers (no duplicates after renaming)
• Offline detection via expire_after / last-seen timestamps
• Diagnostic entities (entity addresses and rssi)
• Uses only standard Home Assistant features:
  • Serial integration (text sensor) for JeeLink device
  • Automation blueprint
  • MQTT integration + broker

Note: The blueprint is designed for receive-only workflows and private interoperability use.

Sample entity of a sec2way sensor in MQTT:

---

Architecture overview

sec2way sensors (868 MHz), like door, fire and motion ↓
JeeLink radio stick(custom firmware)
↓
Home Assistant Serial integration (text sensor entity, receives JeeLink data)
↓
Sec2way Serial2MQTT blueprint
↓
MQTT broker + HA MQTT integration
↓
Home Assistant devices (Gateway + sensors)

---

Requirements

• Home Assistant with MQTT integration enabled
• A working MQTT broker
• A serial text sensor entity using JeeLink radio stick with custom FW

---

Install the blueprint

1. Use HA serial integration to integrate custom flashed JeeLink radio stick.

   # configuration.yaml
   sensor:
   - platform: serial
     serial_port: /dev/serial/by-id/<your-jeelink-usb-id>
     baudrate: 57600
     name: sec2way```
   
   After a restart, you should see a sensor entity (e.g. sec2way) updating with the received lines.
   E.g. 2W 01 208 102 16 4 -40 
   Format: <PROTO> <TYPE> <ADDR1> <ADDR2> <ADDR3> <STATE> <RSSI>
   

2. In Home Assistant go to:
   Settings → Automations & Scenes → Blueprints → Import Blueprint

3. Paste the URL to the blueprint YAML from this repo
   (Tip: use the file view in GitHub and copy the URL of the YAML file.)

4. Create an automation from the imported blueprint:

   • Select your serial text sensor entity e.g. sec2way
   • Save

After the first valid telegram, the Gateway device appears in MQTT integration automatically.

---

Using Discovery mode

1. Open the Gateway device in Home Assistant
2. Turn Discovery switch ON (default is on)
3. Trigger a few sensor telegrams (open/close contact, tamper, etc.) or just wait for the heartbeat (~4 min)
4. Devices/entities are created automatically
5. Turn Discovery OFF again to prevent accidental changes

This workflow keeps your entity list stable once everything is learned.

---

Firmware (JeeLink radio stick)

Firmware binaries and sources for the radio stick live in:

• firmware/

See firmware/README.md for:

• supported hardware
• flashing instructions
• expected serial output format
• release artifacts

---

Troubleshooting

No devices appear

• Confirm Home Assistant receives the serial lines in the Serial text sensor entity history/logbook.
• Ensure the line starts with the expected prefix (e.g. 2W 01 ...).
• Ensure MQTT broker + MQTT integration are working (check “Listen to a topic” in MQTT integration).

Duplicate devices / unstable IDs

• Use Discovery only for onboarding, then switch it off.
• The blueprint uses a canonical device id strategy to avoid duplicates when “heartbeat” frames use a related address.

RSSI issues

• RSSI is reported by the receiver (the radio stick), not by the sensor.
• RSSI varies strongly with antenna, USB position, walls/metal, and RF noise. It seems that their is still potential for improvements.

---

Security & legal notice

• This project processes unencrypted radio telegrams passively. Public analysis of this protocol family describes lack of encryption/authentication on the wireless layer. :contentReference[oaicite:0]{index=0}
• Intended for interoperability and private use.
• No proprietary keys, no vendor documentation, and no transmit/attack tooling are included.

Trademarks:

• Product and company names referenced here are the property of their respective owners.
• This project is independent and not endorsed by any trademark holder.

---

License Blueprint

MIT