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!

Finally, after reading the data sheet, I see the problem with the watchdog timer: its value can not be read.
Timer2 would be a nice option. I will have a look at that. Thanks for your answers!

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

Finally, after reading the data sheet, I see the problem with the watchdog timer: its value can not be read.
Timer2 would be a nice option. I will have a look at that. Thanks for your answers!

@Yveaux I mean to modify the MySensors code, adding a new feature to MySensors. The accuracy can be very good if it is implemented in the right way.

Something like this, ignoring some details to be solved:
Sleep() sets a variable inSleep to true, starts the watchdog counter and goes to sleep.
When millis() is called and inSleep is true, millis() must add the elapsed time (as calculated from the watchdog timer) to the millis counter and return this value. This can only happen in an ISR.
Before returning, the sleep() function adds the elapsed time (as calculated from the watchdog timer) to the millis counter and sets inSleep to false, in one atomic action.

Accuracy can be as good as one or two millis per sleep I guess, max one at start and max one at stop.

What is the problem in modifying the millis() function in the way I proposed? Why is it impossible to add the watchdog count to the millis counter?
I know that currently this is not supported, but it would be a nice feuture to have.

Re: gw.sleep(...) and milis()
I have a use case on an ATMega328 where I want to know the millis, also after a sleep.

I have been thinking about it and this crossed my mind:

A solution could be to modify the millis() function. If it is called while the sleep function was active (that can only happen in an ISR I guess) it could set the millis counter to the saved millis at sleep start, plus the elapsed time since sleep start (i.e. the sleep timer count). It should also do so at sleep end.
Unfortunately I do not know much about the internals of the MySensors and Arduino software, so my suggestion might be complete nonsens.

My preferred solution would be the use of a real time OS, But that seems very complicated.

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.