Posts made by willemx

@NaCl
No, it did not work as expected. It could not provide enough power for my application. I ended up buying a more powerful setup (10W solar panel + included controller/BMS) with 4 Li-Ion cells and a 3V3 step down converter.

@SuperNinja : Nice 'schematic' !
I had not thought of a buck/boost converter, but this might also be a good idea in my setup (we just had a full week of almost non-stop rain and drizzle).
I think I will stick with the LiFePo4 / TP5000. I guess the switch mode TP5000 should be more efficient than the linear TP4056.
My next target will be designing a 3d printable weather proof case and than I will do some actual field testing. I am a bit worried about the stamina of LiFePo4's in cold weather conditions. Winter is coming...

Thank you all for your recommendations!

@NeverDie : the TP5000 also has built-in battery protection, so I think I could just use a standard LiFePo4

@skywatch : my nodes only send a few dozen messages per day and are in deep sleep 99.9% of the time, so I do not need much power. I don't expect battery temperature to be an issue in my setup (I live in the Netherlands, very moderate climate)

@ncollins : do you know if a HT7333 will still work if most of the time there is only 3.3V at the input? I find the datasheets not very clear at this point. I should do some experimenting... And I wil apply your suggested large capacitor.
Did you use a regulator yourself ?

I need to power some outdoor sensors (built with Pro Mini + RFM95) with solar panels. I plan to use a single LiFePo4 battery and a TP5000 type charger and a small 6V solar panel.
I think I should not need any further regulation and can just connect the battery to VCC of the Pro Mini and the RM95.
Or should I be worried about the voltage maybe becoming too high in bright sunshine? Or what would happen if I took out the battery while the charger is still connected?
Does someone have any experience with this kind of setup?

@Yveaux Thanks for the tip, I certainly will order my next RFM modules from ideetron.

It turned out that my problems were not gone yet. When powered up, the ethernet gateways sometimes worked, and sometimes not. They got stuck waiting for the W5500 ethernet module. After some experimenting I found that the reset procedure of the W5500 is unreliable if the reset pin is left unconnected, leaving the W5500 in some undefined state after power up.
I solved this by connecting the W5500 reset pin to an unused pin of the Arduino and performing a software controlled reset on power up:

#define W5500_RESET_PIN     4

void before() {
    pinMode(W5500_RESET_PIN, OUTPUT);
    digitalWrite(W5500_RESET_PIN, LOW);
    delay(10);
    digitalWrite(W5500_RESET_PIN, HIGH);
    delay(1000);
}

Now the gateways always work when powered up.
It might be helpful to add this tip to the "Building an ethernet gateway" guide.

Hi @Yveaux, thanks for stepping in. I added the before() function, but no change.
I had tried two RFM95 modules which both failed. Then I tried a third RFM95 module, but this failed in a different way: it did initialise, but then it reset itself and started over again. Although I didn't have much faith anymore I did try my last and fourth module and to my surprise it did work!
I think maybe I got a bunch of unreliable modules. I did some inspection under a microscope and found a tombstoned resistor on one module and another module had a lot of debris between the components. Somehow I managed to get the resistor in place with my hotgun and I cleaned the other modules. Now I have 3 out of 4 RFM95 modules working!
The before() function does not seem to matter.
Only one module is still caught in an endless init loop:

0 MCO:BGN:INIT GW,CP=RLNGA---,FQ=8,REL=255,VER=2.3.2
53 MCO:BGN:BFR
69 TSM:INIT
81 TSF:WUR:MS=0
100 RFM95:INIT
114 RFM95:INIT:PIN,CS=6,IQP=2,IQN=0
163 RFM95:PTX:LEVEL=13
188 TSM:INIT:TSP OK
208 TSM:INIT:GW MODE
231 TSM:READY:ID=0,PAR=0,DIS=0
264 MCO:REG:NOT NEEDED
1026 GWT:TPC:IP=192.168.178.75
2058 MCO:BGN:STP
2076 MCO:BGN:INIT OK,TSP=1
2260 GWT:TPC:IP=192.168.178.75
3293 GWT:RMQ:CONNECTING...
3325 GWT:RMQ:OK
3344 GWT:TPS:TOPIC=mygateway3-out/0/255/0/0/18,MSG SENT
3403 TSM:READY:NWD REQ
3428 RFM95:SWR:SEND,TO=255,SEQ=0,RETRY=0
0 MCO:BGN:INIT GW,CP=RLNGA---,FQ=8,REL=255,VER=2.3.2
53 MCO:BGN:BFR
69 TSM:INIT
81 TSF:WUR:MS=0
100 RFM95:INIT
114 RFM95:INIT:PIN,CS=6,IQP=2,IQN=0
163 RFM95:PTX:LEVEL=13
188 TSM:INIT:TSP OK
208 TSM:INIT:GW MODE
231 TSM:READY:ID=0,PAR=0,DIS=0
264 MCO:REG:NOT NEEDED
1026 GWT:TPC:IP=192.168.178.75
2058 MCO:BGN:STP
2076 MCO:BGN:INIT OK,TSP=1
2260 GWT:TPC:IP=192.168.178.75
3293 GWT:RMQ:CONNECTING...
3526 GWT:RMQ:OK
3545 GWT:TPS:TOPIC=mygateway3-out/0/255/0/0/18,MSG SENT
3604 TSM:READY:NWD REQ
3629 RFM95:SWR:SEND,TO=255,SEQ=0,RETRY=0
0 MCO:BGN:INIT GW,CP=RLNGA---,FQ=8,REL=255,VER=2.3.2
53 MCO:BGN:BFR
69 TSM:INIT
...

But never mind, I'm very happy with my working gateways now.
BTW, can someone recommend a reliable source for RFM95 modules? I got mine here: https://nl.aliexpress.com/item/32831799362.html?spm=a2g0s.9042311.0.0.27424c4dgIoZKr

I am building 3 ethernet/MQTT gateways, one for NRF24, one for RFM69HCW and one for RFM95W.
For ethernet, I use the HanRun W5500 Lite modules (https://nl.aliexpress.com/item/32598945210.html?spm=a2g0s.9042311.0.0.27424c4d7XOuUi)
For the processor I use Arduino Pro Mini 8MHz, 3.3V.
I designed 2 small PCB's to build these gateways, one for the NRF24 module and one for the RFM modules since they have the same pinout.
I use hardware SPI for all interfaces; connections are as follows...
W5500:

W5500 SCK  - Arduino SCK
W5500 MISO - Arduino MISO
W5500 MOSI - Arduino MOSI
W5500 SS   - Arduino SS

RFM69/95 gateway:

RFM69/95 SCK  - Arduino SCK
RFM69/95 MISO - Arduino MISO
RFM69/95 MOSI - Arduino MOSI
RFM69/95 NSS  - Arduino D6
RFM69/95 DIO0 - Arduino D2

NRF24 gateway:

NRF24 SCK  - Arduino SCK
NRF24 MISO - Arduino MISO
NRF24 MOSI - Arduino MOSI
NRF24 CSN  - Arduino D6
NRF24 CE   - Arduino D5

The NRF24 gateway and the RFM69 gateway are working fine, but I cannot get the RFM95 gateway working. If I plug in the RFM95 module, the ethernet module will not work anymore. The RFM95 gateway initcode runs ok but the ethernet code will abort with a timeout.
If I unplug the RFM95 module, the W5500 runs fine (tested with simple ethernet client sketch).
If the RFM95 is in the circuit (with NSS line forced to low) the W5500 will not work anymore.
If I replace the RFM95 with a RFM69, everything is ok again.

This is my gateway sketch:

#define MY_DEBUG
#define MY_BAUD_RATE 9600

#define MY_RADIO_RFM95
#define MY_RFM95_FREQUENCY        RFM95_868MHZ
#define MY_RFM95_CS_PIN           6
#define MY_DEBUG_VERBOSE_RFM95

#define MY_GATEWAY_MQTT_CLIENT

#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway3-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mygateway3-in"
#define MY_MQTT_CLIENT_ID "mysensors-3"
#define MY_MAC_ADDRESS 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0x03

#define MY_CONTROLLER_IP_ADDRESS 192, 168, 178, 90
#define MY_PORT 1883

#define MY_DEFAULT_LED_BLINK_PERIOD 300
#define MY_WITH_LEDS_BLINKING_INVERSE
#define MY_DEFAULT_RX_LED_PIN   7
#define MY_DEFAULT_TX_LED_PIN   8
#define MY_DEFAULT_ERR_LED_PIN  9

#include <Ethernet.h>
#include <MySensors.h>

void setup() {}
void presentation() {}
void loop() {}

Am I doing something wrong? I thought the RFM69 and RFM95 are pin compatible, but they are not?
I cannot find any significant difference in the datasheets.
Has someone else managed to get a ethernet/RFM95 gateway working?

@mfalkvidd If I add a sequence number to all messages, is there a way to include some code in the gateway sketch to filter out duplicate messages before they are relayed to the MQTT broker?
I mean without modifying the MySensors gateway code, but just inserting some kind of hook that gets called by the gateway code on every incoming message.
I could not find such a hook in the library API. There is a receive() function, but I don't think this is meant for this purpose. Ideally there should be a onReceive() function that can do some processing on messages and return a status code to indicate that a message should be discarded.

Thanks @mfalkvidd for the Two Generals theory, that was very enlightening.
So I assume the following scenario is happening in my situation:

1. the sensor node sends a message to the gateway
2. the gateway receives the message and sends acknowledge back to sensor node
3. the gateway relays the message to the MQTT broker
4. the sensor node fails to receive the acknowledgement from the gateway so it resends the message to the gateway
5. the gateway receives the message, thinks it is a new message and also relays this message to the MQTT broker

Not sure if this scenario is correct, but it explains my controller receiving duplicate messages.
It seems as if a gateway cannot discriminate between a new message and a resent message?
If it could, then it should simply ignore resent messages that have already been relayed to the MQTT broker.

That is a bit disappointing and also confusing
So the returned boolean of the MySensors send() function is not to be trusted? The docs state that send "Returns true if message reached the first stop on its way to destination". In my test setup there is a direct connection between node and gateway and every call to send() returns true, yet apparently this is no guarantee that the message reached the gateway.

@mfalkvidd : In the gateway log I can indeed see that some messages are sent twice
@Yveaux : I modified my controller to subscribe to the gateway using QoS=2 (was 0), but this made no difference; I keep receiving duplicate packets.
@electrik : Your suggestion could be right. This is consistent with the duplicate messages in the gateway log and the duplicate messages to the controller despite QoS=2. If the node resends the message, it is apparently considered by the gateway to be a 'new' message.
So the question is now why the gateway does not send an acknowledgment for every message. I thought that RFM69 modules were very reliable.

Done some more debugging...
Realised that maybe the MQTT broker can also be the culprit. I modified my controller code to make it inspect the "dup"-flag of received packets. So far I found out that this flag was never set although there were duplicate messages received, so I guess this flag has some other meaning (maybe duplicate messages for different topics?)
Also set the (Mosquitto) broker config to "log_types all", but unfortunately this does not log the message payload so it is very hard to check for duplicate packets in the logfile.
Maybe I should just make my controller ignore duplicate messages...

My MQTT gateways produce lots of duplicate messages. I have two gateways in my network: one with a NRF24 radio and one with a RFM69 radio. Both gateways use a ESP8266 processor board (Wemos D1 mini) and communicate via WiFi with a MQTT broker on a raspberry pi. In my controller (on a Linux machine) I see lots of duplicate messages arriving from the MQTT broker.
Duplicate messages come from both gateways and can originate from all network nodes.
I created a small RFM69 based testnode that periodically sends an incrementing counter and checks for send errors. There are never any send errors, but I do get duplicate messages from this node.
What can be the reason that a gateway should send a message multiple times?

You were right; there was a minuscule piece of wire strand between two contacts and after removing it all is fine now.
Also checked all the radio's again which is easy now I have a working configuration and there was indeed one defective radio module.
Thanks everyone for unblocking me!

config on WEMOS D1 gateway:

#define MY_RADIO_RFM69
#define MY_RFM69_NEW_DRIVER
#define MY_DEBUG_VERBOSE_RFM69
#define MY_IS_RFM69HW

log:

--- Miniterm on /dev/cu.SLAB_USBtoUART  9600,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
0�~?�4�Ҷ␞��␄OAqr��62 MCO:BGN:INIT GW,CP=RPNGE---,FQ=80,REL=255,VER=2.3.2
119 TSF:LRT:OK
135 TSM:INIT
148 TSF:WUR:MS=0
166 RFM69:INIT
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 3
cnt 

connected with TOUTATIS, channel 2
dhcp client start...
ip:192.168.178.68,mask:255.255.255.0,gw:192.168.178.1
383 RFM69:INIT:PIN,CS=15,IQP=5,IQN=5
423 RFM69:PTX:LEVEL=5 dBm
450 !RFM69:INIT:SANCHK FAIL
479 !TSM:INIT:TSP FAIL
503 TSM:FAIL:CNT=1
523 TSM:FAIL:DIS
540 TSF:TDI:TSL
557 RFM69:RSL
pm open,type:2 0
10573 TSM:FAIL:RE-INIT
10597 TSM:INIT
10612 RFM69:INIT
10630 RFM69:INIT:PIN,CS=15,IQP=5,IQN=5
10673 RFM69:PTX:LEVEL=5 dBm
10702 !RFM69:INIT:SANCHK FAIL
10734 !TSM:INIT:TSP FAIL
10760 TSM:FAIL:CNT=2
10781 TSM:FAIL:DIS
10801 TSF:TDI:TSL
10820 RFM69:RSL
20838 TSM:FAIL:RE-INIT
20862 TSM:INIT
20877 RFM69:INIT
20895 RFM69:INIT:PIN,CS=15,IQP=5,IQN=5
20938 RFM69:PTX:LEVEL=5 dBm
20967 !RFM69:INIT:SANCHK FAIL
20999 !TSM:INIT:TSP FAIL
21025 TSM:FAIL:CNT=3
21047 TSM:FAIL:DIS
21066 TSF:TDI:TSL
21085 RFM69:RSL
31103 TSM:FAIL:RE-INIT
31127 TSM:INIT
31142 RFM69:INIT
31160 RFM69:INIT:PIN,CS=15,IQP=5,IQN=5
31203 RFM69:PTX:LEVEL=5 dBm
31232 !RFM69:INIT:SANCHK FAIL
31264 !TSM:INIT:TSP FAIL
31290 TSM:FAIL:CNT=4
31312 TSM:FAIL:DIS
31332 TSF:TDI:TSL
31350 RFM69:RSL
41368 TSM:FAIL:RE-INIT
41392 TSM:INIT
41407 RFM69:INIT
41425 RFM69:INIT:PIN,CS=15,IQP=5,IQN=5
41468 RFM69:PTX:LEVEL=5 dBm
41497 !RFM69:INIT:SANCHK FAIL
41529 !TSM:INIT:TSP FAIL
41555 TSM:FAIL:CNT=5
41577 TSM:FAIL:DIS
41596 TSF:TDI:TSL
41615 RFM69:RSL
51633 TSM:FAIL:RE-INIT
51657 TSM:INIT
51672 RFM69:INIT
51690 RFM69:INIT:PIN,CS=15,IQP=5,IQN=5
51733 RFM69:PTX:LEVEL=5 dBm
51762 !RFM69:INIT:SANCHK FAIL
51794 !TSM:INIT:TSP FAIL
51820 TSM:FAIL:CNT=6
51842 TSM:FAIL:DIS
51861 TSF:TDI:TSL
51880 RFM69:RSL
61898 TSM:FAIL:RE-INIT
61922 TSM:INIT
61937 RFM69:INIT
61955 RFM69:INIT:PIN,CS=15,IQP=5,IQN=5
61998 RFM69:PTX:LEVEL=5 dBm
62027 !RFM69:INIT:SANCHK FAIL
62059 !TSM:INIT:TSP FAIL
62085 TSM:FAIL:CNT=7
62107 TSM:FAIL:DIS
62126 TSF:TDI:TSL
62145 RFM69:RSL
122163 TSM:FAIL:RE-INIT
122188 TSM:INIT
122204 RFM69:INIT
122223 RFM69:INIT:PIN,CS=15,IQP=5,IQN=5
122267 RFM69:PTX:LEVEL=5 dBm
122298 !RFM69:INIT:SANCHK FAIL
122330 !TSM:INIT:TSP FAIL
122357 TSM:FAIL:CNT=7
122380 TSM:FAIL:DIS
122401 TSF:TDI:TSL
122421 RFM69:RSL
182439 TSM:FAIL:RE-INIT
182464 TSM:INIT
182480 RFM69:INIT
182499 RFM69:INIT:PIN,CS=15,IQP=5,IQN=5
182543 RFM69:PTX:LEVEL=5 dBm
182574 !RFM69:INIT:SANCHK FAIL
182606 !TSM:INIT:TSP FAIL
182633 TSM:FAIL:CNT=7
182656 TSM:FAIL:DIS
182677 TSF:TDI:TSL
182697 RFM69:RSL
242716 TSM:FAIL:RE-INIT
242741 TSM:INIT
242757 RFM69:INIT
242776 RFM69:INIT:PIN,CS=15,IQP=5,IQN=5
242820 RFM69:PTX:LEVEL=5 dBm
242851 !RFM69:INIT:SANCHK FAIL
242883 !TSM:INIT:TSP FAIL
242910 TSM:FAIL:CNT=7
242933 TSM:FAIL:DIS
242954 TSF:TDI:TSL
242974 RFM69:RSL
302992 TSM:FAIL:RE-INIT
303017 TSM:INIT
303033 RFM69:INIT
303052 RFM69:INIT:PIN,CS=15,IQP=5,IQN=5
303096 RFM69:PTX:LEVEL=5 dBm
303127 !RFM69:INIT:SANCHK FAIL
303159 !TSM:INIT:TSP FAIL
303186 TSM:FAIL:CNT=7
303209 TSM:FAIL:DIS
303230 TSF:TDI:TSL
303250 RFM69:RSL

log from Arduino Pro Mini sensor node:

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

16 MCO:BGN:INIT NODE,CP=RPNNA---,FQ=8,REL=255,VER=2.3.2
28 TSM:INIT
28 TSF:WUR:MS=0
30 RFM69:INIT
32 RFM69:INIT:PIN,CS=10,IQP=2,IQN=0
36 RFM69:PTX:LEVEL=5 dBm
38 TSM:INIT:TSP OK
40 TSM:INIT:STATID=42
45 TSF:SID:OK,ID=42
47 TSM:FPAR
47 RFM69:SWR:SEND,TO=255,SEQ=0,RETRY=0
53 RFM69:CSMA:RSSI=-104
59 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2066 !TSM:FPAR:NO REPLY
2068 TSM:FPAR
2070 RFM69:SWR:SEND,TO=255,SEQ=1,RETRY=0
2074 RFM69:CSMA:RSSI=-107
2080 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4089 !TSM:FPAR:NO REPLY
4091 TSM:FPAR
4093 RFM69:SWR:SEND,TO=255,SEQ=2,RETRY=0
4098 RFM69:CSMA:RSSI=-105
4104 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6113 !TSM:FPAR:NO REPLY
6115 TSM:FPAR
6117 RFM69:SWR:SEND,TO=255,SEQ=3,RETRY=0
6121 RFM69:CSMA:RSSI=-106
6127 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8136 !TSM:FPAR:FAIL
8138 TSM:FAIL:CNT=1
8140 TSM:FAIL:DIS
8142 TSF:TDI:TSL
8142 RFM69:RSL
18145 TSM:FAIL:RE-INIT
18147 TSM:INIT
18149 RFM69:INIT
18151 RFM69:INIT:PIN,CS=10,IQP=2,IQN=0
18155 RFM69:PTX:LEVEL=5 dBm
18157 TSM:INIT:TSP OK
18161 TSM:INIT:STATID=42
18163 TSF:SID:OK,ID=42
18165 TSM:FPAR
18167 RFM69:SWR:SEND,TO=255,SEQ=0,RETRY=0
18173 RFM69:CSMA:RSSI=-107
18180 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
20189 !TSM:FPAR:NO REPLY
20191 TSM:FPAR
20193 RFM69:SWR:SEND,TO=255,SEQ=1,RETRY=0
20197 RFM69:CSMA:RSSI=-103
20203 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
22212 !TSM:FPAR:NO REPLY
22214 TSM:FPAR
22216 RFM69:SWR:SEND,TO=255,SEQ=2,RETRY=0
22220 RFM69:CSMA:RSSI=-105
22226 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
24236 !TSM:FPAR:NO REPLY
24238 TSM:FPAR
24240 RFM69:SWR:SEND,TO=255,SEQ=3,RETRY=0
24244 RFM69:CSMA:RSSI=-109
24250 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
26259 !TSM:FPAR:FAIL
26261 TSM:FAIL:CNT=2
26263 TSM:FAIL:DIS
26265 TSF:TDI:TSL
26267 RFM69:RSL
36270 TSM:FAIL:RE-INIT
36272 TSM:INIT
36274 RFM69:INIT
36276 RFM69:INIT:PIN,CS=10,IQP=2,IQN=0
36280 RFM69:PTX:LEVEL=5 dBm
36282 TSM:INIT:TSP OK
36286 TSM:INIT:STATID=42
36288 TSF:SID:OK,ID=42
36290 TSM:FPAR
36292 RFM69:SWR:SEND,TO=255,SEQ=0,RETRY=0
36298 RFM69:CSMA:RSSI=-105
36304 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
38316 !TSM:FPAR:NO REPLY
38318 TSM:FPAR
38320 RFM69:SWR:SEND,TO=255,SEQ=1,RETRY=0
38324 RFM69:CSMA:RSSI=-105
38330 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
40339 !TSM:FPAR:NO REPLY
40341 TSM:FPAR
40343 RFM69:SWR:SEND,TO=255,SEQ=2,RETRY=0
40347 RFM69:CSMA:RSSI=-102
40353 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
42362 !TSM:FPAR:NO REPLY
42364 TSM:FPAR
42366 RFM69:SWR:SEND,TO=255,SEQ=3,RETRY=0
42371 RFM69:CSMA:RSSI=-104
42377 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
44386 !TSM:FPAR:FAIL
44388 TSM:FAIL:CNT=3
44390 TSM:FAIL:DIS
44392 TSF:TDI:TSL
44394 RFM69:RSL
54398 TSM:FAIL:RE-INIT
54401 TSM:INIT
54403 RFM69:INIT
54405 RFM69:INIT:PIN,CS=10,IQP=2,IQN=0
54409 RFM69:PTX:LEVEL=5 dBm
54411 TSM:INIT:TSP OK
54415 TSM:INIT:STATID=42
54417 TSF:SID:OK,ID=42
54419 TSM:FPAR
54421 RFM69:SWR:SEND,TO=255,SEQ=0,RETRY=0
54427 RFM69:CSMA:RSSI=-105
54433 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
56442 !TSM:FPAR:NO REPLY
56444 TSM:FPAR
56446 RFM69:SWR:SEND,TO=255,SEQ=1,RETRY=0
56451 RFM69:CSMA:RSSI=-104
56457 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
58466 !TSM:FPAR:NO REPLY
58468 TSM:FPAR
58470 RFM69:SWR:SEND,TO=255,SEQ=2,RETRY=0
58474 RFM69:CSMA:RSSI=-104
58480 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
60489 !TSM:FPAR:NO REPLY
60491 TSM:FPAR
60493 RFM69:SWR:SEND,TO=255,SEQ=3,RETRY=0
60497 RFM69:CSMA:RSSI=-102
60504 ?TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
62513 !TSM:FPAR:FAIL
62515 TSM:FAIL:CNT=4
62517 TSM:FAIL:DIS
62519 TSF:TDI:TSL
62521 RFM69:RSL
72525 TSM:FAIL:RE-INIT!

Yes, that is what I ordered and also it is marked on the radio PCB's.

Yes, I added a capacitor to both radio's.

Thank you for your setup example. It is nearly identical to my setup (only I use RFM69HW's).
The only thing I can think of now is that the radio modules must be defective, but I have no means to test this) So I ordered a new batch of RFM69's and hope for the best...

[Edit]
I see that you do not use the following defines as instructed in link text:

#define MY_RFM69_IRQ_PIN D1
#define MY_RFM69_IRQ_NUM MY_RFM69_IRQ_PIN
#define MY_RFM69_CS_PIN D8

I have tried both with and without these defines, but it makes no difference.

Yes, but this cannot be the problem. The node must first find a parent anyway.

This is the gateway code: (comments left out)

#define MY_DEBUG

#define MY_BAUD_RATE 9600

#define MY_RADIO_RFM69
#define MY_IS_RFM69HW
#define MY_RFM69_IRQ_PIN D1
#define MY_RFM69_IRQ_NUM MY_RFM69_IRQ_PIN
#define MY_RFM69_CS_PIN D8

#define MY_GATEWAY_MQTT_CLIENT
#define MY_GATEWAY_ESP8266

#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway2-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mygateway2-in"

#define MY_MQTT_CLIENT_ID "mysensors-2"

#define MY_WIFI_SSID "TOUTATIS"
#define MY_WIFI_PASSWORD "XXXXXXXXXXXXXX"

#define MY_CONTROLLER_IP_ADDRESS 192, 168, 178, 90

#define MY_PORT 1883

#include <ESP8266WiFi.h>
#include <MySensors.h>

void setup() {}

void presentation() {}

void loop() {}

This is the sensor node code:

#define MY_DEBUG 

#define MY_RADIO_RFM69
#define MY_IS_RFM69HW

#include <MySensors.h>
#include <Bounce2.h>

#define CHILD_ID 3
#define BUTTON_PIN  3

Bounce debouncer = Bounce(); 
int oldValue=-1;

MyMessage msg(CHILD_ID,V_TRIPPED);

void setup()  
{  
  pinMode(BUTTON_PIN,INPUT);
  digitalWrite(BUTTON_PIN,HIGH);
  debouncer.attach(BUTTON_PIN);
  debouncer.interval(5);
}

void presentation() {
  present(CHILD_ID, S_DOOR);  
}

void loop() 
{
  debouncer.update();
  int value = debouncer.read();

  if (value != oldValue) {
     send(msg.set(value==HIGH ? 1 : 0));
     oldValue = value;
  }
}

This is the sensor node log:

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

16 MCO:BGN:INIT NODE,CP=RRNNA---,FQ=8,REL=255,VER=2.3.2
28 TSM:INIT
28 TSF:WUR:MS=0
32 TSM:INIT:TSP OK
34 TSM:FPAR
38 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2048 !TSM:FPAR:NO REPLY
2050 TSM:FPAR
2054 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4063 !TSM:FPAR:NO REPLY
4065 TSM:FPAR
4069 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6078 !TSM:FPAR:NO REPLY
6080 TSM:FPAR
6084 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8093 !TSM:FPAR:FAIL
8095 TSM:FAIL:CNT=1
8097 TSM:FAIL:DIS
8099 TSF:TDI:TSL
18102 TSM:FAIL:RE-INIT
18104 TSM:INIT
18106 TSM:INIT:TSP OK
18110 TSM:FPAR
18114 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
20123 !TSM:FPAR:NO REPLY
20125 TSM:FPAR
20129 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
22138 !TSM:FPAR:NO REPLY
22140 TSM:FPAR
22145 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
24154 !TSM:FPAR:NO REPLY
24156 TSM:FPAR
24160 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
26169 !TSM:FPAR:FAIL
26171 TSM:FAIL:CNT=2
26173 TSM:FAIL:DIS
26175 TSF:TDI:TSL
36179 TSM:FAIL:RE-INIT
36182 TSM:INIT
............repeating endlessly

And this is the gateway log:

--- Miniterm on /dev/cu.SLAB_USBtoUART  9600,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
0�~?�4�Ҷ␞��␄OA␌r��61 MCO:BGN:INIT GW,CP=RRNGE---,FQ=80,REL=255,VER=2.3.2
118 TSF:LRT:OK
134 TSM:INIT
148 TSF:WUR:MS=0
167 TSM:INIT:TSP OK
scandone
state: 0 -> 2 (b0)
217 TSM:INIT:GW MODE
239 TSM:READY:ID=0,PAR=0,DIS=0
state: 2 -> 3 (0)
290 MCO:REG:NOT NEEDED
state: 3 -> 5 (10)
add 0
aid 4
cnt 
354 GWT:TPC:CONNECTING...

connected with TOUTATIS, channel 2
dhcp client start...
scandone
1441 MCO:BGN:STP
1459 MCO:BGN:INIT OK,TSP=1
1487 TSM:READY:NWD REQ
1515 ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
ip:192.168.178.68,mask:255.255.255.0,gw:192.168.178.1
2209 GWT:TPC:IP=192.168.178.68
2296 GWT:RMQ:CONNECTING...
2605 GWT:RMQ:OK
2622 GWT:TPS:TOPIC=mygateway2-out/0/255/0/0/18,MSG SENT
pm open,type:2 0
900148 TSF:SAN:OK
1201488 TSM:READY:NWD REQ
1201519 ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
1800148 TSF:SRT:OK
1800168 TSF:SAN:OK
2401489 TSM:READY:NWD REQ
2401520 ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:

So it appears that the gateway is not hanging after all. It just takes a long time between log messages. It is doing a network discovery broadcast every 20 minutes or so.
But the gateway and sensor (1 meter distance) node do not connect...

Yes, I can see the gateway connecting to the broker. And yes, it is a local sensor that is trying to find the gateway (I just copied the "door/window/button" example sketch for testing)

I am trying to create a MQTT gateway on a ESP8266 with a RFM69HW radio using the config options from the example sketch:

#define MY_DEBUG
#define MY_BAUD_RATE 9600
#define MY_RADIO_RFM69
#define MY_IS_RFM69HW
#define MY_RFM69_IRQ_PIN D1
#define MY_RFM69_IRQ_NUM MY_RFM69_IRQ_PIN
#define MY_RFM69_CS_PIN D8
#define MY_GATEWAY_MQTT_CLIENT
#define MY_GATEWAY_ESP8266

This is the debug output from the gateway:

--- Miniterm on /dev/cu.SLAB_USBtoUART  9600,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
␒`␓␀�9���␒�␓␐�)���60 MCO:BGN:INIT GW,CP=RRNGE---,FQ=80,REL=255,VER=2.3.2
118 TSF:LRT:OK
133 TSM:INIT
147 TSF:WUR:MS=0
167 TSM:INIT:TSP OK
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

connected with TOUTATIS, channel 2
dhcp client start...
ip:192.168.178.64,mask:255.255.255.0,gw:192.168.178.1
388 TSM:INIT:GW MODE
411 TSM:READY:ID=0,PAR=0,DIS=0
443 MCO:REG:NOT NEEDED
530 GWT:TPC:CONNECTING...
1557 MCO:BGN:STP
1575 MCO:BGN:INIT OK,TSP=1
1604 TSM:READY:NWD REQ
1633 ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
scandone
2893 GWT:TPC:IP=192.168.178.64
2934 GWT:RMQ:CONNECTING...
2992 GWT:RMQ:OK
3010 GWT:TPS:TOPIC=mygateway2-out/0/255/0/0/18,MSG SENT
pm open,type:2 0

After this line, there is no more output; the gateway just seems to hang.
I have an arduino node with a RFM69HW radio running trying to connect to the gateway, but it cannot find a parent node: lots of !TSM:FPAR:NO REPLY debug messages
I am using MySensors V2.3.2 on all nodes.

I have tried different ESP8266 boards (NodeMCU, Wemos D1) that I know to be good (I have used them succesfully as gateways with NRF24 radio's). Also tried several new RFM69HW boards and various power supplies that I have used succesfully with other working nodes but all with the same results.

I could use some advice on how to proceed...

One more update:
Because I mostly use PlatformIO as my IDE and I don't know how to downgrade board versions there,
as @scalz suggested, I tried the development version of MySensors.
I am happy to report that this also solves the problem.

My simple sketch is now working fine. So it appears that you can use the ESP32 support in MySensors to build non-gateway nodes too.
(For the moment, I am not going to investigate the "Brownout" problem in the ESP32 gateway example any further, because I have a perfectly working ESP8266 MQTT gateway...)
Thank you both for your help!

@electrik : downgrading the board definition to 1.0.0 worked. I can now build the ESP32 gateway.
However, I'm not quite there yet, because I get an endless series of "Brownout detector" messages:

Brownout detector was triggered

ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:808
load:0x40078000,len:6084
load:0x40080000,len:6696
entry 0x400802e4
17 MCO:BGN:INIT GW,CP=RNNGF---,REL=255,VER=2.3.1
21 TSF:LRT:OK
23 TSM:INIT
24 TSF:WUR:MS=0
30 TSM:INIT:TSP OK
32 TSM:INIT:GW MODE
34 TSM:READY:ID=0,PAR=0,DIS=0
39 MCO:REG:NOT NEEDED

Brownout detector was triggered

I am using the latest stable version (2.3.1).
I want to use the ESP32 board because I am building a rather huge sketch (lots of UI and data RAM requirements) and I also need a WiFi connection. I did not know that the ESP32 support in MySensors is only meant to build gateways.
I have also tried building the ESP32 Gateway example, but this produces the same error.
(BTW: I have successfully built the ESP8266 + MQTT gateway).

I am trying to build a simple MySensors node based on an ESP32 board (WEMOS LOLIN32). When compiling/linking I get this error:

/var/folders/kp/0pvgxrnd3jn33s22hqwphrw00000gn/T/arduino_cache_624989/core/core_efeb97a62522d93e012a29bee7d9532f.a(main.cpp.o): In function `app_main':
/Users/willem/Library/Arduino15/packages/esp32/hardware/esp32/1.0.1/cores/esp32/main.cpp:30: multiple definition of `app_main'
sketch/test1.ino.cpp.o:/Users/willem/Documents/Arduino/libraries/MySensors/hal/architecture/ESP32/MyMainESP32.cpp:44: first defined here
collect2: error: ld returned 1 exit status

Can someone explain this error?
BTW: I can successfully build other sketches for this board; it's just when I #include mysensors.h when things go wrong. I get the same results building on Arduino or PlatformIO.
It's this simple test sketch that I'm trying to build:

#define MY_DEBUG
#define MY_RADIO_RF24
#define MY_NODE_ID 42

#include <SPI.h>
#include <MySensors.h>

#define CHILD_ID 3
#define BUTTON_PIN 12

MyMessage msg(CHILD_ID, V_TRIPPED);

void setup() {
    pinMode(BUTTON_PIN, INPUT);
    digitalWrite(BUTTON_PIN, HIGH);
}

void presentation() {
    present(CHILD_ID, S_DOOR);
}

void loop() {
    static int oldValue = 0;
    int value = digitalRead(BUTTON_PIN);

    if (value != oldValue) {
        send(msg.set(value == HIGH ? 1 : 0));
        oldValue = value;
    }
    wait(200);
}

No support for Gateway Transport messages?
GWT:TPS:TOPIC=mygateway1-out/19/255/3/0/21,MSG SENT

@mfalkvidd : thank you for your help. I think you are right about the #undef.
However, using MY_WIFI_BSSID instead of MY_ESP8266_SSID got rid of the original error, but produced lots of other errors in return. So I tried again removing Arduino, libs and board packages and reinstalling everything from scratch using older versions.
I have it working again now, using MySensors version 2.2.0, esp8266 version 2.4.1 and Arduino version 1.8.7.
So I won't be updating libs and board packages any time soon again. This appears to be very risky, or is there a way I could have known this? I could not find any release notes that warned about these breaking changes.
I think for someone who is coming new to all this and just installs the current libs/packages it must be very hard to get things working...

@mfalkvidd I'm using MySensors lib Version 2.3.0 (the same version I used when everything worked) and esp8266 boards package version 2.4.2
Edit: I switched back to boards package version 2.4.0 (and also tried 2.4.1) but the error remains the same.
I am not surprised by this, because I think the error is somewhere else: the error message is simply stating that the preprocessor cannot find the definition of MY_ESP8266_SSID. Very strange, because it clearly is defined.
I noticed one peculiar thing: in my source code all defined symbols are color coded, for example in the line :
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway1-out"
'#define' is green, 'MY_MQTT_PUBLISH_TOPIC_PREFIX' is light-blue and "mygateway1-out" is darker-blue, however, in the line:
#define MY_ESP8266_SSID "FRITZREP",
'#define' is green, "FRITZREP" is darker-blue, but 'MY_ESP8266_SSID' is black.
Not sure if this has any significance...

A few months ago I built a MQTT gateway using the MQTTgatewayESP8266 sketch and it has been running succesfully ever since. I now need to make a small modification, but I am unable to compile the sketch anymore. I have not changed anything to the code yet, but only updated Arduino to V1.8.7 (from 1.8.5) and updated to the latest board definitions.

I am getting this error when compiling the MQTTgatewayESP8266 sketch (for NodeMCU V1 board):

In file included from /Users/willem/Documents/Arduino/libraries/MySensors/MySensors.h:194:0,
                 from /Users/willem/Documents/Arduino/MQTTgatewayESP8266/MQTTgatewayESP8266.ino:124:
/Users/willem/Documents/Arduino/libraries/MySensors/core/MyGatewayTransportMQTTClient.cpp: In function 'bool gatewayTransportInit()':
/Users/willem/Documents/Arduino/libraries/MySensors/core/MyGatewayTransportMQTTClient.cpp:28:22: error: 'MY_ESP8266_SSID' was not declared in this scope
 #define MY_WIFI_SSID MY_ESP8266_SSID
                      ^

Of course MY_ESP8266_SSID is still defined just like it was months ago:

// Set WIFI SSID and password
#define MY_ESP8266_SSID "FRITZREP"

I tried to rebuild everything, uninstalled and re-installed Arduino, libs and boards, but I can't get it running anymore.
Does anyone have a suggestion on how to tackle this?

I have the wireless gateway and Mosquitto running and now I can see the temperature readings coming into node-RED, nicely decoded through mysdecode.
Thanks everyone for these amazing frameworks!

I did install node-red-contrib-mysensors and these nodes will indeed be very useful for me.
However, the part I'm struggling with is how to get input into the mysdecode node. This input needs to come from the gateway of course, but I don't now how to make the gateway send this to node-RED. And also, I don't know what to do with the output of mysencode to get the data to the gateway.
I understand that if I was using a MQTT gateway this would be easy, but I have a WiFi ESP8266 gateway (because I wanted my gateway to communicate wireless and I couldn't find a wireless MQTT gateway...)

EDIT: I just did find a wireless MQTT gateway!
It was somewhat hidden as an example sketch inside the Ethernet MQTT gateway. I will now install Mosquitto on my Raspberry Pi and try if I can get this wireless gateway to speak to Node-RED.
Will report back...

I would like to use Node-RED as my single home automation controller and use MySensors devices for monitoring/control. In the past few days I have managed to get Node-RED up and running on a Raspberry Pi and I also built a MySensors temperature sensor node on a Arduino and a MySensors WiFi gateway using a ESP8266 NodeMCU board.
Now it is time to connect the gateway to Node-RED, but I have no idea how to accomplish this.
I understand that there are "plugins" that should be available for the gateway to connect to various types of controllers, but I cannot find such a plugin to connect to Node-RED.
Can someone show me a small example how to get a temperature reading from my sensor into Node-RED?
And also, how to control a MySensors device (like a relay switch) from Node-RED?