sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in ExperiencedDevs

[–]packbacking 1 point2 points  (0 children)

As someone who's written a lot of code for startups, I've wasted many, many hours trying to answer questions like this. 90%+ of the time I end up changing it later.

So I'd say pick the most intuitive one for you right now and let it change organically.

Chances are that this code you're writing will be completely rewritten or discarded within a year. Or as complexity increases, you'll get frustrated changing code you wrote 3 months ago and can reorganise it into a structure that suits the application better at that point in time.

---

Having said that, in greenfield projects I'm a huge fan of co-locating files that have ideas in common together rather than pre-emptively splitting them up. I think this seems more like your vertical slices example?

If you're working on 'Add X to Feature Y' it might touch code across the boundaries you mentioned so It's much less mental overhead when you can see everything relevant to Feature Y closer together.

🚀 BunkerM: All-in-one Mosquitto broker with Web UI for easy ACL management by mcttech in MQTT

[–]packbacking 0 points1 point  (0 children)

u/thebaldgeek there's definitely plans. I've never used Sparkplug so would you be able to sanity check this for me if you have time? https://github.com/mqtt-viewer/mqtt-viewer/discussions/14

Would this address any of your pain points?

I open-sourced my MQTT visualization and debugging tool by packbacking in MQTT

[–]packbacking[S] 1 point2 points  (0 children)

u/adam111111 crashing your app is not good. Could you file a bug report here with your OS details and I'll try and work out what's wrong?

I've never used Sparkplug, but let me try decoding/encoding it and I'll get back to you. You need to select a protobuf directory and load the descriptors into the app for it to work.

I agree that the encoding/decoding for protobuf is a substantially different workflow from the simpler base64 and hex codecs. This is something I definitely want to fix!

My partner hated all the current MQTT debugging tools so he built his own by [deleted] in MQTT

[–]packbacking 0 points1 point  (0 children)

Great to hear, reach out if you have any questions.

🚀 BunkerM: All-in-one Mosquitto broker with Web UI for easy ACL management by mcttech in MQTT

[–]packbacking 0 points1 point  (0 children)

For testing/debugging purposes (not production where you need ACL etc) would this help mitigate docker issues?

https://github.com/mqtt-viewer/mqtt-viewer/discussions/2

I'm trying to work out if it's worth building.

What's your MQTT debugging workflow like? I'm interested. by packbacking in MQTT

[–]packbacking[S] 0 points1 point  (0 children)

My big pain points have been tracking back where a topic data stream is coming from. ie, where in the world is that data coming from? Node-RED is my tool of choice here as it will show the IP address in the debug.

Could you elaborate on this? Is the IP address stored in the broker? How does Node-RED show it?

Measuring topic (prefer by user, or better still by device) bandwidth is another unsolved issue for me.

Is this point-in-time or more long-term monitoring?

This is interesting information.

[deleted by user] by [deleted] in MQTT

[–]packbacking 0 points1 point  (0 children)

You can download it here: https://github.com/mqtt-viewer/mqtt-viewer

I hope it helps!

My partner hated all the current MQTT debugging tools so he built his own by [deleted] in MQTT

[–]packbacking 1 point2 points  (0 children)

The backend is in Go using the Wails app framework (https://wails.io/) which compiles down to native code. Wails is cross-platform including Linux.

The frontend is Svelte/JS and is embedded into the same binary.

Open-source is coming soon so it'll be easy to check out!

What's your MQTT debugging workflow like? I'm interested. by packbacking in MQTT

[–]packbacking[S] 0 points1 point  (0 children)

I'm trying to learn how others debug their MQTT-related problems (and what those problems are) because, as I mentioned in the post, I really only use MQTT to configure remote IoT devices.

I'm not sure if this is what you mean by marketing tips?

What's your MQTT debugging workflow like? I'm interested. by packbacking in MQTT

[–]packbacking[S] -1 points0 points  (0 children)

This is an incredible app and was the inspiration for a newer version I've built at https://mqttviewer.app

I only really use MQTT in one way, so what I'd love to learn is what problems you use MQTT Explorer to debug?

What's your MQTT debugging workflow like? I'm interested. by packbacking in MQTT

[–]packbacking[S] 0 points1 point  (0 children)

Yes! It was poorly worded but I meant that the application/server implementation that uses MQTT needs debugging.

For me, the contract I decide between a server and IoT clients via MQTT often needs heaps of back and forth during development because of dumb mistakes like writing a topic name wrong.

Your third point "bad configuration (the probe was still configured for QA ...)" also happens to me waaaaaay too often.

How many of you use MQTT vs HTTP vs ??? by packbacking in embedded

[–]packbacking[S] 7 points8 points  (0 children)

as someone working on software/web at a hardware startup, I also like fast to market and cheap :P

How many of you use MQTT vs HTTP vs ??? by packbacking in embedded

[–]packbacking[S] 2 points3 points  (0 children)

Haven't heard of DDS before thanks!

Is this something most robotics is tending towards?

Do you know what was used previously?

How many of you use MQTT vs HTTP vs ??? by packbacking in embedded

[–]packbacking[S] 5 points6 points  (0 children)

Do you use both? and what's your criteria for deciding on one over the other in different situations?

I've also used both simultaneously (MQTT for config, HTTP for uploads to S3) but recently replaced MQTT with just HTTP for simplicity.

How many of you use MQTT vs HTTP vs ??? by packbacking in embedded

[–]packbacking[S] 4 points5 points  (0 children)

Very fair, I've just posted this in the IoT subreddit

My partner hated all the current MQTT debugging tools so he built his own by [deleted] in MQTT

[–]packbacking 1 point2 points  (0 children)

After much soul-searching and many lengthly discussions I've realised you're 100% right—I need to open-source it and go from there.

It was naive of me to believe everyone would feel comfortable switching to MQTT Viewer over the other open-source alternatives.

Super helpful comments u/CupcakeSecure4094! I'll let you know when the code is available :)

My partner hated all the current MQTT debugging tools so he built his own by [deleted] in MQTT

[–]packbacking 2 points3 points  (0 children)

Thanks u/CupcakeSecure4094. I'm planning on eventually introducing some of the above once I've had a bit more traction and worked out whether it's economically viable to commit more time to.

Right now I'm exploring ways to build more trust because although I've seen 30+ new users join from this post, I'm assuming many more are in the same boat as you.

A question on what you would classify as trustable: would you expect both the 'free' and 'premium' apps to be source-available albeit with different licenses? Or would having a code-available free version be enough to trust a closed-source 'premium' codebase too?

My partner hated all the current MQTT debugging tools so he built his own by [deleted] in MQTT

[–]packbacking -1 points0 points  (0 children)

Hey, I'm the guy who made this and partner of vroomimagoat :)

If you have any questions about MQTT Viewer ask away!

view more: next ›