derliebemarcus / homeassistant_teltonika_rms / 28290060867

98%

Build Type

push

github

Committed by web-flow

Commit Message

fix: align device inventory with current RMS schema (#79)

## Summary

- accept the current RMS device status contract (`0`, `1`, `2`, or
`null`) while retaining compatibility with legacy string statuses
- normalize the documented status semantics so `2` is pending rather
than truthy/online and `null` is offline
- make device IDs optional at contract-validation level because the
OpenAPI schema does not mark device properties as required
- use the documented `/devices` pagination parameters `limit` and
`offset`
- follow `meta.total` without the former implicit 20-page/1,000-device
truncation
- stop safely when RMS ignores `offset` and repeats a page
- de-duplicate overlapping pages and retain an explicit `max_pages`
limit for connection validation
- add contract, status-semantics, and pagination edge-case tests

## Root cause

The current RMS OpenAPI specification defines `device_body.status` as a
nullable integer:

- `0`: offline
- `1`: online
- `2`: pending
- `null`: offline

The integration required `status: str | None`. Pydantic therefore
rejected normal `/devices` responses and raised `RMS schema changed for
devices_list` during Home Assistant setup.

Even after accepting integers, passing numeric status through generic
truthiness would make `2` appear online. Device-list and device-detail
responses are now normalized to stable textual values before Home
Assistant consumes them.

The same specification documents `limit` plus `offset` for `/devices`
and returns `meta.total`. The existing client sent an undocumented
`page` parameter. Its old `max_pages=20` default would also truncate
inventories above 1,000 devices; the specification itself uses
`meta.total: 1420` as an example.

## Additional schema audit

No further strict response-type mismatches were found in the Pydantic
fields currently validated against `/devices` and `/devices/{id}`. The
remaining declared fields are aligned with the specification or
deliberately broader for compatibility.

... (continued)

Coverage Stats

79 of 82 new or added lines in 3 files covered. (96.34%)

1 existing line in 1 file now uncovered.

1975 of 2008 relevant lines covered (98.36%)

0.98 hits per line