A couple of days ago, I re-installed the archiver. The archiver moves the data files of the day to the 'archive' subdirectory. The compression function is still disabled as the file sizes are too small to compress daily.
I may run the compressor function monthly or yearly.
The service/timer scripts are tested, installed and running.
What's left:
1. Limit switch
2. Solar sensor installation.
3. Possible installation of a replacement relay for the actuator power supply.
Up util now, I've booted the system periodically, or however often I wanted.
The idea now, is to run the system continuously. This will allow the system to 'wake' in the morning, and 'sleep' in the evening, all the while collecting data and adjusting the array position during operating hours.
The mechanism will be setup in the computer operating system using services and service timers. The php and python scripts collecting data and array position, currently rnon boot, will be controlled by the operating system timerss/servoces.
There is a problem with the RPi's ability to run uninterrupted.
The charge controller is not connected to the router by cable, but by WiFi.
A problem occurs when the router/modem is powered up. Most of a line of data is lost.
The data collection script collects fifteen data points. Fifteen for each line of the table, a CSV file.
The collection is done every thirty seconds.
When the router/modem is powered up, the first eleven or twelve are lost. This occurs for only one line during each power up, but is still troublesome.
I intend to leave the RPi running continuously. I also have a script that publishes the data on a webpage. When the data gap occurs, the graphing script stops plotting. the page is blank.
Is there a way to disable the WiFi during a data collection operation?
I had the problem a year or so past and concluded the computer was being overloaded with running processes or had speed limitations. At any rate, I slowed down the sampling rate to once every thirty seconds for the Epever controller. That solved the problem then.
I can be satisfies with a one minute sampling rate, but the problem disappeared after an adjustment.
The devices are labeled A-I.
A: actuator power supply booster.
B: booster relay control board.
C: actuator direction control relay board.
D: screw terminal block expansion board.
E: expansion board on top of Raspberry Pi 3B+.
F: Raspberry Pi 3B+.
G: ADS1115 analog-to-digital converter (ADC) for the solar sensor mini-array.
H: solar array charge controller.
I: Inverter, 12VDC to 110VAC converter, 1KW.
Click on the image, then click again to enlarge.
The solution, for me, was to search the web thoroughly, and find information.
I did and found the solution.
The hwclock service had been replaced by a link to a NULL. I removed the link and re-installed the hwclock service.
I re-installed the NTP service.
This is not all, but the NULL link was the key to solving the problem.
Local/network timing is now working.
Two scripts run during boot and write headers to daily log files. Recently, the headers are not written but the data is logged.
The problem seems to be the NTP system time software. This software maintains and updates the system time and clock. An internet connection is required.
There is also a RTC hardware clock I have installed.
I am now testing to discover whether the NTP service is preventing the headers from being written.
In my theory, if there is a web connection when the Pi boots, there is no problem. Howerver, if there is no web connection, the NTP service prevents the first write to both log files, i.e. the headers.
Two options exist.
Turn off the NTP service and rely on the hardware clock I installed. The clock loses 63-110 seconds per year. If the battery goes bad, the time will be incorrect and log files will not be useful since the timestamp will be wrong. This is a major concern since the Pi is intended to run continuously, without interruption, and unmonitored. This option makes the Pi portable.
The second option is to make sure the first boot of the Pi follows the web boot. Thus the headers are written. The NTP has no effect afterwards and no web connection is required. The NTP will automatically update when a web connection is detected.
Turn NTP on : sudo timedatectl set-ntp True
Check result with : timedatectl status
I have installed a mechnical limit switch on the linear actuator. This switch will close when the actuator reaches the maximum point of retraction. A signal is sent to the Raspberry Pi computer informing the software the switch has been closed and maximum retraction has occurred.
The purpose of this is to prevent overloading that can occur when the actuator motor is still trying to retract after the retraction physical limit has been reached..
The overload occurs when the software boots and automatically performs a full retraction, and the actuator is already retracted.
A different problem is going to be addressed as well. The RPi has Dupont jumpers as connecting wires to other devices. These jumpers have a #28 AWG wire gauge. This is too fragile and difficukt to work with if soldering needs to be done. A screw terminal breakout board will allow dupont jumpers to connect the Pi to the terminal board and external devices with heavier gauge wire, to connect to the board using screw terminals. The terminal board is a 'hat' and plugs into the Pi.
