bwc not starting if there is a problem with wifi

[davidmardanielsson]

Hi.

First, thanks for this brilliant solution. Works really well.

I have the Lazy spa Helsinki and I'm running it 24/7 the whole year. It is located in the countryside of Iceland (actually near a glacier) and I've had issues with the electricity going out a few times. The house is a couple of hours away and I've needed to rely on my neighbour to start the pump again. Therefore this solution works quite well in that case since it offers to turn on the pump with the same configuration as before.

I was testing a new wifi connection and I noticed that if I turn on the pump and the wifi doesn't work correctly, the pump itself doesn't turn on. In setup(), it starts with starting the wifi and ends with starting the bwc.
For me I would like to eliminate the need to actually depend on the wifi, but if the wifi is available it would be used.
So I was thinking if there would be anything wrong with doing the bwc.begin() before starting the wifi?

Thanks!

David

[visualapproach]

Hi David! Sounds nice to live by a glacier with a hot tub! Maybe post something here ;-) : #13
I understand your need for wifi independence. The reason wifi.begin() is before bwc.begin() is that the command queue, and therefore the whole program, is depending on the NTP to get the correct time. In principle it's not a problem. In practice there is some more changes needed to make it work. For instance, you can't have the autoportal since it's blocking the program from running. There was a version out there that didn't block, but I didn't get it to work.
I'll look into it and will report here if/when it's done.
/Thomas

[davidmardanielsson]

Nice, I will definitely post something to #13. It has been on my list to build some structure around the tub, mainly to insulate it and those photos are definitely an inspiration.

Ok, so I was going through the code. With the goal of making sure that the pump is started before attempting to initialize the wifi I was thinking if the following makes sense. In setup(), start with setting the clock to some value (a date in the past). Run bwc.begin() where the startNTP() has been split out into an initialize() function which will be run later. Then run bwc.loop one time.

So:

time_t rtc = 1510592825;
timeval tv = { rtc, 0 };
settimeofday(&tv, nullptr);
bwc.begin(); // Does not contain the _startNTP()
bwc.loop(); 
startWiFi();
startOTA();
startServer();
startWebSocket();
bwc.initialize(); // Contains the _startNTP()

Will this start up the pump?

After this in setup() the startWIFI() and the rest can be run and end with bwc.initialize(); which is basically the NTP and related.

As mentioned, my main concern is after some power failure the wifi might be in a bad state and for me it is most important that the spa is started up with the default configuration before doing anything else.

Maybe another option would be to create another function which would send the power / heater / pump commands explicitly?

I just want to find a clean way to do this because I don't have the means to debug this.

Thanks!

David.

[visualapproach]

I can't tell without testing. I'm working on a fix and will be reporting back

[davidmardanielsson]

Amazing, thanks!

[visualapproach]

@davidmardanielsson Hey, I updated the development version. I don't know if you can push updates to the glacier from home, but I suggest you test this version before trusting it 100%. I'm running it on my hot tub now and it seems to work as planned, but you'll never know. I tested to turn off wifi for a while and it worked. When I turned on wifi it reconnected fine. See "changelog.txt" file for more info.
Please report how it works for you. If OK I will pull this version to master.

[visualapproach]

Ok I suggest you install the master branch again and I will investigate further. Sorry it didn't work

[davidmardanielsson]

But suddenly I can connect to it now and the web UI is working. But the DSP is still off.

Ok. I'll do that. I would probably want to setup a remote serial console, using a 8266 so I can see what is going. I'll do that next weekend.

Is your setup working with the dev branch?

Thanks!

[visualapproach]

Nope, It's a b*tch to get it to connect after a first failed try. Hope to get it working until your next trip...

[visualapproach]

I found out that the autoportal was stopping the device from reconnecting if it didn't find wifi at start-up. I think it's sorted out now. I've tested to restart the pump with no wifi, and it resumes last states and when I turned on the wifi again, it reconnected fine. (Actually I blacklisted the device in my router temporarily but I hope it's a valid test)

New test procedure for you would be:
Update with dev-version.
Let the device run until the display shows the current temperature without blinking.
Change unit, or pump state or heater state. Then change it to whatever setting you would like it to have. (ESP saves the setting upon something changing)
disconnect wifi and restart pump.
It should now be responsive and restore the last states.
turn on wifi and verify that it connects again.

[davidmardanielsson]

Thanks! I'll test it next weekend.

[davidmardanielsson]

Hi Thomas.

One question. The power went out and kind of as expected the pump wouldn't turn on. I suspect that it was my wifi that was too slow to turn on. But I was able to log in to my router and see that there was an IP there that was related to the ESP. So it actually got a DHCP lease and the device name on my router for this IP is ESP-1BB310. I had seen it before but I always used the other IP address that actually did have an open port 80 which was named BW_2.0. But this IP (ESP-1BB310) doesn't have any port open (at least not 80 or 81).

So I'm wondering why the ESP gets two IP addresses and two leases and what this other IP is used for. And also, can I somehow use this IP to access the ESP?

[visualapproach]

Yes I understand that. Since you were leaving the hut I thought it would be best to use the stable master version instead of the not finished test in the dev. But the "work without WiFi" feat is only in the dev branch. When it's good enough I'll push it to master. So you should try the development version now if your up (out?) there.

[davidmardanielsson]

Yep! I'm there for the next few days. Will try dev. Thanks

[visualapproach]

NP, sorry to confuse you

[visualapproach]

Hi again. The "temp"-branch is now another option to test if you want. It's designed to work without wifi as well, but you just have to edit the file "config.h" and change line 53 to
const bool enableWmApFallback = false;
to stop the blocking autoportal from running. You need to have had the ESP connected to WiFi with your credentials before you edit that line and upload. Don't forget to upload the filesystem also.

You don't have to try that branch of course, I just mention it in case you'd like the new web interface by @torei or just want to help out testing.

[torei]

@visualapproach sorry to correct you. @davidmardanielsson you just have to upload the filesystem and flash the temp branch. on the first startup, even if you set enableWmApFallback=false, the WiFi manager starts and asks you for your local WiFi credentials. :-)
or you could set your local WiFi credentials in the config as well. then it will try to connect with these instead of starting any AP.

would be nice to have that branch tested, by the way :-)