bvis/aegis-hass

Four action blocks are present in every language file but still hold their English text. The keys are all there — a test now enforces that — so this is purely about the values, and it is the kind of thing a native speaker fixes in two minutes and a maintainer guesses badly. Status (updated 2026-09-09). Done: it (wip3out3r, #477), nl (aavdberg, #483 + #484), es (#485), uk — which already carried all 26 values in Cyrillic — and da, a whole new language contributed by webliodk in #488 with exact key parity. de, fr, pt, pt-BR and ca are in #493, translated by the maintainer from each file's existing vocabulary (see the status comment below for why, and what still needs a native eye there). Four languages left, each needing a native speaker: cs, pl, ro, tr. #493 also localises the press_panic_button field names (Entity / Latitude / Longitude), a fifth gap that was still English in 13 of 14 locales. Affected in 12 of the 13 non-English languages (es already has them): Correction: es

Six MotionCam families the integration already knows get no camera entity, and four of them have phod in their own device-type name yet get no photo-on-demand button. This became visible while reviewing #469 (PR-3 of #332), which moved camera and PhOD detection into the handler registry and preserved the previous behaviour exactly, as a refactor should. The registry knows 139 device families. The ones that get a camera entity are these six: motion_cam, motion_cam_outdoor, motion_cam_fibra, motion_cam_phod, motion_cam_outdoor_phod, motion_cam_fibra_base and the last three of those are also the only ones that get a capture button. The MotionCam families that get neither: motion_cam_g3 motion_cam_hd motion_cam_phod_fibra motion_cam_outdoor_two_four_phod motion_cam_s_phod motion_cam_s_phod_am They do get their motion, tamper and delay sensors — they are fully modelled detectors — so what is missing is the camera entity that shows the last capture, and for the four phod ones the butto

Description Hi, First of all, thank you for this great integration! I'm using an Ajax MultiTransmitter with several wired magnetic contacts. Each wire input is correctly discovered as a device, but Home Assistant only exposes the following entity: binary_sensor._wire_input_alert This entity only represents the alarm state (device_class: safety). What is currently missing is the actual contact state (open / closed). For example, in the official Ajax app and in other integrations (such as the Jeedom Ajax plugin), it is possible to know whether the wired contact is currently open or closed, independently from the alarm state. This would be very useful for: Door and gate status Garage door status Home Assistant automations Dashboard cards From the diagnostics, the wire input currently exposes: { "type": "wire_input_mt", "state": "online", "online": true, "statuses": [ "armed_in_night_mode" ] } ### Use case This would be very useful for: - Door and gate status - Garage d

Description Add the ability to view active Ajax account sessions and terminate (drop) them from within the Home Assistant integration, mirroring what the official Ajax mobile app already offers ("Active sessions" → log out a device). Ideally: A way to list the current account's active sessions with their key attributes (device model, OS, app label, last-connection IP, creation/refresh time, active flag). A way to drop/terminate a specific session (and/or "log out all other sessions"). Possible HA surface: a diagnostic sensor whose attributes list the sessions, plus a service (or per-session button) to drop a session by session_id. Use case This directly helps diagnose and fix the most common real-time-push problem with this integration. Ajax does not reliably deliver one account's FCM push to two active sessions at once, so a second session (phone app, desktop/web app, another HA instance) silently starves Home Assistant's push channel — fcm_connected shows 1/1 but pushes_receive

Context Since 1.10.0, SpaceControl keyfobs surface as a single Keyfobs device with one experimental per-keyfob Active binary sensor (diagnostic). Who armed/disarmed via a keyfob is already attributed in the logbook independently of this sensor. What's unconfirmed The active / inactive value of that sensor is experimental and not yet validated. On every install that produces the sensor, every keyfob reports as active — and a keyfob can only be deactivated server-side by an installer or monitoring company. So there has never been an inactive example to validate the indicator against; it may not correctly reflect a genuinely deactivated keyfob. Two corrections to this issue's original wording, both from @wip3out3r's measurements — worth reading before spending time on it: Neither of the Ajax app's two deactivation entries is the toggle this issue needs, and there is no third. Permanent deactivation (English docs) and Disattivazione forzata (Italian docs) are Ajax's two names for one