Yes, the pin change intgerrupt gives me what I want. The sleep call also wakes up on this interrupt, I thought it would only wake up in INT0 or INT1.

So for now my experiments with FreeRTOS end.

@electrik thanks for the hint!

@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);

Yes, the pin change intgerrupt gives me what I want. The sleep call also wakes up on this interrupt, I thought it would only wake up in INT0 or INT1.

So for now my experiments with FreeRTOS end.

@electrik thanks for the hint!

@skywatch There should be no reason why a RTOS would drain batteries quickly, one could even expect the opposite. In a RTOS there is no need to loop, it can simply wait for any interrupt to arrive. That is theory. But I suspect FreeRTOS not doing a low-power sleep, and instead simply looping the cpu. There might be possibilities to do a low-power sleep (in the loop() method).
Connecting diodes to other pins is not very simple in my situation. I have this easypirmultisensorbox (https://github.com/EasySensors/easyPIRmultisensorsBox2) and soldering will not be easy:-).
The PIR sensor in this thing is connected to pin 7. In the MySensors sleep method only pins 2 and 3 can be used for interrupts.
This Arduino forum post https://forum.arduino.cc/index.php?topic=704977.0 didn't give me much hope. It is bare Arduino that already is problematic with FreeRTOS, and I guess that MySensors will make things even more complicated.
So maybe I will take a look at dirtier solutions, like writing my own sleep method. If I don't find a solution within a few months, I might even resort to one of the worst, dirtiest and appalling software mechanism ever: polling.

@jenspr said in Use FreeRTOS?:

The mysensor-library s building some kind of own operating system It hijacks a lot of things If you want to use them, you need to know how. For example save&read from EEPROM.
Of course it is possible to handle everything.

FreeRTOS would set the system on a standard base.
Mysensor could "use" the functionality of FreeRTOS including different platforms and focus on the software for radio communication, security, etc..

But FreeRTOS is also not very easy to understand and there are some tricky things to consider. In the end is it also complicated to understand everything as soon you need to go in detail. i am pretty sure that you would have had this or other questions if mysensors would set up on FreeRTOS.

In the end a normal mysensor node just wants to send some collected data over the air and is not doing a lot of other things in parallel.
So I dont know if it would make it more easy or more complicated.

Maybe it is worse a thought if somebody starts to think about mysensor 3.0?

Yes, I totally agree with you. The "problem" is, that I am a big fan of real time solutions, it was the subject of my final project at school. Things won't be easier, mistakes are easily made in concurrent programming.
I see these advantages of using a real time OS:

• better hardware support (more interrupts)
• nice features to support elegant real-time concurrent programming (queues, semaphores etc.)
  The disadvantages I see:
• extra software, more complexity (download, documentation to read)
• concurrent programming is error-prone

I am going to spend a few hours trying FreeRTOS with MySensors for my application, it looks like there are not many people who have tried it.

Carl

@skywatch I would like to see the "diode matrix solution", but I cannot find it. Is it in Arduino or in MySensors?

Re: The "new" Arduino Pro IDE

Currently I am running into a limitation of MySensors. Sleeping can be done on only two interrupts. I am using an Arduino ATMega 328.
The bare Arduino platform doesn’t provide a solution.
A real time OS could provide a neat solution and imho that would be the right place to implement such things as interrupts.
The first OS I found was FreeRTOS, there is a library available in the Arduino IDE.
It would be nice if MySensors had a mode to run on FreeRTOS.
Is there anybody who already built this?
I don’t have enough knowledge and time to develop this on my own. maybe someone can help me.

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