si_tyler
@twilson · Se unió el marzo 2026
System integrator · energy · 15 years in the field
- Temas
- 3
- Respuestas
- 20
- Puntos
- 0
Respuestas de foro creadas
Traducido del English por IA ·
Una VPN es justo la conversación que intento evitar. Su equipo de seguridad trata cualquier túnel hacia su red como un nuevo proyecto con una revisión de 3 meses.
A VPN is exactly the conversation I’m trying to avoid. Their security team treats any tunnel into their network as a new project with a 3 month review.
+1 to Grace. We lost a week on a site job because of a PCB antenna inside a steel cabinet.
Also those slow clients eat airtime for everyone on that AP. A frame at 1 Mbps occupies the channel for a long time.
Traducido del English por IA ·
La solución más fácil: no reinicies el script. Ejecútalo como servicio de systemd con Restart=always, abre el puerto una vez y nunca lo cierres.
Easiest fix: don’t restart the script. Run it as a systemd service with Restart=always, open the port once and never close it.
Traducido del English por IA ·
Era el adaptador. Información del sistema no mostraba nada con mi dongle USB-C genérico; con un hub con alimentación aparece «USBasp» y avrdude lo encuentra. Ayer grabé cuatro placas en campo; la placa de repuesto recién comprada necesitaba -B 32, tal como dijo tsmith. Los fusibles ya estaban configurados en las demás. El portátil con Linux se queda ahora en el taller.
Adapter it was. System Information showed nothing through my no-name USB-C dongle; through a powered hub it shows «USBasp» and avrdude finds it. Flashed four boards in the field yesterday, the brand-new spare board needed -B 32 exactly like tsmith said. Fuses were already set on the others. Linux laptop stays in the workshop now.
For the sensor: an FSR strip under the mattress works but needs calibrating per mattress and drifts as the foam ages. Load cells under two legs are more reliable and don’t care about bedding. Avoid PIR, it can’t tell «in bed» from «standing next to the bed».
Traducido del English por IA ·
Buena detección. Conviene poner el host en un archivo de configuración en lugar de en la compilación, para que la próxima planta no copie un host codificado de forma fija.
Good catch. Worth putting the host in a config file instead of the build, so the next plant doesn’t copy a hardcoded host.
Traducido del English por IA ·
Mismo error con el avrdude del Arduino IDE.
Same error with the Arduino IDE’s avrdude.
On the device: take 5 readings a second apart and send the median, not one sample. Kills most of the hand-in-the-way readings before they leave the board.
0xE2 is a response timeout. Same baud and parity on both meters?
Fitted the DW from the tube, port is back and the meters reappeared as children within a minute. Both TVS diodes measured short, replaced those too. You were right about the package table at the end, I’d only looked at the one on page 1.
Traducido del English por IA ·
Para los inversores, compruebe si soportan los mapas SunSpec Modbus; así no tendrá que escribir un mapa de registros para cada modelo.
For the inverters check if they do SunSpec Modbus maps, saves you writing a register map per model.
Traducido del English por IA ·
Para el escalado puede enviar los mA sin procesar y dejar que un bloque Scale en el flujo raíz de Hermetry convierta 4-20 en 0-10 bar. Así podrá ajustar el rango más adelante sin tocar la Pi.
And for the scaling you can send the raw mA and let a Scale block in Hermetry’s root flow turn 4-20 into 0-10 bar, then you can fix the range later without touching the Pi.
Traducido del English por IA ·
Kevin tiene razón, y eso es solo la mitad. Nos encontramos con lo mismo en un parque eólico.El MQTT de Hermetry es 3.1.1, y un CONNECT con clean session en false se atiende como clean. No se encola nada para un dispositivo mientras está desconectado, salvo los comandos enviados como persistentes. Por tanto, no hay estado de sesión que reanudar, en ninguna dirección para la telemetría.Lo que Hermetry sí garantiza es en el sentido de entrada: el PUBACK solo se envía después de que el mensaje esté encolado de forma segura en su lado. Si no puede encolarse, no recibes PUBACK, la sesión se cierra y se espera que el cliente vuelva a enviarlo tras reconectar. Los duplicados con el mismo dispositivo, clave y marca de tiempo se almacenan una sola vez, así que reenviar es seguro.Así pues, el búfer es tuyo, y el patrón es:
- Escribe cada lectura en un almacenamiento local (nosotros usamos un archivo SQLite) con su propio ts en ms.
- Publica desde el almacenamiento y elimina una fila solo cuando llegue su PUBACK.
- Tras reconectar: suscríbete, solicita los atributos compartidos y luego envía el backlog antes de los datos en vivo.
Envía el backlog como arrays de {ts, values} para que llegue en los momentos correctos. El perfil tiene un límite separado de Mensajes de repetición por segundo para mensajes cuyos registros son todos anteriores a un minuto, así que un backlog largo se vacía en un tiempo. No te preocupes si no aparece todo a la vez.La página de MQTT tiene la sección de confirmaciones, vale la pena leerla una vez.
Kevin’s right, and that’s half of it. We hit the same thing on a wind site.
Hermetry’s MQTT is 3.1.1 and a CONNECT with clean session false is served as clean. Nothing is queued for a device while it’s offline, apart from commands that were sent as persistent. So no session state to resume, in either direction for telemetry.
What Hermetry does promise is on the way in: the PUBACK goes out only after the message is safely queued on their side. If it can’t be queued you get no PUBACK and the session closes, and the client is expected to resend after reconnecting. Duplicates of the same device, key and timestamp are stored once, so resending is safe.
So the buffer is yours, and the pattern is:
- Write every reading to a local store (we use a SQLite file) with its own ts in ms.
- Publish from the store, delete a row only when its PUBACK arrives.
- After reconnect: subscribe, ask for shared attributes, then send the backlog before live data.
Send the backlog as arrays of {ts, values} so it lands at the right times. The profile has a separate Replay messages per second limit for messages whose records are all older than a minute, so a long backlog drains over a while. Don’t panic when it doesn’t all appear at once.
The MQTT page has the acknowledgement section, worth reading once.
Built one of these with my kid a couple of years ago and made both mistakes.
Angle: combine the two sensors with a complementary filter. The gyro is good short-term, the accelerometer long-term:
// fixed 200 Hz loop from a hardware timer, dt = 0.005
float accAngle = atan2f(ax, az) * RAD_TO_DEG;
angle = 0.98f * (angle + gy * dt) + 0.02f * accAngle;Use a fixed loop rate from a timer, not millis() differences in a busy loop, and keep MQTT out of that loop entirely. Wilson’s DMP route works too, it just ties you to that chip’s library.
PID: start with P only and raise it until the robot oscillates around upright, then add D until the oscillation dies down, then a small I for drift. And add the motors’ deadband to the output, gear motors don’t move below a few percent duty.
Data: collect samples in the fast loop, decimate to 20 Hz, and send one message per second as an array of records with their own timestamps:
[
{"ts": 1767600000000, "values": {"bal.angle": 0.42, "bal.out": 12.5, "bal.speed": 3.1}},
{"ts": 1767600000050, "values": {"bal.angle": 0.38, "bal.out": 11.9, "bal.speed": 3.0}},
...
]That is 1 message a second with 20 x 3 = 60 data points, inside the per-device defaults (10 messages a second, 200 points a second and 6,000 a minute). Your plan has an organisation-wide data points per minute limit too, so check Usage if other devices are busy. The ESP32 needs NTP time for ts, otherwise leave ts out. A chart over the last 24 hours shows every raw point, so the tuning curves stay sharp. Payload forms: MQTT topics and payload reference.