bugra.demiriz
@bugra-demiriz · Joined August 2026
- Topics
- 11
- Replies
- 33
- Points
- 0
Forum Replies Created
They’re not the same thing, so they can disagree. The Sites & Assets map is coloured by the worst active alarm. The Sites board template reads the site status (Critical, Warning, OK or Unknown), the worst of each device’s status key, its active alarms and its connection. A major alarm paints the map red but on its own only makes the device Warning there, because only a critical alarm makes it Critical. Site status explains where that one comes from.
Edit the site and fill Latitude and Longitude. Copy them from any map application and use a dot as the decimal sign. The time zone sits on the same form; rules use both. Locations and time zones.
Polled devices use Last seen only, and devices on Last seen only write no connect and disconnect rows. That’s expected for your box.
Yes. A refused login (CONNACK 5) is logged with its reason. The device itself never gets the reason.
Agreed. And if a device reports and then disconnects on purpose, give its profile the Recent message online rule; then a disconnect alone doesn’t show it offline while its last message is still recent.
Over the API: GET …/devices/{deviceId}/log?source=connection (or source=audit for the changes), at most 1,000 entries deep. Connection history is kept for 30 days, so for a quarter you’d pull it every few weeks and keep the files. The changes are also in the audit log; its API filters by resourceType=iot_device and the device’s id, and Export CSV takes the date range you filtered: Audit log.
Duplicate profile on the profile page. It copies every setting into “<name> (copy)”, provisioning starts off and no provisioning key is copied. Then change the limits on the copy and move the second site’s devices to it.
Yes. A toggle every second is 60 a minute, over the flows limit of 30 commands and settings a minute to one device (it can be set anywhere from 1 to 600), and the general command limit is 10 per device per minute. Commands over the limit are refused. I wouldn’t drive a one-second sequence from the cloud anyway. Put the sequence in the device firmware and send one command that starts it, with the duration as a parameter.
Resuming accepts what happened so far: only new failures count against the gate, and a wave stopped at its end counts as passed. So look at the failed devices before you press it.
One for all twelve. You’d only split them if some had a different firmware family or a different security need, for example a few old ones that can’t do TLS.
That one again. After the fix: Deploy, then Resume from the flow’s row menu. The pause keeps the flow’s memory and the messages that were waiting.
No. Devices still offline or waiting when a wave closes are carried on and don’t count as failures. Online devices are put first, so the canary wave reports back quickly. Devices on metered links may show Waiting instead of updating, and they’re carried on the same way. The one case that does pause is a wave that closes with no device finished at all.
Nothing. A device in a later wave gets no fw_* attributes until its wave starts, and its page says “Waits for wave n”. The order is stable for the rollout, so a device doesn’t move between waves.
Script CPU only counts the CPU time of Script blocks, not the rest of the run. 0 ms means none of this month’s runs spent time in one.
Right. iot_device_settings.dangerous.write is Owner only, so an API key never has it, and the request also needs “confirm”: true.