Decoupling a KNX Alarm from the JUNG Panel in Home Assistant

The house came with a JUNG EAM4000 KNX alarm panel, and for years it owned the entire security story. It gated the motion detectors, it decided whether the place was armed, and it drove the sirens. When I started pulling the house into Home Assistant, the obvious move was to read the alarm out of that panel and call it done. I didn't do that, and this post is about why.

The naive way couples you to the panel

The tempting approach is to tap the panel's own outputs: wire its zone and sabotage objects into HA and read them as sensors. It works on day one. But then HA only ever knows what the panel decides to tell it. When the panel is disarmed, those zone outputs go quiet, so HA sees nothing either. Your automation logic now lives downstream of someone else's arming logic, and you've inherited a dependency you can't easily reason about or change.

I didn't want Home Assistant to be a slave to the JUNG panel. I wanted HA to be the thing that decides, and the panel to become, at most, a peer on the bus. So I inverted who owns the truth.

HA owns the state and exposes it back onto the bus

The core trick is almost embarrassingly simple once you see it. Instead of reading the alarm's status out of the panel, I made Home Assistant the owner of the alarm state and exposed it back onto the KNX bus. Two HA input_booleans — an 'armed/active' object and a 'ready to arm' object — get published to KNX group addresses as type binary via an expose: block in knx.yaml. The bus now reflects HA's truth, not the panel's.

# knx.yaml — HA OWNS the alarm state and pushes it back onto the bus
# (status + 'ready' are HA input_booleans exposed to KNX, not read from the panel)
expose:
  - type: "binary"
    entity_id: "input_boolean.knx_ha_alarm_status"
    address: "x/1/10"   # HA-owned 'armed' object on the bus (real GA masked)
  - type: "binary"
    entity_id: "input_boolean.knx_ha_alarm_bereit"
    address: "x/1/11"   # HA-computed 'ready to arm'

Note these exposed objects deliberately omit sync_state — HA is the writer here, it's allowed to push. The addresses use the normal 3-level KNX form; I've masked the leading group because this is a security topic and the real map stays private.

Read presence off the light address, not the alarm zone

Here's the detail I'm genuinely happy about. The motion detectors already fire a light telegram to switch corridor and stair lighting, and they send it regardless of whether the alarm is armed. So I read each detector into HA through its light group address, not through the panel's alarm zone — a plain binary_sensor with device_class: motion pointed at the light status object. The payoff: HA sees presence even when the alarm is fully disarmed — exactly the information the panel would have hidden from me. There are seven JUNG 3361-1 detectors across the property, and I split them into a five-detector cellar set for a 'night' mode and the full seven-detector set for 'away'.

Every one of those read-only sensors sets sync_state: false — window contacts, motion detectors, tamper. That stops HA from issuing GroupValueRead requests or writing back, so on those objects HA is a passive listener and can't disturb the alarm's own bus traffic. The exposed alarm objects above deliberately omit it, because there HA is the writer.

'Ready to arm' is computed in HA, and arming is gated on HA's flag

The readiness lamp ('Bereit') isn't the panel's calculation anymore — it's mine. Window and opening contacts are modelled as binary_sensor with device_class: window straight off their KNX status objects, and the garage gets its own device_class: garage_door sensor. Two automations watch floor-level window groups for the ground and upper floors, and only when every window on both floors reports closed do they flip the exposed 'ready' boolean on. That computed readiness is then pushed back to KNX so the lamp on the bus shows HA's answer.

Arming converges on one source of truth. Two 'sync' automations keep a physical KNX wall switch and input_boolean.knx_ha_alarm_status in lock-step in both directions, so arming from the wall and arming from the app land on the same flag. And every escalation is gated on that flag: a window or door open triggers the automation, but nothing escalates unless HA's own armed flag is set. The JUNG panel is no longer in that decision.

# Every escalation is gated on HA's own armed flag, not the JUNG panel:
conditions:
  - condition: state
    entity_id: input_boolean.knx_ha_alarm_status
    state: 'on'
triggers:
  - trigger: state
    from: 'off'
    to: 'on'
    for:
      seconds: 5   # debounce a bouncing reed contact

That for: seconds: 5 is intentional anti-bounce — a flickering reed contact has to hold open for five seconds before it counts. On a real trigger HA writes the offending opening plus a timestamp into an input_text helper, logs it to the logbook, raises a persistent notification, sends a critical-priority push to the household phones (sound critical, volume 1.0, so it punches through iOS focus mode), and turns on a local buzzer plus lighting in a set of areas. The buzzer auto-deactivates five seconds after the armed boolean goes off again. All of it is orchestrated in HA, independent of the panel.

The safety net, and the honest trade-off

Before any of the HA work, I did one thing in ETS: I stripped the siren, flash and transmission group addresses out of the JUNG central unit. The point was that even if the panel mis-fired during the rewire, nothing would physically sound. HA becomes the only thing that can raise an alarm. (Editing the central unit needs JUNG's vendor ETS plug-in on Windows with a KNX/IP gateway — you can't reconfigure it from generic ETS.)

One real gotcha along the way: some detectors were still brightness-gated in ETS ('helligkeitsabhängig'), so they only sent their movement telegram in the dark. Reading presence off the light address means you have to reprogram those to send brightness-independently, or they show up dead in HA. A few of mine did exactly that until I caught it.

The honest trade-off: I gave up the panel's certified, tamper-monitored signal path for flexibility. The tamper contacts still exist — they're mapped as device_class: tamper sensors — but I'm no longer routing security through the panel's coupling. If you need a monitored, insurance-grade alarm path, that certified panel still has a real job. For a house where I want HA to actually own the logic, inverting ownership and listening passively on the bus was the cleaner build. If you're following the series, this leans on the same KNX foundation as the earlier HACS and Docker posts.