Integrating NodeManager with Sketch Generator

[user2684]

PS. I think the ascii art is coming from https://github.com/mysensors/MySensors/blob/development/core/MySplashScreen.cpp

[user2684]

@rakeshpai I cannot reproduce the issue, with your config.h looks like it is working fine here :-/

NodeManager v1.6-dev
LIB R=N E=X T=R A=A S=S B=-
INT P=3 M=255
INT P=2 M=255
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.2.0-beta
RADIO OK
0;255;3;0;11;Gateway
0;255;3;0;12;1.0
PRES I=200, T=23
0;200;0;0;23;
READY

MY I=0 M=1

[rakeshpai]

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

[user2684]

@rakeshpai You're right! there was a js error:

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)

[rakeshpai]

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

@rakeshpai sure here it is:

{"networks":[{"radio":"NRF24L01+","nrfChannel":76,"rfmFrequency":868,"id":"3yu5c1pv","nodes":[{"name":"Gateway","type":"gateway","key":"554766e4d3b69590e5","pa":true,"hw":false,"battery":{"powered":false,"min":2.5,"max":3.3,"measure":"internal","measurePin":"A0","voltsPerBit":0.003363075},"sleepTime":60,"sleepUnit":"minutes","sensors":[],"signing":"software","softSigningPin":"A7","atshaSigningPin":"A3","id":"vv4cn7l3","gatewayType":"ethernet","ethernet":{"dhcp":true,"module":"w5100","ip":"192.168.1.10","gateway":"192.168.1.1","subnet":"255.255.255.0"},"wifi":{"ssid":"adsad","password":"asdsad"},"conn":{"type":"client","serverPort":5003,"serverMaxClients":1,"controllerIp":"1111","controllerPort":5003,"mqttHost":"","mqttPort":1883}},{"id":"anzgjjrk","name":"MyNode","type":"node","key":"22cb1534bdec90d3bf","pa":true,"hw":false,"battery":{"powered":true,"min":2.5,"max":3.3,"measure":"internal","measurePin":"A0","voltsPerBit":0.003363075},"sleepTime":60,"sleepUnit":"minutes","sensors":[{"type":"ldr","pin":"A0","usePowerPin":true,"reportPercentage":true,"reverse":true,"powerPin":"D9","percentageRangeMin":0,"percentageRangeMax":1024},{"type":"rain","pin":"A1","usePowerPin":true,"reportPercentage":true,"reverse":true,"powerPin":"D0","percentageRangeMin":0,"percentageRangeMax":1024},{"type":"relay","pin":"D0","onValue":"high","initialValue":"low","autoTurnOff":true,"turnOffTime":1},{"type":"motion","pin":"D1","interruptMode":"rising"},{"type":"switch","pin":"D2","interruptMode":"change","debounceTime":30,"normalValue":"high"},{"type":"latchingRelay","pin":"D3","onValue":"high","initialValue":"low","autoTurnOff":false,"turnOffTime":1,"pulseOutput":false,"pulseDuration":100}],"signing":"software","softSigningPin":"A7","atshaSigningPin":"A3"}],"hmac":"e7f21811523c4e8e463843367bf5f415c9c8cf776eebf4e1fbfd7ae3135fcbc8","aes":"b07372524a15001e092200550200a15b"},{"radio":"NRF24L01+","nrfChannel":76,"rfmFrequency":868,"id":"fi253u7o","nodes":[{"name":"Gateway","type":"gateway","key":"f98623fd783becc370","pa":false,"hw":false,"battery":{"powered":false,"min":2.5,"max":3.3,"measure":"internal","measurePin":"A0","voltsPerBit":0.003363075},"sleepTime":60,"sleepUnit":"minutes","sensors":[],"signing":"software","softSigningPin":"A7","atshaSigningPin":"A3","id":"015okgk","gatewayType":"serial","ethernet":{"dhcp":true,"module":"w5100","ip":"192.168.1.10","gateway":"192.168.1.1","subnet":"255.255.255.0"},"wifi":{"ssid":"","password":""},"conn":{"type":"server","serverPort":5003,"serverMaxClients":1,"controllerIp":"","controllerPort":5003,"mqttHost":"","mqttPort":1883}},{"id":"v6301ydk","name":"MyNode","type":"node","key":"5785ead033fe668a9e","pa":false,"hw":false,"battery":{"powered":false,"min":2.5,"max":3.3,"measure":"internal","measurePin":"A0","voltsPerBit":0.003363075},"sleepTime":60,"sleepUnit":"minutes","sensors":[{"type":"relay","pin":"D0","onValue":"high","initialValue":"low","autoTurnOff":false,"turnOffTime":1}],"signing":"software","softSigningPin":"A7","atshaSigningPin":"A3"}],"hmac":"1108c29e98d1274aa5a4e0a0c23de71053584fbda39ffe68a3c1477415fd9aab","aes":"3c44673691a361ae3f22c15f50dce5b9"}],"version":1}

[rakeshpai]

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

@rakeshpai thanks, not a big issue, I'm just running a few tests so I'm not losing anything significant by deleting that key :)

[rakeshpai]

@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 :D 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]

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

[rakeshpai]

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]

@rakeshpai not your fault, it is just not easy to see :) When you register a sensor this could create one or more child IDs. How many, depends on the sensor. If you have a look at https://github.com/mysensors/NodeManager/blob/development/NodeManager.cpp#L3139 you can see for each sensor_type how many. As a rule of thumb, add 1 every time _getAvailableChildId() is called. If you need a summary table I can make it for you.
Defining MAX_SENSORS is not mandatory but since we may risk to have precious storage wasted, better to address this at the first run I think :)

[user2684]

Hi @rakeshpai, I'm finalizing v1.6 and I was wondering if you had any other issue with NM along the way so I can fix it timely. Also, are you still experiencing the gateway issue (https://github.com/mysensors/NodeManager/issues/187) which I couldn't reproduce? Thanks!

[rakeshpai]

@user2684 Sorry, I'm not at a computer. IIRC, the issue I've been facing is that when I used the latest version of NodeManager with the latest version of MySensors dev branch, with signing and encryption, the gateway would crash on startup. This has been preventing me from proceeding.

Sorry for the lack of detail - I can't verify things at the moment. Looking forward to 1.6!

[user2684]

@rakeshpai no hurry thanks! The gateway issue sounds like a show stopper to me though but maybe I've been able to reproduce it: with both encryption AND signing enabled I got 94% of storage utilization on a pro mini hence causing the crash. If I eg disable debug so saving some storage I get no issues. Whenever you can this is probably something you can test: if this is the issue we would need to find something else to disable in order to have the gw running fine.

Also I'd recommend to disable repeater mode by default otherwise I guess you can get some issues if every node is acting as a repeater on the network

[ru64]

@rakeshpai I've got the same problem. Occasionally found out that this reproduces if DEBUG is off (#define DEBUG 0). As soon as I turned it on - it works.