💬 NodeManager
-
@user2684, why does NodeManager take so many sketch memory?
e.g.
(#define BATTERY_MANAGER 1; #define DEBUG 1; #define MODULE_DS18B20 1)
sketch NodeManager RS485 config for DS18B20 --> 28730 bytes (93%) of program storage space. Maximum is 30720 bytes.own sketch for RS485 SR04T --> 17078 bytes (55%) of program storage space. Maximum is 30720 bytes.
OK, DS18B20 and SR04T are not the same but DS18B20 is less complex, so 38% more memory is pretty much.
Do I miss something?@ArduiSens for curiosity, what board are those numbers from?
NodeManager is a young project. You can expect changes and optimizations in the future. And also you can do suggestions and pull requests.
-
@user2684, why does NodeManager take so many sketch memory?
e.g.
(#define BATTERY_MANAGER 1; #define DEBUG 1; #define MODULE_DS18B20 1)
sketch NodeManager RS485 config for DS18B20 --> 28730 bytes (93%) of program storage space. Maximum is 30720 bytes.own sketch for RS485 SR04T --> 17078 bytes (55%) of program storage space. Maximum is 30720 bytes.
OK, DS18B20 and SR04T are not the same but DS18B20 is less complex, so 38% more memory is pretty much.
Do I miss something?@ArduiSens that's true, many optimizations can be done to save additional storage. With v1.5.1 a design issue eating up 20% of the storage has been fixed but many things for sure can be improved. As for the current version, try lowering down MAX_SENSORS (which by default allocates the pointers for 10 child IDs) and set DEBUG to 0 after your tests. The latter especially should give you another 20% of storage back (static strings of the debug output are consuming most of this storage). Thanks
-
How to add i2c sensor?
I see that there is a git issue asking about si7021 which I would also like to use as well, but has someone perhaps connected it already by creating a custom sensor?
How difficult would it be?
Thanks!Hi @dakipro, I've just commented on github for the Si7021. Regarding the custom sensor, have a look at this https://github.com/mysensors/NodeManager#creating-a-custom-sensor (or the same section on the development branch documentation if you are using it). As far as you create an (inline) class inheriting from Sensor or its subclasses and implement the methods listed in the documentation you can invoke registerSensor() providing the instance of your class and NodeManager will take care of it. Just take inspiration from an existing sensor if you want to do so, it should save you some time. Thanks
-
Hello All,
NodeManager v1.6 is finally available! Download and upgrade instructions can be found as always on https://github.com/mysensors/NodeManager
First of all I want to thank everybody contributing to the project, especially those who have submitted pull requests to the repository.
In v1.6 we have 36 out-of-the-box sensors as well as a good number fixes and enhancements. The most notable are for sure the capability to customize any sensor remotely through a brand new remote API and a more flexible and effective way to configure reporting intervals and sleep cycles:
- Introduced new remote API to allow calling almost ALL NodeManager's and its sensors' functions remotely
- Reporting interval configuration is now indipendent from the sleep cycle
- Reporting interval can be customized per-sensor
- All intervals (measure/battery reports) are now time-based
- Added support for BMP280 temperature and pressure sensor
- Added support for RS485 serial transport
- Added support for TSL2561 light sensor
- Added support for DHT21 temperature/humidity sensor
- Added support for AM2320 temperature/humidity sensor
- Added support for PT100 high temperature sensor
- Added support for MH-Z19 CO2 sensor
- Added support for analog rain and soil moisture sensors
- Added support for generic dimmer sensor (PWM output)
- Added support for power and water meter pulse sensors
- Radio signal level (RSSI) is now reported automatically like the battery level
- SensorRainGauge now supports sleep mode
- SensorSwitch now supports awake mode
- SensorLatchingRealy now handles automatically both on and off commands
- SensorMQ now depends on its own module
- Added safeguard (automatic off) to SensorDigitalOutput
- Any sensor can now access all NodeManager's functions
- DHT sensor now using MySensors' DHT library
For those who have previously forked the repository, please ensure to merge the updated development branch first before submitting any new PR.
Thanks!
-
Hi, obviously a lot of work gone into NodeManager thanks, I'm quite new to MySensors but have started working on.a few sensors around my home.
I was just looking through the code (NodeManager.cpp) and an apparent issue jumped out at me (I write C++ for a living on very large boxes but still worry about performance!)
The two functions NodeManager::_saveConfig and NodeManager::_loadConfig are used to save the _sleep_time value to EEPROM. The code splits the long value into 3 parts by dividing by successively 255 . On loading the value is reconstructed by multiplying by 255.
I'm pretty sure that you meant to use 256 to split the long value into three independent bytes to store.
Dividing or multiplying by 255 is potentially expensive whereas dividing or multiplying by 256 is much faster simply requiring shifts.
The normal code for splitting a long value into individual bytes would be something like
uint8_t byte0 = _sleep_time & 0xff; // compiler should generate a simple byte load
uint8_t byte1 = (_sleep_time >> 8 ) & 0xff; // compiler should still generate a simple byte load from the second byte of _sleep_time
uint8_t byte2 = (_sleep_time >> 16) & 0xff; // as before should still be a byte load.
I'm not sure how good the gcc optimiser is for the AVR code but, putting the shift&mask operations directly into the calls of saveSave(...) may avoid having to allocate local variables as in
// save the 3 bits
saveState(EEPROM_SLEEP_SAVED,1);
saveState(EEPROM_SLEEP_1,_sleep_time & 0xff);
saveState(EEPROM_SLEEP_2,(_sleep_time >> 8 ) & 0xff);
saveState(EEPROM_SLEEP_3, (_sleep_time >> 16) & 0xff);I am not an expert in in the AVR architecture or instruction set so maybe there is a good reason why you are using 255 instead of 256 - it just seems strange!
Regards
Graham
-
Hi,
I have started to play with nodemanager and I have registered a SENSOR_DS18B20. Nodemanager handles all the heavy lifting and the sensor is reporting the temperature 100%. I can change the sleep and report intervals with “setReportIntervalSeconds and setSleepSeconds”.Question 1:
According to the MySensors documentation (https://www.mysensors.org/download/serial_api_20#variable-types) a S_TEMP sensor can report the V_TEMP value and a V_ID value. Nodemanager populates the V_TEMP variable, but how can I populate and send the V_ID value?
Question2:
If I want to add an additional sensor I must register it with “registerSensor” and I would set the report interval for this sensor by getting a pointer to this sensor with “getSensor”, but how do I add custom code for this sensor in Loop()? How do I ensure that the custom code is only executed for this sensor and not for the other sensor? -
@user2684, Will you like to consider adding a #DEFINE to let user configure PowerOn function to select "GND-On" or "Vcc-On" (5V0)?
With this GND-On PowerOn, a single GND wire controlled by a digital pin can control the power instead of 2 wire poweron control. [so many control words :)]
For devices that require more than ~10mA current (~Arduino pin current) this GND-On configuration can help externally supplied higher powered V+ current to switch the devices! Thus, will also help 3V3 devices to be controlled by PowerOn, of course, with external 3V3!
-
I just started using NodeManager, mainly for the ability to send settings to the node.
I started with a plain analog (Voltage) sensor, and it works just fine. But I cannot make a DS18B20 sensor to send any temperature data. It registers on the gateway, and that's it.
I have enabled the DS18B20 module in the config.h.
This is the code in the sketch:/* * Register below your sensors */ nodeManager.setSleepSeconds(10); nodeManager.setReportIntervalSeconds(10); int temp = nodeManager.registerSensor(SENSOR_DS18B20); /* * Register above your sensors */Am I missing something?
-
Hi, obviously a lot of work gone into NodeManager thanks, I'm quite new to MySensors but have started working on.a few sensors around my home.
I was just looking through the code (NodeManager.cpp) and an apparent issue jumped out at me (I write C++ for a living on very large boxes but still worry about performance!)
The two functions NodeManager::_saveConfig and NodeManager::_loadConfig are used to save the _sleep_time value to EEPROM. The code splits the long value into 3 parts by dividing by successively 255 . On loading the value is reconstructed by multiplying by 255.
I'm pretty sure that you meant to use 256 to split the long value into three independent bytes to store.
Dividing or multiplying by 255 is potentially expensive whereas dividing or multiplying by 256 is much faster simply requiring shifts.
The normal code for splitting a long value into individual bytes would be something like
uint8_t byte0 = _sleep_time & 0xff; // compiler should generate a simple byte load
uint8_t byte1 = (_sleep_time >> 8 ) & 0xff; // compiler should still generate a simple byte load from the second byte of _sleep_time
uint8_t byte2 = (_sleep_time >> 16) & 0xff; // as before should still be a byte load.
I'm not sure how good the gcc optimiser is for the AVR code but, putting the shift&mask operations directly into the calls of saveSave(...) may avoid having to allocate local variables as in
// save the 3 bits
saveState(EEPROM_SLEEP_SAVED,1);
saveState(EEPROM_SLEEP_1,_sleep_time & 0xff);
saveState(EEPROM_SLEEP_2,(_sleep_time >> 8 ) & 0xff);
saveState(EEPROM_SLEEP_3, (_sleep_time >> 16) & 0xff);I am not an expert in in the AVR architecture or instruction set so maybe there is a good reason why you are using 255 instead of 256 - it just seems strange!
Regards
Graham
@graham86 there was no special reason why I used 255 apart from my lack of c++ knowledge :P Thanks for the hit, I'll fix it with https://github.com/mysensors/NodeManager/issues/215
-
Hi,
I have started to play with nodemanager and I have registered a SENSOR_DS18B20. Nodemanager handles all the heavy lifting and the sensor is reporting the temperature 100%. I can change the sleep and report intervals with “setReportIntervalSeconds and setSleepSeconds”.Question 1:
According to the MySensors documentation (https://www.mysensors.org/download/serial_api_20#variable-types) a S_TEMP sensor can report the V_TEMP value and a V_ID value. Nodemanager populates the V_TEMP variable, but how can I populate and send the V_ID value?
Question2:
If I want to add an additional sensor I must register it with “registerSensor” and I would set the report interval for this sensor by getting a pointer to this sensor with “getSensor”, but how do I add custom code for this sensor in Loop()? How do I ensure that the custom code is only executed for this sensor and not for the other sensor?Hi @FredRoot, V_ID has not been used so far by NodeManager, thanks for noticing it! I've added https://github.com/mysensors/NodeManager/issues/216 for this
Regarding the other question you have two ways: 1) add your custom code to onLoop() in NodeManager.cpp (this will not survive to an upgrade) 2) create a custom sensor inheriting from Sensor or other subclasses and call registerSensor() by providing an instance of this class (https://github.com/mysensors/NodeManager#creating-a-custom-sensor)
Thanks -
@user2684, Will you like to consider adding a #DEFINE to let user configure PowerOn function to select "GND-On" or "Vcc-On" (5V0)?
With this GND-On PowerOn, a single GND wire controlled by a digital pin can control the power instead of 2 wire poweron control. [so many control words :)]
For devices that require more than ~10mA current (~Arduino pin current) this GND-On configuration can help externally supplied higher powered V+ current to switch the devices! Thus, will also help 3V3 devices to be controlled by PowerOn, of course, with external 3V3!
-
I just started using NodeManager, mainly for the ability to send settings to the node.
I started with a plain analog (Voltage) sensor, and it works just fine. But I cannot make a DS18B20 sensor to send any temperature data. It registers on the gateway, and that's it.
I have enabled the DS18B20 module in the config.h.
This is the code in the sketch:/* * Register below your sensors */ nodeManager.setSleepSeconds(10); nodeManager.setReportIntervalSeconds(10); int temp = nodeManager.registerSensor(SENSOR_DS18B20); /* * Register above your sensors */Am I missing something?
-
@kted I think you forgot the pin to which the sensor is attached to. e.g.
nodeManager.registerSensor(SENSOR_DS18B20,6); -
@user2684 Actually, you are right. Thank you.
But shouldn't the compiler throw an error?Now to the hard part: How to send the actual command from Domoticz, for example to change the sleep duration...
@kted Such functionality it's supposed to be hard-coded in the node sketch. But if you want to make it modificable from Domoticz, perhaps you can make use of the V_VAR1-3 variables and modify them in domoticz, receive them in the node and pass to NodeManager.
-
@user2684 Actually, you are right. Thank you.
But shouldn't the compiler throw an error?Now to the hard part: How to send the actual command from Domoticz, for example to change the sleep duration...
@kted the compiler doesn't complain because for some sensors (e.g. those using i2c), the pin is not required so I made it not mandatory. As for Domoticz, I'll let others to address your question since I don't know that controller enough. Thanks
-
@user2684 I have looked at the changes in https://github.com/mysensors/NodeManager/pull/174 which incorporates an alternative improved implementation for the _LoadConfig/_SaveConfig functions (interesting that using an intermediate union requires less code than my shifting version- presumably due to differences in the way the GCC optimiser works for an AVR target).
I spotted a coupld of minor points and was also able to further reduce the code size.
Firstly as we are writing C++ rather than C the declaration of the union should just be
// Local union used to split _sleep_time into bytes
union tLongByteArrayCombo{
long long_value;
uint8_t byte_array[4];
} ;
(The typedef systax, although valid C++ is unnecessary - a simple union declaration is sufficient.)
There is also a typo - the original had a member called byte_arrray instead of byte_array.You can also save 24 bytes of code by avoiding the use of a local union variable and simply aliasing _sleep_time as the union type. So instead of _load_config doing -
tLongByteArrayCombo c;
c.byte_array[0] = loadState(EEPROM_SLEEP_1);
c.byte_array[1] = loadState(EEPROM_SLEEP_2);
c.byte_array[2] = loadState(EEPROM_SLEEP_3);
c.byte_array[3] = 0;
_sleep_time = c.long_value;
You can do
(((tLongByteArrayCombo&)_sleep_time).byte_array )[0] = loadState(EEPROM_SLEEP_1);
(((tLongByteArrayCombo&)_sleep_time).byte_array )[1] = loadState(EEPROM_SLEEP_2);
(((tLongByteArrayCombo&)_sleep_time).byte_array )[2] = loadState(EEPROM_SLEEP_3);
(((tLongByteArrayCombo&)_sleep_time).byte_array )[3] = 0;
And in _save_config instead of
tLongByteArrayCombo c;
c.long_value = _sleep_time;
saveState(EEPROM_SLEEP_1, c.byte_array[0]);
saveState(EEPROM_SLEEP_2, c.byte_array[1]);
saveState(EEPROM_SLEEP_3, c.byte_array[2]);
you can use
saveState(EEPROM_SLEEP_1, (((tLongByteArrayCombo&)_sleep_time).byte_array )[0] );
saveState(EEPROM_SLEEP_2, (((tLongByteArrayCombo&)_sleep_time).byte_array )[1] );
saveState(EEPROM_SLEEP_3, (((tLongByteArrayCombo&)_sleep_time).byte_array )[2] );In my specific sample sketch I had the following code sizes
Original NodeManager.cpp 28242 Bytes
NodeManager with patch from pull rq 174 - 28154 Bytes (saving of 88 Bytes of code(
Patched NodeManager with additional changes above - 28130 Bytes ( saving another 24 Bytes of code) -
@user2684 I have looked at the changes in https://github.com/mysensors/NodeManager/pull/174 which incorporates an alternative improved implementation for the _LoadConfig/_SaveConfig functions (interesting that using an intermediate union requires less code than my shifting version- presumably due to differences in the way the GCC optimiser works for an AVR target).
I spotted a coupld of minor points and was also able to further reduce the code size.
Firstly as we are writing C++ rather than C the declaration of the union should just be
// Local union used to split _sleep_time into bytes
union tLongByteArrayCombo{
long long_value;
uint8_t byte_array[4];
} ;
(The typedef systax, although valid C++ is unnecessary - a simple union declaration is sufficient.)
There is also a typo - the original had a member called byte_arrray instead of byte_array.You can also save 24 bytes of code by avoiding the use of a local union variable and simply aliasing _sleep_time as the union type. So instead of _load_config doing -
tLongByteArrayCombo c;
c.byte_array[0] = loadState(EEPROM_SLEEP_1);
c.byte_array[1] = loadState(EEPROM_SLEEP_2);
c.byte_array[2] = loadState(EEPROM_SLEEP_3);
c.byte_array[3] = 0;
_sleep_time = c.long_value;
You can do
(((tLongByteArrayCombo&)_sleep_time).byte_array )[0] = loadState(EEPROM_SLEEP_1);
(((tLongByteArrayCombo&)_sleep_time).byte_array )[1] = loadState(EEPROM_SLEEP_2);
(((tLongByteArrayCombo&)_sleep_time).byte_array )[2] = loadState(EEPROM_SLEEP_3);
(((tLongByteArrayCombo&)_sleep_time).byte_array )[3] = 0;
And in _save_config instead of
tLongByteArrayCombo c;
c.long_value = _sleep_time;
saveState(EEPROM_SLEEP_1, c.byte_array[0]);
saveState(EEPROM_SLEEP_2, c.byte_array[1]);
saveState(EEPROM_SLEEP_3, c.byte_array[2]);
you can use
saveState(EEPROM_SLEEP_1, (((tLongByteArrayCombo&)_sleep_time).byte_array )[0] );
saveState(EEPROM_SLEEP_2, (((tLongByteArrayCombo&)_sleep_time).byte_array )[1] );
saveState(EEPROM_SLEEP_3, (((tLongByteArrayCombo&)_sleep_time).byte_array )[2] );In my specific sample sketch I had the following code sizes
Original NodeManager.cpp 28242 Bytes
NodeManager with patch from pull rq 174 - 28154 Bytes (saving of 88 Bytes of code(
Patched NodeManager with additional changes above - 28130 Bytes ( saving another 24 Bytes of code)@graham86 I guess you are referring to https://github.com/mysensors/NodeManager/pull/217, not 174, am I wrong? Anyway, any contribution that would help saving bytes is more than welcome: NodeManager is becoming more and more complex and the situations where we are out of storage start increasing so we definitely need to save whatever wherever we can :-) Regarding what you are proposing above, keep on eye on PR #217; once a new one dedicated to this part of the code will be created as discussed there, feel free to add your own PR to that branch or just let me know and I'll do it for you. Thanks!