Ductapemaster

Water is being used to get heat from one place to another. The idea is being able to separate the heat generation and the heat extraction

If you were to remove the heat at a sufficient rate by, say, turning the lid into a heat exchanger, you would have a stable system.

Evaporative cooling does not necessitate an open loop system

I usually smell it too. I've noticed its when they switch from the air handler provided by the jetway (big yellow hose) to the plane's onboard system. Perhaps there's some sequencing procedure that the staff is moving through too quickly trying to get the plane out on time, or it's just an acceptable amount of cross-contamination.

You're right, I was representing a best-case scenario with an intention to be inspiring.

And yes, the Android approach works too and I have done exactly that with Claude previously. The BLE dongle is however a platform-independent approach.

Quite possible transport is encrypted, but that can likely be overcome with some RE on the Android app. Given the price of this piece of hardware, it's likely recoverable with moderate effort. At least worth a try.

From my experience Fable will reject this request - its pretty trigger-happy with it's safety detector for reverse engineering, even if you push it on right-to-repair. However Opus 4.8 is more than capable of doing it, with a bit of guidance.

While I empathize with your feelings about lock-in, I encourage you to see that we live in an amazingly empowering era. I would wager that with $20 in credits for the LLM flavor of the week and and an equally expensive BLE-to-USB dongle (try the nRF52840 dongle), you will have the protocol reverse-engineered overnight. BLE protocols are often very low-hanging fruit for this type of effort.

Yes, it's annoying this stuff isn't open source from the get-go, but it has never been easier to open hardware up for yourself and others.

Nice work! Through efforts with Claude in the last few weeks, I have a working model of the actual wireless protocol between sensor and bridge, and have built a passive listener device to snoop on local traffic. I'm in the process of creating documentation for the protocol and would be happy to share what I've learned.

Shoot me an email at my username-at-gmail if you want to chat.

The 8266 has no flash readout protection, and the UART is exposed on a programming header. It was very easy to dump the firmware.

I looked into it and the channel sounding approach isn't yet ready. Will need the new iOS as well as some firmware work from Nordic's side.

No need — I simply plugged into the exposed programming header on the gateway.

The sensor has an Atmel SAMD part which I assume has the security bit set. I didn't need to dump that firmware directly as it exists within the gateway flash.

I am planning a write up once I get it working. I'd be happy to share.

My setup is a logic analyzer tap on the SPI bus between 8266 and the RFM69 on the bridge device to log raw traffic, and my secondary RX (ESP32 + RFM69) for over-the-air traffic.

Also, I have a gas meter sensor based on your work half-built on my workbench. I plan to set that up once I finish my Flume distraction. Great work, thank you!