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

Gateway >> Node >> Device >> Metrics

Nodes have devices attached and each device has metrics.

@mfalkvidd said in Best password manager?:

Bitwarden

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

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.

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

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.

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.

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".

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

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

SimoneBnc created this issue in mysensors/MySensors

open RPI3 GW poor RSSI on RFM69HW #1077

@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