Should be bundled with the device firmware within the next few releases, well that’s the goal anyway
This is amazing. Great work!
Will it be possible to run this against a local serial connection? I believe chrome supports that now: https://web.dev/serial/
I ran: mosquitto_sub -h mqtt.meshtastic.org -v -t $SYS/# -t msh/+/stat/# -t msh/+/json/#
and got he error: “Invalid subscription topic ‘$SYS/#’, are all ‘+’ and ‘#’ wildcards correct?”
was i subsitute something in that command line?
In most OS shells the $ and the # sign need to be escaped by putting a backslash in front of them. I bet that will help.
Awesome job everyone!!
I have a node fwding to mehtastic.org and another to my mqtt broker. Is there a guide on how to decode the payload? I’ve tried to set my channel as “unencrypted”, but seems like they still are.
alas not yet - once the initial experimenting is over we should have something (a few weeks?)
also - alas - unenecrypted channels are not yet supported. So you should probably do “–ch-longslow --ch-set uplink_enabled true” for now (to go back to defaults)
I received a really long message and fiddled with the tbeam middle button to see if I could scroll to the rest of the message. I held down the middle button and got a progress bar and when it was complete I let go. This didnt appear to do anything other than dim the screen. Holding it again and letting go before the progress bar completed brightened the screen again. Holding the middle button down past the progress bar, a new progress bar comes up and holding it on past that it turned off the device. Is all of this expected? Any plan to add scrolling through a long message?
Scrolling through a message would be a good feature! Alas no code there yet for that.
There is a feature request logged here
Ever since this build came out I’ve been using a fresh flash and the default channel as I assume some but not all of you are using. Once @geeksville gives his blessing and we add downlink_enabled to the channel, those of us on the default channel will be exchanging messages as one huge mesh?
alas, part of what we still need to develop is the signing infrastructure around “global channels”. I suspect very few users would end up turning on downlink_enabled on any sort of big “global channel” because it would quickly swamp the local mesh.
After a bit more experimenting @danmandle (are you DanV on dev slack?) and I will be making a more complete proposal and implementation
Thanks for the call out. Unfortunately my boards are still en route from China. Very excited to see this progress though!
A post was merged into an existing topic: IP over meshtastic kinda implemented
So, i‘have update my node, i‘hope he is connected … later i‘will update my mobil devices …
Great work! Thanks
i’get nice msg:
$SYS/broker/version mosquitto version 1.5.6
$SYS/broker/uptime 273676 seconds
$SYS/broker/clients/total 133
so, and now all devices updated
I have the MQTT feed pushing into Influxdb from NodeRed. all is well, but can anyone give me guidance on formating the lat/lon. eg. inserting a decimal point after the 1st two digits?
This is tangentially related, but as a Node Red user, do you know if/how to wrap the meshtastic python library up into a Node Red package, or if one already exists somewhere?
tried and failed on my end.
It is documented in mesh.proto and I’m away from my computer now but I think the rule is:
Multiply latitudeI by 1e-7 to get latitude (might be 1e-9 don’t remember). If you pick wrong the coords look obviously wrong.
(We use 32 bit ints to send our latlon because it gives less loss of precision than using floats - and doubles have lots of wasted space)
You may have better luck with the JS lib, as that’s what nodes written in anyway and has native support for.