Von English mit KI übersetzt ·
Integrator hier. Ein Kunde hat etwa 300 Pumpensteuerungen im Feld, ESP32-S3-Boards mit unserer eigenen Firmware, alle per MQTT an Hermetry angebunden. Wir müssen einige Einstellungen remote pro Standort ändern: das Berichtsintervall, ein Totband beim Druckwert und den NTP-Server (manche Standorte blockieren die öffentlichen Pools).Intern stehen zwei Ansätze zur Diskussion:
- ein Befehl, etwa
cfg.set, mit den Einstellungen als JSON-Parameter, beantwortet mit ok/error - gemeinsame Attribute, die das Gerät übernimmt
Wichtig ist uns, sicher zu wissen, dass ein bestimmtes Gerät einen Wert übernommen hat, und Änderungen für Geräte, die offline sind, nicht zu verlieren. Manche ländlichen Standorte fallen für zwei oder drei Tage am Stück aus.Die Firmware liest beim Start bereits eine JSON-Konfiguration aus dem Flash, das Übernehmen der Werte ist also nicht das Schwierige. Die Geräte melden alle 60 s und sitzen hinter einem Mix aus LTE-Routern und WLAN am Standort. Für welchen Ansatz ist Hermetry gebaut, und gibt es so etwas wie eine Soll-Ist-Ansicht?
Integrator here. A customer has about 300 pump controllers in the field, ESP32-S3 boards running our own firmware, all on MQTT to Hermetry. We need to change a few settings remotely, per site: the reporting interval, a deadband on the pressure reading, and the NTP server (some sites block the public pools).
Two approaches on the table internally:
- a command, say
cfg.set, with the settings as JSON params, answered with ok/error - shared attributes that the device applies
What I care about: knowing for certain that a given unit has applied a value, and not losing changes for units that are offline. Some rural sites drop off for two or three days at a time.
The firmware already reads a JSON config from flash at boot, so applying the values is not the hard part. The units report every 60 s and sit behind a mix of LTE routers and site Wi-Fi. Which way is Hermetry built for, and is there anything like a desired-vs-reported view?
Von English mit KI übersetzt ·
Ich bin Student und neugierig: Warum sollte das eine Rolle spielen? Ein Befehl mit den Einstellungen darin klingt für mich einfacher.
Student here, curious: why would it matter? A command with the settings in it sounds simpler to me.
Von English mit KI übersetzt ·
Befehle an ein offline stehendes Gerät warten nur, wenn Sie sie als persistent senden, und das gibt nach höchstens 7 Tagen auf. Attribute sind Zustand, Befehle sind Aktionen. Ich würde Attribute nehmen.
Commands to an offline unit only wait if you send them persistent, and that gives up after 7 days at most. Attributes are state, commands are actions. I’d go attributes.
Von English mit KI übersetzt ·
Wir haben das bei einer kleineren Flotte mit Befehlen gemacht, und jedes Mal, wenn ein Gerät einen Befehl verpasst hat, war es ein Chaos. Niemand konnte sagen, welche Geräte welches Intervall hatten.
We did it with commands on a smaller fleet and it was a mess every time a unit missed one. Nobody could tell which units had which interval.
Von English mit KI übersetzt ·
Verwenden Sie cfg.*-Shared-Attribute, dafür sind sie genau gedacht, und Sie erhalten die Ansicht Soll- vs. Ist-Wert gratis dazu.Deklarieren Sie die Schlüssel auf dem Tab Configuration keys des Profils (Typ, Bezeichnung, Grenzwerte) und setzen Sie sie dann als Shared-Attribute: cfg.telemetry.interval_s, cfg.pressure.deadband_bar, cfg.ntp.server. Das Gerät erhält Änderungen über v1/attributes/set, wendet sie an und meldet den übernommenen Wert als Client-Attribut mit demselben Schlüssel zurück. Hermetry vergleicht beide Werte und zeigt pro Schlüssel auf dem Tab Attributes den Status In sync, Pending, Rejected oder Drifted an.Geräteseitig nach jeder Verbindung:
SUBSCRIBE v1/attributes/set
PUBLISH v1/attributes/req/1 {"sharedKeys": "cfg.*"}
# Antwort auf v1/attributes/res/1 -> alles anwenden -> zurückmelden:
PUBLISH v1/attributes {"cfg.telemetry.interval_s": 300, "cfg.pressure.deadband_bar": 0.05}Die Anfrage nach dem Verbinden deckt Ihre ländlichen Standorte ab: Ein Gerät, das drei Tage offline war, fragt bei der Rückkehr alle cfg.*-Schlüssel an und holt den Rückstand auf. Kann ein Gerät etwas nicht anwenden, meldet es das in cfg_rejected, z. B. {"cfg_rejected": {"cfg.ntp.server": "apply_failed"}}, und die Zeile zeigt Rejected mit dem Grund. Wenden Sie Änderungen idempotent an, da eine Nachricht zweimal eintreffen kann.Für 300 Geräte schreiben Sie die Werte mit der API (POST …/attributes/shared, bis zu 100 Schlüssel pro Aufruf) in einer Schleife über die Geräteliste. Die Screens Baseline und Bulk-Jobs sind für Geräte gedacht, die ein Einstellungsmanifest veröffentlichen (lizenzierte Geräte). Mit eigener Firmware ist cfg.* daher der richtige Weg. Die Seite Attributes enthält die Statustabelle.
Use cfg.* shared attributes, that’s exactly what they’re for, and you get the desired-vs-reported view for free.
Declare the keys on the profile’s Configuration keys tab (type, label, limits), then set them as shared attributes: cfg.telemetry.interval_s, cfg.pressure.deadband_bar, cfg.ntp.server. The device gets changes on v1/attributes/set, applies them, and reports the applied value back as a client attribute with the same key. Hermetry compares the two and shows In sync, Pending, Rejected or Drifted per key on the Attributes tab.
Device side, after every connect:
SUBSCRIBE v1/attributes/set
PUBLISH v1/attributes/req/1 {"sharedKeys": "cfg.*"}
# answer on v1/attributes/res/1 -> apply everything -> report back:
PUBLISH v1/attributes {"cfg.telemetry.interval_s": 300, "cfg.pressure.deadband_bar": 0.05}The request after connect is what covers your rural sites: a unit that was offline for three days asks for all cfg.* keys when it comes back and catches up. If a unit can’t apply something, report it in cfg_rejected, e.g. {"cfg_rejected": {"cfg.ntp.server": "apply_failed"}}, and the row shows Rejected with the reason. Apply idempotently, a message can arrive twice.
For 300 units, write the values with the API (POST …/attributes/shared, up to 100 keys per call) in a loop over the device list. The baseline and bulk-job screens are for devices that publish a settings manifest (licensed devices), so with your own firmware cfg.* is the route. Attributes page has the status table.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Mitdiskutieren
Melde dich an, um Fragen zu stellen und zu beantworten, hilfreiche Beiträge mit „Gefällt mir“ zu markieren und die Antwort zu kennzeichnen, die dein Problem gelöst hat. Jeder Beitrag bringt Punkte und Stufen.