Posts made by alexelite

What type of gateway and radio do you use?

@vecnar so you have a smoke sensor with a normally open relay contact, and the contact closes when smoke detection is triggered. As I understand the contact is dry ( potential free).
Your alarm system requires normally closed circuit and triggers on open circuit. (ignoring the resistor and tamper for now).
You what to connect the two together, no mysensors stuff in between.
Did I understand correctly?

@skywatch, 3.3V at 16MHz is somewhat out of specs, but it works at 115200bps using the hardware uart.

@NielBierman, the library provides 254 sensors definitions, and for each you can use types VAR1-5, that means 1270 distinct values.
If you have 8 soil moisture and 8 temp you should define a sensor for every pair.
Sensor 0 : VAR1 and TEMP
...
Sensor 8 : VAR1 and TEMP

@stewie I've read about another integration that it is available only when advanced mode is on in user profile. Do you have it on? If not, you can try turning it on to see if it becomes available?

I found the proximate cause for this problem and posted it in an already opened issue.
https://github.com/mysensors/MySensors/issues/1077#issuecomment-832228721

@skywatch where did I say I ignore the note? A library is not the holy truth, it was written by a human being, with more or less accurate info.
I have to check all info found on the net and also do my own testing.
In this case the note should be true only for old Pi boards, Pi3 should be able to supply at least a few hundred mA on the 3v3 header pins. But for testing I checked if this makes a difference.
RFM69HW datasheet makes me think power requirements only affect TX, 16mA in Rx mode, and up to 130mA in Tx.
Noise can be a big factor to consider. I have decupling capacitor right next to the radio module, with thick traces to 3.3 and GND pins. The power supply is a RPi wall adaptor.
The main idea is that it worked once and after a reboot with no hardware change, it stopped working as expected. This does not sound like a power problem or hardware one as a mater of fact, but a software one. kted inspired me to read more carefully some topics and it turns out other libraries are "plagued" with this problem. So it might have nothing to do with mysensors library but something in the Pi? Mabey a timing issue influenced by other service running? Can we solve it? Maybe if we try.

@kted, thank you for your answer, is this documented somewhere? I searched a lot but only found partial info about rssi problems.

I was trying to use a Python library and found a note about RFM69 H version that it should not be powered from the 3.3V pin. This should only matter for transmitting not for receiving, and without anything else connected to the Pi the 3.3V power pin should be able to provide a few hundred mA of current.
I changed the board and powered it from 5V with a dedicated 3.3V regulator and RSSI increased a bit.

at around 10 pm I implemented the mod. But it is nowhere near what I got a few days ago when it worked only from 3.3V.

https://rpi-rfm69.readthedocs.io/en/latest/hookup.html
This pin can only support low power mode. Use different supply if you want to use the RFM69HCW in high power mode.

With serial gateway attached to the Pi, RSSI varies based on distance, the right way. The node very close has a -45 value, and the rest from -65 to -80.

I have a Raspberry pi 3 with a RFM69HW connected directly to GPIO pins as MySensors gateway. 868Mhz.
For months the gateway was placed behind the TV with an antenna dangling 30 cm below the TV. With this setup the average RSSI value for messages form nodes was around -100. Mounting the antenna just behind the TV stopped all communications so I attributed the low RSSI to TV's proximity.
Recently I prepared a new location for the gateway and moved the Pi. RSSI value improved considerably and was very stable at around -80 for most nodes in the house, some higher than this.
A day after the move, I had to reboot the Pi and the RSSI value dropped back to an average of -100. No hardware change.
I tried multiple reboots and got some inconsistent results as seen in the first image.
I made a new HAT with a brand new radio with a bigger ground plane. Same results.
This node is a floor up with a reinforced concrete slab in between, opposite sides of the house.

This is a relay node 2 m from the GW. It is rarely actuated (very low message rate) and usually only responds to discovery messages. After the GW move the tx power was very high and ATC adjusted it from -40 to -60.

I made a signal strength node. It goes to full power because RSSI is so low. If I set the lowest power, signal strength does not drop and all messages are received OK. The RSSI value for messages from GW have an RSSI of -60. If I take the signal strength node closer to the GW (a meter away), still no change. only node's RxRSSI increases.

I've been trying to understand this for days. The problem is that all nodes max out on power because of this value.

Another test I did:
I made 1 node and 1 gw based on Lowpowerlab's library (LPL) (atmega328 + rfm69hw + Ft232), connected the LPL_GW to the Pi and measured the received signal strength. -60 when LPL signal strength node is on a different floor, and increases to -30 when moved in the same location.
I will try to use this hw for a usb connected mys gateway, but other than this I am out of ideas.

@mfalkvidd said in Best password manager?:

Bitwarden

Bitwarden self hosted works very well for me. Definitely a strong candidate for best password manager.

Did you check the voltage on the reset pin? Might be a faulty pullup connection on the reset pin, if your circuit is on a breadboard.

@DenisJ CSN is NSS on radio module, and IRQ is DIO0

You can try with #define MY_DEBUG_VERBOSE_RFM69_REGISTERS to se if radio communication is ok and mysensors library is able to communicate with the radio. You should see registers dump at startup.

If that is ok, on the gateway you should see a "find parent request" from this node.
This should narrow the problem to "are you transmitting and not receiving", or "you are not transmitting".

@Alpoy said in Feather M0 RFM60HCW (433Mhz) - can't connect to gw:

Feather M0 RFM69HCW

I think you only need:
#define MY_RFM69_IRQ_PIN 3
#define MY_RFM69_CS_PIN 8
for M0 this is not required
#define MY_RFM69_IRQ_NUM 3

Gateway >> Node >> Device >> Metrics

Nodes have devices attached and each device has metrics.

I do not think it is a security breach, because ESP32 has AES256 encryption for flash data, if enabled.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/flash-encryption.html

@toddles I don't think you can trigger an event directly. HA mysensors integration changes the state of entities only.
Your node sends button state on one single sensor id, value dependent on key pressed? And you only send on depressed event not on release?
If so, why not send also a release event, or count the times one button is pressed before sending?

I also have the gateway near the TV (behind it) with the antenna 30-40 cm below it.
The RSSI value drops for all nodes and this drop can successfully be used to detect tv on . With the magnetic antenna on tv's support, communication stops working even for nodes 4 m away, in the same room.

@Snyfir In your first post you say that only one node is mains powered. Instead of modifying the library, why not provide a UPS type power supply for that node. Something with an old phone battery or 1-2 18650 cells.
But I guess the other two already have something like this, they are not battery only.
That way if the power goes down all your repeaters are up.

In MySensors/hal/architecture/AVR/MyHwAVR.cpp
find:

ISR (WDT_vect)
{
}

// Make it weak to allow local sketch implementation by changing it to

ISR(WDT_vect, __attribute__((weak)))
{
}

Make WDT_vect weak #717

Or you can do it like this Compile problem: multiple definition of `__vector_6'
Go to LowPower.cpp, find this lines

ISR (WDT_vect)
{
	// WDIE & WDIF is cleared in hardware upon entering this ISR
	wdt_disable();
}

and comment it

This last solution worked for me to compile with lowpower lib, but I wanted to use Timer2 on and that is incompatible with Mysensors for now.

Yes, I read it. I started using your approach, gateway sensor ids representing nodes ids, but from the controller point of view this is not straight forward, I think. The 2 problems remain somehow the same. How to get the controllers to understand that gateway sensors are not actually sensors but RSSI value, and repeaters breaks my current algorithm.
Thinking more about this, if it is something the library would benefit, lead me to read about the RF24 and NRF5 radios. I only have RFM69 devices (20 nodes) and it offers RSSI out of the box, same as RFM LoRa version and NRF5. But RF24 lacks this feature. So it somewhat depends on how many are using radios with rssi. Library developers included RSSI functionality, so it has to be of interest.
The repeater problem is partially solved because RF24 networks need repeaters, but don't have RSSI. RFM networks should do without repeaters for most applications. For NRF5, I lack this info. But as I passed the rssi from transport to gateway transport, same can be done with actual sender from the header.

Maybe in version 3.0.0 something like this can be implemented? My understanding is that controllers get link quality data the same way they get all other data from devices, on other platforms. Mabey a I_LINK_QUALITY type can be added especially for this information?

for example my zigbee network:
zigbee2mqtt/device {"linkquality":5,"state":"ON"}

For the past few days I tried to understand how the library works internally and if there is any way to get the gateway received message RSSI to the controller. I'd like to know what the signal strength is at the gateway without asking the node.

By default, RSSI value is not passed from the transport layer to the message layer, so the gateway transport layer cannot use it.
The RSSI value is only sent back to the node via echo message (if requested).
The gateway can request this value via I_SIGNAL_REPORT_REQUEST. But since the value is available directly in the gateway, why not pass it to the controller by default?

I hacked the library (2.4.0) so message layer gets the RSSI value from transport layer (RFM69) and gateway transport layer (MQTT) publishes it as I_SIGNAL_REPORT_RESPONSE, no changes in protocol. But this presents at least 2 problems:

1. I_SIGNAL_REPORT_RESPONSE can be received from the node by request and the value depend on the request.
   Example: controller requests TX power %, node responds and gateway pushes to the controller 2 messages with the same topic but different values and units. There is no way to distinguish which is which.
2. Gateway transport layer knows not if the message was routed via repeater or was received directly from node, and publishes the message as received directly from node, but the RSSI value is for the message from repeater. I don't know how this is handled in the library for I_SIGNAL_REPORT_REQUEST/I_SIGNAL_REPORT_RESPONSE.

Is this something of interest to others? If yes how do you see it implemented, using a dedicated type message, or an existing one? I believe it is useful. Zigbee coordinator provides signal strength for every message. Also Felix Rusu's RFM69 library.

@3nibble Your usb diode should be the one with B2 written on it. You can try shorting it.
Do you have a digital multimeter (DMM)? You can measure the voltage between gnd and both lead of the diode.

@3nibble You shorted the power supply. This will not kill your MCU or usb-serial chip. The 5V rail is the USB power rail and usually if you short it, the USB controller disconnects power or limits current to that USB port until the short is removed or it need a reset.

If one board works and another one doesn't you might have a blown fuse on the backside of the board. Pease post a photo with the backside.
The schematic I found shows a Schottky Diode between VUSB and +5V. It might be open circuit because of your short. If you have a DC 6V-12V power supply you can try powering the board through VIN pin.
Or you can short the usb diode with some conductive tweezers.

Bootloader is not the problem, you should see the Ftdi Serial device even without a MCU connected.
Did you connect any power supply to the breadboard? Maybe you reversed the polarity?
It would help if you could post a schematic of the circuit and a photo with the actual circuit.

Hello David,

In plumbing usually we don't have the sensor directly into the water, it is put inside a copper sheath. You should find them at hardware store. Some are short, some are long (for water tanks), and some even have special accessory for cable fixing (second image).
You need to put in a T designed for your pipe type.


You can use thermal paste to increase the thermal conductivity if you want.

I don't know your application but from experience I can say, for heating, if pipes are copper/steel or if you have metal fittings, outside is ok. Mean value over a defined period of time is important.

Hope it helps.
Alex

Short intro. I have a small Arduino device network based on MySensors with RFM69 radios, a rPi MySensors<->MQTT gateway, and a Home Assistant running on a PC server as controller.
Often my HA sends multiple commands to turn on/off relays on remote devices and although the messages arrive OK and relays actuate, the gateway does not receive the acknowledge because it starts sending a new message. And so the controller does not receive confirmation of state change on all commands sent.
The setup is based on development branch and no custom modifications.

So after going from simple Atmega328 serial gateway via mqtt, esp8266 mqtt gateway, then a Atsamd21 serial gateway via mqtt, and now the rpi gateway, problem still there.

My current solution is a queue implemented in Node-Red. Messages received form controller over mqtt are queued and sent one at a time. If ack is requested but not received in a fixed amount of time (500ms) the message is put back in queue for a total for 5 times. After 5 retries the message is dropped.

This flow work fine so far, all messages are received and acknowledged in time.

[{"id":"c00f16f5.dde598","type":"tab","label":"Flow 1","disabled":false,"info":""},{"id":"f574f085.8c965","type":"simple-queue","z":"c00f16f5.dde598","name":"","firstMessageBypass":true,"bypassInterval":"0","x":410,"y":160,"wires":[["8f09ef2d.2f651"]]},{"id":"47303c08.4463d4","type":"mqtt in","z":"c00f16f5.dde598","name":"","topic":"mysensors-in-queue/#","qos":"2","datatype":"auto","broker":"65b2b296.362e3c","x":200,"y":100,"wires":[["71271e36.f1b4c"]]},{"id":"8f09ef2d.2f651","type":"function","z":"c00f16f5.dde598","name":"process mys","func":"msg.queueLoops++;\nvar m = msg.topic;\nm = m.split('/');\nmsg.retain = false;\nflow.set('node_id',m[1]);\nflow.set('child_id',m[2]);\nflow.set('command',m[3]);\nflow.set('ack',m[4]);\nflow.set('type',m[5]);\nflow.set('payload',msg.payload);\nflow.set('receivedAt',msg.receivedAt);\nif (m[4] == \"0\" ){\n    //message does not requrire acknowladge\n    flow.set('ackRequested',0);\n    //msg.message=\"no ackRequested\";\n    node.log(Date.now() + \":\" + msg.receivedAt +\"/\" + msg.topic + \" \" + msg.payload + \" - noAck\");\n} \nelse\n{\n    //message acknowladge requested\n    flow.set('ackRequested',1);\n    msg.message=\"ackRequested!\";\n    node.log(Date.now() + \":\" + msg.receivedAt +\"/\" + msg.topic + \" \" + msg.payload + \" - ackRequested\");\n}\nmsg.topic = msg.topic.replace('mysensors-in-queue', 'mysensors-in');\nreturn msg;","outputs":1,"noerr":0,"x":570,"y":160,"wires":[["8b425bd3.630458","9ede4d44.22f1f"]]},{"id":"8b425bd3.630458","type":"function","z":"c00f16f5.dde598","name":"check ack","func":"if (flow.get('ackRequested') === 0){\n    //no ack requested, trigger new message from queue. send only trigger command\n    msg = {trigger : 1};\n    return [msg,null];\n}\nelse{\n    //ack requested, start timer and wait for reply\n    msg.mqttPayload = msg.payload\n    return [null,msg];\n}","outputs":2,"noerr":0,"x":760,"y":160,"wires":[["e2913b85.f1b368"],["d843d4a.9199228"]]},{"id":"fd5a5b49.3ec838","type":"mqtt in","z":"c00f16f5.dde598","name":"","topic":"mysensors-out/#","qos":"2","datatype":"auto","broker":"65b2b296.362e3c","x":180,"y":400,"wires":[["c8e82d0.58cabd"]]},{"id":"9ede4d44.22f1f","type":"mqtt out","z":"c00f16f5.dde598","name":"mysensors-in","topic":"","qos":"","retain":"","broker":"65b2b296.362e3c","x":770,"y":100,"wires":[]},{"id":"e2913b85.f1b368","type":"link out","z":"c00f16f5.dde598","name":"Trigger","links":["c2fcc29e.2f944"],"x":1035,"y":160,"wires":[]},{"id":"c2fcc29e.2f944","type":"link in","z":"c00f16f5.dde598","name":"Trigger","links":["e2913b85.f1b368"],"x":255,"y":160,"wires":[["f574f085.8c965"]]},{"id":"d843d4a.9199228","type":"trigger","z":"c00f16f5.dde598","op1":"","op2":"true","op1type":"nul","op2type":"bool","duration":"500","extend":false,"units":"ms","reset":"","bytopic":"all","name":"timeout","x":660,"y":260,"wires":[["956936f9.17acd8"]]},{"id":"956936f9.17acd8","type":"function","z":"c00f16f5.dde598","name":"check status","func":"var maxLoops = 5; \nif (msg.payload === true){\n    //we got a timeout, no ack received\n    if (msg.queueLoops < maxLoops) {\n        //put message back in queue\n        //check queueLopps to avoid a loop and trigger new message from queue\n        msg.payload = msg.mqttPayload;\n        flow.set('ackRequested',0);\n        node.log(msg.topic + \" \" + msg.payload + \" - ack NOK\");\n        return msg;\n    }\n    else{\n        node.log(msg.topic + \" \" + msg.payload + \" - dropped\");\n        msg = {trigger : 1};\n        return msg; \n    }\n}\nif (msg.reset == 1){\n    //ack received\n    //timeout timer canceled\n    //trigger new message from queue\n    msg = {trigger : 1};\n    return msg; \n}\nreturn null;","outputs":1,"noerr":0,"x":850,"y":260,"wires":[["38d0af8e.532d2","e2913b85.f1b368"]]},{"id":"38d0af8e.532d2","type":"function","z":"c00f16f5.dde598","name":"","func":"//simple queue discards a message if trigger propery is set\n//so we send a delayed trigger if \nif (typeof msg.topic  != \"undefined\") {\n    msg = {trigger : 1};\n    return msg;\n}","outputs":1,"noerr":0,"x":790,"y":360,"wires":[["c9ee7809.97a808"]]},{"id":"c9ee7809.97a808","type":"delay","z":"c00f16f5.dde598","name":"","pauseType":"delay","timeout":"1","timeoutUnits":"milliseconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":950,"y":360,"wires":[["e2913b85.f1b368"]]},{"id":"71271e36.f1b4c","type":"function","z":"c00f16f5.dde598","name":"Add info","func":"//we need a way to track how many times a message has been throw the queue to avoid an infinite loop\n//set received time of message\nmsg.receivedAt = Date.now();\n//set number of queue count to 0 for new message\nmsg.queueLoops = 0;\nreturn msg;","outputs":1,"noerr":0,"x":420,"y":100,"wires":[["f574f085.8c965"]]},{"id":"c8e82d0.58cabd","type":"function","z":"c00f16f5.dde598","name":"compare","func":"var m = msg.topic;\n\tm = m.split('/');\nif (flow.get('ackRequested') === 1){\n    if ((flow.get('node_id') === m[1]) &&\n        (flow.get('child_id') === m[2]) &&\n        (flow.get('command') === m[3]) &&\n        (flow.get('ack') === m[4]) &&\n        (flow.get('type') === m[5]) &&\n        (flow.get('payload') === msg.payload)){\n            //acknoladge received\n            flow.set('ackRequested',0);\n            msg.reset = 1;\n            node.log(  Date.now() +\":\"+\n                        flow.get('receivedAt',msg.receivedAt) +\"/\"+\n                        msg.topic + \" \" + msg.payload + \" - ack OK\");\n            msg.delay = Date.now() - flow.get('receivedAt',msg.receivedAt) ;\n            msg.node_id =  m[1];\n            return msg;\n        }\n}\nelse\n    msg.error = 1;\nreturn null;\n","outputs":1,"noerr":0,"x":480,"y":400,"wires":[["d843d4a.9199228","956936f9.17acd8"]]},{"id":"65b2b296.362e3c","type":"mqtt-broker","z":"","name":"","broker":"192.168.1.27","port":"1883","clientid":"","usetls":false,"compatmode":false,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""}]

requires node-red-contrib-simple-message-queue

After more investigations I believe the problem is caused by a mqtt server connection timeout.
By default the gateway tries to send the radio message 5 times. If I lower the number of retries , 2 for example, no more loop. Probably now much more then 25 messages cause a loop.

For testing I added _MQTT_client.loop() in transportSendWrite() (MyTransport.cpp) and, no more loop with default 5 retries.

Hello all,

I recently started a migration process from LowPowerLab library and gateway to MySensors network and Home Assistant controller.

After playing with a ESP8266 as Mqtt gateway and a few test nodes with RFM69 radios, all working ok, I encountered a problem. Basically if the gateway tries to send 25 messages over the air and none of them are acknowledged the mqtt connection is restarted and the gateway starts resending the messages and enters a loop. Evidently this happens with retained mqtt messages.

To make things easier I will start explaining with a simple setup:

Default ESP8266 gateway sketch, only mqtt parameters, radio setup modified.
A relay node with 25 outputs.
Everything works ok.
The mqtt messages look like this:

2019-10-31 10:56:48.095 mygateway10-in/7/255/3/0/6 M
2019-10-31 10:56:48.100 mygateway10-in/7/20/1/1/2 1
2019-10-31 10:56:48.104 mygateway10-in/7/1/1/1/2 1
2019-10-31 10:56:48.108 mygateway10-in/7/10/1/1/2 1
2019-10-31 10:56:48.112 mygateway10-in/7/11/1/1/2 1
2019-10-31 10:56:48.117 mygateway10-in/7/12/1/1/2 1
2019-10-31 10:56:48.121 mygateway10-in/7/13/1/1/2 1
2019-10-31 10:56:48.125 mygateway10-in/7/14/1/1/2 1
2019-10-31 10:56:48.129 mygateway10-in/7/15/1/1/2 1
2019-10-31 10:56:48.133 mygateway10-in/7/16/1/1/2 1
2019-10-31 10:56:48.137 mygateway10-in/7/17/1/1/2 1
2019-10-31 10:56:48.141 mygateway10-in/7/18/1/1/2 1
2019-10-31 10:56:48.145 mygateway10-in/7/19/1/1/2 1
2019-10-31 10:56:48.149 mygateway10-in/7/4/1/1/2 1
2019-10-31 10:56:48.153 mygateway10-in/7/5/1/1/2 1
2019-10-31 10:56:48.157 mygateway10-in/7/6/1/1/2 1
2019-10-31 10:56:48.161 mygateway10-in/7/7/1/1/2 1
2019-10-31 10:56:48.165 mygateway10-in/7/8/1/1/2 1
2019-10-31 10:56:48.169 mygateway10-in/7/9/1/1/2 1
2019-10-31 10:56:48.173 mygateway10-in/7/21/1/1/2 1
2019-10-31 10:56:48.177 mygateway10-in/7/22/1/1/2 1
2019-10-31 10:56:48.181 mygateway10-in/7/23/1/1/2 1
2019-10-31 10:56:48.185 mygateway10-in/7/24/1/1/2 1
2019-10-31 10:56:48.189 mygateway10-in/7/3/1/1/2 1
2019-10-31 10:56:48.193 mygateway10-in/7/2/1/1/2 1

Power down relay node and reset gateway:

38 MCO:BGN:INIT GW,CP=RRNGF---,FQ=240,REL=9,VER=2.3.2-beta
43 TSF:LRT:OK
47 TSM:INIT
50 TSF:WUR:MS=0
57 TSM:INIT:TSP OK
59 TSM:INIT:GW MODE
63 TSM:READY:ID=0,PAR=0,DIS=0
68 MCO:REG:NOT NEEDED
159 GWT:TPC:CONNECTING...
1161 MCO:BGN:STP
1163 MCO:BGN:INIT OK,TSP=1
1167 GWT:TPC:IP=192.168.1.22
1172 GWT:RMQ:CONNECTING...
1191 GWT:RMQ:OK
1193 GWT:TPS:TOPIC=mygateway10-out/0/255/0/0/18,MSG SENT
1201 TSM:READY:NWD REQ
1209 ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
1683 GWT:IMQ:TOPIC=mygateway10-in/7/255/3/0/6, MSG RECEIVED
1689 !TSF:RTE:7 UNKNOWN
2917 !TSF:MSG:SEND,0-0-7-7,s=255,c=3,t=6,pt=0,l=1,sg=0,ft=0,st=NACK:M
2923 GWT:IMQ:TOPIC=mygateway10-in/7/20/1/1/2, MSG RECEIVED
2930 !TSF:RTE:7 UNKNOWN
4159 !TSF:MSG:SEND,0-0-7-7,s=20,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
4165 GWT:IMQ:TOPIC=mygateway10-in/7/1/1/1/2, MSG RECEIVED
4172 !TSF:RTE:7 UNKNOWN
5401 !TSF:MSG:SEND,0-0-7-7,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
5407 GWT:IMQ:TOPIC=mygateway10-in/7/10/1/1/2, MSG RECEIVED
5414 !TSF:RTE:7 UNKNOWN
6643 !TSF:MSG:SEND,0-0-7-7,s=10,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
6649 GWT:IMQ:TOPIC=mygateway10-in/7/11/1/1/2, MSG RECEIVED
6656 !TSF:RTE:7 UNKNOWN
7885 !TSF:MSG:SEND,0-0-7-7,s=11,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
7891 GWT:IMQ:TOPIC=mygateway10-in/7/12/1/1/2, MSG RECEIVED
7898 !TSF:RTE:7 UNKNOWN
9127 !TSF:MSG:SEND,0-0-7-7,s=12,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
9133 GWT:IMQ:TOPIC=mygateway10-in/7/13/1/1/2, MSG RECEIVED
9140 !TSF:RTE:7 UNKNOWN
10370 !TSF:MSG:SEND,0-0-7-7,s=13,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
10376 GWT:IMQ:TOPIC=mygateway10-in/7/14/1/1/2, MSG RECEIVED
10383 !TSF:RTE:7 UNKNOWN
11612 !TSF:MSG:SEND,0-0-7-7,s=14,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
11618 GWT:IMQ:TOPIC=mygateway10-in/7/15/1/1/2, MSG RECEIVED
11625 !TSF:RTE:7 UNKNOWN
12854 !TSF:MSG:SEND,0-0-7-7,s=15,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
12860 GWT:IMQ:TOPIC=mygateway10-in/7/16/1/1/2, MSG RECEIVED
12867 !TSF:RTE:7 UNKNOWN
14096 !TSF:MSG:SEND,0-0-7-7,s=16,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
14102 GWT:IMQ:TOPIC=mygateway10-in/7/17/1/1/2, MSG RECEIVED
14109 !TSF:RTE:7 UNKNOWN
15338 !TSF:MSG:SEND,0-0-7-7,s=17,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
15344 GWT:IMQ:TOPIC=mygateway10-in/7/18/1/1/2, MSG RECEIVED
15351 !TSF:RTE:7 UNKNOWN
16580 !TSF:MSG:SEND,0-0-7-7,s=18,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
16589 GWT:IMQ:TOPIC=mygateway10-in/7/19/1/1/2, MSG RECEIVED
16594 !TSF:RTE:7 UNKNOWN
17823 !TSF:MSG:SEND,0-0-7-7,s=19,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
17829 GWT:IMQ:TOPIC=mygateway10-in/7/4/1/1/2, MSG RECEIVED
17836 !TSF:RTE:7 UNKNOWN
19067 !TSF:MSG:SEND,0-0-7-7,s=4,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
19073 GWT:IMQ:TOPIC=mygateway10-in/7/5/1/1/2, MSG RECEIVED
19080 !TSF:RTE:7 UNKNOWN
20309 !TSF:MSG:SEND,0-0-7-7,s=5,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
20315 GWT:IMQ:TOPIC=mygateway10-in/7/6/1/1/2, MSG RECEIVED
20322 !TSF:RTE:7 UNKNOWN
21551 !TSF:MSG:SEND,0-0-7-7,s=6,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
21557 GWT:IMQ:TOPIC=mygateway10-in/7/7/1/1/2, MSG RECEIVED
21564 !TSF:RTE:7 UNKNOWN
22793 !TSF:MSG:SEND,0-0-7-7,s=7,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
22799 GWT:IMQ:TOPIC=mygateway10-in/7/8/1/1/2, MSG RECEIVED
22806 !TSF:RTE:7 UNKNOWN
24035 !TSF:MSG:SEND,0-0-7-7,s=8,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
24041 GWT:IMQ:TOPIC=mygateway10-in/7/9/1/1/2, MSG RECEIVED
24048 !TSF:RTE:7 UNKNOWN
25277 !TSF:MSG:SEND,0-0-7-7,s=9,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
25283 GWT:IMQ:TOPIC=mygateway10-in/7/21/1/1/2, MSG RECEIVED
25290 !TSF:RTE:7 UNKNOWN
26519 !TSF:MSG:SEND,0-0-7-7,s=21,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
26525 GWT:IMQ:TOPIC=mygateway10-in/7/22/1/1/2, MSG RECEIVED
26532 !TSF:RTE:7 UNKNOWN
27761 !TSF:MSG:SEND,0-0-7-7,s=22,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
27767 GWT:IMQ:TOPIC=mygateway10-in/7/23/1/1/2, MSG RECEIVED
27774 !TSF:RTE:7 UNKNOWN
29003 !TSF:MSG:SEND,0-0-7-7,s=23,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
29009 GWT:IMQ:TOPIC=mygateway10-in/7/24/1/1/2, MSG RECEIVED
29016 !TSF:RTE:7 UNKNOWN
30245 !TSF:MSG:SEND,0-0-7-7,s=24,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
30251 GWT:IMQ:TOPIC=mygateway10-in/7/3/1/1/2, MSG RECEIVED
30258 !TSF:RTE:7 UNKNOWN
31487 !TSF:MSG:SEND,0-0-7-7,s=3,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
31493 GWT:IMQ:TOPIC=mygateway10-in/7/2/1/1/2, MSG RECEIVED
31500 !TSF:RTE:7 UNKNOWN
32729 !TSF:MSG:SEND,0-0-7-7,s=2,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
32737 GWT:TPC:IP=192.168.1.22
32739 GWT:RMQ:CONNECTING...
32868 GWT:RMQ:OK
32869 GWT:TPS:TOPIC=mygateway10-out/0/255/0/0/18,MSG SENT
32935 GWT:IMQ:TOPIC=mygateway10-in/7/255/3/0/6, MSG RECEIVED
32941 !TSF:RTE:7 UNKNOWN
34170 !TSF:MSG:SEND,0-0-7-7,s=255,c=3,t=6,pt=0,l=1,sg=0,ft=0,st=NACK:M
34176 GWT:IMQ:TOPIC=mygateway10-in/7/20/1/1/2, MSG RECEIVED
34183 !TSF:RTE:7 UNKNOWN
35412 !TSF:MSG:SEND,0-0-7-7,s=20,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
35418 GWT:IMQ:TOPIC=mygateway10-in/7/1/1/1/2, MSG RECEIVED
35425 !TSF:RTE:7 UNKNOWN

And it goes in a loop.
I tested with ESP8266, ESP32s, Mysensors Master branch, Mysensors development branch.
No change.
(esp8266 somethimes goes into panic mode)

In my opinion any amount of failed consecutive radio messages should not force a mqtt server reconnection.
If there are fewer then 25 messages, lets say 24 messages and the 25th comes after a while, no problem. I have a problem when in mqtt queue there are more then 24 consecutive messages that cannot be acknowledged.