jacksonmaker
@mariajackson · Joined May 2026
Maker · hobby projects · Hamilton
- Topics
- 1
- Replies
- 18
- Points
- 0
Forum Replies Created
Two sites now, both OK. Thanks!
Tried it on my own workspace and the table is empty. I have devices but I never made any sites. I’m guessing that’s the whole problem?
Which autopilot firmware and which port is free on it? Most have a second telemetry port meant for a companion computer.
Then guest is out. I did this for my sister’s bakery and two cafes, all Ubiquiti, so roughly your setup:
Make a new SSID “store-iot” with WPA2 PSK, tag it to its own VLAN (say 30), turn on client isolation so sensors can’t talk to each other, and in the firewall rules allow that VLAN only outbound: DNS, NTP, and TCP 8883 to the Hermetry broker (443 too if anything uses HTTPS). Block VLAN 30 to every other internal network. That’s what the auditor wants to see, and it’s one afternoon per store.
I wouldn’t add a Pi for this. A Pi is worth it when your devices can’t reach the internet themselves (BLE, Modbus, Zigbee) and something has to report for them as a gateway. Your ESP32s already do TLS on their own, a Pi just adds an SD card that can die in the back office.
On the Hermetry side two cheap extras: on the fridge profile set Allowed networks to each store’s public IP, so a stolen token is useless from anywhere else. And check Plain MQTT is off, TLS only on 8883 is the default but your IT guy may have turned it on while testing. Checklist at the bottom of Device transport security.
Following. I’ve never touched FSK mode at all.
Zigbee at home meshes fine for me, every mains-powered plug becomes a router. Never had a dead corner since.
I went down this hole for a garden sensor last year and the answer turned out to be energy per job, not current.
A battery device spends 99.9% of its life asleep. What empties the battery is (sleep current × sleep time) + (active current × awake time) + the radio. The core width hardly matters for sleep current: that’s set by the process the chip is made on, the RTC, the RAM retention and leakage. Modern 32-bit low power parts are made on newer, leakier-in-theory but better-managed processes with power domains you can switch off, and their sleep currents with RTC running are around 1 µA or less. An ATmega328P in power-down with the watchdog running is in the same ballpark at best, and with brown-out detection on, worse.
When awake, a 32-bit core finishes the job faster. Reading a 16-bit ADC result, doing a few multiplications for RMS current and building a packet is many more instructions on an 8-bit AVR than on a Cortex-M0+, at similar µA/MHz. Fewer cycles means less time awake, so less energy, even if the current while running is similar.
And the peripherals: the low power ARM parts can run the ADC, DMA and timers while the core sleeps, so the core wakes once with the result ready.
In my case the MCU choice turned out to be noise next to the radio: one LoRa transmit costs more than an hour of MCU sleep. Spend your effort on how often you send.
For the survey: carry one test sensor around and watch the frames log. RSSI and SNR per frame told me more than any coverage map.
HC-06 default is 9600. Is your sketch on 115200?
Way over my head but following, the tank-and-pump setup is the same as my rainwater barrel lol
Even with a null at the end, atoi on {“method”:… gives 0 because the first character is a brace. You need to parse the JSON.
CE0 vs CE1, of course. CS was on pin 24 and the code said 1. Changed it to spi.open(0, 0) and channel 0 now reads 412 with the tank half full, channel 1 floats like it should. Loopback test passed too, so I’ll keep that one. Sending mA now and scaling in the flow as twilson said.
VREF and VDD both on 3.3 V, AGND and DGND on ground. Checked twice.
Gaps of exactly the outage length sounds like nothing was published at all during the outage, not like the broker lost them. Is your client even queuing while disconnected?
Pretty sure the Pi doesn’t wire up the HEC pins at all, but I’ve never checked properly.