lategoodbye
commented
10 years ago @schnurksel
You are right it's a bug, the problem appear if there are at least two M-Bus devices with the same ID but different secondary addresses.
Open schnurksel opened 10 years ago
lategoodbye
commented
10 years ago @schnurksel
You are right it's a bug, the problem appear if there are at least two M-Bus devices with the same ID but different secondary addresses.
Hallo, I'm new with the libmbus and with mbus at all. I stepped through the code and found one point, that could be an issue, but may be I did not understand how the mbus protocol works: So lets explain my irritation: Within the function mbus_scan_2nd_address_range(mbus_handle * handle, int pos, char *addr_mask) all positions (16 "letters" each 4 bit) are stepped through and (when no other mask is given) will be probed with a wildcard "F" to see if a slave is connected which address matches. The first 8 positions (or lets say letters) contain the BCD encoded ID of the meter. Therefore if more than one meter is responding (collision case) all possibilities of this letters is probed again with all possile variants, that means with '0' to '9'. Thats right, thats fine and I understand this. Now follows my irritation: The next 8 letters are hex encoded, e.g. the manufacturer ID, the medium and the version. Here follows some examples: 00032629B5151002 for the EMU 3/75 professional 00202909CD4E0904 for the Elster F4 01305532CD4E0804 for the Elster F2 04990254C5140006 for the Engelmann WaterStar As anybody can clearlay see, the letters 0..7 are BCD encoded but the letter 8..15 are hex encoded. The letters 8..15 are probed too with the letter possibilities 0..9, but in my thinking they shall be probed with the possibilities 0..9 plus A..F. So when I'm right in reality in some combinations some meters shall not be found with the scan of the function mbus_scan_2nd_address_range(). Whats wrong with my thinking or is there really a bug within this function? Thanks in advance for checking my idea.