Notification-based monitoring of update statuses

[lizziemac]

Hi there!

I am integrating hawkBit into my backend service, and currently am implementing a polling strategy for monitoring the update status of each device, after an update is started. Is there a more asynchronous way to do this? Ideally one that doesn't require knowing that an update was started, yet is still resource conscious.

• I noticed that the UI is using web sockets to monitor events, is there a way to use the web sockets outside of the UI?
• Alternatively, is there a capability to implement web hooks?

I'm also curious if either of the above are or could be roadmapped, as well as general expected effort. I'd be interested in implementing the web hooks but I haven't worked in this project before, so I'm not sure what the level of effort would be for a newcomer.

Cheers! Liz

[avgustinmm]

Hi @lizziemac, hawkBit provides Device Management Federation - you could receive the updates asynchronously on AMQP topics. This API targets exactly integrations with existing backend systems.

[lizziemac]

Oh perfect, thanks so much!

[avgustinmm]

Just one note. AFAIK, events are triggered when assignment is created. If your need to re-trigger device events (e.g. your backend has read the event but failed to deliver to device) I think you could do that by sending THING_CREATED event to hawkbit.

[lizziemac]

Thanks for the extra detail @avgustinmm

I did a proof of concept by messing with the messages directly in RabbitMQ, and noticed that when I created a device there with THING_CREATED, the address was set to the correct queue, enabling me to listen in on events created by the UI, HTTP requests, etc. This was without a real device, so I was just creating deployments and canceling them, and seeing those events get passed to the queue.

However, I came across an issue when testing with a Raspberry Pi. I created the device on my backend with the REST API, and set the address there as the RabbitMQ/AMQP address I want to eavesdrop with. However, when the device checked in for the first time, it overwrote the address, and my backend is no longer getting updates when distributions are assigned/actions are canceled. Does the target also have to be connected to/communicating via RabbitMQ? It was my understanding this was a way of passively listening to events.

I'm guessing my understanding of the device address was wrong (which in retrospect makes sense). Is there another parameter I can modify instead so that:

1. The physical device communicates via DDI to hawkBit
2. The backend can listen in via DMF to events happening on the hawkBit layer

The Raspberry Pi is using the SWUpdate Suricatta daemon, and authenticating with the target token.

Edit: For further context/clarification, the intent is to have hawkBit communicate directly with the devices, and for my backend to just observe events as they happen.

[avgustinmm]

I'm afraid I've mislead you. DMF is used for integration when your device is actually communicating to hawkBit through your backend. So the communication is: device <-> your backend <-> AMQP <-> hawkBit. If you do this - i.e. being a proxy between device and the hawkBit you'll be able to intercept update assign events (as well as device feedback). However, what you want, AFAIU is to just get notifications not to actually being involved in updates. In this case DMF won't work for you

[lizziemac]

what you want, AFAIU is to just get notifications not to actually being involved in updates. In this case DMF won't work for you

Yes that's correct. I've been ruminating on this over the past week, and I was curious about the following:

• If I were to implement this on my own, could I leverage the existing DMF architecture, and add an additional field to devices called something like eventForwardingAddress?
  • This forward address would pass all events (action status updated, update canceled, update started, etc) to the forwarding address.
  • Initially, I would use AMQP since it ensures no lost messages, but developers in the future could theoretically use/implement HTTP for webhooks
• I'm not sure this would still exist under DMF architecture, but I would think it might since it still uses AMQP/RabbitMQ

What do you think the above effort would be? It is definitely theoretical at this point, I would need to make sure I can get the time to implement it, but overall it could be a valuable addition.

[lizziemac]

@avgustinmm Friendly bump to hear your thoughts. I'm currently using a "polling" method that queries hawkBit's action status endpoint, but I realized that it's very likely that unique steps that are quick will be missed, unless they are sent proactively from hawkbit.

[avgustinmm]

@lizziemac, sorry, somehow, I missed your previous post. I don't know how DMF will fit your use case. It seems too far from your use-case. I would rather think about hawkBit eventing - you could listen for the events you are interesting in and resend then wherever you like - websocket , HTTP endpoint or AMQP exchange (for instance org.eclipse.hawkbit.repository.event.remote.entity.ActionCreatedEvent/ActionUpdatedEvent). This eventing mechanism is a spring's feature, so, spring may even have some tools to send them directly to somewhere.

[lizziemac]

thanks @avgustinmm I'll look into it! I'll re-open the ticket if I hit any design issues/etc