lewisfw
@lewis-e · Membre depuis mars 2026
Embedded developer · energy · 14 years in the field
- Sujets
- 1
- Réponses
- 37
- Points
- 0
Toutes mes réponses sur les forums
Tyler, lower baud would make it worse here, there’s even less room for 200 lines a second. Liam has three separate bottlenecks.
The radio. 250 kbps is the raw air rate of 802.15.4. After framing, Zigbee network and APS headers, acknowledgements, retries and channel access, real application throughput for unicast is in the tens of kbps. Each RF packet carries around 80 bytes of payload at most, less with encryption. 20 kbps is roughly what everyone measures.
The serial side. In transparent mode the XBee buffers your bytes and sends a packet when it goes quiet for a moment or the buffer fills. At 115200 in, ~20 kbps out, the buffer overflows and bytes are lost, which is your half lines. Turn on CTS flow control (D7) and honour it in the sketch, or better, switch to API mode and send binary frames: pack 10 samples (3 × int16 each) into one 60-byte frame.
Hermetry. Publishing each sample as its own message is 200 messages a second from one device. The default profile limits are 10 messages a second and 200 data points a second, go over them and owners get a notice, keep going over and the session gets closed, so those are your warnings. Even batched, 600 values a second is far more than the per-device point limit and the organisation’s per-minute data points.
For a fan rig, compute features on the Pi: per axis RMS and peak every second, maybe crest factor. That’s 6 to 9 values in one message per second, comfortably inside the limits, and a much more useful chart than raw g values.
Limits are on MQTT under Limits.
Ultrasonic won’t do 1 mm on small moving products, the beam is too wide. Laser triangulation is the usual answer, a sensor head above the belt with a reference on the belt surface. Plenty of industrial heads do ±0.05 mm. Shiny surfaces can be tricky, ask for a demo on your product.
Aoife has it. Every DevKit has two NPN transistors (or one UMH3N dual) cross-coupled like this:
DTR ──[10k]── base Q1 Q1: collector → EN, emitter → RTS
RTS ──[10k]── base Q2 Q2: collector → IO0, emitter → DTREN or IO0 only gets pulled low when DTR and RTS are in opposite states. When both are asserted together (which is what many serial terminals do when they open the port), nothing happens. esptool toggles them in a sequence that holds IO0 low while EN goes high, so the chip starts in download mode, then releases both to run.
With your direct wires, any change of either line resets or straps the chip, hence the resets when the monitor opens and the stuck download mode.
Also add 10k pull-up on EN plus 1 uF to ground. Without the cap, EN can come up before the 3.3 V rail is stable and you’ll get random boot failures on power-up, especially with the AMS1117 which is slow.
Traduit de English par IA ·
Gardez les boutons. Le curseur ne peut afficher que ce que l’appareil remonte à Hermetry, donc l’ESP32 doit signaler la position après chaque mouvement, qu’il vienne d’un bouton ou d’une commande.Je parie que le retour en arrière vient de votre liaison Current value. Vérifiez vers quoi pointe l’emplacement Current value du curseur. S’il lit une valeur qui ne change qu’à l’envoi (ou rien du tout), il revient à cette valeur. Liez-le à une clé de télémétrie que l’ESP32 envoie lui-même, par exemple damper1_pos.Sur l’ESP32, après chaque mouvement :
void moveTo(int ch, int angle) {
angle = constrain(angle, 0, 90);
servo[ch].write(angle);
pos[ch] = angle;
char buf[48];
snprintf(buf, sizeof buf, "{"damper%d_pos":%d}", ch + 1, angle);
mqtt.publish("v1/telemetry", buf);
}
// button handler: moveTo(ch, pos[ch] + 15);
// command handler for damper.set: moveTo(ch, params["angle"]); then answer okRéglages du curseur qui ont fonctionné chez nous : Minimum 0, Maximum 90, Step 15 pour correspondre aux pas des boutons. Le curseur envoie une seule fois au relâchement, pas pendant le glissement, ce qui évite de saturer le servo. Pour un volet, vous pouvez activer Ask before running off, sinon l’accueil reçoit une boîte de confirmation à chaque mouvement. Laissez la commande au niveau Basic, une carte n’envoie rien de plus élevé.Il existe aussi « Disable the control when the reading is old », activé par défaut. Si l’ESP32 ne signale qu’en cas de changement et que personne n’a touché au volet pendant des heures, le curseur peut se griser. Faites-lui répéter la position toutes les quelques minutes avec les autres mesures.Les étapes de configuration sont dans Control cards.
Keep the buttons. The slider can only show what the device tells Hermetry, so the ESP32 has to report the position after every move, from a button or from a command.
I’d bet the jump-back is your Current value binding. Check what the slider’s Current value slot points at. If it reads something that only changes when you send (or nothing), it snaps back to that. Bind it to a telemetry key the ESP32 sends itself, for example damper1_pos.
On the ESP32, after any move:
void moveTo(int ch, int angle) {
angle = constrain(angle, 0, 90);
servo[ch].write(angle);
pos[ch] = angle;
char buf[48];
snprintf(buf, sizeof buf, "{"damper%d_pos":%d}", ch + 1, angle);
mqtt.publish("v1/telemetry", buf);
}
// button handler: moveTo(ch, pos[ch] + 15);
// command handler for damper.set: moveTo(ch, params["angle"]); then answer okSlider settings that worked for us: Minimum 0, Maximum 90, Step 15 so it matches the button steps. The slider sends once when you let go, not while dragging, so the servo isn’t spammed. For a damper you can turn Ask before running off, otherwise reception gets a confirm dialog on every move. Leave the command Basic tier, a board won’t send anything higher.
There’s also « Disable the control when the reading is old » on by default. If the ESP32 only reports on change and nobody touched it for hours, the slider may grey out. Have it repeat the position every few minutes with the other readings.
Setup steps are on Control cards.
Then split it, that’s what I’d do as a first project too.
The 4 mains-powered temperature sensors: ESP32 on Wi-Fi, straight to Hermetry over MQTT. No gateway, nothing in between, every sensor is a device you can see connect and disconnect. It’s the shortest path and you learn the topics and payloads on something that’s easy to debug.
The 4 battery door contacts: not Wi-Fi. An ESP32 waking up, joining Wi-Fi and doing a TLS handshake for every door open eats AA cells in weeks. Buy ready-made Zigbee contact sensors (a couple of years on a coin cell), a Zigbee USB coordinator, and run a small bridge on a Pi that reports them as child devices of a gateway. More moving parts, so do it second, once the Wi-Fi ones work.
Emily’s not wrong about the mesh, but with 4 battery contacts there’s no mesh to speak of, battery end devices don’t route. Mains-powered Zigbee devices do.
There’s a decent overview of which way to connect what in the docs, it’s basically this reasoning as a table: Choose how to connect your devices.
I sort this out on every substation job we do, and I treat signal, reference and shield as three separate conductors.
Signal: A and B on the twisted pair.
Reference: RS-485 needs a common mode reference. Add a third conductor (use a 2-pair cable, the second pair for 0 V) and connect the 0 V of every transceiver to it. Without it, the ground difference between the panel and a meter 140 m away eats into the receiver’s common-mode range, and VFD noise does the rest.
Shield: to protective earth, at the panel end, with a 360° clamp where the cable enters the cabinet, not a pigtail to a terminal. At the meter end either leave it open or connect it to earth through a 10 nF capacitor, which gives you HF shielding without a low-frequency ground loop. Both ends hard-bonded is fine only where the earthing system is meshed and equipotential, which next to a tray of VFD cables you shouldn’t assume.
Also check: 120 Ω at both ends of the line only, bias resistors once at the gateway, the tray separation from VFD cables (cross at 90° if you must), and no star wiring.
For the write-up, it helps to log the error rate. Have the gateway count CRC errors and timeouts per poll cycle and send them as telemetry, e.g. mb.crc_err and mb.timeouts, so you can show the before/after on a chart.
Draw the dryer bypass too if you have one, operators always ask why pressure dropped when someone opened it.