NodeManager: plugin for a rapid development of battery-powered sensors

[user2684]

@BeniK said in NodeManager: plugin for a rapid development of battery-powered sensors:

@user2684 You were right! Definately a memory problem. Disabled the non-needed modules and everything is working as it should!

Great! I feel like there are a lot of optimizations that can be done to prevent this and other weird behaviors (tracked already with https://github.com/mysensors/NodeManager/issues/28).

I'd need a real programmer's review sooner or later because I'm sure the way I am e.g. comparing and manipulating strings are far from being efficient...

[user2684]

@BeniK said in NodeManager: plugin for a rapid development of battery-powered sensors:

@user2684 By the way I am alsy trying to implement the forecasting algorithm for BME280 sensor (from here)

Great idea! I wonder if the issue you are facing is due to different libraries being used (I'm using Adafruit's library, not the one from MySensors examples folder, not sure if they are different). I'll give it a try as well (https://github.com/mysensors/NodeManager/issues/56), but please let me know if you'll find the way to have it working and I'll make it part of the main code base.

Thanks!

[mar.conte]

@user2684
all ok now is s_motion but is ever tripped high!!!why?

[user2684]

@mar.conte said in NodeManager: plugin for a rapid development of battery-powered sensors:

all ok now is s_motion but is ever tripped high!!!why?

Default behavior is triggering on RISING but this can be changed with setMode() and setInitial(). Also ensure you are using pin 3 on a pro mini to have a valid interrupt. What is the behavior you are experiencing?
Thanks

[mar.conte]

@user2684
for istance Sensorswitch what is code?

[mar.conte]

@user2684
it's ok this code?

NodeManager nodeManager;
SensorSwitch swiTch(1,3);
// before
void before() {
  // setup the serial port baud rate
  Serial.begin(MY_BAUD_RATE);  
  /*
   * Register below your sensors
  */
swiTch.setMode(0);
swiTch.setInitial(0);
swiTch.setTriggerTime(4000);
  nodeManager.setSleep(SLEEP,60,MINUTES); 
  nodeManager.registerSensor(SENSOR_MOTION,3);```

[user2684]

@mar.conte sorry I'm not sure I have understood what you want to achieve. Do you have a motion sensor which is HIGH by default and when triggers goes LOW? Is this what you need?
Thanks

[mar.conte]

@user2684

Hello, I have a simple pir hcr501 that normally does not send output to pin 3 (so low) but when there is movement becomes HIGH, then my CPU goes to sleep for 60 minutes; the hardware is well configured because this setup I used it with the official mysensors sketches for pir motion; I do not understand why the domoticz controller is always the pir HIGH and does not go into sleep the MCU, thanks

[user2684]

@mar.conte said in NodeManager: plugin for a rapid development of battery-powered sensors:

Hello, I have a simple pir hcr501 that normally does not send output to pin 3 (so low) but when there is movement becomes HIGH

Ok, so you don't need any customization in NodeManager since this is meeting the default behavior (LOW by default and triggering on HIGH), sorry for the wrong advice. Let's have a look at the sensor's logs then to see why the node is waking up continuously.

Thanks!

[mar.conte]

@user2684
@gohan

node

0 MCO:BGN:INIT NODE,CP=RRNNA--,VER=2.1.1
40 MCO:BGN:BFR
REG I=1 P=3 P=6 T=0
NodeManager v1.4
INT1 M=255
INT2 M=255
59 TSM:INIT
135 TSF:WUR:MS=0
155 TSM:INIT:TSP OK
176 TSM:INIT:STATID=100
202 TSF:SID:OK,ID=100
225 TSM:FPAR
370 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2244 TSF:MSG:READ,0-0-100,s=255,c=3,t=8,pt=1,l=1,sg=0:0
2301 TSF:MSG:FPAR OK,ID=0,D=1
2447 TSM:FPAR:OK
2463 TSM:ID
2478 TSM:ID:OK
2492 TSM:UPL
2639 !TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=NACK:1
3678 TSF:MSG:READ,0-0-100,s=255,c=3,t=25,pt=1,l=1,sg=0:1
3737 TSF:MSG:PONG RECV,HP=1
3768 TSM:UPL:OK
3784 TSM:READY:ID=100,PAR=0,DIS=1
3883 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
4003 TSF:MSG:READ,0-0-100,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
4202 !TSF:MSG:SEND,100-100-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=NACK:2.1.1
4415 !TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=1,st=NACK:0
6733 !TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=11,pt=0,l=19,sg=0,ft=2,st=NACK:NodeManagerTemplate
6928 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=3,st=OK:1.0
RADIO OK
PRES I=200, T=23
7137 !TSF:MSG:SEND,100-100-0-0,s=200,c=0,t=23,pt=0,l=0,sg=0,ft=0,st=NACK:
PRES I=201, T=30
7321 TSF:MSG:SEND,100-100-0-0,s=201,c=0,t=30,pt=0,l=0,sg=0,ft=1,st=OK:
BATT V=3.25 P=93
SEND D=0 I=201 C=0 T=38 S= I=0 F=3.25
7469 !MCO:SND:NODE NOT REG
7587 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=OK:93
PRES I=1 T=6
7794 !TSF:MSG:SEND,100-100-0-0,s=1,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=NACK:
READY

7868 MCO:REG:REQ
7933 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=1,st=OK:2
9019 TSF:MSG:READ,0-0-100,s=255,c=3,t=27,pt=1,l=1,sg=0:1
9078 MCO:PIM:NODE REG=1
9105 MCO:BGN:STP
MY I=100 M=1
9123 MCO:BGN:INIT OK,TSP=1
THER I=1 V=354.00 T=40.05
 M=1
SEND D=0 I=1 C=0 T=0 S= N=0 F=40.05
9224 TSF:MSG:SEND,100-100-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:40.05
SLEEP 3600s

9316 MCO:SLP:MS=3600000,SMS=1,I1=255,M1=255,I2=255,M2=255
9527 !TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=NACK:287
9607 TSF:MSG:READ,0-0-100,s=255,c=3,t=27,pt=1,l=1,sg=0:1
9666 !TSF:MSG:LEN,0!=8
10108 MCO:SLP:TPD```

Gateway

0;255;3;0;9;TSF:MSG:READ,100-100-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=100
0;255;3;0;9;TSF:PNG:SEND,TO=0
0;255;3;0;9;TSF:CKU:OK
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-100-100,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,100-100-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
0;255;3;0;9;TSF:MSG:PINGED,ID=100,HP=1
0;255;3;0;9;TSF:MSG:SEND,0-0-100-100,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1
0;255;3;0;9;TSF:MSG:READ,100-100-0,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
0;255;3;0;9;TSF:MSG:SEND,0-0-100-100,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
0;255;3;0;9;TSF:MSG:READ,100-100-0,s=255,c=0,t=17,pt=0,l=5,sg=0:2.1.1
0;255;3;0;9;Sending message on topic: domoticz/in/MyMQTT/100/255/0/0/17
0;255;3;0;9;TSF:MSG:READ,100-100-0,s=255,c=3,t=11,pt=0,l=19,sg=0:NodeManagerTemplate
0;255;3;0;9;Sending message on topic: domoticz/in/MyMQTT/100/255/3/0/11
0;255;3;0;9;TSF:MSG:READ,100-100-0,s=200,c=0,t=23,pt=0,l=0,sg=0:
0;255;3;0;9;Sending message on topic: domoticz/in/MyMQTT/100/200/0/0/23
0;255;3;0;9;TSF:MSG:READ,100-100-0,s=255,c=3,t=0,pt=1,l=1,sg=0:85
0;255;3;0;9;Sending message on topic: domoticz/in/MyMQTT/100/255/3/0/0
0;255;3;0;9;TSF:MSG:READ,100-100-0,s=255,c=3,t=26,pt=1,l=1,sg=0:2
0;255;3;0;9;TSF:MSG:SEND,0-0-100-100,s=255,c=3,t=27,pt=1,l=1,sg=0,ft=0,st=OK:1
0;255;3;0;9;TSF:MSG:READ,100-100-0,s=1,c=1,t=0,pt=7,l=5,sg=0:36.72
0;255;3;0;9;Sending message on topic: domoticz/in/MyMQTT/100/1/1/0/0
0;255;3;0;9;TSF:MSG:READ,100-100-0,s=255,c=3,t=22,pt=5,l=4,sg=0:286
0;255;3;0;9;Sending message on topic: domoticz/in/MyMQTT/100/255/3/0/22
0;255;3;0;9;Message arrived on topic: domoticz/out/MyMQTT/0/0/3/0/18
0;255;3;0;9;Sending message on topic: domoticz/in/MyMQTT/0/255/3/0/22

[user2684]

@mar.conte there is something strange with this node. First of all the node is still presenting the temperature and not the motion sensor. Then I see a lot of failures during transmit but also while receiving (!TSF:MSG:LEN,0!=8). Are you sure you don't have something like two nodes with the same id?

[mar.conte]

@user2684
hi, I noticed that the zero node has a child called S_Arduino_Repeater with an id equal to 255 child node, called 100 S_Arduino_Node, what do you recommend?
smotion now appears I had mistakenly entered analog 0 on a wire that went to +Power

[user2684]

@mar.conte said in NodeManager: plugin for a rapid development of battery-powered sensors:

I noticed that the zero node has a child called S_Arduino_Repeater with an id equal to 255 child node, called 100 S_Arduino_Node

The node 0 is the gateway which presents itself as S_ARDUINO_REPEATER, the child id 255 is the broadcast address, the node id 100 is instead you node. This is all correct (with or without NodeManager). Glad to hear the motion sensor is now showing up. Is it still trigger continuously?
Thanks

[mar.conte]

@user2684
Yes trig again!!!

[user2684]

@mar.conte said in NodeManager: plugin for a rapid development of battery-powered sensors:

Yes trig again!!!

Ok, if triggers continuously, please share the logs of the node now that has been fixed so we can have a look.
Thanks!

[mar.conte]

@user2684
Hi,

NODE OUTPUT

0 MCO:BGN:INIT NODE,CP=RRNNA--,VER=2.1.1
40 MCO:BGN:BFR
REG I=1 P=3 P=1 T=16
NodeManager v1.4
INT1 M=3
INT2 M=255
59 TSM:INIT
135 TSF:WUR:MS=0
153 TSM:INIT:TSP OK
176 TSM:INIT:STATID=100
200 TSF:SID:OK,ID=100
223 TSM:FPAR
368 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
641 TSF:MSG:READ,0-0-100,s=255,c=3,t=8,pt=1,l=1,sg=0:0
698 TSF:MSG:FPAR OK,ID=0,D=1
2445 TSM:FPAR:OK
2461 TSM:ID
2476 TSM:ID:OK
2490 TSM:UPL
2512 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2633 TSF:MSG:READ,0-0-100,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2693 TSF:MSG:PONG RECV,HP=1
2721 TSM:UPL:OK
2738 TSM:READY:ID=100,PAR=0,DIS=1
2785 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
2904 TSF:MSG:READ,0-0-100,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
3018 TSF:MSG:SEND,100-100-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.1.1
3229 !TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=NACK:0
5316 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=11,pt=0,l=19,sg=0,ft=1,st=OK:NodeManagerTemplate
5541 !TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=NACK:1.0
RADIO OK
PRES I=200, T=23
5715 TSF:MSG:SEND,100-100-0-0,s=200,c=0,t=23,pt=0,l=0,sg=0,ft=1,st=OK:
PRES I=201, T=30
5922 !TSF:MSG:SEND,100-100-0-0,s=201,c=0,t=30,pt=0,l=0,sg=0,ft=0,st=NACK:
BATT V=3.21 P=86
SEND D=0 I=201 C=0 T=38 S= I=0 F=3.21
6072 !MCO:SND:NODE NOT REG
6164 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=1,st=OK:86
PRES I=1 T=1
6371 !TSF:MSG:SEND,100-100-0-0,s=1,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=NACK:
READY

6445 MCO:REG:REQ
6531 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=1,st=OK:2
6619 TSF:MSG:READ,0-0-100,s=255,c=3,t=27,pt=1,l=1,sg=0:1
6678 MCO:PIM:NODE REG=1
6705 MCO:BGN:STP
MY I=100 M=1
6723 MCO:BGN:INIT OK,TSP=1
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=0 T=16 S= N=1 F=0.00
6817 TSF:MSG:SEND,100-100-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1
SLEEP 3600s

6897 MCO:SLP:MS=3600000,SMS=1,I1=1,M1=3,I2=255,M2=255
7104 !TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=NACK:264
7684 MCO:SLP:TPD
7700 MCO:SLP:WUP=1
WAKE P=3, M=3
AWAKE
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= N=1 F=0.00
7786 TSF:MSG:SEND,100-100-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=1,st=OK:1
SLEEP 3600s

7876 MCO:SLP:MS=3600000,SMS=1,I1=1,M1=3,I2=255,M2=255
8087 !TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=NACK:1243
8667 MCO:SLP:TPD
8683 MCO:SLP:WUP=1
WAKE P=3, M=3
AWAKE
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= N=1 F=0 
8757 TSF:MSG:SEND,100-100-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=1,st=OK:1
SLEEP 3600s

8859 MCO:SLP:MS=3600000,SMS=1,I1=1,M1=3,I2=255,M2=255
8982 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:2226
9562 MCO:SLP:TPD
9578 MCO:SLP:WUP=1
WAKE P=3, M=3
AWAKE
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= N=1 F=0.00
9621 TSF:MSG:SEND,100-100-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1
SLEEP 3600s

9754 MCO:SLP:MS=3600000,SMS=1,I1=1,M1=3,I2=255,M2=255
9961 !TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=NACK:3121
10541 MCO:SLP:TPD

Tanks

[user2684]

@mar.conte ok, this looks better, the node is presenting correctly and I see the sensor triggering continuously. You still have a lot of radio failures while sending but this is another story and it is not related to the issue but keep in mind you are losing a few messages.
Now, if I look at the digital read of the pin waking up the board (V=):

SWITCH I=1 P=3 V=1

This is HIGH so the board correctly wakes up. Since the signal apparently stays high, the board goes in and out of sleep so looks like an expected behavior. The are a couple of functions available to prevent this (setTriggerTime() and setDebounce()) but before giving direction I'd ask you to measure the voltage at pin 3 with a multimeter because it looks like the motion sensor goes HIGH and stay HIGH for a long time. If we know this timeframe, we can adjust the settings accordingly. Btw you should have the same behavior with the example sketch at https://www.mysensors.org/build/motion.
Thanks

[mar.conte]

@user2684
ok, I will check first the voltage of the pir and even the power of the MCU, it seems to me that the rfm69 module does not communicate with each other (node-gateway), it seems strange because with the sketch of links that you suggested it all works well ! thanks anyway I'll do my tests and let you know soon ...

[mar.conte]

I wanted to know what are the connections to monitor the batteries of my sensor, do I connect the battery V+ to the analog pin A0?

[user2684]

@mar.conte said in NodeManager: plugin for a rapid development of battery-powered sensors:

I wanted to know what are the connections to monitor the batteries of my sensor, do I connect the battery V+ to the analog pin A0?

If you are connecting the arduino directly to the battery (e.g. no step-up-down), then you don't need any connection since NodeManager is able to sense and measure the input vcc (and according to my measures it is very accurate). In case instead you need to use the method here https://www.mysensors.org/build/battery, you need the following:

nodeManager.setBatteryInternalVcc(false);
nodeManager.setBatteryPin(A0);

You can even customize the default 0.003363075 voltage per bit with setBatteryVoltsPerBit()

[mar.conte]

@user2684

THEN MY NODE WILL BE CONNECTED TO A BATTERY 3.6 VOLT AA 2600 MAH, SO I DO NOT RIGHT CONNECTIONS? BUT I HAVE TO CHANGE OTHER PARAMETERS TO BEING 3.6?
TANKS

[user2684]

@mar.conte said in NodeManager: plugin for a rapid development of battery-powered sensors:

THEN MY NODE WILL BE CONNECTED TO A BATTERY 3.6 VOLT AA 2600 MAH, SO I DO NOT RIGHT CONNECTIONS? BUT I HAVE TO CHANGE OTHER PARAMETERS TO BEING 3.6?
TANKS

If directly connected to the battery you don't need any other connection. To set minimum and maximum voltage to have an accurate battery percentage level calculated you need to use e.g.:

nodeManager.setBatteryMin(2.7);
nodeManager.setBatteryMax(3.6);

So the percentage will be calculated between the two values.

[mar.conte]

@user2684

Much easy INFINITE THANKS AND CONGRATULATIONS

[mar.conte]

@user2684
Solved
I solved it by putting settriggertime (5000) setdebounce (50); also solved the supply problems because if power is ftdi with the sensor was always high, with batteries the pir is stable and works well
thanks for the support

This is my reprap printed house for my project

[user2684]

@mar.conte great to hear it is working now! For anybody else interested in these parameters, setDebounce() will set a debounce interval, e.g. the value of the input is checked after the interval from the wakeup so to avoid false positives, while seTriggerTime() ignore any input after the pir has triggered to avoid the sensor to trigger continuously. Btw, very nice and clean packaging!

[mar.conte]

I have a problem, my node is in sleep for 60 minutes and hourly reads the battery voltage but when you wake the pir is high and in addition to the high volts sends me even then the controller sends me a pir pir movement false; how can I avoid it?

[JonnyDev13]

Can I suggest updated sourceforge to say that the code has been moved to github, and leaving little else there? That way it's easier to update everything in the same place. I was browsing on sourceforge for a while and wondering "Why isn't this on github instead?" It wasn't even until I came back and started skimming this thread that I realized it was moved to github.

[user2684]

@mar.conte said in NodeManager: plugin for a rapid development of battery-powered sensors:

I have a problem, my node is in sleep for 60 minutes and hourly reads the battery voltage but when you wake the pir is high and in addition to the high volts sends me even then the controller sends me a pir pir movement false; how can I avoid it?

So you are saying when the node wakes up not from the pir interrupt at the end of the sleeping cycle to report battery level, is it also reporting a V_TRIPPED with payload 0? Thanks

[user2684]

@JonnyDev13 said in NodeManager: plugin for a rapid development of battery-powered sensors:

Can I suggest updated sourceforge to say that the code has been moved to github

Good advice thanks! I've changed the website link on Sourceforge as well as added a note in the description and redirected the "Support" link.

[mar.conte]

@user2684
Yes of course but payload =1 pir movimento detect

[gohan]

What's the problem if it reports no motion?

[JonnyDev13]

@user2684 Looks great!

[mar.conte]

@gohan
The problem is that motion report whenever sleep goes to wake to send me the battery status every 60 minutes ,then every 60 minutes sends me battery status and motion pir

[gohan]

Ok, but is it causing any problem?

[mar.conte]

@gohan
Definitely, if I put a pir sensor to monitor a security access I will never know if I had an intrusion if I have a false alarm

[gohan]

if it reports "no motion" it is not a false alarm. The important thing is it must report when there is "motion"

[user2684]

@gohan said in NodeManager: plugin for a rapid development of battery-powered sensors:

if it reports "no motion" it is not a false alarm. The important thing is it must report when there is "motion"

Agree with what @gohan says. But I'll look into this anyway @mar-conte, reporting no motion when waking up should not happen even if it is a minor issue (https://github.com/mysensors/NodeManager/issues/71). What should not happen at all is reporting motion (payload 1) but as far as I've understood this is the case.
Thanks

[mar.conte]

@user2684
So with version 1.5 do I solve my problem too?

[mar.conte]

I noticed that the battery report if set to one hour does not happen every hour ...

[user2684]

@mar.conte said in NodeManager: plugin for a rapid development of battery-powered sensors:

So with version 1.5 do I solve my problem too?

I'll look into it by then. Feel free to follow the github issue to see how it will evolve. Thanks!

[user2684]

@mar.conte said in NodeManager: plugin for a rapid development of battery-powered sensors:

I noticed that the battery report if set to one hour does not happen every hour ...

More details please Does not happen at all, it is not regular, happens every other hour, etc. what is the case?
Thanks!

[mar.conte]

@user2684
It happens even if i put 6 hours or every 3 hours so in the specified hours it is not regular the report sometimes jumps some report

[user2684]

@mar.conte said in NodeManager: plugin for a rapid development of battery-powered sensors:

It happens even if i put 6 hours or every 3 hours so in the specified hours it is not regular the report sometimes jumps some report

Ok, I'd probably need both MySensors and NodeManagers's logs to troubleshoot this, just to ensure there is no failure in sending out the messages as I've seen in the other logs you have previously shared.

Thanks!

[mar.conte]

@user2684
Ok Tanks

[mar.conte]

Then solved the problem of the accuracy of the battery report: basically I did not realize that the sleep wait time started from the last pir movement then if i put an hour of sleep and during this active time the pir time resumes; The communication problems I solved them by letting antenna from rfm69 so every hour the battery report does not even send pir moviment
....Very strange my rfm69 modules communicate better without an antenna even at a distance of 10 meters with a wall

[gohan]

There is a risk of damaging the radio module if you don't use an antenna. Also a wrong tuned antenna will make transmitting more difficult.

[mar.conte]

@gohan
Ok Tanks, but the 86 mm wire for 868 what is Ideal diameter and thread type for simple antenna no dipole e non ground ant?

[gohan]

Found in another forum

433 1/4 wave = 164.7mm
433 1/2 wave = 329.4mm
433 full wave = 692.7mm

868 1/4 wave = 82.2mm
868 1/2 wave = 164.3mm
868 full wave = 345.5mm

915 1/4 wave = 77.9mm
915 1/2 wave = 155.9mm
915 full wave = 327.8mm

Try shortening a little bit. What kind of wire are you using?

[mar.conte]

@gohan
Wery good Tanks gohan

[mar.conte]

@gohan
Normal wire electric 1 mm diameter

[gohan]

Single core or threaded?

[mar.conte]

@gohan
Threaded

[gohan]

You need to use single core, that's why it is not working well

[mar.conte]

@gohan
Should it be isolated or even without a sheath?

[gohan]

I think you can leave insulation on; there are some guides on how to make antennas for rfm69,just Google it. In addition there are also spring single wire antennas for different frequencies you can buy.

[user2684]

@mar.conte said in NodeManager: plugin for a rapid development of battery-powered sensors:

I did not realize that the sleep wait time started from the last pir movement then if i put an hour of sleep and during this active time the pir time resumes

Yes, when the pir wakes the node up, the sleep is aborted and when going back to sleep, it starts from scratch without resuming it. If this is not creating an issue, I'll keep the current behavior. Regarding the antenna, I'm using the small antennas from the store for my RFM69 and have a decent range without big issues.

[mar.conte]

@user2684
Tanks of course bye

[bilbolodz]

I'm trying to build sensor to drive 3 relays and connect it to Domoticz. Simple sketch:

// before
void before() {
  // setup the serial port baud rate
  Serial.begin(MY_BAUD_RATE);  
  /*
   * Register below your sensors
  */
int przek1 = nodeManager.registerSensor(SENSOR_RELAY,3);
int przek2 = nodeManager.registerSensor(SENSOR_RELAY,4);
  /*
   * Register above your sensors
  */
  nodeManager.before();
}

sensors are visible into Domoticz as switches but It's not possible to turn it on/off from Domoticz. It looks that Nodemanager expect REQ message to change state of relay but Domoticz sends SET message to change state:

RECV S=0 I=3 C=1 T=2 D=1
RECV S=0 I=3 C=1 T=2 D=0

When I've used MYSController and send C_REQ message all is working fine.

I think that in case of "output" sensors logic of getting/setting should be reversed.

[user2684]

Hello, I think I was able to implement most of the requests discussed here during the last few weeks in a pre-release v1.5 version. Please consider it still as a dev release which gone through very limited testing but since I had to make quite a few changes to core code, would be great to start collecting some feedback now.

Is is available here: https://github.com/mysensors/NodeManager/tree/9a485cdcaf8e9856219338553335e2dce7253eb3

It is complicated to reference each of you who requested something so please whoever is interested the full list of new additions/fixes is available here https://github.com/mysensors/NodeManager/milestone/5?closed=1. I did my best to add verbose comments so you should find all the details there. Please add any comment and report any problem directly to the existing issues on github so I can better understand the context. The documentation has been updated as well.
Thanks

[mar.conte]

@user2684

[user2684]

I've just pushed out 1.5-dev3 on https://github.com/mysensors/NodeManager/tree/702a05c7e2f4425c188d5abf62b4a119fea29bc8 fixing a critical bug for the BME280 sensor and providing a way to automatically detect which i2c address the sensor is on for both BME280 and BMP085/BMP180 if anybody is interested.

I'm planning some additional tests so to release a stable v1.5 in a week or two (unfortunately starting from June the real life will become very demanding with me). So please share any feedback by then in case you will have the chance to test the latest dev release. Thanks

[gohan]

Just in time, I am going to get my BME280 sensor soon

[gohan]

May I ask you a favor? Could you add also the MCP9808 I2C sensor?

[user2684]

@gohan done but I don't have such a sensor to test the code so if you could give it a try I'd really appreciate it. Available in v1.5-dev4 you can get from here: https://github.com/mysensors/NodeManager/tree/38fd51c99e47b6ec90f4885ff1cb0cfe33857ab4.
Instructions on https://github.com/mysensors/NodeManager/issues/87
Thanks!

[vikasjee]

Can you please consider support for MCP23017 IO-Expander And TTP226/TTP229 Touch control sensor modules in I2C mode?

[vikasjee]

I can help test them both for sure...

Will it be a good idea to have external file based extension to Node Manager?

I will like to extend the configuration child and probably add node authentication through another security-child. Self Healing Network capabilities are next on my list.

[gohan]

@user2684 Sorry for noob question but how do I get data from the sensors?
I have registered sensors like this to test them out

	nodeManager.setSleep(SLEEP, 10, MINUTES);
	nodeManager.registerSensor(SENSOR_MOTION, 3);
	nodeManager.registerSensor(SENSOR_BME280);
	nodeManager.registerSensor(SENSOR_MCP9808);

[user2684]

@vikasjee tracking both with https://github.com/mysensors/NodeManager/issues/90 and https://github.com/mysensors/NodeManager/issues/92. Mean while I will order the samples and wait for their delivery, if you have any link with demo code to share, please feel free to do so on the two github issues.

Regarding the external file based extension, this is definitively a good idea. I did spend some time at the beginning trying to identify the best way to package this but my weak programming skills prevented me to identify an optimal solution I'm sure. I did not go for multiple files mainly because I thought during upgrade this would have required overwriting multiple files in multiple projects so I gave up. As a workaround, I also tried to put all NodeManager's files in a dedicated folder or create an arduino library but it didn't work (but don't remember why).

So the only way now to expand the existing code in a clean way is to write in your main sketch an inline class deriving from the Sensor class or the other NodeManager's classes and use registerSensor() providing an instance of this class. But I am of course open to any other better way to achieve the same

[user2684]

@gohan since you have set a sleep interval of 10 minutes, what you should see in the logs (and in your gateway) is NodeManager starting up, presenting all the child nodes (one of more for each sensor), running SENSOR_BME280's and SENSOR_MCP9808's onLoop() and a bunch of messages set out with the measures and finally going to sleep for 10 minutes and waking up and sending out a V_TRIPPED message if SENSOR_MOTION triggers.
Generally speaking you can get the measures in the serial output, in the controller or by sending the node a REQ message to each of the child ids. Do you see something different?
Thanks

[gohan]

Ok, I mean from code like if I want to use them to show on local LCD

[user2684]

@gohan never thought about it but it is a good idea to add some "output" capabilities. Tracking this with https://github.com/mysensors/NodeManager/issues/95 but would require some time since it has a few dependencies. Thanks!

[gohan]

I'll give you a feedback sooner or later... I lost so many hours trying to figure out what was wrong with my test sensor but at the end it was a fried nrf24 module that was working since some time ago

[user2684]

I've added a rain gauge out-out-the-box sensor for the latest dev release called 1.5-dev5 (https://github.com/mysensors/NodeManager/tree/126812a9d01311640416222be8225fdcca1e7266). This is intended to be the last enhancement for the upcoming v1.5 version but of course I'll wait for some additional days to collect (and fix) any issue all the new sensors might have.

The implementation of the rain gauge sensor has to be different than the one from the build section for a good number of reasons and limitations. All the details here: https://github.com/mysensors/NodeManager/issues/90.

[mar.conte]

Sorry but the name of the sketch can be different both in the node and in the gateway?

[gohan]

Sure, that's for your use to know what software is running on each sensor

[mar.conte]

@gohan
Should the gateway have the right nodemamager sketch?
Tanks

[gohan]

Why do you need nodemanager on gateway?

[mar.conte]

@gohan
User2694 say:"Setup MySensors

Since NodeManager has to communicate with the MySensors gateway on your behalf, it has to know how to do it. Place on top of the config.h file all the MySensors typical directives you are used to set on top of your sketch so both your sketch AND NodeManager will be able to share the same configuration. For example:"
link text

[gohan]

He is referring on the node side, on the gateway you can just run the default sketch

[mar.conte]

@gohan
Ok Tanks

[user2684]

@mar.conte said in NodeManager: plugin for a rapid development of battery-powered sensors:

Should the gateway have the right nodemamager sketch?

Just to confirm what already discussed: a node/sensor with NodeManager running does not require a gateway with NodeManager on it. Generally speaking, there are two situations in which you may want use NodeManager on a gateway as well (available starting from v1.5):

• It as to run on a Sonoff device which requires to be configured as a gateway
• The gateway has sensors attached to it so you may want to use NodeManager's capabilities to configure your sensors in an easy way

There is also a third situation: you are just lazy and have NodeManager already open in the arduino IDE so you just configure the gateway's settings in config.h and upload the sketch

[mar.conte]

@user2684

[user2684]

Last chance guys to report any issue for those who had tested the dev version of v1.5
The final version will be out in a day or two otherwise.

Thanks!

[gohan]

I am waiting for the LCD mod

[user2684]

@gohan LCD unfortunately has to wait for the another release (https://github.com/mysensors/NodeManager/issues/95), I would like to find a way to provide the info on the LCD without the need for the user to configure it for every sensor but this would require investigating on the best generic approach and will take some time

[gohan]

If you could provide a method to retrieve sensor data from main loop(), it is quite easy for everyone to print it to LCD

[user2684]

@gohan I wonder if something can be done even right now based on what you're saying. In the main sketch, after invoking nodeManager.loop(), you can actually retrieve the instance of each sensor and do something. The last "value", depending on the type of the sensor, is stored in a variable (e.g. _value_int) BUT it is private. I'll add a getValue() function so you can get out this value. Not ideal but I think it can be a workaround I can easily add before releasing 1.5 (https://github.com/mysensors/NodeManager/issues/104)

[gohan]

The problem is how do I know the name of the instance of the sensors

[user2684]

@gohan I mean if you declare a global int to store the child id, then you can save it when calling registersensor() (which returns the id of the sensor) in before() so eventually in loop() you can call getSensor() and then retrieve the value or do whatever else. Something like:

NodeManager nodeManager;
int sensor_id;

void before() {
  Serial.begin(MY_BAUD_RATE);  
  sensor_id = nodeManager.registerSensor(SENSOR_THERMISTOR,A1);
  nodeManager.before();
}

void loop() {
  nodeManager.loop();
  float value = ((SensorThermistor*)nodeManager.getSensor(sensor_id))->getValueFloat();

}

Just the getValueFloat() is missing. Not ideal but a starting point. Don't you think? Thanks!

[gohan]

That would work, at least for me

[user2684]

@gohan cool, just added it to the dev code. I'm packing now the final v1.5 and about to post it here in a few minutes. Thanks!

[gohan]

At least now we can add some more code besides the default created by nodemanager

[user2684]

Very true also because I'd avoid having the users customizing their NodeManager.cpp (even if it is always possible) to prevent issues during the upgrade. For your information the alternative to create an inline class inheriting from Sensor and then invoking registerSensor() with an instance of this class is always valid even if clearly much more complex.

[user2684]

Version 1.5 of NodeManager is finally available here!
https://github.com/mysensors/NodeManager

I've done my best to implement most of the requests received so far since unfortunately I'm expecting starting from June very little spare time to spend here so I tried to hurry up a bit The result is a pretty long change log and a total of 26 between ad-hoc and generic out-of-the-box sensors supported up to this release:

• Added support for ACS712 current sensor
• Added support for HC-SR04 distance sensor
• Added support for BMP085/BMP180 temperature and pressure sensor
• Added support for Sonoff smart switch
• Added support for Rain Gauge sensor
• Added support for MCP9808 temperature sensor
• Added forecast output to all Bosch sensors
• Added I2C address auto-discovery for all Bosch sensors
• Added support for running as a gateway
• Added option to retrieve the latest value of a sensor from outside NodeManager
• Remote reboot now does not need a reboot pin configured
• A heartbeat is now sent also when waking up from a wait cycle
• When waking up for an interrupt, only the code of the sensor expecting that interrupt is executed
• Added capability to retrieve the time from the controller
• Optimized battery life for DS18B20 sensors
• SLEEP_MANAGER has been deprecated (now always enabled) and setMode() replaces setSleepMode()
• New mode ALWAYS_ON to let the node staying awake and executing each sensors' loop
• ESP8266WiFi.h has to be included in the main sketch if MY_GATEWAY_ESP8266 is defined
• Added receiveTime() wrapper in the main sketch
• Fixed the logic for output sensors
• Added common gateway settings in config.h

I've added upgrade instructions as well in the documentation. Generally speaking to upgrade it is safe to just replace the existing NodeManager.h and NodeManager.cpp files but with this release I had to do some minor changes to the main sketch as well, as documented in the release notes.

Thanks everybody for all the advice and for reporting any issue always in a constructive way

[user2684]

Hi, only for those having problems with a too high utilization of the dynamic memory preventing NodeManager to run smoothly (e.g. generating random data / outputting garbage characters / rebooting, etc), a quick fix is to decrease from 255 to a small number like 5 or 10 the size of the Sensor* _sensors array. This saves more than 20% on a pro mini which is huge. Of course you also need to change every cycle in NodeManager.cpp which is using that 255.

This of course will be also fixed in the next release. Very silly mistake I know to initialize such a big array but I couldn't image 255 pointers were consuming so much

[mar.conte]

Hi, i wanted to know in which section of the sketch I turn on and turn off a led when the node controls the battery because at night the led me starts the pir; Now I've put the digitalwrite after nodemanger.loop

[user2684]

@mar.conte NodeManager does not control any led so I think you are free to place your code where you think is most appropriate for your needs. Thanks

[gohan]

@mar.conte put a capacitor on the PIR vcc/gnd and increase the size until it is stable.

[mar.conte]

@gohan
Good idea Tanks

[user2684]

Hi, I've added a "How to contribute" section in the documentation of the dev release in case anybody is interested to contribute to this project: https://github.com/mysensors/NodeManager/tree/development#contributing.

I'm not a git expert so I hope those instructions to have some sense