Monthly Archives: November 2018

Version 21.18 Released!

New Version out!  I was going to get pipenv working before release… but it looks like that’s going to take a bit more time.  
Here are a few highlights of this release.

  • Allow Live Graph on 3 point data
  • Merged Sensor SQL Interval & Trigger code & databases
  • Created Log viewer and downloader in Control Center
  • Tweaked System Report and added Installed Sensors to Config Report
  • Raspbian desktop and menu shortcuts added
  • Created uninstaller for sensors
  • Changed locations for sensor programs, configuration and data to be more in line with Gnu/Linux file structuring
  • Updated help files
  • Bug fixes and code optimization

Due to the location and database structure changes, this version is not compatible with older versions.  I recommend doing a clean install if you have  a previous version installed. 

Stuff

I spent some more time refactoring the Raspberry Pi Sensor code.  For one, I have the import code for each sensor, in the init part of the sensor access class, that’s created per sensor.  AKA, creating a class instance of a sensor, will then pull in the needed libraries at that time.  I did this originally so unneeded sensor libraries would never be imported, saving time and resources.  However, I then realized that I create the sensor object every time any sensor data is taken, which re-initializes the sensor every time!  Long story short, I moved the sensor access object instance creations out of the sensor retrieval functions and into the primary python program before the main loop.  It only initializes sensor access for sensors specified in the “Installed Sensors” configuration file.  This means sensor readings taken, will re-use the same sensor access instance that was created at the start of the program and only create access instances for installed sensors. 

Doc strings have been added to all functions and classes in the raspberry pi sensor code, and I started to get pipenv working for the package management and virtual environments for my programs… but it keeps erroring out on pipenv install.  It almost seems like its timing out on installing the packages, but I can’t be sure since I’m not sure where it stores the logs if it creates any.  In theory, it sounds like it will simplify the install process and help keep a consistent base to run on, but it looks like it will take a bit more time to have it function as intended.  

I was hoping to get pipenv working before creating new Gnu/Linux install scripts, and I was hoping to have the install scripts working before my next release.  So I’ll continue to diagnose the pipenv issues, in hopes that I can use it for with the new installers.  

Hope everyone’s weekend went well!

More SQL write modifications

I figured it was about time to re-look at the “write to SQL DB” code, especially for the datetime entries when writing to the database.  Long story short, I had SQL input the datetime values at the time of recording, but because the code grabbed a few readings to check against the variances, the data ended up being entering with fairly inaccurate datetime correlations (by hundreds of milliseconds or more).  

So, I changed the code in a few ways.  First, I found out how to get the exact same formatting for the datetime as SQL was using, and used that at the time of actually getting the sensor data (through Python datetime).  I also made the Trigger variance checks & database recording, work on 5 readings at a time.  If any of the 5 readings trigger a recording, all 5 will be recorded, so in theory, it will record entries before and after the event that triggered it. 

That’s it for today. 

Live Graph updated

w00t, the Live Graph now works with all supported sensors, AKA Live Graphs work on sensors that give 3 data points as well as just one. I also changed the layout to make it look “cleaner”.  

I have been thinking of a few other features to add, like LED / LCD screen support for displaying sensor readings on the sensors themselves, making the joystick on the SenseHAT functional and adding default reading offsets to the sensors themselves, and sending it with the sensor data for whatever reading it might be.  This will allow the Control Center to choose between the hardware default and a custom setting.

In other news, I have put a few more sensors around my house, to see how the temperature fluctuates in different parts of the house, during different times of the day and night.  The recordings should show me how the heat moves to different parts of the house, at what temperature and how long it takes to get up to temperature, and if certain rooms get more or less heat during the process.  With winter coming and living in a Mobile Home, there should be some good differences!

I have been testing some power systems for the Raspberry Pi, so that I can ultimately have a solar powered system, that charges a battery to keep it running at night.  I tried the “MP2636 Power Booster”, but had mixed results… it seems OK on my one Raspberry Pi 3B+, but it failed to stay on or even charge the battery for a few units…. I suspect polarity is wrong on my cheaper china batteries, but that doesn’t explain the other RP Zero W rebooting when swapping the primary power source.  Long story short, I don’t think the “MP2636” is going to work for my needs.  Next up is one made specifically for the Pi Zero, called “Juicebox Zero”.  It looks very promising, but I have to solder it on, so I’m putting it off for a bit.

** Few days later ** 

Guess I forgot to actually post this a few days back.  I have made some other major changes since the top half of this post.  For starters, I just did an overhaul of the write to SQL Database code.  I merged my 2 programs into one, so now both Trigger and Interval code run from the same python program.  I was mildly torn about doing this, but I think it’s ultimately for the best, not only on system resources and response times but for dealing with the readings as well, as you can now graph both Interval and Trigger readings from the database to a single graph page.  It’s also much nicer to deal with a single database for downloading and storing.

I have changed the “Clean” update code to run as a service (Manual start one-time run), this allows me to fully delete the main folders and files, without terminating the very program that’s doing it, which was preventing the re-install process after deleting everything… AKA it would delete everything and stop.  Now, the program initiates the update service to start, which keeps running after the program that started it, is terminated.  

What else was done… O yes, I added what sensors are installed in the Configuration report, worked on the Unit Testing and did a fair amount of refactoring.  I’m sure there were other things too, but I can’t think of them right now.  

Since I did a few overhauls in the code, I’m going to test things a bit more before an updated release.