Device OperatingState should be recovered when Assertion passed

[cloudxxx8]

Currently, we modify Device OperatingState to down if the Assertion failed.
According to the user feedback, we should recover the OperatingState to up if the new value passed the Assertion
https://edgexfoundry.slack.com/archives/CE4KJ5VV2/p1615486753098600?thread_ts=1614784173.077200&cid=CE4KJ5VV2

[cloudxxx8]

@iain-anderson do you agree with this change request?

[iain-anderson]

If Operating State is down, autoevents will stop and /api/v2/device requests will be blocked.
We could do something on the Async channel? If an event is posted to it we could check OperatingState and if it's down, change it to up (unless the assert fails again)

[cloudxxx8]

I thought we should stop communicating the Device when adminState is Lock.
OperatingState is Down means the Device is not working, but should we keep talking to it until it starts working again, and modify the OperatingState back to Up? AutoEvent could keep running.

[iain-anderson]

We could do that, and make OperatingState purely informational, but at the moment it's specified to deny access (ADR0011)

[cloudxxx8]

I would like to bring up this topic in the WG meeting.
Furthermore, if assertion accepts regular expression, it would be more useful.

[jpwhitemn]

Per Device Service WG meeting of 3/22: if the assertion trips and sets the opState to down, then it requires human
intervention to reset the opState back to up and to allow the device to send data again - which is by design.
Use Patch device on metadata to reset the opState

[raycola]

Hi @jpwhitemn I agree with you, but consider that if resource assertion attribute could accept regular expression would be more useful as enhancement.
Thanks

[cloudxxx8]

I just opened #839 for discussing regular expression support in the future.