You can see at how incoming PING requests sends a message back to the requesting node.
So... something like this:
(void)transportRouteMessage(build(_msgTmp, sender, NODE_SENSOR_ID, C_INTERNAL,
I_ID_RESPONSE).set(currentID));
See this remark:
@tekka said in MySensors 2.0.0 Released:
@mpp said in MySensors 2.0.0 Released:
pm open,type:2 0
This is a message emitted by the ESP8266 core, not MySensors related.
I suggest you add the following to enable debugging on the serial interface:
#define MY_DEBUG
Also tripple check your wiring, it seems to make the ESP very unstable if there's a loose/bad connection. TSM:FAIL:CNT could indicate a problem with the radio/transmission.
@briseis I would just switch back to 2.3.2
I also believe 2.4 on the gateway should work with nodes on 2.3.2. what kind of errors did you get when doing this?
@NickBuilder said:
Thank you @mfalkvidd for the very educational description. I thought that the check could have been as you described but I felt that it was too crude and simple. This doesn't seem to be the most typical use of "exclusive or" but I guess it does the job.
There are more advanced ways. This scheme will not detect two bit errors in the same group (even or odd) and it can only detect errors, not correct them. But without knowing the reasoning behind the design it is impossible to say if it was a bad choice or not.
Is it common to only include part of the transmission packet in the parity check? I would have assumed that the nib (Nib4) should be part of the bit check and that the parity bits would then be set or not set so that the complete packet is confirmed.
Yes, it is common to exclude things. What things depends on the use case.
From what I understand, the exact same message is always sent three times. If the z-bits were included in the checksum, a new checksum would have to be calculated for each time the message is sent. That would probably have a negative effect on the communication speed and would add complexity to the solution without adding any real benefit.
If the checksum bits themselves (C) were included in the checksum calculation they would affect the checksum so the checksum would change so the checksum would have to be calculated again which would cause the checksum to change so the checksum would have to be calculated again and so on.
