lewisfw
@lewis-e · Se unió el marzo 2026
Embedded developer · energy · 14 years in the field
- Temas
- 1
- Respuestas
- 37
- Puntos
- 0
Respuestas de foro creadas
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.
Traducido del English por IA ·
Conserve los botones. El deslizador solo puede mostrar lo que el dispositivo le comunica a Hermetry, así que el ESP32 tiene que informar la posición después de cada movimiento, ya sea desde un botón o desde un comando.Apuesto a que el salto de vuelta se debe a su enlace de Current value. Revise a qué apunta la ranura Current value del deslizador. Si lee algo que solo cambia cuando envía (o nada), vuelve a ese valor. Enlácelo a una clave de telemetría que el propio ESP32 envíe, por ejemplo damper1_pos.En el ESP32, después de cualquier movimiento:
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 okAjustes del deslizador que nos funcionaron: Minimum 0, Maximum 90, Step 15 para que coincida con los pasos de los botones. El deslizador envía una vez al soltarlo, no mientras arrastra, así que el servo no recibe un bombardeo de órdenes. Para una compuerta puede activar Ask before running off; si no, recepción recibe un cuadro de confirmación en cada movimiento. Deje el comando en nivel Basic, una placa no envía nada superior.También está «Disable the control when the reading is old», activado por defecto. Si el ESP32 solo informa cuando hay cambios y nadie la ha tocado en horas, el deslizador puede aparecer en gris. Haga que repita la posición cada pocos minutos junto con las demás lecturas.Los pasos de configuración están en 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.