4 ms·

> The drawbacks include the fact that if you want to configure it you always have to be on the same LAN and figure out its IP or port-forward, but if you port-f

> The drawbacks include the fact that if you want to configure it you always have to be on the same LAN and figure out its IP or port-forward, but if you port-forward, it will be not very secure due to the attack surface of the mini web server. But MQTT suffers from all of these same drawbacks, does it not? (MQTT is a TCP based protocol, and will thus suffer the same issues w/ NAT, and has no security aside from "can be run over TLS" (which I frankly think is okay / the point of layers of abstraction / I would not encourage re-inventing the TLS wheel; my point is only that MQTT and HTTP are in the same boat, AFAICT.)) > Moreover, it's not very elegant for you or others to programmatically control it. I would think the ecosystem for HTTP vastly outstrips that of MQTT's…

Scaevolus 9y ago
No. With MQTT, the client device makes a connection to some external MQTT server-- AWS, GCP, and Azure all have IoT bridges that speak MQTT. There's often an equivalent service over HTTP/1.1, where devices occasionally poll a remote endpoint for commands and to update state-- but without the persistent connection, you can't do realtime commands.
- gh02t 9y ago
  > AWS, GCP, and Azure all have IoT bridges that speak MQTT. Also worth noting for the curious that it's very easy to host your own, e.g. via Mosquitto.
deleted 9y ago
[deleted]
jimmies 9y ago
>But MQTT suffers from all of these same drawbacks, does it not? Your MQTT IoT device is a client, not a server, so you don't need to deal with no NAT. Even if you're outdated and has security problems, as long as the server doesn't exploit you (and filters out the requests that exploit you), then you're safe. It's really hard achieve that with an outdated HTTP server.