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

mar.conte

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

gohan

I think relay is the pir sensor you are looking for.

user2684

@mar.conte your configuration looks correct, SENSOR_MOTION is what you want to use indeed. However, the logs are saying NodeManager is presenting the sensor as S_TEMP so the issue is on NodeManager's side also because looks like SensorThermistor has been instantiated but if I look at the code, there is no way this should happen.I'll try to setup something similar to see if I can reproduce the behavior. Very stupid question: are you sure you have uploaded successfully that sketch and it is not an old one? I really cannot explain it otherwise at a first look...
Thanks

user2684

@bilbolodz having a special registerSensor() for DS18B20 is for sure feasible but I'll leave it as the last option. Are you sure you need to store something in the eeprom? The way I imaged it was something like this, all within the sketch:

register the DS18B20 sensors with one line. registerSensor() returns the child id of the last sensor so I know how many have been detected.
cycle through the DS18B20 sensors found with getSensor(index)
for each sensor, call of getDeviceAddress(), if the address equals to a hard-coded address, renameSensor() to a fixed id.

In this way the same device address will always get the same child id and if a sensor will be unavailable, it will not mess up the other child IDs. Is this something which can be done or am I missing something? Far from saying it is elegant of course...
Thanks

bilbolodz

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

In this way the same device address will always get the same child id and if a sensor will be unavailable, it will not mess up the other child IDs. Is this something which can be done or am I missing something? Far from saying it is elegant of course...

Of course that it's solution but hardcoding addresses into sketch as you said "it's far from elegant"..... The good idea (in my opinion) is to put addresses into array stored in eeprom. The ideal solution would be to have possibility put addresses into eeprom by mysensors controller ;-)

user2684

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

PRES I=1 T=6
PRES I=2 T=6
PRES I=3 T=7

Hi, the sensors are all presented correctly, child id 1 is type temperature (6, the DS18B20), child id 2 is type temperature (6, the DHT22), child id 3 is type humidity (7, the DHT22).
What it looks like from the logs is that it hangs after sending out the temperature of child id 2, never get to child id 3 so never goes to sleep.

I wonder if having both DHT and DS18B20 together would consume too much memory causing the sketch to halt. When you compile it, what is the percentage of program storage space and dynamic memory used? For those sensors the objects are allocated dynamically so when getting closer to the memory limit strange behaviors can happen.
Try also disabling NodeManager's debug (#define DEBUG 0) and all the other modules you are not using (e.g. MODULE_ANALOG_INPUT, MODULE_DIGITAL_INPUT, etc.). All of this should help saving additional memory. Then check on your controller if you get the humidity as well and if the node goes to sleep.

Thanks!

BeniK

@user2684 Hi and thank you for the prompt response!

The % of memory used is 83% of program storage space and 63% of dynamic memory.

Sketch uses 25580 bytes (83%) of program storage space. Maximum is 30720 bytes.
Global variables use 1307 bytes (63%) of dynamic memory, leaving 741 bytes for local variables. Maximum is 2048 bytes.

Heading right now to try to compile without the non-needed modules and try again.

user2684

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

Of course that it's solution but hardcoding addresses into sketch as you said "it's far from elegant"..... The good idea (in my opinion) is to put addresses into array stored in eeprom. The ideal solution would be to have possibility put addresses into eeprom by mysensors controller

Ok got it, just wanted to be sure that what I had in mind, despite being awful, was kind of feasible. Now let me try to understand better what you have in mind: you store in eeprom the the addresses, then call registerSensor() and the for DS18B20, it will retrieve from there the addresses and do the mapping automatically instead of being you doing in the sketch what I listed before. Is it correct? If so, despite some obvious complexity, does not require a special registerSensor() (which would be great).

As a side note, having the controller storing something into the EEPROM is not something extremely difficult to implement, I can add an additional V_CUSTOM message so achieve this since I can imagine may be helpful for this and other use cases (https://github.com/mysensors/NodeManager/issues/53)

bilbolodz

@user2684 Yes, that could be nice solution.

user2684

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

@user2684 Yes, that could be nice solution.

Cool, I'll track it down (https://github.com/mysensors/NodeManager/issues/54) so you can see when I'll get into it.
Thanks!

BeniK

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

REG I=1 P=3 P=6 T=0
REG I=2 P=4 P=6 T=0
REG I=3 P=4 P=7 T=1
NodeManager v1.4
INT1 M=255
INT2 M=255
RADIO OK
PRES I=200, T=23
PRES I=201, T=30
BATT V=3.44 P=100
SEND D=0 I=201 C=0 T=38 S= I=0 F=3.44
PRES I=1 T=6
PRES I=2 T=6
PRES I=3 T=7
READY

MY I=199 M=1
DS18B20 I=1 T=44.19
SEND D=0 I=1 C=0 T=0 S= N=0 F=44.19
DHT I=2 T=24.40
SEND D=0 I=2 C=0 T=0 S= N=0 F=24.40
DHT I=3 H=35.50
SEND D=0 I=3 C=0 T=1 S= N=0 F=35.50
SLEEP 60s

Many many many THANKS for the help!

BeniK

@user2684 By the way I am alsy trying to implement the forecasting algorithm for BME280 sensor (from here) into the BME280 section of NodeManager.cpp and Nodemanager.h but until now no joy. Maybe I am trying to do something complicated for me as a beginner into this, but I always like to learn by trial and error. Any advice you could give me to be able to implement the forecasting algorithm?

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

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

18

11.7k

11.2k

113.0k