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

You should move the define for the node ID before you include mysensors.h

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.

Exactly. Better to ask then waste many hours

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

@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

@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

@niclas comment the

#define MY_DEBUG

In your gateway sketch

@harrdy You don't have to use a stepdown board, you can just use a resistor divider to lower the voltage.
With one diode you will still not have a DC signal yet, better to use two diodes or a bridge rectifier. After the rectifier place a capacitor and the resistor divider.

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

You can try to change the define

#define MQTT_SOCKET_TIMEOUT 
Or
setSocketTimeout()

Which will decrease the time the MQTT client waits when reconnecting

You should move the define for the node ID before you include mysensors.h

The send() function can be trusted, the message arrives right? Twice even.
I think you should look at optimising the tx levels. https://forum.mysensors.org/topic/11107/help-needed-to-setup-a-rfm69-esp8266-gateaway-on-adafruit-feather-huzzah/30?_=1601132509084
Here is a short description of the approach

For the RFM69 radios this can be caused by the software acknowledgement mechanism. If the sending node doesn't receive the acknowledgement from the gateway, the message is sent again. This will result in double messages on the gateway.

Is it really needed to edit this entity?
If you add it to your dashboard, you should be able to use it.
On the top right click on the three dots, then edit dashboard. Create a card and add the sensor there and you should be good to go!

@ejlane said in Dual Radio with Home Assistant Question:

. Do they show up automatically, or do I need to go tweak something?

They will, if your sketch complies to the presentation requirements. See https://www.home-assistant.io/integrations/sensor.mysensors/

@NONO87 What does the debug monitor tell you?

@ejlane
My configuration is this, and that seems to work correctly:

mysensors:
  gateways:
    - device: mqtt
      persistence_file: '/config/mysensors-mqtt.json'
      topic_in_prefix: 'mygateway1-out'
      topic_out_prefix: 'mygateway1-in'
    - device: mqtt
      persistence_file: '/config/mysensors-rfm-mqtt.json'
      topic_in_prefix: 'ms-rfm-from'
      topic_out_prefix: 'ms-rfm-to'
  optimistic: false
  persistence: true
  retain: false
  version: '2.3'

What exactly doesn't work in your case, and can you post your configuration?

So after more then 67h the gateway hangs again. This is the debug output:

(di 01-09 09:58:49.398) 243740964 RFM69:SWR:ACK,FROM=31,SEQ=60,RSSI=-98
(di 01-09 09:58:49.398) 243740969 THA:SND:MSG LEN=9,RES=1
(di 01-09 09:58:49.398) 243740974 TSF:MSG:SEND,0-0-31-31,s=2,c=2,t=3,pt=0,l=2,sg=0,ft=0,st=OK:11
(di 01-09 09:58:49.585) IC<CR>
(di 01-09 09:58:49.585) IH<CR>
(di 01-09 09:58:49.585) 243741189 THA:DATA:AVAIL
(di 01-09 09:58:49.641) 243741241 RFM69:SAC:SEND ACK,TO=31,RSSI=-71
(di 01-09 09:58:49.703) 243741246 RFM69:CSMA:RSSI=-100
(di 01-09 09:58:49.703) 243741253 THA:RCV:MSG=1F1F000A2103020B
(di 01-09 09:58:49.703) 243741256 THA:RCV:MSG LEN=8
(di 01-09 09:58:49.703) 243741261 TSF:MSG:READ,31-31-0,s=2,c=1,t=3,pt=1,l=1,sg=0:11
(di 01-09 09:58:49.703) 243741268 GWT:TPS:TOPIC=ms-rfm-from/31/2/1/0/3,MSG SENT
(di 01-09 09:58:49.703) IC<CR>
(di 01-09 09:58:49.703) IH<CR>
(di 01-09 09:58:49.703) IC<CR>
(di 01-09 09:58:49.703) IH<CR>
(di 01-09 09:58:49.703) 243741282 THA:DATA:AVAIL
(di 01-09 09:58:49.733) 243741334 RFM69:SAC:SEND ACK,TO=31,RSSI=-68
(di 01-09 09:58:49.737) 243741339 RFM69:CSMA:RSSI=-96
(di 01-09 09:58:49.742) 243741345 THA:RCV:MSG=1F1F000A21030A0B
(di 01-09 09:58:49.747) 243741349 THA:RCV:MSG LEN=8
(di 01-09 09:58:49.752) 243741354 TSF:MSG:READ,31-31-0,s=10,c=1,t=3,pt=1,l=1,sg=0:11
(di 01-09 09:58:49.759) 243741361 GWT:TPS:TOPIC=ms-rfm-from/31/10/1/0/3,MSG SENT
(di 01-09 09:58:49.766) IC<CR>
(di 01-09 09:58:49.767) IH<CR>
(di 01-09 09:58:49.862) IC<CR>
(di 01-09 09:58:49.862) IH<CR>
(di 01-09 09:58:49.911) 243741466 THA:DATA:AVAIL
(di 01-09 09:58:49.915) 243741518 RFM69:SAC:SEND ACK,TO=31,RSSI=-69
(di 01-09 09:58:49.921) 243741523 RFM69:CSMA:RSSI=-97
(di 01-09 09:58:49.926) 243741529 THA:RCV:MSG=1F1F000A21171642
(di 01-09 09:58:49.978) 243741533 THA:RCV:MSG LEN=8
(di 01-09 09:58:49.978) 243741538 TSF:MSG:READ,31-31-0,s=22,c=1,t=23,pt=1,l=1,sg=0:66
(di 01-09 09:58:49.978) 243741545 GWT:TPS:TOPIC=ms-rfm-from/31/22/1/0/23,MSG SENT
(di 01-09 09:58:49.978) IC<CR>
(di 01-09 09:58:49.978) IH<CR>
(di 01-09 09:58:59.817) IC<CR>
(di 01-09 09:58:59.817) IH<CR>
(di 01-09 09:58:59.881) 243751420 THA:DATA:AVAIL
(di 01-09 09:58:59.881) 243751473 RFM69:SAC:SEND ACK,TO=31,RSSI=-71
(di 01-09 09:58:59.881) 243751478 RFM69:CSMA:RSSI=-100
(di 01-09 09:58:59.881) 243751485 THA:RCV:MSG=1F1F000A21171643
(di 01-09 09:58:59.909) 243751488 THA:RCV:MSG LEN=8
(di 01-09 09:58:59.909) 243751493 TSF:MSG:READ,31-31-0,s=22,c=1,t=23,pt=1,l=1,sg=0:67
(di 01-09 09:58:59.909) 243751500 GWT:TPS:TOPIC=ms-rfm-from/31/22/1/0/23,MSG SENT
(di 01-09 09:58:59.909) IC<CR>
(di 01-09 09:58:59.909) IH<CR>
(di 01-09 09:59:09.771) IC<CR>
(di 01-09 09:59:09.771) IH<CR>
(di 01-09 09:59:09.771) 243761374 THA:DATA:AVAIL
(di 01-09 09:59:09.860) 243761427 RFM69:SAC:SEND ACK,TO=31,RSSI=-70
(di 01-09 09:59:09.907) 243761432 RFM69:CSMA:RSSI=-101
(di 01-09 09:59:09.907) 243761439 THA:RCV:MSG=1F1F000A21171644
(di 01-09 09:59:09.907) 243761442 THA:RCV:MSG LEN=8
(di 01-09 09:59:09.907) 243761447 TSF:MSG:READ,31-31-0,s=22,c=1,t=23,pt=1,l=1,sg=0:68
(di 01-09 09:59:09.907) 243761454 GWT:TPS:TOPIC=ms-rfm-from/31/22/1/0/23,MSG SENT
(di 01-09 09:59:09.907) IC<CR>
(di 01-09 09:59:09.907) IH<CR>
(di 01-09 09:59:11.447) MQTTP topic
(di 01-09 09:59:11.578) ms-rfm-to/31/2/2/0/3<CR>
(di 01-09 09:59:11.578) 243763051 GWT:IMQ:TOPIC=ms-rfm-to/31/2/2/0/3, MSG RECEIVED
(di 01-09 09:59:11.578) 243763059 THA:SND:MSG=00001F120203023132
(di 01-09 09:59:11.578) 243763065 RFM69:SWR:SEND,TO=31,SEQ=65,RETRY=0
(di 01-09 09:59:11.578) 243763072 RFM69:CSMA:RSSI=-98
(di 01-09 09:59:11.578) IC<CR>
(di 01-09 09:59:11.578) IH<CR>
(di 01-09 09:59:11.578) IC<CR>
(di 01-09 09:59:11.578) IH<CR>
(di 01-09 09:59:11.578) 243763088 RFM69:SWR:ACK,FROM=31,SEQ=66,RSSI=-96
(di 01-09 09:59:11.578) 243763092 THA:SND:MSG LEN=9,RES=1
(di 01-09 09:59:11.578) 243763097 TSF:MSG:SEND,0-0-31-31,s=2,c=2,t=3,pt=0,l=2,sg=0,ft=0,st=OK:12

After this, nothing happens anymore. I'm out of ideas...

So, I have added a check in the PubSubclient to work around this. Until now it works quite well and when an invalid packet is received this is not handled.

However, now sometimes the gateway just hangs at some point.

(za 29-08 13:06:53.126) IH<CR>
(za 29-08 13:06:59.846) MQTTP topic
(za 29-08 13:06:59.846) ms-rfm-to/31/2/2/0/3<CR>
(za 29-08 13:06:59.960) 71554750 GWT:IMQ:TOPIC=ms-rfm-to/31/2/2/0/3, MSG RECEIVED
(za 29-08 13:06:59.960) 71554758 THA:SND:MSG=00001F120203023237
(za 29-08 13:06:59.960) IC<CR>
(za 29-08 13:06:59.960) IH<CR>
(za 29-08 13:06:59.960) IC<CR>
(za 29-08 13:06:59.960) IH<CR>
(za 29-08 13:06:59.960) 71554775 THA:SND:MSG LEN=9,RES=1
(za 29-08 13:06:59.960) 71554779 TSF:MSG:SEND,0-0-31-31,s=2,c=2,t=3,pt=0,l=2,sg=0,ft=0,st=OK:27

And then nothing happens.
(The IC and IH are added by me to check on the interrupts, IC is interrupt clear and IH interrupt handle). I've switched on the internal LED on RFM69 interrupt and that is on when this occurs. It is not clear for me if this happens before or after the freeze.

Now I've added the debug defines below, to get more information on what's happening before the freeze. But after this change the software is running for 47h already. So I suspect there could be some timing issue but not sure if, where and how.

#define MY_DEBUG_VERBOSE_RFM69
#define MY_DEBUG_VERBOSE_TRANSPORT_HAL
#define MY_DEBUG_VERBOSE_RFM69_REGISTERS