Add optional reset-before-request-data

[arska]

1. refactor device reset/de-select
2. add optional reset-before-request-data

This feature is needed to read Sontex Supercal 531 reliably

[arska]

fixed both issues

[lategoodbye]

Sorry, but i don't think mbus_init_slave and mbus_init_slaves_str are a true benefit to the library. Why not using mbus_send_ping_frame() directly? It's an issue in mbus-serial-request-data-multi-reply.c so it should be fixed there.

Here is my suggestion add additional mbus_send_ping_frame with address = MBUS_ADDRESS_BROADCAST_NOREPLY add the end of mbus_init_slaves. I don't like new parameters for "special" devices. It's good if the tools work generally.

Does it fix the issue with Sontex Supercal?

[arska]

I removed mbus_init_slave* completely, you are right they have too little functionality of their own.

Certain devices need to be reset, I don't like to side-effects of sending a broadcast reset to all devices. Other implementations also offer to send reset before request (e.g. Terminal-Systems MGW986).

[lategoodbye]

But we don't send a SND_NKE in case of a secondary address. (Yes, i know that a SND_NKE deselect the slave but nobody prevent us from resending a select again).

As a user i would expect the same reset behavior. Doesn't #90 appear in case of secondary address?

[lategoodbye]

Hi @arska, do you think #97 is related to this issue?

[delreich]

I don't see how this, in its current form, solves anything. You'd have to be very careful (or lucky) to avoid duplicate frames.

Quoting "The M-Bus: A Documentation, Rev. 4.8" (page 28-29):

The master must always contain a "Next REQ_UD2-FCB-image bit" and also a "Next SND_UD-FCB image bit" for each primary slave address used by its application layer. After sending a SND_NKE-request to a slave adress both these "Next FCB-image bit" associated with this address contained in the request must be set. Thus for each primary address the first REQ_UD2 or SND_UD telegram after a SND_NKE contains a set FCB-Bit.

Note that after a memory loss (usually due to a power failure) of these "Next FCB-image bits" the master is required to send a SND_NKE to all affected addresses. All subsequent RSP_UD2- telegrams must contain the "Next REQ_UD2- FCB-image bit" of the appropriate primary address as a FCB. This "Next REQ_UD2 FCB- image bit" is toggeled after an error free link layer RSP_UD telegram has been received.

The default really, really should send resets, and then start with the FCB-bit set (i.e. C=7B for the first REQ_UD2). This should apply to all cases (multi-reply or not, primary and secondary addresses).

Currently, the only correctly working scenario is multi-reply with secondary addresses. Secondary addressing is the only way to get a proper reset, and multi-reply is the only way to get correct FCB-bit handling (given proper reset).

If you want / need a way to skip the reset, you'll also need to specify somehow what state you ended in previously. Supplying the number of read frames might work. I can't think of a reason to do this though.

I don't see any reason to always send a reset to secondary address. Secondary selection is essentially a reset in itself, from what I understand.

Page 64:

A valid selection telegram will not only set the internal selection bit but will also clear all [...] internal "Last received FCB"-memory bit(s) associated with secondary addressing via the pseudo primary address 253 ($FD).

Only way I can see that would allow continuing requests to a secondary address without resetting, would be to explicitly use 253 for follow-up requests. Again, though, I can't see a reason.

I would suggest that, instead of adding an option and all that, fixing the reset (to use the correct address, and only for primary) and FCB- handling (in the single-reply case) is the way to go.

cc @Spindel

[Spindel]

I don't have much to add there, @delreich. More options won't really fix the somewhat broken state it's in right now, and I've always been disappointed in seeing an "--unbreak-something" option for any software.

[delreich]

Looks like mbus/mbus-protocol-aux.c could do with some refactoring. There's several functions there that do very similar things in subtly different ways.

Quick examples:

• mbus_sendrecv_request largely reimplements mbus_send_request_frame (only with working FCB-handling) when it should be calling (a fixed version of) it.
• mbus_read_slave is almost, but not quite, a single-frame version of mbus_sendrecv_request, except it also does secondary address selection (and thus reset) and uses the broken mbus_send_request_frame.

Might be more, but 8pm on a Friday isn't really the time to be looking for them.