Every once in a while, PV Bean Counter stops reporting results of by Sunny Boy 2500TL. Usually the problem is with the SUNNY EXPLORER software which has (at least) two irritating bugs:
Easy to spot: it can truncate the SunnyExplorer.sx2 file
Harder to spot: corrupted SunnyExplorer.sx2 file
The latter results in these log messages from PV Bean Counter:
9/2/2016 8:16:34 PM :T12 DeviceMgr_SE - Inf :DeviceMgr_SE: Sunny Explorer - CSV Export Failed
9/2/2016 8:16:34 PM :T12 DeviceMgr_SE - Inf :DeviceMgr_SE: UpdateFromDirectory - SunnyExplorer did not retrieve the expected date: 9/1/2016 12:00:00 AM
9/2/2016 8:16:34 PM :T12 DeviceMgr_SE - Inf :DeviceMgr_SE: UpdateFromDirectory - SunnyExplorer did not retrieve the expected date: 9/2/2016 12:00:00 AM
My usual follow up is to open the .sx2 file in Sunny Explorer. In this case this resulted in a MessageBox containing Cannot find Central Directory. It indicates that Sunny Explorer uses SharpZipLib and the .sx2 file is likely using ZIP compression.
In this case, the SunnyExplorer.sx2 file was not truncated, but filled with zero bytes.
Luckily that file gets backed-up often, so it was easy to restore:
A pair of 20MB hard drive compilations contain a full MacOS 7.0.1 environment that runs in a browser, and contains an assortment of applications spanning from 1984 to 1991 has appeared on the Internet Archive, with the entire bundle able to be run inside Safari.
I tried the obvious things to force Chrome on my Mac and Windows to use google.com as search engine when searching through the address/search box (omnibox). On Windows, this works fine, but Chrome on Mac (both are linked through my gmail account) keeps insisting to use google.nl no matter what, as all these fail:
I’ve never changed it, so it still points to {google:baseURL}search?q=%s&{google:RLZ}{google:originalQueryForSuggestion}{google:assistedQueryStats}{google:searchFieldtrialParameter}{google:searchClient}{google:sourceId}{google:instantExtendedEnabledParameter}{google:contextualSearchVersion}ie={inputEncoding}
Hosting Grumpydev Imageflair locally ended with two issues left: an empty image and my wish to include more complete StackExchange bits like the current StackExchange flair does.
I thought fixing the empty image would take a rainy day. It actually took a few rainy hours.
The drawback of having fetchmsttfonts is that the original Microsoft versions of these fonts are downloaded from corefonts.sourceforge.net each time the fetchmsttfonts package is updated, potentially overwriting newer versions of the fonts in that directory. If you don’t want that, use the trick at (not yet archived at the WayBack machine) font handling – install fetchmsttfonts, copy fonts, rpm -e fethmsttfonts, copy fonts back.
Having the fonts installed, I thought the only thing I needed to fix were the multiple references in config.php from that pointed to Arial.TTF. I took the poor man’s approach and just did this being in the directory of config.php:
cp /usr/share/fonts/truetype/arial.ttf Arial.TTF
Filled Imageflair
That didn’t work either: still no text showed.
So I decided to run imageFlair.php from the command line after setting $imageflair_debug = true; in config.php which then resulted in all sorts of warnings like
PHP Warning: imagettftext(): Could not find/open font
After reading I decided to build a small php-gd.tester.php script containing phpinfo(); and gd_info showing these portions for PHP GD (non-relevant bits stripped):
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Basically a Raspberry Pi has GPIO pins that can drive electromechanic (like mechanical relay) or electronic (like transistor+resistors or SSR solid-state relay). Examples:
Most solid state relays work with 3V-30V input signals, so these work: