Only if you send a correct message from the controller to the node
the receive function is called. I don't see a receive in your log.
I think in your case the receive-function is not called (or called with a wrong message type or node id). Put a
serial.print("receive() is called with type "); serial.println(message.getType());
on top of the receive function to see if the receive function is called and which type is handed over..
For me, node to node communication is a must have for a reliable secure home automation system. E.g. if a PIR sensor node detects motion, a lamp actuator on a different place should switch on the lamp quickly even if the gateway is off. May be mySensors is the wrong choice for this domain.
My scenario is as follows: A sensor node should report directly to a actuator node wether the gatway or any repeater are on or off. Both nodes should communicate bidirectonal to the gateway if available some different messages. Can anyone give me as an end user a simple example code for the both nodes?
@scalz Thanks for the info. I do not understand much of the software, but I would prefer the second solution as far as it will be integrated in the release. Using an internal API is unacceptable.
But what about the case that the gateway is not reachable and the direct node also but a repeater inbetween could serve it?
Sorry, but this is too much complicated discussion for me. Is it possible or not with the current version for end users like me? If yes, I need a simple how to example.
@dbemowsk Search for node to node communication, you will find e.g.
https://forum.mysensors.org/topic/8716/direct-pairing-of-two-nodes-implementation
https://forum.mysensors.org/topic/826/node-to-node-communication and maybe some more.
@gohan As far as I can remember I used requestTime() on every wakeup which gets time from gateway. Basic implementation based on https://www.mysensors.org/build/rain.
My selfmade rain gauge uses the following algorithm:
It collects amount of rain per day and stores it in eeprom ( with other values) every hour.
If it is not raining, every hour it reports battery voltage and amount of rain per day (mm/day).
If it is raining, it collects bucket tips and reports rain rate (l/h) every 5 minutes. It doesn't matter that the one hour sleep timer is resetted in this case and amount of rain and battery voltage is sent too.
If it stops raining the bucket tip collector is reset to zero after a configurable amount of time, e.g. 1 minute.
Using Arduino pro mini with 2 AA Batteries. Still have 2.9V after 9 month of operation.
See further advanced project nRF24Doctor. Great thanks to @Technovation
@division can you please describe which concrete RF24 Library you took , which version of MySensors library you use, and how you integrate the RF24 library into MySensors?
@AWI Thanks for this great tool. It helped me very much and I tried to implement some extended features.
Here is my current result: It has now a menu interface with two buttons. You can change the pa level and the send repeat tries. Further you can measure the current of the radio module and reset the store. Configuration parameters are stored in EEPROM. See following code for more details.
/*
PROJECT: MySensors / Quality of radio transmission
PROGRAMMER: AWI (MySensors libraries), modified by Heizelmann
DATE: 20160529/ last update: 20171012
FILE: AWI_Send.ino
LICENSE: Public domain
Hardware: ATMega328p board (e.g. Arduino pro nano) w/ NRF24l01
and MySensors 2.1.1
Special:
Summary:
Sends a radio message with counter each x time to determine fault ratio with receiver
Remarks:
Fixed node-id & communication channel to other fixed node
Change log:
20160530 - added moving average on fail/ miss count, update to 2.0
20171012 - extensions by @Heizelmann
. added radio current measurement
. added pa level switching
. added send repeat option
. added LCD Display with parallel interface
. added two button to change pa level, send repeat count, reset store and display radio current
. store config params in EEPROM
. connect timeout with MY_TRANSPORT_WAIT_READY_MS
@see https://forum.mysensors.org/topic/3984/nrf24l01-connection-quality-meter
*/
//**** MySensors *****
// Enable debug prints to serial monitor
//#define MY_DEBUG
#define MY_RADIO_NRF24 // Enable and select radio type attached
//#define MY_RF24_CHANNEL 80 // radio channel, default = 76
// Set LOW transmit power level if you have an amplified NRF-module
// if power your radio separately with a good regulator you can turn up PA level.
// MIN, LOW, HIGH, MAX
#define MY_RF24_PA_LEVEL RF24_PA_MAX //default = MAX on nodes, LOW on gateway and repeater
#define MY_NODE_ID 250
#define NODE_TXT "Quality counter Q 250"
// Init timeout for gateway not reachable
#define MY_TRANSPORT_WAIT_READY_MS 20000 //ms; supported since MySensors V2.1 beta
//#define MY_PARENT_NODE_ID 32 // fixed parent to controller when 0 (else comment out = AUTO)
//#define MY_PARENT_NODE_IS_STATIC
// #define MY_RF24_CE_PIN 7 // Ceech board, 3.3v (7,8) (pin default 9,10)
// #define MY_RF24_CS_PIN 8
#define DESTINATION_NODE 0 // receiving fixed node id (default 0 = gateway)
#define MY_BAUD_RATE 115200
#include <SPI.h>
#include <MySensors.h>
//#include <LiquidCrystal_I2C.h> // LCD display with I2C interface
#include <LiquidCrystal.h> // LCD display with parallel interface
#include <OneButton.h> //from https://github.com/mathertel/OneButton/blob/master/examples/TwoButtons/TwoButtons.ino
// helpers
#define LOCAL_DEBUG
#ifdef LOCAL_DEBUG
#define Sprint(a) (Serial.print(a)) // macro as substitute for print, enable if no print wanted
#define Sprintln(a) (Serial.println(a)) // macro as substitute for println
#else
#define Sprint(a) // enable if no print wanted -or-
#define Sprintln(a) // enable if no print wanted
#endif
// MySensors sensor
#define COUNTER_CHILD 0
// send constants and variables
int messageCounter = 0 ;
const int messageCounterMax = 100 ; // maximum message counter value
const unsigned counterUpdateDelay = 500 ; // send every x ms and sleep in between
// receive constants and variables
boolean failStore[messageCounterMax] ; // moving average stores & pointers
int failStorePointer = 0 ;
boolean missedStore[messageCounterMax] ;
int missedStorePointer = 0 ;
int newMessage = 0 ;
int lastMessage = -1 ;
int missedMessageCounter = 0 ; // total number of messages in range (messageCounterMax)
int failMessageCounter = 0 ; // total number of messages in range (messageCounterMax)
uint8_t parent = 0 ; // parent node-id
// Loop delays
const unsigned long displayInterval = 1000UL ; // display update in ms
unsigned long lastDisplayUpdate = 0 ; // last update for loop timers
// standard messages
MyMessage counterMsg(COUNTER_CHILD, V_PERCENTAGE); // Send value
// ***** LCD
#define LCD_COLS 16
#define LCD_ROWS 2
//LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE); // Set the LCD I2C address
//LiquidCrystal_I2C lcd(0x27, 16, 2); // Set the LCD I2C address
LiquidCrystal lcd(8, 7, 6, 5, 4, 3); // LCD with paralell interface
#define CURRENT_PIN A5
#define BUTTON1_PIN A1
#define BUTTON2_PIN A2
OneButton button1(BUTTON1_PIN, true); //PullUp, Activelow
OneButton button2(BUTTON2_PIN, true); //PullUp, Activelow
// Options
#define EEPROM_FLAG 0
#define EEPROM_PA_LEVEL 1
#define EEPROM_SEND_REPEATS 2
#define LEVEL_ITEMS 4
const char *paLevelNames[LEVEL_ITEMS] = { "MIN", "LOW", "HIGH", "MAX" };
uint8_t rf24palevel = MY_RF24_PA_LEVEL;
#define MIN_REPEAT_DELAY 50
#define MAX_REPEAT_DELAY 200
uint8_t sendRepeats = 3;
// Current measurement
#define CORRECTION 9.285
int currentMa;
// Menu
#define MENU_TIMEOUT 10000
enum mode { STATE_RUN, STATE_RUN2, STATE_PALEVEL, STATE_RESEND};
mode opState = STATE_RUN;
unsigned long lastClickedMillis;
boolean dspRefresh = true;
void before() {
pinMode(CURRENT_PIN, INPUT);
analogReference(INTERNAL);
// Wire.begin(); // I2C
// ** LCD display **
lcd.begin(LCD_COLS, LCD_ROWS);
//lcd.setBacklight(HIGH);
lcd.home();
lcd.setCursor(0, 0);
lcd.print("AWIQuality nRF24");
lcd.setCursor(0, 1);
lcd.print("Connect...");
initStore();
delay(1000);
button1.attachClick(onButton1Pressed);
button1.attachLongPressStart(onButton1LongPressed);
button2.attachClick(onButton2Pressed);
if (loadState(EEPROM_FLAG) == 0xFF) {
rf24palevel = loadState(EEPROM_PA_LEVEL);
sendRepeats = loadState(EEPROM_SEND_REPEATS);
} else {
saveState(EEPROM_FLAG, 0xFF);
saveState(EEPROM_PA_LEVEL, rf24palevel);
saveState(EEPROM_SEND_REPEATS, sendRepeats);
}
}
void presentation() {
present(COUNTER_CHILD, S_DIMMER, NODE_TXT) ; // counter uses percentage from dimmer value
}
void loop() {
button1.tick();
button2.tick();
if (opState != STATE_RUN && opState != STATE_RUN2 && millis() - lastClickedMillis > MENU_TIMEOUT) {
Sprintln("Timeout");
setRFLevel(rf24palevel);
saveState(EEPROM_PA_LEVEL, rf24palevel);
saveState(EEPROM_SEND_REPEATS, sendRepeats);
opState = STATE_RUN;
}
if (dspRefresh) LCD_local_display();
if ( opState == STATE_RUN ) {
Sprint("count:") ; Sprintln(messageCounter++) ;
missedStore[failStorePointer] = false ; // set slot to false (ack message needs to set) ;
boolean success = failStore[failStorePointer] = resend(counterMsg.setDestination(DESTINATION_NODE).set(failStorePointer), sendRepeats); // send to destination with ack
currentMa = analogRead(CURRENT_PIN) / CORRECTION;
if (!success) {
failMessageCounter++ ;
Sprint("Fail on message: ") ; Sprint(failStorePointer) ;
Sprint(" # ") ; Sprintln(failMessageCounter);
}
failStorePointer++ ;
if (failStorePointer >= messageCounterMax) {
failStorePointer = 0 ; // wrap counter
}
parent = getParentNodeId(); // get the parent node (0 = gateway)
wait(counterUpdateDelay) ; // wait for things to settle and ack's to arrive
dspRefresh = true;
}
}
void receive(const MyMessage &message) { // Expect few types of messages from controller
newMessage = message.getInt(); // get received value
switch (message.type) {
case V_PERCENTAGE:
missedStore[newMessage] = true ; // set corresponding flag to received.
if (newMessage > lastMessage) { // number of messages missed from lastMessage (kind of, faulty at wrap)
Sprint("Missed messages: ") ; Sprintln( newMessage - lastMessage - 1) ;
missedMessageCounter += newMessage - lastMessage - 1 ;
}
lastMessage = newMessage ;
break ;
default: break ;
}
}
// calculate number of false values in array
// takes a lot of time, but who cares...
int getCount(boolean countArray[], int size) {
int falseCount = 0 ;
for (int i = 0 ; i < size ; i++) {
falseCount += countArray[i] ? 0 : 1 ;
}
return falseCount ;
}
void initStore() {
for (int i = 0 ; i < messageCounterMax ; i++) { // init stores for moving averages
failStore[i] = true ;
missedStore[i] = true ;
}
missedMessageCounter = failMessageCounter = 0;
}
void setRFLevel(uint8_t rfLevel) {
Sprint("Set RF Level to "); Sprintln(rf24palevel);
uint8_t rfsetup = (((MY_RF24_DATARATE) & 0b10 ) << 4) | (((MY_RF24_DATARATE) & 0b01 ) << 3) | (((rfLevel << 1))) + 1; // +1 for Si24R1;
RF24_setRFSetup(rfsetup);
}
boolean resend(MyMessage &msg, int repeats) {
int repeat = 0;
int repeatdelay = 0;
boolean sendOK = false;
while ((sendOK == false) and (repeat < repeats)) {
if (send(msg, true)) { //send
sendOK = true;
} else {
sendOK = false;
repeatdelay += random(MIN_REPEAT_DELAY, MAX_REPEAT_DELAY);
}
repeat++;
delay(repeatdelay);
}
return sendOK;
}
void onButton1Pressed() {
dspRefresh = true;
lcd.clear(); lcd.home();
switch (opState) {
case STATE_RUN:
opState = STATE_PALEVEL;
break;
case STATE_RUN2:
opState = STATE_RUN;
break;
case STATE_PALEVEL:
opState = STATE_RESEND;
break;
case STATE_RESEND:
setRFLevel(rf24palevel);
saveState(EEPROM_PA_LEVEL, rf24palevel);
saveState(EEPROM_SEND_REPEATS, sendRepeats);
opState = STATE_RUN;
break;
}
lastClickedMillis = millis();
}
void onButton2Pressed() {
dspRefresh = true;
lcd.clear(); lcd.home();
switch (opState) {
case STATE_RUN:
opState = STATE_RUN2;
break;
case STATE_RUN2:
opState = STATE_RUN;
break;
case STATE_PALEVEL:
rf24palevel++; if (rf24palevel > 3) rf24palevel = 0;
break;
case STATE_RESEND:
sendRepeats++; if (sendRepeats > 3) sendRepeats = 1;
break;
}
lastClickedMillis = millis();
}
void onButton1LongPressed() {
initStore();
}
void LCD_local_display(void) {
dspRefresh = false;
char buf[LCD_COLS + 1]; // buffer for max 16 char display
switch (opState) {
case STATE_RUN:
lcd.setCursor(0, 0);
snprintf(buf, sizeof buf, "P%-3dFail%4d%3d%%", parent, failMessageCounter, getCount(failStore, messageCounterMax));
lcd.print(buf);
lcd.setCursor(0, 1);
snprintf(buf, sizeof buf, "D%-3dMiss%4d%3d%%", DESTINATION_NODE , missedMessageCounter, getCount(missedStore, messageCounterMax));
lcd.print(buf);
break;
case STATE_RUN2:
lcd.setCursor(0, 0);
snprintf(buf, sizeof buf, "PA Level = %s", paLevelNames[rf24palevel]);
lcd.print(buf);
lcd.setCursor(0, 1);
snprintf(buf, sizeof buf, "Current = %dmA", currentMa);
lcd.print(buf);
break;
case STATE_PALEVEL:
lcd.setCursor(0, 0);
snprintf(buf, sizeof buf, "PA Level = %s", paLevelNames[rf24palevel]);
lcd.print(buf);
break;
case STATE_RESEND:
lcd.setCursor(0, 0);
snprintf(buf, sizeof buf, "Send repeats = %d", sendRepeats);
lcd.print(buf);
break;
}
}
@rejoe2 For battery power saving you need sleep().
@mfalkvidd said in How to get time a sensor has slept:
There are a few tricks though. See these threads and see if any of the suggested solutions would work for you.
https://forum.mysensors.org/post/71715
That is exact the same issue .Thanks for pointing to this. I didn't found this.
I would like to use sleep function with wakeup from interrupt or timeout. The function only returns the wakeup reason. Is there a possibility to get the time slept when the wakup came from interrupt? The reason is that I would like to process the inteerupt an then recall the sleep with only th remsing time from the inital sleep time.
Thanks, but that is too much discussion for me. Can't someone simply answer with some links where to buy genuine modules for sure or where someone recently bought some which works?
@gohan said in nrf24L01+ 1715AH versus 1452AB problem:
Usually it is most likely a bad Chinese clone. You can't do much about it, just get the genuine ones
But how can I be sure to get the genuine ones?
I have two sets of nearly the same modules. The only visible difference is this number above. The modules with chip NRF M, 24L01, 1452AB work without problem. The modules with chip NRF M, 24L01, 1715AH did not. I tested 5 new modules from each series with the same node hardware and software.
Here the protocol of the not working 1715AH:
0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1
3 MCO:BGN:BFR
BEFORE...
5 TSM:INIT
6 TSF:WUR:MS=0
13 TSM:INIT:TSP OK
15 TSM:INIT:STATID=50
17 TSF:SID:OK,ID=50
19 TSM:FPAR
55 TSF:MSG:SEND,50-50-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2062 !TSM:FPAR:NO REPLY
2064 TSM:FPAR
2100 TSF:MSG:SEND,50-50-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4108 !TSM:FPAR:NO REPLY
4110 TSM:FPAR
4146 TSF:MSG:SEND,50-50-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6154 !TSM:FPAR:NO REPLY
6156 TSM:FPAR
6192 TSF:MSG:SEND,50-50-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8200 !TSM:FPAR:FAIL
8201 TSM:FAIL:CNT=1
8203 TSM:FAIL:PDT
Hope someone can help. I saw a lot of topics concerning those modules on this forum but as a non-expert it is difficult to find the right answer.
So it must be possible for one node to connect to two networks. Is this possible?
@mfalkvidd I would only mention that in my scenario this is not possible. I already have a gateway and controller. As far as I know a second gateway is not allowed.
@Boots33 Yes, that's important, I forgot this. In my case the receiving node is line powered.
@sigolhi I have a similar problem and started a thread about this a while ago. See here https://forum.mysensors.org/topic/6413/node-to-node-communication. It is still unclear how to do a node-to-node communication without a gateway. Even a repeater node will not help.
Still need this 
️. I heard of some low level communication. Might this be a solution? I am not en expert. Would be kind if someone can give an instruction.
@DavidZH Can not confirm this. Messages from sending node reaches repeater but not handled because the repeater finds no gateway.
Still unclear for me? Is it possible or not to have a node to node communication via a repeater without gateway online?
If not I would suggest to put an issue on github. If yes, it would be nice to have a clear instruction how to do this.
@mfalkvidd Thanks for this hint! @hek I like it!
I do not much understand the serial protocoll, but as far as I can see the leaf sends a ping to the repeater, but not the message I defined.
TSF:MSG:READ,44-44-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
See my other logs in the previous post.
@hek I already did this, but with 3000ms. Changed to 1ms but without success.
@mfalkvidd said in Node to node communication fails if gateway is not reachable:
All messages go through the gateway, so if the gateway is turned off the nodes will start searching for a new way to the root, which will fail since there is no root.
In the post refered from @Boots33 stands something diffrent:
@napo7: So, when I send a message with anything but 0 as destination, it goes thru the gateway, and the gateway rewrites a new message with the same destination ?
@hek: No, it might never reach the gateway. For instance if a repeater on the way routes knows the destination, it will route it.
Only repeaters and gateway holds a routing table which is build dynamically from the traffic the "see". So they are the only ones that can send messages "downward" in the sensor network.
What is right and more important what can I do to solve my problem? The receiving message is seen in the log of the repeater but is not processed.
Re: Node to node communnication in v2.0 between repeater nodes
In relation to this older post I have a sceneraio where node to node communication stops working. I have two nodes, a sensor and a repeater/actuator combination and a gateway. As long as the gateway is present to all nodes a direct communication between the sensor and the repeater/actuator works. On the sensor the log shows
MSG:SEND,44-44-43-43,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=1,st=OK:1
and on the repeater/actuator
TSF:MSG:READ,44-44-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
But if the gateway is not reachable (tested by simply switiching it off) the message delivery is unreliable. Mostly on sensor side the log shows NACK instead of OK
!TSF:MSG:SEND,44-44-43-43,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=2,st=NACK:
On the receiver side (the repeater/actuator node) a lot of logs are seen for finding the gateway, I think this correct. But the receive function is not called.
...
TSF:MSG:SEND,43-43-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
!TSM:FPAR:NO REPLY
TSM:FPAR
TSF:MSG:SEND,43-43-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
!TSM:FPAR:FAIL
TSM:FAIL:CNT=7
TSM:FAIL:PDT
...
TSF:MSG:READ,44-44-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
...
I detected another problem. From debug log it looks like the loop() function starts before initialization is finished. This can cause problems when trying to send data in loop() very early.
Here a log example:
0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.0-beta
4 MCO:BGN:BFR
5 before() begin
5 before() end
5 TSM:INIT
9 TSF:WUR:MS=1000
16 TSM:INIT:TSP OK
17 TSM:INIT:STATID=42
20 TSF:SID:OK,ID=42
21 TSM:FPAR
58 TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
651 TSF:MSG:READ,0-0-42,s=255,c=3,t=8,pt=1,l=1,sg=0:0
656 TSF:MSG:FPAR OK,ID=0,D=1
1010 MCO:BGN:STP
1011 Setup() begin
1512 Setup() end
1512 MCO:BGN:INIT OK,TSP=0
1516 loop() begin
2017 loop() end
2017 loop() begin
2065 TSM:FPAR:OK
2066 TSM:ID
2067 TSM:ID:OK
2069 TSM:UPL
2072 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2078 TSF:MSG:READ,0-0-42,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2083 TSF:MSG:PONG RECV,HP=1
2086 TSM:UPL:OK
2087 TSM:READY:ID=42,PAR=0,DIS=1
2093 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
2100 TSF:MSG:READ,0-0-42,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2107 TSF:MSG:SEND,42-42-0-0,s=255,c=0,t=17,pt=0,l=10,sg=0,ft=0,st=OK:2.1.0-beta
2116 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
2126 TSF:MSG:READ,0-0-42,s=255,c=3,t=6,pt=0,l=1,sg=0:M
2131 Presentation() begin
2135 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=11,pt=0,l=22,sg=0,ft=0,st=OK:Sink Pump Control Node
2145 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.2
2153 TSF:MSG:SEND,42-42-0-0,s=1,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
2161 TSF:MSG:SEND,42-42-0-0,s=2,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
2168 TSF:MSG:SEND,42-42-0-0,s=3,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
2174 Presentation() end
2176 MCO:REG:REQ
2181 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
2187 TSF:MSG:READ,0-0-42,s=255,c=3,t=27,pt=1,l=1,sg=0:1
2192 MCO:PIM:NODE REG=1
2518 loop() end
2518 loop() begin
...
Sorry, my fault. The receiveTime function is called. The problem was that I had an error in the Serial.println() statement so it doesn't appear in the log.
My Sketch uses mySensors 2.0. In loop() I issue about every minute a requestTime();
Pimatic got this request and responds the time. The node receives the message, but didn't call the receiveTime function.
I do not fully understand the protocol but in my opinion a wrong value fro the subtype is the reason.
her my logs:
Pimatic:
debug [pimatic-mysensors]: -> Sending 42;255;3;0;1;1482091727
Node:
60236 TSF:MSG:READ,0-0-42,s=255,c=3,t=1,pt=0,l=10,sg=0:1482091727
@tekka OK unplugging the GW leads to a different behaviour.
First the node didn't detect the failure as long it is not trying to send.
When it tries to send it fails
131268 !TSF:MSG:SEND,42-42-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=NACK:1
and after some more failure this
238494 !TSM:READY:UPL FAIL,SNP
238497 TSM:FPAR
238534 TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=6,st=OK:
238995 !TSF:SND:TNR
240002 !TSF:SND:TNR
240542 !TSM:FPAR:NO REPLY
240544 TSM:FPAR
240581 TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
246683 !TSM:FPAR:FAIL
246685 TSM:FAIL:CNT=1
246687 TSM:FAIL:PDT
and after a while mostly only
609748 !TSF:SND:TNR
When gateway comes back a proper reinitialization takes place:
620572 TSM:FAIL:RE-INIT
620574 TSM:INIT
620581 TSM:INIT:TSP OK
620583 TSM:INIT:STATID=42
620587 TSF:SID:OK,ID=42
620589 TSM:FPAR
620625 TSF:MSG:SEND,42-42-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
Current: 0.00
0:0:0
Current: 0.00
0:0:0
621443 TSF:MSG:READ,0-0-42,s=255,c=3,t=8,pt=1,l=1,sg=0:0
621448 TSF:MSG:FPAR OK,ID=0,D=1
Current: 0.00
0:0:0
Current: 0.00
0:0:0
622633 TSM:FPAR:OK
622635 TSM:ID
622637 TSM:ID:OK
622638 TSM:UPL
622642 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
622652 TSF:MSG:READ,0-0-42,s=255,c=3,t=25,pt=1,l=1,sg=0:1
622657 TSF:MSG:PONG RECV,HP=1
622660 TSM:UPL:OK
622662 TSM:READY:ID=42,PAR=0,DIS=1
From now the sensor can send again without errors. 
So far my tests.
Except the case where the radio of the sensor went off and causes a lot of logging all test cases where satisfactorily.
I think this is really an edge case and not so serious.
From this point of view I would welcome that this beta development version will be published.
@tekka May be it is the kind of my testing. For getting quick results I simply plug and un-plug the radio module (NRF24L01+) from the socket in my sensor node. I know, this is not a real use case but it was easy and I didn't thought there is adifference in behaviour. How do you you switch off and on the network connection in your test?
Here my report after a quick test.
To say it short: Generally I am happy with it, it works very well. Only one small problem.
In detail:
When connection is initially off, the sketch entered after the defined wait the loop.
before()
5 TSM:INIT
7 TSF:WUR:MS=1000
13 !TSM:INIT:TSP FAIL
15 TSM:FAIL:CNT=1
17 TSM:FAIL:PDT
1008 MCO:BGN:STP
Setup()
1510 MCO:BGN:INIT OK,TSP=0
If the sketch tries to send within the loop a message is logged.
145312 !MCO:SND:NODE NOT REG
If connection comes back the sketch connects to the gateway on the fly within the defined wait time.
244251 TSM:FPAR:OK
244252 TSM:ID
244254 TSM:ID:OK
244255 TSM:UPL
244259 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
244265 TSF:MSG:READ,0-0-42,s=255,c=3,t=25,pt=1,l=1,sg=0:1
244271 TSF:MSG:PONG RECV,HP=1
244274 TSM:UPL:OK
244276 TSM:READY:ID=42,PAR=0,DIS=1
244281 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
244288 TSF:MSG:READ,0-0-42,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
244295 TSF:MSG:SEND,42-42-0-0,s=255,c=0,t=17,pt=0,l=10,sg=0,ft=0,st=OK:2.1.0-beta
244304 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
244321 TSF:MSG:READ,0-0-42,s=255,c=3,t=6,pt=0,l=1,sg=0:M
Presentation()
244329 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=11,pt=0,l=22,sg=0,ft=0,st=OK:My Node
244339 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.2
244347 TSF:MSG:SEND,42-42-0-0,s=1,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
244356 TSF:MSG:SEND,42-42-0-0,s=2,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
244364 TSF:MSG:SEND,42-42-0-0,s=3,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
244370 MCO:REG:REQ
244373 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
244380 TSF:MSG:READ,0-0-42,s=255,c=3,t=27,pt=1,l=1,sg=0:1
244385 MCO:PIM:NODE REG=1
Only problem is that you get high logging traffic in the case when you are in loop and network connection gets lost again as long as the connection is lost.
605458 TSF:MSG:READ,1-1-1,s=1,c=1,t=1,pt=0,l=0,sg=0:
605463 !TSF:MSG:LEN,0!=7
605465 TSF:MSG:READ,1-1-1,s=1,c=1,t=1,pt=0,l=0,sg=0:
605470 !TSF:MSG:LEN,0!=7
605472 TSF:MSG:READ,1-1-1,s=1,c=1,t=1,pt=0,l=0,sg=0:
605477 !TSF:MSG:LEN,0!=7
...
I am now ready with my node and I need the non-blocking feature urgently. Is there an estimation when this feature will be come or can anyone provide a workaround?
@Nca78
Take a battery lifetimecalculator, e.g. like this
and you will see that battery life time is sufficient. In my opinion more than 1 year is enough.
Here are some measured values (not very precise):
The unmodified HC-SR50: Supply 5.0V, Standby 0.05mA, Tripped: 0.19mA
Regulator and diode removed: Supply 3.0V, Standby 0.03mA, Tripped 0.15mA
Regulator and diode removed: Supply 2.4V, Standby 0.02mA, Tripped 0.11mA
Below 2.4 V the Sensor doesn't work reliable.
The voltage drop of the diode depends on the current and is minimum 0.5V.
So if you would like to operate with 3 AA-Batteries it is recommended to remove/shortcut the diode.
@Never Thanks for this additional link.
The solution described there is very common, I saw it on some places. The advantage is that no modification of the board is necessary but the disadvantage is that the regulator is still in place and might draw some current back from the 3.3V supply. I prefer to remove unused parts.
I had no problems without the 100nf capacitor. It was only a preventive measure.
@NeverDie My Multimeter is not very good, but I tried to measure the total current. I got 3 values: 0.03mA when sleeping, 0.16mA when PIR triggered and about 18mA when RF is sending. Last is very short an cannot measured with my digital multimeter directly. I measured this value on startup the node when the registration process is longer and I guess it is a similar value when sending.
@dbemosk
Look for a datasheet for the PIR e.g.here.
In the diagram you can find the regulator IC1 on the topright as well as the diode D1 below of it.
@dbemowsk The picture shows the modified PIR. The right circle shows the place where the diode was. It is also removed and the contacts are bridged by soldering. The regulator was on position marked with the left circle. it is removed and the two upper contacts are bridged. The adde blue capacitor is contected from this point ( now 3.3V) input to the lower pad which is Ground. It is a 100nF ceramic capacitor.
Here you find a sketch including battery report which I found best. Works also with your PIR I think. For a advanced sketch you can ckeck this.
I use an arduino pro mini 3.3V with 2 AA batteries at 8 MHZ CPU speed.
Most important is to remove the voltage regulator on the PIR and supply it directly with 3V. My battery lasts over month with this combination.
There are different solutions for this. Most powersaving is to remove the regulator.
The solution n the picture above has the advantage that the electrolytic capacitor downright is still in use. The additional blue capacitor 100nF is optional, should serve as noise filter.
Coming from this thread, where I learned that an implementation of this feature is in progress.
In my opinion it is an essential architectural feature. Reasons for this you can see above.
Here I summarize what I think is necessary:
General requirements
Needed functionality
@mfalkvidd Thanks for the link to this thread. I didn't found this before. It is exactly my problem, so we can close this thread and continue discussing in thisone.
@tekka Thank you for this outlook.
For me this feature is essential and I am wondering if it is not implemented from the beginning. So I hope that it will be published soon.
Anyway I like MySensors and the great developer community. Many thanks to all.
I would like to build a actuator/sensor node with mySensors 2.0 which have an autonoumous feature. This means when the connection to the gateway fails during operation as well as on booting the node should go on working in a stand-alone mode until connection comes back. Currently I am trying to achive that the node boots without radio connection but it hangs somewehre in an endless loop trying to connect. What I would like to have is a quick connection trial at boot time and if this fails going quickly to he loop() function.
Depends on. An ESP-12 would be minimalistic. An ESP-201 can be used in breadboards. A node-MCU is a complete development board including the programming interface. But there are a lot of others.
@DrKuebel ESP-01 has not enough general purpose data pins. Besides Vcc and GND you need 5 GPIOs. ESP-01 only has 4.
Some optimization to check:
Thanks for Rev 03. Another optimization would be to turn the DHT22 180 degrees. Then the open front would face outside. Better for air circulation if put into a case with only a small open slot for the DHT.
Something like that:
long ringSendtAt;
boolean isRinging;
void setup() {
ringSendtAt = millis() - 10000;
...
}
void loop() {
...
if ( isRinging && millis()- ringSendtAt > 10000)
sendRingingMessage();
ringSendtAt = millis();
}
...
If the module also should be operated while charging and the DHT11 sits directly on the board close to the battery charger the sensor would show significantly higher temperatures caused by the TP4056 battery charger which becomes really hot during charging.
On an experiment on a breadboard with comparable distance I measured a temperature of the TP4056 of about 70 degree Celsius in the first phase of charging and the sensor reading rises from about 20 to 22 degrees.
... and to give the DHT sensor a chance on reading errors to retry and not to wait until next cycle which might be very long:
for (unsigned int i = 0; i < DHT_MAX_TRIES; i ++) {
float temperature = dht.getTemperature();
if (isnan(temperature)) {
Serial.println("Failed reading temperature from DHT");
gw.wait(dht.getMinimumSamplingPeriod());
} else if (temperature != lastTemp) {
lastTemp = temperature;
if (!metric) {
temperature = dht.toFahrenheit(temperature);
}
gw.send(msgTemp.set(temperature, 1));
Serial.print("T: ");
Serial.println(temperature);
break;
}
}
Repeat the same for humidity of cause.
If cycle interval might become a parameter and for smaller values of this it is better to do it this way
if((millis() - oldTime) > max(cycleInterval, dht.getMinimumSamplingPeriod() )
@HenryWhite said:
Did you made measurements to compare the range of the nRF when mounted onto the board and mounted sticking out?
No. With shield PCB I meant the ground fill. In your pictures I can not see if you leave this region out for filling. At least it is prophylactic.
What I tested is only this antenna modification. For me it really helps. May be this can be taken into account for the layout.
I think, on Rev 0.2 the download link for the board is wrong, it is the same as for Rev 0.1.
I think it is also imported that the antenna will not be covered by the shield pcb (see http://forum.mysensors.org/topic/1109/sensor-shield-for-arduino-pro-mini-3-3v-with-boost-up-regulator)
I am new in this forum so may be what I will tell here is posted already somewhere else.
Firstly I would measure the battery voltage at the end after sending some values to see the voltage after some stress. Often it is the case for a nearly empty battery that it shows a relaxed high voltage after a long sleep and the break down on some stress. I think it is better to measure the lower level.
Secondly for a motion sensor I would implement a wakeup on a pin change interrupt. As a stand-alone sensor this would be optimal for battery life time. In combination the other components you can use a large cycle time for getting temperature humidity and so on and for the motion sensor you get an intermediate interrupt on demand. If those event are too often for your desire, you can check it against time or count of last event and go back to sleep without sending.