Do not require SSID on ESP32

[iBobik]

I can use a wifimanager or Ethernet interface, but MQTT client requires to configure wifi in it's config.

It should be optional even on ESP32.

[peterhinch]

The principal purpose of "resilient" MQTT is to handle WiFi outages which is why it expects to control taking down and re-instating WiFi. If you have a guaranteed network connection such as a wired interface a radically simplified client could be devised which merely rectified the inadequacies of the official clients. In such an environment TCP/IP will do much of the hard work for you, leaving only the problem of server outages.

I think the right approach would be to write an asynchronous client based on a fixed "robust" client and merely taking the nonblocking socket handling from this client.

The task of modifying the "resilient" client would probably be harder than doing this and would lead to needless bloat.

[iBobik]

I already use your "mqtt_as.py Asynchronous version of umqtt.robust".

[peterhinch]

I gathered that. But my comments still stand: a substantial part of the complexity of the code is there because WiFi doesn't provide the guaranteed packet delivery of TCP/IP. The characteristics of radio communication make this impossible. With a wired connection you have that guarantee. This means that much of mqtt_as would be redundant.

I believe that the correct solution to an asynchronous MQTT client for a wired network would be to write one, rather than to add to the complexity of this existing solution. Such a rewrite would be simpler and more lightweight than mqtt_as.

[iBobik]

I need client what works with wifimanager and allow use of Ethernet.

mqtt_as works well, I just need to stop it mess up with a WiFi configuration.

Could I send PR what will make SSID optional like on ESP8266?

Jan Pobořil https://honza.poboril.cz/

7. 10. 2020 v 8:38, Peter Hinch notifications@github.com:

 I gathered that. But my comments still stand: a substantial part of the complexity of the code is there because WiFi doesn't provide the guaranteed packet delivery of TCP/IP. The characteristics of radio communication make this impossible. With a wired connection you have that guarantee. This means that much of mqtt_as would be redundant.

I believe that the correct solution to an asynchronous MQTT client for a wired network would be to write one, rather than to add to the complexity of this existing solution. Such a rewrite would be simpler and more lightweight than mqtt_as.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[kevinkk525]

Just use your own fork. I need some different functionality too (like unsubscribe) so I use my own fork in my projects.

[iBobik]

Why not to make ssid optional on all boards? It will simplify your code. I would make a pull request.

Jan Pobořil https://honza.poboril.cz/

7. 10. 2020 v 11:28, Kevin Köck notifications@github.com:

 Just use your own fork. I need some different functionality too (like unsubscribe) so I use my own fork in my projects.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[peterhinch]

I have explained my reasons.

It will simplify your code.

I doubt that very much if WiFi resilience is to be maintained. I have pointed out that this is a fundamental principle of the module. Kevin and I spent a considerable amount of effort in achieving resilience and I don't believe significant code savings are possible without compromising this.

There is a further reason: proving WiFi resilience is extremely time consuming. I have no intention to introduce code which alters the connection and disconnection process because this would require a repeat of that testing. Sorry, but this simply isn't going to happen.

As Kevin has suggested, you could maintain your own fork. Since you have no need of the resilience feature you would not need to test this aspect.

[iBobik]

Thank you for explanation. Just one question :-)

I've changed condition to behave on ESP32 the same like on ESP8266:

    async def wifi_connect(self):
        s = self._sta_if
        if ESP8266 or ESP32:
            if s.isconnected():  # 1st attempt, already connected.
                return

Do you know about some issues what I should expect on ESP32? (Where ESP32 behaves differently than ESP8266.) Or this branch is there only for ESP8266 just because nobody tested it with ESP32?

[peterhinch]

The module has been extensively tested on ESP8266, ESP32 and Pyboard D.

ESP8266 and ESP32 behave entirely differently in regard to WiFi connection. ESP8266 automatically stores WiFi credentials in Flash. So if you power up an ESP8266 it will automatically attempt to reconnect to its last network. This was considered a security risk in the industry, and ESP32 does not do this. Nor does the Pyboard D.

However, given that the ESP8266 does store credentials in Flash, it is best to let it try to automatically reconnect if it can. This is because if you supply explicit credentials, it writes them to Flash causing flash wear.

Hence the different treatment.

[kevinkk525]

Look at my fork for some ideas without wifi control because I implemented Unix port support which does not have any network control.

[iBobik]

Thank you both!

Jan Pobořil

On 8 Oct 2020 at 11:23:22, Kevin Köck notifications@github.com wrote:

Look at my fork for some ideas without wifi control because I implemented Unix port support which does not have any network control.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/peterhinch/micropython-mqtt/issues/45#issuecomment-705446139, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEV6WEUBR7POIYIJUESU3LSJWAIVANCNFSM4SE556DA .