ECHO problems when sending with no payload

[frits]

sorry, ctr-c didn't work
Node:

 
 __  __       ____
|  \/  |_   _/ ___|  ___ _ __  ___  ___  _ __ ___
| |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
| |  | | |_| |___| |  __/ | | \__ \  _  | |  \__ \
|_|  |_|\__, |____/ \___|_| |_|___/\___/|_|  |___/
        |___/                      2.2.0

16 MCO:BGN:INIT NODE,CP=RNNNA---,VER=2.2.0
26 MCO:BGN:BFR
***********************************************
Hello MySensors 328P
Version 1.3
Radio type: NRF24
signing: no
32 TSM:INIT
40 TSF:WUR:MS=0
47 TSM:INIT:TSP OK
49 TSM:INIT:STATID=123
51 TSF:SID:OK,ID=123
53 TSM:FPAR
90 TSF:MSG:SEND,123-123-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
700 TSF:MSG:READ,0-0-123,s=255,c=3,t=8,pt=1,l=1,sg=0:0
706 TSF:MSG:FPAR OK,ID=0,D=1
2099 TSM:FPAR:OK
2099 TSM:ID
2101 TSM:ID:OK
2103 TSM:UPL
2107 TSF:MSG:SEND,123-123-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2117 TSF:MSG:READ,0-0-123,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2123 TSF:MSG:PONG RECV,HP=1
2127 TSM:UPL:OK
2129 TSM:READY:ID=123,PAR=0,DIS=1
2134 TSF:MSG:SEND,123-123-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
2142 TSF:MSG:READ,0-0-123,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2152 TSF:MSG:SEND,123-123-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.2.0
2160 TSF:MSG:SEND,123-123-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
2185 TSF:MSG:READ,0-0-123,s=255,c=3,t=6,pt=0,l=1,sg=0:M
2193 TSF:MSG:SEND,123-123-0-0,s=255,c=3,t=11,pt=0,l=20,sg=0,ft=0,st=OK:Hello MySensors 328P
2205 TSF:MSG:SEND,123-123-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.3
2215 TSF:MSG:SEND,123-123-0-0,s=0,c=0,t=36,pt=0,l=6,sg=0,ft=0,st=OK:system
2226 TSF:MSG:SEND,123-123-0-0,s=1,c=0,t=36,pt=0,l=9,sg=0,ft=0,st=OK:timestamp
2236 TSF:MSG:SEND,123-123-0-0,s=2,c=0,t=3,pt=0,l=3,sg=0,ft=0,st=OK:led
2244 MCO:REG:REQ
2248 TSF:MSG:SEND,123-123-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
2256 TSF:MSG:READ,0-0-123,s=255,c=3,t=27,pt=1,l=1,sg=0:1
2263 MCO:PIM:NODE REG=1
2265 MCO:BGN:STP
2267 MCO:BGN:INIT OK,TSP=1
49412 TSF:MSG:READ,0-0-123,s=1,c=1,t=47,pt=0,l=5,sg=0:hello
49420 TSF:MSG:ACK REQ
49424 TSF:MSG:SEND,123-123-0-0,s=1,c=1,t=47,pt=0,l=5,sg=0,ft=0,st=OK:hello
h
received message for sensor 1, type 47, value hello
56838 TSF:MSG:READ,0-0-123,s=1,c=1,t=47,pt=0,l=18,sg=0:next message empty
56846 TSF:MSG:ACK REQ
56850 TSF:MSG:SEND,123-123-0-0,s=1,c=1,t=47,pt=0,l=18,sg=0,ft=0,st=OK:next message empty
n
received message for sensor 1, type 47, value next message empty
60434 TSF:MSG:READ,0-0-123,s=1,c=1,t=47,pt=0,l=0,sg=0:
60440 TSF:MSG:ACK REQ
60444 TSF:MSG:SEND,123-123-0-0,s=1,c=1,t=47,pt=0,l=0,sg=0,ft=0,st=OK:

[karlheinz2000]

I again checked with latest 2.3.2 development lib. Same, ECHO does not work.
You use ethernet gateway, my is serial. This might be the difference...

13.11.2020 09:17:20	TX	70;0;1;1;47;
13.11.2020 09:17:20	RX	0;255;3;0;9;10969 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0
13.11.2020 09:17:20	RX	0;255;3;0;9;10989 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0
13.11.2020 09:17:20	RX	0;255;3;0;9;11008 TSF:MSG:ECHO
13.11.2020 09:17:20	RX	70;0;1;1;47;0

I now try to setup an ethernet gateway just for test.

[karlheinz2000]

Same with ethernet gateway (UNO, W5100)

gateway 2.2.0

10:25:06.047 -> 73634 GWT:RFC:MSG=70;0;1;1;47;
10:25:06.047 -> 73639 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=0,l=0,sg=0,ft=0,st=OK:
10:25:06.088 -> 73652 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=0,l=0,sg=0:
10:25:06.088 -> 73657 TSF:MSG:ACK

MYSController

13.11.2020 10:25:06	TX	70;0;1;1;47;
13.11.2020 10:25:06	RX	70;0;1;1;47;

gateway 2.3.2

10:30:45.718 -> 22546 GWT:RFC:MSG=70;0;1;1;47;
10:30:45.718 -> 22550 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0
10:30:45.718 -> 22561 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0
10:30:45.718 -> 22566 TSF:MSG:ECHO

MYSController

13.11.2020 10:30:45	TX	70;0;1;1;47;
13.11.2020 10:30:45	RX	70;0;1;1;47;0

Now I have to look for some ESP board...

[rejoe2]

@karlheinz2000
Which type of radio you are using? There might be a difference between nRF24 and other (RFM-based?) transceivers. So if possible, also make a test with 2.3.2 and nRF24.
Problem may be related to the change from soft ACK to ECHO (https://github.com/mysensors/MySensors/releases).

[karlheinz2000]

All tests are done with nRF24 radio only.

[rejoe2]

Thx, so this seems not to be the reason behind that.
Sth. else: If possible, it could be a good idea to add some more content to the thread title (ECHO in 2.3.2 changes message content)?

[frits]

the library differs the way it sends empty V_TEXT messages between 2.2.0 and 2.3.2.

2.2.0
10:25:06.047 -> 73639 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=0,l=0,sg=0,ft=0,st=OK:

note: length = 0, payload type = 0

2.3.2

10:30:45.718 -> 22550 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0

note: length = 1, payload type = 1

[frits]

I think the issue found it's way into the library here:
https://github.com/mysensors/MySensors/commit/74e566f5602261ba58e9a7fb06357810ae793b0b#diff-75e571c3ad1b2847e816b36b077fb7306d69ac8386b59d600a265f12bee1f8ba

old code:

	// payload
	if (command == C_STREAM) {
		uint8_t bvalue[MAX_PAYLOAD_SIZE];
		uint8_t blen = 0;

new code:

	// payload
	if (str == NULL) {
		// no payload, set default value
		message.set((uint8_t)0);
	} else if (command == C_STREAM) {
		// stream payload

if there's no payload, the library assumes uint8_t with value 0

[rejoe2]

@frits: Thx for analyzing this issue. Atm I honestly don't have no clue how to deal with this change in the FHEM module code. When analyzing ECHO, there's a check weather send info is identical to what's been sent.
So the only way out seems to be less exact and also let be 0 the same as "nothing" (Perl doesn't use NULL).

@karlheinz2000 Perhaps, we could ad a small if statement at the end of line 760 to treat 0 as "nothing" or undef?

or $_->{payload} ne $msg->{payload} if $msg->{payload}

Deleting the entire line might cause problems...

[karlheinz2000]

I've opened an issue for that.
https://github.com/mysensors/MySensors/issues/1452

According to API payload is same on ECHO message.
I feel this should be handled/fixed in lib, but I have no idea how to do...
If it is not possible to fix in lib, it shall not be allowed to send message with no payload anymore, which controller has to make sure then.
@rejoe2
Regarding FHEM, at the moment we should keep it as it is. No payload is not the normal use case.
I flashed gateway with 2.2.0 and this fixed the problem for me.