IoT device to check if doors and windows are closed or open https://cgit.xengineering.eu/iot-contact/atom?h=binary-descriptors 2025-03-22T20:21:44Z 2025-03-22T20:21:44Z xengineering me@xengineering.eu 2025-03-22T20:21:44Z urn:sha1:f4eccbe461f8c33144c72cfe2d533ecda4072d15 2025-03-22T20:21:44Z xengineering me@xengineering.eu 2025-03-22T20:21:44Z urn:sha1:0c771fb52f864c867d2fcff795e4d3ebd8de1c7c 2025-03-22T20:21:44Z xengineering me@xengineering.eu 2025-03-22T20:21:44Z urn:sha1:9f2ce4cc9ba9ad45a7e88247f8c1fb0953717b0e 2025-03-21T21:41:35Z xengineering me@xengineering.eu 2025-03-21T21:41:35Z urn:sha1:3447721d20146ba0447ee9998838266619e4c789 2025-03-21T21:40:53Z xengineering me@xengineering.eu 2025-03-21T21:40:53Z urn:sha1:7447a3875ea64b1fd45aaae850085b0cac5c8e50 The scope of the mac.{c,h} files was very small. Furthermore more network related logic needs a place. Thus making the name more general makes sense. 2025-03-21T21:39:30Z xengineering me@xengineering.eu 2025-03-21T21:39:30Z urn:sha1:2ddf4682f4c11f4356b030b6474fb12fea55b8ea This makes it transparent to the user that there is an active connection to the firmware. If the connection is broken the user notices that quickly and can re-load the page. 2025-03-21T21:33:41Z xengineering me@xengineering.eu 2025-03-21T21:33:41Z urn:sha1:e042129eddeb06c9272a6544c67f9222c347ab10 The primary interface for this firmware was so far HTTP. This protocol is not suitable for small and bidirectional messages which are time-critical. If something like this needs to be implemented with HTTP the best approach is likely long-polling which at least makes it possible for the server / the firmware to send data to the client / user as reaction to an event like a closed door sensor. TCP would fix this issue and is a good choice. Nevertheless web clients are not allowed to open TCP connections for security purposes. Thus the WebSocket protocol was created to fill this gap. To not duplicate the any effort the WebSocket API should be used for small, time-critical messages for all clients (one with TCP support like CLI tools as well as web clients). HTTP is still kept to provide a web page but also for functionality where HTTP is more suitable like firmware uploads. 2025-03-21T21:28:09Z xengineering me@xengineering.eu 2025-03-21T21:28:09Z urn:sha1:fb9bf2457dae53cd10a916c9beac6d292e28654a The heartbeat of the firmware might be used for multiple purposes. It can trigger a blinking LED on the PCB, can be displayed in a client program or might serve additional purposes. Since at least display in client programs should be implemented and multiple clients should be support in long term it improves the code structure to use a zbus channel here to publish heartbeat messages in a publish-subscribe pattern. That way the publishing of the heartbeat message and the receiving by an unknown number of observers is completely decoupled. A central trait of the publish-subscribe pattern and an advantage for a modular code structure. 2025-03-21T21:26:19Z xengineering me@xengineering.eu 2025-03-21T21:26:19Z urn:sha1:61e108a0ae856b3e1c849482d0008f698d41db27 Common browsers always request this URL. Not responding to it shows up as an error. To silence this error report the firmware just responds with HTTP 204 No Content since a favicon is currently not available. 2025-03-21T21:25:16Z xengineering me@xengineering.eu 2025-03-21T21:25:16Z urn:sha1:690f38b8212b2638ec323d19869cc0c14487375e 2025-03-21T21:24:27Z xengineering me@xengineering.eu 2025-03-21T21:24:27Z urn:sha1:dc146be244c8063971d7b769f35c8c9991cf144a 2025-03-21T21:23:47Z xengineering me@xengineering.eu 2025-03-21T21:23:47Z urn:sha1:2430e8557685a8af292ae82ca11ec59acb365390 This provides the index HTML page. 2025-03-21T21:23:32Z xengineering me@xengineering.eu 2025-03-21T21:23:32Z urn:sha1:b912c63ca9724a31f57226a44e87954e4fbd46c4 This follows the pattern: * ERR in error handler if statements * DBG at top of each function and on demand * INF at end of function 2025-03-21T21:22:51Z xengineering me@xengineering.eu 2025-03-21T21:22:51Z urn:sha1:07d694f3d21ffc1b69638b8732ffd630affc9768 The used MAC address is from an example range. Later it can easily be combined with reading from a MAC-providing EEPROM chip to using a unique hardware MAC on the device. 2025-03-21T21:15:46Z xengineering me@xengineering.eu 2025-03-21T21:15:46Z urn:sha1:fbed749cd316f1c9fe8dbe8a564b41f93cf0ac1f 2025-03-21T21:07:26Z xengineering me@xengineering.eu 2025-03-21T21:07:26Z urn:sha1:fcbd6ac3415d4a122d21b2e379ccf170620f45da Network-based logging via the syslog protocol allows to log from many IoT devices to a central log server. This makes reading logs way easier. Choosing UDP removes the need for logic keeping a state. Maybe dropped packages are acceptable for the use case but should be rare anyway. 2025-03-21T20:52:38Z xengineering me@xengineering.eu 2025-03-21T20:52:38Z urn:sha1:f0561bc721f783487ebdd3cbd1424cf116d48712 This makes it easier to develop the whole network-related firmware parts on a simulation board instead of hardware. The nucleo_f767zi board has likely a hardware bug making Ethernet sometimes fail. This is not suitable for development. 2025-02-11T10:59:32Z xengineering me@xengineering.eu 2025-02-11T06:14:29Z urn:sha1:57182e7bfad6c635140184db97477559393e2047 The Mozilla Public License seems to be suitable for this firmware project. See the original license text for details. This commit also adds a `.txt` suffix to the LICENSE file to make the file type more visible to humans and tools. 2025-02-11T05:58:50Z xengineering me@xengineering.eu 2025-02-11T05:58:50Z urn:sha1:304e1e443dc1283efbd1fe8b4a72c13f6cfc2fe4 This makes the name shorter which is especially relevant for Git commit messages.