@timh I kind of get what you're going for, but the issue is mostly that when attempting to use any sort of debouncing with multiple buttons (each button with their own callback), the first button pressed is the only button that the callback will run for until the device is reset (even though the device detects the other button is push as confirmed through looking at the pin value).
So if I understand you correctly, I could simply provide arguments for each pin's callback function to identify which one was activated. That would work, but when the callback won't even go through for any button other than the first one pressed, that doesn't really work.
I just worked around it and made a function to detect sequential long presses. Since I have 3 different status codes, I made it as such
1 long press sends status code 1
2 long presses sends status code 2
3 long presses sends status code 3
A user is notified of what press they are on based on the LED colors, and 3 green blinks represents that the status/data has been sent.
@fsergeys yes, we physically cut the header for that pin, so the only things that remain connected are the sensor and the PIC on the Pysense in our case. The LoPy was just bringing havoc when in deep sleep mode.
You may want to experiment by using jumper cables between the WiPy and PyTrack at first, connecting everything but that pin, but I’m pretty sure you’ll get better results that way.
Of course things would be very different with a WiPy 3, LoPy 4 or any of the other modules that implement deeep sleep directly rather than having to rely on an external board.
@fsergeys You should measure power draw from battery, not USB. There's a lot more going on when powered via USB, it's not representative of what happens when you're running on battery.
You can definitely use the Pytrack's deep sleep (use the PyTrack library) to power down completely the WiPy, but you shouldn't see much of a difference when running from battery in the case of a WiPy 3.