Remix clone Hacker News

In addition to cloud connectivity, we've been using MQTT for IPC in our Linux IIoT gateways and touchscreen terminals and honestly it's been one of the better architectural decisions we've made. Implementing new components for specific customer use cases could not be easier and the component can be easily placed on the hardware or on cloud servers wherever it fits best.

I don't see how gRPC could be any worse than that.

(The previous iteration before MQTT used HTTP polling and callbacks worked on top of an SSH reverse tunnel abomination. Using MQTT for IPC was kind of an afterthought. The SSH Cthulhu is still in use for everyday remote management because you cannot do Ansible over MQTT, but we're slowly replacing it with Wireguard. I gotta admit that out of all VPN technologies we've experimented with, SSH transport has been the most reliable one in various hostile firewalled environments.)

▲

goalieca 5 days ago | parent | next [-]

MQTT also lends itself to async very well. The event based approach is a real winner.

▲

DanielHB 5 days ago | parent | prev [-]

Trying to understand an existing IoT codebase is scarier than reading Lovecraft.

Out of curiosity, why were you using SSH reverse tunnel for IPC? Were you using virtualization inside your iot device and for some reason need a tunnel between the guests?

▲

anilakar 4 days ago | parent [-]

Reverse tunnel SSH was used for remote management. Once we replaced it with MQTT, we realized we could use it for IPC, too. I was not too clear about this in the post above.

Before MQTT we used whatever we had at hand; the touchscreen frontend (that ran Qt, not an embedded browser) talked to the local backend with HTTP. SMS messages were first sent to another local HTTP gateway and then via UNIX shm to a master process that templated the message to the smstools3 spool directory. A customer-facing remote management GUI ran on the device's built-in HTTP server but I no longer remember how it interfaced with the rest of the system. The touchscreen GUI might actually have had its own HTTP server for that, because it also handled Modbus communication to external I/O.

This was back in the day when everyone was building their own IoT platforms and obviously we were required to dogfood our own product, trying to make it do things it was never meant for. The gateway was originally designed to be an easy solution for AV integrators to remotely manage whole campuses from a single GUI. I'm pretty sure no customer ever wrote a line of code on the platform.

	▲	DanielHB 18 hours ago \| parent [-]
		Ah okay, that makes more sense. We used wireguard for remote management and we never got into MQTT (I wish we had).