mirror of
https://github.com/jkingsman/Remote-Terminal-for-MeshCore.git
synced 2026-11-03 08:02:19 +01:00
Feature request: Create an integrated MQTT forwarder to letsmesh.net for integrated observing #11
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/Remote-Terminal-for-MeshCore#11
Reference in new issue
Block a user
Create an integrated MQTT forwarder that satisfies the requirements for letsmesh.net observers so companions/repeaters used with this distribution can also feed the analyzer.lestmesh.net
I like the features this distribution has but not at the expense of stopping my observer from feeding letsmesh.net. I would imagine other individuals would also appreciate being able to hit two birds with one hardware stone.
In reference to Issue #31.
I actually have a branch I'm banging on this with, and do have packets forwarding. I'm still debating on whether to mainline this or not; it's a LOT of code to emulate the way they're expecting packets, and I'm not sure if I want to support it in the codebase (but I'm leaning towards yes). Let me keep hammering on my branch and see if I can get this into a shape that I only cringe a little at when introducing it to the codebase. Will probably have something merged in the next few days, unless something goes sideways. Will keep you in the loop.
I'm in no rush, take your time. I perfectly understand this is all hobby stuff for us. I'm glad you're open to the idea and I think it would open up more people to using this if they can convert their observer hardware into doing both things.
Got bored during lunch, and it was less code than I thought. Give it a pull and lemme know what you think.
Hot-damn dude, I ran a pull and it's working! I'll leave things running on this to see if it's stable.
Awesome! I haven't let it run for longer than 24 hours which is when the JWT expiration/autorenew should fire, so if there's any spot that might have hiccups, that's a possibility. Just got my node set up to stream as well so I'll keep an eye out.
One thing I've noticed is the Observer Metrics stopped updating when I switched over. I'm guessing their collect is forwarding this data in addition to the actual network packets.
Correct; their collector is gonna be grabbing those straight from the radio I assume; ours is a simple mqtt reporting machine.
Well, I stand corrected; that is sent as mqtt traffic. Lemme dig into this deeper.
Okay, new code pushed up appears to fix the issue; I've got metrics reporting. Sorry about that!
I ran a pull and I show it now as working thanks!
As a side note before I repulled everything, the local instance wasn't showing new packets come in but it was still correctly feeding letsmesh.net. I'll let things run for a day and check back in to see if I see the same behavior. If I do I'll open a new issue # and try to collect log info.
Oh interesting, yeah def shoot me some logs if that happens again. It could have just been a flaky websocket connection, but I would expect that to resolve on refresh (which I assume it didn't). Feeding to letsmesh but not the ui is actually a very odd failure because the core processing logic forks off both the mqtt and websocket logic, so something going scuzzy at the processing level should affect everything.
Would be curious to know if the missing messages reappeared on refresh (websocket transport failed but persisted to db), restart (maybe websocket host failed? But also persisted to db), or not at all (something is hosed at the storage layer).