MAX_SENSORS defines the maximum number of child ids

How can I know how many child ids exist in total? Is there a way to arrive at it from the sensors? Sorry for my ignorance.

Fixed most of the other bugs you pointed out. Thanks!

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

Thanks for pointing out the other issues. I'll get on it. Thanks!

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

Sorry for the lack of detail. You can get the latest gateway sketch from the app itself at https://rakeshpai.github.io/mysensors-network-manager/

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

I'm trying to compile a serial gateway, no sensors, against the development branch of NodeManager, which works fine. However, when I open the serial monitor, I get the following output:

$ pio device monitor --port /dev/ttyUSB2
--- Miniterm on /dev/ttyUSB2  9600,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
 __  __       ____
|  \/  |_   _/ ___|  ___ _ __  ___  ___  _ __ ___
| |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
| |  | | |_| |___| |  __/ | | \__ \  _  | |  \__ \
|_|  |_|\__, |____/ \___|_| |_|___/��

...and it hangs.

Any idea what the issue might be?

PS: As a self-confessed connoisseur of ASCII-art, I tip my hat in your general direction. Well done, good sir.

Pretty big update: Added the ability to select the board that the node/gateway is based on. Supported boards are: Pro Mini (5v and 3.3v), Nano and Uno for the atmega328 boards, and NodeMCU and D1 Mini for the esp8266 boards. Please let me know if your favourite board isn't listed here.

The selection of the board effects the list of available pins for sensors. The sense pin dropdown for sensors now shows the appropriate pins (analog/digital/interrupt pins) based on the board selected for the node and the type of sensor being configured.

The selected board also affects the platformio.ini file generated, which makes PlatformIO integration even more enjoyable to use. No need to specify the board during the build.

This was a pretty big update, including changes to the underlying internal datastructure itself, so it's also an acid test for the data migration and versioning system implemented before. If you don't see any errors when you refresh after the update, it means everything worked transparently, and that's great news! (The migration mechanism hasn't been tested so far, so please let me know if you see errors when you get the update.)

Also implemented a reporting interval setting for analog sensors, to bring it in line with the latest changes in NodeManager.

We're getting closer to being release-ready!

EDIT: Also, this project crossed 100 commits in GitHub already! Wow!

@user2684 The clear separation between sleeping and reporting definitely makes things easier to understand and use. Thanks for doing this.

I've now published a release with the changes for sleep time and reporting time in place. Could you please give it a spin? https://rakeshpai.github.io/mysensors-network-manager/ You may need to delete your existing sensors first.

• Sleep config is as before. Nothing's changed there.
• New reporting interval fields added. Only applies to analog sensors ATM.
• 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.

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?