I think the PCB was v4.41 but I can open her up again to check if necessary.
Firmware is the latest MAJOR: 02_06_06
It was on poor wifi but always operational
24R Burden resistors per manufacture
Last night I followed Bob’s instructions in the link and, other than actually replacing the SD card, I did delete the current (corrupt I think) & history (big & corrupt) logs which I don’t require as I had only been using two CT channels; grid & solar, pending a long outstanding home network refresh, Home Assistant implementation, EV etc.
IoTaWatt came up no problem although the message log attached shows restarts overnight. It wasn’t on a UPS but the 5VDC will be going forward. Only the VT was in overnight no CTs as it was on my bench not with the electric dis. board so perhaps that was an issue?
I now plan to use all 14 CT channels, recalibrate for accuracy etc. and wish to start over with a ‘clean sheet’.
Questions:
Is my PCB version OK going forward?
Should I replace the 8Gb SD with a new & or larger one?
What do I need to do to start with a ‘clean’ (as new) IoTaWatt? Anything else other than the already deleted / recreated current & history logs?
Is it possible to limit history to say 1, 2 or 3 years for example?
Anything else I need to do or think about for a new start?
Regardless of whether your issues are caused by your SDcard, after four years it would be best to replace it for a couple of reasons:
The older systems used a 4GB class 4 card. Newer systems use an 8GB class 10 card. While the greater capacity isn’t needed for the data, I think it gives the wear leveling algorithms more space to spread out usage. The class 10 will provide some incremental speed increase when graphing.
Another reason is that early cards were subjected to more wear. With 02_06_xx a newer low-write algorithm was introduced with better fail-safe techniques.
I’d recommend getting an 8GB class 10 card. Copy all of the root files from your old card but none of the higher level directories and restart. It should come up with new datalogs and message logs.
I’d also recommend going to auto_update MINOR to upgrade to 02_07_05. This release is very solid.
Update your config and you should be fine. The only difference between your unit and the current V5 is the ability to connect additional VTs for three-phase direct reference. The 24 ohm vs 20 ohm burden difference is not very significant.
Don’t know why you would want to do that. There is an unpublished config entry to set the size of the current log, but not the history log. It’s possible to add that but why? Make the case and maybe I’ll do it. It would be a few years before you would need it anyway.
Just so I get it right, delete, or at least don’t copy back to the new card, these higher level directories:
\.Trash-1000 \DOWNLOAD & \IOTAWATT ?
Maybe I asked the wrong question. I suppose I’m saying I don’t wish to look back at my consumption / generation data more than 2-3 years although I appreciate that others might.
Before I set about re-installing & re-connecting my IoTaWatt to my electric dis. board I’ve been monitoring the message log (attached) for a couple of days since my last post and there are ** Restarts ** with ‘Reset reason: Exception and Hardware Watchdog’. I don’t think I’ve seen any other reason before the attached log, possibly ‘Software Watchdog’.
NB Previous restarts were much less frequent, maybe 1 every 8-10 hours.
I have seen, on previous messages twice, short ~5s wifi disconnect / reconnect but that might be that we are on an, albeit very good signal, outdoor antenna 4G LTE modem and MikroTik router and access points all on UPS. IoTaWatt WiFi RSSI is between -40 to -50dBm so that looks OK on a static reserved IP. Is the IoTaWatt’s WiFi disconnect / re-connect actually an Internet lost / restored message, i.e. a ping of a public IP address e.g. IoTaWatt firmware server?
I have had (switched off currently) a couple of ESP32 Home Assistant ESP32 boards (I realise the IoTaWatt is an ESP8266) connected to the same access point with no issues. If it’ll help I can connect the IoTaWatt to my entirely separate VDSL Broadband router that is not normally in use so it will just be a single device on that WiFi network.
The IoTaWatt, during this testing period is on UPS and raw ac mains VT only with no CTs attached - and therefore 14x open circuit inputs which could possibly be an issue but other than 2.4GHz & 5GHz wifi and switched mode PSUs around no other RF fields. The Integral Ultima Pro 8Gb Class 10 SD FAT32 factory formatted card is brand new.
I have stopped both PVoutput & EMONCMS uploaders to see if that’s an issue but the restarts continue.
Am I right in thinking that the ‘Trace:’ numbers in the message log tell you what the IoTaWatt is doing and might help to home in on the issue? I’m not a dev but do have a basic understanding and haven’t looked through the IoTaWatt’s code yet.
Any thoughts, checks & tests I can do are welcome.
So restarting about every minute. You’re right in that I can see pretty much where it was executing at the time of the exception. Check me if I’m wrong but although you say there are no CTs connected, it looks as though there are some configured. I see at least 0,1,2,3,4,10,11,13 and 14.
It’s a pretty limited section of code and the only thing I can see causing an exception would be a divide by zero if frequency degrades to zero. I should note that the software watchdog does not fit this scenario. It’s an area that I should bulletproof, but it’s not a common problem in most systems. So what’s different here?
This doesn’t look like a WiFi issue. My suspicion is that it has to do with the VT. What exactly is the situation with the UPS? Are both the USB supply and VT plugged into the UPS? Can you try running it directly without the UPS?
All 14# CT inputs are configured but currently none are connected to CTs.
The small UPS (5VDC output) is only powering the 5VDC to the IoTaWatt. The AC output VT transformer is connected directly to the approx 240VAC mains supply. I shall remove the UPS and power the 5VDC adapter from the same mains as the VT transformer.
I’ll run & monitor IoTaWatt it for 18 - 24 hours and update you.
(I’m now wondering about the UPS too as it’s a low cost (cheapo?)device. In the final install IoTaWatt will probably be fed from my main high-quality UPS along with my network, AV, CCTV etc. but if that gives any issues, direct from the mains.)
Hi Bob,
No restarts in the last hour or so since I put the 5VDC adapter on to the mains alongside the VT txfmr.
SD initialized.
2/19/22 16:20:46z Real Time Clock is running. Unix time 1645287646
2/19/22 16:20:46z Reset Reason: Power-fail restart.
2/19/22 16:20:46z ESP8266 ID: 2873399, RTC PCF8523 (68)
2/19/22 16:20:46z IoTaWatt 4.x, Firmware version 02_07_05
2/19/22 16:20:46z SPIFFS mounted.
2/19/22 16:20:46z Local time zone: +0:00, using DST/BST when in effect.
2/19/22 16:20:47z device name: IotaWatt
2/19/22 16:20:50z HTTP server started
2/19/22 16:20:50z emoncms: Starting, interval:10, url:http://emoncms.org
2/19/22 16:20:50z WiFi connected. SSID=BTHomeHub2-4R2S, IP=192.168.1.109, channel=6, RSSI -48db
2/19/22 16:20:50z MDNS responder started for hostname IotaWatt
2/19/22 16:20:50z LLMNR responder started for hostname IotaWatt
2/19/22 16:20:50z timeSync: service started.
2/19/22 16:20:50z statService: started.
2/19/22 16:20:50z Updater: service started. Auto-update class is MINOR
2/19/22 16:20:50z emoncms: Start posting at 02/18/22 04:18:20
2/19/22 16:20:50z emoncms: stopped, Last post 02/18/22 04:18:10
2/19/22 16:20:50z dataLog: service started.
2/19/22 16:20:50z dataLog: Last log entry 02/19/22 16:20:25
2/19/22 16:20:52z Updater: Auto-update is current for class MINOR.
2/19/22 16:20:55z historyLog: service started.
2/19/22 16:20:55z historyLog: Last log entry 02/19/22 16:20:00
2/19/22 16:21:00z PVoutput: started
2/19/22 16:21:00z PVoutput: System The Hayloft, interval 5, donator mode
2/19/22 16:21:00z PVoutput: Start status beginning 02/18/22 04:15:00
Please see attached IoTaWatt Status screenshot although this looked OK before including Frequency & free Heap but not Running time: of course.
Is the Current Log size OK - I hadn’t noticed what it was when IoTaWatt was operational before my Starting Over situation other than one of corrupt logs looked to be c1.5Gb I think?
First paragraph: I purchased my IoTaWatt May 2020…is it likely that has a 4 GB or 8 GB card? Alternatively, is there a way to tell the card capacity via an API call, so I won’t have to shut it down and physically open the case?
Second paragraph: Ooooh, what is that unpublished config entry for increasing the size of the current log?! As I’m just now uploading data into Influx, I’ve only got one year to view/analyze. Having “all” of it would have been nice…oh, well.
Case for increasing the history: “why not?” If the cards are plenty big and if I upgrade mine to a larger (and faster) one, why not be able to keep many years of 1-minute history?
(I know you have lots to do to keep a product like this up-to-date and such, so this is just a nice-to-have request / vote to enable increasing the history log.)
Replying to tie up this thread and probably mark it ‘solved’ if Bob’s happy to do that please.
I was experiencing ‘Reset reason: ‘Exception’ & ‘Hardware Watchdog’’ crashes of IoTaWatt very frequently.
I initially looked in these areas:
I suspected the mini 5VDC UPS I had the IoTaWatt on then
Home Assistant integration - where I’d read of issues then
Two recently installed TP-Link KP303 three (UK 13A style sockets) socket WiFi power strips which led me to
the TPL KASA app, initially on iOS then Android.
The TPL KASA app that can be used to control TPL’s light bulbs, sockets & power strips has some issues with mDNS and it’s the sending of a switching action from the app to a TPL device that causes IoTaWatt to crash almost without fail.
If I switch a TPL device from within Home Assistant, or locally on the KP303 on / off switches, there are no crashes or any other issues. Searching the Internet it seems that others have had issues, mentioning mDNS, with KASA.
Avoiding the use of iOS & Android versions of the KASA app for >31hrs has resulted in no IoTaWatt crashes nor even a single WiFi disconnects.
IoTaWatt firmware version: 02_07_05
802.11b WiFi - I realise that this isn’t the fastest, and doesn’t need to be, 2.4GHz protocol but I can achieve an RSSI of -70 to -75dBm with zero disconnects so far until I install an additional access point in my distribution board area.
Whilst I await for delivery of additional current transformers I have the opportunity to leave the IoTaWatt alone for a couple of weeks to re-confirm my findings.
