iot-contact/doc/api, branch mainIoT device to check if doors and windows are closed or openhttps://cgit.xengineering.eu/iot-contact/atom?h=main2025-07-30T17:50:18Zdoc: api: future: Switch to `mqtt/url` setting2025-07-30T17:50:18Zxengineeringme@xengineering.eu2025-07-30T17:46:47Zurn:sha1:d07fc8cb10b7c04f3a22137678fe1150f4a1e379doc: api: future: Switch to `set` topic suffix2025-07-30T17:50:18Zxengineeringme@xengineering.eu2025-07-30T17:41:03Zurn:sha1:8e722f61a6ba8e56b7a0a93fa41f5b9b23bff6c4
If a writable topic should correlate to a readable topic the new
convention is a suffix (`my/topic/set`) instead of the old prefix
(`request/my/topic`).
This keeps the alphabetical ordering the same.
doc: api: future: Order MQTT topic by alphabet2025-07-30T17:50:18Zxengineeringme@xengineering.eu2025-07-30T17:39:32Zurn:sha1:22c9abdba9961f2088999cb40d6906dc7ba01d2fdoc: api: future: Remove update automation2025-07-30T17:50:18Zxengineeringme@xengineering.eu2025-07-29T20:41:39Zurn:sha1:e5da3cfc1869899c7c6c84ffd218d9397f89be3a
With the change to MQTT the device will not be usable anymore without
server infrastructure.
This design change allows to reduce the complexity of configuration and
implementation here significantly.
The device only supports MQTT-triggered HTTP pull updates and the server
should take care of regularly triggering this via MQTT.
doc: api: future: Update MQTT API2025-07-27T09:45:54Zxengineeringme@xengineering.eu2025-07-27T09:45:54Zurn:sha1:aa4e3f742a9b1468b4c332a2b0d0183a353bedb8doc: api: future: Introduce device info concept2025-07-26T21:16:34Zxengineeringme@xengineering.eu2025-07-26T21:16:34Zurn:sha1:05579afdc2fd425b697b2ac77ba9e82eaaac9719
This reduces the HTTP endpoints and overhead.
doc: api: future: Switch to pull updates2025-07-26T20:53:50Zxengineeringme@xengineering.eu2025-07-26T20:53:50Zurn:sha1:325f029c35422267c4b3267838b9a46b4baf39e2doc: api: Add README.md and flatten future.md structure2025-07-24T12:46:00Zxengineeringme@xengineering.eu2025-07-24T12:37:21Zurn:sha1:1a44c30c94dbbf0f3aabc1610d61b032d9d80e29
This makes it later possible to diff the planned `current.md` with the
`future.md`. When the firmware is feature-complete the diff should be
empty.
doc: api: future: Add first draft2025-07-24T12:46:00Zxengineeringme@xengineering.eu2025-07-24T10:19:58Zurn:sha1:de80791503ceb080c8b32330e0414bf099e40ab0