IotaWatt stoped monitoring after wi-fi disconnect


Hi all:

From my understanding, if the IotaWatt losses the wi-fi signal it would continue monitoring power and saving it in the SD card.

I have some questions:
Will the unit upload data to influx once the wifi connection is restored? (Just trying to confirm)
If the backlog is large, how will data be uploaded? At what rate?
Why could the unit stop saving data when the wifi connection is lost?

Here’s the relevant info about this case:

Last data points are on November 20 at 17:27:30. From the CSV output:

2018-11-20 17:27:20, 1078.7
2018-11-20 17:27:25, 1086.8
2018-11-20 17:27:30, 1090.3
2018-11-20 17:27:35, null
2018-11-20 17:27:40, null
2018-11-20 17:27:45, null

Data started getting logged again on November 26, 16:30:10, once the wifi access point was restored and the IotaWatt reset.

2018-11-26 16:30:00, null
2018-11-26 16:30:05, null
2018-11-26 16:30:10, 1271.2
2018-11-26 16:30:15, 1284.8
2018-11-26 16:30:20, 1280.1

The message log shows the wifi disconnection on November 20 at 17:27:31 so it makes sense, but again, I would expect logging to continue with no wifi. The log also shows the unit reset a few minutes before:

11/20/18 22:04:54z Reset reason: Exception

(This is 17:04:54 local time.)

I’m adding a short version of the log file.

iotalog.txt (15.4 KB)

Thanks a lot!



Yes, it will upload after WiFi isrestored.
If the backlog is large, it will use larger buffers, more than bulk load, to send more measurements in each post. The rate depends on the number of measurements in each interval, as well as other factors like transmission time and how fast influx responds.

I looked at your log, and I’m not exactly sure what happened. Clearly there was some WiFi drop off. The first event recovered ok, and it kept logging. Then there was an exception. I have seen this before. It happens in some low level esp8266 code after a WiFi failure. It’s usually not a big deal because the unit restarts and moves on.

In your case, for some unknown reason, it spent six days in the WiFi manager code, and then It apparently resolved without a restart. I think there’s more to the story because there was a power cycle a few minutes later.

Nevertheless, this is all definitely WiFi related and in the core or other included code. I believe you have some other units running there as well. If so, what do their logs show for that period?

You are using 02_03_16. The latest general release is 02_03_18, which has newer versions of the core and some of the underlying support code. The newer release has been very solid, and if you look at the forum support topic, there have been very few problems with it. The ESP folks have been working on the newer lwip2 and it’s getting very solid. So I’d encourage you to set auto-update to MINOR and keep current with the improvements.


Thanks for replying. So far, we’ve updated the version now.

Sorry. I should probably have given a few more details. Here they are:

At some time on 11/20 power to the access point, EMILab, was removed (without a warning)
At some time on 11/26 we restored power to the access point, maybe just before 17:30.
At 17:37 we power cycled the IotaWatt. The LED was solid-red before this.

Thanks again.



Hi Carlos,

I got a similar problem reported today, and I want to follow up on something came out of that report. Was the device that you used to configure the IoTaWatt within wifi range when the power went off? I’m looking at a scenario where the IoTaWatt comes back up in AP mode before the WiFi router. Then the device that was originally used to connect to the IoTaWatt AP, which might ordinarily wait to connect to the WiFi router, instead connects to the IoTaWatt because it’s available and the WiFi is not. They remain connected indefinitely until something else happens to break them up. Is that a possibility in your case?


That’s a very interesting case.

If you mean when the Iota was power cycled, then yes. But that’s when things started going well again because the access point was working already.

The whole thing was as follows. Iota was logging and AP was working

  1. At some time on the 20th power to the AP was removed

  2. At 17:04 on the 20th there was an Exception Reset

  3. At 18:27:34 on the 20th there was a Software/System restart because “WiFi disconnected more than 60 minutes”

  4. The Iota got stuck on 11/20/18 18:27:38 Connecting with WiFiManager.

  5. Next message in log is: 11/26/18 17:30:04 No WiFi connection.
    This is, apparently, when the AP was powered again.
    Note that the device (laptop) for configuring the Iota was probably within range at this point.

  6. The laptop’s wifi was connected to the AP to check for internet access

  7. Tried to access the Iota from the laptop without success (LED was red)

  8. Power cycled the Iota and green led was blinking rapidly (wifi connected)

  9. Searched for the Iota in the network (we can’t use http://Iota3.local, so we use Bonjour software)

  10. Found the Iota, with a different IP than before, btw.


I mean on the 20th, when power to the router (when I say AP I mean the IoTaWatt in AP mode for configuration) was removed, and more specifically at 18:27:38 when the IoTaWatt was trying to connect with WiFi Manager - was that laptop or any other device that might have been previously connected to the Iotaxxxxxx SSID in the vicinity.

When the IoTaWatt starts up, if it cannot see the configured SSID that it uses to connect to a local network router in STAtion mode, it will activate AP mode as SSID Iotannnnn so that the user can connect to it and configure a different network. If the original local network becomes available before you connect to the AP, it’s supposed to make that connection, stop the AP mode, and move on. What happens if it makes a connection before the local network becomes available is the case I’m exploring. It’s possible it just hangs there waiting for a dialogue to configure a new network.

There are a few hundred issues outstanding against the WiFi Manager package. I sympathize with the author because there are so many different routers and clients out there it’s probably impossible to test. I think he may have lost interest in keeping up with this fast changing environment as well. I have elevated the priority of making an alternative.

Most clients rely on DHCP (Dynamic Host Configuration Protocol) to get their IP address assigned by the router. A client can try to use a fixed IP, but if it conflicts with the DHCP pool, there could be a conflict. If you would like your IoTaWatt to have a fixed IP address (which is handy when accessing from the internet), then you would need to configure whatever facility your router offers to fix it’s IP assignment based on the MAC address.


No. Not a chance. The Iotas are only used by us involved in the project and we’re usually like 400 ft away from that particular IotaWatt.

As for the problem you’re investigating, if we find something we’ll let you know. That’s a very interesting problem and in hindsight something we probably faced before while doing some early tests, when we would sometimes plug and unplug the IotaWatts several times a day and also change routers.

Yeah, we’ve been using DHCP in all of out units, but I don’t recall any of them changing their IP just because the wifi was down, and we use the same DHCP server for all of our network. Anyway, I though that could possibly be related to the issue. Guess it’s not.


Could be. Might indicate something weird happened to the router, or could just be business as usual. I’ve already put in changes so that it only invokes WiFi Manager after a power fail restart. That fixes a known problem and maybe helps this issue as well because it will not invoke WiFi Manager after a “WiFi disconnected more than 60 minutes” restart. Every little bit helps.


Hi: I’m adding here two logs; just in case they’re of any help.

Iota 3 minilog.txt (3.4 KB)

Iota 4 minilog.txt (3.2 KB)

Since we’ve been having access (wifi/internet) problems with the IotaWatt that stopped logging data (Iota3) we decided to set up another unit next to this one. The access problems have been always present, but we wanted to correlate setting up this second unit (Iota4).

We just had a disconnect issue today (12/13) and we couldn’t access neither unit from our cubes. The Iotas are on a different subnetwork and we believe there’s network connectivity access from there (hence the failed Influx posts; the Influx server is in our cubes) but there’s also the WiFi disconnections.

Since I really don’t understand most of the messages in the log, you’ll know more of what happened.

Consider that both units were restarted early today for a time zone change (from -5 to -6) we had neglected since the end of DST… Also, the LED in both units was blinking green at the time we went to check them at about 14:30… but there was no internet access (connecting from a laptop to EMILab AP); although access was intermitent. Also, at one point both Iota4 and laptop could be reached from out cubes, but not Iota3, so we restarted it (that’s the restart at 14:35:39).




The new release in ALPHA has DST support. Also, it’s not necessary to restart to change time zone. Actually, except for the new PVoutput support, all of the internal timing is done with UTC except for the message log which is converted to local-time.

blinking green means it’s sampling, and also that it believes it is connected to WiFi. It would blink red if sampling but not connected to WiFi. In either case, the sampling is being recorded in the datalog, as appears to be the case here. All of the data backlog should have gone to influx when the connection was re-established.

HTTcode -4 means that a connection could not be established. It is possible that you have something interfering with your WiFi. I can see that both IoTa has problems at ~12:31 and again at ~13:14 where Iota4 was disconnected and Iota3 simply failed to connect.

I’d suggest you try using different Wifi channels. That is set in your router. Conventional wisdom recommends 1, 6 and 11. (you are on 9). It might be as simple as that.