Feature Request/Proposal: When on battery, shutdown after certain time

[joshpirihi]

This would be useful for my vehicle-based application (quad bike tracking on a farm) where the node is powered by the vehicle but has it's own battery too. When the vehicle is switched on, the node powers up and stays on (in the Powered state). Position reports sent via the smart_position feature.

The node will shutdown (fully power off, not just sleep) if vehicle power is off for more than the defined time period.

So my current thought is to add a field "on_battery_shutdown_after" to the UserPreferences protobuf. If >0, then it will be active.

Would need another state in PowerFSM shutdownEnter() too.

Does this sound like a reasonable approach? And how annoying is it to be adding more stuff to the UserPreferences like this?

[tim292stro]

This is interesting, but I'd opt for it to be widely configurable. Not just shut down but lower position reporting frequency, listen-mostly mode (pretty much just the radio block in RX listening for channel traffic, everything else powered off), or wake-and-report on physical interrupt (like that of an accelerometer).

I'm looking at using one node for a vehicle remote since I'm already putting it in for another messaging app... for that purpose being able to listen more than transmit as a configuration would be nice (it's lower power). On a vehicle like a quad you might find it useful to "ping" a listening/sleeping node to have it wake and respond with a location and status then go back to sleep/low-power-listen-only.

For that matter, I'm also looking at rolling my own node based on RPi Zero W2 and just using the Meshtastic protocol layer run on a RP2040 (Cortex-M0+) but using a 1W(30dBm) PA for the TX chain from an Ebyte module. This way I can use the off-the-shelf hardware and firmware for the mid-span repeaters, but then the custom hardware for the actual meat and potatoes at the end-points.

[thebentern]

For that matter, I'm also looking at rolling my own node based on RPi Zero W2 and just using the Meshtastic protocol layer run on a RP2040 (Cortex-M0+) but using a 1W(30dBm) PA for the TX chain from an Ebyte module. This way I can use the off-the-shelf hardware and firmware for the mid-span repeaters, but then the custom hardware for the actual meat and potatoes at the end-points.

Your project sounds right up my alley. I've been interested in playing with a RP2040 based solution for Meshtastic. You might take a look at a project I'm involved with using probably the same 1W E-Byte module you're referring to, albeit with an ESP32 module as the MPU. https://github.com/Hydra-Designs/project-hydra-meshtastic-pcb It's still in the early stages, but tinkering with hardware is fun!

[joshpirihi]

Yea I initially was thinking of something more complex with more config options like that, as it happened @mc-hamster was in the process of implementing position_broadcast_smart that was good enough for my use case that I don't really need to worry about it. I'm toying with the idea of some sort of event plugin that could send a message when the vehicle is turned on or off (and attach a location to that message). As it stands, you might not know for a few minutes where a vehicle parked.

I have a Traccar instance running that gathers all the position reports so I can look back and see the history (or the last known location), it works pretty well.

I wonder if there's a way I could query the nodedb from my repeater node to get the last known info for a certain device, that would mean I would be able to get the last known location of a node without needing to access Traccar (when I don't have an internet connection).

[tim292stro]

I have a Traccar instance running that gathers all the position reports so I can look back and see the history (or the last known location), it works pretty well.

I have been using ATAK... also works pretty well.

I wonder if there's a way I could query the nodedb from my repeater node to get the last known info for a certain device, that would mean I would be able to get the last known location of a node without needing to access Traccar (when I don't have an internet connection).

I think you want to be careful with relying on stale information, as long as you are aware of the risks inherent (....it says I left the kid right here!! But it's not here!!), then make hay. Likewise, having a "node failed to report-in" event/alarm is useful.

[joshpirihi]

Nice, I haven't tried ATAK. I've been tinkering with one of the beta iOS apps but stale info is a real annoyance (have to close and reopen the app to update the information).

What is your use case here? I'm using it for ATVs (and maybe a ute and tractor one day) on a hill country farm in NZ. The time that I really would want to know where a node is, is right when I can't rely on it being online like an accident of some sort (quad rollovers are a big issue here).

Something like your self contained RPI + meshtastic node all in one would be ideal as a hub. I'm very keen to see how it goes!

[tim292stro]

Quad rollovers are a big issue in general, so I feel you concern there.

I've been integrating ATAK into a lot a of stuff - tracking, security awareness (currently building it into a CCTV NVR), command+control, communications... it's a real swiss army knife tool.

My interest with Meshtastic is mostly the hardware and protocol - it's cheap and fairly robust, but the front-end is not what I want and I found that extending ATAK was easier and closer to what I wanted. In the USA (as a citizen) we can pull in a ton of imagery or terrestrial data from government public sources (like NOAA, USGS) - so rather than a flat 2D vector map we can view high-resolution satellite imagery overlaid on Space-shuttle-collected terrain data. This gives a better perception about how you figure in the world. Plus ATAK lets one annotate a map and send those annotations to other users in your team over a radio or Meshtastic (thanks to a plug-in). Interconnection to other data sources is also possible and can be directly overlaid on the client-side maps - like weather, events (for example something entering/leaving a geofence).

Out in rural areas in the California Sierra Nevada mountains where we don't have cell coverage, I use a node on my vehicle that can forward messages from a Mestastic originated client over to an Iridium SBD modem when cellular data is not available, and up to my FreeTAK server. Basically I could be way out in the woods, and extend my team communication range globally without having to carry the battery needed to run Iridium. So for me Meshtastic is a local range extender... But, like the LoRaWAN I see the interface/protocol as a low-bar to entry for a large volume of target devices.

[mc-hamster]

Closing per Andre