si_tyler
@twilson · Membre depuis mars 2026
System integrator · energy · 15 years in the field
- Sujets
- 3
- Réponses
- 20
- Points
- 0
Toutes mes réponses sur les forums
Traduit de English par IA ·
Un VPN est exactement la discussion que j’essaie d’éviter. Leur équipe de sécurité traite tout tunnel vers leur réseau comme un nouveau projet soumis à un examen de 3 mois.
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.
Traduit de English par IA ·
La solution la plus simple : ne redémarre pas le script. Lance-le comme service systemd avec Restart=always, ouvre le port une seule fois et ne le ferme jamais.
Easiest fix: don’t restart the script. Run it as a systemd service with Restart=always, open the port once and never close it.
Traduit de English par IA ·
C’était l’adaptateur. Informations système n’affichait rien via mon dongle USB-C sans marque ; via un hub alimenté, « USBasp » apparaît et avrdude le trouve. J’ai flashé quatre cartes sur site hier : la carte de rechange toute neuve avait besoin de -B 32, exactement comme l’a dit tsmith. Les fusibles étaient déjà configurés sur les autres. Le portable Linux reste maintenant à l’atelier.
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 ».
Traduit de English par IA ·
Bien vu. Il vaut mieux placer l’hôte dans un fichier de configuration plutôt que dans le build, afin que la prochaine usine ne copie pas un hôte codé en dur.
Good catch. Worth putting the host in a config file instead of the build, so the next plant doesn’t copy a hardcoded host.
Traduit de English par IA ·
Même erreur avec l’avrdude de l’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.
Traduit de English par IA ·
Pour les onduleurs, vérifiez s’ils proposent les tables SunSpec Modbus, cela vous évite d’écrire une table de registres pour chaque modèle.
For the inverters check if they do SunSpec Modbus maps, saves you writing a register map per model.
Traduit de English par IA ·
Pour la mise à l’échelle, vous pouvez envoyer les mA bruts et laisser un bloc Scale dans le flux racine de Hermetry convertir 4-20 en 0-10 bar. Vous pourrez ainsi corriger la plage plus tard sans toucher au 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.
Traduit de English par IA ·
Kevin a raison, et ce n’est que la moitié de la réponse. Nous avons rencontré le même problème sur un site éolien.Le MQTT de Hermetry est en 3.1.1, et un CONNECT avec clean session à false est traité comme clean. Rien n’est mis en file d’attente pour un appareil hors ligne, sauf les commandes envoyées en mode persistant. Il n’y a donc aucun état de session à reprendre, dans aucun sens pour la télémétrie.Ce que Hermetry garantit concerne le sens entrant : le PUBACK n’est envoyé qu’une fois le message mis en file d’attente de manière sûre de leur côté. Si le message ne peut pas être mis en file, vous ne recevez pas de PUBACK, la session se ferme, et le client doit renvoyer le message après reconnexion. Les doublons portant le même appareil, la même clé et le même horodatage ne sont stockés qu’une fois, donc renvoyer est sans risque.Le tampon est donc de votre ressort, et le schéma est le suivant :
- Écrire chaque mesure dans un stockage local (nous utilisons un fichier SQLite) avec son propre ts en ms.
- Publier depuis le stockage, et ne supprimer une ligne que lorsque son PUBACK arrive.
- Après reconnexion : s’abonner, demander les attributs partagés, puis envoyer le retard avant les données en direct.
Envoyez le retard sous forme de tableaux {ts, values} pour qu’il arrive aux bons moments. Le profil dispose d’une limite distincte, Messages de relecture par seconde, pour les messages dont tous les enregistrements datent de plus d’une minute, donc un long retard se résorbe progressivement. Ne paniquez pas si tout n’apparaît pas d’un coup.La page MQTT contient la section sur les accusés de réception, à lire une fois.
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.