thompsonplc
@lthompson · Mitglied seit Mai 2025
Automation engineer · pharma · 14 years in the field
- Themen
- 7
- Antworten
- 65
- Punkte
- 0
Erstellte Forenantworten
Von English mit KI übersetzt ·
Beide haben recht. Ich musste das letztes Jahr unserer eigenen Einkaufsabteilung erklären, deshalb hier die ausführliche Version:Der Preis setzt sich zusammen aus: kleineren Stückzahlen als bei Wi-Fi/BLE-Bausteinen, einem vorzertifizierten Modul (die modulare FCC/CE-Zulassung ist ein großer Kostenfaktor, den man sonst pro Produkt tragen müsste), dem Zigbee-Stack und der Firmware/den Tools des Herstellers sowie der Allianz-Mitgliedschaft und Zertifizierung für ein Produkt, das das Logo tragen soll. Ein nacktes EFR32MG- oder CC2652-Modul kostet vielleicht 5-8 $, aber dann liegen die HF-Zertifizierung und die Stack-Integration bei Ihnen.Dann gibt es noch den Weg in Hermetry. Zigbee-Geräte verbinden sich nicht von selbst; man braucht einen Koordinator und etwas vor Ort, das für die Sensoren meldet. In Hermetry-Begriffen ist das ein Gateway, das auf den Topics v1/gw/* veröffentlicht, sodass jeder Sensor zu einem untergeordneten Gerät wird. Das ist ein weiterer Kasten und eine weitere Softwarekomponente, für die Sie verantwortlich sind.Für Pumpstationen würde ich zumindest LoRaWAN-Sensoren kalkulieren: Hermetry betreibt einen eigenen LoRaWAN-Network-Server, und der Frequenzplan richtet sich nach Ihrem Gateway, in den USA kaufen Sie also US915-Gateway und -Sensoren. Sensoren laufen jahrelang mit einer Batterie, und ein Gateway deckt eine große Fläche ab. Falls LoRaWAN an den Standorten nicht passt, ist die verdrahtete 4-20-mA-Anbindung an ein Gateway die andere realistische Wahl.
Both right. I had to explain this to our own purchasing last year, so the longer version:
The price stacks up from: smaller volumes than Wi-Fi/BLE parts, a pre-certified module (FCC/CE modular approval is a big cost you’d otherwise carry per product), the Zigbee stack and the vendor’s firmware/tools, and the alliance membership and certification for a product that wants the logo. A bare EFR32MG or CC2652 module is maybe $5-8, but then the RF certification and the stack integration are yours.
Then there’s the path into Hermetry. Zigbee devices don’t connect by themselves; you need a coordinator, and something on site that reports for the sensors. In Hermetry terms that’s a gateway publishing on the v1/gw/* topics so each sensor becomes a child device. That’s another box and another piece of software to own.
For pump stations specifically I’d at least price LoRaWAN sensors: Hermetry runs its own LoRaWAN network server and the frequency plan follows your gateway, so in the US you’d buy US915 gateway and sensors. Sensors run years on a battery, and one gateway covers a lot of ground. If LoRaWAN doesn’t fit the sites, wired 4-20 mA into a gateway is the other realistic choice.
Von English mit KI übersetzt ·
Gut. Bewahren Sie die Genehmigungs-E-Mail des Betreibers zusammen mit der Konstruktionsdatei auf, die nächste Hardware-Revision wird sie erneut benötigen.
Good. Keep the operator’s approval email with the design file, the next hardware revision will need it again.
US work is mostly the ANSI/NFPA-79 habits (TB1-3 style), Europe is IEC. Since your customers are UK/IE, go IEC.
Von English mit KI übersetzt ·
Die Zertifizierung des Moduls reduziert den Aufwand, den das Endprodukt wiederholen muss, ersetzt ihn aber nicht. Fragen Sie das IoT-Vertriebsteam des Netzbetreibers, was für ein Gerät in seinem Netz erforderlich ist. Manche verlangen nur die Zulassung des Moduls und eine Registrierung Ihres Geräts, andere wollen Labortests am fertigen Produkt.
Module certification lowers what the end product has to repeat, it doesn’t replace it. Ask the operator’s IoT sales team what they require for a device on their network. Some just want the module’s approval and a registration of your device, some want lab testing on the finished product.
0x3F. Changed the constructor and it reads „dP: 12.4 Pa“ on the first line. Going with a BSS138 level shifter board for the final build as you suggest. Bit embarrassed I didn’t scan first.
Yes, turned it end to end. Blocks get lighter and darker, no text.
Von English mit KI übersetzt ·
Benutzerdefinierte Topics sind nur eingehend, sie werden zur Telemetrie des Geräts, das sie veröffentlicht hat. Und Geräte erhalten in Hermetry niemals die Nachrichten anderer Geräte, daher wird ein Sensor, der für einen Lüfter veröffentlicht, nie funktionieren.Außerdem aus 14 Jahren Anlagenpraxis: Man möchte, dass der Aktor antwortet. Fire-and-forget an ein Relais führt dazu, dass ein Lüfter im Leitstand als eingeschaltet angezeigt wird und im Raum aus ist.
Custom topics are inbound only, they become telemetry of the device that published. And devices never get each other’s messages in Hermetry, so a sensor publishing for a fan will never work.
Also from 14 years of plant work: you want the actuator to answer. Fire and forget to a relay is how you end up with a fan that shows on in the control room and is off in the room.
Aisha, the single low-side MOSFET has a catch I’ve been bitten by. When it’s off, the bottom of the divider floats, and the top resistor pulls the ADC pin up to the full 12 V through 100k. That’s above the ESP32’s 3.3 V limit; the pin’s protection diode clamps it and current leaks into the 3.3 V rail. So you save the divider current and stress the pin instead.
The two-transistor version switches the top: a P-channel (AO3401 or similar) between the battery and the divider, gate pulled up to the battery with 100k so it’s off by default. A small N-channel (2N7000) driven by a GPIO pulls that gate down to switch it on. You need the N-channel because a 3.3 V GPIO can’t pull the gate of a P-channel sitting at 12 V high enough to turn it off. With the top switched off, the whole divider sits at 0 V, the ADC pin too.
In the firmware: switch on, wait about 10 ms, take 16 readings and average them, switch off. Use the calibrated reading (analogReadMilliVolts) and send battery_v as a number with two decimals.
For the flapping: a lead-acid battery’s voltage jumps when charging starts, so a plain threshold will always bounce. Give the rule hysteresis so it only clears well above the threshold, and two severities:
{
"type": "battery_low",
"title": "{{device.name}}: battery {{value}} V",
"severities": [
{ "severity": "MAJOR", "condition": { "key": "battery_v", "op": "<", "value": 11.5 } },
{ "severity": "MINOR", "condition": { "key": "battery_v", "op": "<", "value": 11.8 } }
],
"hysteresis": 0.4,
"debounce": { "mode": "count", "raise": 2, "clear": 2 },
"notify": { "recipients": [ { "kind": "email", "email": "field-team@example.com" } ], "minSeverity": "MINOR" },
"enabled": true
}It opens below 11.8 and clears only at 12.2 or above, two readings in a row. Kevin’s idea would hide the problem, not fix it. Hysteresis and debounce are explained on this page.
Short helps, but 17 dB is not „short trace“ territory, that’s a broken RF path. Did this on a sensor board for a cleanroom monitor and lost about the same.
Questions to check: is there solid ground under the trace on the other layer? Is the trace 50 ohm? On 1.6 mm FR4 a 50 ohm microstrip is around 3 mm wide, so a 0.25 mm signal trace is closer to 120 ohm. Over 6 mm that alone isn’t the whole 17 dB, but add no ground plane under it and the trace is half an antenna radiating into your own board.
What I’d do on the next revision: coplanar waveguide with ground on both sides and a row of vias, width from a calculator for your stackup, a pi network footprint between module and connector (0 ohm in series, others not fitted until you can measure), and the U.FL ground pads stitched straight to the plane. Keep the switching regulator away from that corner.
Then compare again in the frames log, it shows the best RSSI and SNR per uplink so you can check both boards on the same gateway without extra tools. See The frames log.
Von English mit KI übersetzt ·
Bus 0 ist für das HAT-ID-EEPROM an den Pins 27/28 reserviert. Bus 1 ist der Benutzerbus. Aoife, meinst du mit „GPIO 3“ den physischen Pin 3 oder BCM GPIO 3?
Bus 0 is reserved for the HAT ID EEPROM on pins 27/28. Bus 1 is the user one. Aoife, when you say „GPIO 3“, do you mean physical pin 3 or BCM GPIO 3?
Are you sending one line per sample, so 200 radio packets a second?
Von English mit KI übersetzt ·
Regelkarte. Ich betreibe Lüftungspläne im Labor auf diese Weise.Gib zuerst dem Profil des Pi einen Befehl, z. B. heaters.set mit einem Ja/Nein-Parameter on, Basic-Stufe. Auf dem Pi:
from rpi_rf import RFDevice
tx = RFDevice(17); tx.enable_tx()
CODES = {True: [5592405, 5592407, 5592411, 5592413],
False: [5592404, 5592406, 5592410, 5592412]}
def on_rpc(req_id, body):
if body.get("method") == "heaters.set":
for code in CODES[bool(body["params"]["on"])]:
tx.tx_code(code, 1, 350) # protocol 1, pulse length from the sniff
client.publish(f"v1/rpc/res/{req_id}", '{"ok": true}', qos=1)(Deine Codes und die Pulslänge stammen aus dem Sniff, meine sind Platzhalter.)Dann auf der Regelkarte des Terrassen-Assets:
- Regel „Heaters on“: When Sunrise or sunset, Sunset, offset -15. Then Send a command
heaters.seton = yes to the Pi. - Regel „Heaters off“: When A time of day 23:00, every day. Then the same with on = no.
Für den Sonnenuntergang wird der Standort benötigt. Trage daher Breiten- und Längengrad am Terrassen-Asset ein und ordne den Pi darunter an, sonst wird die Regel nicht gespeichert. Außerdem gibt es bei 433 MHz keine Rückmeldung. Wenn du sicher gehen willst, sende den Befehl zweimal mit einer Minute Abstand. Doku: Time, sunrise/sunset, dates and holidays.
Rules card. I run lab ventilation schedules this way.
First give the Pi’s profile a command, e.g. heaters.set with a Yes/no param on, Basic tier. On the Pi:
from rpi_rf import RFDevice
tx = RFDevice(17); tx.enable_tx()
CODES = {True: [5592405, 5592407, 5592411, 5592413],
False: [5592404, 5592406, 5592410, 5592412]}
def on_rpc(req_id, body):
if body.get("method") == "heaters.set":
for code in CODES[bool(body["params"]["on"])]:
tx.tx_code(code, 1, 350) # protocol 1, pulse length from the sniff
client.publish(f"v1/rpc/res/{req_id}", '{"ok": true}', qos=1)(Your codes and pulse length come from the sniff, mine are placeholders.)
Then on the terrace asset’s Rules card:
- Rule „Heaters on“: When Sunrise or sunset, Sunset, offset -15. Then Send a command
heaters.seton = yes to the Pi. - Rule „Heaters off“: When A time of day 23:00, every day. Then the same with on = no.
Sunset needs the place’s location, so put latitude/longitude on the terrace asset and place the Pi under it, otherwise the rule won’t save. Also, 433 MHz has no feedback, so send the command twice a minute apart if you want to be sure. Doc: Time, sunrise/sunset, dates and holidays.
Using the shield as your signal reference is the main problem. Noise current from the drives flows in it and straight into your receiver’s ground.
Von English mit KI übersetzt ·
Fast, aber es ist andersherum, und das passiert allen. Die Namen sind aus Sicht des Pi benannt: MOSI ist der Pi, der an den Chip sendet, MISO ist der Chip, der an den Pi sendet. DO auf deinem Breakout bedeutet „Daten aus dem MAX31855“, also geht DO an MISO, GPIO 9, Pin 21.Der MAX31855 empfängt nie etwas, du ziehst einfach CS auf Low und taktest 32 Bit heraus, deshalb hat er gar keinen Eingangspin. Lass MOSI (Pin 19) unbelegt. Verdrahtung:
VIN -> 3.3 V (Pin 1)
GND -> GND (Pin 6)
DO -> GPIO 9 MISO (Pin 21)
CLK -> GPIO 11 SCLK (Pin 23)
CS -> GPIO 8 CE0 (Pin 24)
Aktiviere SPI in raspi-config und lies dann 4 Bytes mit spidev bei 1 MHz oder weniger. Die Bits 31..18 sind die Thermoelement-Temperatur in 0,25-C-Schritten, Bit 16 ist das Fehlerflag. Prüfe dieses Flag, bevor du etwas sendest, sonst erscheint ein offenes Thermoelement als seltsame Zahl in deinem Diagramm.
Close, but it’s the other way round, and it trips everyone. The names are from the Pi’s point of view: MOSI is the Pi sending to the chip, MISO is the chip sending to the Pi. DO on your breakout means „data out of the MAX31855“, so DO goes to MISO, GPIO 9, pin 21.
The MAX31855 never receives anything, you just pull CS low and clock out 32 bits, so it has no input pin at all. Leave MOSI (pin 19) unconnected. Wiring:
VIN -> 3.3 V (pin 1)
GND -> GND (pin 6)
DO -> GPIO 9 MISO (pin 21)
CLK -> GPIO 11 SCLK (pin 23)
CS -> GPIO 8 CE0 (pin 24)
Enable SPI in raspi-config, then read 4 bytes with spidev at 1 MHz or below. Bits 31..18 are the thermocouple temperature in 0.25 C steps, bit 16 is the fault flag. Check that flag before you send anything, an open thermocouple otherwise shows up as a strange number on your chart.
RS-485, Modbus RTU, one 4-core cable. I’ve wired a few greenhouses like this.
Cable: a shielded twisted pair cable with two pairs, for example a 2x2x0.5 mm². One pair for A/B, the other pair for power: 12 V and 0 V. The 0 V also serves as the RS-485 common. At 80 m and 12 Nanos drawing maybe 40 mA each through a small buck converter, the voltage drop on 0.5 mm² is under a volt, fine for 12 V in.
Topology: a daisy chain along the benches, with short stubs (under 30 cm) to each node. No star. 120 Ω termination at both ends of the main run, bias resistors only once, at the ESP32 end. Each Nano gets a MAX485 (or better, an auto-direction module so you save a pin).
Protocol: each Nano is a Modbus RTU slave with its own address 1-12 (the ModbusRTUSlave library is fine), holding registers for moisture, temp x10, RH x10, lux. The ESP32 is master, polls every node every 30 s at 19200, and publishes:
v1/gw/connect {"device": "bench-03", "type": "greenhouse-node"}
v1/gw/telemetry {"bench-03": {"ts": 1767225600000, "values": {"soil": 41, "t": 23.4, "rh": 71.2, "lux": 8200}},
"bench-04": {"ts": 1767225600000, "values": {"soil": 38, "t": 23.1, "rh": 70.8, "lux": 7900}}}One gateway message for all twelve, and megan_b40 is right about ts, only if the ESP32 has NTP. Make a device profile named greenhouse-node and every child lands in it with the same alarms.
If a node stops answering, publish v1/gw/disconnect for it so it shows offline instead of silently going stale.