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);
@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.
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.
@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.
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:
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.
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.
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 <firstname.lastname@example.org> Date: Mon Jan 6 15:47:04 2020 +0100 Fix logparser frequency regexp (#1380) commit 9040272ccbf57026780ed10f589a5498db729ae9 Author: Olivier <email@example.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.