After exploring how MQTT integrates with IoTaWatt, I’ve moved doing anything with it pretty far down the list. MQTT is a transport mechanism that is used to support higher level communications. While the simple use case of sending a value may seem a standard use, it’s of little value in the primary mission of IoTaWatt. HTTP is a much more robust protocol and more importantly, all of the intended clients and servers (Browsers, Emoncms, influxDB) have native support.
Beyond lack of utility, there are major issues with adding MQTT:
- Increased code and heap space for the supporting code.
- There is no embedded support in the ESP8266SDK so would rely on another package. The most popular has quite a few issues outstanding.
- Without a higher level layer, there is no provision for time stamping.
- Message delivery beyond the broker is not certain or acknowledged without a higher level protocol layered on.
- Without TLS or SSL, there is no authorization mechanism.
It all goes to product philosophy. I realize that there are some energy monitors out there that try to do it all. I’ve tried to keep the IoTaWatt function more narrowly focused and concentrate on ease of use, reliability, low-maintenance, and full-function within the capabilities that are supported.
If MQTT turns out to have a lot of value (by that I mean some very useful capability that cannot be supported without it), I’d be happy to work with someone to provide a secure feed to an external (RPi, ESP32) capability.