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

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

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

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)

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

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

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

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

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

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.

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.

@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

@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

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

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.

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.

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

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

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

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

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.

@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

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

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

@mar.conte 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?

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:

@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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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