Scary Cabin

One of my backup drives failed. This is the drive that is primarily backing up the media (music, photos, etc.) so it’s pretty important. The drive was set up as a TimeMachine drive and the media files reside on a USB disk attached to a Mac Mini.

Since I need at least a new drive, this seems like an opportunity to look into replacing the Mac Mini with a NAS device. Looking at some of the low-end NAS devices, it seems like they’ve come a long way since I last looked at them many years ago. They have well thought out user interfaces and some seem to have very good application support.

So maybe this is an opportunity to consolidate and improve a number of the home network functions.

The Mac Mini holds the media, web, and other various archives and serves these out to other machines.

The Linux desktop has database files, and runs the web server, the media server, and a crashplan server so it’s handling a lot different tasks.

There’s also a RPi set up as a VPN server.

Those are all things that a NAS can do, but what should it do?

#1 is file serving. So move all the file serving functions from the Mac Mini to the NAS.
#2 is backups. If possible, run CrashPlan headless on the NAS and point all the other machines at it.
#3 is TimeMachine backups. It should be able to handle local data from each of the Macs
#4 is media server. Maybe even an iTunes server and possibly a Plex server
#5 is a web server.
#6 is a VPN server.
#7 is running the MariaDB database service
#8 What about creating a calendar server?
#9 Would it make sense to make it a mail server too?

Some considerations. While running Crashplan and sending all backups to the NAS seems like a good idea, Crashplan can be a resource hog. Handling the data from the Windows machines is probably easy, but what about the Linux home directory? Some testing is needed. Would it make any sense to move the Linux home directory to the server too?

Media servers can also be a bit resource intensive. Does it make sense to run more than one? There’s a built-in one and there’s Plex. Should only one be run? Is there any advantage to running an iTunes server?

Running the web server on the NAS and the database on the Linux box may cause additional network traffic and performance issues for the web applications that want a database. Of most concern is the power monitoring app as that updates the database frequently. Would it make any sense to run two database servers, one on the NAS handling web applications only and one on the Linux box for the power monitoring.

The biggest concern with hosting all the databases on the NAS is the power monitoring. Would it be possible to run the power monitoring data collection on the NAS? It would need a USB port dedicated for that.

Moving the VPN service over seems like a no brainer.

Hosting a family calendar on the NAS is an interesting idea. It may make a shared calendar between ios and android devices possible.

Moving the mail processing over doesn’t seem to have any advantage or disadvantage. If the NAS isn’t bogged down by everything else, it might be nice to have it handle this too.

The real benefit to using the NAS seems to be that it could free up resources on the Linux box. How much it can handle, we’ll see.

And what NAS am I going to use? A Synology DS216j. This is a dual bay, low end NAS. If it works out well, it’s possible to move up to a more powerful NAS down the road.

Back in the late 80’s and early 90’s the Sacramento TSD rally scene was quite active. There were multiple rally clubs and typically at least one rally a month (The Friday Night Rally Series) along with various weekend rallies. Some of the folks involved were also involved at the national SCCA level. They typically used a “rally computer” to accurately track their distance and compute how close they ran to the ‘perfect’ time.

One bright fall Saturday, my rally partner, Jim and I ran a tour type T&D rally from Sacramento to Reno. Official mileages were given for every RI so it was possible to do manual calculations without the need for odometer correction calculations. We decided to try this armed with only a 4-function calculator, a pen and a pad of paper. This kept Jim very busy for most of the day and he didn’t get to see much of the scenery. After it was over, me being a software engineer, thought, “It would be pretty simple to write a computer program to handle all the calculations”. And thus, The Rally Computer program was born. I had a Zenith Supersport laptop computer that I had won in a raffel and it wasn’t being used for anything else so that made a perfect test machine. This was an 8088 based machine with 640K of memory, a floppy disk drive (3.5”!), a B&W LCD display, and a very large battery pack.

I started by writing some routines to handle time manipulations. I needed routines that could subtract and add two time values, convert a time (HH:MM:SS) to number of seconds, and convert a number of seconds to a time value. Delving into the Microsoft C documentation, I found a routine, _dos_gettime (), that would read the current time from the operating system and return it in a time structure. The time structure held hours, minutes, seconds, and hundredths of seconds. Perfect! I wrote all of the time functions to use the time structure.

The first version of the program would prompt for the mileage at the end of the odometer check. It would compare the official mileage with the stock odometer reading and calculate the correction factor. It would then ask for the out time. For the rest of the leg, it would prompt for a speed and a stock odometer reading and calculate the perfect time to that point. It would also mark the time-of-day when the ‘’ key was pressed and compare that time with the perfect calculated time and display the difference as an early/late number of seconds. By entering this information for each speed change, we would know how far off we were at that point. This worked OK but we soon found out that it was definitely not perfect. If we made any errors, either in entry or by going off course, there was no way to correct them. After almost every rally we would find something that didn’t work quite right or if changed, would make it easier to use. After almost 2 years of adding features, making changes, and redesigning it is finally to the point were we felt it was competitive with commercial rally computers.

So far all I’ve talked about is the software. After a while it became apparent that reading and interpolating the stock odometer and then entering that into the computer was a major cause of errors. The next step was to add some hardware that could sense the number of wheel rotations and calculate the mileage. This would eliminate errors caused by miss-reading the odometer and by typo’s while entering it. It would also free up the navigator as trying to type all those numbers while bouncing around could be a trying experience. We investigated various methods of getting data into the computer. Making the computer count pulses would take too much of the processors time and we didn’t think it would be able to keep up. The Zenith doesn’t have any card slots so a simple I/O board was out of the question. We decided to build an intelligent electronic odometer and interface it to the computer with an RS-232 interface. The next step was to come up with a way to count wheel revolutions. I had a speedometer/odometer for my bike that used a magnet on the wheel and a reed switch to generate pulses. We decided to try and connect a $35 bicycle speedometer/odometer (CatEye) to the car. We mounted the reed switch on the top of the back brake caliper. There was a bolt holding a heat shield that worked perfectly. We then glued a magnet to the inside of the wheel and once it was aligned, spinning the wheel did cause it to pulse. We then ran the wire up to front seat and connected it to the display module. The CatEye is capable of working with a wheel diameter from 20 to 28 inches and my car tires were about 23 inches. It actually worked, we were able to read distance down to 1/100th of mile and speed, at least we could until we exceeded the units speed limitation. If we went over 60 MPH the unit would stop reading correctly. Of course, why would we ever want to go over 60 MPH on a rally? After more testing we determined that the problem was in the CatEye display unit and not in the switch sensor. It was time to build the odometer. We did some preliminary designs using an 87C51FB micro-controller, a couple of binary counters, and a display unit. Everything looked good but it would be expensive and complicated to build. I poured through the Zenith hardware reference manual looking for a simple way to do byte size I/O. The printer port looked promising. It had a 1 byte output port and 6 input bits. After experimenting with it I found I could transfer 8 bits out and 5 bits in. Maybe we could do something with this after all. I told Jim I would need a 20 bit binary counter with latchable outputs. He said, no problem, we can put that on a single EPLD chip. So he did. We have a 68 lead PLCC chip with a 20 bit counter, latched and multiplexed outputs. The counters clock is tied to the reed switch so that every pulse increments the count by one. By setting the latch line high and setting a 3 bit value to the bank we want, we can read all 20 bits, 4 bits at a time using simple I/O calls on the computer. We had our odometer.

At some point, the big Zenith laptop was replaced with a smaller, lighter 80386 based notebook which we used until the rallying scene mostly died out in the Sacramento region . We used this not only to run rallies, but to help with the creation of rallies. Since we could log everything, it was easy to pre-run a rally and log the perfect times for each instruction and leg.

Around 2002 I started to revive the software. As computers were getting more powerful, it seemed like it should be possible to eliminate the counter hardware and just count the pulses with the computer. I did some experiments using the parallel port interrupt line and a simple Linux kernel module around 2003 but never finished it into a working version.

In 2007 I acquired an Intel Poulsbo based tablet. This had a 800×480 display and could run Linux. I thought this might make a good rally computer. At the time, my wife and I were creating rally events for the local Miata club so I thought getting The Rally Computer working again might help with those. The two challenges were how to count the pulses and updating the code to work with the GUI based touchscreen. Since I wanted to do this in Linux, GTK+ / Glade make the most sense for the GUI. I created a layout and ported over some of the basic functionality. Since the tablet doesn’t have a parallel port, would a USB parallel port adapter work? What about a USB mouse button? I did some tests where I wired up the mouse button to the hall effect speedometer sensor and had mixed results. The pulse counting was a bit flaky. Life took over and I never did debug the problems.

Fast forward to 2016. Computers and cars have progressed quite a bit. Small hobbyist computer boards with multiple I/O’s, good displays, Wi-Fi, and Bluetooth are available cheap. For $40 or less you can get a Raspberry Pi that’s many times more powerful than the Zenith Super Sport of 1988. Cars all have various speed sensors that are used for traction control and ABS brakes. All it took was one trigger to start the thought process of what it would take to bring The Rally Computer into the 21st century.

It didn’t take long to finish up most of the software conversion to GTK+ but the real challenge is still getting accurate distance data. A RPI has multiple GPIO pins and those could be used to implement a pulse counter in a Linux kernel module without too much effort. The source for the pulses could be one of the car’s VSS sensor leads but that would involve cutting and tapping a wire the ECU. A less invasive approach would be to go back to the original reed switch and epoxied magnets. Both of these solution will only work with the specific car that has the modifications. Is it possible to access the VSS signal from the OBD2 connector that’s been mandated since 1996? Time to experiment. ELM327 based OBD2 dongles are dirt cheap, like less than $10. There are numerous examples of connecting one to a RPI via Bluetooth or USB on the web. The ELM327 datasheet is available and describes how to communicate with it in great detail. Sounds like a plan.

With a bit coding to create an test application that connects to the ELM327 and pulls various sensor data, we’re ready to experiment. It looks like the VSS signal is not available, at least not through the standard PID’s. But the vehicle speed (in kph) is available. Tracking the vehicle speed over a very short period of time can provide distance data. But is the speed data accurate enough and can the ECU be queried quick enough to make this a practical plug-n-play solution? The test application has been able to pull speed data at approximately once every .6 seconds. The speed data is in integer kph and ranges between 0 and 255kph (0 -159mph).

The next step will be hook up the GUI app to the ELM327 and run some real-world tests to see how it behaves when the vehicle is driven normally. To do this, the RPI will need some type of local display and input. There’s a nice 800×480 7” touch screen display available for $65 that seems perfect for the job.

If this works, it will be nice plug-n-play solution that should work with almost any vehicle 1996 or newer and it can all be powered from a USB port in the car. Total cost:

RPI model 3 - $40
7” display - $65
ELM327 - $10
Total = $115

Some questions from a colleague about home automation got me thinking. Maybe I should document what I use and why. Well, this entry is an attempt to do so. First some background.

When Smarthome first introduced the Insteon line of devices and protocol they made it fairly easy for developers by providing full documentation and development kit. The price point was less than the equivalent Z-Wave and UPB products but more than similar X10 products. However, it also would work with X10 products. I had some X10 products (dimmer switches, lamp/appliance modules). Since I preferred to have a Linux based control system, getting started with the Insteon SDK seemed like the way to go. I jumped in with the development kit (PLC & lamp module) plus a few additional switches and lamp modules. Using the documentation, I started writing Insteon tools for Linux. I developed a fairly robust set of tools to control devices, dump link tables, save and compare topology. Then Smarthome changed the protocol. The differences were substantial and you had to support both.

It was about this time that a company called Universal Devices Inc. came out with the ISY26. The ISY26 was an embedded controller for Insteon. Since they were dealing with all the special cases needed to interact with all the different devices and both protocols and provided a nice network based API to interact with the ISY26, it seemed like a good way to go. I jumped on-board. About this time I was also looking into ways to get touch screen controllers in the house. I started playing with Cinemar’s MainLobby home automation software. This software is Windows based, but allowed for custom plug-in’s to support various HA type devices using Visual Basic or C#. I wrote a couple of simple things to get familiar with it and then developed a plug-in to interact with the ISY26. Because of this, UDI approached me about developing something similar for HomeSeer, another home automation software company. A lot of what I created for MainLobby was applicable for HomeSeer so I decided to go for it. It took about a year to fully develop a plug-in for HomeSeer, but I was able to create a core library that interacts with the ISY and front-end code for both MainLobby and HomeSeer that made use of it. The HomeSeer plug-in is available in the HomeSeer store. Attempts to get Cinemar to officially recognize my MainLobby plug-in failed. When a new player in the home automation software field emerged, Code Core Technologies Elve, I switched over to that for my home control system. Developing touch screen interfaces was easy and they fully supported third party developers creating additional drivers. Using the same base code that was used for the MainLobby and HomeSeer plug-ins, I quickly created an ISY driver for Elve. I’ve also created and modified a number of other drivers for Elve. Being able to customize it for my environment was a huge selling point. Unfortunately, Code Core Technologies was unable to survive and has mostly shutdown. The good news is that the latest version of Elve is still available as a free download. I’m currently working on a driver for the RainMachine irrigation controllers.

My current system is:

A UDI ISY 994i controller with Z-Wave module
Elve 2.2 running on a Windows XP virtual machine
Insteon light switches throughout the house
Insteon keypad switches
Insteon lamp modules for various stand alone lamps
Insteon LED light bulbs for a couple lamps
Insteon motion sensors for garage, side door light, and den light
Insteon garage door sensor/control module
Insteon Venstar thermostat
One Z-wave dimmer switch
Two Z-wave lamp modules with beaming support
Kwikset Z-Wave deadbolt
DSC alarm panel
Russound CAV whole house audio controller
Roku 2 media streamer
ASUS All-in-one PC touchscreen computer for monitoring & contol