Create autoEvent fails

[IkerDC]

TL;DR:

For our use case, we have several devices with running autoEvents. From an app service in the North, we are subscribed to events of those devices. When an autoEvent is received, we do something. However, we also need to know when the autoEvent has failed, because in that case we have to do something else.

Question:

Is there a way to know when a device autoEvent has failed?

[mglmc]

As Iker said, there is a problem here with using autoevents for pulling actions for protocols that don't have last will or something similar, such as Modbus or REST. In these cases, it is useful to know when the device is down, so that we can take appropriate action.

We have been working on a solution to this problem, and we have found a way to notify the north side when an autoevent has failed. We do this by sending an ASYNC message.

For example, for Modbus devices, when an error happens in the connection, we send an async event with the resource failedConnection

We believe that this is a useful feature that could be helpful for a lot of EdgeX Foundry developers. We are wondering if it would be possible to add this feature to the official device service, or if it could be implemented as an example device service in another place.

Please let us know your thoughts.

[cloudxxx8]

@lenny-intel we got similar request from other users. When the southbound or northbound connection go wrong from Device Service and App Service, we may send out a system event as an alert. Ideally, Notifications Service should be able to receive and process this alret. Maybe we can plan the system event in the next release.
@IkerDC for now, you may adopt @mglmc 's suggestion to implement something in your device service.

[lenny-goodell]

@cloudxxx8 , Sounds like a good topic for discussion for next Core WG meeting.

[cloudxxx8]

@lenny-intel oh, I missed this today.
@jumpingliu please put this topic into the agenda of our next Core WG meeting

[jumpingliu]

@cloudxxx8 ok added.

[mglmc]

Glad to hear that. I really think that is a mandatory FTR for a lot of use cases. Meanwhile, we'll be using this workaround.