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

[user2684]

Oh I see, when you have custom hardware sometimes you have different options set for the compiler, this is why with the default settings works here. Nevertheless it is an easy fix on my side, just wait for v1.3 to be out very soon and it should compile without issues.

Thanks!

[user2684]

Hi, I've updated NodeManager to its 1.3 version. This should also solve your issue @Ben-Coton. Short changelog:

• Added support for BME280 temperature/humudity/pressure sensor
• Added option to measure battery level via a pin in addition to internal Vcc
• Added example sketches to the documentation
• Fixed a few bugs

Code and updated documentation (now with with four comprehensive examples including the full sketches at the end) on https://github.com/mysensors/NodeManager

[vikasjee]

@user2684 , Thanks for the new version.

Are you planning to include Virtual Button and IOExpander(MCP23017) support too? Thst would really help especially adding consistent child-ids for the expander pins, just like multiple temp sensors on the SPI bus...

[user2684]

@vikasjee I'm very open to whatever can make the life of an average user easier, so far I've just pitched what were common requirements for me as a new user but I'm sure there is a lot more that I'm missing. Give me some more info or pointers regarding Virtual Button and IOExpander and how you are using it right now, I couldn't find much here on the forum and my knowledge is limited and I'll look into it for sure!
Thanks

[BeniK]

A long time reader and "lurker" here, but just registered today to thank @user2684 for this contribution to MYS Community! In my opinion NodeManager is really a great addition to MYS!

[Efflon]

I just started playing with this and must say FANTASTIC! This makes things almost too simple.

I found a few small things´(bugs?)

• You refer to the sourforge page for the latest releases (nit pick)
• Baud in the config.h is default set to 9800, shouldn't this be 9600? However, setting it to whatever doesn't help, only 4800 outputs anything, this could be something on my setup as well ...

Again, thanks!

[soif]

It sounds absolutely terrific ! :+1:

Thank you very much !

[user2684]

@Efflon thanks for reporting these two issues, I'll track them down with https://github.com/mysensors/NodeManager/issues/34 and https://github.com/mysensors/NodeManager/issues/33 and fix asap!
Thank you all for your comments!

[Efflon]

@user2684 Excellent!
A question, I'm doing a simple door sensor

  nodeManager.setBatteryMin(1.8);
  nodeManager.setBatteryMax(3.2);
  nodeManager.setBatteryReportCycles(1);
  int door = nodeManager.registerSensor(SENSOR_DOOR,3);
  ((SensorDoor*)nodeManager.get(door))->setDebounce(500);
  nodeManager.setSleep(SLEEP,1,HOURS);

Now, the node is constantly sending. It seems as if every wake-up triggers a sending, and a wakeup from the debounce sleep, then battery reporting etc.. Removing the debounce helps and lets the node sleep.

AWAKE
SEND D=0 I=200 C=1 T=48 S=AWAKE I=0 F=0.00
BATT V=3.16 P=97
SEND D=0 I=201 C=0 T=38 S= I=0 F=3.16
SWITCH I=1 P=3 V=0
SEND D=0 I=1 C=1 T=16 S= N=0 F=0.00
SLEEP 60s
SEND D=0 I=200 C=1 T=48 S=SLEEPING I=0 F=0.00

[here i "open" the door]

WAKE P=3, M=1
AWAKE
SEND D=0 I=200 C=1 T=48 S=AWAKE I=0 F=0.00
BATT V=3.16 P=97
SEND D=0 I=201 C=0 T=38 S= I=0 F=3.16
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= N=1 F=0.00
SLEEP 60s
SEND D=0 I=200 C=1 T=48 S=SLEEPING I=0 F=0.00

[just a second wait]

WAKE P=3, M=1
AWAKE
SEND D=0 I=200 C=1 T=48 S=AWAKE I=0 F=0.00
BATT V=3.16 P=97
SEND D=0 I=201 C=0 T=38 S= I=0 F=3.16
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= N=1 F=0.00
SLEEP 60s

[repeated until closing "door"]

Edit:

I changed the sleep to a wait and now the behavior is correct (this line).

// what do to during loop
void SensorSwitch::onLoop() {
  // wait to ensure the the input is not floating
  if (_debounce > 0) wait(_debounce);
  // read the value of the pin
  int value = digitalRead(_pin);

MY I=8 M=1
SEND D=0 I=200 C=0 T=48 S=STARTED I=0 F=0.00
SWITCH I=1 P=3 V=0
SEND D=0 I=1 C=0 T=16 S= N=0 F=0.00
SLEEP 60s
SEND D=0 I=200 C=1 T=48 S=SLEEPING I=0 F=0.00

[open]

WAKE P=3, M=1
AWAKE
SEND D=0 I=200 C=1 T=48 S=AWAKE I=0 F=0.00
BATT V=3.16 P=97
SEND D=0 I=201 C=0 T=38 S= I=0 F=3.16
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= N=1 F=0.00
SLEEP 60s
SEND D=0 I=200 C=1 T=48 S=SLEEPING I=0 F=0.00

[close]

WAKE P=3, M=1
AWAKE
SEND D=0 I=200 C=1 T=48 S=AWAKE I=0 F=0.00
BATT V=3.16 P=97
SEND D=0 I=201 C=0 T=38 S= I=0 F=3.16
SWITCH I=1 P=3 V=0
SEND D=0 I=1 C=1 T=16 S= N=0 F=0.00
SLEEP 60s
SEND D=0 I=200 C=1 T=48 S=SLEEPING I=0 F=0.00

[user2684]

Thanks for the hit @Efflon! I accidentally fixed that sleep() in the v1.4 dev branch this afternoon because of another issue. Is everything else now behaving correctly?

I have a concern regarding battery level reports when operating with interrupts: right now I do not distinguish between a cycle because a full sleep has completed from a cycle interrupted by an interrupt like in this case. This may cause a lot more battery reports, depending on how often the sensor triggers. To avoid this unexpected behavior, in the dev branch the default behavior is now the opposite: waking up from an interrupt does not count as a cycle. The drawback though is that if the sensor triggers continuously, it will never report the battery to the controller since unable to complete a full sleeping cycle. This is why I've added the following so allow the user to pick up the policy he likes the most:

// If true, wake up by an interrupt counts as a valid cycle for battery reports otherwise only uninterrupted sleep cycles would contribute (default: false)
void setBatteryReportWithInterrupt(bool value);

In case you want to give this a try, the dev branch is available at https://github.com/mysensors/NodeManager/tree/v1.4-dev. You just need to replace the existing NodeManager.cpp and NodeManager.h files, you can keep both your sketch and your config.h.
Thanks

[Efflon]

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

behavior, in the dev branch the default behavior is now the opposite: waking up from an interrupt does not count as a cycle. The drawback though is that if the sensor triggers continuously, it will never report the battery to the controller since unable to complete a full sleep

This is tricky. Myself uses the battery report as a heartbeat on top of checking the battery level, thus I only need the info once or twice a day. Not sending on wake-up is good since it will preserve battery. I guess a combination the right sleeping time and cycle count could end up quite ok. For a front door sensor, 4h sleep and 2 cycle count would report battery level after the night and then maybe one more time, max 3 times per day, which is more than enough. I'll test the dev branch after some sleep :smile:

Btw, great work!! and yes, using wait works just fine, no other issues so far.

[mar.conte]

Hello everyone, you can send commands to the node by domoticz even if the node is in sleep forever? Or the node must always have a sleep delay?

[Efflon]

@mar.conte if it's sleeping, it will not receive anything until wake-up. If you change the sleep mode to wait,

nodeManager.setSleepMode(WAIT);
[or]
nodeManager.setSleep(WAIT,1,HOURS);

the sensor will be awake all the time (and drain your battery).

[user2684]

@Efflon glad to see you found out the right balance for you needs. Based on what you are saying I probably want change the default value of setBatteryReportWithInterrupt() back to true, in this way the new version will present the same behavior as the old one but can be changed at any time by the user. Of course if anybody has a different view, please let me know.

[user2684]

@Efflon @mar-conte, if the sensor is powered by batteries, I'll leverage smart sleep which NodeManager is using by default. Smart sleep is btw the reason why I moved into MySensors: since all of my sensors are battery powered, I needed a way to send commands also in this situation.

There is no overhead for the sensor in terms of code (it just needs to wake up periodically to receive commands) and on the controller side the implementation is very simple: once the controller knows the node is a sleeping one, it will queue the commands and send them once the node is awake next (when using smart sleep, a heartbeat is reported once the node is awake and just before going to sleep again).

I'm using this since a while for my boiler controller without issue: the node controls a (latching) relay and goes through a 5 minutes sleeping cycle with the controller (I'm using my https://www.mysensors.org/controller/myhouse) queuing the on/off command. This will introduce a little delay (1-5 minutes in my case) but can be adapted with a shorter/longer sleeping cycle.

[mar.conte]

@user2684
a really interesting project, however I would use NodeManager to query each time the battery status of my pir sensor; I would like to know how I can send from domoticz commands to query my node !! thank you

[gohan]

what's the point of querying node for battery status? Just put in the code to report it when battery level changes.

[user2684]

@mar.conte if you want to query the battery level on-demand, you can by sending to NodeManager's service child id (by default 200) a REQ V_CUSTOM message with BATTERY as a payload.Of course the node must be awake to respond or the controller must support smart sleep. Or as @gohan says, just have the node reporting the battery level

[mar.conte]

@user2684
Tanks i try and report you
By

[rhaymo]

Hi,
first of all, thanks to user2684 for his great job.
I wonder if it would possible adding a feature in nodeManager, where after a wake up from interrupt, only the onLoop method of the sensor attached to that pin is executed. onLoop of sensors not attached to interrupt are executed only after a full sleep cycle. (of course, this requires that after a wakeup from interrupt, the node come to sleep only for (sleepTime - elapsedTimeBeforeWakeup) )

In my case, I have a sketch for a node with a temperature and door sensor. Temperature is sent each 60 minutes, while door status only on interrupt.