{"entries":[{"lastCommit":{"author":{"email":"claas@claas.dev","name":"Claas","when":"2026-09-03T23:16:08.000000+02:00"},"committer":{"email":"claas@claas.dev","name":"Claas","when":"2026-09-03T23:16:08.000000+02:00"},"hash":"f506eb6d29f861cb960f8b17692ace3a0bcc9793","message":"Make the bypass position a type instead of a bool\n\nRenaming the bool told the reader which \"open\" was meant. It did not tell the\ncompiler, which had no opinion at all: a stray negation, or two match arms\nwritten the wrong way round, would invert the damper and build cleanly. That is\na live risk here rather than a theoretical one, because the two conventions\nboth exist in this repository -- `serial/src/devices/relay.ts` calls an\nenergised relay *closed*, since its contact closes between COM and NO, and this\ncrate calls that same state *open*, since the damper is then out of the way.\n\n`bypass::Position` is `Open` or `Closed` and says which subject it is about.\nThe bool survives in exactly two functions, `is_coil_energised` and its inverse\n`from_coil`, which sit next to each other so they cannot drift apart. Between\nthem they are the firmware's half of the wiring convention; the other half is\nwhich contact the actuator hangs off, which decides where the damper ends up on\na power loss and is not something the firmware can see.\n\nEverything between MQTT and the modbus call now carries the position rather\nthan a bool, so there is no longer anywhere for the polarity to be reapplied by\naccident. The coil functions keep their `is_on`: they are about the coil.\n\nThe logs read better as a side effect -- \"Bypass set Open\" rather than \"Bypass\nset to open: true\". Nothing changes on the wire or in Home Assistant.\n\nCo-Authored-By: Claude Opus 5 \n","tree":"f46153dda061ed968651e55008d4419026032fe9"},"mode":"0100644","name":"bypass.rs","size":3520},{"lastCommit":{"author":{"email":"claas@claas.dev","name":"Claas","when":"2026-08-28T23:01:02.000000+02:00"},"committer":{"email":"claas@claas.dev","name":"Claas","when":"2026-08-28T23:01:02.000000+02:00"},"hash":"ce9679a45f236fa6fcd6555418cd31a79e3ecee2","message":"Join the Wi-Fi network again after losing the link\n\nJoining happened once, during start up, and the control handle was dropped\nstraight after. Nothing could rejoin because nothing still owned the handle\nthat joining needs.\n\nThat held up until the access point went away. The mesh access point this\ncontroller reaches the network through is switched off overnight, and the\ncontroller never came back: it sat transmitting to an access point that was\nnot there for five days, while the fans, the button and the LEDs carried on\nworking perfectly. Only the network was gone, and nothing on the device could\nsay so, because saying so is what the network is for.\n\nSo keep the handle and give it to a routine that watches the link and joins\nagain when it drops. The MQTT session already reconnects when the broker goes\naway; this is the same idea one layer down, and without it that reconnect\nloop retries forever over a radio link that can never work again.\n\nJoining also waits between attempts now. Retrying as fast as the chip can\nanswer is harmless for the one attempt at start up and a busy loop for the\nwhole night once it can run whenever an access point is off.\n\nCo-Authored-By: Claude Opus 5 \n","tree":"5a616c0f6b6b439adedab7b6316eb832f8d1b095"},"mode":"0100644","name":"configuration.rs","size":3588},{"lastCommit":{"author":{"email":"claas@claas.dev","name":"Claas","when":"2026-08-23T16:37:50.000000+02:00"},"committer":{"email":"claas@claas.dev","name":"Claas","when":"2026-08-23T17:02:10.000000+02:00"},"hash":"b64ff20c74cc6724fa7468f3fd8e9738847ab727","message":"Require the button to hold low instead of trusting one edge\n\nTurning on a fluorescent lamp in the same room changed the fan speed. The\nlamp's glow starter interrupts current through the ballast, and the spike\nthat follows couples into the button wiring, which is a long conductor held\nhigh by nothing but the RP2040's weak internal pull-up. The edge is latched\nin INTR even when it lasts under a microsecond.\n\nThe old debouncer confirmed a press when no *further* falling edge arrived\nwithin the window, which catches contact bounce but rewards a lone spike:\nsilence is exactly what follows one. Wait for the level to hold instead, and\nstart over if it does not. Waiting for the level rather than a rising edge\nmeans a spike already over by then returns right away instead of counting as\na press for want of an edge that has been and gone.\n\n50 ms leaves bounce and interference far behind while staying under the\nshortest deliberate tap, and it makes the button snappier than the 250 ms the\nold window always waited out.\n\nBoth outcomes log at debug level. Filtering everything else away with\nDEFMT_LOG=\"error,fan_controller::debounce=debug\" leaves a log that says only\nwhether edges are arriving and whether they are being kept, which is what\nmakes this diagnosable the next time interference is suspected.\n\nCo-Authored-By: Claude Opus 5 \n","tree":"d698a965583c7c678f3e8ad0a376d3c67225f35f"},"mode":"0100644","name":"debounce.rs","size":1909},{"lastCommit":{"author":{"email":"claas@claas.dev","name":"Claas","when":"2026-08-23T15:29:57.000000+02:00"},"committer":{"email":"claas@claas.dev","name":"Claas","when":"2026-08-23T15:29:57.000000+02:00"},"hash":"f93c193859f81e89516e3463601a101a8454ef6d","message":"Drop the energy sensor the fans do not actually report\n\nBoth fans answer 0xFFFF for both registers of the consumption counter at\nD029/D02A, which arrived in Home Assistant as 4294967295 kWh and, with a\ntotal_increasing state class, went straight into the energy dashboard.\n\nSection 3.22 does document the counter as E[kWh] = data bytes with D029\nas the high half, and that is exactly what was implemented — the decoding\nwas never wrong. 0xFFFF is what an ebm-papst fan reports for a register\nits hardware variant does not implement, and the specification's foreword\nwarns that the documented feature set depends on the variant. There is no\nparameter to switch the counter on; it appears in the extract only in the\nregister list and in 3.22.\n\nPublishing null instead would have left two sensors that are permanently\nunknown, so the sensor is gone from the discovery payload, from the topic\ncrate and from `Reading`. That leaves 10 components in the payload rather\nthan 12, and four sensors per fan.\n\nD029 and D02A were the only reason the second run read past D027, so it\nis now a single register and is named after the power draw it carries.\n\nHome Assistant will not drop the two entities on its own: omitting a\ncomponent from a device discovery payload does not remove it, and this\nfirmware publishes discovery unretained, so there is nothing in the\nbroker to clear either. They have to be deleted in the UI, along with\ntheir long term statistics.\n\nCo-Authored-By: Claude Opus 5 \n","tree":"6a750e2a448096016a78fc1fdc079d19e214ea28"},"mode":"0040000","name":"fan","size":0},{"lastCommit":{"author":{"email":"claas@claas.dev","name":"Claas","when":"2026-09-03T23:16:08.000000+02:00"},"committer":{"email":"claas@claas.dev","name":"Claas","when":"2026-09-03T23:16:08.000000+02:00"},"hash":"f506eb6d29f861cb960f8b17692ace3a0bcc9793","message":"Make the bypass position a type instead of a bool\n\nRenaming the bool told the reader which \"open\" was meant. It did not tell the\ncompiler, which had no opinion at all: a stray negation, or two match arms\nwritten the wrong way round, would invert the damper and build cleanly. That is\na live risk here rather than a theoretical one, because the two conventions\nboth exist in this repository -- `serial/src/devices/relay.ts` calls an\nenergised relay *closed*, since its contact closes between COM and NO, and this\ncrate calls that same state *open*, since the damper is then out of the way.\n\n`bypass::Position` is `Open` or `Closed` and says which subject it is about.\nThe bool survives in exactly two functions, `is_coil_energised` and its inverse\n`from_coil`, which sit next to each other so they cannot drift apart. Between\nthem they are the firmware's half of the wiring convention; the other half is\nwhich contact the actuator hangs off, which decides where the damper ends up on\na power loss and is not something the firmware can see.\n\nEverything between MQTT and the modbus call now carries the position rather\nthan a bool, so there is no longer anywhere for the polarity to be reapplied by\naccident. The coil functions keep their `is_on`: they are about the coil.\n\nThe logs read better as a side effect -- \"Bypass set Open\" rather than \"Bypass\nset to open: true\". Nothing changes on the wire or in Home Assistant.\n\nCo-Authored-By: Claude Opus 5 \n","tree":"f46153dda061ed968651e55008d4419026032fe9"},"mode":"0100644","name":"main.rs","size":64047},{"lastCommit":{"author":{"email":"claas@claas.dev","name":"Claas","when":"2026-08-30T22:59:45.000000+02:00"},"committer":{"email":"claas@claas.dev","name":"Claas","when":"2026-09-03T23:02:21.000000+02:00"},"hash":"a9c148385ed60f1ad82c8ea7fb6d0e086c025379","message":"Drive the bypass damper from Home Assistant\n\nAdds `bypass_routine`, announces the switch, and connects the two, which turns\nthe previous two layers into a damper that actually moves.\n\nThe routine is modelled on `fan_control_routine` and differs where the device\ndoes. There is no second device to keep in step, so a write that will not go\nthrough after three attempts is logged and left alone rather than corrected --\na damper that stayed where it was does not put the house under pressure the way\ntwo fans at different speeds do. The relay has its own supply and holds its\nposition through a controller reset, so the position is read back on boot\nrather than assumed; that read waits for the fans' set point reads first, since\nthose are what the house needs and the damper can wait.\n\nThe state publish is awaited rather than dropped when the channel is full,\nunlike the sensor and display publishes. Those repeat on a timer or on the next\nchange; this is the only message that will ever describe this position, and a\ntoggle sitting in the wrong place in Home Assistant is worse than waiting. The\ncommands it answers arrive over the same connection that has to come back\nbefore the channel drains, so nothing is lost by waiting.\n\nNothing on the device displays the bypass. Both LEDs are fully spoken for by\nthe fan speed protocol, and there is no automation here either: when the bypass\nshould open is a temperature question Home Assistant already has the sensors\nfor.\n\n`documentation.md` gets the relay: the onboarding step, the bus wiring, how to\ncommission it off the bus, and which contact to hang the damper off so a relay\nthat loses power leaves the house recovering heat. The parity caveat is written\nup there as a warning, because it is the first thing to suspect if the relay\nstays silent.\n\nThe discovery payload has about 625 bytes of the send buffer left after the\nswitch.\n\nCo-Authored-By: Claude Opus 5 \n","tree":"b44b2a5289d935b3aca5bce5606c831272897759"},"mode":"0040000","name":"modbus","size":0},{"lastCommit":{"author":{"email":"claas@claas.dev","name":"Claas","when":"2026-08-23T17:53:43.000000+02:00"},"committer":{"email":"claas@claas.dev","name":"Claas","when":"2026-08-23T17:53:43.000000+02:00"},"hash":"726b55fb6e28dc6fad9db2029c5a91751fdaaf86","message":"Publish why the controller last reset\n\nA controller that reboots on its own is indistinguishable from one that was\npower cycled, and chasing interference made the difference matter: a reset\nand a spurious button press both end with the fan speed changing, but they\nhave nothing else in common and no shared fix.\n\nThe chip records the answer across the reset, so read CHIP_RESET before\nanything else runs. The watchdog reason is checked first because a watchdog\nreset runs through the same power-on state machine, which CHIP_RESET alone\nwould report as a plain restart.\n\nPublish it retained. The resets worth diagnosing are exactly the ones nobody\nis watching for, so the answer has to still be on the broker whenever someone\nnext looks. Retain needed a flag the encoder never set, so the publish trait\nnow decides per message whether the broker should keep it, which is the part\nof the fixed header TODO that is now done.\n\nCo-Authored-By: Claude Opus 5 \n","tree":"9e45947623570e8ac17aedd3563a44906b86b1ce"},"mode":"0040000","name":"mqtt","size":0},{"lastCommit":{"author":{"email":"claas@claas.dev","name":"Claas","when":"2026-08-23T17:53:43.000000+02:00"},"committer":{"email":"claas@claas.dev","name":"Claas","when":"2026-08-23T17:53:43.000000+02:00"},"hash":"726b55fb6e28dc6fad9db2029c5a91751fdaaf86","message":"Publish why the controller last reset\n\nA controller that reboots on its own is indistinguishable from one that was\npower cycled, and chasing interference made the difference matter: a reset\nand a spurious button press both end with the fan speed changing, but they\nhave nothing else in common and no shared fix.\n\nThe chip records the answer across the reset, so read CHIP_RESET before\nanything else runs. The watchdog reason is checked first because a watchdog\nreset runs through the same power-on state machine, which CHIP_RESET alone\nwould report as a plain restart.\n\nPublish it retained. The resets worth diagnosing are exactly the ones nobody\nis watching for, so the answer has to still be on the broker whenever someone\nnext looks. Retain needed a flag the encoder never set, so the publish trait\nnow decides per message whether the broker should keep it, which is the part\nof the fixed header TODO that is now done.\n\nCo-Authored-By: Claude Opus 5 \n","tree":"9e45947623570e8ac17aedd3563a44906b86b1ce"},"mode":"0100644","name":"reset_cause.rs","size":2435},{"lastCommit":{"author":{"email":"claas@claas.dev","name":"Claas","when":"2026-08-30T22:59:45.000000+02:00"},"committer":{"email":"claas@claas.dev","name":"Claas","when":"2026-09-03T23:02:21.000000+02:00"},"hash":"a9c148385ed60f1ad82c8ea7fb6d0e086c025379","message":"Drive the bypass damper from Home Assistant\n\nAdds `bypass_routine`, announces the switch, and connects the two, which turns\nthe previous two layers into a damper that actually moves.\n\nThe routine is modelled on `fan_control_routine` and differs where the device\ndoes. There is no second device to keep in step, so a write that will not go\nthrough after three attempts is logged and left alone rather than corrected --\na damper that stayed where it was does not put the house under pressure the way\ntwo fans at different speeds do. The relay has its own supply and holds its\nposition through a controller reset, so the position is read back on boot\nrather than assumed; that read waits for the fans' set point reads first, since\nthose are what the house needs and the damper can wait.\n\nThe state publish is awaited rather than dropped when the channel is full,\nunlike the sensor and display publishes. Those repeat on a timer or on the next\nchange; this is the only message that will ever describe this position, and a\ntoggle sitting in the wrong place in Home Assistant is worse than waiting. The\ncommands it answers arrive over the same connection that has to come back\nbefore the channel drains, so nothing is lost by waiting.\n\nNothing on the device displays the bypass. Both LEDs are fully spoken for by\nthe fan speed protocol, and there is no automation here either: when the bypass\nshould open is a temperature question Home Assistant already has the sensors\nfor.\n\n`documentation.md` gets the relay: the onboarding step, the bus wiring, how to\ncommission it off the bus, and which contact to hang the damper off so a relay\nthat loses power leaves the house recovering heat. The parity caveat is written\nup there as a warning, because it is the first thing to suspect if the relay\nstays silent.\n\nThe discovery payload has about 625 bytes of the send buffer left after the\nswitch.\n\nCo-Authored-By: Claude Opus 5 \n","tree":"b44b2a5289d935b3aca5bce5606c831272897759"},"mode":"0100644","name":"task.rs","size":35372}],"lastCommit":{"author":{"email":"claas@claas.dev","name":"Claas","when":"2026-09-03T23:16:08.000000+02:00"},"committer":{"email":"claas@claas.dev","name":"Claas","when":"2026-09-03T23:16:08.000000+02:00"},"hash":"f506eb6d29f861cb960f8b17692ace3a0bcc9793","message":"Make the bypass position a type instead of a bool\n\nRenaming the bool told the reader which \"open\" was meant. It did not tell the\ncompiler, which had no opinion at all: a stray negation, or two match arms\nwritten the wrong way round, would invert the damper and build cleanly. That is\na live risk here rather than a theoretical one, because the two conventions\nboth exist in this repository -- `serial/src/devices/relay.ts` calls an\nenergised relay *closed*, since its contact closes between COM and NO, and this\ncrate calls that same state *open*, since the damper is then out of the way.\n\n`bypass::Position` is `Open` or `Closed` and says which subject it is about.\nThe bool survives in exactly two functions, `is_coil_energised` and its inverse\n`from_coil`, which sit next to each other so they cannot drift apart. Between\nthem they are the firmware's half of the wiring convention; the other half is\nwhich contact the actuator hangs off, which decides where the damper ends up on\na power loss and is not something the firmware can see.\n\nEverything between MQTT and the modbus call now carries the position rather\nthan a bool, so there is no longer anywhere for the polarity to be reapplied by\naccident. The coil functions keep their `is_on`: they are about the coil.\n\nThe logs read better as a side effect -- \"Bypass set Open\" rather than \"Bypass\nset to open: true\". Nothing changes on the wire or in Home Assistant.\n\nCo-Authored-By: Claude Opus 5 \n","tree":"f46153dda061ed968651e55008d4419026032fe9"}}