So far version Alpha.28 is coming along nicely. I have finished up on showing the running status of each Variance Trigger Thread and am now refining the Variance Triggers, as well as creating a new type of trigger-based recording.

The new type of trigger-based recording is done with a high value and a low value. Once either is passed or comes back from said value, the sensor data is recorded for that period.
For example. let’s say we monitor the temperature with a high of 30c and a low of -10c. If the temperature goes above 30 or below -10, the readings are recorded. If the value returns to normal later on, those readings are recorded. It records CHANGES of state only, reducing the required writes.

I have had issues with the HTTPS server freezing when going to the “Sensor Readings Page” when Trigger Variances are enabled. I’m thinking the constant reads are crashing a sensor or two. So with that in mind, I was thinking of creating an autotest for figuring out how long it takes to get sensor data from a sensor. Once the program has that number, it can use it to help set a minimum value for sensor retrieval intervals. I’m hoping that will help prevent overtaxing sensors and keep some crashes and freezes at bay. I’ll also create a report of direct sensor access times to help set proper times and see if a sensor is taking longer then it should.

In other news, I have been playing around with solar panels and batteries. I have 2x 100-watt panels + 1x 50-watt panel. I have tested the 100 watts panels in different environments with a single Pi Zero W to see how they might operate under poor conditions. First, I tried putting one in my window with very little direct sunlight, and it managed to keep the battery’s charge level during sunlight, which means it probably had enough power to keep my Pi going, but that was about it.
Next, I put one 100 watt panel in my back yard behind my shed, and it did fairly well there when the sun was out but as soon as clouds came and or shad from the trees fell, it didn’t do so well.
So it seems solar really does need direct sunlight with no obstacles to function well. That being said, I still have to test it with my lead-acid battery (used Lithium-Ion for tests), as it may be able to charge better with less sun. I guess the next 2 tests will be putting one in direct sunlight and my lead-acid behind the shed to see how well it does.

Sensor Control in the web interface now allows the use of DNS addresses and port #. AKA instead of 192.168.10.11, you may have a DNS URL setup from the outside like sensor.mycooldomain.com and a port # of 10022 through your router. Now you can enter sensor.mycooldomain.com:10022 instead of just the IP and it will work correctly, including links in reports and downloads.

The “Creating Graph” works the same as creating downloads in Sensor Control since I like the Sensor Control method of flashing a message and disabling the create button better.

I have also added the framework to put in “Tool Tips” throughout the web interface to help explain things on the fly. I only put a few in the Graphing section to start but will add more fairly soon.

Let’s see what else… I created a class to start a Thread and monitoring it so I can show the running status of different parts of the program. I just need to finish up on the Trigger monitoring, since it actually starts a thread for each sensor type. It’s already working, it’s just not showing on the information page right.

I’m making decent progress, so more to come soon.

New Release!

I have now managed to go over most of the program for testing and things seem stable. So 27.336 was the magic number. There are a lot of developments since version 26.x, but I won’t go into them tonight since most of the changes are in previous posts and definitely in the changelogs.

This release is the first to have a section dedicated to replacing the management features of the Control Center. It already does most things better than the Control Center program, especially around downloading sensor data from multiple sensors. I’ll be making big changes to the Control Center and re-branding it. It will focus on Data manipulation instead of Sensor Management. The HTTPS web portal will take up the management of single and multiple sensors. This release also adds support for both Luftdaten and Open Sense Map weather monitoring services.

I have started to customize some of the HTML components to make them a bit more modern. The checkboxes and radio boxes are slightly fancier now. A small gesture of things to come.

I feel like I should keep an SD card of each version pre-installed to see how things change over time. Thanks to GitHub keeping all versions in one form or another, it shouldn’t be too hard.

That’s it for now.

I just spent the last 3 days or so testing, fixing and refactoring. The changes are definitely in the right direction but there’s a lot more to do. I’m not sure how much more refactoring I want to do before releasing it into the Stable channel since each refactor brings the possibility of new bugs, and new bugs take time to find and fix… which again reminds me I need to work on more Unit Tests. I was working on tests before, but the ‘requests’ module wouldn’t work on the local sensor for testing. I think I found a few workarounds that I’ll test later, including a httpx module that says it does work locally with flask apps and I was also thinking I could run the test through threading or a multiprocess so both tasks can run in parallel.

In other news, I created a kind of “lock” to ensure sensor data is not being retrieved from the same sensor at the same time. This should prevent any sensor retrieval issues when multiple threads access the sensors. Basically it sets a variable as True or False. If said variable indicates the sensor is in use, the program simply sleeps for 100ms and tries again. If it’s still not available, it waits some more. This will also lead to a refactoring session because I previously loaded the sensor_access module at the start and passed it as a variable to other functions. This was a failed attempt to ensure single sensor access because it was passed to other functions in threads so multiple sensor access could still occur. So now I’ll most likely remove all the sensor_access passes into module imports.

Besides all the fixes and cleanups, I also added a few minor improvements like more colour coding in the reports, adding sensor links to IPs in Sensor Control Online Checks, logging improvements and a bunch more I can’t remember at this moment.

That’s it for now.

After finishing up on the Sensor Control section, I committed the code and started refactoring for clarity and simplicity.

To start, I re-did Routes, Render templates and post checks from classes into flask blueprints. This allows me to break up all the flask routes into multiple py files. It took all day, but it “feels” (or should I say “smells”) better. This clean up should make it easier to do future modifications and additions. I still have to review and refactor the Sensor Control code but that will be nothing compared to moving around all the flask routes and co-functions!

There are only a few minor tweaks I want to do, then it’s testing time… which reminds me, I need to work on unit testing… Although I might start looking around for other test suites that are a bit more friendly or advanced then Python unit tests.

Things are coming along nicely. I expect to release a new version to the stable channel within the next week.

That’s it for today.

It’s getting time to release another version into the “Stable” Alpha channel.

I have been working on Sensor Control for the most part and have added the following features.

• Online Status – Now Creates a new page with Sensor IP, Response Time and Sensor Name.
• The Reports for System, Configuration and Test are pretty much the same with a few minor tweaks like colour coding response time and adding total RAM with % RAM used.
• Added “Relay and Direct” download options.
  • With Relay, all files are collected and zipped on the local sensor
  • Download buttons are enabled upon zip creation completion
• Download Zip of all 3 Reports – Creates a zip with all 3 reports.
• Sensor Databases – Creates a zip of all online sensor databases.
• Logs – Creates a zip of all online sensor logs
• The Big Zip – Creates a zip of all online sensors Databases + logs and add all 3 reports

This section of Sensor Control is now pretty much done. I did some sloppy coding to get it working, so I’ll have to review and refactor it. I have tested using it most ways, and it seems stable, but I’m sure I’ll find an extra bug or two. I’m also not sure about the RAM limitation of the Pi’s, because even when using zipped files, the Raspberry Pi doesn’t have much RAM. I created a function to save to disk instead of memory should the database downloads be larger than available memory, but I’m pretty sure I’ll have to do a bit more to get it to writes from the HTTPS download right to disk, instead of putting all the databases into memory and then writing to disk.

Let us see… what else changed… O I’m zipping Database delivery over HTTPS by default, as it can reduce the download size of the Database A LOT! There’s more, but I’ll leave that to the changelog on GitHub.

New Release soon!