Persist Payload Data Through Modbus Read

General
1

I've got a flow setup where a CSV file is parsed for various items of data, the most important being and electricity meters "name" and then all the information required to read it via Modbus. I have managed to get the Modbus to work but the "name" doesn't make it through the "Modbus - Flex - Getter" node.

I have thought about using a "Split" and "Join" node but that would make a new message for every property of the modbus information, which I don't want.

The payload going into the "Modbus - Flex - Getter" node has all the data, the payload coming out has only the value read from the Modbus device. What's the best way for me get the original payload with a new item named "meterReading"?

Thanks.

2

Welcome to the forum @igloodan

If you copy the name to a top level message property such as msg.meterName before the modbus node then, if the node is well behaved, it should still be there in the message passed on.

3

Hi Igloodan,

yes .. msg.payload is replaced by the Modbus Flex Getter node with the modbus register values reply .. and unfortunatelly the node doesnt keep the properties of the original msg ..
but i believe you can preserve the original payload (or any other properties) with the following example.

Consider having a simple read

image
image833×77 6.09 KB

In the Function node you can pass in value all the data that you want to preserve.

msg.payload = { 
    'value': {originalPayload: msg.payload, myKey: "test"},
    'fc': 4,
    'unitid': 1,
    'address': 0,
    'quantity': 120
} 
return msg;

That you can later pickup from msg.modbusRequest.value

image

Test Flow:

[{"id":"d7423fb4.625788","type":"function","z":"981a2a72.4329f","name":"FC4","func":"msg.payload = { \n    \n    'value': {originalPayload: msg.payload, myKey: \"test\"},\n    'fc': 4,\n    'unitid': 1,\n    'address': 0,\n    'quantity': 120\n    \n} \nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":310,"y":940,"wires":[["5f36b457.bc277c"]]},{"id":"5f36b457.bc277c","type":"modbus-flex-getter","z":"981a2a72.4329f","name":"","showStatusActivities":true,"showErrors":true,"logIOActivities":false,"server":"bf37180a.2d18e","useIOFile":false,"ioFile":"","useIOForPayload":false,"emptyMsgOnFail":false,"keepMsgProperties":false,"x":560,"y":940,"wires":[["19f8c57d.a690e3"],[]]},{"id":"6b38e4c3.61cac4","type":"inject","z":"981a2a72.4329f","name":"trigger","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"temperatures","payload":"","payloadType":"date","x":140,"y":940,"wires":[["d7423fb4.625788"]]},{"id":"19f8c57d.a690e3","type":"debug","z":"981a2a72.4329f","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":770,"y":940,"wires":[]},{"id":"bf37180a.2d18e","type":"modbus-client","name":"","clienttype":"tcp","bufferCommands":true,"stateLogEnabled":false,"queueLogEnabled":false,"tcpHost":"192.168.1.66","tcpPort":"502","tcpType":"TPC-RTU-BUFFERED","serialPort":"/dev/ttyUSB","serialType":"RTU-BUFFERD","serialBaudrate":"9600","serialDatabits":"8","serialStopbits":"1","serialParity":"none","serialConnectionDelay":"100","unit_id":1,"commandDelay":20,"clientTimeout":1000,"reconnectOnTimeout":true,"reconnectTimeout":2000,"parallelUnitIdsAllowed":true}]
4

That is a pity. I think that is arguably a bug in that node. Certainly it is breaking the convention.

5

After further reading on the Flex Getter node's settings .. it seems that there is an option to pass on properties of the original msg. Its not enabled by default but you have to check Keep Msg Properties.

image

So whatever data you need to pass on, dont leave it msg.payload but have it in other properties like
msg.deviceName = "myMeter1" etc

ps. apologies for the confusion, even though passing data with the use of value would have worked also

6

It is odd having that optional, it is very unusual to have the situation where you would want a node to discard other properties.

7

UnborN,

Thanks for your first (and subsequent) help with this.
Why is it that an object within the original payload makes it through, but not values?

Thanks.

8

While we're on the topic of the Modbus Flex Getter node, what is actual difference between the two outputs other than the order of what is returned?
The below seems to suggest that it's exactly the same data but in a different order?

Output 1: data Array (PDU), modbus response Buffer, input message

Output 2: modbus response Buffer, data Array (PDU), input message
9

It seems the 2nd message gives you access to the original message. It might have been added at a later time for the reasons above?

10

It looks like "input message" is listed on both outputs though!?

11

Can you share a simple flow and screenshots to better visualize what you are asking ?
Use Debug nodes before and after your Flex Getter and show as the results.
Set them to show Complete msg object
image

.. yes the order and structure of the reply msg from two outputs differs a little but it practically has the same data.

12

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.