Adds HTTPS proxy
Adds influxDB2 support
Improved config upload/recovery
Rebrand servers as uploaders, recode with common base class.
Modify scheduler from seconds to ms.
Improve AC synchronization with us “bingo-time”.
Increase SDspi clock to 25MHz.
Recode and improve script->run
Improve uploader start/stop mechanism.
Update docs for new support and misc .
2 Likes
Mar 18, 2021 14:18UTC reverted ALPHA to 02_05_12 due to the restart problem reported in other threads. Working on fix and will issue new release in a few days.
Not sure if this is the right spot to report bugs with ALPHA 02_06_00 Alpha.
I got through the issue with the “server” line in the config.txt causing the system to barf.
I have a new issue now, it’s a green-red-red light…but it only happens once I plug in the 9V reference. I lose all connectivity. If I unplug the VT, then everything goes back to happy.
I think this is the relevant part from the log:
3/18/21 16:45:10z Reset reason: Software Watchdog
3/18/21 16:45:10z Trace: 1:6[6], 1:3, 1:3, 1:6[1], 1:6[2], 1:6[2], 1:6[3], 1:5[19], 1:6[4], 1:6[6], 1:3, 1:3, 1:6[1], 1:6[2], 1:6[3], 1:5[14], 1:6[4], 14:0, 14:1, 1:6[6], 1:3, 1:3, 1:6[1], 1:6[3], 1:5[31], 1:6[4], 31:0, 31:1, 31:2[1], 29:20, 29:20, 29:21
I’ve already double checked to make sure that it still says “TDC DA-10-09-E6”, and it does. I’m an EE and have several tools at my disposal for troubleshooting, so feel free to provide any instructions that would be helpful for you.
Lookup that led code in the troubleshooting section of the docs.
Sorry, forgot to mention that. I did pull the SD Card and the config.txt file is intact and readable.
It’s hard to tell if green-red-red, or green-red-red-red…it happens very fast.
I did more troubleshooting and it appears related to my InfluxDB2 settings.
If I delete the “influxdb2” settings in config.txt, then everything is fine again.
Sounds like I should just wait for the next Alpha version to come out?
Well, GRR is SDcard not readable. GRRR is config,txt file not found. There is another code GRRG that is displayed when the config.txt file is not valid Json, which I might suspect after the config was manually edited. Did you use the JSON LINT checker after editing? Json is pretty unforgiving. Leaving a hanging comma can cause the whole thing to become invalid. As of now the only thing I’m fixing with influxDB2 is a problem with the bucket not being properly initialized.
I think the blinking is just GR. Here’s a video showing the sequence:
I guessed at it being GRR or GRRR because there is not fault specified for GR.
The JSON is valid. Here’s what it looks like when it borks: config_bad.txt (2.9 KB)
I’ve obfuscated the url, orgid, and authtoken. Everything else is the same.
It worked fine adding the InfluxDB2, but as soon as I added “ct” => “$name” in the tag-set it borked.
I was able to reproduce and fix this. It is not related to the config issue.
1 Like
Hi Bob, I’m curious, what exactly was changed and optimized here?
This is complicated and gets into the fundamental way IoTaWatt works. As you know, it samples one AC cycle, and then processes those samples and then tries to do whatever else it needs to do during the next half cycle. Rinse and repeat.
So in your 50Hz world, it samples one complete AC cycle for 20ms, then does other stuff for 10ms. It doesn’t always get back in time, so sometimes it cuts into the next half cycle, and so if it’s real busy, usually with communications, you will see the cycles sampled/sec drop.
The internal processes that do this off-cycle work are scheduled. Previously the resolution of the scheduler was 1ms, so not very accurate at working the timeslice, especially in my 60Hz world where it’s 8.3ms.
So the scheduler has been reworked to schedule at the microsecond level, and the exact time when the last cycle crossed zero is recorded. Bingo-time is term you will see used for aircraft sorties. It is the time when an aircraft has just enough fuel to return home. When the scheduler dispatches tasks, it sets “bingo-time” as the time the latest time the task should relinquish control in order to catch the next AC cycle.
The ESP8266 does not do pre-emptive scheduling, and so these tasks (about 8 of them) are on their honor to work in short bursts, save their context and return to the scheduler. Knowing bingo-time takes a lot of the guesswork out of that and allows them to work up until the limit.
With this I saw a modest improvement in sample rates, especially when uploading history. All of these changes are geared toward being able to use the ESP8266 code as unaltered as possible in the ESP32. The ESP32 isn’t constrained by the AC cycle problem as it dedicates one processor to sampling, but it does use the same dispatching techniques to minimize stack requirements that would otherwise be needed to utilize the FREErtos scheduler for so many activities.
3 Likes
I got 02_06_01 and have it working with my locally hosted version of influxdb2…works great!