Reading through secondary addressing

[Pelmar]

Good day,

I´m new using libmbus, and I´m experimenting problems to read using secondary addressing. I have one Sontex 531 Mbus slave that when i read using primary adressing works fine.

Mbus-tcp-request-data –d 192.168.1.163 10001 5

[2015-12-10 14:51:07] SEND (017): 10 7B 05 80 16 [2015-12-10 14:51:08] RECV (125) : 68 77 77 68 08 05 72 66 87 24 16 EE 4D 0D 04 94 30 00 00 05 5B 00 00 00 00 05 5F 00 00 00 00 05 3E 00 00 00 00 05 2B 00 00 00 00 01 FF 07 01 05 96 28 B4 A2 91 39 05 FF 01 AC 0D C2 3D 05 FF 02 36 89 C7 3E 01 FF 04 01 01 FD 0F 2A 02 FD 0D 29 00 03 22 FB 0D 00 01 70 1E 82 89 01 FD 25 3C 00 82 82 03 FD 26 18 00 02 EC 7E 01 0F C2 84 01 EC 7E 01 07 82 85 01 EC 7E 01 01 1F 00 16.

I would like to read using secondary addressing, becase i have two slaves that i can´t change the primary ID and always 0, so they can´t be in the same bus.

But when i use the secondary address with the mask.

Mbus-tcp-request-data –d 192.168.1.163 10001 16357551FFFFFFFF

[2015-12-10 14:54:07] SEND (017) 68 0B 0B 68 73 FD 52 51 75 35 16 FF FF FF FF CF 16 [2015-12-10 14:54:07] RECV (001) E5

the call gets stuck. but if a execute mbconfig with secondary adressing 2 minutes later

[2015-12-10 14:56:07] SEND (005) 10 5B FD 58 16 Failed to receve M-Bus response frame: M-Bus tcp transport layer connection close by remote host.

If i compare the request with the one done with the mbconfig. The first one is the same,but before receiving the acknowledge (E5) the new message sent is different in one byte and in the checksum.

libmbus : 10 5B FD 58 16 MBconfig: 10 7B FD 78 16

Which coud be the problem?

I´m using a Ethernet to Serial converter for the task.

Best regards

[lategoodbye]

Hi Pelmar,

have you tried https://github.com/rscada/libmbus/tree/fix-fcb-handling ?

[Pelmar]

Hi lategoodbye,

Yes , i used the last compilation /fix-fcb-handling

Thanks for your help

Best Regards

[lategoodbye]

Hi Pelmar,

does it mean the issue fixed in this branch?

[Pelmar]

Sorry for the delay, I don´t get online very often. No, I used the last compilation /fix-fcb-handling and the error was still there. Using primary addressing everything ok, but with the secondary it gets stuck.

[Apollon77]

@lategoodbye I experienced the same issue with one user of my node-lib (see https://github.com/Apollon77/node-mbus/issues/14) I solved it a bit more hacky as an experiment (see https://github.com/Apollon77/libmbus/commit/bdf0a92547276fc3e324667959fe15e6da8bb228) ...

Your idea here is to enhance one method ... this is not really backward compatible - that's why i decided for a new method ... what is the preferred option?

[Apollon77]

@lategoodbye Any feedback on my last comment/question? I still have this topic kind if open for my node-lib

[lategoodbye]

Sorry, i don't have a clear answer to this problem. Neither of those hacks are a good solution. But i agree with you about the backward compatibility.

I think a first step would be the following:

• add a new function mbus_send_request_frame_fcb with additional parameter frame count bit
• make mbus_send_request_frame call the new function in order to avoid copy & paste

[Apollon77]

Ok, I will provide a PR (but unsure if i make it before my vacation, could be beginning of june).

Do you have seen how I implemented it? I only use the fcb variant if the result of "mbus_select_secondary_address" was a MBUS_PROBE_SINGLE ... if this is not the case I still use the old processing. makes this sense? The standard is kind of unspecific there

[lategoodbye]

I think it's a bad idea to implement this FCB handling without a test setup. Sorry, i also need to look at the standard.

[Apollon77]

The FCB solution I have as hack is at least verified by one user of my node-lib as working (so it is not only test setup, it is also the need for devices that respect react like this :-(

[Apollon77]

found that one: www.m-bus.com/files/MUTFCBN5.pdf ... but i do not completely understand it :-(

[Apollon77]

@lategoodbye I got one user with a big ">70 devices" setup to test my library version with the changed FCB handling (https://github.com/Apollon77/libmbus/commit/05134e7e608111455ce64dfe9293cd7bffcd686a together with https://github.com/Apollon77/node-mbus/commit/4ff23ce983505da776f09dcc179b2b69c12e23ad ) and for him everything worked as before too ... I think we can not do more testing :-)

If ok I will provide a PR the next days

[lategoodbye]

As long as the setup doesn't use 70 devices which doesn't support FCB handling ;-)

I'm happing about a pull request.

[Apollon77]

Just found that info today ... need to think about it:

This mechanism is activated if the FCV-bit is set to one in the Request Frame generated by the Master, otherwise the mechanism is ignored by the Slave. The FCB/FCV protocol allows a safer transfer from Slave to Master when the Slave response has more than one Long Frame. After a SND_NKE Procedure, the Master transmits in the REQ_UD2 RSP_UD a Control Field with FCB-bit set to one (Control Field = 7Bh) and the Slave will reply with the first Long Frame. If this data is correctly received from the Master, the Master itself will send to the Slave a new Request Frame with the FCB-bit cleared (Control Field = 5Bh), hence the Slave will send the next Long Frame. On the contrary, if the Master did not correctly receive the first Long Frame from the Slave, it can send to the Slave the Control Field = 7Bh another time, in this way the Slave will repeat the First Long Frame. The same is valid for the Second Long Frame. The last Long Frame transmitted by the Slave does not have the MDH Field, this absence has to be interpreted by the Master as the receipt of the last Long Frame from the Slave. After a SND_NKE procedure, the slave is always set on the first frame, even if the last transmitted frame was not the last.