kapua
kapua copied to clipboard
eclipse
Optional read in Assets tab
Is your feature request related to a problem? Please describe. When a device has lots of industrial devices connected, the delay reading them in the Assets tab is considerable and it is easy to exceed the timeout of 30 seconds in the read.
Besides, in Assets tab it is possible to view the assets and variables much more comfortably than in the Configuration tab. Such other tab shows them much more confusingly as the assets are mixed with the rest of components and the variables are hard to distinguish as part of the parameters of the asset.
Describe the solution you'd like In Devices -> Select device -> Assets, it could be great if the assets were listed without performing any read. After they are shown it could be available the possibility to read them one by one to avoid timeout problem described above. To keep previous functionality it could be also available a button to read all of them.
Describe alternatives you've considered A good option could be to transform the assets list in the left in a checklist where you can select all of them to select which to read to maintain the previous functionality of reading all at a time. In this case I'm not sure if the write option should also be available for multiple devices, but in that case I think it would be needed that the assets to be modified are marked in the left panel to avoid undesired operations.
@Coduz correct me if I'm wrong, but this is actually not possible, right? I mean, the assets are not stored anywhere, they're always coming live from the device. Should we think about caching them somehow?
Hey @lorthirk, I think that caching is a bad idea in this particular case. I mean, you can have stored the device somewhere (cache in this case), but in order to refresh them, you will always have to retrieve the fresh list of assets from the device. I think that caching would introduce all sort of problems and testing this would be a real problem.
@pintify I understand your concern and solution behind it, but to have somehow static (cached) list of assets is a bad idea, since assets can and will change on the device. Imagine you change an asset channel parameter which does not exist on the device and it takes you a couple of minutes or more to do that, becasue of all the channels asset might contain - this woul just prolong the whole process as Kura would return an error describing this asset does not exist etc.
I agree, that anything more than 5 second delay in retrieving the assets is too much, but this has to be done differently, not throguh caching or static configuration etc. Maybe a solution would be that connected device sends number of drivers first, then number of assets and then number of channels in each asset, and an estimate, how long the import will take - just a heads up for user to expect a bit of delay.
What do others think?
Well... from a strict REST API view, we have both /{scopeId}/devices/{deviceId}/assets and /{scopeId}/devices/{deviceId}/assets/_read. I should dig in the code right now to have a better picture, but from an external perspective we should make sure that just reading the list of assets doesn't read values as well. If we're already doing that, we should investigate on how to improve performances on that specific operation.
Indeed, caching the assets seems a bad idea, but just as the API requests, it could be done in two steps, one to get the assets and another one to read them. My team has implemented a test web that uses the calls that @lorthirk mentions to have exactly this behaviour.