New: the AI firewall watches the whole platform and explains each incident in plain words. See how it works

aisha.maker

aisha.maker

@aisha_r58 · Joined October 2025

Newcomer

Maker · home automation · Brisbane

Topics
7
Replies
40
Points
0
Newcomer10 points to Member

Forum Replies Created

Viewing 15 posts – 16 through 30 (of 40 total)

Dongle route it is. Antenna on top of the box, onboard Wi-Fi off, signal now -61 dBm with the door shut. No keepalive disconnects in the Log tab since Saturday, and I kept the soldering iron in the drawer. Had to install the driver for my dongle first, it was a RTL8812AU one, so check yours is supported before buying.

♥ 1

Tyler’s right in one line, here’s the longer version. PubSubClient only reads from the socket and sends pings inside client.loop(). Its default keepalive is 15 s. You sleep 30 s, so no ping goes out, the broker drops you for keepalive_timeout, and state -3 is “connection lost”.

Never block in loop(), use a timer instead:

unsigned long last = 0;

void setup() {
  ...
  client.setKeepAlive(60);
  client.setBufferSize(512);
}

void loop() {
  if (!client.connected()) reconnect();   // with a back-off, not a tight loop
  client.loop();                          // every pass
  if (millis() - last >= 30000) {
    last = millis();
    snprintf(buf, sizeof buf, "{"temperature":%.2f}", bme.readTemperature());
    client.publish("v1/telemetry", buf);
  }
}

Keepalive between 30 and 300 s is what the docs recommend. And do what Niall said, the Log tab names the reason for every disconnect.

Accepted solution♥ 1

No per-device topics needed. All 300 publish to the same v1/telemetry. Hermetry knows who’s talking from the credential the device logged in with, so the token is effectively the address. Unit 17 can’t write as unit 18 because it doesn’t have 18’s credential, and a device can only subscribe to its own downlink topics (v1/attributes/set, v1/rpc/req/+ and so on), so it never sees another device’s messages either. No ACL file to keep.

Kevin’s not wrong that Custom topics exist, but they’re for firmware you can’t change: the profile then takes any topic outside v1/ as telemetry of that device. Limits there are topic depth 8, length 128 and 50 distinct topics per device, and with “Prefix keys with the topic” grid/s12/temp becomes a key like grid.s12.temp. Since you’re writing new firmware, skip all of that.

For the site id I’d make it an attribute of the device instead of part of the topic. It doesn’t change every minute so it doesn’t belong in telemetry.

Reference with the full topic table: MQTT topics and payload reference. One practical thing from when I moved my own stuff: give every unit its own credential. Two devices sharing one token keep kicking each other off.

Accepted solution♥ 9

Sorted. Added the hotspot with nmcli as tsmith wrote, priorities 20/10. Saturday it joined the phone within about 40 s of boot. Readings went into a JSONL file while the phone had no signal at the far beds, then went up in batches of 50 when it came back. First week the times were off by an hour on the first few readings, the NTP thing exactly, so I’ve ordered a DS3231 like Michael. Until it comes the script checks NTPSynchronized before stamping.

♥ 0

Ordered 20 MDBT42Q modules to rework the board, and set up a Pi gateway at home with the v1/gw format. My five tags showed up as children named after their MAC addresses within a minute. The double-reporting point is real: two Pis in my house both reported the same tag, fixed it with a strongest-RSSI rule in the gateways.

♥ 0
Viewing 15 posts – 16 through 30 (of 40 total)