New alpha 1.2.25 to test the MQTT gateway feature

Should be bundled with the device firmware within the next few releases, well that’s the goal anyway

5 Likes

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.

1 Like

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.
Un_encrypt

1 Like

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?

1 Like

Scrolling through a message would be a good feature! Alas no code there yet for that.

1 Like

There is a feature request logged here

2 Likes

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?

1 Like

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 :wink:

1 Like

Thanks for the call out. Unfortunately my boards are still en route from China. Very excited to see this progress though!

1 Like

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

1 Like

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?

2 Likes

2 Likes

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?

2 Likes

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.

1 Like