Great project you got started! One thing to consider is that the Nano is not the most suitable Arduino for battery powering... Reason is that it has a USB TTL chip on it that consumes power when idle which does not add to your sensor (except for the times you want to change its sketch). Perhaps it would be best to redesign it to a Pro Mini 3.3V 8MHz. The battery power tips on the build section has more info on that.
Perhaps the 3.3V voltage regulator on the Nano does not provide enough current to power both the radio module and the OLED display? You could test the setup first with the display disconnected. If that works then you can try and find a way to power the display from a different source.
@cdr @Henry I ran into the same issue. Turned out to be a syntax issue in the boards.txt file. If you change:
MYSBL.menu.frequency.MYSBL16.f_cpu=16000000L
into
MYSBL.menu.frequency.MYSBL16.build.f_cpu=16000000L
Then it works again. Adding build. needs to be done for the other menu entries as well.
On my battery powered bicycle light I use petroleum jelly on the battery terminals. It makes changing batteries a little bit more messy than usual, but it seems to do the trick for over two years now.
@Tekka You steered me in the right direction. Thanks again! I did a search on wdt_reset to get a better idea of what it does and then found posts describing that if something keeps the CPU occupied for a prolonged time that the watchdog can kick in thinking the MCU has stalled/froze. I also understood that the MySensor library will reset the watchdog timer regularly.
Looking at my sketch I found that I used delay() at certain points. The five minute sleep was done using wait(). Replacing delay() with wait() throughout the sketch fixed the issue for me! It has not reset overnight where otherwise I would see it reset every 25 seconds or so. Now I will look at the other examples that would reset itself.
I'm in good shape now to roll out MYSBootloader and upgrade my nodes to 2.2.0 at the same time.
I would expect there to be two options: Either the Sonoff connects to the Ewelink cloud service and polls if there are actions to be taken. So the actions are not sent directly to the Sonoff unit, but the Sonoff reads at some point something needs to be done.
Another approach would be that a tunnel of some kind is initiated by the Sonoff. The Ewelink service then sends commands back through this tunnel.
Not sure what would be the best way, but two options spring to mind:
The second option has the advantage that the controller always knows the correct state of the light and it makes it easier to control the light from timers or different events (light sensors, motion, etc) and the buttons at the same time.
The basis for the three nodes could be this example: https://www.mysensors.org/build/dimmer, where you choose the example with the rotary encoder for the dimmer nodes (and leave out the LED strip).