NodeManager: plugin for a rapid development of battery-powered sensors
-
If you could provide a method to retrieve sensor data from main loop(), it is quite easy for everyone to print it to LCD
@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 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!
-
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.
-
Version 1.5 of NodeManager is finally available here!
https://github.com/mysensors/NodeManagerI'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 :-)
-
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 :-)
-
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
@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
-
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
-
@mar.conte put a capacitor on the PIR vcc/gnd and increase the size until it is stable.
-
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 :)
-
Pretty big enhancement in the development branch of NodeManager if anybody is interested. I spent quite a good amount of time working on the core code to introduce mainly two features opening up the door to a good list of enhancements.
The first one is a sort of countdown utility. Can be based on the number of sleeping cycles or minutes. It detects automatically a sleeping node and instead of using millis sum up the sleep interval and reports when the time is over. This approach has been used to:
- Allow different sensors reporting at different timeframes (e.g. by configuring a specific sensor to report every e.g. 5 minutes or 10 sleeping cycles instead of at the end of each cycle)
- For output sensors optionally use the input value as an elapsed time (e.g. the output will be turned on and the input value will be used as a timer to turn it off automatically). For example by sending 3 to a relay, it will be turned on and after 3 minutes turned off automatically. Useful if you already know for how long the output should stay on.
- For output sensors optionally set a safeguard (e.g. after a relay is set to on, turn it off automatically after 1 hour). Useful if e.g. you are controlling a boiler and you are afraid something could prevent the command to turn it off to reach the board.
- Add timeframe option for reporting battery level (e.g. instead of reporting every 10 sleeping cycles, report every 1 hour regardless of how long is the sleeping cycles).
The other big change is a an complete remote API. With the current version you could send to NodeManager's service child id a limited list of commands to change the behavior of the board remotely, mainly to alter the duration of the sleep cycle. In the development release instead, almost every function of both NodeManager AND of every sensor can be invoked remotely. This is done by sending a V_CUSTOM message with a function_id and optional value to pass along to the service child id or each sensor's child id. More details here: https://github.com/mysensors/NodeManager/tree/development#communicate-with-nodemanager-and-its-sensors
This development branch is available here: https://github.com/mysensors/NodeManager/tree/development
-
But i'm trying to test a Pir of panasonic EKMB1201113 papirs series cost a bit but they have low power consumption
1 to 100 microampers in sleep mode, just connect a 100 kohm resistance in pulldown and it is very precise up to 12 meters -
Do you think it may be possible to add the function to use a digital pin to power a PIR sensor to turn it on only when setting it armed? (to save a little power)
@gohan interesting use case. I personally prefer to have the arm/disarm logic on the controller but I can understand there are also different situations. I've opened https://github.com/mysensors/NodeManager/issues/138 for this. Thanks for the suggestion!
-
Why does the power manager use two pins to power the sensor? Could we just use one pin for Vcc, and assume that the GND is permanently connected?
@rakeshpai said in NodeManager: plugin for a rapid development of battery-powered sensors:
Why does the power manager use two pins to power the sensor? Could we just use one pin for Vcc, and assume that the GND is permanently connected?
I usually use the power pins when either I need to save power or I do not have vcc/gnd pins available on the arduino board. But yes, you're right, there are other scenarios to consider. I've opened https://github.com/mysensors/NodeManager/issues/139 for this. Thanks
