bugra.demiriz
@bugra-demiriz · Joined August 2026
- Topics
- 11
- Replies
- 33
- Points
- 0
Forum Replies Created
Don’t try it on a workspace with live devices. It pauses every running flow on every host, root flows included, and the root flow is the one storing your device data. Device messages, schedules and webhooks start no run until you resume.
It does ask first: you tick “I understand that nothing runs until the flows are resumed.” and type STOP. Resume the flows brings back every flow the stop paused. A flow that had paused itself before stays paused. Both are in the audit log.
The person wins. Only one writer changes a device’s section at a time, and a person’s change on the device page wins over the job; “Changed by a person” is one of the states a device can show in the job. When two jobs want the same device, the job’s setting decides whether it waits or skips the device.
Not this way, sorry. Two things have to be true: the firmware announces its settings sections when it connects, and Hermetry has the settings description (the manifest) for that model and firmware. Licensed devices have both.
For your own boards, declare cfg.* keys on the profile’s Configuration keys tab (type, limits, allowed values) and let the firmware read them as shared attributes. You get typed keys with limits, and the Attributes tab shows each one as In sync, Pending, Rejected or Drifted, without writing a manifest. Attributes has the device side.
Connection history is kept for 30 days, and Load more goes further back within that. Devices whose profile uses Last seen only write no connect and disconnect rows, so check the profile’s online rule if the tab looks empty.
It subscribes to v1/rpc/req/+ and gets the method and params; for a two-way command it answers on the same id:
PUBLISH v1/rpc/req/42
{"method": "sys.ping", "params": {"host": "8.8.8.8", "count": 3}}
PUBLISH v1/rpc/res/42
{"ok": true, "result": {"sent": 3, "received": 3, "avg_ms": 18.2}}Commands are only delivered after the device has subscribed on that connection.
Each command in the catalog has a tier. By default Basic is for Users, Privileged and Critical for administrators, and a raw method that isn’t in the catalog is owners only. If one operator needs privileged commands, a custom group with iot_rpc.send.privileged does it without making them Admin.
That’s why it reads that way. One thing for the firmware side while you’re at it: a command can arrive twice, so remember at least the last 32 request ids for 10 minutes and don’t run the same id again.
What we see: the address of the newest connection. For HTTP and polled devices, which don’t hold a connection, it’s the address of the newest activity. Behind your router you’ll see the public address the connection comes from (the router’s, or the mobile operator’s NAT address if it puts one in front), not the 192.168 one the device has.
On the alarm’s timeline. It shows Notified with the number of recipients and channels, “Notification held back” when the throttle kept one back, and Muted when nobody was told.
The notification log only has attempts that were made (sent, failed or pending per recipient and channel). Something held back before it was attempted (by a preference, quiet hours, the repeat window or a mute) never got that far, so it is not in the log; those decisions show on the alarm timeline instead.
The changelog line is about the trigger itself: it’s stored durably and repaired automatically after an outage.
For the calls themselves, a webhook call that waited longer than its time-to-live during an outage isn’t run on its own. It goes to Failed messages with the reason “Waited too long”, and Replay runs it. Replay keeps the original ids, and the outbound blocks send the same idempotency key, so if the system you call deduplicates it sees the call once. Details in Protections and failed messages.
For a fixed key in a header I’d put it on the HTTP endpoint connection: auth type header, header_name X-Api-Key, and the value goes in header_value, which is stored as a secret. Then the block only names the connection and the row in the block’s headers can go.
After saving, the field shows “A value is stored. Leave empty to keep it.” and the value never reaches a run record, a log or an export. If you export the flow later, the importer has to type the secret again.
Yes, if the device sends its own time. A message like {"ts": 1759572000000, "values": {...}} is stored at ts, in milliseconds since 1970 UTC. A flat object is stored at the time it arrived. Two things to watch: a record more than 10 minutes in the future is refused as bad_ts, so keep the clocks synced, and an admin can set an oldest accepted age. Details on Timestamps, late and duplicate readings.
Welcome Lakshmi. For a regular extract into your own store, the History API called by your scheduler is the usual route. If you want every reading in real time instead, a forwarding block in the root flow sends them on as they arrive. Exporting data compares the options.
They can’t. A group can lift a member over an Admin minimum, never over an Owner one. Raw commands, ownership transfer and deleting the organisation stay with owners whatever a group says, and those cells are locked in the matrix for everyone but the owner.
No, groups only add. A member’s rights are the role plus every active group, and nothing in a group subtracts.
To hold someone back from what their role allows, use an access policy with a deny. A deny always wins over the matrix. Policies need the Owner role to set up: Access policies. If it’s a whole role you want changed (no User in your organisation may acknowledge), unticking that cell for User in the Access Rights matrix is simpler.