v3.0.0

🚨 Blitzer.de 3.0.0 — now with traffic hazards

🚧 Traffic hazards are reported too. Tailbacks, accidents, roadworks, obstacles, broken-down vehicles, road blocks and police bulletins — ten types under Hazards / Gefahren, each tickable on its own and all off until you switch them on. They get their own map source, their own update interval and their own count sensor: a tailback is stale within a minute, a permanent roadwork is still there next week.

🔍 Seventeen control kinds, instead of four categories that hid them. A tunnel camera, both halves of a section control, a weight check, a dummy and a plain speed camera were all "fixed" — 98 of 127 in the test data. How a control is installed and what it measures are now two separate axes, Controls / Kontrollen and Control types / Kontrollarten, so "only section controls" is something you can actually ask for.

📝 Every report prints in one line. summary reads Stauende · 2.3 km · 34 km/h · +3 min · A100, Berlin, so a card or a notification uses one field instead of six. Alongside it: kind, type_name, created, confirmed, info, and a tailback's speed and delay computed the way blitzer.de's own map computes them.

🔔 A blueprint, "Report Alerts". A live alert for every newly reported control or hazard, inside a time window you set — plus a digest of everything currently reported, at a time of day, when you leave a zone, or on demand. One set of filters, one set of channels: mobile push, the notification bell, a dashboard helper, text-to-speech, and your own actions.

🗄️ Archive data / Archivdaten on request. Blitzer.de's own record of enforcement that used to be there. Off by default and labelled archive, so it can never be read as something standing there today.

🧭 The setup form got shorter. The three switch groups are single lists now: seventeen control kinds take 700 px instead of 1300. The count sensors follow your Home Assistant language — Control count / Anzahl Kontrollen — instead of being German for everyone.

🐛 Five fixes. A third of all controls showed the wrong symbol; the map picks by what the control is, not by category and speed limit. A single camera near Sankt Michael im Lungau could take a whole entry down, because its info arrived as an empty list. Also: six cameras wrongly reported as trailers, a duplicate area name slipping through, and an entry with no control type sending a malformed request.

⚠️ Breaking. "Blitzer" is Controls / Kontrollen throughout. blitzer.refresh → blitzer.refresh_controls and its response key cameras → controls; the event blitzer_new_camera → blitzer_new_control; a map source now names its half (blitzer_berlin_controls). Every entry becomes a device, so entity ids lose the "Blitzer.de" prefix — the count sensors are migrated and keep their history. type no longer reports redlight; read kind instead.

📖 Full changelog

v2.1.1

Fixed

• The searched area was not the circle you drew on the map. A radius in meters was turned into a degree offset by dividing by 100000 and applying the result to latitude and longitude alike. A degree of latitude is 111320m, not 100000m, and a degree of longitude is shorter still - by the cosine of the latitude. The queried box therefore came out 11% too tall and, at German latitudes, 24-35% too narrow: with a 5km radius near Cologne the search reached only 3.5km east and west, while pulling in cameras almost 6.2km to the north. Nothing filters by distance afterwards, so both the misses and the strays went straight into the entity list. Measured against the live API for a 5km radius, this now finds cameras that were inside the radius all along - five more in Hamburg, one more in Cologne - and stops reporting the ones that were never in it. Route entries benefit the same way, since the corridor width is a radius around each sample point.
• Resolving a cluster asked for the wrong cameras. When the API answers with a cluster rather than individual cameras, the integration zooms in and queries that spot again - but without passing on which camera types the entry actually wants, so it fell back to a default that was itself malformed: [TYPE_TRAILER + TYPE_MOBILE] nests a list inside a list, which reaches the URL as the literal text [ts, 0, 1, ...] instead of ts,0,1,.... The API answers that with 200 and a shorter list rather than an error, so the loss was silent - the same box returned 2 cameras instead of 5 in a Berlin test. The types are now threaded through, and the default is built inside the function.
• A second area with the same name came up empty. Every entity an entry creates is identified by that entry’s name, so two entries called the same thing produced identical identifiers and Home Assistant dropped the ones it could not tell apart – the new area appeared with no cameras and no sensor, explained only by a line in the log. The name is now claimed when it is typed, so a duplicate is refused right there with “already configured” instead of failing quietly several screens later.
• Every area logged under the same name. Entries carried no identifier of their own, so each one’s coordinator wrote its messages as blitzer (None) and there was no telling which area a message came from. New entries use the name they were set up under; existing ones fall back to it.

v2.1.0

Added

• blitzer_new_camera event: fired once per camera that's genuinely new - never for one already known from an earlier poll, and never during the very first fetch right after Home Assistant starts (that's just "here's what's already there", not a new detection). Includes config_entry_id, area, id, type, vmax, street, city, zip_code, latitude, and longitude. Lets an automation react directly to a newly reported camera anywhere in the configured area/route, without needing a matching Home Assistant zone. See the README's updated "Notify when a new camera is reported" section (event-based vs. zone-based approaches).

Fixed

• README images and License link not rendering in HACS: every <img> and the License badge's link both used a repo-relative path (e.g. docs/map-card-example.png, LICENSE), which GitHub's own viewer resolves but HACS's README renderer does not. Switched to absolute raw.githubusercontent.com/github.com URLs.

v2.0.0

Added

• Configurable polling interval ("Update interval", in minutes) for every area/route, replacing the previous fixed 60-second interval. Defaults to 1 minute (unchanged behavior); setting it to 0 disables automatic polling entirely for that entry.
• blitzer.refresh action ("Blitzer Refresh"), for on-demand polling - most useful for entries with a manual-only (0) update interval, e.g. triggered from an automation, but works for any entry. Immediately fetches the latest cameras, updates that entry's geo_location entities exactly like a normal poll, and returns the cameras found so an automation can use them directly (e.g. in a notification) without a separate template step. See the README's new "On-demand refresh for a commute" example.

Changed

• When update interval is 0, entities start empty instead of the integration making an API call on every Home Assistant startup/reload - the whole point of manual-only mode is avoiding automatic requests.

See CHANGELOG.md for the full history.

v1.6.1

Added

• Each camera's geo_location entity now sets a proper MDI icon per type (mdi:cctv fixed, mdi:speedometer mobile, mdi:truck-trailer trailer, mdi:traffic-light red light), matching the sibling lufop_radar integration. The map card still shows the existing Blitzer.de speed-sign picture, but the icon now shows correctly wherever entity_picture isn't used (entity list, history, more-info dialog).

See CHANGELOG.md for full details.

v1.6.0

Added

• New Route (waypoints) search mode, alongside the existing area/radius search. Choose "Suchart" when adding an entry: draw a route as a chain of map-based waypoints (one screen per point, same drag-the-map interaction as the radius picker) and set a corridor width; cameras are searched along straight-line segments between waypoints without any external routing engine, by sampling and querying points spaced one corridor-width apart and deduplicating the merged results by camera id. A route's geo_location entities report distance to the nearest waypoint rather than a single area center.
• A route's waypoints have no upper limit, and editing a route via Configure now offers a choice up front: step through each already-saved waypoint to reposition or remove it (then append further new ones), or jump straight to the corridor width / camera types / optional settings without touching the waypoints at all — it no longer discards and redraws the whole route from scratch, and no longer forces you through every waypoint just to change an unrelated setting.
• Multi-step forms (waypoint entry/review, the search-mode picker) now show a "Next" button instead of the generic submit label, since more steps always follow.

Changed

• Breaking: The whitelist option is now a comma-separated list of city names (same syntax as the blacklist, e.g. Berlin,Potsdam), matched case-insensitively, instead of a regex pattern. Existing entries still using the old default (.*) keep working unchanged (treated as "no filter"); anyone who configured an actual regex needs to replace it with a plain city list via Configure.

Fixed

• Adding a new area or route showed a completely blank form on the second step: the location/map selector field had no explicit default, which the frontend can only tolerate on a flow's very first step (Selector location not supported in initial form data). Every location field on a later step now gets an explicit default.
• Adding waypoints to a route silently stopped being possible after the 3rd one for anyone who didn't notice the "Add another waypoint" checkbox had defaulted to unchecked once the 2-waypoint minimum was reached; it now always defaults to checked.
• Clearing the whitelist or blacklist field back to empty didn't stick: the frontend strips an empty optional text field from the submitted data entirely, so the schema silently re-applied its default (the previously saved value) instead of actually saving empty. Both fields now use description={"suggested_value": ...} to pre-fill the current value instead of a hard schema default=, which is not re-applied on submit — and unlike making the fields Required, still allows submitting them empty in the first place. The whitelist field also no longer keeps displaying the legacy .* value on existing entries — it's now shown (and treated) as empty, matching what it actually means.

Full Changelog: https://github.com/somansch/blitzer/blob/main/CHANGELOG.md#v160

v1.5.0

See CHANGELOG.md for full details.

Added

• New Rotlichtampel/Red light type option, independent of Feste/Fixed.
• Example markdown card now sorts cameras by distance, closest first.

Changed

• Options layout: "Nur bestätigte Blitzer anzeigen" moved to the top of optional settings; whitelist field relabelled for clarity.
• Extended disclaimer with specifics on the reverse-engineered atudo.net API.

v1.4.0

See CHANGELOG.md for full details.

Added

• Per-area geo_location source (blitzer_<area>) so the map card can show a single configured area instead of all combined.
• type (mobile/trailer/fixed/redlight) and id attributes on every camera entity.
• New Blacklist config option to exclude specific camera IDs alongside the existing whitelist regex.

Fixed

• Inconsistent spacing in the example markdown card.

v1.3.0

See CHANGELOG.md for full details.

Fixed

• Setup crashed with a KeyError when enabling fixed cameras, since they lack a confirmed field.
• Red light cameras got a broken icon URL instead of the correct redlight SVG.
• Cameras that disappear are now purged from the entity registry immediately instead of via a delayed task, closing the window where they could show up as unavailable ghosts.

v1.2.0

Fixed

• geo_location distance is now computed from the configured area's center point instead of the Home Assistant home zone.
• Options flow: the location selector now correctly pre-fills with the area's saved coordinates/radius instead of resetting to the home zone.
• The sensor count (Anzahl der Sensoren) can now be changed after initial setup via the options flow; previously it was locked in permanently.

Added

• Local brand icon, served via the brands proxy API (HA 2026.3+) so the integration shows a proper icon instead of a placeholder.
• README now documents every config flow / options field.