I haven't tested it, but this one seems to fit what you need
https://github.com/mycontroller-org/serial2mqtt/blob/master/README.adoc

If you use an ISP programmer, you can reprogram the fuses and use it on lower voltages also. Upto 1.8v but also 3.3v

Exactly. Better to ask then waste many hours

@skywatch said in Auto resend on NACK:

@electrik & @Marek - Are you both sure about that? It seems to me that both those statements are doing what was intended.

Now that I see it again, I'm not so sure anymore actually.

In your code you used the variable msg. That should be one of msgFgeHum, msgFgeTemp, msgFzrHum, msgFzrTemp.
That is why the compiler complains msg is unknown.

You also enabled the ack message, this is just a software acknowledge, while the send function returns the status of the hardware acknowledge. So if you check with

if (send(msgFgeHum.set(fgehum),true))
{
// this is sent ok
}
else
{
// sending failed
}

you check if the hardware acknowledge was successful. The software ack should be tested differently and some more logic is needed for it.

Hope this helps

You can remove these lines, the declaration is already done in the MySensors framework. For presentation() it is needed because you write code there, that is in the function. Now you only call the function, and the code is already in the framework.

@skywatch still if you use wait(), the rest of the code in the loop is not executed during the waiting time. Only the mysensors core is executed

@martim Did you read this thread?
https://forum.mysensors.org/topic/9431/solved-esp8266-mysensors-2-2-0-problem-with-static-ip-configuration

You should do the same for requestTime();

Hello
I've tried to use this with an ESP32 (I modified some defines for the architecture, to make it compatible). In MyHwESP32.h I've changed

#define MY_SERIALDEVICE Serial

to

#ifndef MY_SERIALDEVICE
  #define MY_SERIALDEVICE Serial
#endif

I think this why it doesn't work for you @ricorico94 with version 2.3 of MySensors.

It worked sometimes, but usually Putty responds "Network error: Connection refused"

Any ideas?

Did you try this?

https://forum.mysensors.org/search?term=ets_update_cpu_frequency&in=titlesposts&matchWords=all&sortBy=relevance&sortDirection=desc&showAs=posts

@jocke4u said in Migrating from openHAB to Home Assistant:

But get in logs a lot of:
2020-05-26 17:32:30 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:32:40 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-26 17:32:50 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:33:10 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:33:30 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:33:39 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-26 17:33:50 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:34:10 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:34:13 WARNING (MainThread) [mysensors] Node 3 is unknown
2020-05-26 17:34:13 WARNING (MainThread) [mysensors] Node 3 is unknown
2020-05-26 17:34:14 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-26 17:34:30 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:34:33 WARNING (MainThread) [mysensors] Node 4 is unknown

These are caused by the nodes not correctly being presented to home assistant.
Check https://www.home-assistant.io/integrations/sensor.mysensors/ for some examples of what the sketch should do so it is recognised by home assistant.
Mainly presenting the sensors and sending a value to the controller.

You could try to specify the protocol version in the hinge assistant configuration file.
https://www.home-assistant.io/integrations/mysensors/#version

After I wrote the message above I realised this is another topic in fact, I hope you don't mind.
To explain a bit more what happens, here is some debug output. Each 10 seconds an increasing counter is sent to the gateway, and after each sent message the TX power is printed on the screen.

46219 TSM:UPL:OK
46252 TSM:READY:ID=31,PAR=0,DIS=1
54607 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:4
Power is 3
64618 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:5
Power is 2
74629 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:6
Power is 1
85655 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=NACK:7
Power is 1
94650 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=1,st=OK:8
Power is 0
105168 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:9
Power is -1
114671 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:10
Power is -2
124682 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:11
Power is -3
135708 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=NACK:12
Power is -3
144703 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=1,st=OK:13
Power is -4
154714 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:14
Power is -5
164724 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:15
Power is -6
174735 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:16
Power is -7
184745 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:17
Power is -8
195772 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=NACK:18
Power is -8
204980 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=1,st=OK:19
Power is -9
214990 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:20
Power is -10
225804 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=NACK:21
Power is -10
235438 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=1,st=OK:22
Power is -11
245825 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=NACK:23
Power is -11
255836 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=1,st=NACK:24
Power is -11
265846 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=2,st=NACK:25
Power is -11
275857 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=3,st=NACK:26
Power is -11
285868 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=4,st=NACK:27
Power is -11

Here are a couple of NACKs, so this is on the limit of TX power IMO. Still one succesfull one, which decreases the power even more.

294862 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=5,st=OK:28
Power is -12
305889 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=NACK:29
Power is -12
315899 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=1,st=NACK:30
Power is -12
325910 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=2,st=NACK:31
Power is -12
335921 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=3,st=NACK:32
Power is -12
345931 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=4,st=NACK:33
Power is -12
355942 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=5,st=NACK:34
Power is -12

Five failed messages and the node starts finding its parent. But also that fails.

356024 !TSM:READY:UPL FAIL,SNP
356073 TSM:FPAR
356089 ?TSF:MSG:SEND,31-31-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=6,st=OK:
358203 !TSM:FPAR:NO REPLY
358219 TSM:FPAR
358252 ?TSF:MSG:SEND,31-31-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
360366 !TSM:FPAR:NO REPLY
360382 TSM:FPAR
360415 ?TSF:MSG:SEND,31-31-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
362512 !TSM:FPAR:NO REPLY
362528 TSM:FPAR
362561 ?TSF:MSG:SEND,31-31-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
364675 !TSM:FPAR:FAIL
364691 TSM:FAIL:CNT=1
364724 TSM:FAIL:DIS
364740 TSF:TDI:TSL
364888 !TSF:SND:TNR
Power is -12
374784 TSM:FAIL:RE-INIT
374800 TSM:INIT
374833 TSM:INIT:TSP OK
374865 TSM:INIT:STATID=31
374898 TSF:SID:OK,ID=31
374915 TSM:FPAR
374947 ?TSF:MSG:SEND,31-31-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
375046 !TSF:SND:TNR

Now the Transportlayer is re-initialised and the power level goes to 5, which makes the messages being ACKed again. This starts the process all over again.

Power is 5
375734 TSF:MSG:READ,0-0-31,s=255,c=3,t=8,pt=1,l=1,sg=0:0
375799 TSF:MSG:FPAR OK,ID=0,D=1
377044 TSM:FPAR:OK
377061 TSM:ID
377077 TSM:ID:OK
377110 TSM:UPL
377192 TSF:MSG:SEND,31-31-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
377913 TSF:MSG:READ,0-0-31,s=255,c=3,t=25,pt=1,l=1,sg=0:1
377978 TSF:MSG:PONG RECV,HP=1
378028 TSM:UPL:OK
378044 TSM:READY:ID=31,PAR=0,DIS=1
385105 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:37
Power is 3
395116 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:38
Power is 2
405127 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:39
Power is 1
415137 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:40
Power is 0
425148 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:41
Power is -1
435159 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:42
Power is -2
445169 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:43
Power is -3
455180 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:44
Power is -4
465207 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:45
Power is -5
475201 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:46
Power is -6
485720 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:47
Power is -7
495222 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:48
Power is -8
505446 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:49
Power is -9
516259 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=NACK:50
Power is -9
525254 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=1,st=OK:51
Power is -10
536281 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=NACK:52
Power is -10
546291 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=1,st=NACK:53
Power is -10
556302 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=2,st=NACK:54
Power is -10
565510 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=3,st=OK:55
Power is -11
576323 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=NACK:56
Power is -11
586334 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=1,st=NACK:57
Power is -11
596344 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=2,st=NACK:58
Power is -11
606355 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=3,st=NACK:59
Power is -11
615989 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=4,st=OK:60
Power is -12
626376 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=NACK:61
Power is -12
636387 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=1,st=NACK:62
Power is -12
646397 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=2,st=NACK:63
Power is -12
656408 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=3,st=NACK:64
Power is -12
666419 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=4,st=NACK:65
Power is -12
676429 !TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=5,st=NACK:66
Power is -12
676511 !TSM:READY:UPL FAIL,SNP
676560 TSM:FPAR
676577 ?TSF:MSG:SEND,31-31-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=6,st=OK:
678690 !TSM:FPAR:NO REPLY
678707 TSM:FPAR
678739 ?TSF:MSG:SEND,31-31-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
680853 !TSM:FPAR:NO REPLY
680869 TSM:FPAR
680902 ?TSF:MSG:SEND,31-31-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
682999 !TSM:FPAR:NO REPLY
683016 TSM:FPAR
683048 ?TSF:MSG:SEND,31-31-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
685162 !TSM:FPAR:FAIL
685178 TSM:FAIL:CNT=1
685211 TSM:FAIL:DIS
685228 TSF:TDI:TSL
685375 !TSF:SND:TNR
Power is -12
695271 TSM:FAIL:RE-INIT
695287 TSM:INIT
695320 TSM:INIT:TSP OK
695353 TSM:INIT:STATID=31
695386 TSF:SID:OK,ID=31
695402 TSM:FPAR
695435 ?TSF:MSG:SEND,31-31-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
695533 !TSF:SND:TNR
Power is 5
696369 TSF:MSG:READ,0-0-31,s=255,c=3,t=8,pt=1,l=1,sg=0:0
696434 TSF:MSG:FPAR OK,ID=0,D=1
697548 TSM:FPAR:OK
697565 TSM:ID
697581 TSM:ID:OK
697614 TSM:UPL
697696 TSF:MSG:SEND,31-31-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
698236 TSF:MSG:READ,0-0-31,s=255,c=3,t=25,pt=1,l=1,sg=0:1
698302 TSF:MSG:PONG RECV,HP=1
698335 TSM:UPL:OK
698351 TSM:READY:ID=31,PAR=0,DIS=1
705593 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:69
Power is 3
715603 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:70
Power is 2
725827 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:71
Power is 1
735641 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:72
Power is 0
745635 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:73
Power is -1
755646 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:74
Power is -2
765657 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:75
Power is -3
775667 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:76
Power is -4
785678 TSF:MSG:SEND,31-31-0-0,s=22,c=1,t=23,pt=1,l=1,sg=0,ft=0,st=OK:77

Hello,
I would like to step in here as you will look into this ATC mode anyway
I've been observing the behaviour, and when it successfully sends a message, the power level is decreased. Excellent.
At some point the power becomes too low and messages are not ACK'ed anymore. I had expected the power level would be increased at that point, but it doesn't.
The result is that on another succesfull delivery the power level is decreased even more, and the node can't find the gateway anymore. Then the node increases its power level to the initial value (let's say 5) and then the process starts over again.
Would it be an idea to increase the power level when there is a NACK and then try to stay around this "ideal" level?

I'm willing to test if it is needed

I don't know about pi gateways, but the Arduino gateways need to use the new rfm69 driver when you use the new driver on the nodes, else it won't work.

Interesting finding!
I'm trying to replicate the behaviour, and have added some debug print statements in my code, which shows the tx level after each transmission. The number is changing often which doesn't correspond with your behaviour.
How did you measure this?

@iamtheghost yes you can. With the latest development build you can even use the same gateway for both. I'm currently using two different ones, one for nrf24 and one for rfm69.
I edited my post above, I forgot node red on the list. I prefer that for automations instead of home assistant.

Here is my recommendation:

• Rfm69 radios or decent ebyte nrf24 modules (search the forum for the exact type)

• Mqtt gateway (I use an Esp32)

• Home assistant as controller
  Edit:

• Node red to manage more complex automations

@Rolland said in Serial GW and motion sensor functionning, but no activity between them:

Here is the log of sensor :
16 MCO:BGN:INIT NODE,CP=RNNNA---,FQ=16,REL=255,VER=2.3.2
26 TSM:INIT
28 TSF:WUR:MS=0

Are these three lines all output from the sensor? That should be more, eg that it is finding its parent etc.
Did you double check the connections between the Arduino and the NRF24?

I can't tell yet. The node I'm now using is a wall switch, operating on a CR2032 battery. No idea yet how long it lasts.