Author Archives: chad.e - Page 2

Almost ready!

Kootnet Network Testers are almost done! That’s the new name I decided on because it’s already in the GitHub name. On Raspbian, TCP/IP 4 can be configured on both the Ethernet and Wireless adapters, as well as the wireless connection settings, such as SSID & passkey. There’s some more testing to do and a few bugs to fix. For one, I was able to test over the wireless network (cool!) but it showed that the MTR readings were getting cut off if more then double digits on the WaveShare display (doh!). The Web interface had no such issues and ran great.

For testing, I set static IP’s on the ethernet adapters of 2 Raspberry Pi’s (a 3 and a 4) and connected the wireless to my network. I used the wireless connections to control the 2 units through the Web Portal after connecting both their ethernet ports to a single ethernet cable. The tests ran great and I have already seen some interesting deviations of speeds, depending on a few factors like what systems are being used, cable and route. It was kinda funny to test my wireless speeds from my office, as they were mostly in the single digits.

Things are on track for an end of the month release. Besides testing and bug fixes, I also have to add a few validation checks for user input around the network configurations. I have a bunch of other ideas, but they’ll have to wait until after the initial release.

Soon!

Ethernet Tester Update

Things are going very well on the Ethernet Tester front. I might have to change the name because technically, the testers can test all kinds of networks, not just Ethernet, especially since it can install on Ubuntu, but I’ll think about that later.

So to start, I’ll list what works. For hardware, the WaveShare 2.7″ E-Ink (both versions) works well, same for the Installer Script. Some of the HTTP sections still need work, but most are operational.

  • HTTP Portal
    • Working
      • MTR / iPerf 3 Tests (Run & View)
      • Primary Configuration
      • Hardware Configuration
      • Online Upgrades
      • Power Commands (Restart + Shutdown)
    • Not Working
      • Ethernet & Wireless Configurations

The Testers automatically save every test run into text files on the computer itself, under the test_results folder in the program’s install folder (/opt/kootnet-something-or-other directory). Each text file also has half an epoch timestamp at the end, so you can figure out which was the most recent run. I’ll later be adding a section in the HTTP portal to review past results in the near future.

Here’s a picture to illustrate some of the progress on the HTTP portal.

Main page show previously run Tests. Each test was run at a different time.

Ethernet Tester Development

The Development version can now actually be installed and used with or without a display. You have to open up the configuration file manually to edit, but it’s all functional! It’s also awesome it works on Ubuntu, so you can install it on pretty much any hardware to take advantage of faster network adapters and such.

I need to work on the Flask app to allow configurations. Luckily a good portion is already done, so it won’t take to long to finish this up. After that it’s QA, refactoring and adding in documentation and such.

I have also tested this on a Pi 4, both with and without the 2.7″ E-Paper display. Both worked great!

Expect a release soon!

Kootnet Ethernet Testers Update

I have spent some decent time on the Ethernet Testers and have laid most of the foundation to get things working, including the base for supporting different (or no) displays.

The next step is setting up the configuration & testing pages in the flask app. Once that is in place, I should be able to start testing it with the original display and without any displays. If all goes well, I can start adding other display support and different configuration options.

On a side note, it was cool to get my first fork on GitHub, which was of my Ethernet testers. I should get a bit more attention to the project once I finish the updates, especially with the Raspberry Pi 4 having a 1GB ethernet port.

I expect to have a release out of the new version sometime this month.

Kootnet Ethernet Tester Enhancements

So I have thought a bit about how I want the Ethernet Tester program to work and here are a few insights into what’s to come.

For starters, I’m breaking up the program into different server “Threads”. This will allow for more modular operations. Said threads would include Display, Interactions, HTTP config + access and iperf3.
Secondly, I’m creating an HTTP server for configuration and remote results access. This combined with the ability to configure the wireless through HTTP will allow the use of devices without an actual hardware display!

The HTTP configuration pages will eventually have options to do things like customize iperf3 settings, configure unit between display & secondary server, swap between supported displays, etc.

Right now I’m working on Refactoring and creating the new foundation to support these new features. This program is MUCH smaller than my Sensor program, so I don’t expect it to take too long. That being said, I will be playing around with things to see both my options and what works best. For instance, I’m going to be including all the required python files for the supported displays so you don’t need to use pip to get them (and should remain compatible regardless of how they change things upstream).

Once I get things working, I’ll post on the Raspberry Forums.

Change of Pace

I have done a lot on Kootnet Sensors, so I thought I would shift gears a bit and look over and enhance Kootnet Ethernet Testers. I have learned a lot since I made that one, so I think it’s time to fix it up and tweak it out. I have a few ideas already but I’ll keep them to myself until I think them through.

At some point, I’ll also finish up Sensor Control on Kootnet Sensors, then release another update.

Look for a new Kootnet Ethernet Tester release soon!

Re-working Triggers

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.

Updated Sensor Control to allow DNS + Port

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.

Released Kootnet Sensors Ver. Alpha.27.336

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.

Testing, Fixes & Cleanups

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.