thompsonplc
@lthompson · Mitglied seit Mai 2025
Automation engineer · pharma · 14 years in the field
- Themen
- 7
- Antworten
- 65
- Punkte
- 0
Erstellte Forenantworten
The readings stored before the fix keep the wrong value, so if that night matters, export it and correct it by hand.
Von English mit KI übersetzt ·
Du brauchst im Firmware-Code überhaupt keine Tokens pro Gerät. Teile das Problem in zwei Teile.WLAN: Behalte WiFiManager bei. Wenn du einen gut lesbaren Gerätenamen möchtest, füge im Portal ein benutzerdefiniertes Feld hinzu, andernfalls verwende die MAC.Token: Lass den Knoten sein eigenes anfordern. Öffne im Geräteprofil den Reiter Provisioning, setze die Strategie auf Allow creating new devices, speichere, klicke dann auf Create key und kopiere das Secret (es wird nur einmal angezeigt). Dieser Schlüssel mit Secret ist für alle 12 Builds gleich. Beim ersten Start verbindet sich der Knoten mit dem Benutzernamen provision und einem leeren Passwort, abonniert v1/provision/res und veröffentlicht seine Anfrage. Die Antwort enthält sein Zugriffstoken; du speicherst es im NVS, und ab dann meldet sich der Knoten normal an.
// 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
Zwei Dinge haben uns auf einer Pharma-Anlage erwischt. Neue Geräte, die so angelegt werden, landen in Quarantäne: Sie verbinden sich, aber ihre Daten werden verworfen, bis ein Administrator sie aktiviert. Sag deshalb dem Verantwortlichen der Organisation, dass er nach ihnen suchen soll. Außerdem muss der Name eindeutig sein; eine zweite Anfrage mit demselben Namen erhält device_exists, weil nie zweimal eine Zugangsdaten ausgegeben wird. Lösche den NVS deshalb nicht leichtfertig. Details stehen unter Adding and claiming devices.
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.
Von English mit KI übersetzt ·
Kstewart hat recht gehabt. Im QA-Labor eine Etage darüber gibt es ein Basics-Station-Gateway, das vom QA-Team in unserer Organisation registriert wurde. Das hat meine „sporadischen“ Frames empfangen, mein Entwicklungs-Kit hat nicht einen einzigen weitergeleitet. Ich habe es für den Bench-Test ausgeliehen, die Einkanal-Platine und den Kanal-Hack entfernt. Der Join klappt beim ersten Versuch, Uplinks alle 60 s auf allen acht Kanälen. Der 868.1-Trick hat übrigens zwischendurch funktioniert, der Vollständigkeit halber.
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.
Von English mit KI übersetzt ·
Aoife, der Pi hat leider keinen Tiefschlafmodus. Es ist ein Linux-Rechner, er läuft entweder oder er ist aus. Also schaltest du alles ab, was du kannst, und lässt das Funkmodul weniger arbeiten.Das würde ich tun, nach dem Nutzen geordnet:
- Pi:
dtoverlay=disable-wifiunddtoverlay=disable-btin config.txt, HDMI aus (tvservice -obei älteren Images), Aktivitäts-LED aus. Auf einem Zero kommst du damit auf etwa 80 mA. - GPS: die GNSS-Engine zwischen den Fixes abschalten (
AT+CGPS=0, dann wiederAT+CGPS=1). Ein Warmstart am SIM7600 dauert wenige Sekunden. - Rate: 30 s während der Fahrt, 15 bis 60 min im Stand. Entscheide anhand der Geschwindigkeit oder der Distanz zum letzten Fix.
- Batch: Fixes puffern und alle paar Minuten eine Nachricht als Array mit ts senden. GPS liefert eine korrekte Uhrzeit, daher sind die Zeitstempel verlässlich. Ein HTTPS-Aufruf statt zehn bedeutet weniger Funkzeit und kostet eine Nachricht des Monatskontingents statt zehn.
[{"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}}]Da das Gerät nur alle paar Minuten sendet, stelle die Online-Regel des Profils auf Recent message mit einem erwarteten Intervall, das zu deiner Standzeit-Rate passt. Sonst wird es die ganze Nacht als offline angezeigt.Wenn eine Woche eine harte Anforderung ist, lautet die ehrliche Antwort: ein Mikrocontroller (ESP32 oder nRF), der schläft und das Modem aufweckt, oder ein Timer-Chip wie ein TPL5110, der zwischen den Läufen die gesamte Stromversorgung des Pi abschaltet. Eine Linux-Platine, die mit 80 mA im Leerlauf läuft, schafft das mit 10 Ah nie.
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 againAoife: 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.
Von English mit KI übersetzt ·
Das habe ich bei einem Haufen SG90 für einen Lehraufbau gemacht. Die Modifikation:
1. Gehäuse öffnen, Abtriebszahnrad herausnehmen. Den kleinen Kunststoffnocken auf der Unterseite, der am Endanschlag aufschlägt, abschneiden oder abfeilen.
2. Das Potentiometer unter der Abtriebswelle ist die Positionsrückmeldung. Auslöten und an seiner Stelle zwei 2,2-kΩ-Widerstände als feste Spannungsteiler einsetzen (Enden an die äußeren Pads, die Mitte an das Schleiferpad). Der Servo glaubt jetzt immer, er stehe in der Mitte.
3. Wieder zusammenbauen. Jetzt bestimmt die Pulsbreite Geschwindigkeit und Richtung statt Position: etwa 1,5 ms stoppen ihn, kürzer dreht in eine Richtung, länger in die andere. Den genauen Stoppwert durch Ausprobieren finden, die Widertoleranz verschiebt ihn.
Zu deiner zweiten Frage: Nein, er weiß nicht mehr, wo er steht, genau wie ein FS90R. Bei einem Rollladen ist das wichtig, also mach, was Keisha gesagt hat: einen Reedkontakt oder Mikroschalter bei ganz offen und ganz geschlossen anbringen und die Zeit zählen oder dazwischen einen günstigen Encoder einbauen. Ehrlich gesagt ist ein SG90 auch schwach für einen echten Rollladen. Ein 28BYJ-48-Schrittmotor mit ULN2003-Platine liefert dir die Position gratis und mehr Drehmoment.
Auf der Board-Seite: Füge blind.set mit einem Number-Parameter 0-100 im Commands-Tab des ESP32-Profils hinzu, Basic-Stufe. Der Slider sendet den Wert einmal beim Loslassen, nicht während du ziehst, was für einen Motor passt. Lass den ESP32 seine tatsächliche Position als blind_pct veröffentlichen und binde den Current value des Sliders daran, damit die Karte zeigt, wo der Rollladen wirklich steht.
Versorge den Servo oder Schrittmotor aus einem eigenen 5-V-Netzteil, nicht über den Pin des ESP32.
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.
Von English mit KI übersetzt ·
Ich habe letztes Jahr für einen Auftragnehmer ein ähnliches Design geprüft, daher hier die Begründung für den Bericht.Trenne öffentliche von geheimen Daten. Das CA-Bundle ist öffentlich; das Serverzertifikat ist ein öffentliches Zertifikat, das mit einem normalen CA-Bundle geprüft wird, daher ist es unbedenklich, es auf der Karte zu speichern. WLAN-Passwort und Geräte-Token sind Geheimnisse, denn sie identifizieren genau dieses Gerät.Geheimnisse auf Wechselmedien scheitern aus zwei Gründen: Beim Entfernen bleibt keine Spur zurück, und die Karte wird häufig auf andere Boards kopiert („klon einfach die Karte“), sodass mehrere Geräte dieselbe Zugangsdaten teilen. Hermetry erlaubt pro Gerät nur eine Sitzung; zwei Boards mit demselben Token werfen sich daher ständig gegenseitig heraus, und du würdest eine Übernahme im Log-Tab des Geräts sehen.Zu X.509: Für eigene Boards ist das nicht verfügbar. Client-Zertifikate müssen von der Geräte-Zertifizierungsstelle von Hermetry stammen, und das Hochladen einer eigenen CA für Fremdgeräte wird nicht angeboten; dieser Weg ist für lizenzierte Geräte gedacht, die ihren Schlüssel selbst erzeugen und selbst eine CSR senden. Dein ESP32 verwendet ein Access-Token oder MQTT basic.Was ich auf einem ESP32 tun würde:1. Dasselbe Binary für jedes Board ist in Ordnung. Lege das Token bei der Bereitstellung über einen kleinen seriellen Befehl beim ersten Start in NVS ab, nicht auf der Karte.2. Aktiviere Flash-Verschlüsselung und NVS-Verschlüsselung, damit ein Flash-Dump das Token nicht preisgibt.3. Die Karte nur für Datenprotokollierung und das CA-Bundle verwenden.4. In Hermetry je ein Gerät und ein Token pro Board anlegen; wenn ein Board verloren geht, das Geheimnis rotieren. Damit werden dessen Sitzungen sofort beendet.Die Einschränkung bei Zertifikaten steht im letzten Abschnitt von Device certificates.
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.
Von English mit KI übersetzt ·
Nur zwischen dem Telefon und dem Funkmast, und die 2G-Version davon ist schwach, weshalb der Van-Trick funktioniert. Hinter dem Kernnetz des Betreibers ist es normales Internet. Behandeln Sie die Funkstrecke als nicht vertrauenswürdig.
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.
Von English mit KI übersetzt ·
Gut. Plane aber einen Ersatz für diesen Edison ein, er wird seit Jahren nicht mehr produziert und Ersatzteile werden immer schwerer zu finden.
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.