A good question came in from a friend today about what is the difference between Mostly Cloudy and Partly Sunny. While I had a general sense that it had to do with cloud percentages, I didn’t actually know the details. 10 minutes on google, and I got to the Weather Service Operational Manual (WSOM) Chapter C-11, Zone and Local Forecasts – section 8.6. In a more readable format:
| Term |
Expected Predominant or Average Sky Condition |
| Cloudy |
9/10 to 10/10 opaque clouds |
| Mostly Cloudy or Considerable Cloudiness |
7/10 to 8/10 opaque clouds |
| Partly Cloudy or Partly Sunny |
3/10 to 6/10 opaque clouds |
| Mostly Clear or Mostly Sunny |
A Few Clouds and 1/10 to 3/10 opaque clouds |
| Clear or Sunny |
0/10 to 1/10 opaque clouds |
Opaque means you can’t see the sun, moon, or stars through them (so wispy clouds don’t count). Terms like “Fair” are specifically deprecated (though defined), and there is even a list of words that “are viewed as hedge terms and should be used sparingly and with great discretion”.
Notice, the warmest city tonight is New York. Hotter than Houston, hotter than Vegas, hotter than anything in Florida. Oooof.
I have to give the weather channel folks a lot of credit for their android application. One of the quite nifty features is an alert model built into it that will actually translate national weather service alerts into phone alerts. Today I got 2 of those. One for the Tornado warning in the county, and the other for a very specific thunder cell moving over my location. This is the second time that I’ve gotten an alert on an extremely strong thunder cell, and both times it came with a roughly 20 minute warning window.
Having my phone alert me when doom is coming is a quite good thing. It also makes me wonder if in the future we’ll have some new cellular version of the Emergency Broadcast System. Given how few people are typically watching broadcast TV or Radio, something like this model would be quite slick.
A few years ago I bought an Oregon Scientific wireless weather station. It’s a nice way to keep an eye on what’s going on outside. The unit supports up to 3 of these remote sensors (shown here), and aggregates it at a base station. It doesn’t have a computer interface, so while it displays nicely in the living room, I can’t get access to that data.
Once upon a time I bought some 1-wire thermo sensors that I was going to wire that into my computer for data collection. After the house was hit by lightning, I got far more gun shy about running conductive cables from the outside to a computer.
It occurred to me recently that there was good odds that someone must have figured out to sniff that wireless communication. These aren’t complicated devices, and Oregon Scientific seems to be letting different generations of sensors work with different generations of head units, implying that they have some pseudo standard protocol. It would also solve my spark gap problem, as I could gather this data without any wires connected to the sensors.
After some googling I discovered that yes, these devices are operating in the 433 Mhz band, and yes, thanks to the folks at rfxcom, there is a unit out there which will receive this and spit it out in a reasonable usb interface.
Under Linux, this information can be very easily decoded with the heyu program. This is really more of a command line system for home automation, but it also includes the rfxcom protocol and the decoders for just about everything Oregon Scientific makes.
After plugging in the rfxcom device, it took me about all of 30 minutes to get heyu compiled and configured for my devices. The first time you run the heyu monitor you’ll actually get big hex strings which are the raw data. Once you tell heyu what kinds of sensors they are, you’ll get it decoded in much more friendly units. Here are the relevant lines in the heyu config file:
TTY dummy
TTY_AUX /dev/ttyUSB0 RFXCOM
ALIAS Sensor1 A1 ORE_TH1 0xB1
ALIAS Outside A2 ORE_TH1 0x83
ALIAS Sensor3 A3 ORE_TH1 0xCE
ORE_TSCALE Fahrenheit
After configured and running, I now have sensor data being collected continuously:
gallifrey:~> heyu monitor
02/25 21:49:54 Monitor started
02/25 21:50:11 rcva func oreTemp : hu A3 Ch 3 Temp 58.6F (Sensor3)
02/25 21:50:11 rcva func oreRH : hu A3 Ch 3 RH 42% (Sensor3)
02/25 21:50:20 rcva func oreTemp : hu A1 Ch 1 Temp 43.7F LoBat (Sensor1)
02/25 21:50:20 rcva func oreRH : hu A1 Ch 1 RH 54% LoBat (Sensor1)
02/25 21:50:22 rcva func oreTemp : hu A2 Ch 2 Temp 34.3F (Outside)
02/25 21:50:22 rcva func oreRH : hu A2 Ch 2 RH 87% (Outside)
The next steps here are going to be gathering this into something that I can use for graphing. I’ve now got all the sensors I was looking for to be able to build my better thermostat brain. Next steps will be tying this all together and starting my graphing.
