Question about how device states work, If i do a payload path to an object of device states does that count as one payload/device state update, or one per entry in that object? for example here is this one payload or 3. Our application seems to be putting out way more payloads than were expecting and were trying to figure out the cause for it.
There’s no alternative method that will reduce the payoad count. When the platform receives an array of state objects, it is required to break them apart and record each individually to the time-series database. It’s also possible to trigger workflows on each individual state object within the array.
If you’d like to understand where payloads are being consumed, you can see a breakdown of payloads per application on your Organization’s Usage page.
You can then find a detailed breakdown under the Usage tab under the Application Info page.
Thanks for input Brandon…
Curious how we’d (co)create something more sustainable / scalable? Ex, it seems like batch-updating device state doesn’t batching anything (coz we can do sets, not just single points).
We’re not talking huge data points, but there are a fair number of them.
The only other recommendation is to ensure you’re reporting all attributes for a single timestamp for a single device in the same state message. For example, if you reported half the attributes in one message and the other half in another message, that would count as two payloads.
Batch reporting has benefits when it comes to data usage and power consumption. If a device comes online and needs to report a batch of historical data, it can be done in a single message instead of dozens or hundreds of individual messages.
Because of the nature of our devices architecture at the moment it really only makes sense/is possible to report time series data for one state per message from our webhook. (no mixing of different states in a single trigger of the webhook). Like if were reporting temperature and wind speed over the hour they would come in as two different messages with their values over time.
Is there a way to hold info from one trigger of a webhook and merge it into another so we could consolidate time stamps like that.
You can implement an aggregator using Workflow Storage. It’s more complicated to build than it appears on the surface. For example, what happens if you don’t get one of the messages? You’ll have to implement some kind of timeout system, otherwise you’ll be stuck waiting forever. It’s possible, and will reduce your payload count quite a bit, but the corner cases are tough.
The main piece of advice for using Workflow Storage for something like this is to include the device ID in the key(s). This way you can handle multiple devices at the same time.
Ok, and just to close the batch-reporting idea, sounds like it’s really batch reporting per timestamp, such that all data points in that timestamp are considered one device state update (aka one payload).
Not entirely correct. Each individual state message, regardless of timestamp, counts as a payload. You can theoretically report the same attribute with the same timestamp 10 separate times, which would count as 10 payloads.
Since you are receiving your attributes individually as separate webhooks, you are generating a payload per attribute even though they’re on the same timestamp.
You can potentially reduce payload usage by aggregating those separate attributes together and reporting them in a single state message. I’m not talking about batch reporting, I’m talking about waiting until you’ve received all the attributes for a single timestamp before reporting any state at all.
