So I decided it would be good to track a bit of the Sensor usage to help with troubleshooting as well as give the ability to monitor sensors uptime and such. To that end, I have created a “Call Home” type function. I know privacy is often a concern, so I came up with the following ideas (so far) to help track sensors and their issues, without compromising privacy.

To start, it sends the following information “Home” on boot and every 24 hours after that by default.

• A randomly generated (at first run) “Sensor ID”. This is a 32 alphanumeric string. This is used to ensure each checking in sensor is unique. It can also be used to help individuals if they run into issues, as they only need to give me that ID and I can find log entries to determine and resolve issues.
• Software Version. The version will help me identify where issues are and when issues are fixed.
• The last 25 lines of the Primary and Hardware Sensor logs. I chose not to include the Network log, because of all the IP’s it logs, which might be a privacy concern. It also only sends logs on A) start-up and B) when the logs have changed since the last sending. This will help keep bandwidth usage to a minimum.

What I want to do is expand this to be able to change where it “checks into” so it can be used to track sensors for the person using it if desired (AKA get check-in’s yourself, instead of sending them to me). I’m making both the check-in function and check-in tracking integrated into the Sensor Software, so one can turn any sensor unit into the tracker monitor. I also want to add the ability to disable it completely for those who really don’t want any data being sent back.

In other news, I have finally set up a Configuration transition to smoothly keep settings between upgrades. It should work well for upgrades between Stable releases, but might not be perfect if you are constantly upgrading to the latest development builds.

Besides working on my sensor tracking section, I also want to add 2x new sensor “types”. First being Particulate Matter 4 (one sensor supports that level) and Noise (on the Enviro+). Once those are in and more tests have been run, I will release a new version into the stable channel.

Here is a quick recap of some things done with my programming that I haven’t posted about. I should also be releasing a new version into the stable channel in the next few days or so.

Here’s a list of some of the major changes to Kootnet Sensors in no particular order.

• Added MQTT Support as a Broker, Publisher and Subscriber
• New Sensor Support
• Tweaked for faster performance
• Added Temperature Compensation based on Raspberry Pi CPU temp + multiplication factor
• Dummy sensor added for Testing and Demo purposes
• Added Display Configuration to customize mini LED display usage
• Added the ability to restart specific parts of the program without having to restart the whole application. Only changing the Main configuration, Installed sensors or Trigger variances will cause a restart of the whole app. Soon only saving Installed Sensors will cause a restart
• A ton of behind the scene changes
• Misc bug fixes and visual tweaks

Right now I’m just smoothing over the rough spots and fixing any bugs I find. I also want to add a FAQ’s section as well as make a decent manual.

So I haven’t updated for more then a month, mostly due to the kid being home due to school’s closing for COVID-19. So I just havn’t set aside the time to post here, however, I have still been coding, just to a lesser degree.

I’ll see about posting some updates soon, but until then, here are a few highlights.

• Released a new version of Kootnet Network Testers
  • Some decent additions I’ll go into later
• Bunch o additions to Kootnet Sensors
  • Such as MQTT Support and enhanced Display support