@chipmc, I’ve discussed a 1 year of run-time @ a 2 hour publish schedule for a Boron LTE using the EN pin, AA batteries, in this post/thread. The actual Stress Test concluded at 10,000 Wake & Publish Cycles using (3) AA Batteries. The Cycle time was 12-14 seconds for the 10,000 Events.
Summary: A power budget for my location would be calculated using any publish schedule (1 mWh each publish) and the Quiescent current of 7.5 mWh per day. Note: The 1 mWh per Startup/Publish Event will likely be reduced if not Connecting to the Particle Cloud each cycle, by pushing data directly to your backend service (as @Backpacker87 did with Ubidots to minimize Cellular Data on each Event).
As far as I know, you just need your carrier board to store the Count from your motion sensor, and cleared after each Boron Wake Cycle/Publish.
Trial #1 in the same thread used a 0.5W Solar Panel, that only cost a few dollars. It’s smaller than the breadboard that Particles ship with (for a physical size reference). That was 1 year ago (and several firmware versions), but the Boron still re-charged the LiPo while Shutdown via EN Pin. I haven’t confirmed that for 1.4.0.
Depending on the # of Motion Sensor Events that actually occur in a day at your locations, a simplified version (no carrier board) might be applicable with a small panel. The Motion sensor can trigger the TPL to wake the Boron and report each Event directly (simple test here), especially considering the Cellular Data Reduction that @Backpacker87 reported.
Side Note: In my opinion, it makes more sense to track the mWh, not mAh.
In Low-Powered Applications, we are dealing with the entire voltage range of the battery source.
The mA change drastically across this voltage range, the power (mW) doesn’t.