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!

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

@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 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!

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.

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