timeSync: No time update in last 24 hours

I’m currently on Firmware version: 02_05_11 (after an automatic update some weeks ago), and am concerned about some error messages I’m seeing in iotamsgs.txt. Particularly those related to the updater web connection and time syncing. Here’s an extract from the most recent part of this file:

SD initialized.
11/17/20 11:49:25z Real Time Clock is running. Unix time 1605613765
11/17/20 11:49:25z Power failure detected.
11/17/20 11:49:25z Reset reason: Power on
11/17/20 11:49:25z ESP8266 ChipID: 3155632
11/17/20 11:49:25z IoTaWatt 4.x, Firmware version 02_05_11
11/17/20 11:49:25z SPIFFS mounted.
11/17/20 21:49:25 Local time zone: +10:00
11/17/20 21:49:25 device name: WattsOn
11/17/20 21:49:28 Connecting with WiFiManager.
11/17/20 21:49:31 HTTP server started
11/17/20 21:49:31 WiFi connected. SSID=WattsOn001, IP=, channel=12, RSSI -64db
11/17/20 21:49:31 MDNS responder started for hostname WattsOn
11/17/20 21:49:31 LLMNR responder started for hostname WattsOn
11/17/20 21:49:31 timeSync: service started.
11/17/20 21:49:34 statService: started.
11/17/20 21:49:34 Updater: service started. Auto-update class is MINOR
11/17/20 21:49:34 dataLog: service started.
11/17/20 21:49:34 dataLog: Last log entry 11/17/20 21:46:20
11/17/20 21:49:34 historyLog: service started.
11/17/20 21:49:34 historyLog: Last log entry 11/17/20 21:46:00
11/17/20 21:49:36 Updater: Invalid response from server. HTTPcode: 302
11/18/20 21:50:19 timeSync: No time update in last 24 hours.
11/19/20 21:51:08 timeSync: No time update in last 24 hours.
11/20/20 21:51:59 timeSync: No time update in last 24 hours.
11/21/20 21:52:52 timeSync: No time update in last 24 hours.
11/22/20 21:53:40 timeSync: No time update in last 24 hours.
11/23/20 21:54:30 timeSync: No time update in last 24 hours.
11/24/20 15:05:17 WiFi disconnected.
11/24/20 15:07:33 WiFi connected. SSID=WattsOn001, IP=, channel=12, RSSI -67db
11/24/20 21:55:00 timeSync: No time update in last 24 hours.
11/25/20 21:55:48 timeSync: No time update in last 24 hours.
11/26/20 21:56:36 timeSync: No time update in last 24 hours.
11/27/20 21:57:27 timeSync: No time update in last 24 hours.

The two items of particular concern are:
Updater: Invalid response from server. HTTPcode: 302
timeSync: No time update in last 24 hours

Can anyone point me in the right direction for what to check/test to resolve these issues?

On a (possibly) related issue, can anyone explain why the time server time1.google.com is hard-coded, which seems to require some extra steps to get a ‘random’ time-server, when the commonly recommended NTP server is pool.ntp.org, which automatically assigns a random server for each NTP request?


Pool.ntp.org is a loosely organized volunteer network of NTP hosts. IoTaWatt is currently running in more than 50 countries worldwide, and had mixed results in many of those places when using it.

Because the servers are typically not dedicated and sometimes not particularly powerful, the software that they run rejects frequent requests.

As a distributor of software and/or hardware that utilizes it, they require that the product be registered with them as a user. I tried repeatedly to establish contact, through their published contact info, but never received a reply.

Since switching to time.Google.com, all problems have disappeared.

Since you are not running the standard firmware release, you will need to determine why your system is unable to contact the time server. Given that you are getting 302 (redirect) from whatever update server you are contacting, I would try to resolve that as it stands a good chance of being related.

Thanks for your prompt reply, Bob, and explanation of the time server issue.

As for:

sadly I am not that proficient in software to be able to solve these issues. My skills are primarily in hardware, and in the end my changes to your design were almost entirely hardware improvements, but using your IoTaWatt firmware virtually unmodified.

The code will (presumably) be trying to access the update server that you operate, but getting the temporary redirect message.

What especially puzzles me is that it obviously was previously able to access your server since it automatically updated to version 02_05_11 (on 1-Nov), but some time later appears to be unable to contact your server again.

It has actually become more serious while I was composing this post…

Today I was also experimenting with the RTC battery, so see how IoTaWatt warns the user when the battery is low (since this isn’t explained in the documentation). So I removed the battery to observe what happened at the user interface (Status screen and Graph+ screen). Nothing. I thought maybe it only checks at boot-up, so I power-cycled the unit. Fatal mistake!

Apparently it’s not just the update server it can’t access, but anything on the Internet. Since the RTC is now not initialised (power-cycled without battery) and the software can’t access the 'net to re-initialise it, the firmware won’t progress past the

Updater: service started. Auto-update class is MINOR

line in the messages file and serial stream. Just the red LED on for 5-seconds, off for 10, ad-infinitum (along with blinking of the ESP8266 blue LED when the red LED is on - not the NodeMCU one). I’m at a loss to work out what’s stopping it from accessing the 'net, when it’s communicating fine within my LAN.


For anyone who stumbles upon this thread and wants to know the outcome, the issue turned out to be something strange happening with my LAN and its three routers…

While only one of those routers initially had DHCP enabled, and all three have the WattsOn (IoTaWatt variant) MAC bound to my desired fixed IP address, for reasons unknown to me WattsOn failed to get that IP address, and instead received an address from the DHCP router’s address pool.

So I then turned on DHCP on the router/AP that WattsOn first connects to, but restricted its range to only the IP address I wanted WattsOn to have. This worked for several weeks. Then for reasons also unknown, it suddenly stopped working and was no longer able to access the Internet even though WattsOn was still accessible locally on my LAN at the fixed IP address.

Today I again disabled DHCP on that first-stop router and rebooted it, and WattsOn then was able to get an address from the other router’s DHCP pool, and was then able to access the Internet.

I don’t understand any of this LAN/router stuff, but am happy that it is working again. And despite the IP address change, wattson.local still finds WattsOn, so a fixed IP address was perhaps not necessary after all.

All that remains now is for me to re-start my battery removal experiment to find out how the IoTaWatt firmware alerts the user to a low RTC battery!


Have to ask: if you don’t understand LAN/router stuff, why do you have three of them?

The point of network names is so you don’t have to remember addresses (that might change). The dot local names are a method of doing this for local (non Internet) devices.

Based on some things you said it sounds like you might be trying to segment your network, which some people say is a good idea. Like many good ideas, there is a cost to it. Complexity goes up and it can prevent the things you want to happen in addition to the things you actually want to prevent (that might never really happen on your network). It’s like insurance. When you need it and didn’t buy it, you will feel really bad. But when you pay a very high price for insurance for decades and never need/use it, will you still feel good for the peace of mind the high price bought you?

Because of the size and layout of my house. I long ago gave up on wi-fi for critical streaming devices, and have wired most of the house with Cat6 wired Ethernet. But I still use wi-fi for a few devices, including WattsOn/IoTaWatt.

My #1 router (part of the broadband VDSL modem) is in one corner of the house on the lowest floor. It has only an internal antenna, so can’t reliably reach the furthest reaches of the 3-level house. So I connected a second wireless router with an external hi-gain antenna in the middle of the house (but still lowest floor). This serves well for mobile phones, visitors’ PCs, etc.

But it’s not close enough to the garage (opposite far corner from broadband modem/router, and on a different level) for a strong signal to the solar inverter and WattsOn. So I installed a third wireless router there just for those two devices. All three routers are connected via Ethernet to a Gigabit switch.
Gerroa_network_diagram202011.pdf (1.0 MB)

So now you understand my LAN arrangement, I would really appreciate any constructive comments on how to get a fixed IP address for IoTaWatt (I really don’t understand why that provision wasn’t included in its Configuration options, since the NodeMCU can certainly request a fixed IP address – I’ve done it myself on other NodeMCU projects. Sure, the extra menu would be a pain, but what about just editing the desired address into the Config.txt file?).


Your DHCP server should be configurable to assign a fixed IP to a given MAC address. In my experience, that’s far superior to having the device declare itself to be a particular IP. That’s the mess we had before DHCP. When all addresses are assigned by the DHCP server, there is no guesswork, and the topology can be seen and maintained in one place.

Why doesn’t IoTaWatt allow setting the IP? Because I don’t need yet another opportunity for users to have connectivity problems.

Bob, yes, it should, and has worked for my friend where I installed WattsOn. But for some strange reason on my 3-router LAN it doesn’t work, even though set on all three routers!

Anyway, as everything normally on my LAN (including two mobile phones) all have fixed IP addresses, WattsOn should keep its assigned IP address indefinitely, unless there’s a power failure while visitors are logged in to my network; very unlikely!


While you might be using three routers, you do NOT have a three router configuration and don’t need one. First some terminology. A router works at level 3 of the network. This is common called TCP/IP. Level 2 of the network is what a, hub, switch, access point works at.er tha

Many home network (Wi-Fi) routers have the ability to be either a router or an access point. I have had TP-Link equipment and was not that impressed with it, other than its cheapness (in every sense of the word). As I recall the router I had did not have the ability to be an actual Access Point. However, I could make it do that by turning off DHCP, setting it to a static IP address on the same network (and configuring the DHCP server to not lease that address to something else.

You have a possibly needlessly complex network. How much money and time are you willing to spend to fix it?
Many people I know have been very happy with the mesh network setups. If you go this route, get ones that have ethernet ports on the satellites. If you have less than 1Gbit service this would probably be the best path. Looks like $400 for three eero pros (on sale right now at best buy). Eero does a good job of steering the client to the best AP. There are cheaper mesh solutions, but they all have a lot of bad review and some good ones.

Your network looks like it is set up in a complicated way that is unlikely to give good results.


Thanks for your further comments, and willingness to help.

The answers to that question are “little” (fixed pension) and “some” (retired). Like many Aussies, I tend to do things on a shoestring budget, using stuff that I have at hand (even if not the most suitable) rather than buying new stuff.

So it is with my network – I had three (actually more) modem/routers on hand (all free from ISPs), and it seemed like they would achieve my desired purpose.

And indeed they have; at least 99% of my desired purpose. Everything is working swimmingly, except I can’t get a fixed IP address for WattsOn/IoTaWatt. And as I said, I can live with that since the chances of anything else grabbing that DHCP-assigned IP address (which is the first in the range of addresses that router can allocate) are minimal.

Yes, my network is messy, having grown like Topsy as I added devices to the house, over many years (most recently the solar system). But spending $400 (even if only AUD400!) just to fix one IP address does not sound like good value to me.

But thanks for taking the time to look at my problem and offer solutions!


There are different methods that DHCP allocators can use for allocation. As you might imagine some are better than others for any particular purpose.

Many people say that fixed IP addresses are better. I don’t understand that statement, since I have never really heard a good reason for having ALL addresses static. As Bob said, that was the way it was at the beginning of the internet. I was there and it was a nightmare to manage with anything but a very small and very static/fixed/unchanging network. This was the reason DHCP was invented any what the first letter means, Dynamic.

I don’t recall what TP-Link does. I currently use pfSense, which I don’t recommend unless you are willing to spend a lot of time learning about a lot of things. It has a DHCP allocator that is really annoying. It allocates in order, but it does remember MAC address, so once a device gets an IP address it will continue to get the same address, at least until it runs out of new addresses. It also allows assignment, but these have to be outside of the normal assignment range. I have a few ASUS routers and they are nice and work well. I am now using the latest two as APs. Their DHCP assigns a fixed address based on MAC (probably using a hash to generate the address) but also allow setting particular MAC addresses to a fixed IP address, still in the normal range. This makes it much easier to manage.

Back to your network. You can probably achieve what you want with your equipment. First thing, there should only be one DHCP allocator per network. Your picture says this is the TP-Link in the middle of the picture. But, some of the words in your post seem to indicate you have multiple running. If you have multiple allocators a device can get an address from any of them, with generally not good results, which sounds like what happened to yours.

The reason I got rid of the TP-link router (that I was using as an AP) was because it was rather unreliable and I got a really good deal on an ASUS (T-Mobile was having a closeout on private branded ones). Having said that, the TP-Link was better than the no-name one I had there before. It would go out to lunch every month or so and needed to be rebooted.

For a multiple unit setup, it is best to pick one unit to be the “controller”. I would pick the one that is doing the actual routing to do that would be the my republic one in your network. It must have a DHCP allocator in it. The TP-Link routers should be put in AP mode. They should have a static IP address to make it easier to find them. If the TP-Link FW doesn’t allow AP mode (the version I had didn’t, probably because they could get more money for an AP, because they are used in business networks) you HAVE to turn off the DHCP and make sure you only plug into the LAN ports. Nothing should be plugged into the WAN port.

Then there is the problem with SSID and channel. You have to decide if they will be all on the same wireless network (layer 1) or if they will get individual SSIDs. For minimum interference, you should assign them non-overlapping channels (1, 6, 11 in the USA, probably the same in AU). All of these decisions and more are handles simply by the better mesh network products. This is the reason they have been successful and able to charge such a high price. Most people don’t understand networking (and don’t really want to) they just want it to work.

I have a long history with networking and have done it professionally from before what most people consider the start of the internet. When I got 1Gbps service, I was tempted to get a mesh setup. It would have saved me a bunch of time. Actually, using my existing ASUS would have saved me a bunch of money, but there was one thing it would not let me do. I got a new cable modem (CM-8200) with the new service. My ASUS router and it were not on speaking terms, ie I could no longer connect to the modem’s web page from within the network. I had been able to do this fine with the SB-6142 I had before. It was that one thing I couldn’t do with my network that led me down the path of complete overhaul of my network. I moved the ASUS up one floor (from the basement) and turned it into an AP. I have a small low power PC running pfSense as my router. All of it is monitored using Influxdb and Grafana, which is really cool to see. Also, the one AP is enough to get wireless in all of my house’s two stories plus basement. There really is a difference in the quality/capability of wireless equipment. The older I get, the less tolerant I get with poor performance in equipment. Only you can decide what a well functioning network is worth to you. Since I am working from home, it is worth a LOT to me. When I was not at home all day, only what my wife thought of it really mattered. I resisted throwing money at the problem, so I had to spend a lot of time researching possible solutions and more time and some money trying them out. There was a point, where I was ready to just spend the several hundred dollars on a mesh system and be done with it. But, I had already spent a few hundred and a bunch of time and felt I was close. Turns out I was not quite as close as I thought I was, but I got it all working eventually. My guess, for your network, is you just need to make sure there is only one DHCP allocator. That will probably fix it, until the next change :slightly_smiling_face:.


Many thanks for your time and sharing your expertise. And for solving my ‘problem’! This did the trick:

So I disabled DHCP in the TP-Link router, rebooted it, enabled DHCP in the MyRepublic (Technicolor brand) router, set its allocation range the same as the TP-L had been and rebooted it. Then power-cycled WattsOn, and lo-and-behold it came up with the fixed IP address (…123) I had specified in the router’s MAC binding table!

You have been a great help to me, and if I can return the service, please ask. I’m a BE specialising in electronic hardware design, both analogue and digital. The last 24 years of my working life involved designing and programming embedded systems for industrial control purposes, though my (self-taught) programming skills (assembler and C only) are limited, and my aging brain is not as quick as it used to be. :frowning:


PS: The main reason I use fixed IP addresses is the Squeezeboxes. They need to be set up with the IP address of the music server, so if that were to change from time to time, it would be a pain having to reprogram every one again. So easiest was to fix everything.

It also helps when diagnosing network issues from a WireShark capture, as packet analysis software (e.g. NetData from MeasureIT) can use a fixed name table and display dialogues and such with the device’s name (as in the old sample below) rather than a meaningless IP number!


Cool, glad it helped. Okay, here’s a question for you. I have a software solution, but what would be a good HW solution.

I have a device that requires a 1KHz square-ish wave ~5V to provide it with power and communication. It communicates back with a higher frequency signal of low amplitude (about 0v5) when the controller is not powering the line. The data to the device is encoded by changing the low/off time.

Right now I am using an NPN transistor to turn on a MOSFET to drive the line high. The line is hooked up to the input of an inverting op-amp (with about 5x gain). Since the line has 5V (used to have higher) on it, I have resistor inline to an LED (across the line and gnd). This limits the voltage to a safe level for the op-amp and has the added benefit of providing visual indication of the communication. The problem is that the output of the op-amp is not a constant level, since the input signal is changing rapidly. I solved this in SW, by looping with a delay 10x and reading the input and if the input is low all 10 times, I assume it really is low. But, if it is high at any point, it means the device is talking back. This provides that 1 bit of information. A pulse stretcher seems like the typical HW solution, but an RC filter might also work. What do you think?

A good DHCP sever will generally give the same IP address. The original RFC doesn’t specify the behavior, so that is left as an exercise to the implementer. There are advantages to having the same IP address, using static IP addresses set by the device is one way to achieve that. But, I much prefer to have the configuration on the server. That makes changing network stuff much easier.

When I was debugging my issue with my new cable modem, I heard that some people had success by switching from 192.168.0 to 192.168.1. I have a lot of configuration of many devices that has to be done using IP address, so I resisted making this change. Luckily all of my devices (except the extra AP) use DHCP, so it was actually possible to make the switch. When I switched to using pfSense, I had to figure out how to get the IP addresses I wanted for the few devices that needed to be static. It was a pain to do, but I probably won’t have to do that again.

Both my IotaWatts have fixed IP addresses and always have, I just do that configuration from the router, which is why Bob says it really isn’t necessary to provide a static IP selection (because then you really need to provide a way to reset when someone types the wrong number in the UI).

I’d be happy to spend some time looking into a h/w solution. But as it’s not relevant to this forum, let’s do it off-line. I’ll PM you my eddress to continue the discussion.


I can see the point you and Bob are making. I believe the IoTaWatt is aimed at ‘hobbyists/enthusiasts/tech-heads’ who are quite comfortable messing around inside their router’s settings.

But if I commercialise WattsOn (a bridge not yet crossed) it will be targeted at ‘the man in the street’ – someone who has had solar installed and just wants to see how it’s performing. Typically they wouldn’t have a clue how to change modem/router settings, but could probably edit a text file to add an IP address.

But I really can’t expect Bob to add such a facility just for me – a potential competitor! Sooner or later (if I decide to go commercial) I will need to pay someone to make some firmware improvements.


If you think a normal customer can figure out an IP address to use, I believe you will be disappointed in your sales numbers (since the number of people who can do that are very limited).

Decades ago, I designed the process for one of the first “getting connected to the Internet” setup wizards and got to sit in on usability testing. It was an eye-opening experience.

What Bob and I are saying is that using static IP is an advanced technique that should be avoided unless you know what you are doing. If you KNOW that you need static IP, you also should be smart enough to figure out how to set it up on your router. If you don’t have that level of knowledge, you really should not be using static IP addresses as you will get into trouble with them.

If you look at other network devices, they typically have some sort of discovery protocol and an app for finding the device. Sometimes this involves a special network that you have to join, other times it is an layer 2 discovery protocol, other times a layer 3 broadcast protocol.

Bob added mDNS to IottaWatt so that you can normally use iotawatt.local as the name. This eliminates the need to know what the IP address is. However, mDNS does not work for everybody for some reason. It does not work on my Windows systems, but does work on my Linux instances (even the one running in WSL2 on windows). I am curious now, so I will see what it takes to make it work on Windows too. But, mDNS Multicast DNS - Wikipedia is the solution to not needing static IP. Humans are much better with names than numbers.

And it appears that Edge is now smart enough to use something like http://iotawatt.local/

This did not work on at least some of my older computers, but works fine on my Windows 10 PC. So, now I don’t even need to remember an (or even set a static) IP address.

Ping is not smart enough to find it (on Windows) but Edge works fine.