Tasmota VS ESP-Now

BTW, there is one more way - if your devices are connecting to some kind of central hub, e.g. MQTT broker, they may send a "sticky" (retained) message with discovery info to some known topic - Tasmota is using this way, devices are publishing to tasmota/discovery/id and every time MQTT client connects it gets lastly updated autoconf info.

Just seeing your edit. WeightRaw is changing, so that is a good sign that everything might be hooked up right. I believe weight is in KG so it won't necessary change unless you put over a KG on the scale. I looked at the code for this and couldn't easily figure out what might be causing the calibration failure. I don't have time to figure out what all is going on there.

These are Tuya ones (unfortunately, the specific one on Amazon has been removed now, so can't share a link) reflashed with Tasmota so I can use them natively with Home Assistant rather than bouncing through a third-party cloud service. Bit of logic to manage the transitions from "not using power" to "using power" and convert that into notifications to the various Google Homes.

If it's a simple thing, the Tasmota firmware might do everything you need without a single line of code.

The lesson here is to never buy a smart home product which can only be controlled/montitored/upgraded via a cloud service provided by the hardware vendor. If the product cannot be controlled and monitored from your home network while unplugged from the internet, then there is some risk that this type of experience can happen again. Tasmota [0] allows a user to erase the vendor provided firmware, of ESP chipset devices, with well maintained open source firmware so that is never reliant on the vendor ever again. This is one example. Perhaps there are others.

[0] https://tasmota.github.io/docs/

You can use wifi devices, you just have to be careful about it. Anything that is supported by the Tasmota Project (https://tasmota.github.io/docs/) can be re-flashed with their firmware which doesn't make any calls to the internet and will directly talked to by anything that supports the MQTT protocol (Home Assistant, Hubitat, etc)

Here's the list https://github.com/arendst/Tasmota/blob/development/BUILDS.md

There's some other good tutorials for it as well, https://randomnerdtutorials.com/?s=esp-now and https://github.com/HarringayMakerSpace/ESP-Now

For power, I'd recommend Li-Ion primary (non-rechargeable) cells, whatever size works best for you. Those have essentially zero internal leakage and a 5 year shelf-life. If you've done it all correctly, it's conceivable it could be 5 years before you need to change the batteries (on top of a 30' ladder). You'd need a small high-efficiency buck converter to drop the 6.8V batteries down to 3.3V for the ESP, with a separate switched 5V linear regulator (one with a SHUTDOWN pin) to power the servos when they need to be driven. The ESP will consume 16-20uA in Deep Sleep, and the buck converter should mostly be off, except for when the ESP wakes every 3.5 hours (maximum Deep Sleep interval). If you're already using ESP-NOW to talk to the vent ESPs, then you could do a 'vent changed' check every time it wakes, otherwise it's more efficient to go back to Sleep quickly and wait until 12-24 hours has elapsed before you fire up a full WiFi connection. Not counting buck inefficiencies and servo movements, the ESP would only consume about 175mAh per year. The batteries will expire before they empty, maybe in 6-7 years.

I presume you've seen Anthony Elder's examples? He got a single ESP to act as hub by restarting it. In a low-traffic environment that'd work. There was discussion and a new PR to speed up the reconnect time using WIFI_RESUME that's been merged in the git repo, which should make a single-ESP hub faster to respond. You'd need a little fault checking in case the BSSID changes of course, but for the normal case things would be faster.