A bit of history
Quite a few years ago I bought a WS1083 weather station locally from Scientific Sales – the black one in the image. I’m not sure now if this was the first or second. For some time it was running stand-alone and I would occasionally connect a Windows XP computer running Cumulus to extract the data. Then one day I plugged in the PC with the clock set back pre-2000 (needed for some other crappy software) and something nasty happened to Cumulus and all the data. This was very disappointing but as I was getting rid of Windows it was a chance to find a Linux alternative.
The best option at the time seemed to be wview. So a basic vwiew install operated for years with only the occasional linux update, the last few years on a AMD mini-ITX board running Ubuntu server. This board also runs another service, so it’s not complete overkill, but probably does complicate maintenance.
Back on March-11 this year the data stopped coming in. It turned out that the sender unit on the outdoor mast had failed. I couldn’t find a new sender unit so I bought a new weather station of the same style. The new one is a WH1081PC, very similar but would not work with the existing wview.
Time to update Weather Station and PC
As wview hasn’t been updated in a couple of years I decided to have another look at weewx. I looked at it back in 2014 but wview was working so it didn’t go any further. This is also a chance to get off the mini-ITX board and onto a low-power arm board.
According to the weewx site, the sqlite database format is the same as that used by wview. So it should be reasonably easy to import the years of existing data. We will have a 2 month gap.
I have a couple of spare Orange Pi Zero boards (O-Pi-Z) that may do it and I’ve seen a few examples of the Raspberry Pi (R-Pi) being used with weewx, but I am not a fan of the R-Pi. How difficult could it be 🙂
Long story short – I downloaded Armbian for the O-Pi-Z, installed it, installed weewx, installed Apache2, and Apache2 wouldn’t work. Starting with a fresh Armbian I installed Apache2 and tested it then installed weewx, which broke Apache again. The solution was to manually add the Apache log directory. A lot of updates later and it was ready for the WH1081.
At 10.7 volts suppled, the draw of the O-Pi-Z and console averages 122mA. Thats only about 1.3 watts; much better than the 30-50 watts of the original mini-ITX board and HDD.
Now the FUN begins – not really
The problem I had was that weewx only updated every 30 minutes, even when the polling interval was set to 5 minutes. The result is only 48 samples per day and some very thin looking graphs.
There is a configuration file for weewx that sets many parameters. For the WH1081 we use the fineoffset driver. The utility wee_device can display console status, weather data and can change the archive period which comes defaulted to 30 minutes.
There is a lot of useful information on the weewx wiki, forum/group and other users web sites. The WH1081 is a member of the Fine Offset family. The same units are re-branded with many names. I don’t know what all the variants and differences are, WHxxxx, WSxxxx and so on. From what I have read the protocol is proprietary but has been reverse engineered. Scientific Sales sell a range of units, a couple of brands, the Aercus Instruments units appear to be very similar to the Fine Offset.
I didn’t want to just buy another unit such as the Aercus WS2083 from Scientific Sales, because the description, function and manual suggest it is basically the same unit as the WH1081, and will probably also have the default 30 minute archive period.
I did try the WH1081 connected to the Cumulus software running on a Win-7 PC and it seemed to work OK. I did read several reports of people having communications problems with Fine Offset stations and Cumulus a couple of years ago. It seems Cumulus may have since been updated to solve these problems.
The Solution – as best I can tell, at the moment
Another 4 or 5 hours research, adjusting and testing, and I have it working. The way it works seems a bit complex, but it is what it is. It seems that weewx receives data from the console archive even when it appears from the settings to be polling at the pre-set interval. This does allow weewx to recover archived data when the PC is not connected or down.
The console reads the sensors every 48 seconds (apparently) and has a default archive period of 30 minutes; where it writes to the eeprom buffer – I guess average and accumulation of data collected over the past 30 minutes. The default 30 minute archive period can be changed to 5 minutes. If polling is possible, apparently it should be longer than 48 seconds and not a multiple of 48 seconds to avoid console internal conflicts.
The data delivered from the console has a 2-byte trailing code (magic numbers) that seems to have changed function a few years ago and confuses drivers that haven’t kept up. When USB is first connect the numbers are 55 AA and the utility “wee_device” can change the archive period to 5 minutes. But soon after wee_device no longer works, just showing some errors. wee_device can also report console status and current weather data, so it’s easy to see when it fails “sudo wee_device –info”.
I suspect the failure occurs because the magic numbers start out correct, but after a period one of them changes to indicate something about the console (count of data records available ??), which upsets the weewx driver.
So the solution is, to unplug the USB for a minute, plug it back in, lsusb confirms the device, then enter “sudo wee_device –set-interval=5” and answer “y” to set a 5 minute archive period. It takes 20-30 seconds to complete and returns. After this the WH1081 provides much more information to weewx and the graphs become complete lines.
Fine Offset Station notes
Apparently fine offset stations produced since about 2010 have a habit of locking up the USB link. The station continues to gather and archive data, but the USB link is dead. The only known solution is to power-cycle the console, not weewx. Weewx supports USB hub power control and can detect the condition and briefly power down a console connected to a particular hub port. The console must not contain batteries and the USB hub must support per-port power control. I have experienced this problem several times in 4-5 weeks with a WH3081 console but so far not with the WH1081 console. It is such a serious problem that I suggest not buying the WH3081 system.
After resetting the console, it takes a long time before Weewx starts working again. It is usually necessary to restart Weewx.
Orange Pi Zero
I’m not using the wifi but will leave the antenna connected. I had a lot of trouble with the Orange Pi Lite and gave up on the wifi after some time, but suspect it shouldn’t be that difficult. The Lite has no wired ethernet, so wifi is essential.
I downloaded the latest Armbian image for the O-Pi-Z and used dd to put it on a 16G micro SD card. Then did the usual basic setup, fixed IP address and updates. The first time I tried the update one failed, running out of memory (kernel update). A reboot and the next attempt worked no problem.
The O-Pi-Z apparently supports POE, but only with 5V DC applied via the ethernet port – not really very useful. To suit my computer cabinet power supply, I have attached a mini voltage regulator fixed at 5V. In this case, remove the miniature pot and fit a 470K and 47K resistors in parallel.
The O-Pi-Z has two additional USB ports on the header along the front edge. An adapter board or cable would be needed to plug in an extra device.
The RTC is a miniature module intended for the Raspberry Pi. To make it sit over the O-Pi board, I moved the 5-pin connector to the other side of the board. The I2C connector pin function is the same I also noticed that a small ceramic capacitor on the board was cracked, so I replaced it.
A small board on its own with wires hanging off is difficult to handle and at risk of being damaged. So I made a small gear-tray housing using 3mm foam-pvc sheet and pvc guttering cement. This secures the two extra USB ports off the header – for a 16GB thumb-drive and a USB camera; a spare Logitech C170.
SD Card Reliability
Like the R-Pi, it runs the OS off a micro-SD card. This is a problem because weewx is continually writing data to the sqlite data file and creating the html files. Apparently this can kill the micro SD card pretty quickly; possibly under 6 months.
The sqlite data file can be moved to another drive, possibly a USB stick. A ramdrive folder under var/www/html for the weewx folder would hold the html files that are recreated every few minutes. The log files should also be considered.
Another option may be to put the database on a USB stick and back it up to another device then make the SD card read only and run from RAM.
to-do: consider something like rsync to back up the database to another drive.
I tried using a Transcend 8GB class-6 card but it wouldn’t boot – recall having this problem before. So I have picked up a couple of Strontium 16GB class-10 cards that do boot and seem to run fine.
A spare Logitech C170 USB camera does work and can be used to capture regular images to file. The file can be used with weewx or displayed elsewhere.
Update to WS3081
NOTE: The WH3081 suffers from the known USB lockup problem. This causes the console to stop transferring data to Weewx, which stops updating the web pages. Apparently, being a fault with the console, it also affects the Windows software.
My suggestion is: Don’t waste your money on the WH3081.
The WH3081 included the solar charging of the sender batteries (2 alkaline rechargeable AA cells), light level and UV radiation sensors on the top of the original vented outdoor sender. When assembled this made the sender unit quite heavy and in my opinion too much for the single mounting bracket at the bottom. It seemed that vibration and wind could cause the bracket to fail. My plan is to mount the rain gauge off the pole to avoid vibration, making the extra bracket available. Trimming the end with a hole-saw and drilling a cable-tie hole provides a top bracket the well secures the sender.
Wind Sensor Balance
The wind direction and speed sensors were out of balance. I’m not sure how much this matters, but it’s easy enough to fix while preparing the unit in the workshop. A small 3mm bolt and and brass nut were just right. The black mark is North to make alignment easier on the roof.