Proposal: A new light weight config mode

[kartom]

The new HOMIE_CONFIG=0 flag offer the opportunity to completely remove the ESP webserver and save space. The drawback of this is that the device has to be reflashed to change the configuration if WiFi/MQTT connection fails due to a config misstake or that something has been altered in any of those (new wifi password for example).

I think it would be useful with a new configuration mode (selectable via compile flags?) that uses the MQTT protocol that is already supported so that we don´t need the webserver.

My idea of configuration mode goes something like this:

1. Start WiFi in AP-mode.
2. Wait for the first client to connect
3. Connect to an open MQTT broker on that client
4. Wait for an new configuration sent over MQTT.

By writing an Android app that contains an MQTT broker and a configuration interface it will be possible to access the configuration w.o. the need for much extra code. (Quick investigations gave that the AP-mode was rather lightweight).
My first test with Moquette as broker on Android was promising.

Does anybody think this would be useful?

[luebbe]

This would be very useful since it would even work without a companion app. E.g. any old netbook with lubuntu would do.

But:
The http json api is always there in config mode, so you can always send a config via curl -X PUT. So in princible your suggestion is not very different from what is possible now. I think the real problem is that homie never falls back to a config/AP mode if Wifi/MQTT connections fail for a while.

Would the following work?

1. Try to connect to wifi/mqtt with the currently know credentials
2. After N failures, open an AP so that a new configuration can be sent.
3. If nobody has connected to the AP (or no new config was received) for N minutes go back to 1.

[kartom]

If i use the HOMIE_CONFIG=0 and put that code onto a ESP8266 without a config file i get the following response:

✖ /homie/config.json doesn't exist
Configuration invalid. CONFIG MODE is disabled.

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3584, room 16
tail 0
chksum 0xb0
csum 0xb0
v2843a5ac
~ld

And then the device reboots and repeats itself so it doesn't seam that the http json api is available if i select HOMIE_CONFIG=0.

To get an Homie device into configuration mode could be solved by using Homie.reset() or Homie.setResetTrigger(). In my case i am using the Homie.setResetTrigger() on one of the physical buttons that are already connected to the device and used for other purposes as well. This way i can reset it and make it ready to accept a new configuration without the need for reprogramming of the device. It hasn't been used yet, but the day i'll have to change the WiFi password i think i will be most grateful for the feature.

But the original question and idea remains valid, would it be useful for anybody more than me to have the functionality described in the proposal?

[luebbe]

Yes, you're right, when the webserver is gone, there's no http api :)
And yes, I think your proposal sounds helpful. I always compile my projects without webserver.

[luebbe]

A lightweight config mode would have come handy for me already. Yesterday I flashed one of my devices using HOMIE_CONFIG=0 and didn't pay attention to the memory layout. Of course I lost the existing config :)
How is your progress?

[kleini]

If you compile with HOMIE_COMFIG=0, then there is no config mode compiled into the code. Furthermore in your case (@kartom) JSON configuration is missing. The device is then not able to open the access point and webserver, as this code is not compiled in and it does not have a configuration to connect to any access point. The only solution, that I found for this case, where the device is completely stuck, is to write the log message and do a reboot. Another possible option is to halt the device and do nothing any more.

[kartom]

The problem with HOMIE_CONFIG=0 is that there is no possible way to access the configuration of the device (other than direct flash).
My progress is slowly moving forward since a lot of other thins had required my attention, but my ambition is still to implement this idea.