Skip to content
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

Closed
KenRenAtHilti opened this issue Sep 1, 2023 · 6 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@KenRenAtHilti
Copy link

KenRenAtHilti commented Sep 1, 2023

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)

@marcschier marcschier self-assigned this Sep 1, 2023
@marcschier marcschier added the feature request New feature or request label Sep 1, 2023
@marcschier marcschier added this to the 2.9.2 milestone Sep 1, 2023
@marcschier
Copy link
Collaborator

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.

@KenRenAtHilti
Copy link
Author

Thx.
Would be better if a global command-line option is also provided. To read the monitored item for the first time when the publisher module is restarted or new nodes are added through some direct method like SetConfiguredEndpoints.

@marcschier
Copy link
Collaborator

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.

@KenRenAtHilti
Copy link
Author

KenRenAtHilti commented Sep 7, 2023

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.

@marcschier
Copy link
Collaborator

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?

@marcschier marcschier changed the title Read init value for new nodes after calling SetConfiguredEndpoints First Heartbeat message send has GoodNoData even though the monitored item is not yet live Sep 7, 2023
@marcschier marcschier added bug Something isn't working and removed feature request New feature or request labels Sep 7, 2023
@KenRenAtHilti
Copy link
Author

Thx. It is tested and the fix works as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants