v2.1.2

Fixed

• An area with no radars in it looked like an outage. Lufop answers “nothing in range” with a bare null rather than an empty list, and that was read as a broken response: the poll failed and every entity of that entry went unavailable, with Lufop API returned an error: None in the log. Route entries felt it worst – a route queries one narrow corridor per sample point, and most stretches of road legitimately hold no radar at all, so a single empty one failed the whole poll. An empty answer is now simply an empty result.
• The narrowest corridor searched nothing at all. A radius is converted into Lufop’s own search margin, one unit per 100m, and the result was rounded to the nearest whole unit. The smallest corridor width the form accepts, 50m, lands exactly on half a unit, which Python rounds to zero – so the tightest search anyone could ask for was the one that asked for no margin. Every other value rounded to nearest as well, meaning half of them quietly searched less ground than requested. The margin is now rounded up and never smaller than one unit.
• 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 radars 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 lufop_radar (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

• lufop_radar_new_radar event: fired once per radar 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, speed, street, city, country, latitude, and longitude. Lets an automation react directly to a newly reported radar anywhere in the configured area/route, without needing a matching Home Assistant zone. See the README's new "Automations" 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, quota-derived interval. Defaults to 10 minutes for an area; for a route, to the route's sample-point count × 8 minutes (shown to you, recalculated live if you adjust the corridor width). Setting it to 0 disables automatic polling entirely for that entry.
• lufop_radar.refresh action ("Lufop 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 radars, updates that entry's geo_location entities exactly like a normal poll, and returns the radars found so an automation can use them directly (e.g. in a notification) without a separate template step. See the README's new automation example.
• The route wizard's corridor-width step is now separate from the rest of the route's settings, so the following step can show an accurate, live "N sample points / requests per poll at this corridor width" explanation and a matching suggested update interval. An "Adjust corridor width instead of saving" option loops back to revise it without redrawing the whole route.

Changed

• Entries created before the update-interval option existed keep their previous (quota-safe, ~10 min × requests-per-poll) polling behavior until next saved via Configure, rather than silently switching to the new default.
• 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.
• The total-count sensor's name no longer has a stray German word ("Anzahl") left over from an earlier translation pass.

See CHANGELOG.md for the full history.

v1.2.2

Second round of live-testing fixes, plus entity display and dashboard polish, from configuring real Strasbourg and Paris test areas.

Added

• README now includes a "Dashboard Examples" section with screenshots and the actual map/markdown card configuration used for them, matching the sibling blitzer integration's README structure.

Changed

• README now states explicitly that only the free plan's country coverage (France, Belgium, Switzerland) has been tested, and all examples use French/Belgian/Swiss cities instead of German ones.
• Entity friendly names now use the radar's city and street instead of Lufop's raw radar name.
• Every radar now gets a generated round road-sign picture as its entity_picture - the speed limit for speed cameras, a traffic-light emoji for red-light cameras - rendered both by the entity itself and by the map card's marker. The map card previously showed no usable icon at all for geo_location markers, falling back to text initials of the entity name.
• The flash_direction attribute now reports readable front/back/both instead of Lufop's raw F/B/D codes.

Removed

• "Covoiturage" (carpool/HOV-lane) cameras with no speed limit are now dropped entirely instead of showing up as unlabelled fixed cameras. These check lane occupancy, not speed, and always report an empty "vitesse" by design - not useful for a speed-camera integration.

Fixed

• "Chantier" radars (mobile radar units deployed in roadwork zones - Lufop's own term, not the roadwork itself) were being misclassified as fixed cameras. Some countries, notably France, have no separate "Mobile" listing at all and report these mobile deployments only as "Chantier", so this was silently miscategorizing real mobile-radar data. "Chantier" now counts as "mobile".

See CHANGELOG.md for full details.

v1.2.1

First release verified against the real Lufop API with a live key. Several issues below only surfaced once real data and a real account's limits came into play.

Fixed

• The country selector's option order was only actually alphabetical in English - German and French showed the same (English-sorted) order underneath correctly-translated labels. Each language now has its own sorted option order.
• Polling now respects the Lufop free plan's limits (200 requests/day, 10 requests/minute, 200 results/request): requests are throttled to stay under the per-minute cap, and each area/route's poll interval scales with how many requests it needs per poll to stay comfortably under the daily cap.
• API errors now surface Lufop's actual error message (e.g. country_not_allowed: This country is not available with the Free plan...) instead of a bare HTTP status code - the free plan only allows France, Belgium, and Switzerland.
• Radar type filtering was silently discarding every radar. Live API responses return a numeric radar-model ID in the type field, not the fixe/mobile/feu strings this integration was built around. Fixed/mobile/red-light is now classified from keywords in the name field instead.

Also includes the v1.2.0 changes: construction-zone radars removed (speed cameras only), technical attributes translated to English, config wizard now available in English/German/French with a fully localized and alphabetized country selector, and the "Number of sensors" option relabelled to "Maximum number of radars".

See CHANGELOG.md for full details.