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.