Iotawatt clock connection

Hi all,

I am having trouble getting my Iotawatt clock to initialize after being connected to the internet, initially I had the Iotawatt hoocked up to a network with no internet connection, bu

Can you tell me why you believe the clock is not being initialized and post your message log?

Hi @overeasy,

My apologies it looks like only part of my posting went through, here is the message log you requested. It is my understanding that the clock should connect automatically after connecting to the internet right?

Yes. IoTaWatt requests the current time from a pool of internet time servers. It is very reliable. I can see that your system is having trouble accessing the iotawatt.com firmware update site as well. Looks like a problem accessing the internet.

I don’t know which release of the firmware you are using, the portion of the log that you are showing is, of course, dominated by the connectivity errors. Could you restart the device and capture the message log from the ** Restart ** header? At least I would get the firmware version and basic WiFi network information,

Also, where are you located? The only other problem similar to this was reported by someone that had satellite internet. That doesn’t really work. The solution was to take the IoTaWatt someplace with terrestrial internet and boot it up to set the real-time-clock and get the latest firmware upgrade, then bring it back to run essentially standalone. I’m assuming that worked.

That’s what we tried, we are trying to run our Iota Watts on a local network with no internet connection, we took them to a place with internet with unfortunately no results. Can the Iota Watts still work successfully with a local network? Also here is the information you requested

Are you saying that these message logs are produced while the IoTaWatt has no internet connection? If that’s the case, the clock problem will never be resolved without it, and IoTaWatt cannot log power data if it doesn’t know what time it is. I have a low priority project sketched out to set the clock from the configuration app browser device time when internet is not available, but that is not something that is available right now.

If I understand what you are saying, you tried to jump start the IoTaWatt by running it on a WiFi network with internet access, then moved it to this location with no internet.

When it was connected to the internet, the time should have been set. Apparently it was not, because this unit appears to have never had a running clock. When you connect it to the internet, the “Noclock yet:” preamble in the message log changes to the current time. Once the clock is set, as long as the battery is connected the real-time clock should run. It does gain or lose up to 2 seconds per day, but in the big picture, you should be fine for years.

Once the time is set, the unit will check to be sure you have the current firmware for the auto-update level you have specified. If you select “NONE”, then it will not attempt to access the update server and the update failure messages will stop.

So it looks as if you need to get the device connected to the internet and verify that the time is set, change auto-update class to NONE, and then move the UNIT back to this WiFi network that does not have internet. It should work then. I’m assuming your Emoncms server is an EmonPi or other instance as it appears to be on the local LAN.

@overeasy I am working with @Ticktock on this project. This project was started by a group of college students at our workplace and we dove in to finish it. We have 7 IotaWatts to set up. Previously, 4 of them were set up and we were to set up the last 3. The established 4 were working just fine and now none of them are working.

It is my understanding that the IotaWatts need to first be connected to an actual internet enabled WiFi connection first to initialize a clock and then this enables it to show up as an input in Emoncms and we can go from there.

We have tried to initially set up the IotaWatts with an internet connection in order to initialize the time clock. We get to the WiFi configuration page, select the internet, put in the password information, the next screen says that the credentials have been save and the LED on the IotaWatt glows green. After this, we are unable to ping the IotaWatt to continue with the set up. We have tried this with two different mobile devices, 4 different laptops, and 6 different internet connections. We were told this was seamless and simple and we do not understand where or why we are hitting a roadblock. Any advice would be appreciated.

You are a little off the beaten path using the devices without internet. I can’t say that I have done extensive testing of that capability, but I believe you should be OK once you get them running.

I run four to six IoTaWatt on the same network, using different device names. My network has internet - most of the time- but when it drops things run fine.

What is the failure mode of the 4 that were previously working and now do not work? Specifically, is there an LED error code - what exactly is the state of the LED?

When you connect to the internet capable network and the LED turns dull green, that indicates that a WiFi connection was established, but not necessarily that the clock was set. You would need to run the app and look at the message log. If the time has been set, the log entries will be timestamped. You will need to be sure that there is a good internet connection and wait for the time to be set.

When you initially connect to the WiFi network, the IoTaWatt will register with the mDNS under the name iotawatt.local. If you are going to run more than one IoTaWatt on the same WiFi network, you will need to change the name of each to something unique in the Device section. Changing the name will force an automatic restart, after which the device will register as the newname.local, and you will thereafter address it that way, even if you move it to another network.

When moving from one network to another, you should first disconnect the device from the old network:

iotawatt.local/command?disconnect=yes

substituting any changed name. This will force a disconnect and the led will turn from dull green to dull red. It is still logging, but not connected to WiFi. When you subsequently restart the IoTaWatt by power down/up, it will broadcast the AP name just like a new IoTaWatt, and you need to connect to it and configure the new WiFi network. There is a three minute window to do that, and if you miss it, the LED will go dull red and you would need to power down/up to start again.

If you are having trouble connecting to an IoTaWatt that has been configured to a WiFi network and has a dull green LED, you might try looking up the IP address that was assigned to it and accessing it with that rather than the mDNS name.

Getting connected to WiFi can be one of the most challenging aspects of installation. As a single developer with limited resources, I’m up against a world of dozens of different router firmware, different communication devices and different browsers. QC to make the seamless and simple would be a huge undertaking. My approach has been to use the WiFiManager class. While not necessarily the best in all scenarios, it is widely used so that there is a larger audience and mainstream compatibility problems tend to get reported and fixed.

See if any of this helps your effort, and get back to me with any remaining problems.

I understand that they need to be connected to the internet. I believe the first four were connected to the internet, but the remaining 3 had not been. I will try the iotawatt.local/command?disconnect=yes and retry to get them all connected to the internet first. I have read that this is mostly an initial step, is this saying it would be better if they were always, or for the most part, connected to the internet? It has been a security issue within the company, but if it is necessary then I will look into finding a remedy for this issue. Within the company, something like this would require signing into a login page which pops up after selecting it as the network on the computer’s settings. We did previously attempt to connect it like this, the WiFi shows up on the WiFi configuration page but this login page does not. I’m sure with the broad range of networks you’re trying to cover this may not be something you have looked into yet, so no worries there if so. However, this may be our only option.

They are not showing and LED error code, they continue to glow green. These 4 also show timestamps in their message log. We have not tried to switch their network at all. I went through and removed the web server information, restarted them, added the web server information again, restarted them, and took a look at emoncms and the message log. We have them named as Iota1, Iota2, etc. The second one just shows a wall of ‘6/29/18 15:43:43 EmonService: input/get failed.’ The other 3 I have attached pictures for. 1 and 4 show up in emoncms but all 3 say ‘6/29/18 15:42:39 checkUpdate: Invalid response from server.’

Understandable, just as we understand it is difficult to diagnose problems you aren’t here to see. Thank you for your responses and time. We stepped into the middle of an unfinished project and have had quite the time finding our bearings in it. We will try to disconnect them and start from step 1 and I will update this post. Thank you again!!

Iota1 Message Log

Iota3 Message Log

There’s a lot here, and I have some answers, but I can’t get to it right now. I’ll try do it justice this evening (US Eastern Time). There have been some security enhancements. I had thought the internet issue was unavailability. I think this can be resolved.

Sorry for the multiple replies. @Panda has the new user restrictions of one picture per post.

Iota4 Message Log

Awesome, that is good news! Thank you so much again.

Also, I tried the disconnect from network thing and I was unsuccessful. Just in case this changes things.

disconnect

iota3.local/command?disconnect=yes

Heh, I may have been at this for way too long. Thank you!

I’ll probably break these responses down into a few to address different subjects and points.

My understanding now is that the primary problem is not unavailability or security, but that the local LAN requires another sign-in/authorization after the basic network password is provided. As far as I know there is no standard protocol for this and so not realistic to add that to IoTaWatt.

With regard to security, whether your LAN is connected to the internet or not, there are three major areas of interest:

  1. Firmware update. IoTaWatt can download and install new firmware from the internet. The way it works is that you configure an auto-update class for the device. The current release level for each auto-update class is published in this forum, and the device checks - approximately once per hour - to see if it has the current release for it’s update class. If not, it will download and install the new current release from iotawatt.com. The new release is signed with a digital signature based on a private key that only exists on a non-internet connected ESP8266. New released are shuttled to this signing device via SDcard and then uploaded after signature. The installed firmware only has the public key for verification.

You can also set the auto-update class to “NONE” and the IoTaWatt will not check for or download new firmware.

  1. Sending monitoring data to a web server. IoTaWatt can send to Emoncms or influxDB, and soon PVoutput. Only Emoncms can be sent securely. Working with OEM a shared secret protocol has been developed by which the data payload can be completely encrypted.

You are in control of where data is uploaded.

  1. The web server. This is probably the biggest vulnerability. The webserver supports all of the APIs and provides access to the IoTaWatt file system on the SDcard. So with uninhibited access, anyone can modify the configuration, delete non-critical files, disconnect the wifi (and then reconnect to their network), read the datalog, delete the datalog… It’s wide open.

This isn’t just for internet connected, it applies to anyone who can get onto the local LAN. In fact, that’s one of the simplest ways to protect against this vulnerability - have a reasonably secure LAN and don’t allow port forwarding from the internet to the IoTaWatt.

But that’s not adequate if port forwarding is enabled to port 80 of the IoTaWatt from the internet, or the LAN is widely shared and not all users are trusted to access IoTaWatt. So there is now authentication for web-server access. The documentation hasn’t caught up yet, but it’s available as of release 02_03_07. In a nutshell, there are two usernames that can be activated by assigning passwords: “admin” and “user”.

The admin password provides access to everything, and no access without it.
except:
The user password will allow access to just read only data and a special /user directory on the SD.

The authentication system uses the digest method challenge/response protocol that does not expose the password. The data still flows in plaintext, but it is authenticated with the digest. All of the major browsers support this authentication method, so you enter the password in response to the first challenge, and it handles subsequent authorization for some period of time depending on the particular browser.

you can specify a password for a username “user” that will allow only certain read only operations. Basically look at data using the graph app or any app that uses the getdata api.

This actually looks OK. IoTa1 and 4 are chugging along fine, and although IoTa3 still shows as 4.2 days behind, the log you posted has it starting up as of June 15 at 6:47pm, so it appears to be bulk uploading history and has made progress from 14 days behind. With 5 second intervals, you are posting 17,280 frames per day. Unless there is something else going on that isn’t posted, I think it may already have caught up.

None of these IoTaWatt seem to be able to access NTP time servers or the IoTaWatt update server. Notice that IoTa4 seems to be 17 seconds back to the future. That’s probably because the RTC has drifted about that much. It can gain or lose up to 2 seconds per day. My non-scientific observation is that it gains in warm ambient and loses in cold. In the big picture, 12 minutes per year isn’t the end of the world, so I elected to source a Timex rather than a Rolex. Besides, with internet, it gets checked every hour against Big Ben.

You can eliminate the “checkupdate: Invalid response…” message by changing your auto-update class to NONE.

IoTa2 sounds like something wrong with the Emoncms specification. The EmonService: input/get failed message means it cannot query Emoncms for the last entry. So check the IP address and the write-key.

One last note: Unless you are trying to do real-time monitoring, writting to Emoncms every 5 seconds is not necessary. You can use the bulk-update parameter to cause IoTaWatt to aggregate measurements into a single HTTP write. It’s more efficient on the network, and as I understand it, more efficient posting to Emoncms. There is a fixed overhead to every HTTP transaction. The incremental overhead for extra payload data is hardly significant. If possible, I would suggest setting bulk update to about 6 and go from 12 writes per IoTaWatt per minute to 2. Don’t worry about data loss. Every write is acknowledged and any interruption, including a power failure, will cause a resend. (just as IoTa3 is presently doing).