Real Time Clock not initialised; rapid red LED

1

Hi Bob!

I’m about to start another Australian 3-phase install and tested my IotaWatt. It functions as expected, but I get a (very) rapid red LED, with no LED when I make web requests. The message log is below. Note “Real TIme Clock is not initialised”. You’ll see I then soft restarted and I get the normal pulsing red light.

I tested this on another IotaWatt (firmware 02_03_16) and got the same result, except the rapid red LED remains even after soft restart. These units are about 1.0 years old and 0.5 years old respectively.

I’ve tried: another power supply, deletelog=all command, check SD cards in a laptop, multiple soft restarts.

Perhaps the clock battery gone?

My question: Can I safely install these units, since they seem to operate ok?

Thanks,

Brett

Ps. This install will have complete circuit and supply CT coverage with a upstream 3 phase utility meter, so I will be able to cross-check results. It will be derived 3 phase.

** Restart **
SD initialized.
Real Time Clock not initialized.
Version 02_03_13
Reset reason: External System
Trace: 194:251[16], 240:71[128], 29:218[237], 31:250[76], 120:142[159], 232:159[28], 53:14[167], 129:174[142], 98:202[124], 244:227[88], 3:15[34], 241:75[11], 161:140[133], 113:3[158], 194:136[171], 43:86[213], 181:96[150], 208:16[170], 58:234[89], 117:66[118], 255:162[121], 146:34[17], 160:219[233], 193:234[59], 147:51[65], 158:252[154], 143:110[121], 49:254[204], 167:82[185], 22:200[31], 110:14[200], 167:102[41]
ESP8266 ChipID: 1848778
Local time zone: 10
device name: IotaWatt, version: 3
Connecting with WiFiManager.
MDNS responder started
You can now connect to http://IotaWatt.local
HTTP server started
timeSync: service started.
statService: started.
WiFi connected. SSID NetComm 0405, IP 10.1.1.3, channel 11, RSSI -68db
Updater: service started. Auto-update class is MINOR
dataLog: service started.
dataLog: Last history entry: 1536736020
Restart command received.

** Restart **

SD initialized.
Real Time Clock not initialized.
Version 02_03_13
Reset reason: Software/System restart
Trace: 1:2, 1:3, 1:4, 1:5[20], 1:6, 1:1[11], 1:2[12], 9:0[12], 9:0, 9:1, 8:2, 8:12, 8:0, 9:2, 1:2, 1:3, 1:4, 1:5[20], 1:6, 1:1[12], 1:2[13], 9:0[13], 9:0, 9:1, 8:2, 8:13, 8:0, 9:2, 1:2, 1:3, 10:2, 10:3
ESP8266 ChipID: 1848778
Local time zone: 10
device name: IotaWatt, version: 3
MDNS responder started
You can now connect to http://IotaWatt.local
HTTP server started
timeSync: service started.
statService: started.
WiFi connected. SSID NetComm 0405, IP 10.1.1.3, channel 11, RSSI -67db
Updater: service started. Auto-update class is MINOR
dataLog: service started.
dataLog: Last history entry: 1536736020

2

Two things cause the LED to glow red. No WiFi or no time. The IoTaWatt needs to know what time it is. A dead battery would cause it to lose the time after a power failure, but it would go to the internet for the time and run fine until the next power failure.

You need to have a decent internet connection to initialize the clock and check for updates. Just havingWiFi doesn’t do it. You need to be able to access a time server. I don’t know what kind of coverage you get down there, but others seem to be working.

If you believe there is an internet connection, try letting just one unit run for awhile to see if it can get the time. The timeserver pool does reject requests from an IP that issuesrequests too frequently.

3

Wifi is okay as I access it via the app, so it’s a time problem.

The internet connection is good and I’ve installed other Iotawatts without any problems, although not on this WiFi. The timesync service started, but how can I check it’s found a time (NTP) server? Maybe a firewall is blocking outgoing requests.

I’m letting it run now in case of IP address overload.

To test if it will work as is (still I need to install tomorrow) I’ve created a new EmonCMS account and am testing to see if I can get an input to log (just voltage at the moment). With default settings, I see the following (below). EmonCMS doesn’t see any inputs. Hence I think I need to fix the time problem first (?). Note weird date.

WiFi connected. > SSID NetComm 0405, IP 10.1.1.3, channel 11, RSSI -62db

Updater: service started. Auto-update class is MINOR
dataLog: service started.
dataLog: Last history entry: 1536736020
EmonService: started. url:emoncms.org:80,node:IotaWatt,interval:10, unsecure GET
EmonService: Node doesn’t yet exist.
EmonService: Start posting at 2/6/6 16:28:26

4

This is now resolved. Here’s what it I did:

  • Install new RTC battery (CR1220)
  • Use a different WiFi network temporarily (AP off a mobile phone)
  • Restart and let it timesync (see log)
  • Put back on original WiFi network

Log on new WiFi network:

statService: started.
WiFi connected. SSID=AndroidAP, IP=192.168.43.90, channel=6, RSSI -42db
Updater: service started. Auto-update class is MINOR
11/07/18 17:47:47 timeSync: RTC initalized to NTP time

I think what happened was the battery ran down (hence RTC was initially not running: they have been unplugged for several months). Then the timesync service couldn’t reach a NTP server (as per Bob’s suggestion). I couldn’t find any firewalls or issues with the WiFi, but it seems IotaWatt couldn’t reach NTP on this WIFi network. It reachs emoncms.org okay, but maybe on a different port.

So it’s okay, but I think time is not syncing: just running off the RTC. That’s not a huge problem, but how can I determine if this is the case: it seems the timesync service doesn’t throw an error when it can’t connect?

Thanks again for your assistance.

5

It will post a message if it fails to get NTP time after 24 hours.

The RTC can lose or gain as much as 2 seconds per day, and it varies with temperature. Seems to run slower in cold, faster in heat. That’s not a huge deal but extreme cases could add AP to a minute per month.

IoTaWatt uses pool.ntp.org. The protocol is UDP.

6

As a followup - these IotaWatts continue to work fine - the RTC is running and NTP syncing.

So replace the battery and restart if you have the same problem!

7

Hi again. Unfortunately this problem has appeared on two of the new IotaWatts I’m setting up. On each of these, the symptoms are the same as above. In brief:

  • Startup and config WiFi okay

  • Restart and get 3s off, 1s dull red flash

  • Check log and see:

    ** Restart **
    SD initialized.
    Real Time Clock not initialized.
    Version 02_03_18
    Reset reason: Software/System restart
    Trace: 20:6, 20:7, 20:8, 20:9, 20:91, 1:6, 1:1, 1:2, 9:0, 9:0, 8:4, 8:6, 8:8, 8:9, 1:2, 1:3, 1:4, 1:5[18], 18:0, 18:1, 1:6, 1:1, 1:2, 9:0, 9:0, 8:2, 8:0, 8:0, 1:2, 1:3, 10:2, 10:3
    ESP8266 ChipID: 6910366
    SPIFFS mounted.
    Local time zone: 0
    device name: IotaWatt, version: 3
    Connecting with WiFiManager.
    MDNS responder started for hostname IotaWatt
    LLMNR responder started for hostname IotaWatt
    HTTP server started
    timeSync: service started.
    statService: started.
    WiFi connected. SSID=NetComm 0405, IP=10.1.1.13, channel=1, RSSI -69db
    Updater: service started. Auto-update class is MINOR

Am I missing something silly? Should I just expect to replace batteries?

8

Do you have multiple IoTaWatt running at the same location?

9

Do you have multiple IoTaWatt running at the same location?

Yes, in this case I do as a test at home. I renamed the devices and the http://foo.local , http://bar.local works for me on Windows with Firefox.

I’m boring myself with these updates, but here it is: both IotaWatts are running fine. The RTC has started. After about a few hours plugged in I see in the logs:
Updater: Auto-update is current for class MINOR.
12/13/18 13:35:57 timeSync: RTC initalized to NTP time
12/13/18 13:35:57 dataLog: service started.
And I have the nice green light, and all is well. So my new solution is “RTC is not initialised” is:

  • Plug in for a few hours
  • Restart if necessary
  • If RTC still doesn’t start, replace the battery
10

I think I know what is going on. The IoTaWatt use a pool.ntp.org. The servers have restrictions on the frequency of requests,and when they get irritated by one particular IP doing a lot of requests they begin to respond with the “kiss-o-death” response. I run into that here from time to time.

The protocol is supposed to spread the requests across various servers in the area, but I have found that sometimes it gets the same one over and over and continues to issue the KOD.

Usually it gets another server after awhile and all’s well thereafter. In my area, it’s always the same server that gives me this trouble. So that seems to be what you are experiencing, and as you have found, waiting it out while annoying, can be effective.

There is a process to register firmware that uses the NTP pool, and I suppose I should do that. Maybe that would grease the skids.

11

New user here with the same issue. I was about to post trying to figure out why my graphs are all empty, but I’m guessing they require the actual time to build them :slight_smile:

Checked my log and sure enough, RTC not initializing. Is there anyway to specify another time server? I run my own on my firewall (pfsense) because I have so much stuff that syncs time.

-Rich H.

12

Solved my own problem, but not in the way I was expecting, and this is info that’s good for other users and a suggestion for a potential change in a future version.

I did a packet capture and saw that actually it was the DNS queries for pool.ntp.org that were failing at my own recursive DNS server. I didn’t have the netblock in the allow recursive section. Added, and now looks ok:

12/18/18 17:48:45z timeSync: RTC initalized to NTP time
12/18/18 17:48:46z dataLog: service started.
12/18/18 17:48:46z dataLog: New current log created.
12/18/18 17:48:47z Updater: Auto-update is current for class MINOR.

I didn’t realize this for over a yr with other machines/devices, as the 2nd DNS server my DHCP hands out was working for recursives, but iotawatt seems to only ever try the first DNS server. Might be good to support multiple DNS servers DHCP hands to iotawatt, in the event the first one is down.

13

Thanks for posting that resolution and I’m glad to see you up and running. All of the DNS activity in the ESP8266 is under the hood. The methods that I work with simply offer a way to get the IP for a given URL. That said, I’ll try to see if I can figure out what that failure mode looks like at my level, and if there are any other levers I can pull to get different DNS lookup behavior.