Acuparse Troubleshooting Guide¶
This guide is meant to assist troubleshooting common issues with Installing and using Acuparse. It is not a complete guide. If you require assistance, please reach out to the project via Community Support.
Initial Readings¶
When you first install Acuparse, you may receive a No Data Received! message on your dashboard. Acuparse needs to receive and process it's initial updates from your sensors, before the dashboard can be rendered.
After your initial readings are received, Cron will process them into archive readings. If you see a No Archive Data! message, there may be a problem archiving your readings. Some dashboard features require Archive data. It's critical that your Cron is running the Archive job. Look for the message (SYSTEM){CRON}: Archive Updated in your syslog. When the Archive job has not yet completed successfully, you'll see an error on your dashboard and no data will be displayed.
If your dashboard does not update after 5-10 minutes, check your syslog to ensure data is flowing. Additionally, check and ensure your DNS is redirected, OR you have set your hostname on the Access directly. See also DNS Redirect.
Logs¶
If using Docker, set DEBUG_ENABLED=1 in your acuparse.env file to include the Apache Error and Cron logs in acuparse logs. Then acuparse restart to update the container config. Syslog is always available.
Syslog¶
The best way to troubleshoot your installation is to view the syslog. All Acuparse output is logged there.
tail -f /var/log/syslog
Apache¶
Access Log¶
The Apache access log contains all the data Apache has received from the web. Including the readings from your Access/Hub. Checking this log will indicate if Acuparse is receiving data from your devices.
tail -f /var/log/apache2/access.log
Error Log¶
The Apache error log contains the errors and warnings generated by Apache and PHP. Viewing this log can indicate if something is wrong with Acuparse.
tail -f /var/log/apache2/error.log
Cron Log¶
You can check for errors running cron jobs in the cron log file.
tail -f /opt/acuparse/logs/cron.log
Sensor ID's and MAC Addresses¶
Without a MAC configured for your Hub or Access, Acuparse has no way of knowing what data it should listen for. You must set a MAC and Iris (5-in-1) or Atlas (7-in-1) sensor ID in the admin settings to begin receiving and uploading your readings.
Sensor ID's/MAC addresses are located on the sensors themselves. If you can't locate them, the syslog will report all sensors and MAC addresses it does not recognize.
cat /var/log/syslog | grep '(SYSTEM)\[ERROR\]'"
for sensor ID's the log format is (ACCESS/HUB){ATLAS/IRIS/TOWER}[ERROR]:
Cron Job¶
The cron job is essential for the proper operation of Acuparse. It runs the archiving, update checking, and external uploads. If your station remains offline and/or there are no updates to external providers, there is a chance this is why.
Run the following commands to update your crontab.
crontab -l | { cat; echo "* * * * * php /opt/acuparse/cron/cron.php > /opt/acuparse/logs/cron.log 2>&1"; } | crontab -
To check for Cron errors, see Cron Logs above.
RaspberryPi's¶
See RaspberryPi Direct Connect in the install guide to configure your RaspberryPi for direct connection to the Access.
When you are directly connecting your Access/Hub to a RaspberryPi, you must change your upload servers to the secondary ones. This is due to the fact that the Pi is redirecting your DNS locally and without changing the upload server, you can end up with a never ending cycle of readings.
See MyAcuRite Upload URL's for more details!
Installation Errors¶
If you experience unexpected results while completing the web install, try removing your config file and retry.
sudo rm /opt/acuparse/src/usr/config.php
In more extreme cases, you may also need to remove and reinitialize the Acuparse database.
Access Device¶
If you're not receiving data from your Access, ensure you have a DNS resolvable hostname set for the upload server and/or a DNS redirect in place. Then, reboot your Access. The Access can at times require multiple reboots to begin sending data. The Access also needs to communicate with Acuparse using TLS1.1. When using LetsEncrypt, this can be an issue as certbot can sometimes overwrite the apache config and remove TLS1.1 support. If you're having issues with your Access, check your /etc/apache2/sites-available/acuparse-ssl.conf file to ensure TLS1.1 is enabled. If you have LetsEncrypt ensure #Include /etc/letsencrypt/options-ssl-apache.conf is commented out. The default configuration is stored in /config in your Acuparse directory.
MyAcuRite Offline¶
If MyAcuRite is offline, Acuparse will respond to your Access and store your readings, but they will not be backfilled to MyAcuRite after their outage is over. The Access is capable of storing the data and sending it later but when used with Acuparse, the Access will continue to think MyAcuRite was online and the readings stored.
You will receive a warning in your syslog when this happens.
Extended Outages¶
When your Access stops sending data for an extended period of time, your Acuparse data will become stale. This creates errors in your dashboard and api. Once your Access comes back online, you will need to wait for enough data to be received before some calculations can be made. This can take up to 24 hours.
NTP¶
The date and time are critical to Acuparse operations. Both on the server and on your Access device.
The Access device will check for NTP on pool.ntp.org. Ensure your Access can connect to NTP here, or redirect your DNS for pool.ntp.org to a local NTP server.
If the installer was not able to configure NTP for you, review your OS documentation for the proper way to configure NTP on your system.
Cisco Switches¶
If your Access constantly reboots/reconnects when connected to a Cisco switch, enable Portfast.
config terminal
interface FastEthernet0/XX
spanning-tree portfast
end
Hub Device¶
MyAcuRite Support¶
MyAcuRite has terminated support for the SmartHUB. Acuparse will receive and store these readings and respond to your hub. Readings will not be uploaded to MyAcuRite and will only be stored locally. You can still use the Hub to upload to external providers.
Inaccurate Readings¶
Acuparse filters Access readings for erroneous readings by default. See Filter Access Readings for more details.
If you have old erroneous readings in your archive table, you can clean them using MySQL commands.
Modify the below queries to fit your requirements.
Local Install¶
Main:
mysql -u<USER> -p<PASSWORD> acuparse "DELETE FROM archive WHERE tempF='-40' AND (relH='0' OR relH='1')";
Towers:
mysql -u<USER> -p<PASSWORD> acuparse -e "DELETE FROM tower_data WHERE sensor='<SENSOR_ID>' AND tempF='-40' AND (relH='0' OR relH='1')";
Docker Install¶
Main:
acuparse console
mysql -h$MYSQL_HOSTNAME -u$MYSQL_USER -p$MYSQL_PASSWORD acuparse -e "DELETE FROM archive WHERE tempF='-40' AND (relH='0' OR relH='1')";
Towers:
acuparse console
mysql -h$MYSQL_HOSTNAME -u$MYSQL_USER -p$MYSQL_PASSWORD acuparse -e "DELETE FROM tower_data WHERE sensor='<SENSOR_ID>' AND tempF='-40' AND (relH='0' OR relH='1')";
Git Repository¶
If you make changes to the source code locally, your changes will break git pull unless you commit or stash them. If you receive errors while doing a git pull, you can remove your changes and reset your code back to release state by running git reset --hard.
If you're interested in learning Git, this is an excellent resource: Git Exercises.
Docker Container Won't Start¶
Acuparse moved to Debian Bullseye as the primary container image. Some users running Acuparse on systems with an older Linux Kernel may experience an error similar to below when starting Apache
acuparse_1 | Starting apache2 ...
acuparse_1 | [DATE] [:crit] [pid 307] (38)Function not implemented: **AH00141: Could not initialize random number generator**
acuparse_1 | Action 'start' failed.
acuparse_1 | The Apache error log may have more information.
If you receive this error, update your docker files to use the legacy Buster image.
acuparse/acuparse:busteroracuparse/acuparse:<VERSION>-buster