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!

I have Sensor Control Reports complete. I even upgraded the configuration report to colour code on/off items and include more settings. I still don’t really like the layout of the IP’s and functions… but I’ll worry more about that later, and just concentrate on the functionality. I have the HTML layout complete for configuring online services in Sensor Control as well.

Sensor Control is coming together fairly well. It shall be a worthy replacement for Sensor Control Center. I might end up stripping down what Sensor Control Center does, so it concentrates on data manipulation, instead of sensor manipulation. Since data manipulation is where you want real computing power, that’s the direction Sensor Control Center should go… which means it probably needs a name change… hmm something like… Kootnet Data Manipulation? or … Kootnet Sensor Companion? Probably more along the lines of Kootnet Sensors Analytics. Yeah, I think I like the last one.

This means I have a fair amount of work ahead of me. I need to finish off the new Sensor Control, then re-model Sensor Control Center into Kootnet Sensors Analytics. This means I also have to add advanced analytical abilities to Kootnet Sensors Analytics, AKA, put in some AI learning to analyze the data and find neat patterns we would miss ourselves. O I also need to work on tests.

O I added the ability to download the Sensor Database or Logs from whatever sensors you have listed in Sensor Control. one click to Download all sensor logs and Databases to review at a later time. I have also been thinking about adding a “Download the ‘Full Package'” option that would combine reports, databases, and logs of all listed sensors into a single zip file. This would make it especially easy to “grab ‘n’ go”.

It was surprisingly easy to get Kootnet Sensors installed on Ubuntu. After tweaking a few Raspbian specific areas, it installed just fine!

So this is awesome and will help with development, as I can test things on much faster systems before deploying to the Pi Sensors. I can also run it from my development environment now (making sure the original service is disabled). So yay!

I suppose this opens up the possibility of using this on other platforms too, like Windows. I have no plans to support Windows as a sensor but it’s nice to know someone could donate time to add support or fork the project.

I just wanted to say it works on Ubuntu. W00t.

I had someone email me about my program recently who asked if I was going to support more online services like Luftdaten. This was great, because I posted a few days before, asking what other Online Services I could add support for. In fact, I still have gotten no replies on the forum post asking about other services. Through Luftdaten, I also found Open Sense Map, which I am adding support for right now.

Luftdaten is already working and supported but Open Sense Map has a much more complicated API with Logins, Tokens, Station ID and even Sensor IDs (one per sensor). It looks like the API is pretty comprehensive, as I can even create new accounts, sensor stations, change sensor settings, etc. So far I have 2 sensors uploading to Open Sense Map with manually set Sensor ID’s and such, so next, I want to be able to just enter in a Username / Password and have the program create the sensor under their account with included Sensor IDs and such (Program use Simplicity is a project goal).

I modified my Graphing to use multiprocessing instead of threading. There was no difference in the time it took to finish a graph, but the web interface seemed more responsive during its creation on the Pi’s with more then 1 CPU core.

Let’s see … what else… I have started on the web portals “Sensor Control”, which allows interaction with multiple sensors (up to 20 right now). Sensor Control is going to be a “replacement interface” for the PC software Control Center. I don’t think I’ll actually get rid of the Control Center, as it can create graphs on much faster computers and interact with offline databases but I will be putting more focus on the Web App’s side of things. So far it can check to see if other sensors are online. Next, I’ll be adding the ability to create system and configuration reports, then the ability to change settings on multiple sensors at a time (Good for the deployment of multiple similar sensors).

That’s it for now.

I have added a new section in the Web Portal for 3rd party online services. Right now it supports a service called ‘Weather Underground’, which from my understandings is a website that hosts a collection of environmental readings provided by citizen donating the use of their weather stations. To get it working, you need an account with Weather Underground, then you can add a device on their website to get an ID and Key, which is what you need to get it working.

I also created a post about my Sensor Project on the Raspberry Pi forums. I’m hoping to get a bit of feedback.

This marks the final release of Alpha.26.324. Since I’m mostly making changes to the server and HTML side of things, I’m releasing Control Center versions that look like this “Alpha.26.x”, indicating it was released supporting the Alpha.26 branch.