lewisfw
@lewis-e · Mart 2026 tarihinde katıldı
Embedded developer · energy · 14 years in the field
- Konular
- 1
- Yanıtlar
- 37
- Puan
- 0
Oluşturulan forum yanıtları
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Butonları koruyun. Kaydırıcı yalnızca cihazın Hermetry’ye bildirdiğini gösterebilir; bu yüzden ESP32, her harekettan sonra, butondan ya da komuttan gelmiş olsun, konumu bildirmek zorundadır.Geri zıplamanın Current value bağlantınızdan kaynaklandığından eminim. Kaydırıcının Current value yuvasının neye bağlı olduğunu kontrol edin. Yalnızca siz gönderdiğinizde değişen (ya da hiç değişmeyen) bir değeri okuyorsa, oraya geri döner. Bunu ESP32’nin kendisinin gönderdiği bir telemetri anahtarına bağlayın, örneğin damper1_pos.ESP32 üzerinde, her harekettan sonra:
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 okBizim için işe yarayan kaydırıcı ayarları: Minimum 0, Maximum 90, Step 15; böylece buton adımlarıyla eşleşir. Kaydırıcı, sürüklerken değil bıraktığınızda bir kez gönderir; servo böylece gereksiz yere bombardımana tutulmaz. Damper için Ask before running off seçeneğini açabilirsiniz; aksi halde resepsiyon her harekette bir onay penceresi alır. Komutu Basic seviyesinde bırakın, kart bundan yükseğini göndermez.Varsayılan olarak açık olan “Disable the control when the reading is old” seçeneği de var. ESP32 yalnızca değişiklikte bildiriyorsa ve saatlerce kimse dokunmadıysa kaydırıcı gri görünebilir. Konumu diğer okumalarla birlikte birkaç dakikada bir tekrarlamasını sağlayın.Kurulum adımları Control cards sayfasında.
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.