Product/components used and version/fix level are you on:
10.16
Detailed explanation of the problem:
My customer wants to have at the end of the month for each if his devices the latest measurement. We talk here about hundreds of devices which would mean you have to do a call for each device. Can we avoid doing this for each device.?
Any Idea
Exports are not fine granular enough.
Is your question related to the free trial, or to a production (customer) instance?
production
Have you installed all the latest fixes for the products and systems you are using?
If this is just a single measurement I would just add it as a fragment to the managed object of the device like “cust_whatEverMeasurement”. Can be done within the agent or using EPL or Analytics Builder.
When using REST you can just query all the devices and get the latest value of the measurements in the response.
Effort: O(1) for each 2000 devices in comparison to the measurement API O(n).
Still not perfect as the managed object could be pretty big and might not be needed for your request.
I think you have to be careful with big-O comparisons there, and potentially optimising for the wrong thing.
The original message says they want to collect from all the devices once per month.
If you attempt to update ManagedObjects on new Measurements, you be doing that for every incoming Measurement of each device - that’s a lot more traffic and processing just to optimise something being collected once per month.
Also, note that the MO API is not designed for updates at Measurement rates, so depending on rate you could struggle.
yeah it sounds simple by using the managed object as suggested by @Stefan_Witschel but as you mentioned this is not an option for my customer because of the extra load.
I would rather go for the export functionality but this is also not optimal, because you do not collect just only one Measurement and you don’t know the timeframe with the smallest amount of measurements.
.
@Kevin_Palfreyman That’s all true! But the goal was to reduce the requests to a minimum Reducing the requests does not mean that this is most efficient way how to do it.
Still I think this can be optimized e.g. executing a scheduled microservice every day/week/month which fetches the latest measurement for each device and updates the MO. You could probably do the same with EPL Analytics Builder I guess… so not processing every single measurement each time. Measurement frequency and accuracy are important details implementing that.
@Kai_Reinhardt With export you mean reporting functionality? I wouldn’t go that route for the reasons you already mentioned, also the number of records exported is limited.
it is a common solution to the problem to have a microservice that updates the latest values. That’s why we are working on a feature to support this out of the box in the platform. Basically, we are going to update a dedicated fragement with every new measurement recevied from the device. Via the MO API those can be queried for multiple devices at once.
Having latest measurement in MO would help with group dahboards a lot. Also, it would help customers create exports without need to combine inventory export with measurements export.
And talking about inventory API not being optimized for measurement rates, the LWM2M agent updates the MO with every measurement already today. Does that mean, that there is a performance limitation for LWM2M clients?
by default, the MO API is not optimized to handle the same load as the measurements API but we do consider some optimizations that can help to lower the overhead associated. I.e., we try to bucket changes together and do bulk updates, prevent notifications, etc. Things that are not possible via the MO API but internally.
Reducing the requests does not mean that this is most efficient way how to do it.