I have a similar setup: MySensor nodes running on NodeMcu/ESP8266 and each using an MQTT client gateway to send sensor status directly to my MQTT broker running on a Raspberry pi alongside Home Assistant. And I also had to replace sleep() with counters in the loop() code. Those error codes are described here.
I spent many hours learning and configuring HA so sticking to that for now. Their community, like MySensors are very helpful.
@anvil - great code sleuthing! I have been absent due to travel but to ensure this doesn't slip through the cracks and create future confusion for other users, I have filed GitHub issue https://github.com/mysensors/MySensors/issues/770 to add these defaults into the RPI gateway example for the 2.2.0 release.
With your increased familiarity with the code base, feel free to make the change and submit a GitHub PR if you are so inclined, otherwise it will wait until one of the core members makes the change.
@tekka optimized the NRF driver significantly between release 1.5.1 and 2.1.1 allowing the driver to push the radio a bit harder resulting in higher current-draw spikes. I experienced the same issue with nodes that had been running for several years but failing miserably after simply upgrading to the newer library. What I had to do was ensure that I had an adequate current supply for the radio to cope with the larger current-draw spikes. This included adding a 47uf capacitor across the NRF VCC and GND pin (actually @tekka recommended 100uf) and in one case swapping out a 3.3v LDO for a higher current LDO. So I would suggest that you first eliminate NRF power/current supply issues first. Additional background about NRF power needs are available here - https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo#PP
By the way, the new MySensors Gateway that @tbowmo developed has no problem driving an NRF24L01+ PL/NA+ radio at high power.
Yes. Correct. call BME.begin() every time and the subroutine only at the beginning.
And you are also correct about the library. I use the "blue" lib, from Sparkfun. As i can recall correct (it's been over a year since I built the damn thing) I have tried both, and found the Sparkfun more stable.
And you CAN switch off power for this module, but after conversion it goes to sleep and uses less than 1uA. Hardly worth the effort, because the current can find a way over the data lines, and that's a pain in the behind to solve (I tried!).
Update: Managed to get my NFR24 radios work with Sensebender micro with greatly oversized 100uF normal electrolytic capacitor. Been in my freezer (appr. -20C) now for three days and still works fine. 2xAA batteries powering the node. Not sure where the problem is, maybe just the capacitor size because of diminishing capacitance curve in freezing temperatures. Have still some spare Nanos and Pros to spend, but gradually moving to ESP8266 based sensor network. They have proven to be very reliable even under -20 degrees celsius.
This is more a guess, but I think the real one (GPIO) is only for the interface between radio and serial gateway program. The virtual is for the interface between serial gateway program and controller. Serial interfaces are exclusive to one program at a time. Someone should verify what I just said though.
Signing is supported using both atsha204a and pure software. They are perfectly compatible so you can mix all you want.
What is important to understand is that if you use software based signing, if someone gets physical access to your node, they can dump eeprom and obtain your secret hmac key (PSK) and using that they can potentially compromise your node network.
The benefit of a atsha is that the key is securely stored and cannot be extracted from the chip. At least it is according to Atmel. So if you plan to put your node "outside" it is recommended to use atsha. On your gateway it is less important as you would typically have your gateway placed "securely". If you do not, then your network would be compromised as an attacker could tap in to the communication between gateway and controller, which is not secured.
This limitation is not accidental. Supporting security between gateway and controller mean a dependency which would limit the ability to support a wide range of controllers and is therefore undesirable. And personally I don't really see a usecase for it anyway as gateways generally are placed indoors and are hooked up to a LAN in one way or another.