@mfalkvidd The development branch has the same behavior. An edit in core/MyGatewayTransportMQTTClient.cpp (I added a "delay(3000)" after line 148 in reconnectMQTT(void)) made it a lot better!

Looks like this was solved in branch develop at Jan, 6, 2019:
98355b2d ( tekka 2019-01-06 18:14:10 +0100 158) delay(1000);

@hakha4 said in RPI Gateway Error:

I have updated Buster and Domoticz works ok but can't get the gw to work. Btw is it normal (ok) to get a number of warnings when compiling??

I am getting the same warnings (about string truncation), that doesn't make it "normal", but I have a working gateway in Buster on my raspberry pi (raspbian). The error is about the radio. You have a rf24, I use a rfm69, so that is quite different.
Another difference is the gateway version. Mine is using protocol version 2.4.0-alpha:

Apr 29 22:12:35 INFO  Starting gateway...
Apr 29 22:12:35 INFO  Protocol version - 2.4.0-alpha
Apr 29 22:12:35 DEBUG MCO:BGN:INIT GW,CP=RPNGL---,FQ=NA,REL=0,VER=2.4.0-alpha
Apr 29 22:12:35 DEBUG TSF:LRT:OK
Apr 29 22:12:35 DEBUG TSM:INIT
Apr 29 22:12:35 DEBUG TSF:WUR:MS=0
Apr 29 22:12:35 DEBUG TSM:INIT:TSP OK
Apr 29 22:12:35 DEBUG TSM:INIT:GW MODE
Apr 29 22:12:35 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
Apr 29 22:12:35 DEBUG MCO:REG:NOT NEEDED
Apr 29 22:12:35 DEBUG MCO:BGN:STP
Apr 29 22:12:35 DEBUG MCO:BGN:INIT OK,TSP=1
Apr 29 22:12:35 DEBUG GWT:RMQ:CONNECTING...
Apr 29 22:12:35 DEBUG connected to 127.0.0.1
Apr 29 22:12:35 DEBUG GWT:RMQ:OK
Apr 29 22:12:35 DEBUG GWT:TPS:TOPIC=mysensors/all/0/255/0/0/18,MSG SENT
Apr 29 22:12:35 DEBUG TSM:READY:NWD REQ
Apr 29 22:12:35 DEBUG ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Apr 29 22:12:40 DEBUG TSF:MSG:READ,153-153-0,s=4,c=1,t=23,pt=0,l=4,sg=0:3.75
Apr 29 22:12:40 DEBUG GWT:TPS:TOPIC=mysensors/all/153/4/1/0/23,MSG SENT

I am using this version of MySensors (branch development):

git status
On branch development
Your branch is up to date with 'origin/development'.

The last commits that I have are:

git log
commit 397b70f37b4fc5ffd15dddf49364cce2408e5bb5 (HEAD -> development, origin/development, origin/HEAD)
Author: Henrik Ekblad <henrik.ekblad@gmail.com>
Date:   Mon Jan 6 15:47:04 2020 +0100

    Fix logparser frequency regexp (#1380)

commit 9040272ccbf57026780ed10f589a5498db729ae9
Author: Olivier <tekka007@users.noreply.github.com>
Date:   Mon Dec 9 22:43:02 2019 +0100

    Development version 2.4.0-alpha (#1373)

So maybe you can try this newer development branch to build your gateway.

Looks like this was solved in branch develop at Jan, 6, 2019:
98355b2d ( tekka 2019-01-06 18:14:10 +0100 158) delay(1000);

@mfalkvidd The development branch has the same behavior. An edit in core/MyGatewayTransportMQTTClient.cpp (I added a "delay(3000)" after line 148 in reconnectMQTT(void)) made it a lot better!

mysgw (the mysensors gateway) sends a continuous flow of error messages to the log file if mysgw is started and the configured mqtt broker is not available. I am running a quite recent version (built on Dec 5, 2018), branch master.
My problem with mysgw is the excessive logging. I know I can resolve it by configuring my mqtt broker, but mysgw should not produce such a massive amount of logging if the mqtt broker is not available.

Dec  5 11:19:13 raspberrypi mysgw: failed to connect
Dec  5 11:19:13 raspberrypi mysgw: GWT:RMQ:MQTT RECONNECT
Dec  5 11:19:13 raspberrypi mysgw: connect: Connection refused
Dec  5 11:19:13 raspberrypi mysgw: failed to connect
Dec  5 11:19:13 raspberrypi mysgw: GWT:RMQ:MQTT RECONNECT
Dec  5 11:19:13 raspberrypi mysgw: connect: Connection refused
Dec  5 11:19:13 raspberrypi mysgw: failed to connect
Dec  5 11:19:13 raspberrypi mysgw: GWT:RMQ:MQTT RECONNECT
Dec  5 11:19:13 raspberrypi mysgw: connect: Connection refused
Dec  5 11:19:13 raspberrypi mysgw: failed to connect

Started on the command line (only first lines copied, there are hundreds of lines per second):

root@raspberrypi:/home/pi# mysgw
Dec 05 11:26:42 INFO  Starting gateway...
Dec 05 11:26:42 INFO  Protocol version - 2.3.0
Dec 05 11:26:42 DEBUG MCO:BGN:INIT GW,CP=RPNGL---,VER=2.3.0
Dec 05 11:26:42 DEBUG TSF:LRT:OK
Dec 05 11:26:42 DEBUG TSM:INIT
Dec 05 11:26:42 DEBUG TSF:WUR:MS=0
Dec 05 11:26:42 DEBUG TSM:INIT:TSP OK
Dec 05 11:26:42 DEBUG TSM:INIT:GW MODE
Dec 05 11:26:42 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
Dec 05 11:26:42 DEBUG MCO:REG:NOT NEEDED
Dec 05 11:26:42 DEBUG MCO:BGN:STP
Dec 05 11:26:42 DEBUG MCO:BGN:INIT OK,TSP=1
Dec 05 11:26:42 DEBUG GWT:RMQ:MQTT RECONNECT
Dec 05 11:26:42 ERROR connect: Connection refused
Dec 05 11:26:42 ERROR failed to connect
Dec 05 11:26:42 DEBUG GWT:RMQ:MQTT RECONNECT
Dec 05 11:26:42 ERROR connect: Connection refused
Dec 05 11:26:42 ERROR failed to connect
Dec 05 11:26:42 DEBUG GWT:RMQ:MQTT RECONNECT
Dec 05 11:26:42 ERROR connect: Connection refused
Dec 05 11:26:42 ERROR failed to connect
Dec 05 11:26:42 DEBUG GWT:RMQ:MQTT RECONNECT
Dec 05 11:26:42 ERROR connect: Connection refused
Dec 05 11:26:42 ERROR failed to connect
Dec 05 11:26:42 DEBUG GWT:RMQ:MQTT RECONNECT
Dec 05 11:26:42 ERROR connect: Connection refused
Dec 05 11:26:42 ERROR failed to connect
Dec 05 11:26:42 DEBUG GWT:RMQ:MQTT RECONNECT
Dec 05 11:26:42 ERROR connect: Connection refused
Dec 05 11:26:42 ERROR failed to connect

@scalz A useful addition could be that the controller only runs on Windows. I bumped into this limitation after quite a few succesful steps. Is there a Linux or Java alternative?