One of my units is having a curious (to me) behavior on power on. The sequence is as follows:
1 Power on
2 Access point blinking of red-green-green for one time
3 Solid green for 2:55 minutes. It replies to ping during this time but webserver access is not possible
4 Fast green blinking and webserver access now possible
If we replace the microSD card with one from another IotaWatt unit (datalog mostly empty) the unit goes immediately from the red-green-green access point sequence to green blinking and the webserver access becomes available.
Configuration is 6 CTs, 1 Voltage sensor, and 9 defined outputs.
This IoTaWatt has about 10 days of logged data. File IOTALOG.LOG is ~53 MB in size
The unit was dropped from about 40 cm.
Data seems corrupted. I can no longer see graphs and the Show CVS shows all NULL for every output.
I also just updated (after this issue) from 02_02_30 to alpha.
I’m not sure if this behavior is common since the unit was installed without problems for more than a week and was rebooted manually maybe once. The fall from 40 cm was during the weekend and it turned off.
About what happened, just wild speculation. The thing is pretty rugged, but if it was running when it fell, possibly the SDcard was jarred loose, which can cause file damage.
It sounds like your datalog may be bad. After it starts, can you get the status screen then click the Data Logs tab. If either of the logs don’t look right with respect to start and end date, post a screenshot and I’ll tell you the best way to fix it.
It does look like the current log is toast. The way to fix it is to delete it, which I’ll get to. The history log contains all off the data that would have been in the current log until it got damaged, only at 1 minute resolution instead of 5 second resolution. When you use the visualization tools like graph, you are only using 2 minute resolution unless you drill down with the + key.
But I’m concerned that you have damage to the basic SDcard format, which can manifest itself in a variety of ways. So if you just want to cross your fingers and delete the current log, use this command:
http://iotawatt.local/command?deletelog=current
That will delete the current log and restart the IoTaWatt. A new log should be created immediately. Take a look at the status again after a minute or so and see if the history log is now showing your install data through the current date and time. If not, use the same basic command to delete that and restart:
http://iotawatt.local/command?deletelog=history
If you want to be really safe, get a new SD card, or at least reformat the one you have. You can copy the contents of the root directory, or at least your configuration - config.txt.
The SD seems fine. I can access every directory and file and I did a backup yesterday.
I just used the command you suggested on both logs and it’s booting fast now. Looks like I can see graphs and CSV data now, but I see a lot of nulls, which may be because we don’t have the sensors installed right now. See the screenshots.
After current log delete:
After history log delete:
One thing, though. During power on sometimes the access point sequence (red-green-green) is missing. That is, sometimes it goes:
green, red-green-green, continuous green blinking
and other times:
green, continuous green blinking
OK, Fingers crossed. That’s not a definitive test.
R-G-G means the WiFi STA isn’t connected yet. The ESP8266 tries to connect to the last successful SSID whenever it’s powered up, so sometimes, that happens fast enough that by the time the firmware checks for a connection, it’s already done. You won’t see that sequence at all in the case of a programmed restart, because the chip never powers down and WiFi stays connected.
Anyway, what you are seeing is normal.
I just realized of something. While we were trying to restore the unit to full operation, and when we got the SD access error, we applied heat to the SD connector with a heat gun. We removed the SD but also the BATTERY.
Are there any unexpected consequences for this? Thanks.
We continued using the IotaWatt but now it’s stuck on a fixed behavior after power on:
solid green for about 6 seconds then turns off for a fraction of a second then solid green again. I opened the case and that’s the exact behavior of the blue led on the nodeMCU board so I’m assuming it’s reseting itself.
I already reformat the SD and copied the root files from another working unit as you recommended on a previous reply and still nothing.
That’s not a failure mode of the firmware. I’m not going to try to diagnose the hardware via the forum, especially where you’ve taken a heat gun to it. There are a couple things you can do:
The other thing you can do, if you are in the USA, is send it to me and I’ll take a look at it. If you decide to go that route, PM me and I’ll give you a shipping address.
Thanks. I will consider the reflashing. But the problem got kind of strange. Let me elaborate.
What I was working on (with no CTs or VTs connected) was trying the options for direct and derived three-phase modes (we’ll switch to direct reference mode later this week, maybe tomorrow), enabling/deleting the 3 voltage inputs and checking how everything relates to the CT inputs (like a single voltage reference will be the default for all CTs, etc). While doing so, I removed CTs, added VTs, removed all VT’s etc. That’s when the unit stopped working.
And it has happened with a second unit now (no heat gun for this one) but the led stays green for 3 seconds (not 6) then blinks. I was trying the configuration options for inputs too.
What’s even more strange is that when this 2nd unit failed I went back to the original unit and it is working now. As you said previously I’ll keep my fingers crossed.
I went back to the second unit and it began showing a red-green-green sequence. Then it went to the previous error. The green lasts about 3 seconds and then turns off for a fraction of a second then it repeats.
I’m attaching the IOTAMSGS.TXT file from this second unit. I removed older lines to keep the file smaller (it was at almost 1 MB). It looks like the unit is reseting itself (watchdog). The power failures are from disconnecting the power. Maybe the trace will tell you something.
Looks like the wdt is from an endless loop looking for something to sample. You need to have a VT defined. You will need to edit the config.txt file or load the default from the git.
No problem. That’s what we do for work, along with embedded system design…