tribute to micropython community

[mekanixms]

Hi!

I plan on sharing this project with everybody for more than a year now but ... too short on time!

This would be my take on a IoT platform (for ESP32) with multiple peripherals, communication (mqtt, espnow or http for config only).
Programming is a hobby to me, I am not a professional: do not expect wonders. Moreover, most of my life I did C, php, and Java so ... sometime I am far from being a good python-eer. Would appreciate your feedback on what to do to improve, both my skills and these scripts
Some of the scripts may be basic but my point was to make them functional.

https://github.com/mekanixms/mqHome

This is my way to say Thank you to the micropython developers and this community

[peterhinch]

I notice the MQTT implementation is based on the official library. Are you aware of these issues with it? The official library also does nothing to address the keepalive mechanism of the MQTT protocol, which really requires a background task or thread.

I haven't had time to study your code in detail, but I wondered how far you'd gone in addressing these issues.

[mekanixms]

I rely on the mqttht driver, in a watering and a heating application, and is stable, running for more than a year now.
For stability is very important the mqtt server to have user and password set otherwise it disconnects randomly.

The most stable version of the mqtt drivers is mqttht, which is an implementation where I use a hardware timer for the loop.

I have written mqtta, another version of mqtt driver, works pretty well too but being based on a thread for the main loop, sometimes has some errors, i guess due to memory limitations. This is to be used only if all hardware timers are used in other purposes.

I had in plan to write another version with your library, async, but I could never commit too much time to it because the mqttht and mqtta cover my needs for now.

[peterhinch]

I'd be interested to hear how it copes with outages. In developing mqtt-as we spent a lot of time testing its ability to recover from outages of WiFi and broker, also testing under conditions where WiFi reception was marginal. Achieving and proving resilience was the hardest task in developing this.

Do you support subscribe-only clients and the keepalive mechanism?

You might like to read this short doc which encompasses my ideas for a future MQTT client. tl;dr I think a new client with a radical rewrite would be good.

You might also be interested in this repo which I think serves a similar purpose to your library. Its author, Kevin Köck, was a substantial contributor to mqtt-as.

[mekanixms]

Given that I use mqtt as a communication driver and I have to account for the limited resources, so I can add/use other peripherals, I had to design my mqttht class in a minimalistic manner: short messages and with low frequency.
I considered that the only straight forward approach at hand is to use a hardware timer, set at 100 ms, to execute the loop function (in my case run method, below, of the mqttht class). If there is something to be guaranteed to work all the time is a hardware timer....

In this method I check for messages and, in case of an OSError I try and reconnect + subscribe to my desired topics (while netutils.waitForNetUp() and netutils.waitForNetServiceUp())

Keepalive is set to off when mqtt instance is created - the timer loop automatically reconnects if needed

    def run(self, t):
        try:
            self.mqttInstance.check_msg()
        except MQTTException as err:
            print("\n\n")
            print("Mqtt Exception")
            print(err)
            print("\n\n")

        except OSError as e:
            print("\n\n")
            print("OSError Exception")
            print(e)
            print(ujson.dumps(dir(e)))
            print("\n\n")

            netutils.waitForNetUp()

            if not self.isconnected():
                if conf.mosquitto_reconnect:
                    netutils.waitForNetServiceUp(
                        conf.mosquitto_server, conf.mosquitto_port)
                    try:
                        self.mqttInstance.connect(False)
                        self.subscribe()
                    except Exception as e:
                        print("Could not reconnect")
                        print(e)

[mekanixms]

You might like to read this short doc which encompasses my ideas for a future MQTT client. tl;dr I think a new client with a radical rewrite would be good.

Yes, I agree a rewrite is needed and indeed many improvements are needed but do not think this is going to get real because it seems there is not much incentive to make ESP32 platform too competitive

One other nice addition would be to have virtual timers as well, they are damn good to have...