Oh yes. Good comments. I’m away from code until tonight but I’ll ad a bunch of comments on that bug do we can talk.
The project manager side of me has a basic overall suggestion for the hardware side of things.
Make 1.1.x a plumbing and documentation update with an eye on future features. (This could make future updates easier, and make things more accessible to new developers)
Make 1.2.x the WIFI expansion series (This would support the next release)
Make 1.3.x the MQTT release series
Make 1.4.x the additional hardware series
2 Likes
Hey,
maybe it’s not a bad idea showing the battery life in the app or notification area. Personally, I would like to be informed at any time how much juice there is left.
Maybe it’s already somewhere and I’m just retarded.
Hmm. It should be showing battery % full on both the device screen and the app. But one big caveat, only a few board types have the appropriate sensor to measure battery state of charge (TBEAMs and the TTGO LORA32 I think). For boards without that sensor we don’t/can’t show it.
2 Likes
my bad. its there. thanks for the kind answer tho.
Greetings from germany
1 Like
It just occured to me that an implementation of a topographical map tool like heywhatsthat would be usefull, so that you can see your position on a map, and red areas where you don’t have line of sight to known nodes. That way you can predict when you will loose contact, and easily see where you need to go to regain contact
2 Likes
I really miss some APRS features, where you can share sensor data (temperature, pressure, altitude, wind speed and direction, or lightning - with meshed sensors you can triangulate strike position), then current speed and heading or any other interesting data, like Beacons (first aid station, water source,… or commercials). For now we could just define these custom values via app, later connect some sensors through I2C or later on boards with nRF52 through ANT+/BTLE (maybe some people remember Quarq Qollector https://www.dcrainmaker.com/2016/09/quarq-qollector-review.html but with GPRS/Edge modem).
I think you will dig this document and work items (which I think will do most of that): MQTT/text messaging to internet/GPIO access/open mini-app API request for comment
1 Like
Theoretically yes, but I don’t want to let any external device touching my sensors through MQTT - just want to broadcast these values to everybody around and have them visible on the user list screen.
The similar approach I use at home - every node have to be self sufficient, don’t want to relay to any other central device (local control and all the logic have to work independently from home assistant that just acts as a hub for remote monitoring and control).
1 Like
I’m developing a plugin for this: https://github.com/paulmandal/atak-forwarder/
4 Likes
Some people, including me, comparing tracking features of Meshtastic with APRS. We don’t need to invent wheel again, since APRS is a really good example how to do public tracking and how it can integrate different services (weather, AIS,…). Similar implementation on Meshtastic site could be beneficial to us and with some features to APRS guys as well.
First we need to introduce more packet types (like APRS) - position/object/item, status, messages, queries, weather reports and telemetry. Every packet type could carry optional parameters (nicely described on APRS wiki) and could be public or private only for a specified channel. This would achieve compatibility with APRS and if properly integrated, we could take some information from APRS network - for example to see AIS nodes would be beneficial for boats and people using ferries; we could see state of their weather stations,…
Sure, we can’t just take their data, we have to provide some other benefit for them - each “public” Meshtastic node identified by a defined “call sign” could be advertised to APRS network and for this feature we would need have compatible packet types.
What do you think?
2 Likes
I think that eventually a gateway between this more general MQTT mechanism and the aprs web services would be a great idea. (I’m technically a ham though I haven’t done anything with it in a while and I used to write a fair amount of APRS related code).
And I like the concept of aprs but in a lot of ways the actual protocol is IMO pretty yucky, inflexible and dated.
This may sound completely unnecessary, but if there were room for the overhead of 1-wire code, it would be great if we could pick an unused gpio and (if we attached a DS18B20) see a temperature. Not something that requires any configuration. Just a 'if you attach a DS18B20 to GND, V+ and (some predetermined pin), temperature shows up on screen three or four, whatever. If you don’t attach the sensor to those pins, no big deal and if you attach the data wire to some ‘other’ gpio, you don’t get a temperature. The idea being to provide temp sensor capability without requiring users or developers to make any other coding changes. Baked-in if you want it, unnoticed if you don’t.
Just an idea.
I was in Missouri (home state) for the autumnish temperatures for the first time in 16 years. Now I am back in Haiti and the temperature range day to day is around 12 degrees. Monitoring the temp here is like watching corn grow. But, others may find temperature monitoring useful and in the case of repeater nodes might even find temperature logging helpful.
Pase yon bon jounen.
Scott
1 Like
good idea and even easier, because the ESP32 has a built in temp sensor that we could just read. And since we keep the CPU sleeping almost all of the time it should be reading almost ambient. I’ve added your idea here:
1 Like
My 1.1 feature request?
A simple and well documented “repeater only” device that works for multiple chats, not just the one for which was configured.
I would love to have this because in this way you could potentially cover a wide area adding a fixed repeater into tactic locations.
1 Like