TCP Agent not writing

Agents, Protocols and APIs
1

Hi,
im running a TCP server on an nodeMCU and i have created a TCP Agent Asset that is conecting to it. When i write from the server to openremote, the attribute with the agent link does not receive the message. Is there some special value filter in the agent link that im missing?
Thanks!

2

Hi,

The agent link requires the messageMatchPredicate to be set; I realised that there wasn’t a ValuePredicate that would match any incoming message so I’ve added the Any Value predicate.

There’s been some updates to the AgentLink UI as well, here’s what you need:

image
image816×465 16.4 KB

There’s nothing to configure on this predicate; if you don’t want to match all incoming messages then you can use one of the other predicate types.

You’ll need to wait for a manager docker image that is newer than this post (as our pipeline is currently building it).

Let us know if you get things working.

ATB,

Rich

3

Hi Rich,
setting the message match predicate does not fix the problem. When i send data from openremote attribute to the tcp server, the attribute tells “Send failed” but the data is reaching the server. When i send data form the server to openremote, nothing changes in the attribute. Some ideas? Thanks!

4

When writing an Attribute value in the UI it expects the attribute to actually be updated by a message coming from the server.

Generally attribute writes with agents work this way:

Attribute Write Request -> Agent -> Server -> Agent -> Write to Attribute

Writing to attributes is asynchronous so some sort of incoming message is expected to acknowledge that the request was completed; this can get complicated quickly (i.e. does the server use message IDs so request response can be associated) and what you can do with the generic protocols is limited but messageMatchFilters and messageMatchPredicate give a reasonable amount of capability.

I could look to add an option to the AgentLink to updateOnWrite so as long as the server receives the message the attribute would be updated without any response from the server.

5

Hi Rich,
I have read your answer carefully, what you said make me know more about the system. But I can not find the option of updateOnWrite. Can you tell me how can I do this ?

Thanks a lot.

6

The same as your situation. Have you solved this?

7

Just added this updateOnWrite agent attribute, please try a manager docker image which is newer than this post (will take about 30mins from now to be updated).

8

Hi Rich,
updateOnWrite is working great! Im having issues catching a message send by the server to an attribute, any help? Thanks

9

Glad to hear updateOnWrite solves your use case.

As for updating an attribute from a server message please share:

  1. Your attribute Agent link (you can edit the json and copy paste that)
  2. The message that your server is sending that you expect to update the attribute
10

Agent link:

{
  "id": "75Va00a0Qsnz0Nw4KZS9jI",
  "messageMatchPredicate": {
    "predicateType": "value-any"
  },
  "type": "DefaultAgentLink"
}

Im trying to catch a string of text from the server. The attribute linked with this agent is text type. Thanks!

11

Hi Rich,
I have updated docker image and seen the updateOnWrite attribute. I have followed your suggestion but the agent didn’t receive the message from the tcp server. Any ideas?
Thanks!
{
“id”: “4yuDmM3Ccta0AQicxiOPpm”,
“messageMatchPredicate”: {
“predicateType”: “value-any”
},
“type”: “DefaultAgentLink”
}

Thanks a lot for your help. Now I can receive the TCP message.

12

Hi,

I have now covered the updateOnWrite and message match predicate value-any with a test and can confirm both are functioning correctly.

I think the problem you have is with your TCP Agent attributes; most likely you haven’t specified Delimiters or Max length which are used to determine where the end of a message is.

I have now made a code change so if neither of these are specified then the TCP, UDP, and Serial agents (all generic IO agents) will default to using the new line delimiters (\r\n or \n) which are widely used; if your server doesn’t use these delimiters then please adjust accordingly.

To get this update, get the latest manager docker image or specify these attributes on your TCP agent.

13

Hi Rich,
Indeed that was the problem. Now works flawlessly. Thanks!

14