Registry service for resin.io devices

[simonkemper]

Hi!

If someone would ask me what I think is best about resin.io I really would not know what I should answer because I almost like every little thing about it.

In two of my latest projects however I was heavily using the devices public-url to access remote devices via web API or web sockets for realtime bidirectional communication.

Clients have access to their end-devices via Smartphone App which is making a connection to the end-device based on the public-url.

To make setting up and storing of public-urls a little more nicer and easier I came up with the idea of implementing a device registry service that automatically tracks the public-url along with other things. I would like to share this basic idea with you and get feedback. To get a better understanding let me summarize the idea into a few details. For better understanding let’s call the registry service Gister …

So here’s the basic structure:

---

Gister Application

In Gister an application is very similar to applications in resin.io. The Gister-Operator creates an application for it’s use-case, for example an IoT sensor product which might be called “IoT-Sense”. So this application will have the name “IoT-Sense”.

Devicetype

A Devicetype is the “prototype” of the resin.io device and can have data-fields, very similar to environment/device variables in resin.io. But mostly important, after creating a Devicetype (for example in our application with the name “IoT-Sensor-Device1”) an unique **Device-Type-Token" is being generated.

Users

Users are the customers of the Gistry-Operator and are the people who are buying and actually using the products. They have to create an Account on the Gister-Service (which can be done via API and integrated into the Gister-Operators homepage, for example). After unboxing a new device they have to set their account credentials into the device and when it connects to the internet it calls the Gister-API and forwards the Device-Data along with resin.io’s public url so that this is being stored in Gisters Device-Registry.

Clients

A client can be for example a smartphone which connects via public-url to the end-device. But instead of using the inconvenient way of manually entering the long and not-so-good-human-readable public-url the user of the client can simply enter it’s Gister Account credentials and a list of his registered things / end-devices is being loaded via Gister’s API. With this information the client application has access to the public-url and can connect to the end-device without manually entering the public-url.

---

So concerning my projects and clients I really need such a service since this really helps settings up connected microservices spread over embedded end-devices using resin.io. I am going to start developing such a service (Actually, I have already started).

So what do you guys think? Maybe there is an existing service that does exactly what I am looking for. Sure lot’s of things can be done with resin.io API but the aspect of serving this to creator of devices (which are my customers) and their customers (which are the creators customers - who buy the product in the end) is something that simply cannot be done with resin.io API alone.

In the end a Gister Device-Type can also carry parameters like Publish/Subscribe Keys for PubSub, etc.

Thanks,

Simon

[lekkas]

Hey @simonkemper!

Thank you for your kind words!

So let me summarize a few points and please correct me if I’m wrong somewhere:

• Customers of the Gister operator that use ‘IoT-Sense’ app will have their device be part of the same underlying resin.io application/fleet - In other words, Gister Operator will be able to see all his ‘IoT-Sense’ customers by checking the device list in the underlying resin.io ‘IoT-Sense’ application.

• The Gister Operators either pre-provisions every device in the Gister ‘IoT-Sense’ application before shipping it to its customer or has the customer provision the device by downloading/burning the image to an SD Card. I think you were describing the latter in your use case. In either case, the Device Registry/DB of Gister Operator will be populated with the required information to keep track of [Gister Customer] — 1…* [device] relationships.

• From the previous points it’s implied that Gister Customers never have to use resin.io directly.

If the above points are true, I think your approach of introducing a Gister registry as an abstraction of the resin.io platform seems to be in the right direction. That way, IoT-Sense clients (e.g. smartphone app) will query Gister Registry and fetch the public-url as you describe. The Gister Platform will be able to fetch the public url info using the Gister Operator’s credentials for the ‘IoT-Sense’ application using the resin.io API (e.g by using resin-sdk)

I’m not sure if we currently provide scoped/limited access API keys for devices that Gister Customers would be able to use directly with the resin.io API (raised this internally with the team to get more info) - in any case, do you think that such a feature would help you with your use case? Note that clients would still have to go through a Gister API endpoint/service to facilitate the creation of a limited access API key.

Best,
Kostas

[simonkemper]

Hey @kostas ! You’re welcome! It’s always a pleasure to talk to one of you guys since there is always someone there to talk to … Amazing!

@kostas

Customers of the Gister operator that use ‘IoT-Sense’ app will have their device be part of the same underlying resin.io application/fleet - In other words, Gister Operator will be able to see all his ‘IoT-Sense’ customers by checking the device list in the underlying resin.io ‘IoT-Sense’ application.

Yes, the Operator will be able to see all his customers but not via resin.io just by using the Gister-Service.

@kostas

From the previous points it’s implied that Gister Customers never have to use resin.io directly.

Exactly.

@kostas

The Gister Platform will be able to fetch the public url info using the Gister Operator’s credentials for the ‘IoT-Sense’ application using the resin.io API (e.g by using resin-sdk)

Yes. Somehow. But it’s more that Gister is installed on the resin.io Device as some kind of daemon which interacts with the Gister-API each time the device is updated, etc.

On the device the Gister-Daemon is fed with Gister-User-Credentials and is able to communicate with the API. The Daemon also forwards the public-url (and any other user-definable info) to Gister-DB so that even in case the URL changes the Gister-DB will be up to date (each device in Gister has a UUID).

Basically the idea is to really decouple resin.io and Gister from each other having a system of connected microservices and the device (with its application) is the interface between those services!

I hope that makes sense!?

[lekkas]

@simonkemper

Yes, the Operator will be able to see all his customers but not via resin.io just by using the Gister-Service.

I’m a bit confused by the indirection levels and the how each stakeholder interacts with the separete APIs available, so please excuse me for the many questions - So Gister Operator will get customer/device info from the Gister-Service and, like Gister Customers, they don’t interact with resin.io platform directly, correct? So if I understood correctly, you will imlement and then provide provide the Gister API and Gister Service to your Gister Operator customers, right?

@simonkemper

On the device the Gister-Daemon is fed with Gister-User-Credentials and is able to communicate with the API.

That’s the Gister API, corect?

@simonkemper

The Daemon also forwards the public-url (and any other user-definable info) to Gister-DB so that even in case the URL changes the Gister-DB will be up to date (each device in Gister has a UUID).

Note that resin.io API is the source of the public URL information and not the device itself, so public URL info should be fetched from resin.io API, for instance using any of the available resin SDKs. resin.io is the source for more device meta-data (e.g. check the resin.models.device.get() examples here) but any other data produced by the device itself will have to be streamed/stored to a third party endpoint like the Gister API/DB)

@simonkemper

Basically the idea is to really decouple resin.io and Gister from each other having a system of connected microservices and the device (with its application) is the interface between those services!

I see, so IIUC, if separate devices are to communicate to each-other over public url, then each will have to fetch a list of its ‘neighbour’ public-urls by querying a special Gister API. Or you could instead use a publish/subscribe service as you already mentioned.

[simonkemper]

@kostas

Note that resin.io API is the source of the public URL information and not the device itself, so public URL info should be fetched from resin.io API, for instance using any of the available resin SDKs. resin.io is the source for more device meta-data (e.g. check the resin.models.device.get() examples here) but any other data produced by the device itself will have to be streamed/stored to a third party endpoint like the Gister API/DB)

I see. I really was pretty sure that using the Resin-Supervisor Device API I could access the UUID or public url (which is UUID + url-suffix).

I have to rethink first …

[simonkemper]

@kostas

Ok. Well then the only way of getting public-url via device is to access resin.io API from the device but that would mean that the “operator” would have to set the resin.io auth-key on the device as an application-wide variable.

Another way is having a device variable that the device is able to update. When the device registers itself via Gister-API the Gister-DB can answer with a UUID (which is assigned to the device). This UUID can be stored into the device variable and be read out via Resin.io API.

So the Gister-DB Application has to talk to the resin.io API and request the variable.

That’s what I came up with very shortly - in regard to using public-url.

When using a Pub/Sub service or any other (ngrok.com tunneling service, for example) the whole resin.io api thing is not necessary anymore.

But I WANT to use public-url - there’s no reason to reinvent the wheel

[lekkas]

@simonkemper If your goal is to get a device to know its own public url, why not have a Gister backend service to set the public url as a device variable directly - then the application running on the device would simply have to read the specific environment variable.

And now I’m really curious on what you’re working on!

[simonkemper]

@kostas Damn! That’s it! The missing piece … I really was thinking too complicated but your idea is great! Now I know where to start!

Good to hear that you are really curious to know what I am working on. I’ll keep you informed and will post updates here and let everyone know what I am working on.

Thanks for your great idea!

[lekkas]

@simonkemper Glad I could help, let us know how it goes!