Topics created by DavidZH

Thanks Gohan, there are a few reasons for me to use the BME outside. The most important: power management (and that explains my conundrum now...). The unit contains a light sensor. That basically controls my lighting in the living room. So that needs to measure quite often to be able to control it with any accuracy. I've chosen every minute as a basis. That was also given when I found a sketch with a weather prediction function based on barometric pressure. That sketch needs to read the pressure every minute. That means that the sensor wakes up every minute. Also the radio. That's a huge load. Not really ideal for battery power. But that meant I was able to add the light sensor very easily. So now I put them in an outdoor sensor with a solar panel to keep the battery topped up. That still means I have to watch the consumption in sleep. Here in NL we have quit a few overcast days, so the panel will not be able to keep up with the demand on those days. The solution in place now is to wake up the sensor 1 second before measurement. Power up the sensors, put the controller and radio back to sleep for one second. Then do the measurement stuff, power down the sensor and I2C bus and go into deep sleep. Average current consumption measured over 4 hrs is now 140uA. Sleep current for the whole system is 36uA. That is including the charger board and Moteino voltage regulator. The unit is now up for 3 weeks and the panel keeps up very good. Most of those days were overcast. So when the cold hits next week with clear skies it should be full all the time. Battery level is sent every 6 hours. And next to that I have implemented a voltage measurement that signals when the battery is being charged. Energy is coming in, so I am allowed an extra data transfer... Now see if it dies on me again end of november 2019...

@gertsanders Thanks! Works great! I'm so happy!!!

@DavidZH absolutely. The whitelist is used to revoke secured nodes. The typical usecases is a fully secured network and you have a node compromised and want to revoke it. If someone stole your node and therefore also your hmac key they could attempt to tap into your network (also if you use a atsha and for some reason don't want to replace hmac key on all devices). As the serials are never transmitted OTA the attacker would have to guess a valid node id+serial match to get past the GW whitelist filter. Full signing documentation for 2.1.1 is here: https://ci.mysensors.org/job/Verifiers/job/MySensors/job/master/56/Doxygen_HTML/group__MySigninggrp.html

@DavidZH you're welcome. No worries, everyone can't keep track of everything

Glad it helped David. I just thought about it again, maybe sleep(0xff, 0x00, 0) does work too. I did not test it but I think it calls the same function anyway. However the method of direct calling sleep(0xff, 0x00, 0xff, 0x00, 0) should save some clocks because one less jmp is required

You are probably right, but I had already committed to the RFM by buying a Moteino and 4 radio's. Next to that is the lower penetration through concrete. Between the gateway and 2 future sensors is a '70s style bearing wall (25cm thick). I prefer lower frequencies to counter that. And thanks to this topic by Carsten I have solved it. Why I thought the radio calls in gateway and sensor should not be equal is beyond me... I did use the hack of changing the -H version in the MyTransportRFM69.h file to "true" after trying to do that via call from the sensor sketch. For now that works. When 1.6 drops I will see I can make it work by calls. Now build my other sensors and see if I can make it talk to pimatic!