Setting a value for all devices at once

Help
, ,
1

I am creating a trigger for my devices that sends an MQTT message to each device to initiate a cleaning cycle monthly.

I want to do this in my main workflow and use the storage set and get values functions.

Currently I have a timer that goes off at the beginning of every month that connects to a storage set node and sets the value of clean to false. Then a conditional statement sends out an MQTT message to initiate the cleaning process. The problem is I need to set that value to false for each device to make sure the message is only sent once a month, one time per device.

My understanding for the current way to do this is that I have to put in a specific ID every time and have one storage set node for each device in our system. That is quickly becoming a mess and will only get worse as we add more devices. Is there a way to quickly set this value for each device without having a bunch of storage set commands?

image
image201×517 10.9 KB

3

I’m still a little unclear on what you’re trying to accomplish, but what if you stored the “lastCleanedTimestamp” as a tag on the device? Given you’re only performing this action once a month, I am less concerned about the race conditions, performance issues, and throttling limits that come into play when updating device tag values on a frequent basis.

  1. First of the month comes around and your timer fires.
  2. Fetch a list of devices that you wish to “clean”. If using a tag, this is an advanced query where “tags.lastCleanedTimestamp” < (current time minus a month).
  3. Publish one message on your custom MQTT topic (i.e. time/to/clean) and then all of your devices receive it.
  4. On your hardware, you take some sort of action when that message is received that does the cleaning process.
  5. On success, publish back to the MQTT broker on a different MQTT topic (i.e. cleaned/time) with the device ID.
  6. Cloud-side, you have a workflow that triggers on messages to that topic and updates the value of the “lastCleanedTimestamp” for the provided device ID.
5

Hi @Dylan_Schuster,

Could you please clarify this with some more detail?
“race conditions, performance issues, and throttling limits that come into play when updating device tag values on a frequent basis.”

I have a project which relies heavily on tags, just checking we will not hit any unexpected limits.

Many thanks

6

@ChrisGM some of the issues I was referring to there have since been resolved; for example, bulk updates to device tags on peripheral devices associated with an edge compute device could previously cause the edge compute device to be disconnected from the broker as those updates were sent down to the edge. That is no longer the case.

Race conditions are certainly still a concern if you have multiple workflows reading and updating device tag values, as the order of execution may not be guaranteed depending on other factors. The chances of these issues increases as your application’s scale increases.

Performance issues could come into play down at the edge if an edge compute device is receiving a significant number of updates to the associated peripheral devices through the MQTT broker; if your hardware is beefy enough, this may not be cause for concern.

Would you mind telling me a little more about your use case? We look at tags to be used more as “write-light, read-heavy” meta information about a device, and if you’re making frequent updates to them, I may be able to suggest a better approach.

7

Thanks @Dylan_Schuster,

I think your description of it in line with my assumptions. I don’t think we’re at risk in any way with current applications.