Jeremy Gillula

Makes sense! For (1), I would actually lean toward resetting all the registers, and I'd be happy to code up that PR if you'll accept it. If not, no worries--I...

1) Makes sense! 2) Also makes sense--I'll work on a PR that breaks out listen mode into RFM69_ListenMode.h and RFM69_ListenMode.cpp as a polymorphic subclass of RFM69.

Definitely the first one--apologies for not being clear. I agree, the second seems very risky.

Yep, I saw [miguelgrinberg/python-socketio#485](https://github.com/miguelgrinberg/python-socketio/issues/485) and thought it might be related. The solution you gave there didn't work in my case though (since the socketio client never even realized it was...

Yep, you're right--apologies for not catching that myself. I've edited the title of the bug to reflect that the calls to `_reset()` aren't spurious. Given that, I can think of...

OK, then here's how I'd change the settings (**bold** is new): - Run on Wi-Fi - Run on metered Wi-Fi - Run on specified Wi-Fi networks - **VPN over Wi-Fi...

> Isn't iii. redundant with the combination of having both "run on specified..." and ii set? I didn't mean for iii (Run on Wi-Fi if VPN is active or connected...

> I was referring to > > > * Never run when VPN is on (overriding other run conditions) > > which I understood as an option that means: Run...

> If the never_on_vpn options are included, I think it might be simpler if there was a checkbox on "vpn conditions" and then just a two-state selection between "run on...

Since this bug got a little more activity and I was the original poster, I thought I'd add a little more background. First: yes, this is only about being able...