-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First Heartbeat message send has GoodNoData even though the monitored item is not yet live #2041
Comments
The ask is a flag per node/endpoint to read a value into the "lastValue" field of the monitored item, similar to Displayname so that it can be sent in keyframes or heartbeats. This is something we can put on the 2.9.2 backlog if I have captured the ask correctly. Marking as feature request. |
Thx. |
While fixing another issue I noticed that the reason we see mostly GoodNoData here is that the heartbeat timer starts off before the monitored item is even applied to the subscription. That is of course not intended and will be fixed (part of the fix is already in main). The heartbeat should be sending the last received DataValue (again). OPC UA ensures that the first value received after the monitored item is created is the value of the variable, so shortly after creating the monitored item the value would be there just like reading it using read service call, so reading it is redundant. This data value received in the first publish response as per spec "could" however have a Status code that identifies an access denied error or identifies that the underlying system is still being connected to. But in that case, I am not sure if a ReadValue will actually return anything useful either. And then there is the case where a node is deleted from the address space, or goes away, or the user publishing is not allowed to see the data while the publishing request is ongoing. OPC UA specifies that a DataValue with a corresponding status code is then sent. So, the question here is how Heartbeat should actually behave if the last value received has a DataValue with a StatusCode other than "Good". Should the last known "Good" and valid value be sent then continuously? Or should OPC Publisher send the last received data value regardless of the status code and value validity? Should this be customizable? I would morph this feature request into this direction then. The other aspect here is that what might be desired. |
The real issue for us is mentioned in the first part of the response and we need this fix ASAP. Current temp solution to solve this GoodNodata is to restart our broker and thus the data value is renewed to the current value. Regarding the behaviour of heartbeat, i would prefer that the output should reflect the current/latest status of the monitored item for the purpose of transparency. This is the same kind of the request as for the bugfix: always shipping the current status of the desired node, either it is disconnected or "GOOD" when no value change happened. |
Great, if you would not mind, could you test "mcr.microsoft.com/iotedge/opc-publisher:2.9.2-preview2" build to see if this fixes this issue for you or if you have more needs? |
Thx. It is tested and the fix works as expected. |
Is your feature request related to a problem? Please describe.
After calling SetConfiugredEndpoints in 2.9.1, the new nodes would be in the State GoodNoData instead of the current value of the nodes if the value of the nodes is not changing after the updates of nodes.
Describe the solution you'd like
After new nodes are updated, the current value of the nodes should be read once for init value and published.(We are using heartbeat setting, so every timeout, if no data are sent, the latestest output would be sent still)
The text was updated successfully, but these errors were encountered: