@hek You are right, I forgot that I configured my controller to respond to a I_CONFIG request by sending an 'M'. Apparently, a config request and an answer to I_PRESENT are the same message, so my controller does not differentiate its behaviour.
Anyway, thanks for your fast reply, this really helps me out!
@hek After a week, I've found some time to test your advice and tried to send the I_PRESENT-message to some of my nodes. The reply that I get unfortunately is not totally clear to me. Can you help me out some more? I've tried sending the message to nodes 1 (being closest to the gateway) and 4 (being far from the gateway and with some nodes in between). I got the following response:
Sent to module 1:
1;255;3;1;19;
Received from module 1 (duplicate lines removed):
1;255;0;0;18;2.0.0
1;255;3;0;6;0
1;255;3;0;6;M
1;0;0;0;6;
1;1;0;0;7;
1;2;0;0;1;
Sent to module 4:
4;255;3;1;19;
Received from module 4 (duplicate lines removed):
4;255;3;0;6;3
4;255;3;0;6;M
4;255;0;0;18;2.0.0
4;255;3;0;6;3
4;2;0;0;3;
If I had to guess, I'd say that the lines '1;255;3;0;6;0' and '4;255;3;0;6;3' are the ones that I am looking for. They seem to tell me that
Before I draw conclusions, however, I'd really like to know if I'm correct. Can you confirm this? And if so, can I safely assume that any I_CONFIG-message received not containing an 'M' or 'I' in the payload tells me the parent-node?
Thank you very much!
@sundberg84 Great, thanks!
(pity that there is no official doc, however, but this should suffice for now)
@mfalkvidd Thanks. It might be the case that I can find each node's parent in the EEPROM, but I would like to be able to read the topology "run time". I.e., while the system is in production.
@hek This might be what I was looking for, thanks, I'll try it out!
@sundberg84 Thanks! Unfortunately, the API does not tell me anything about the contents of the payload of internal messages like
Init complete, id=0, parent=0, distance=0, registration=1
TSP:MSG:READ 3-3-0 s=1,c=1,t=1,pt=7,l=5,sg=0:62.00
TSP:SANCHK:OK
I can guess what some of these things mean, but I would really like to read some documentation to make sure that my interpretations are correct.
Impressed by what MYSController does, I would like to add some functionality to my home-built controller to be able to view the network topology (i.e., which nodes are connected to which nodes by which routes). I suspect that the information that I need is hidden in the log messages that are received by the controller, but I haven't been able to decipher them.
Can anyone tell me where I can find the information about the network topology that is apparently used by MYSController?
(and while I'm at it: is there some kind of documentation that tells me what all the "internal" messages mean?)
According to the NRF24L01+-datasheet, the device has a "6 data pipe MultiCeiver[TM]". It is not entirely clear to me what this means for a MySensors-network running on NRFs. I get the feeling that I can only add 6 modules to a gateway if I don't use any repeaters (since the gateway-NRF can only simultaneously connect to 6 other NRFs). Is this correct, and is adding repeaters the only way to increase my network size, or am I mistaken?
Thanks ia for your response!
I am building my own controller (in Python) and although most of it seems to work now, I haven't built functionality that resends not-acknowledged messages yet. I am planning to do so, but I can't find any documentation about how I can recognise an "acknowledged"-message. I know how to send one, but I don't know what I'm expected to receive back as acknowledgment.
Some tests show me that the controller literally repeats the message when that was sent by the controller, but before I start building, I would like to know if this is indeed how these messages were designed.
TL;DR - Is my assumption correct that messages with an ack-request are replied to with an exact copy of that message?