Ask HN: Using WebSockets instead of mqtt for IoT | Hacker News Reader

Ask HN: Using WebSockets instead of mqtt for IoT

2 pointswillemmerson5 comments

I recently worked on a personal project where I wanted to connect multiple ESP32's to a web app. Previously I've used mqtt to do this and also done this in several work projects, but I decided to try something different and use websockets as ESP-IDF has a websocket client. It worked really well and ended up in a much simpler setup, I didn't need an mqtt broker or a long running process listening to the broker, which meant it was much easier to deploy. Previously I'd had to create a CA and generate self-signed certificates for each device, but with websockets this doesn't seem necessary and is handled transparently by the webserver.

A few other advantages are: - it can have actual end-to-end confirmation, unlike MQTT which is only between client and broker - port 443 won't be blocked - much easier to develop and test locally

So my question is, is anyone else doing this at scale, is there something I haven't thought of?

There might be some issues with web sockets over a cellular connection. I'm no expert, but I've read that historically there are issues there. This might not be the case anymore though.

I like the idea of using Websockets for IoT devices if you just need a simple communication mechanism.

I wouldn't do it at scale. Message brokers are battle-hardened for messages at scale, have multiple communication styles, especially pub/sub. They are built for messages at scale.

My interest in Websockets is the same as yours — fewer components (no MQTT server). Works well for a simple message flow and I'm ok with reenventing pub/sub for a small number of devices.

You might be right about scale, but web servers already handle huge amounts of websockets, and already have complicated pub/sub schemes - think about a chat room for instance. I am using Django Channels which lets you define groups that other channels can subscribe to, and I'm sure other web frameworks have similar things. It seems easier to use than MQTT topics because it's all there right inside your webapp and DB, not on a seperate MQTT broker, this is the main thing that's attracting me to the idea.

If a client is offline I guess it will never get messages that were sent in that time, I think this might be something that MQTT solves?

MQTT does solve this by storing messages on the broker but you can just store messages in your database instead and send them when the client connects, and personally I think this is easier.

Reply on news.ycombinator.com