To anyone following along, I took a few minutes to update the code that backs the map to reconnect more robustly. I anticipate the map being a little bit more “live” going forward, as every time the MQTT client disconnected previously I’d have to manually notice and reconnect it (which I didn’t really do).
Hopefully now it should be reliable and catch even more Meshtastic users as they connect devices! Though with 760 currently (wow!) it might be more useful to start graying out nodes that don’t reconnect frequently.
Inspired by stefopl I added a couple images to differentiate plugged in vs. battery powered devices, e.g.:
I also updated it so that the markers show two very granular things, the relative time since last seen (< 7 days = green, < 30 days = yellow, anything older = grey) and whether it’s plugged in or off battery. I was thinking that would make a good proxy for “fixed” vs. “mobile”, but . Looks something like:
Wow, thank you so much. For me, the colors are a significant improvement
To turn geen (almost immediately) of cause I had to enable MQTT and the “Uplink” at the “LongFast” default channel.
To protect my tiny device from the incoming MQTT traffic I disabled Downlink for the LongFast channel.
Can this (somehow inconsistent) combination break something, or is it OK for operation?
I think there’s generally a ~5 minute latency, which I’m guessing is “fast enough” for the use case.
I guess being pedantic, the map doesn’t care at all about your device’s configuration. The map exclusively looks at protobuf messages on MQTT. Obviously the MQTT broker needs the information published to be useful. With that said, I think disabling downlink would be preferable - it’s so busy and likely you don’t care about almost all of it. I’m not aware of anything that would be negatively impacted by disabling downlink.
Can you share the user ID of one of your nodes? I can peek and see if I’ve encountered it.
I only just recently saw that the default root for new firmware changed (PR here), which is an unfortunate change for this specific atypical use case. As of this weekend the map should be pulling everything from msh/#.
I wanted to filter it somehow so currently I’m only grabbing positions that are:
a protobuf message
on a topic that contains /c/ (attempt to only get protobufs)
either not encrypted at all or encrypted with the default (AQ==) PSK
That said, I have noticed that my device isn’t showing up even though I’d expect it to. I haven’t looked at why that is - something seems slightly either off or unexpected with nodes providing their position to the mesh.
Thank you for this map @ambiguous_thaw Is it possible to add used frequency to nodes/stations? This would be good because in regions like Turkey, both 433 and 868 Mhz is used and would be nice to see for choosing devices.
. Looks something like:
