Monthly Archives: December 2019

Sensor Control Enhanced!

I have finally finished up the Sensor Control section of the Web Portal. All configurations can now be edited and pushed to multiple sensors using Sensor Control. Once I do some testing, I’ll release this into the stable channel. Besides finishing up on the Configuration section of Sensor Control, I also added drop-down buttons for upgrading, power commands and misc other.

I would like to add the ability to review and add notes next, but I might space it out with a bit of reading. I got a new book “Modern Python Standard Library Cookbook”. I want to be able to do as much coding using the Standard Python Library as possible, so I can limit the outside requirements. This should also make my code cleaner and more efficient.

A new release is coming soon. As always, feel free to check out what is coming by upgrading to the development channel, but be warned, the development channel can be unstable.

Sensor Latency Tests Added

I finally got around to adding Sensor Latency testing. A button has been added under the “System Management” page to run it. The latency tests tell you just how long it really takes for a sensor to return a reading. This is required knowledge to set trigger variances in the seconds or less, so it doesn’t end up building a queue of reading requests waiting to get data. I have already set each sensor’s “multiple access wait times” to match more closely with how long it takes to get a sensor reading. This should improve performance when sensors are accessed at the same time.

Most sensors return data within 100ms (0.1 seconds). Some like the EnviroPhat can get a reading from each sensor within 10ms. But there’s one sensor, the light spectrum AS7262 that can take anywhere from 700ms to 8 seconds! I’m not sure exactly why, because my other spectrum sensors, like the BH1745 and the EnviroPhat, can grab readings in less than 20ms every time. I also checked the source code for the driver and how I set-up the API, and it’s set for under 30ms to get a reading for each of the six colours, so added up, it shouldn’t be much more than 200ms, and that’s assuming it can’t do them in parallel.

I have been putting off doing the configuration section under Sensor Control because I know I can actually get it to re-use my existing individual configuration pages without copying them … but it would take some creative re-working, and I have been lacking in creative motivations. Soooo… I think I’ll just copy-paste to get it working and refactor it later.

Kootnet Sensors Runs on Ubuntu

W00t, I made it so Kootnet Sensors can be run on Ubuntu (and probably other GNU/Linux systems). It just disables the hardware access functions but allows the web interface with access to “Sensor Control” to manage other sensors. Most changes were made to where the configurations are saved.

So this is awesome for testing! I can now just get it running from my Development Environment and test most HTML functions. It also does not require root access if there are no sensors.

Besides that, I also moved the sensor in use checks to the driver interface so nothing could bypass the check. The “Online Services” section of Sensor Control now works as well, except for setting the interval.

Things are coming along nicely.

Kootnet Sensors – Hardware Drivers Included

I have put the hardware drivers directly into Kootnet Sensors, instead of installing them with pip. This should ensure all the sensors work, regardless of the upstream project changes or updates I make to utilize new driver features. It took a bit of poking for the EnviroPlus sensor, but it and all other sensors I could test appear to be working well across the Pi Zero W, Pi 3b+ and the Pi4. I’m still wondering about including some of the other dependencies …

A few “bugs” have been fixed, such as making sure only one call to access a sensor is done at a time. Mostly around sensors that require a “keep-alive” thread, which bypassed the other in use checks. This should clear up errors around gas and the EnviroPlus’s particulate matter sensor.
I also made it so sensors that update multiple readings, even with single reading requests use a cache, so if the program is getting readings for all sensors (but through individual sensor reading requests), it can take from the cache for all requests made after the initial update within 1/2 a second.

The next thing I should really finish up is the Sensor Control section of the web portal. Once Configuration and Online Service sections have been done, it can pretty much do everything the PC Control Center app can do.

That’s it for now. Slow going for the short winter days and the long winter nights.

Kootnet Sensors Update

Now that Kootnet Network Testers are working well, I thought it was time to do a bit more on my Sensor Project.

I have started to integrate a version of each hardware sensor driver (the pip modules) into my program directly. The major reason for this, is I have already had 2 sensors change their functions in a way I had to fix my program to use it. This creates real problems because previous sensors don’t auto-update their drivers and conflicts start to arrive where it’s working on one but not another. I’m hoping I won’t have issues between the Pi Zero and the Pi3/4 due to the arm hardware differences. I’ll be sure to test it on all models before release, but so far the only one I am having any real issues with is the Enviro+. All the others have been entirely drop-in replacements. I think I have 4 sensors left to add drivers for, plus the Enviro+ I have to fix.
I’m happy to say that all the drivers so far have added up to about 500 Kbytes. So my installer is currently sitting at 1.5 Mbytes.

This change will also make the install much faster, as pip is not exactly a speed demon for downloading and install modules. I’m also considering adding other dependencies to the installer to make sure it will work, regardless of what happens with the dependencies own projects and even pip itself. But I’m also concerned about security with modules like Flask and the gevent since they are the internet-facing modules that you want to be patched and up to date. For now, I’ll most likely keep Flask and gevent as a pip install at the time of install, however that may change in the future… in fact, I suppose I could include the modules but then add a script to download the new version and copy it over the old one and restart the program… yeah that would probably work. I could even add an auto-update option for those modules at set intervals but disable it by default in case of issues introduced… actually… I can even have it update the module at the time of install.

Anywho, that’s what I’m working on now and once done, should improve consistent stability.