ciaran55
@ciaranwalsh55 · Mitglied seit Juni 2025
Smart-city engineer · energy
- Themen
- 9
- Antworten
- 68
- Punkte
- 0
Erstellte Forenantworten
Von English mit KI übersetzt ·
Bildschirmabschaltung bewirkt das nicht. Klassisches WLAN-Energiesparen beim Broadcom-Chip des Pi; ich hatte dasselbe mit einem Pi 3B+ in einem Pumpenhaus. Der Pi schläft nicht, das WLAN schon, und eingehende Pakete werden verzögert oder verloren. Dein paho-Client sendet alle 60 s einen Ping, die Antwort kommt nicht rechtzeitig zurück, Hermetry sieht innerhalb des Keepalive nichts und beendet die Sitzung, daher keepalive_timeout. Dein SSH-Zugriff weckt das Funkmodul auf, deshalb kommt dann alles zurück.
Prüfe das:
iw wlan0 get power_save
Power save: onDauerhaft deaktivieren unter Bookworm mit NetworkManager:
sudo tee /etc/NetworkManager/conf.d/wifi-powersave.conf <<EOF
[connection]
wifi.powersave = 2
EOF
sudo systemctl restart NetworkManager(2 bedeutet deaktiviert.) Wenn du ein älteres Image mit dhcpcd verwendest, füge iw wlan0 set power_save off in ein Skript ein, das nach dem Start des Netzwerks läuft.
Sorge außerdem dafür, dass dein Client sich selbst wieder verbindet: client.reconnect_delay_set(1, 120) und loop_forever oder loop_start, damit sich ein kurzer Verbindungsabbruch von selbst behebt.
Screen blanking won’t do it. Classic Wi-Fi power saving on the Pi’s Broadcom chip, I had the same with a Pi 3B+ in a pump house. The Pi doesn’t sleep, the Wi-Fi does, and incoming packets get delayed or lost. Your paho client sends a ping every 60 s, the answer doesn’t come back in time, Hermetry sees nothing within the keepalive and closes the session, hence keepalive_timeout. Your SSH wakes the radio up, which is why everything comes back then.
Check it:
iw wlan0 get power_save
Power save: onTurn it off for good on Bookworm with NetworkManager:
sudo tee /etc/NetworkManager/conf.d/wifi-powersave.conf <<EOF
[connection]
wifi.powersave = 2
EOF
sudo systemctl restart NetworkManager(2 means disabled.) If you’re on an older image with dhcpcd, put iw wlan0 set power_save off in a script that runs after the network is up.
Also make your client reconnect on its own: client.reconnect_delay_set(1, 120) and loop_forever or loop_start, so a short drop fixes itself.
Von English mit KI übersetzt ·
Oder man dreht es um und lässt den Pi nachfragen. Pull ist besser als Push, wenn der Empfänger hinter NAT liegt.
Or turn it around and have the Pi ask. Pull beats push when the receiver is behind NAT.
For real positions you’d want UWB anchors, BLE RSSI jumps around a lot. Pricey though.
Von English mit KI übersetzt ·
Ja, mein Fehler bei Docker, ich habe es mit einer lokalen Node-RED-Box verwechselt, die wir betreiben. Gut zu wissen ist aber der Vertriebsweg für On-Premises trotzdem.
Yeah my bad on the docker bit, I was mixing it up with a local Node-RED box we run. Good to know about the sales route for on-prem though.
That’s typical with those TT motors. No two run at the same speed for the same PWM, the L298N drops a couple of volts differently per channel, the floor and the wheel diameters differ, and all of it changes with battery voltage. A fixed trim only fits one battery level, as you saw. Swapping the motors and still drifting right points at something besides the motors too (wheel diameter, a caster, the floor).
Better motors won’t fix open loop. What fixes it is measuring the wheels: TT motors with encoder discs and slotted optical sensors cost a few pounds. Count ticks on both wheels and correct the PWM so the counts stay equal. A simple proportional correction is enough for a corridor:
from gpiozero import Motor, RotaryEncoder # or DigitalInputDevice per sensor
import time
left, right = Motor(17, 18), Motor(22, 23)
enc_l, enc_r = RotaryEncoder(5, 6), RotaryEncoder(13, 19)
base, kp = 0.7, 0.002
while not arrived():
err = enc_l.steps - enc_r.steps # +: left ahead
left.forward(max(0, min(1, base - kp * err)))
right.forward(max(0, min(1, base + kp * err)))
time.sleep(0.02)If one cheap optical sensor per wheel (no direction) is all you have, count pulses with a DigitalInputDevice callback instead, direction is known anyway. For really straight runs, add an MPU6050 gyro and hold the heading. And if they’re rebuilding, swap the L298N for a TB6612FNG: much smaller voltage drop, so the battery lasts longer too.
While they’re at it, send the encoder counts per trip to Hermetry. A rising left/right difference on the same route is an early sign of a wheel or gearbox going.
Von English mit KI übersetzt ·
Hatte letztes Jahr fast dasselbe Gespräch mit der IT eines Kunden. Ich bin ziemlich sicher, dass man es auf einem eigenen Rechner betreiben kann, irgendwo gibt es doch ein Docker-Image? Zitiert mich bitte nicht dazu, wir nutzen die Cloud-Variante.
Had nearly the same chat with a client’s IT last year. Pretty sure you can run it on your own box, there’s a docker image somewhere? Don’t quote me though, we’re on the cloud one.
Von English mit KI übersetzt ·
Ist der Anlagen-AP tatsächlich auf Kanal 6? Das Mesh muss auf dem Kanal des Routers liegen, wenn der Root als Station arbeitet, sonst wechselt das Funkmodul ständig den Kanal und genau dieser Abbruch und Wiederbeitritt tritt auf.
Is the plant AP actually on channel 6? The mesh has to sit on the router’s channel when the root is a station, otherwise the radio keeps hopping and you get exactly that drop and rejoin.
David’s current sensor is a valid feedback source, but most contactors already have an auxiliary contact block, which is cheaper.
Wire an NO auxiliary contact to a PLC input (or use the current relay if the contactor can’t take an aux block). Then publish both values in the same message, every few seconds, not only on change:
{"sf1.cmd": 0, "sf1.fb": 1}Alarm rule on the profile, in JSON mode since the form only does one comparison per severity:
"severities": [
{ "severity": "MAJOR",
"condition": { "any": [
{ "all": [ { "key": "sf1.cmd", "op": "==", "value": 0 }, { "key": "sf1.fb", "op": "==", "value": 1 } ] },
{ "all": [ { "key": "sf1.cmd", "op": "==", "value": 1 }, { "key": "sf1.fb", "op": "==", "value": 0 } ] } ] } }
],
"debounce": { "mode": "duration", "raise": 5, "clear": 5 }That covers welded (off but running) and failed to pull in (on but stopped). The 5 s duration debounce covers the contactor’s pick-up and drop-out time. Duration debounce only moves forward when readings arrive, so the PLC has to keep reporting; with change-only reporting the alarm would wait for the next change.
Simpler alternative: let the PLC compute a discrepancy bit with its own timer (it needs it for the local interlock anyway) and alarm on sf1.discrepancy == true. Less JSON, one source of truth. Conditions are explained on Alarm conditions reference.