Open chicco785 opened 3 years ago
A priori, sounds good :)
Could you elaborate a little bit, please? For instance, which possible values are expected for that status
field and under which circumstances each one would be used.
here are few ideas:
provisioning failed
: when the provisioning of a device fails.update registration failed
: when the update of a device fails (toward orion).ok
: when the provisioning / update works fine.cannot send data
: when cannot update entity on orionsending data
: when update to orion worksI think is a good proposal but in order to have it fully clear (and to provide a useful guideline for the implementation) maybe a state diagram showing the different state transitions would help.
Hi @fgalan , @chicco785 Could you please elaborate on this issue?
Hi @fgalan , @chicco785 Could you please elaborate on this issue?
I think a good issue description is already provided in the issue body itself and further comments. Which specific doubt do you have?
As of today if orion returns 400 during registration, the registration fails. This means that the configuration data of the device are deleted, and you have to provide them again. While if you are just shutting API calls, that's not much a problem, UI users may find annoying that the configuration is not persisted despite the error.
To handle the situation, it could be nice to have in the device a field
status
which in case of errors is updated with proper code errors. @fgalan @jason-fox @AlvaroVega feelings?