thompsonplc
@lthompson · Mayıs 2025 tarihinde katıldı
Automation engineer · pharma · 14 years in the field
- Konular
- 7
- Yanıtlar
- 65
- Puan
- 0
Oluşturulan forum yanıtları
The readings stored before the fix keep the wrong value, so if that night matters, export it and correct it by hand.
Yapay zekâ tarafından English dilinden çevrildi ·
Firmware içinde cihaz başına token’a hiç ihtiyacınız yok. Sorunu iki parçaya ayırın.Wi-Fi: WiFiManager’ı koruyun. Dostça bir cihaz adı istiyorsanız portala bir özel alan ekleyin; aksi halde MAC adresini kullanın.Token: Düğümün kendi token’ını talep etmesine izin verin. Cihaz profilinde Provisioning sekmesini açın, stratejiyi Allow creating new devices olarak ayarlayın, kaydedin, ardından Create key seçeneğine tıklayıp secret değerini kopyalayın (yalnızca bir kez gösterilir). Bu anahtar ve secret, 12 derlemenin hepsinde aynıdır. İlk açılışta düğüm, kullanıcı adı provision ve boş parola ile bağlanır, v1/provision/res konusuna abone olur ve isteğini yayınlar. Yanıt kendi erişim token’ını taşır; bunu NVS’e kaydedersiniz ve bundan sonra normal şekilde giriş yapar.
// first boot only, after Wi-Fi is up
mqtt.setServer(host, 8883); // WiFiClientSecure, TLS
mqtt.connect(clientId, "provision", "");
mqtt.subscribe("v1/provision/res", 1);
String req = String("{"deviceName":"aq-") + mac6 +
"","provisionDeviceKey":"pk_xxx","provisionDeviceSecret":"ps_xxx"}";
mqtt.publish("v1/provision/req", req.c_str());
// in the callback: parse credentialsValue when status == "SUCCESS",
// prefs.putString("tok", value); then reconnect with the token as username
Bir eczane tesisinde iki sorunla karşılaştık. Bu yolla oluşturulan yeni cihazlar karantinaya düşer; bağlanırlar ama bir yönetici etkinleştirene kadar verileri atılır, bu yüzden kuruluşun sahibine onları aramasını söyleyin. Ayrıca ad benzersiz olmalıdır; aynı adla ikinci bir istek device_exists hatası alır, çünkü sistem aynı kimlik bilgisini iki kez vermez. Bu nedenle NVS’i gelişigüzel silmeyin. Ayrıntılar Adding and claiming devices sayfasında.
You don’t need per-device tokens in the firmware at all. Split it in two problems.
Wi-Fi: keep WiFiManager. Add one custom field in the portal if you want a friendly device name, otherwise use the MAC.
Token: let the node ask for its own. On the device profile open the Provisioning tab, set the strategy to Allow creating new devices, save, then Create key and copy the secret (it’s shown once). That key + secret is the same for all 12 builds. On first boot the node connects with username provision and an empty password, subscribes to v1/provision/res and publishes its request. The answer carries its access token, you store that in NVS and from then on it logs in normally.
// first boot only, after Wi-Fi is up
mqtt.setServer(host, 8883); // WiFiClientSecure, TLS
mqtt.connect(clientId, "provision", "");
mqtt.subscribe("v1/provision/res", 1);
String req = String("{"deviceName":"aq-") + mac6 +
"","provisionDeviceKey":"pk_xxx","provisionDeviceSecret":"ps_xxx"}";
mqtt.publish("v1/provision/req", req.c_str());
// in the callback: parse credentialsValue when status == "SUCCESS",
// prefs.putString("tok", value); then reconnect with the token as username
Two things bit us on a pharma site. New devices created this way land in quarantine, they connect but their data is dropped until an admin activates them, so tell whoever owns the org to look for them. And the name must be unique, a second request with the same name gets device_exists because it never hands out a credential twice. So never wipe NVS casually. Details are on Adding and claiming devices.
Yapay zekâ tarafından English dilinden çevrildi ·
Kstewart anladı. Bir kat yukarıdaki QA laboratuvarında, QA ekibi tarafından organizasyonumuzda kayıtlı bir Basics Station gateway var. Benim “aralıklı” çerçevelerimi o aldı; geliştirme kit kartım tek bir çerçeveyi bile iletmedi. Test tezgahı için ödünç aldım, tek kanallı kartı ve kanal hilesini kaldırdım. İlk seferde katılıyor, sekiz kanalın tümünde her 60 s’de bir uplink gönderiyor. Kayıt için not düşeyim, 868.1 numarası bu arada işe yaradı.
Kstewart got it. There is a Basics Station gateway in the QA lab on the floor above, registered in our org by the QA team. That’s what heard my “sporadic” frames, my dev kit board never forwarded a single one. Borrowed it for the bench, removed the single-channel board, removed the channel hack. Joins first time, uplinks every 60 s on all eight channels. The 868.1 trick did work in between, for the record.
Yapay zekâ tarafından English dilinden çevrildi ·
Aoife, maalesef Pi’nin derin uyku modu yok. Bu bir Linux kutusu, ya çalışıyor ya da kapalı. Bu yüzden kesebildiğin her şeyi kes ve radyoyu daha az çalıştır.Yapacaklarım, kazanç sırasına göre:
- Pi: config.txt içinde
dtoverlay=disable-wifivedtoverlay=disable-bt, HDMI kapalı (eski imajlardatvservice -o), etkinlik LED’i kapalı. Zero’da bu sayede yaklaşık 80 mA’ya inersin. - GPS: konum alımları arasında GNSS motorunu kapat (
AT+CGPS=0, ardından tekrarAT+CGPS=1). SIM7600’de sıcak başlatma birkaç saniye sürer. - Hız: hareket halindeyken 30 sn, park halindeyken 15 ila 60 dakika. Karar vermek için hızı veya son konumdan olan mesafeyi kullan.
- Toplu gönderim: konumları tampona al ve her birkaç dakikada bir, ts içeren bir dizi olarak tek mesaj gönder. GPS doğru bir saat sağladığı için zaman damgaları güvenilirdir. On ayrı HTTPS çağrısı yerine tek çağrı daha az radyo süresi demektir ve aylık kotadan on yerine bir mesaj harcar.
[{"ts": 1757683200000, "values": {"lat": 52.95231, "lon": -1.14972, "speed_kmh": 31.5}},
{"ts": 1757683230000, "values": {"lat": 52.95410, "lon": -1.14701, "speed_kmh": 33.0}}]
Cihaz yalnızca birkaç dakikada bir veri gönderdiği için, profilinin çevrimiçi kuralını park oranına uyan beklenen aralıkla Recent message olarak ayarla; aksi halde gece boyunca çevrimdışı görünür.Bir hafta kesin bir gereksinimse, dürüst cevap, uyuyup modemi uyandıran bir mikrodenetleyici (ESP32 veya nRF) ya da çalışmalar arasında tüm Pi’nin gücünü kesen TPL5110 gibi bir zamanlayıcı çipidir. 80 mA’da boşta çalışan bir Linux kartı, 10 Ah ile bunu asla başaramaz.
Aoife, the Pi has no deep sleep, sadly. It’s a Linux box, it’s either running or off. So you cut everything you can and make the radio work less.
What I’d do, in order of payoff:
- Pi:
dtoverlay=disable-wifianddtoverlay=disable-btin config.txt, HDMI off (tvservice -oon older images), activity LED off. On a Zero that gets you to roughly 80 mA. - GPS: switch the GNSS engine off between fixes (
AT+CGPS=0, thenAT+CGPS=1again). A warm start on the SIM7600 is a few seconds. - Rate: 30 s while moving, 15 to 60 min while parked. Use speed or the distance from the last fix to decide.
- Batch: buffer fixes and send one message every few minutes as an array with ts. GPS gives you a correct clock, so the timestamps are trustworthy. One HTTPS call instead of ten is less radio time, and it costs one message out of the monthly quota instead of ten.
[{"ts": 1757683200000, "values": {"lat": 52.95231, "lon": -1.14972, "speed_kmh": 31.5}},
{"ts": 1757683230000, "values": {"lat": 52.95410, "lon": -1.14701, "speed_kmh": 33.0}}]
Because the device only talks every few minutes, set its profile’s online rule to Recent message with an expected interval that matches your parked rate, otherwise it shows offline all night.
If a week is a hard requirement, the honest answer is a microcontroller (ESP32 or nRF) that sleeps and wakes the modem, or a timer chip like a TPL5110 that cuts power to the whole Pi between runs. A Linux board idling at 80 mA will never get there on 10 Ah.
No register trick, I’m afraid. As far as I remember the sleep mode table in the 328P datasheet, the analog comparator is only a wake source in idle (and ADC noise reduction), not power-down. In power-down only the external interrupts, pin change, TWI address match and the watchdog wake it. Your idle current is the clocks running.
Move the comparator outside. A nanopower comparator with push-pull output into INT0 (D2) lets the 328P sit in power-down at a few µA. TLV3691 draws about 75 nA, and the reference can be a micropower 2.5 V shunt. Add hysteresis with a resistor from output to the + input, a few hundred mV at the battery side, otherwise a battery hovering at 11.8 V will wake you a hundred times a night as the load changes.
attachInterrupt(digitalPinToInterrupt(2), wake, FALLING);
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_enable(); sleep_cpu(); // wakes on INT0 only
// on wake: read ADC once for the real value, send it, sleep again
Aoife: you can use the bandgap internally, but the comparator itself still can’t wake power-down, so it doesn’t help here.
On the Hermetry side I’d still send a heartbeat once a day with the voltage. Then an offline alarm on the profile tells you a sensor died, which a wake-only design never would. Put the low-voltage alarm rule on bat_v with some hysteresis too.
Monitor was on “Newline”. Both NL & CR and NAME and UART went through at once. Kevin, the baud was fine, AT mode is always 38400 on these.
Yapay zekâ tarafından English dilinden çevrildi ·
Bunu bir eğitim düzeneği için bir grup SG90 üzerinde yaptım. Modifikasyon:
1. Kasayı açın, çıkış dişlisini çıkarın. Alt yüzündeki, bitiş durdurucusuna çarpan küçük plastik çıkıntıyı kesin ya da törpüleyin.
2. Çıkış milinin altındaki potansiyometre konum geri beslemesidir. Lehimini sökün ve yerine sabit bir gerilim bölücü olarak iki adet 2.2k direnç takın (uçları dış pedlere, orta ucu sürgü pedine bağlayın). Servo artık her zaman merkezde olduğunu düşünür.
3. Yeniden birleştirin. Artık darbe genişliği konum yerine hızı ve yönü belirler: yaklaşık 1.5 ms durdurur, daha kısa değerler bir yöne, daha uzun değerler diğer yöne döndürür. Tam durma değerini deneyerek bulun, direnç toleransı bu değeri kaydırır.
İkinci sorunuza gelince: hayır, FS90R’de olduğu gibi artık konumunu bilmiyor. Bir panjur için bu önemlidir, bu yüzden Keisha’nın dediğini yapın; tamamen açık ve tamamen kapalı konumlara bir reed anahtarı ya da mikro anahtar ekleyin ve aradaki süreyi sayın ya da araya ucuz bir enkoder ekleyin. Açıkçası SG90 gerçek bir panjur için de zayıftır; 28BYJ-48 step motor ile ULN2003 kartı size konumu bedavaya ve daha fazla tork ile verir.
Kart tarafında: ESP32’nin profilindeki Commands sekmesine, Basic seviyesinde, 0-100 aralığında bir Number parametreli blind.set ekleyin. Kaydırıcı değeri, sürüklerken değil bırakıldığında bir kez gönderir; bu da bir motor için uygundur. ESP32’nin gerçek konumunu blind_pct olarak yayınlamasını sağlayın ve Kaydırıcının Current value alanını buna bağlayın; böylece kart panjurun gerçekte nerede olduğunu gösterir.
Servoyu ya da step motoru ESP32’nin pininden değil, kendi 5 V kaynağından besleyin.
Did this to a pile of SG90s for a teaching rig. The mod:
1. Open the case, take out the output gear. Cut or file off the little plastic tab on its underside that hits the end stop.
2. The potentiometer under the output shaft is the position feedback. Unsolder it and put two 2.2k resistors in its place as a fixed divider (ends to the outer pads, the middle to the wiper pad). The servo now always thinks it’s at centre.
3. Reassemble. Now the pulse width sets speed and direction instead of position: about 1.5 ms stops it, shorter turns one way, longer the other. Find the exact stop value by trial, resistor tolerance shifts it.
To your second question: no, it no longer knows where it is, same as an FS90R. For a blind that matters, so do what Keisha said, add a reed switch or microswitch at fully open and fully closed, and count time or add a cheap encoder in between. Honestly, an SG90 is also weak for a real blind, a 28BYJ-48 stepper with a ULN2003 board gives you position for free and more torque.
On the board side: add blind.set with a Number parameter 0-100 to the ESP32’s profile Commands tab, Basic tier. The Slider sends the value once on release, not while you drag, which suits a motor. Have the ESP32 publish its real position as blind_pct and bind the Slider’s Current value to it, so the card shows where the blind actually is.
Power the servo or stepper from its own 5 V supply, not the ESP32’s pin.
USB-RS485 with auto direction plus 680 R bias resistors at the Pi end: zero CRC errors over 10,000 polls. Children show up in Hermetry as mixer-11 to mixer-16. Ciaran, thanks.
120 R at both ends. No bias resistors anywhere, I’d assumed the PIC boards had them.
Yapay zekâ tarafından English dilinden çevrildi ·
Geçen yıl bir yüklenici için benzer bir tasarımı inceledim, bu yüzden raporda kullanmak üzere gerekçeyi buraya yazıyorum.Genel bilgiyi gizli bilgiden ayırın. CA paketi herkese açıktır; sunucu sertifikası da herkese açık bir sertifikadır ve normal bir CA paketiyle doğrulanır, dolayısıyla onu kartta tutmak sorun değil. WiFi parolası ve cihaz belirteci ise sırdır, çünkü tam olarak bu cihazı tanımlarlar.Çıkarılabilir bellekteki sırlar iki nedenle başarısız olur: onları kaldırmak hiçbir iz bırakmaz ve kart genellikle başka kartlara kopyalanır (“sadece kartı klonla”), bu durumda birden fazla cihaz aynı kimlik bilgisini paylaşır. Hermetry cihaz başına tek oturuma izin verir; yani aynı belirteci taşıyan iki kart birbirini sürekli düşürür ve cihazın Log sekmesinde ele geçirme görürsünüz.X.509 konusunda: kendi kartlarınız için kullanılamaz. İstemci sertifikaları Hermetry’nin cihaz sertifika yetkilisinden gelmelidir; üçüncü taraf cihazlar için kendi CA’nızı yüklemek sunulmaz. Bu yol, anahtarını kendisi üretip CSR’yi kendisi gönderen lisanslı cihazlar içindir. ESP32’niz bir erişim belirteci veya MQTT basic kullanır.ESP32 için yapacaklarım:1. Her kart için aynı ikili dosya uygundur. Belirteci, ilk açılışta küçük bir seri komutla sağlama sırasında NVS’e koyun, karta değil.2. Flash şifrelemeyi ve NVS şifrelemeyi açın, böylece flash dökümü belirteci ele vermez.3. Kart yalnızca veri kaydı ve CA paketi için kullanılsın.4. Hermetry’de her kart için bir cihaz ve bir belirteç tanımlayın; bir kart kaybolursa sırrı yenileyin. Bu, o kartın oturumlarını hemen sonlandırır.Sertifika kısıtı Device certificates sayfasının son bölümünde.
Did a review of a similar design for a contractor last year, so here’s the reasoning for the report.
Separate public stuff from secret stuff. The CA bundle is public; the server certificate is a public one and you verify it with a normal CA bundle, so keeping that on the card is fine. WiFi password and the device token are secrets, they identify this exact device.
Secrets on removable media fail on two counts: removing them leaves no trace, and the card usually gets copied into other boards (“just clone the card”), and then you have several devices sharing one credential. Hermetry allows one session per device, so two boards with the same token keep kicking each other off, and you’d see takeover in the device’s Log tab.
On X.509: for your own boards it’s not available. Client certificates must come from Hermetry’s device certificate authority, and uploading your own CA for third-party devices is not offered; that path is for licensed devices that generate their key and send a CSR themselves. Your ESP32 uses an access token or MQTT basic.
What I’d do on an ESP32:
1. Same binary for every board is fine. Put the token in NVS at provisioning (a small serial command on first boot), not on the card.
2. Turn on flash encryption and NVS encryption, so a flash dump does not give up the token.
3. Card only for data logging and the CA bundle.
4. In Hermetry, one device and one token per board; rotate the secret if a board goes missing. That ends its sessions at once.
The certificate limitation is on Device certificates, last section.
The pH jumping with the EC probe in is a ground loop. Both EZO circuits share the Pi’s ground and the EC probe drives current through the water, which shifts the pH reference. Atlas sells an isolated carrier board for exactly this, put at least one of the two on it.
Yapay zekâ tarafından English dilinden çevrildi ·
Yalnızca telefon ile baz istasyonu arasında, ve 2G’nin buradaki koruması zayıf; bu yüzden van numarası işe yarıyor. Operatörün çekirdek ağından sonra ise düz internet trafiği var. Radyo bağlantısını güvenilmez kabul edin.
Only between the phone and the tower, and 2G’s version of it is weak, which is why the van trick works. After the operator’s core it’s plain internet. Treat the radio as untrusted.
Until something like that exists, do the zone decision on the robot. That’s also what the personnel tracking solution expects: the tracker or its gateway reports the zone name, and Hermetry’s rules work on that. I run exactly this for carts in a warehouse, ESP32 scanning fixed BLE tags.
every 2 s: scan 1.5 s, keep RSSI per known tag (EMA, alpha 0.3)
best = tag with highest smoothed RSSI
switch zone only if best beats the current zone's tag by 6 dB
for 3 scans in a row (stops flapping at borders)
publish on change and every 60 s:
{"zone": "F3-east", "zone_id": 32, "zone_rssi": -71}
Send both: zone as text for tables and the alarm, zone_id as a number because text keys have no chart history and you’ll want “where was it at 14:00”.
For the kitchen corridor: give each cleaner a server attribute forbiddenZone = “F0-kitchen” and an alarm rule on the robot profile where zone equals that attribute. Per-device thresholds from attributes work for text too with ==. Same pattern the tracking solution uses, described on Personnel tracking.
Polygons: no workaround on the map that I know of. Map the polygon to tag zones instead, one zone per forbidden area.
Yapay zekâ tarafından English dilinden çevrildi ·
İyi. Yine de o Edison için bir yedek planlayın; yıllardır üretimi durdurulmuş durumda ve yedek parça bulmak giderek zorlaşıyor.
Good. Plan a replacement for that Edison though, it’s been out of production for years and spares get harder to find.
Aoife has the core of it.
Cutting the solenoid only puts the directional valve into its rest position. Depending on the valve type that can trap air in the cylinder (closed-centre 5/3 valves do exactly that), so the cylinder can still move when someone opens a fitting, or hold a load that drops later. A stuck valve spool is the other failure: power off, valve doesn’t move. Pneumatic energy is stored energy, and for safe access you want it gone, not held. The dump valve exhausts the supply to atmosphere so the cell ends up at zero pressure. The safety relay usually also monitors the dump valve’s feedback (a pressure switch or a position contact), so a dump valve that fails to vent stops the cell from restarting. The two parts cover different failures. How much of this you need follows from the risk assessment and the required performance level under ISO 13849, which is your engineer’s job to document.
On Hermetry Safe: there’s no doc page for it, so I won’t guess what it does. Whatever it does, I would never put a cloud platform into the safety function itself. Even the personnel tracking page calls that solution an information tool, not a certified safety system. Emergency stop, safety relay and dump valve stay hardwired.
What works today and is useful: monitoring. Wire the safety relay’s auxiliary contact and the dump valve’s pressure switch into the cell PLC or a gateway and send them as telemetry, say estop.active and dump.vented. Then an alarm rule can tell maintenance when the e-stop has been active for a long time, or when the e-stop is active and dump.vented is still 0. That gives you records and notifications without touching the safety chain.

