Navimow Binding 0.2.0 (openHAB 5.2.0)

Navimow Binding 0.2.0

Second pre-release. Still targets openHAB 5.2.0 and is not yet submitted to the official openHAB
add-ons repository.

New since 0.1.0

• Optional MQTT push connection (enableMqtt bridge config, default off): pushes activity/
  battery-level updates within milliseconds of a real state change instead of waiting for the next
  REST poll. Purely additive - REST polling remains the bridge's only source of truth for online/offline
  status, and the bridge stays fully functional if MQTT fails to connect.
  • Investigated specifically for mower position, based on earlier reverse-engineered SDK reading.
    Live-tested against a real Navimow X430 across docked/mowing/returning states and the sibling
    event/attributes topics: position is not delivered over MQTT at all. The feature was
    pivoted to its actual, proven value - push latency, not new data.
• New model channel on the mower Thing (String, read-only), mirroring the modelId Thing property
  as a plain bindable Item - useful for dashboards/widgets that want to key their appearance off the
  mower model without a separate Thing lookup.
• Model, firmware, and battery tier surfaced as Thing properties (modelId, firmwareVersion,
  batteryTier), refreshed every poll cycle from the same data already being fetched.
• Full README replacing the unfilled binding-archetype skeleton: supported things, discovery, bridge/
  mower configuration, channels, Thing properties, a full example, and known limitations.

Fixes and cleanup

• Fixed a reflected-XSS gap in the OAuth connect servlet's error page (the error redirect parameter
  was inserted into the HTML response unescaped).
• Reduced internal duplication (shared response-envelope base class, shared activity-update/device-id
  helpers, single config fetch per connection cycle) - no behavior change.
• Filled in missing Javadoc across the binding and corrected a couple of stale comments left over from
  before MQTT support existed.

Known limitations (unchanged from 0.1.0, restated)

• Cloud-only: requires internet connectivity; no local/LAN fallback.
• Mower position is not available at all - now conclusively confirmed rather than just undocumented.
• STOP and PAUSE are indistinguishable from the reported state alone - both settle to the same
  paused activity value.
• The MQTT connection can only be opened from inside the account bridge's own process - the cloud API
  binds an access token to whichever process first used it. This is a Segway backend behavior, not a
  limitation of this binding.

See the README for full configuration, channels, and details.

Feedback

Still a beta: built, live-tested, and iterated against a real production Navimow X430 throughout
development, but without independent third-party review or broad testing across other Navimow models
yet - issues and feedback welcome.

Navimow Binding 0.1.0 (openHAB 5.2.0)

Navimow Binding: first beta release

This is the first public release of the org.openhab.binding.navimow add-on: an openHAB binding for Segway Navimow robotic lawn mowers, integrating via Segway's cloud REST API and, optionally, its MQTT push channel.

This binding is not yet submitted to the official openHAB add-ons repository. It targets openHAB 5.2.0 and has been built, live-verified, and iterated against a real production Navimow X430 throughout development, but it hasn't had independent third-party review or broad real-world testing across other Navimow models yet, hence beta.

Supported Things

• Bridge (account): a Segway Navimow cloud account. Owns the browser-based OAuth2 authorization flow, the REST polling loop, and the optional MQTT push connection.
• Mower (mower): one robotic lawn mower linked to the account, auto-discovered once the bridge is online.

Highlights

• Browser-based OAuth2 login - no manually pasted auth codes or client secrets to configure
• Automatic discovery of every mower linked to the account
• Full command support: START, STOP, PAUSE, RESUME, DOCK, all live-verified end-to-end against a real mower
• Configurable REST polling interval (default 60s)
• Optional MQTT push connection (enableMqtt) for lower-latency activity/battery-level updates (observed ~130ms after a real state change, live-tested) - purely additive, REST polling remains the bridge's only source of truth for online/offline status
• Model, firmware version, and a human-readable battery tier surfaced as Thing properties
• Every REST/business-error edge case found during development (including a cloud-side access-token/process-binding quirk) is handled and documented in the source

Known limitations

• Cloud-only: requires internet connectivity; no local/LAN fallback
• Polling-based updates by default (60s interval); MQTT lowers latency but does not add new data
• Mower position is not available at all - the MQTT push channel was specifically investigated for this and does not carry it, contrary to what earlier reverse-engineered documentation suggested
• STOP and PAUSE are indistinguishable from the reported state alone - both settle to the same isPaused state
• The MQTT connection can only be opened from inside the account bridge's own process (a cloud-side access-token restriction, not a limitation of this binding), so it cannot be independently diagnosed with an external tool

See the README for full configuration, channels, and known limitations.

Feedback

This is a beta: issues, especially around Navimow models other than the X430 this was developed against, are expected and welcome.

Diagral Binding 0.3.0 (openHAB 5.2.0)

Diagral Binding 0.3.0: no more duplicate commands from double-clicks

A focused release: one reliability fix, requested after real-world use of the batch zone control added in
0.2.0 surfaced a rough edge with dashboard widgets.

Fixed: double-clicking a widget could send the same command twice

Arming/disarming the system or activating/disabling a group from a Main UI widget could fire the exact same
command twice in a row on a single double-click/double-tap, sending two identical requests to the Diagral
API for what the user intended as one action.

The bridge now tracks in-flight and just-completed commands, keyed by what's being done (e.g. "activate
group 3"). An exact duplicate arriving while the first is still running, or within 1.5 seconds after it
finishes, is dropped before it ever reaches the API - no extra request, no extra re-poll. Different
commands (two different zones, or a zone activation racing a mode change) are never affected by each
other's in-flight state, and a deliberate second press a few seconds later still goes through normally.

Covered by 5 new unit tests (including a true concurrent-overlap test using a blocking mock) and 3 new
integration tests against the FakeDiagralApiServer harness, verifying the real HTTP layer sees only one
request for a duplicate, independent requests for different zones, and a second real request once the
dedup window has elapsed.

Upgrading

Drop the jar into your addons folder as before; no configuration or item changes are required.

See CLAUDE.md for the full investigative history behind this and every prior fix.

Diagral Binding 0.2.0 (openHAB 5.2.0)

Diagral Binding 0.2.0: security hardening, correctness fixes, batch zone control, and semantic model support

The biggest release since 0.1.1 - a full security and correctness review of the bridge/HTTP layer, several
live-verified reliability fixes, two new capabilities (batch group control and semantic tagging), and a
fix for a channel that silently never worked.

Security

• Credentials no longer reach the log. Response bodies carrying an access token or API key/secret pair are
  now redacted even at TRACE, and a leak where a full API key appeared in a logged request URL is closed.
• API keys no longer accumulate on your Diagral account. Every re-authentication used to leave the previous
  key pair permanently registered; the superseded key is now deleted.
• An HTTP 400 (malformed request) is no longer treated as an expired credential - it used to discard a
  working API key and loop re-authenticating for as long as the bad request kept being retried.
• Request signing (HMAC/timestamp/API key) is now computed atomically, closing a race where a concurrent
  re-authentication could produce a signature that didn't match the key it was sent with.

Reliability

• The mode-control channel no longer gets stuck permanently blank after a successful arm/disarm.
• A zone's active state is now correctly derived once it settles into the API's GROUP status, and the
  bridge's internal state stays thread-safe under concurrent access.
• Two overlapping polls can no longer race each other and duplicate every HTTP call.
• The bridge now retries a failed first authentication automatically instead of requiring a manual
  disable/enable to recover.
• Device state (enabled/low-battery) and central-unit battery status are no longer frozen at the first
  successful fetch - the underlying cache is now time-bounded so changes made outside openHAB (e.g. from the
  e-ONE app) are picked up.
• motion/contact channels report UNDEF instead of a fabricated OFF/CLOSED - the API has no live
  value for either, and the previous hardcoded value could make a rule silently never fire.
• Lifecycle callbacks (initialize(), bridgeStatusChanged()) no longer block on the cloud API, fixing the
  framework's recurring "takes more than 5000ms" warnings.
• Discovery no longer aborts entirely if one device record from the API is malformed; the bridge now backs
  off automatically when the API throttles it (429/5xx) instead of hammering it at the normal poll rate.
• Every child Thing in a poll cycle now shares one consistent snapshot of the system's state, instead of
  each independently re-fetching and risking a partial/inconsistent view.

New: batch zone control

• The alarm system Thing gains activate-groups/disable-groups channels: send a comma-separated list of
  zone IDs (e.g. "1,3,5") to arm or disarm several zones in a single API call instead of one call per zone.
• Each zone (group) Thing gains a read-only group-id channel, so a rule or widget can build that list
  without hardcoding zone numbers.

New: semantic model tags

Every Thing and its key channels now carry openHAB semantic tags (AlarmSystem, AlarmZone,
MotionDetector, Siren, etc.), matching the convention used by this repository's other alarm-panel
bindings. This lets Main UI's Add Equipment from Thing build a proper Equipment/Point structure
straight from the binding - including a real per-zone Group item you can iterate in a rule or widget.

Fixed: the contact channel never actually worked

The contact/door sensor's contact channel referenced a core channel type that doesn't exist in current
openHAB versions - it silently disappeared at runtime, so no contact sensor has ever reported open/closed
state through this binding. It's now a real, binding-owned channel (still UNDEF-only, since the API has
no live contact value - see "Reliability" above).

Under the hood

Substantial internal cleanup with no behavior change: five near-identical discovery methods collapsed into
one, repeated HTTP-response parsing and bridge accessor boilerplate deduplicated, the handler-factory
if/else replaced with a table, dead code removed. A new stateful fake of the Diagral cloud API
(FakeDiagralApiServer) now backs integration-style tests that exercise the real HTTP/auth/bridge classes
together without live network access. Full Javadoc audit across every class, method, and DTO field.

Upgrading

Drop the jar into your addons folder as before; no configuration changes are required. If you use the new
group-id channel or want the semantic-model structure, you'll need to re-link or re-add the affected
Things after upgrading.

See CLAUDE.md for the full investigative history and live-verification notes behind each fix.

Diagral Binding 0.1.1 (openHAB 5.2.0)

Diagral Binding 0.1.1: reliability fixes for arm/disarm state tracking

This release fixes several issues found through extensive live testing against a real Diagral installation, focused on making openHAB's view of the alarm's armed/disarmed state trustworthy no matter how it was changed (from openHAB itself, from the official e-ONE app, or via a whole-system mode vs. a single zone).

Fixes

• mode-control on the alarm system Thing previously stayed permanently NULL after a successful arm/disarm; it now correctly reflects the current mode.
• Zone (group) active state is now derived correctly for the GROUP status the real API reports once a directly-armed zone settles. Previously this settled state was ignored and the zone's active channel could report the wrong value indefinitely.
• All child Things (alarm system, zones, sensors) now share a single status snapshot per poll cycle instead of each independently re-fetching, avoiding a race where a slow request from one handler could push another handler's read past the cache window and return stale data.
• A discovery listener registering after the bridge already has a populated configuration now immediately receives all already-known devices, instead of only devices discovered after registration.
• The bridge now flips to OFFLINE after 5 consecutive poll failures, closing a gap where a genuinely sustained outage was silently tolerated forever. The threshold is sized generously from this binding's own observed pattern of transient timeouts self-healing within 1 to 3 poll cycles, so normal flakiness will not trip it.

Upgrading

Drop the jar into your addons folder as before; no configuration changes are required.

See CLAUDE.md for the full investigative history and live-verification notes behind each fix.

Diagral Binding 0.1.0 (openHAB 5.2.0)

Diagral Binding: first beta release

This is the first public release of the org.openhab.binding.diagral add-on: an openHAB binding for Diagral home alarm systems, integrating via Diagral's cloud REST API (HMAC-SHA256 signed requests; there is no local/LAN protocol support, everything goes through the cloud).

This binding is not yet submitted to the official openHAB add-ons repository. It targets openHAB 5.2.0 and has been built, live-verified, and iterated against a real production Diagral installation throughout development, but it hasn't had independent third-party review or broad real-world testing yet, hence beta.

Supported Things

• Bridge: holds cloud credentials, manages authentication and polling
• Alarm System: arm/disarm control (OFF/FULL/PRESENCE/PARTIAL1/PARTIAL2) and anomaly reporting
• Motion Sensor / Contact Sensor: detection state, enable/disable, low-battery
• Group (zone): per-zone activation, either directly or as part of a whole-system mode
• Siren, Keypad, Plug, Transmitter, Camera: enable/disable and low-battery where the Diagral API supports it

Highlights

• Automatic discovery of the alarm system, all sensors, groups, and peripherals
• Real anomaly reporting (battery, radio link, etc.) rather than a stub
• Per-device enable/disable (inhibit), including a documented workaround for a Diagral API quirk where this endpoint returns a false HTTP 500 on success
• Group entry/exit delay and arm-mode membership surfaced as discovery-time properties
• API key cleanup on bridge disposal, so keys don't accumulate on the account
• Automatic recovery from transient cloud API timeouts/failures on both polling and command paths (arm/disarm, group/device actions), including a retrying first authentication attempt
• Full i18n translation support (English source strings ready for Crowdin-style translation)
• Every class and method documented (including private members) for maintainability

Known limitations

• Cloud-only: requires internet connectivity; no local/LAN fallback
• Polling-based updates (default 60s interval), not push/real-time
• API keys are stored in memory only, regenerated each openHAB restart
• The Diagral cloud API's activated_groups status field is unreliable under all conditions; this binding works around it by deriving zone state from its own cached configuration and a best-effort local record during transitional arming states (see README "Known Bugs" for details)
• Automatism "rudes" (shutters, gate/garage automatisms, comfort relays) are not implemented: Diagral's cloud API currently returns no data for this category regardless of installed hardware

See the README for full configuration, channels, and a detailed "Known Limitations & Bugs" section, and CLAUDE.md for architecture notes.

Feedback

This is a beta: issues, especially around less common configurations (multiple groups/modes, device types not present on the developer's own installation) are expected and welcome.