@rakeshpai I think once https://github.com/mysensors/NodeManager/pull/177 will be done, you can start working with it. I'm completely changing the default behavior the board operates and I hope this would be more intuitive. There will be only 2 modes instead of 4 and reporting and sleeping will be completely decoupled since it was not very intuitive before.

Hi @rakeshpai, I've finally merged the big update I mentioned in my previous post and postponed to v1.7 a few things I had on the list so to speed up the development and having v1.6 out asap. There will be no major changes left (apart from adding a few other sensors) so I think you can start from the current development branch https://github.com/mysensors/NodeManager/tree/development. With https://github.com/mysensors/NodeManager/pull/177 I've introduced a completely different way to define reporting intervals and sleeping cycles, more details in the PR and in the updated documentation. Of course feel free to let me know in case of any doubt.

Also, regarding your screen for configuring every sensor, I was wondering if you want to somehow apply a logic similar to mine. I mean, for every sensor in NM you can call a member function of the Sensor class or one from the subclass. E.g. for the thermistor you can set the number of samples (like every sensor since setSamples() is a member of Sensor or a thermistor class specific function. This could for example translate into two tabs, one common for all the sensors and another sensor specific; which has no impact in the code since the object to use is still the same but would probably help you in the configuration screen.
Thanks

Sorry for the silence. I didn't realise I wasn't getting notifications about this thread. Thanks for the updates. I'll go over your comments and issues and start making changes accordingly. I'll update here once I have something. Thanks again. Woohoo!

Just want to be sure I understand the changes, so please bear with me.

When a node is awake, each sensor can have its individual reporting times (or a global reporting time), which need not have any relation to anything else. However, if a node is sleeping, its reporting time has to be a multiple of the sleep interval of the node. Is this understanding correct?

If so, I'm thinking of the following UI:

If a node is not battery powered, the UI can let you set the reporting interval on individual sensors. Even though setting reporting interval on every sensor gets repetitive, it might be the easiest to use. The alternative would be to have a shared global setting influencing the reporting interval, but that gets tricky to convey in the UI.

If a node is battery powered, the user will have to set a sleep interval. We could then use one of two approaches: (1) The user can't set the reporting interval for sensors at all, in which case the sleep interval is used as the reporting interval by default, or (2) We can let the user set a reporting interval, but only if it's a multiple of the sleep interval. Either one works for me, the second seems most flexible.

Is my understanding correct, and would this kind of a UI implementation do the job?

@rakeshpai correct (almost). There is a global setReportInterval which will set the reporting interval for all the sensors. If setReportInterval of the sensor is called, the global setting of course will not apply. All of this has been done to allow potential per-sensor reporting intervals and to have a consistent behavior, regardless if the node is sleeping or not.
If battery powered, the logic is still the same, of course the condition (is it the time to report?) in this case is evaluated when the node is awake next. So yes, in this case better if the reporting interval is a multiple of the sleep time but not necessarily. The end result of course would be the same.

In terms of UI, I'd probably add a global reporting interval input (and if you prefer with a drop down menu with seconds/minutes/hours so to call the right function) together with global optional sleep interval and an optional per-sensor reporting interval. I'd probably not enforce the "multiple of" thing to keep it simple on your side. Users may guess if the node is sleeping it will not report.

Also, do you think all of this NodeManager's restructuring makes the logic more clear to understand? I felt like reporting by default at every sleep cycle was not intuitive and confusing, hope now looks better.
Thanks!

There's additional messaging for the reporting interval fields to clarify what happens when the node is sleeping.

The generated code has been updated.

I haven't implemented a global reporting time. I felt it would make the UI complicated. I might be mistaken, but it isn't relevant for all types of sensors, isn't it? For eg. there's not much to sense by polling a motion sensor, or a switch. So, I felt like it's best if we ask for it only where relevant, and not out of context. I'm open to change this though. Please let me know what you think.

The sketch is just a barebones sketch, wiring up the before, presentation, etc. functions to node manager. The config.h is as follows, though nothing stands out to me as being out of place.

#ifndef config_h
#define config_h
// Message signing
#define MY_SIGNING_SOFT
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
#define MY_SIGNING_REQUEST_SIGNATURES
/**********************************
* Sketch configuration
*/
#define SKETCH_NAME "Gateway"
#define SKETCH_VERSION "1.0"
#define MY_REPEATER_FEATURE
/**********************************
* MySensors node configuration
*/
// General settings
#define MY_BAUD_RATE 9600
//#define MY_DEBUG
// NRF24 radio settings
#define MY_RADIO_NRF24
#define MY_RF24_ENABLE_ENCRYPTION
#define MY_RF24_CHANNEL 76
#define MY_RF24_PA_LEVEL RF24_PA_LOW
//#define MY_DEBUG_VERBOSE_RF24
// Serial gateway settings
#define MY_GATEWAY_SERIAL
/***********************************
* NodeManager configuration
*/
// if enabled, enable debug messages on serial port
//#define DEBUG 1
#define POWER_MANAGER 0
#define BATTERY_MANAGER 0
// if enabled, allow modifying the configuration remotely by interacting with the configuration child id
#define REMOTE_CONFIGURATION 1
// if enabled, persist the configuration settings on EEPROM
#define PERSIST 0
// if enabled, a battery sensor will be created at BATTERY_CHILD_ID and will report vcc voltage together with the battery level percentage
#define BATTERY_SENSOR 0
// if enabled, send a SLEEPING and AWAKE service messages just before entering and just after leaving a sleep cycle and STARTED when starting/rebooting
#define SERVICE_MESSAGES 0
// Enable this module to use one of the following sensors: SENSOR_ANALOG_INPUT, SENSOR_LDR, SENSOR_THERMISTOR, SENSOR_MQ, SENSOR_ML8511, SENSOR_ACS712, SENSOR_RAIN_GAUGE
#define MODULE_ANALOG_INPUT 0
// Enable this module to use one of the following sensors: SENSOR_DIGITAL_INPUT
#define MODULE_DIGITAL_INPUT 0
// Enable this module to use one of the following sensors: SENSOR_DIGITAL_OUTPUT, SENSOR_RELAY, SENSOR_LATCHING_RELAY
#define MODULE_DIGITAL_OUTPUT 0
// Enable this module to use one of the following sensors: SENSOR_DHT11, SENSOR_DHT22
#define MODULE_DHT 0
// Enable this module to use one of the following sensors: SENSOR_SHT21
#define MODULE_SHT21 0
// Enable this module to use one of the following sensors: SENSOR_SWITCH, SENSOR_DOOR, SENSOR_MOTION
#define MODULE_SWITCH 0
// Enable this module to use one of the following sensors: SENSOR_DS18B20
#define MODULE_DS18B20 0
// Enable this module to use one of the following sensors: SENSOR_BH1750
#define MODULE_BH1750 0
// Enable this module to use one of the following sensors: SENSOR_MLX90614
#define MODULE_MLX90614 0
// Enable this module to use one of the following sensors: SENSOR_BME280
#define MODULE_BME280 0
// Enable this module to use one of the following sensors: SENSOR_SONOFF
#define MODULE_SONOFF 0
// Enable this module to use one of the following sensors: SENSOR_BMP085
#define MODULE_BMP085 0
// Enable this module to use one of the following sensors: SENSOR_HCSR04
#define MODULE_HCSR04 0
// Enable this module to use one of the following sensors: SENSOR_MCP9808
#define MODULE_MCP9808 0
#endif

That's correct, for a motion sensor or a switch, reporting inteval does not make sense (even if technically the loop() function is called every 10 minutes which is the default reporting interval if a custom one is not provided but this does not make any difference). I'd keep per-sensor reporting inteval as you suggest, it seems easier for a new user to me as well.

When opening https://rakeshpai.github.io/mysensors-network-manager/ after clicking on the "there is an update please click here" message, I have now a "Just a moment..." message fixed on the screen and I couldn't recover the app even after clearing the cache of my browser. In an incognito window of course works just fine

I'd probably add a global setting (maybe in advanced) for enabling MySensors and/or NodeManager debug since this may be a common task even of a new user when requested

Having soft signing defined in config.h is in my backlog as well and will be added soon

We probably need a way to select which MySensors API version we are using. MY_RFM69_NEW_DRIVER is only available in v2.2-beta and the old RF69_868MHZ will become RFM69_868MHZ which may cause compilation errors if the wrong library version is installed

Are you sure MY_RF69_IRQ_PIN, MY_RF69_IRQ_NUM and MY_RF69_SPI_CS have to be defined with a pro mini board? I thought they were only to be set when using a ESP8266

You may want to use the updated config.h which now includes a few more common directives. Even if they are commented out can be useful for a user to have those example available

When adding a PIR sensor, the pin in the code is always 0

You can add automatically in config.h a #define MAX_SENSORS 10 where the number is automatically calculated based on the number of sensors configured. This will help in saving storage if defining just a few sensors or allowing multiple sensors to be allocated

We can probably start adding all the other built-in sensors left out so far, now that the available functions are not subject of big changes. Let me know if you need any help with it

@user2684 Woops, if you only see the loading message, I've dun goofed. Can you please look in your JS console (Ctrl+Shift+I) and tell me what is the error you see?

To fix the problem, you can delete your existing data. You can do that within the devtools itself. Click on the Application tab in the devtools, and in the left pane, under Storage, select Localstorage > https://rakeshpai.github.io, and delete the key called 'app-data'. Please make sure you copy your error messages before you do this though, so that I know what went wrong.

TypeError: Cannot read property 'pinType' of undefined
at https://rakeshpai.github.io/mysensors-network-manager/static/js/main.1fdf5f27.js:1:238265
at Array.map (native)
at https://rakeshpai.github.io/mysensors-network-manager/static/js/main.1fdf5f27.js:1:238221
at Array.map (native)
at o (https://rakeshpai.github.io/mysensors-network-manager/static/js/main.1fdf5f27.js:1:238079)
at https://rakeshpai.github.io/mysensors-network-manager/static/js/main.1fdf5f27.js:1:238546
at Array.reduce (<anonymous>)
at i (https://rakeshpai.github.io/mysensors-network-manager/static/js/main.1fdf5f27.js:1:238518)
at Array.map (native)
at a (https://rakeshpai.github.io/mysensors-network-manager/static/js/main.1fdf5f27.js:1:238659)

@user2684 Thanks. If you haven't already deleted the app_data key, could you please share the value of that key with me? If you've already deleted it, do you remember which sensors you had configured across your nodes in your settings?

This was an error in the migration process, where the old data is ported over to the new format, if I make changes in the format of the data. I've obviously done something wrong in that porting logic.

@user2684 Thanks. That helped identify the problem. I've changed the key switch to inputSwitch to avoid clashes with C keywords, which is causing the issue. I had done this long ago, when I wasn't caring about data migrations. Looks like your data still has that old bit in it.

Sorry for the trouble. The easiest thing to do is to delete that value, and start afresh. I'll be more diligent about making modifications in the future.

@user2684 We will need to decide which version of MySensors to use. I've been using the latest version from the development branch. In fact, the ascii-art splash screen is the latest commit, as of 5 days ago. Since you aren't seeing the ascii-art, you are probably on a slightly older commit.

I'm not sure if we can start supporting from the current stable 2.1.1 onwards? I don't know about the advantages that the new driver for RFM69 brings. If it's any effort at all to get it to work with older versions, it's probably not worth it. I don't mind waiting till 2.2 is released.

I've simply copy-pasted the MY_RFM_* defines from somewhere in the MySensors examples. They are currently hardcoded and probably are just the defaults. I'll clean that up.

@rakeshpai I think you're right, making it compatible with too many versions can become challenging. The only remarkable difference between 2.1.1 and 2.2.0 is the RF69_868MHZ turned into RFM69_868MHZ. MY_RFM69_NEW_DRIVER if set in 2.1.1 has no impact and the radio signal level child id I've just introduced is not enabled unless MY_SIGNAL_REPORT_ENABLED is defined (only in 2.2.0). So the issue apparently is only on RF69_868MHZ which is probably minor since the user can add or delete a single letter. So we can definitely target 2.1.1.
Just a note on the MAX_SENSORS: what I wrote before is wrong, MAX_SENSORS defines the maximum number of child ids, not the maximum number of sensors so if you want to set it up, you need to take into account for each sensor how many child ids are created (which is static but to take into account). Thanks!