ciaran55
@ciaranwalsh55 · Haziran 2025 tarihinde katıldı
Smart-city engineer · energy
- Konular
- 9
- Yanıtlar
- 68
- Puan
- 0
Oluşturulan forum yanıtları
Yapay zekâ tarafından English dilinden çevrildi ·
Ekran kararması bunu yapmaz. Pi’nin Broadcom çipinde klasik Wi-Fi güç tasarrufu var; bir pompa odasındaki Pi 3B+ ile aynı sorunu yaşamıştım. Pi uyumuyor, Wi-Fi uyuyor ve gelen paketler gecikiyor ya da kayboluyor. paho istemcin her 60 sn’de bir ping gönderiyor, yanıt zamanında dönmüyor, Hermetry keepalive süresi içinde hiçbir şey görmüyor ve oturumu kapatıyor; bu yüzden keepalive_timeout. SSH bağlantın radyoyu uyandırıyor, bu yüzden her şey o anda geri geliyor.
Kontrol et:
iw wlan0 get power_save
Power save: onBookworm’da NetworkManager ile kalıcı olarak kapatmak için:
sudo tee /etc/NetworkManager/conf.d/wifi-powersave.conf <<EOF
[connection]
wifi.powersave = 2
EOF
sudo systemctl restart NetworkManager(2 kapalı anlamına gelir.) dhcpcd kullanan eski bir imajdaysan, iw wlan0 set power_save off komutunu ağ ayağa kalktıktan sonra çalışan bir betiğe koy.
Ayrıca istemcinin kendi kendine yeniden bağlanmasını sağla: client.reconnect_delay_set(1, 120) ve loop_forever ya da loop_start kullan; böylece kısa bir kopma kendiliğinden düzelir.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Ya da işi tersine çevirip Pi’nin sorgulamasını sağlayın. Alıcı NAT arkasında olduğunda pull yöntemi push yönteminden daha iyidir.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Evet, Docker konusundaki hatam için özür dilerim; işletmekte olduğumuz yerel Node-RED kutusuyla karıştırmışım. Yine de on-prem kurulumlar için satış yolunu öğrenmek iyi oldu.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Geçen yıl bir müşterinin BT ekibiyle neredeyse aynı sohbeti yapmıştım. Kendi sunucunuzda çalıştırabileceğinize oldukça eminim, bir yerde bir docker image’ı var, değil mi? Ama bunu bana atfetmeyin, biz bulut sürümünü kullanıyoruz.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Tesisin AP’si gerçekten 6. kanalda mı? Kök bir istemci (station) olduğunda mesh’in yönlendiricinin kanalında kalması gerekir; aksi halde radyo sürekli atlar ve tam olarak bu kopma ve yeniden bağlanma sorunu yaşanır.
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.