💬 NodeManager
-
@user2684 No issues! When are you planning for 1.7.0? Looking forward to an early release especially the IO-Expander MCP23017 support...
@vikasjee v1.7 will be somewhere after summer since v1.6 should be out by the end of this month I guess. But I can promise to start looking into IO-Expander MCP23017 support as the first thing as v1.7 development will start so to make it available first thing into the development branch :)
-
@MCF I've added https://github.com/mysensors/NodeManager/issues/203 to track this request. Feel free to add any relevant comment or code samples to the issue. Thanks!
-
@ArduiSens RS485 should be already there in the development version (https://github.com/mysensors/NodeManager/tree/development). Nothing special, I've just added to config.h some sample directives, commented out by default. Let me know in case this approach can be improved. Thanks!
-
@user2684, found the RS485 settings (thanks), but having problems with disabling the BATTERY_MANAGER option.
We don't need this option in a RS485 serial wired network (or RS485 serial gateway).config.h:
#define BATTERY_MANAGER 0gives following compiling errors:
sketch\NodeManager.cpp: In member function 'void NodeManager::process(Request&)':
NodeManager.cpp:3722: error: 'setBatteryReportSeconds' was not declared in this scope
case 40: setBatteryReportSeconds(request.getValueInt()); break;
NodeManager.cpp:3723: error: 'setBatteryReportHours' was not declared in this scope
case 41: setBatteryReportHours(request.getValueInt()); break;
NodeManager.cpp:3724: error: 'setBatteryReportDays' was not declared in this scope
case 42: setBatteryReportDays(request.getValueInt()); break;exit status 1
'setBatteryReportSeconds' was not declared in this scope -
@user2684, found the RS485 settings (thanks), but having problems with disabling the BATTERY_MANAGER option.
We don't need this option in a RS485 serial wired network (or RS485 serial gateway).config.h:
#define BATTERY_MANAGER 0gives following compiling errors:
sketch\NodeManager.cpp: In member function 'void NodeManager::process(Request&)':
NodeManager.cpp:3722: error: 'setBatteryReportSeconds' was not declared in this scope
case 40: setBatteryReportSeconds(request.getValueInt()); break;
NodeManager.cpp:3723: error: 'setBatteryReportHours' was not declared in this scope
case 41: setBatteryReportHours(request.getValueInt()); break;
NodeManager.cpp:3724: error: 'setBatteryReportDays' was not declared in this scope
case 42: setBatteryReportDays(request.getValueInt()); break;exit status 1
'setBatteryReportSeconds' was not declared in this scope@ArduiSens thanks, good catch, this looks like a mistake on my side, keep on eye on https://github.com/mysensors/NodeManager/issues/206 for a fix which should come shortly.
-
@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? -
@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