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


  • Contest Winner

    Hi, being a newbie in this wonderful MySensors world, I found myself excited about the flexibility of the overall platform but also somehow implementing the same common functionalities across my sensors over and over again. I decided then to spend some reasonable amount of time to expand the idea behind MyExtention (https://forum.mysensors.org/topic/6062/myextension) into something I have called NodeManager (I know, I'm bad with names!).

    NodeManager is intended to take care on your behalf of all those common tasks a MySensors node has to accomplish, speeding up the development cycle of your projects. It should help who is new to MySensors to get up to speed quicker and for those already into the matter to delegate to NodeManager common and boring tasks so to focus on more interesting scenarios.

    NodeManager main features are:

    • Manage all the aspects of a sleeping cycle by leveraging smart sleep
    • Allow configuring the sleep mode and the sleep duration remotely
    • Allow waking up a sleeping node remotely at the end of a sleeping cycle
    • Allow powering on each connected sensor only while the node is awake to save battery
    • Report battery level periodically and automatically
    • Calculate battery level without requiring an additional pin and the resistors
    • Report battery voltage through a built-in sensor
    • Can report battery level on demand
    • Allow rebooting the board remotely
    • Provide out-of-the-box sensors personalities and automatically execute their main task at each cycle

    Specifically on this last point, the idea behind providing built-in the functionalities of most common sensors is to simplify the development especially for somebody new to it.
    E.g. if I connect a thermistor to one of the pin, I just need a single line to have it working, as it was leveraging some sort of embedded firmware:

    nodeManager.registerSensor(SENSOR_THERMISTOR,A2);
    

    The following built-in sensors are available:

    • SENSOR_ANALOG_INPUT Generic analog sensor, return a pin's analog value or its percentage
    • SENSOR_LDR LDR sensor, return the light level of an attached light resistor in percentage
    • SENSOR_THERMISTOR Thermistor sensor, return the temperature based on the attached thermistor
    • SENSOR_DIGITAL_INPUT Generic digital sensor, return a pin's digital value
    • SENSOR_DIGITAL_OUTPUT Generic digital output sensor, allows setting the digital output of a pin to the requested value
    • SENSOR_RELAY Relay sensor, allows activating the relay
    • SENSOR_LATCHING_RELAY Latching Relay sensor, allows activating the relay with a pulse
    • SENSOR_DHT11 DHT11 sensor, return temperature/humidity based on the attached DHT sensor
    • SENSOR_DHT22 DHT22 sensor, return temperature/humidity based on the attached DHT sensor
    • SENSOR_SHT21 SHT21 sensor, return temperature/humidity based on the attached SHT21 sensor
    • SENSOR_SWITCH Generic switch, wake up the board when a pin changes status
    • SENSOR_DOOR Door sensor, wake up the board and report when an attached magnetic sensor has been opened/closed
    • SENSOR_MOTION Motion sensor, wake up the board and report when an attached PIR has triggered
    • SENSOR_DS18B20 DS18B20 sensor, return the temperature based on the attached sensor

    I put the package on Sourceforce so to avoid leaving here piece of code which may become obsolete in a short time.

    The project is here: https://sourceforge.net/projects/mynodemanager
    I've also tried to document everything the best as I could on https://sourceforge.net/p/mynodemanager/wiki

    Thanks



  • I'm amazed this hasn't got more attention. A superb contribution to the community and one which I'm sure has taken many hours... Thank you!


  • Contest Winner

    Thanks @Mark-Swift!
    By the way, if anybody is interested I've just fixed a few bugs and added some minor enhancements (for details: https://sourceforge.net/p/mynodemanager/tickets/milestone/v1.1/).

    The new version (v1.1) is available as always at https://sourceforge.net/projects/mynodemanager


  • Hardware Contributor

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

    I'm amazed this hasn't got more attention. A superb contribution to the community and one which I'm sure has taken many hours... Thank you!

    I agree with you, for a lot of beginners this is like the graal for sketch creation if I believe the many posts asking how to combine some sketches.


  • Contest Winner

    Hi, I've made an update of NodeManager in case can be of interest. Latest version v1.2 is available on https://sourceforge.net/projects/mynodemanager/.
    Short changelog:


  • Contest Winner

    ...and I've moved the repository (including tickets and documentation) under the MySensors community on https://github.com/mysensors/NodeManager (thanks again for your help @hek!).

    I'll keep the Sourceforge project open to avoid broken links but I will upload only new releases there in sync with github.



  • Cool stuff! was looking for a way to do some configuration of mysensors remotely!
    Gonna give it a spin this week!



  • I love the look of this setup. I am making my own slim nodes running at 8MHz with a basic 328P chip.

    I am starting with a basic Thermistor which is fine but when I try to compile the code I get the following error.

    exit status 1
    default argument given for parameter 3 of 'void PowerManager::setPowerPins(int, int, long int)' [-fpermissive]

    My code is as follows:

    // load user settings
    #include "config.h"
    // load MySensors library
    #include <MySensors.h>
    // load NodeManager library
    #include "NodeManager.h"
    
    // create a NodeManager instance
    NodeManager nodeManager;
    
    // before
    void before() {
      // setup the serial port baud rate
      Serial.begin(9600);  
      // instruct the board to sleep for 10 minutes for each cycle
    //  nodeManager.setSleep(SLEEP,10,MINUTES);
    
      // register the sensors
      nodeManager.registerSensor(SENSOR_THERMISTOR,A1);
    //  nodeManager.registerSensor(SENSOR_LDR,A2);
      /*
       * Register below your sensors
      */
      
    
      /*
       * Register above your sensors
      */
      nodeManager.before();
    }
    
    // presentation
    void presentation() {
      // Send the sketch version information to the gateway and Controller
    	sendSketchInfo("Battery Temp Sensor","1.0");
      // call NodeManager presentation routine
      nodeManager.presentation();
    
    }
    
    // setup
    void setup() {
      // call NodeManager setup routine
      nodeManager.setup();
    }
    
    // loop
    void loop() {
      // call NodeManager loop routine
      nodeManager.loop();
    
    }
    
    // receive
    void receive(const MyMessage &message) {
      // call NodeManager receive routine
      nodeManager.receive(message);
    }
    

    Any help with sorting this out will be great.
    Cheers,

    Ben


  • Contest Winner

    Thanks for your comment @Ben-Coton! The error message tells me that I'm doing something wrong in the code (http://stackoverflow.com/questions/2545720/error-default-argument-given-for-parameter-1) but I wonder why it compiles without error or warning on my system.

    Meanwhile I'll fix the problem (tracking it with https://github.com/mysensors/NodeManager/issues/30), in case you want to try a workaround, I share below my platform.txt file since I'm sure there must be some flag in mine which is somehow ignoring the error when I compile it:

    # Arduino AVR Core and platform.
    # ------------------------------
    #
    # For more info:
    # https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification
    
    name=Arduino AVR Boards
    version=1.6.17
    
    # AVR compile variables
    # ---------------------
    
    compiler.warning_flags=-w
    compiler.warning_flags.none=-w
    compiler.warning_flags.default=
    compiler.warning_flags.more=-Wall
    compiler.warning_flags.all=-Wall -Wextra
    
    # Default "compiler.path" is correct, change only if you want to override the initial value
    compiler.path={runtime.tools.avr-gcc.path}/bin/
    compiler.c.cmd=avr-gcc
    compiler.c.flags=-c -g -Os {compiler.warning_flags} -std=gnu11 -ffunction-sections -fdata-sections -MMD -flto -fno-fat-lto-objects
    compiler.c.elf.flags={compiler.warning_flags} -Os -g -flto -fuse-linker-plugin -Wl,--gc-sections
    compiler.c.elf.cmd=avr-gcc
    compiler.S.flags=-c -g -x assembler-with-cpp -flto -MMD
    compiler.cpp.cmd=avr-g++
    compiler.cpp.flags=-c -g -Os {compiler.warning_flags} -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -flto
    compiler.ar.cmd=avr-gcc-ar
    compiler.ar.flags=rcs
    compiler.objcopy.cmd=avr-objcopy
    compiler.objcopy.eep.flags=-O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0
    compiler.elf2hex.flags=-O ihex -R .eeprom
    compiler.elf2hex.cmd=avr-objcopy
    compiler.ldflags=
    compiler.size.cmd=avr-size
    
    # This can be overridden in boards.txt
    build.extra_flags=
    
    # These can be overridden in platform.local.txt
    compiler.c.extra_flags=
    compiler.c.elf.extra_flags=
    compiler.S.extra_flags=
    compiler.cpp.extra_flags=
    compiler.ar.extra_flags=
    compiler.objcopy.eep.extra_flags=
    compiler.elf2hex.extra_flags=
    
    # AVR compile patterns
    # --------------------
    
    ## Compile c files
    recipe.c.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.c.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.c.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"
    
    ## Compile c++ files
    recipe.cpp.o.pattern="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.cpp.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"
    
    ## Compile S files
    recipe.S.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.S.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.S.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"
    
    ## Create archives
    # archive_file_path is needed for backwards compatibility with IDE 1.6.5 or older, IDE 1.6.6 or newer overrides this value
    archive_file_path={build.path}/{archive_file}
    recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{archive_file_path}" "{object_file}"
    
    ## Combine gc-sections, archives, and objects
    recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mmcu={build.mcu} {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -lm
    
    ## Create output files (.eep and .hex)
    recipe.objcopy.eep.pattern="{compiler.path}{compiler.objcopy.cmd}" {compiler.objcopy.eep.flags} {compiler.objcopy.eep.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.eep"
    recipe.objcopy.hex.pattern="{compiler.path}{compiler.elf2hex.cmd}" {compiler.elf2hex.flags} {compiler.elf2hex.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.hex"
    
    ## Save hex
    recipe.output.tmp_file={build.project_name}.hex
    recipe.output.save_file={build.project_name}.{build.variant}.hex
    
    ## Compute size
    recipe.size.pattern="{compiler.path}{compiler.size.cmd}" -A "{build.path}/{build.project_name}.elf"
    recipe.size.regex=^(?:\.text|\.data|\.bootloader)\s+([0-9]+).*
    recipe.size.regex.data=^(?:\.data|\.bss|\.noinit)\s+([0-9]+).*
    recipe.size.regex.eeprom=^(?:\.eeprom)\s+([0-9]+).*
    
    ## Preprocessor
    preproc.includes.flags=-w -x c++ -M -MG -MP
    recipe.preproc.includes="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} {preproc.includes.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.cpp.extra_flags} {build.extra_flags} {includes} "{source_file}"
    
    preproc.macros.flags=-w -x c++ -E -CC
    recipe.preproc.macros="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} {preproc.macros.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.cpp.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{preprocessed_file_path}"
    
    # AVR Uploader/Programmers tools
    # ------------------------------
    
    tools.avrdude.path={runtime.tools.avrdude.path}
    tools.avrdude.cmd.path={path}/bin/avrdude
    tools.avrdude.config.path={path}/etc/avrdude.conf
    
    tools.avrdude.network_cmd={runtime.tools.arduinoOTA.path}/bin/arduinoOTA
    
    tools.avrdude.upload.params.verbose=-v
    tools.avrdude.upload.params.quiet=-q -q
    # tools.avrdude.upload.verify is needed for backwards compatibility with IDE 1.6.8 or older, IDE 1.6.9 or newer overrides this value
    tools.avrdude.upload.verify=
    tools.avrdude.upload.params.noverify=-V
    tools.avrdude.upload.pattern="{cmd.path}" "-C{config.path}" {upload.verbose} {upload.verify} -p{build.mcu} -c{upload.protocol} -P{serial.port} -b{upload.speed} -D "-Uflash:w:{build.path}/{build.project_name}.hex:i"
    
    tools.avrdude.program.params.verbose=-v
    tools.avrdude.program.params.quiet=-q -q
    # tools.avrdude.program.verify is needed for backwards compatibility with IDE 1.6.8 or older, IDE 1.6.9 or newer overrides this value
    tools.avrdude.program.verify=
    tools.avrdude.program.params.noverify=-V
    tools.avrdude.program.pattern="{cmd.path}" "-C{config.path}" {program.verbose} {program.verify} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{build.path}/{build.project_name}.hex:i"
    
    tools.avrdude.erase.params.verbose=-v
    tools.avrdude.erase.params.quiet=-q -q
    tools.avrdude.erase.pattern="{cmd.path}" "-C{config.path}" {erase.verbose} -p{build.mcu} -c{protocol} {program.extra_params} -e -Ulock:w:{bootloader.unlock_bits}:m -Uefuse:w:{bootloader.extended_fuses}:m -Uhfuse:w:{bootloader.high_fuses}:m -Ulfuse:w:{bootloader.low_fuses}:m
    
    tools.avrdude.bootloader.params.verbose=-v
    tools.avrdude.bootloader.params.quiet=-q -q
    tools.avrdude.bootloader.pattern="{cmd.path}" "-C{config.path}" {bootloader.verbose} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{runtime.platform.path}/bootloaders/{bootloader.file}:i" -Ulock:w:{bootloader.lock_bits}:m
    
    tools.avrdude_remote.upload.pattern=/usr/bin/run-avrdude /tmp/sketch.hex {upload.verbose} -p{build.mcu}
    
    tools.avrdude.upload.network_pattern="{network_cmd}" -address {serial.port} -port {upload.network.port} -sketch "{build.path}/{build.project_name}.hex" -upload {upload.network.endpoint_upload} -sync {upload.network.endpoint_sync} -reset {upload.network.endpoint_reset} -sync_exp {upload.network.sync_return}
    
    # USB Default Flags
    # Default blank usb manufacturer will be filled in at compile time
    # - from numeric vendor ID, set to Unknown otherwise
    build.usb_manufacturer="Unknown"
    build.usb_flags=-DUSB_VID={build.vid} -DUSB_PID={build.pid} '-DUSB_MANUFACTURER={build.usb_manufacturer}' '-DUSB_PRODUCT={build.usb_product}'
    

    Thanks!



  • Thanks for the reply.

    I have no idea about the platform.txt file so I will wait to see if someone much smarter than me can figure it out 🙂

    If it helps, I am using the Arduino IDE V.1.81, compiling with a custom atmega328p board running at 8MHz with BOD disabled.

    Ben


  • Contest Winner

    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!


  • Contest Winner

    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



  • @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...


  • Contest Winner

    @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



  • 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!



  • 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!


  • Plugin Developer

    It sounds absolutely terrific ! 👍

    Thank you very much !


  • Contest Winner

    @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!



  • @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
    

  • Contest Winner

    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



  • @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 😄

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



  • 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?



  • @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).


  • Contest Winner

    @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.


  • Contest Winner

    @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.



  • @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


  • Mod

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


  • Contest Winner

    @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



  • @user2684
    Tanks i try and report you
    By



  • 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.


  • Contest Winner

    @rhaymo you're right, combining sensors waking up from an interrupt and sensors reporting periodically does not work properly with NodeManager right now. I've opened this enhancement request: https://github.com/mysensors/NodeManager/issues/41.
    It may be not trivial to implement so it will not be part of the next release which is almost ready but I'll work on it just after since looks like a key requirement for many projects.
    Thanks!



  • @user2684 Great plugin, thanks. Please: consider adding support for a more than one DS18B20 devices and fixed mapping sensor_id <-> DS18B20 id.



  • Hi User2684,

    As promised i took NodeManager for a spin. It functions well but i have an issue with powering a DHT22 from the digital pins. It just does not show any temp/hum. If i use the power from the battery it functions well.

    Any clue what this could be?

    I used setPowerPins6,7,10000 to be sure the DHT22 has enough time to start up. If i use my multimeter between pins 6,7 i see the voltage going to 3.something volts and to 0 when the 10000 miliseconds are gone.

    My config is as following;

    // before
    void before() {
      // setup the serial port baud rate
      Serial.begin(MY_BAUD_RATE);  
      /*
       * Register below your sensors
      */
      nodeManager.setSleep(SLEEP,1,MINUTES); 
    nodeManager.registerSensor(SENSOR_DHT22,3);
    nodeManager.setPowerPins(6,7,10000);
      /*
       * Register above your sensors
      */
      nodeManager.before();
    }


  • @Robbie_ I've NOT checked anything but I think that probably better:

    1. power up DHT
    2. wait a little to "dht startup"
    3. register sensor


  • @bilbolodz
    So like this?

    nodeManager.setPowerPins(6,7,10000);
    nodeManager.registerSensor(SENSOR_DHT22,3);
    nodeManager.setSleep(SLEEP,1,MINUTES);



  • @Robbie_ said in NodeManager: plugin for a rapid development of battery-powered sensors:
    Try this:

    nodeManager.setPowerPins(6,7,10000);
    wait(10000);
    nodeManager.registerSensor(SENSOR_DHT22,3);```


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

    wait(10000);

    Thanks for the fast reply! Still the same issue;

    SEND D=0 I=200 C=0 T=48 S=STARTED I=0 F=0.00
    14258 TSF:MSG:SEND,100-100-0-0,s=200,c=1,t=48,pt=0,l=7,sg=0,ft=0,st=OK:STARTED
    14395 MCO:BGN:INIT OK,TSP=1
    ON P=7
    14426 MCO:SLP:MS=10000,SMS=0,I1=255,M1=255,I2=255,M2=255
    14493 MCO:SLP:TPD
    14512 MCO:SLP:WUP=-1
    DHT I=1 T=nan
    OFF P=7
    SLEEP 60s
    SEND D=0 I=200 C=1 T=48 S=SLEEPING I=0 F=0.00
    

  • Contest Winner

    @bilbolodz multiple DS18B20 are supported indeed, when you register a DS18B20 sensor and provide the pin where multiple devices are attached, NodeManager will go through all of them (by calling getDeviceCount() of DallasTemperature) and will register each of them with a different child id. Is this what you were looking for?


  • Contest Winner

    Hi, @Robbie_ the order doesn't matter since all of this is happening inside before(), NodeManager just keeps track of all your settings without doing anything at that stage.

    Your configuration looks correct to me, the DHT sensor attached to pin 3, pin 6 playing the role of ground, pin 7 the role of vcc and waiting for 10 seconds after powering on, before actually reading the value from the sensor. The log also tells the same story, pin 7 is turned on, then 10s of sleep and then the "nan" read which I cannot really understand (the code is very simple, just executes a digitalWrite(_vcc_pin, HIGH) at that stage).
    Would you please ensure pin 7 is HIGH during the 10s sleep?

    Not sure if it matters (and those more expert than me with a DHT sensor can confirm) but I've noticed that I call dht.begin() only once (during before()) and during loop() I just call readTemperature(). Does powering off the sensor have an impact on this? e.g. should I call begin() before every read?
    Thanks


  • Mod

    I think you need to call the begin if you power off the sensor



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

    @bilbolodz multiple DS18B20 are supported indeed, when you register a DS18B20 sensor and provide the pin where multiple devices are attached, NodeManager will go through all of them (by calling getDeviceCount() of DallasTemperature) and will register each of them with a different child id. Is this what you were looking for?

    Multiple sensors: great but for me important thing is "fixed" matching exact DS18B20 to particular child id. I'm going to monitor may two function water boiler and check input/output temperature. In case when one of the DS disappear (because of many reasons) after next nodemanager device startup assigning sensors to child id will change and it will be a great problem. That's why I'm asking for exact assigning DS id - child id. Is it clear now?


  • Contest Winner

    Thanks @gohan. @Robbie_ if you can then try copying that "_dht->begin();" you have in line 576 of NodeManager.cpp also at the beginning of "SensorDHT::onLoop()" which is just below we can see if this can help (unfortunately I don't have anymore a DHT sensor to test by myself).

    Another try would be to disable both MySensors and NodeManager debug: I've seen strange behaviors happening when approaching the dynamic memory limit (including this) and since objects are allocated dynamically, it could be the case (this issue is partially mitigated in the dev branch)


  • Contest Winner

    @bilbolodz I understand what you are saying. I've opened this: https://github.com/mysensors/NodeManager/issues/42. I did not consider this use case before because according to DallasTemperature documentation the attached sensors are always returned in the same order but you're right, if one of the sensor for any reason is not detected, it will mess up your logic. Thanks for reporting it.



  • @user2684 Great, so I'm waiting for version 1.4. Any ideas about timeline?



  • @user2684 This is exactly i had mentioned in my requirement for IOExpanded pins attached to any sensor or virtual buttons... getting the same child_id everytime. Hope its clear now...



  • @user2684 Thanks for your reply. Ive tested the following;

    i editted the NodeManager.cpp and added _dht->begin(); to the beginning of "SensorDHT::onLoop()"

    I also disabled both debug, still the same issue.

    In your other post you mentioned "Would you please ensure pin 7 is HIGH during the 10s sleep?"

    My log looks as following;

    PWR G=6 V=7
    REG I=1 P=3 P=6 T=0
    REG I=2 P=3 P=7 T=1
    NodeManager v1.30
    INT1 M=255
    INT2 M=255
    RADIO OK
    PRES I=200, T=23
    PRES I=201, T=30
    BATT V=3.26 P=94
    SEND D=0 I=201 C=0 T=38 S= I=0 F=3.26
    PRES I=1 T=6
    PRES I=2 T=7
    READY
    
    MY I=100 M=1
    SEND D=0 I=200 C=0 T=48 S=STARTED I=0 F=0.00
    ON P=7
    DHT I=1 T=nan
    OFF P=7
    SLEEP 60s
    SEND D=0 I=200 C=1 T=48 S=SLEEPING I=0 F=0.00
    
    AWAKE
    SEND D=0 I=200 C=1 T=48 S=AWAKE I=0 F=0.00
    ON P=7
    DHT I=1 T=nan
    OFF P=7
    SLEEP 60s
    SEND D=0 I=200 C=1 T=48 S=SLEEPING I=0 F=0.00
    

    Where do you want me to messure if the pin is on?

    AWAKE
    SEND D=0 I=200 C=1 T=48 S=AWAKE I=0 F=0.00
    ON P=7
    DHT I=1 T=nan
    <------------------------ I messured here and the voltage is 3.something volts
    OFF P=7
    SLEEP 60s
    <--------------------------- HERE?
    SEND D=0 I=200 C=1 T=48 S=SLEEPING I=0 F=0.00
    

  • Mod

    use a multimeter and check if pin 7 during the startup of the arduino and see if you get 5v out for 10 seconds


  • Contest Winner

    @bilbolodz v1.4 is actually ready, just want to see if the DHT issue discussed here requires a code fix or not before releasing but it is already available in the dev branch (https://github.com/mysensors/NodeManager/tree/8280de908929a117287a70e73cd047f50ab9a5bb). Let me explain the way I have implemented it because may look cumbersome but I didn't want to make exceptions and have a sensor configured in a different way the all the others.
    First of all, for any sensor, the child id can be manually assigned by providing a third argument to registerSensor(), e.g. to assign child id 5:

    nodeManager.registerSensor(SENSOR_THERMISTOR,A1,5);
    

    This was available also in v1.3 but not very clear from the docs. Of course this approach does not work when you have multiple DS18B20 sensors attached since they are all configured with a single line.
    So I have implemented a renameSensor() function which basically assign a different child id, e.g. to give the sensor with child id 1 the child id 5:

    nodeManager.renameSensor(1,5);
    

    This is available for all the sensors. So in the case of multiple DS18B20 you need to register them all in the usual way ( registerSensor(SENSOR_DS18B20,pin)) then assign the child id you like just after so in case one is lost, you still have a static mapping. The alternative would have been to provide a special registerSensor only for DS18B20 which I don't like that much. Any other better alternative of course is more than welcome!

    Btw, I have also added for DS18B20 getDeviceAddress() - in case you want to assign the child id based on the device address, getResolution() and setResolution()


  • Contest Winner

    @Robbie_ even if unfortunately I do not have a spare DHT sensor to test right now, I did some tests with other sensors trying to understand the issue. My educated guess it that the problem is related to the fact that setPowerPins() set both ground and vcc but initialize both to LOW. This means that when you register the sensor (and the DHT library is initialized), the sensor is off. This behavior will be changed in v1.4 (vcc wil be set to high). What you can do with the version you are currently running is to call nodeManager.powerOn() just after the call to setPowerPins() and before registering the sensor so to keep the power on.

    If this does not work, try calling nodeManager.setAutoPowerPins(false) after setPowerPins(): this prevent nodeManager to turn the power off which is not what you want but can help in isolating the issue.
    Thanks!



  • Hello, good work !!! I'll be trying your extension very soon....

    Quick question: is it compatible with ATMEGA chips flashed with MYSBootloader pre-1.3a ?


  • Contest Winner

    @luizrrocha I did not test it by myself but the bootloader used should have no impact on the code (unless you need to call different/specific functions with that bootloader but I guess this is not the case).



  • @user2684 Ive tested this morning a DHT22 without resistor between VIN & DATA, now it works correct. I reverted the changes back and just use the default code (1.3), everything keeps functioning. I don't understand why it works but hey, i got data! 🙂

    Somehow the following issue pops up with domoticz (also before the DHT22 was working), im not sure if anybody can help me here with it, else il open a threat at the domoticz forum. As soon ase NodeManager presents itself (via ESP8266 WiFi Gateway // MyS v2.1.0) to domoticz, domoticz goes offline. Does somebody else had the same experiance?



  • This post is deleted!


  • @Robbie_ Narrowed down the issue with domoticz, if i #define SERVICE_MESSAGES 1 in config.h domoticz crashes, if i put it back to 0 it stays online.


  • Contest Winner

    @Robbie_ glad to see it is working now! It has been still a good excuse for me to review and correct the logic of the power pins. Regarding SERVICE_MESSAGES, NodeManager sends a set of V_CUSTOM, SET messages from its service child id 200. When starts, it sends a STARTED payload , when going to sleep SLEEPING and when out of sleep AWAKE. I'm not familiar with domoticz but the service child id is presented correctly as S_CUSTOM, maybe the controller does not expect or handle a string payload. However, if you disable SERVICE_MESSAGES, this has no impact on the way NodeManager works, it just does not send those messages but if you are not using them, you are ready to go.
    In future versions I should probably even disable SERVICE_MESSAGES by default also because I expect it costs in terms of battery to send string payloads...


  • Contest Winner

    Hi, v1.4 is out and available at https://github.com/mysensors/NodeManager:

    • Added support for ML8511 UV intensity sensor
    • Added support for MQ air quality sensor
    • Added ability to manually assign a child id to a sensor
    • Ensured compatibility for non-sleeping nodes
    • Ability to control if waking up from an interrupt counts for a battery level report
    • When power pins are set the sensor is powered on just after
    • Service messages are disabled by default
    • Bug fixes

    Full changelog at https://github.com/mysensors/NodeManager/milestone/4?closed=1
    Thanks!



  • Hello,
    I am trying to sketch a simple PIR motion as an example the official NodeManager but does not appear to me the pir of domoticz
    DOMOTICZ OUTPUT

    1	S_TEMP		#1. V_TEMP (56.5)	true	1200	2017-04-09 12:11:15
    200	S_CUSTOM			true	1200	2017-04-09 11:34:45
    201	S_MULTIMETER			true	1200	2017-04-09 12:11:15
    255	S_ARDUINO_NODE	2.1.1```
    
    

    SKETCH

    /*
    NodeManager is intended to take care on your behalf of all those common tasks a MySensors node has to accomplish, speeding up the development cycle of your projects.
    
    NodeManager includes the following main components:
    - Sleep manager: allows managing automatically the complexity behind battery-powered sensors spending most of their time sleeping
    - Power manager: allows powering on your sensors only while the node is awake
    - Battery manager: provides common functionalities to read and report the battery level
    - Remote configuration: allows configuring remotely the node without the need to have physical access to it
    - Built-in personalities: for the most common sensors, provide embedded code so to allow their configuration with a single line 
    
    Documentation available on: https://mynodemanager.sourceforge.io 
     */
    
     
    // load user settings
    #include "config.h"
    // load MySensors library
    #include <MySensors.h>
    // load NodeManager library
    #include "NodeManager.h"
    
    // create a NodeManager instance
    NodeManager nodeManager;
    
    // before
    void before() {
      // setup the serial port baud rate
      Serial.begin(MY_BAUD_RATE);  
      /*
       * Register below your sensors
      */
      nodeManager.setSleep(SLEEP,60,MINUTES); 
      nodeManager.registerSensor(SENSOR_MOTION,3);
    
      /*
       * Register above your sensors
      */
      nodeManager.before();
    }
    
    // presentation
    void presentation() {
      // Send the sketch version information to the gateway and Controller
    	sendSketchInfo(SKETCH_NAME,SKETCH_VERSION);
      // call NodeManager presentation routine
      nodeManager.presentation();
    
    }
    
    // setup
    void setup() {
      // call NodeManager setup routine
      nodeManager.setup();
    }
    
    // loop
    void loop() {
      // call NodeManager loop routine
      nodeManager.loop();
    
    }
    
    // receive
    void receive(const MyMessage &message) {
      // call NodeManager receive routine
      nodeManager.receive(message);
    }
    


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

    This is available for all the sensors. So in the case of multiple DS18B20 you need to register them all in the usual way ( registerSensor(SENSOR_DS18B20,pin)) then assign the child id you like just after so in case one is lost, you still have a static mapping. The alternative would have been to provide a special registerSensor only for DS18B20 which I don't like that much. Any other better alternative of course is more than welcome!

    Thanks for support but actually in case of multiple DS18B20 your "general solution" is not very useful..... It require manual checking ID (first it IDs need to bs stored in EEPROM) renaming child id sensor in case of change and so on. In my private opinion it could be better add special registerSensor() function which takes pin and DS18B20 ID and register sensor (or not). Please consider these.


  • Mod

    @mar.conte please include node log and gateway log when node tries to connect



  • Needles to say and re-say this is really a much needed plugin for us beginners!

    Made a bunch of battery operating nodes with only DHT22 and all are working flawlessly.

    Today I tried making a node using a DS18B20 and DHT22. DS18B20 connected to digital pin 3 and DHT22 to digital pin 4. Both sensors have 10K resistors between their vcc and data lines (tried without resistors but none of the sensors worked).

    Sketch compiles and uploads fine to a Arduino Pro Mini 328 3.3v 8MHz. It also connects to the gateway, but I run into some problems;

    The first one being that watching from the serial debug, the node strarts up, connects to the gateway, reports some data and then hangs. No more activity from the node watching on the serial debug.

    The second one is that the node never sleeps - Activity led on Arduino Pro Mini remains lit.

    The last one is that DS18B20 reports the Temp to the gateway but DHT22 reports only Temp and not the Humidity. Tried changing pins for the sensors, but the same.

    Connection logs (from the serial interface) are as follows:

    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=47.75
    SEND D=0 I=1 C=0 T=0 S= N=0 F=47.75
    DHT I=2 T=25.00
    SEND D=0 I=2 C=0 T=0 S= N=0 F=25.00
    

    And the sketch I use is as follows:

    /*
    NodeManager is intended to take care on your behalf of all those common tasks a MySensors node has to accomplish, speeding up the development cycle of your projects.
    
    NodeManager includes the following main components:
    - Sleep manager: allows managing automatically the complexity behind battery-powered sensors spending most of their time sleeping
    - Power manager: allows powering on your sensors only while the node is awake
    - Battery manager: provides common functionalities to read and report the battery level
    - Remote configuration: allows configuring remotely the node without the need to have physical access to it
    - Built-in personalities: for the most common sensors, provide embedded code so to allow their configuration with a single line 
    
    Documentation available on: https://github.com/mysensors/NodeManager
     */
    
     
    // load user settings
    #include "config.h"
    // load MySensors library
    #include <MySensors.h>
    // load NodeManager library
    #include "NodeManager.h"
    
    // create a NodeManager instance
    NodeManager nodeManager;
    
    // before
    void before() {
      // setup the serial port baud rate
      Serial.begin(MY_BAUD_RATE);  
      /*
       * Register below your sensors
      */
    
        nodeManager.setBatteryMin(2.0);
        nodeManager.setBatteryMax(3.3);
        nodeManager.setSleep(SLEEP,60,SECONDS);
        nodeManager.registerSensor(SENSOR_DS18B20,3);
        nodeManager.registerSensor(SENSOR_DHT22,4);
    
      /*
       * Register above your sensors
      */
      nodeManager.before();
    }
    
    // presentation
    void presentation() {
      // Send the sketch version information to the gateway and Controller
    	sendSketchInfo(SKETCH_NAME,SKETCH_VERSION);
      // call NodeManager presentation routine
      nodeManager.presentation();
    
    }
    
    // setup
    void setup() {
      // call NodeManager setup routine
      nodeManager.setup();
    }
    
    // loop
    void loop() {
      // call NodeManager loop routine
      nodeManager.loop();
    
    }
    
    // receive
    void receive(const MyMessage &message) {
      // call NodeManager receive routine
      nodeManager.receive(message);
    }
    

    Also on config.h I have enabled DS18B20 and DHT22 modules.

    Really, any help would be welcome!

    Thanks all in advance!



  • @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
    

    0_1491753073560_domoticz_screen.jpg


  • Mod

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


  • Contest Winner

    @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


  • Contest Winner

    @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



  • @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 😉


  • Contest Winner

    @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!



  • @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.


  • Contest Winner

    @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)



  • @user2684 Yes, that could be nice solution.


  • Contest Winner

    @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!



  • @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!



  • @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?


  • Contest Winner

    @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...


  • Contest Winner

    @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!



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


  • Contest Winner

    @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



  • @user2684
    for istance Sensorswitch what is code?



  • @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);```

  • Contest Winner

    @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



  • @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


  • Contest Winner

    @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!



  • @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
    

    0_1491753073560_domoticz_screen.jpg


  • Contest Winner

    @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?



  • @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


  • Contest Winner

    @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



  • @user2684
    Yes trig again!!!


  • Contest Winner

    @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!



  • @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


  • Contest Winner

    @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



  • @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 ...



  • 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?


  • Contest Winner

    @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()



  • @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


  • Contest Winner

    @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.



  • @user2684

    Much easy INFINITE THANKS AND CONGRATULATIONS



  • @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

    0_1492372761834_IMG_3804.JPG

    This is my reprap printed house for my project


  • Contest Winner

    @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!



  • 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?



  • 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.


  • Contest Winner

    @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


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 8
  • 1
  • 16
  • 2

0
Online

11.2k
Users

11.1k
Topics

112.5k
Posts