hawkbit icon indicating copy to clipboard operation
hawkbit copied to clipboard

Better gateway system

Open Nopik opened this issue 7 years ago • 2 comments

In some IoT deployments, especially mesh-based, all devices are divided into groups (meshes). They can communicate with each other (e.g. by proprietary radio), but not with the Internet. Each mesh typically have 1 or more border router devices acting as a gateway between mesh and rest of the world. Protocols such as Zigbee, Thread etc. do this, just as all 802.15.4 / 6lowpan devices.

It would be great if HawkBit could support such scenarios, especially that 90% of the stuff is already there.

My proposal would be to:

  • add a concept of gateway to the system, in 'proper' sense, not all-or-nothing as it is now
  • allow adding targets to gateways, so gateway can act on behalf of assigned devices only
  • for starters, security done on gateway authorization token should be enough (so devices dont even need to know their security tokens). Just sending GET /{tenant}/controller/v1/{controllerId} with Authorization: GatewayToken foo should be enough, at least for first version.
  • some care should be taken to reduce amount of file downloads. I.e. I would expect that the case of updating all devices together within a mesh network will be a common case. If that happens, there is no point of GW downloading the same firmware upgrade image over and over again, for each target from different URL. Currently deploymentBase endpoint returns list of artifacts and their http download links, who have /softwaremodules/<id>/artifacts/ in their urls, but it would be great just to add something like { softwareModule: { id: 8 } } or something to the artifact list, so gateway can easily detect that this file is already downloaded locally.

That's it, actually. With those changes it should be possible to handle mesh networks in pretty good way. What do you think about such approach?

Nopik avatar Apr 07 '18 13:04 Nopik

Just for clarification, I'm thinking about very simple approach to gateway model. In database it should be enough to store following information per gateway:

  • some id/name for easy references
  • list of assigned devices
  • authorization token
  • optionally tags as well

All rollouts would still pointing the targets themselves, maybe with some gateway.id = 42 or gateway.tag.tenant = 42 filtering. In order to update software gateway, a target would need to be defined, either within its own group, or free-standing.

Nopik avatar Apr 07 '18 14:04 Nopik

Sounds good! We highly appreciate your idea of multiple "mesh based gateways". As you pointed out the concept of a single gateway is already there

schabdo avatar Apr 11 '18 11:04 schabdo