Saturday, October 9, 2010
Consolidation and Clean Up
It's been about 10 years since I started using the first beta copies of StarCOM with our home automation system. That was when I learned how to build ASP pages to communicate with StarCOM. About 3 years ago, I started building our floorplan GUI using AJAX and MySQL, which required running Apache web server. So the last few years I've had Apache and IIS running, but this week, I decided it's time to get rid of the ASP stuff. I've been converting 10 years worth of ASP pages (it's not really that much) over to CGIs running on Apache. Last night, I finished converting all the heavily used ASP pages and pulled the plug on IIS. As a result, the server gained about 100-150 MB of free RAM in addition to a little more stability and simplicity.
Sunday, September 26, 2010
A Productive Weekend Home Sick
I spent the weekend cooped up inside with a cold, but I actually got some things done. The wife's laptop was hit by a drive-by virus, so I took the drastic measure of installing Ubuntu on it. She doesn't actually use any Windows apps and all her docs are done on Google Docs anyway. I set up all her Windows shares with CIFS and installed her printer driver and that's all she needs. She seems happy with it. I liked it so much I loaded my old Acer Aspire One netbook with Ubuntu Netbook Remix. The kids' netbook has already been running a flavor of Ubuntu - they've been using Jolicloud on their Dell Mini 10. So it was easy to add the printer driver and network shares to their machine. I don't really like Jolicloud a whole lot, especially since version 1.0 seems to have slowed everything down. I would have preferred Ubuntu Netbook Remix, but for some reason, it can't deal with the Dell Mini's graphics chip. Jolicloud works flawlessly with the Mini's graphics and even supports an external monitor. Couldn't do that with the Remix.
Monday, September 20, 2010
Quick Post - xPLGVoice Preview
Here's a quick screenshot of my new xPLGVoice app. It allows control of some aspects of Google Voice via xPL messages - specifically, sending SMS, initiating calls and enabling/disabling your forwarding numbers. I hope to release it soon.
Saturday, September 18, 2010
BlueBlabber Released
The first release of our hybrid bluetooth tracker with IM is available here. Follow the link for more information.
Tuesday, September 14, 2010
BlueBlabber Coming
I just wanted to post an update on something new I'm working on called BlueBlabber. I tweeted about it earlier today. It's a bluetooth proximity app like BlueTracker and BlueTrackerScript. BlueBlabber mixes BlueTracker and Blabber together, removing the xPL component, and communicating via IM.
I built this to use at work. At my previous job, I used BlueTrackerScript and scripted up HTTP GETs to my webserver - one URL for when it detects my phone and another for when my phone disappears. I figured I'd try out this method since I've been IMing status between homes. I've been tweaking it the last couple days and I should be releasing it shortly.
I built this to use at work. At my previous job, I used BlueTrackerScript and scripted up HTTP GETs to my webserver - one URL for when it detects my phone and another for when my phone disappears. I figured I'd try out this method since I've been IMing status between homes. I've been tweaking it the last couple days and I should be releasing it shortly.
Monday, September 13, 2010
EventGhost Disappearing From Our System
Given my latest effort to bridge our remote network via IM, I've started scaling back our usage of EventGhost on the remote thin client and our HA server. This weekend, I started converting the automation code on the remote thin client over to xScript. I've had it running overnight and it's been working so well I've shutdown EG. It hasn't been running on the HA server for a few weeks since I extracted the network sender/receiver plugins to Python scripts. The server actually seems more stable. I've always suspected EG of having memory leaks that force me to reboot the HA server and remote thin client periodically. At one point, I had 3 machines running EG and now I don't have any. EG is also facing an uncertain future as the developer is planning to stop work on it, and now seems like a good time to transition away. This also means I will probably stop maintaining the xPL plugin. There aren't any outstanding problems with it and I haven't touched it in over a year, so it's not a big deal.
Wednesday, September 8, 2010
Bridging xPL Revisited
I originally talked about bridging xPL across the Internet using EventGhost in this post. More recently, I wrote about pulling the sender/receiver plugins out of EventGhost here. I did that but haven't gotten around to cleaning up the code. The problem with either of solution is that it's not very secure, so I've always tunneled them through SSH. If either Internet connection goes down, I have to manually restart the SSH session (since leaving my password and keys lying around so I can automate the login probably isn't a good idea).
Instead, I've decided to bridge the connection using IM with our Blabber app. I just set up 2 GMail accounts, one for each house, and added one to the other's chat list and fired up the local and remote Blabber apps. I wrote a script to capture certain xPL messages and embed them in an xPL message sent to Blabber. On the receiving end, the xPL message generated by Blabber is parsed out in my xPLSCU scripting engine.
The big advantage is there's no need to manually set up SSH tunnels as the messages go over Google's chat server encrypted with TLS. If the link goes down, Blabber will just keep trying to send messages until the link comes back up. No manual intervention necessary. I've had it running for a day now and it seems to be working out well. I've already had the remote ISP connection go down for about an hour, and when the cable modem was automatically restarted, the Blabber conversations continued on their own. Very cool! For added security, you can also encode your messages before sending them to Blabber.
Instead, I've decided to bridge the connection using IM with our Blabber app. I just set up 2 GMail accounts, one for each house, and added one to the other's chat list and fired up the local and remote Blabber apps. I wrote a script to capture certain xPL messages and embed them in an xPL message sent to Blabber. On the receiving end, the xPL message generated by Blabber is parsed out in my xPLSCU scripting engine.
The big advantage is there's no need to manually set up SSH tunnels as the messages go over Google's chat server encrypted with TLS. If the link goes down, Blabber will just keep trying to send messages until the link comes back up. No manual intervention necessary. I've had it running for a day now and it seems to be working out well. I've already had the remote ISP connection go down for about an hour, and when the cable modem was automatically restarted, the Blabber conversations continued on their own. Very cool! For added security, you can also encode your messages before sending them to Blabber.
Thursday, August 19, 2010
More Tracking
I continue to tweak the map resulting from the tracking info (see my updated video). I implemented a suggestion in this thread to grab the "address" corresponding to the longitude/latitude of a sample. That now shows up as the location when mousing over a marker. The mouseover kicks off an AJAX fetch of the geolocation info from Google Maps, which processes the JSON data and fills the popup. Clicking the marker brings updates the popup to show 3 nearby items and clicking it again brings up the original data.
A major change is I'm now using the Google Maps direction service and renderer to do the actual distance calculations between two markers and to draw the line connecting them. This ends up being a lot more accurate than my original straight line calculation and, of course, the line actually follows the road traveled. The more accurate distance calculation means a better speed estimate for that interval as well.
Right now, the code is a disaster, but I plan on putting it on my website after I clean it up.
A major change is I'm now using the Google Maps direction service and renderer to do the actual distance calculations between two markers and to draw the line connecting them. This ends up being a lot more accurate than my original straight line calculation and, of course, the line actually follows the road traveled. The more accurate distance calculation means a better speed estimate for that interval as well.
Right now, the code is a disaster, but I plan on putting it on my website after I clean it up.
Tuesday, August 17, 2010
Google Latitude Tracking Live
Today, I've fully deployed our tracking scheme using Google Latitude. My wife and kids have started their road trip and I'm tracking their progress. Here's how things look so far.
Using the Latitude data, I can determine their position in the past 2 minutes (it appears to update only every 2 minutes). Using two points and their timestamps, I can estimate the approximate speed they were driving between the two points. As I mentioned in a previous post, I'm storing the locations in a MySQL table and through AJAX, I'm able to update a map with their path and show information bubbles over each point with some information, which is what you see in the video linked above. You can see an occasional large gap between points as they move in & out of 3G coverage, but it's not too bad since we don't use AT&T. HA!
Using the Latitude data, I can determine their position in the past 2 minutes (it appears to update only every 2 minutes). Using two points and their timestamps, I can estimate the approximate speed they were driving between the two points. As I mentioned in a previous post, I'm storing the locations in a MySQL table and through AJAX, I'm able to update a map with their path and show information bubbles over each point with some information, which is what you see in the video linked above. You can see an occasional large gap between points as they move in & out of 3G coverage, but it's not too bad since we don't use AT&T. HA!
Sunday, August 15, 2010
Jobless Still...But "Work" Continues
The deal with the early stage startup (which recently closed a Series A round from 2 firms) fell through. It left a bad taste in my mouth. They dragged the whole process out over a week only to email me this: "Thanks for taking the time to speak to us. Unfortunately, your background is not a good fit for the current position we have open." It's odd they came to this conclusion after I nailed the technical screenings with their engineers, and they thought I was good enough to talk with the VP of Engineering and the CTO. They even asked for my references, but in the ensuing 5 days, they never called a single one. I also had an inside person there who said everyone was impressed by me and it was pretty much a done deal. However, their Director of ASICs admitted to having difficulty with the compensation package given where I was at. After doing a little research on my own, it looked like I would be offered a 25% cut. So, to save face and not be called cheap, they chose to say my background was not a good fit rather than saying they wasted everyone's time because they can't afford me. What a joke.
Instead of long hours at the early stage startup with a menial salary, I've accepted a consulting gig at a large, public company. I won't have to cut back on my gadget spending and I'll only work 40 hour weeks, leaving plenty of time for my own projects.
On that note, my Google Latitude project is progressing nicely. Still, not yet at the point to post screencaps, etc. Another project I started yesterday was creating an xPL bridge in Python. I had already created a rudimentary way to link xPL networks across the Internet using EventGhost and the Network Sender & Receiver plugins. I'm still using EG at our other house, but I don't really need to use EG on my HA server, so I stripped out the Network Sender & Receiver plugins and made them into standalone Python scripts. I've also gone one step further and made the receiver script capable of re-sending the bridged xPL messages as if they were sent by the original source. Now, I can fully view the remote xPL network and configure the remote apps as if they were local. There's still a lot of tweaking and clean up to do, and I am pondering building a C# xPL bridge just to make things less of a hack. The thing is, I still use EG on the remote network and the thin client it runs on is rather limited, so I don't really want to add another app on that machine.
Instead of long hours at the early stage startup with a menial salary, I've accepted a consulting gig at a large, public company. I won't have to cut back on my gadget spending and I'll only work 40 hour weeks, leaving plenty of time for my own projects.
On that note, my Google Latitude project is progressing nicely. Still, not yet at the point to post screencaps, etc. Another project I started yesterday was creating an xPL bridge in Python. I had already created a rudimentary way to link xPL networks across the Internet using EventGhost and the Network Sender & Receiver plugins. I'm still using EG at our other house, but I don't really need to use EG on my HA server, so I stripped out the Network Sender & Receiver plugins and made them into standalone Python scripts. I've also gone one step further and made the receiver script capable of re-sending the bridged xPL messages as if they were sent by the original source. Now, I can fully view the remote xPL network and configure the remote apps as if they were local. There's still a lot of tweaking and clean up to do, and I am pondering building a C# xPL bridge just to make things less of a hack. The thing is, I still use EG on the remote network and the thin client it runs on is rather limited, so I don't really want to add another app on that machine.
Monday, August 9, 2010
August Already?? and Google Latitiude
I was figuring I'd spend a lot of time on the house and the automation system while I was job hunting, but it didn't turn out that way. It's been about 6 weeks and I really haven't done a whole lot. I did finish up most of the trim for the flooring, but I had to stop and find some flexible quarter-round to go along the bottom of our staircase (which has a full 180 degree curve on one side). I did pick some up from Trimster, but I haven't thought much about how to stain it, so it's sitting around.
As for automation stuff, I've been revamping our AJAX based floorplan GUI. Given all my free time, I've been reading up on CSS3 and jQuery and have completely re-written large portions of the code. My HTML page used to have markup, JavaScript and CSS all mixed together, but now I've gotten everything updated to typical coding standards, with the HTML page containing only the markup, and the CSS and .js files have grown significantly. It's definitely much neater to read now and should make maintaining and updating it easier as well. I figure at some point, I will migrate it to HTML5 and that will be another major overhaul, but for now, I'm very pleased with the new CSS and jQuery things I've learned.
When Google Latitude first came out, I put a placeholder at the bottom here, but had so many things going on, I forgot all about it. This thread reminded me about Latitude tracking and with the wife planning a 5-day roadtrip with a girlfriend, I finally decided to get off my butt and implement some tracking (with her permission of course! :)
First off, we need to get a public badge for Latitude - you can find out more here. We already have Google Maps on our cells so we just need to enable Latitude on the app. Next, we need an automatic trigger to start Latitude tracking. We use RFID tags in the cars and bluetooth on our phones for tracking, so when someone's phone and a car are gone, we can start the Latitude tracker.
The tracker is just a perl script that periodically fetches the Latitude badge's JSON feed and parses its information (latitude, longitude, timestamp, reverse geocode info). That information is stored in a MySQL table that is reset for every new trip. Finally, I've written an AJAX page that fetches the location data from MySQL via PHP and shows each data point on Google Maps with a line connecting the points. I plan to post more details as I debug this new feature.
Finally, I am about to close a deal to join an early stage startup. The company is in a very promising space and is at the right stage for me to be able to contribute a great deal to the product development. However, early stage equals long hours, but I'm ready for another startup. HA stuff will just have to be put on the backburner...
As for automation stuff, I've been revamping our AJAX based floorplan GUI. Given all my free time, I've been reading up on CSS3 and jQuery and have completely re-written large portions of the code. My HTML page used to have markup, JavaScript and CSS all mixed together, but now I've gotten everything updated to typical coding standards, with the HTML page containing only the markup, and the CSS and .js files have grown significantly. It's definitely much neater to read now and should make maintaining and updating it easier as well. I figure at some point, I will migrate it to HTML5 and that will be another major overhaul, but for now, I'm very pleased with the new CSS and jQuery things I've learned.
When Google Latitude first came out, I put a placeholder at the bottom here, but had so many things going on, I forgot all about it. This thread reminded me about Latitude tracking and with the wife planning a 5-day roadtrip with a girlfriend, I finally decided to get off my butt and implement some tracking (with her permission of course! :)
First off, we need to get a public badge for Latitude - you can find out more here. We already have Google Maps on our cells so we just need to enable Latitude on the app. Next, we need an automatic trigger to start Latitude tracking. We use RFID tags in the cars and bluetooth on our phones for tracking, so when someone's phone and a car are gone, we can start the Latitude tracker.
The tracker is just a perl script that periodically fetches the Latitude badge's JSON feed and parses its information (latitude, longitude, timestamp, reverse geocode info). That information is stored in a MySQL table that is reset for every new trip. Finally, I've written an AJAX page that fetches the location data from MySQL via PHP and shows each data point on Google Maps with a line connecting the points. I plan to post more details as I debug this new feature.
Finally, I am about to close a deal to join an early stage startup. The company is in a very promising space and is at the right stage for me to be able to contribute a great deal to the product development. However, early stage equals long hours, but I'm ready for another startup. HA stuff will just have to be put on the backburner...
Subscribe to:
Posts (Atom)
