No category for platform!
We issue each hardware device with an admin generated token.
This is done (rather than generating an organisation token) because devices sometimes need to be switched to a different organisation.
That is fine, however, if we need to temporarily disable a device (because a customer does not pay for a few weeks) all we can do is delete a token and not just disable it.
This means that we either have to get the device back to the factory to change the protected token or to use clever software to send to the customer to change it.
It would be so much easier to disable a token (Just like you can with events) then re-enable it later if the customer pays up.
Thank you so much for reaching out, that is a great suggestion and I appreciate you explaining how it would help you out. I’m going to pass along your request to our product development team so they can consider it for future developments. I will let you know as soon as I have an update.
Please, let me know if you have other questions or feedback.
Greetings @mantracourt , besides that there is not an option to "turn off " a token, you may disable the ability to send/retrieve data to organizational and device tokens just as follows:
Both of the actions described above are available just through your account owner interface, so your end-users, even with permissions, will not be able to modify them. In the practice, this should work as a way to “disable” your tokens unless that you use a global token, which is actually not possible to be disabled in any way.
The devices use the standard tokens (not organisational or device based).
I do this so we can allocate devices to different organisations as the model we use is that distributors hold the devices and may use the same one passed around various organisations.
So that is why I don’t use Organisation Tokens. Each device also pulls data from a central ‘controller’ device that holds tariff information common to all devices.
However, the device tokens do look interesting but I have a few questions.
The main issue is that each device reads certain data from another central device so I would guess that I cannot use a device level token as that will not allow it to be read? (Because we subscribe via MQTT to this other device and certain variables so that the devices are immediately informed of tariff changes etc)
Is it correct that our customers would never be able to see this token in the browser regardless of their user role settings?
Is this token automatically generated when the device is created?
If a device on Ubidots were deleted would it get a new token when created again? (i.e. a device would need to be returned to us to get a new token written in)
If a device is allocated to a different organisation does the token stay the same?
This does look nice because even if a user found out the device token he could not access the API to fiddle with other devices or create new devices. But I think 1 above means we cannot use it.
The main issue is that each device reads certain data from another central device so I would guess that I cannot use a device level token as that will not allow it to be read? (Because we subscribe via MQTT to this other device and certain variables so that the devices are immediately informed of tariff changes etc)
If possible, you could ship every device with the same “central device” read-only token, in addition to each device’s own token. Would that work?
Is it correct that our customers would never be able to see this token in the browser regardless of their user role settings?
Yes, just make sure to have the corresponding App flag disable
Is this token automatically generated when the device is created?
Yes
If a device on Ubidots were deleted would it get a new token when created again? (i.e. a device would need to be returned to us to get a new token written in)
Yes
If a device is allocated to a different organisation does the token stay the same?
Yes, the token stays the same.
Based on this, I believe the only impediment would point 1. Let us know if our proposal would be possible.
