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 retour de terrain : faites de l’ensemble des commandes un état, jamais un basculement. Une commande qui expire signifie seulement qu’aucune réponse n’est revenue, elle a peut-être quand même été exécutée. Si le superviseur renvoie la commande, fan.set on envoyée deux fois est sans effet, tandis que fan.toggle envoyée deux fois éteint le ventilateur.
One thing from the field: make the command set a state, never toggle. A command that times out only means no answer came back, it may have run anyway. If the supervisor presses again, fan.set on twice is harmless, fan.toggle twice turns it off.
Traduit de English par IA ·
Je pensais qu’il existait une option « Envoyer le rapport » sur les tableaux de bord ?
I thought there was a « send report » option on dashboards?
Traduit de English par IA ·
J’exploite une trentaine de ces petites passerelles dans des postes électriques, avec le même schéma.Overlay activé pour le système de fichiers racine, oui. Effectue tes modifications RaspAP avec l’overlay désactivé, redémarre, puis réactive-le. Pénible mais rare.Le tampon a besoin d’un emplacement qui survit aux redémarrages et aux coupures de courant : une seconde partition sur la carte (ou une clé USB) montée en lecture-écriture avec ext4 et son journal, en dehors de l’overlay. Dirige SQLite vers cet emplacement, avec PRAGMA journal_mode=WAL et synchronous=NORMAL. Une coupure ne coûte alors que les dernières écritures au maximum, pas la base. Déplace aussi la persistance de mosquitto vers là, ou désactive-la puisque ton forwarder tamponne déjà.Pour la question de Rachel : oui, si tu horodates chaque mesure avec ts en millisecondes UTC au moment où l’ESP l’envoie (seulement si l’horloge du Pi est synchronisée, ce qui est le cas une fois la 4G active, et garde un fake-hwclock pour ne pas revenir en 1970 après une coupure). Envoie le retard par lots, par enfant :
{"esp-bed3": [{"ts": 1767254400000, "values": {"soil_pct": 41}},
{"ts": 1767254460000, "values": {"soil_pct": 41}}]}Les enregistrements sont placés à leur propre heure dans l’historique. Un message dont tous les enregistrements sont antérieurs d’une minute est compté comme une rejeu et doit respecter le débit de rejeu du profil ; un long retard se résorbe donc progressivement. Ne panique pas si tout n’apparaît pas en une seconde. Et attends le PUBACK avant de supprimer des lignes. Voir Devices behind a gateway.
I run about thirty of these little gateways on substations, same pattern.
Overlay on for the root filesystem, yes. Do your RaspAP changes with the overlay switched off, reboot, switch it back on. Annoying but rare.
The buffer needs a place that survives reboots and power loss: a second partition on the card (or a USB stick) mounted read-write with ext4 and its journal, outside the overlay. Point SQLite there, with PRAGMA journal_mode=WAL and synchronous=NORMAL. A cut then costs you at most the last few writes, not the database. Move mosquitto’s persistence there too, or turn persistence off since your forwarder already buffers.
On Rachel’s question: yes, if you stamp each reading with ts in UTC milliseconds when the ESP sends it (only if the Pi’s clock is synced, which it is once 4G is up, and keep a fake-hwclock so it isn’t 1970 after a power cut). Send the backlog in batches per child:
{"esp-bed3": [{"ts": 1767254400000, "values": {"soil_pct": 41}},
{"ts": 1767254460000, "values": {"soil_pct": 41}}]}Records land at their own time in history. A message whose every record is older than a minute counts as a replay and has to fit the profile’s replay rate, so a long backlog drains over a while. Don’t panic when it doesn’t all appear in one second. And wait for the PUBACK before deleting rows. See Devices behind a gateway.
Traduit de English par IA ·
Voilà, c’est donc ça. Un Pi 3 n’a pas d’horloge temps réel. Au démarrage, il restaure l’heure enregistrée lors de l’extinction propre précédente (fake-hwclock), puis attend NTP. Votre réseau de laboratoire bloque NTP (UDP 123), donc l’horloge reste dans le passé et, pour la bibliothèque TLS, le certificat du serveur n’est pas encore valide. J’ai vu cela sur la moitié des Pi déployés que j’ai mis en service derrière des pare-feu verrouillés.Solutions, à choisir :
# 1. demander à l'informatique le serveur NTP interne et l'utiliser
sudo nano /etc/systemd/timesyncd.conf
[Time]
NTP=ntp.your-lab.example
sudo systemctl restart systemd-timesyncd
timedatectl # "System clock synchronized: yes"
# 2. si seul le port 443 est ouvert : synchroniser via les en-têtes HTTPS
sudo apt install htpdate
sudo htpdate -s https://www.example.orgSupprimez l’IP codée en dur. Le broker nécessite SNI, il faut donc se connecter par nom d’hôte ; le certificat est de toute façon vérifié par rapport à ce nom, ce qui explique la non-correspondance. Un simple client.tls_set() avec le bundle de CA du système convient ; Tyler, aucun certificat client n’est nécessaire pour les connexions par jeton, le serveur en demande un mais ne l’exige pas.Faites aussi attendre au script une horloge synchronisée avant de se connecter, sinon un redémarrage au laboratoire le fera à nouveau échouer. Une boucle simple sur timedatectl show -p NTPSynchronized fonctionne. Voir la section TLS de MQTT.
That’s it then. A Pi 3 has no real time clock. At boot it restores the time it saved at the last clean shutdown (fake-hwclock) and then waits for NTP. Your lab network blocks NTP (UDP 123), so the clock stays in the past, and to the TLS library the server certificate isn’t valid yet. Seen this on half the field Pis I’ve commissioned behind locked-down firewalls.
Fixes, pick one:
# 1. ask IT for the internal NTP server and use it
sudo nano /etc/systemd/timesyncd.conf
[Time]
NTP=ntp.your-lab.example
sudo systemctl restart systemd-timesyncd
timedatectl # "System clock synchronized: yes"
# 2. if only 443 is open: sync from HTTPS headers
sudo apt install htpdate
sudo htpdate -s https://www.example.orgUndo the hardcoded IP. The broker needs SNI, so connect by host name, and the certificate is checked against that name anyway, which is why you got the mismatch. Plain client.tls_set() with the system CA bundle is fine; Tyler, no client certificate is needed for token logins, the server asks for one but doesn’t require it.
Also make the script wait for a synced clock before connecting, otherwise a reboot in the lab breaks it again. A quick loop on timedatectl show -p NTPSynchronized works. See the TLS section of MQTT.
On the bench both power supplies share mains earth, so the « isolated » sides are probably closer to each other than you think through supply capacitance.