James Sentman

First project in the new house worth documenting is the install of some X10 controlled LED nightlights. These got a high level of spousal approval ;)

So I Oooo'ed and Ahhhh'ed along with everybody while reading about Apple's new iPad. But apart from a desire to develop remote control apps for XTension on it I really couldn't see how I might actually use one. When I lug my laptop off with me it's so I can do development and I need REALbasic and XCode and all the ancillary things that go along with them. Those things, while they compile for the iPad (well not RB yet but one can hope) they don't actually run on it... So it would be nothing but a plaything for me if I were to buy one. My plaything budget, while it has increased over the years, has not grown to the point where I can pick up $500 toys without some planning.

So I put the idea out of my head.

Then last night as I was reading teh intertubes in bed, I began to think wistfully about our next family vacation and remembering past family vacations and I have brought my laptop along on all of them. I like to be able to log into the house remotely and make sure the cat lady has come when she said and that sort of thing and add a little extra randomness to the vacation light programs. But I also then tend to do actual work. I like my work so this isn't really a problem for me. If I only brought an iPad along I'd still be able to do all those important things like logging into the house and getting my email and VNC and all the rest, but I would be prevented from actually doing any real work. Since the compilers wouldn't be sitting there taunting me to come and accomplish something I would be able to eschew work with a clear conscience.

I'd have access, I'd have books and the web, I'd just not have to do any work. An enforced vacation without having to leave all my connectivity behind. Now that might just be worth the entry price someday.

Course.. the problem is that I can pretty much do all that with my iPhone now...

Or how I learned to stop worrying and embrace the protractor...

Did I mention cutting crown molding was a black art? Those corner units need a 22.5 degree angle cut, and my miter saw has an indent at that angle, but of course it's a little bit off, just like the 45 degree indents and so you have to measure each time you switch it from one side to the other... But eventually it's all up and done and really looks nice. It's just primed right now but the whole thing is getting a fresh coat of paint and all cleaned up and one more step complete.

I have officially begun the process of updating the kitchen in this house. Last week I took down the wallpaper border that I have been meaning to take down for 6 years. My advice for people starting to take down wallpaper? DONT PUT UP WALLPAPER! But to get it off you'll need one of those scoring things that makes tiny tears in the paper, and then you'll want a steamer. You can rent a real one or if it's small you can do what I did which was to use one of those steam cleaner things. It has an attachment that worked pretty good to go over the paper as I tore it down.

Now that the paste is all cleaned off I begin the next bit which is augmenting the crown molding around the top of the cabinets. If you look at new expensive cabinet jobs they all have fine furniture looking crown molding following around the top. Ours had only a fairly simple single strip of molding. I'm adding another layer of real crown molding to it now. The orphan cabinet is now done apart from putty caulk and painting. There is a much larger grouping of cabinets on the other side to do yet, but I tackled the smaller one first so I could check to see if I still remembered how to cut crown molding which is a bit of a black art.

umm.. mail is not happy with me lately, I can't imagine why.

It may be time to give up on email all together.

weed tech makes some nice interface modules, several of which I already support in XTension. Something I've been meaning to get ahold of is their analog output card so that I might make use of some of these old meters that I've collected. I broke down and bought myself the thing the other day ;) I had to revisit the code anyway to support serial connections over IP/serial adaptors and add support for their new analog input module anyway so I decided to add this to the list of maintenance being performed.

There is still a lot of work to be done before it will be ready for full integration and I've mucked up the queue handling somehow in the process, but as far as a demo of the possibility it works great. More fun coming when it's all cleaned up.

It doesn't look that dangerous on a camera closeup but this caused an electrical fault inside my hot water heater this morning. I'm not sure how you can guarantee that a screw connection on something that thermal cycles as much as the connection to your hot water heater element does never comes loose. I'll bet there is a torque rating on the terminals, but the folks that put this in didn't check for that I guess.

I've replaced the bad wire, the thermostats and elements appear to still be functional so we avoid putting in a more efficient model for a while longer. I wonder if I should check the connections on the other one while I'm still dressed for messing around in the attic...

The quest for really good LED replacement bulbs continues and shows promise but still some shortcomings.

On recommendations from friends on the XTension mailing list I ordered a couple of bulbs from http://www.redbirdled.com/ They show some good construction quality and very usable light color and quality, but still have issues that make it difficult for me to recommend them completely. Though I had no issues that required contacting them I've heard from others that the company is also terrific with customer service.

The furst bulb is this 8 watt array, 60 watt replacement. Normally I've recommended to stay away from bulbs with arrays of small LED's as I've never seen one that was of a high quality, these really do seem to be worth a try.

The construction appears very good, the metal looking parts are actually metal. The light color that I ordered was the warm white and they do compare favorably to a real 60 watt bulb. My problem with them is that they flicker horribly. They are dimmable which is a plus, and they appear to work pretty good with X10 lamp modules. But as with many LED's you can't turn them all the way off with a dimmer. Even some regular, non-x10 dimmers cannot turn them all the way off. I imagined using it in my bedside lamp which is on a manual slide dimmer thing but you can't turn it off and it would have been too bright to sleep next to even with just the leakage voltage of the dimmer. These ballasts need a system where they realize they should actually be off even if a tiny amount of current is still available. But the real deal killer here is the flicker. It is not subtle. I've placed this light into the kids bathroom overhead light which we usually leave on all night and I'll wait to see if they complain, but I could not put it anywhere I spent a lot of time or worked under due to the flicker. Fix the power supply though and the LEDs and construction quality of them really are nice.

The second bulb I ordered was a wide dispersion flood light. I like LED spotlights very much, but flood lighting they just haven't been good at yet because they just dont make enough light. This bulb bucks that trend with a really wide and really bright light.

This is a "warm white" but the specs say 3200k. For a CFL warm white is usually 2700k and 3000k or higher are called "bright white" here is the bulb in front of some 3000k CFLs and you can see it's considerably cooler in temperature, but still very usable. This light uses 15 watts and if you use it to replace a current flood you will not be disappointed with the light output.

It is also very hefty, a pound and a half of solid aluminum in the frame and heat sink! I believe it is a single big emitter under the diffusion cover too which is interesting. This is the only led flood light I've owned that actually put out enough light for a real overhead replacement. I could actually put these in my kitchen and not have a decrease in the light available, though it would cool off the light temp in there which I'm not sure I like, but it's not horrible like some really cool LEDs are. I would get used to these. But again, power supply issues cause me to fail to really recommend it. The light is not dimmable, thats OK, neither are the CFL's I've got in the kitchen here. The problem is that it takes a full 5 seconds to light up after you turn the power on. I understand some power supplies do this, but 5 seconds? There is no visible flicker at all which is nice, but if I were to replace all the kitchen lights with these people would turn it on and stand there blinking in the dark for 5 seconds.

So we continue to make serious progress in LED replacement bulbs. This company has the build quality and the LED's down it would seem (though I haven't tried to do any lumen maintenance tests with these) but some work on the power supplies is still needed.

As if there weren't enough displays and readouts in here already today I completed the VFD "ice tube clock" from Adafruit It's actually not at all a hard kit to put together and it looks really nice on my desk :) The quality of the plastics and board and instructions are just second to none. This was about a 2 hour project for me, I'm sure other folks could do it faster. I have only 2 pieces of advise, use the thin solder, not the thick old radio shack kind and though they say some of the plastics can be installed either way around, it actually will only fit one way, so dont force it, try it the other way around. the tolerances are very close due to the quality of the laser cutting.

So MORE VFD goodness in the lab!

Received the Larson Scanner kits I ordered from evilmadscientist.com. I have so many uses for these I don't even know where to start... Kit only took about 15 minutes to put together and most of that was because Ben was helping me to place the components. He's going to be good at this sort of thing :)

First attempt at an unboxing and setup video. I might do more of this sort of thing. Learned a lot for the next time production wise and the box itself is really fantastic for the features and price. The barix 50 is fully supported by the latest beta's of XTension we're going to do some official announcements before long I think.

Previous to my Airport Extreme I was using a very old airport express model that only did 802.11b/g. This was necessary as there are a bunch of deices around here (namely my iPhone) that wont connect to an n network and I guess I didn't realize just how much faster that was. I had experimented with using both airports to extend my network and get better coverage, but only on b/g. After reading something on the internet that it was better to keep the older model on b/g mode and run the extreme in n 5GHz mode I gave it a try and initially I thought it was fantastic. The speed for file sharing and stuff was really much improved and even the internet speed felt better though in that case the cable modem is the problem not the wireless speed. Unfortunately I shortly began to suffer from the problem of dropping the connection that is all over the apple discussion boards. It would work fine for a short time and then just stop. The airport menu would still show full bars and think it was connected but no network traffic would go through at all. Sometimes turning the airport off and back on again would make it reconnect for a few more minutes, sometimes not. Sometimes it would work for hours before cutting off and sometimes only seconds.

I couldn't find a solution anywhere so just decided to mess with it a bit before giving up and putting the express back into b/g mode. The solution appears to be to set a specific channel and not select "auto". Except that by default you cannot select a channel when in n 5ghz mode. But if you hold down the option key while selecting the popup menu then you can! SInce selecting a single channel I have not had it drop the connection once in the last week or so.

of course you might have to play with the channel selection to make it reliable with other radio sources and other base stations in the area then, but so far that hasn't been a problem here.

I guess the lesson here is that if you want the OSX Server blogging system to keep running, don't make a copy of your blog folder and leave it in the collaboration users folder. This will cause the blogging server to try to open and read the copy of it, which since you made that with an admin user it wont have the clearance to do. Then instead of just skipping the stuff that it can't read properly it will crash instead. Then it will try to relaunch and crash again. Every 10 seconds until somebody realizes your blog is down and tells you about it.

Hopefully that is fixed now and I wont do that again...

I have been watching this back and forth between apple and palm and I just can't figure out what palm thinks they are up to. In case you haven't been paying attention here's the quick history. The Palm Pre has a media sync mode where it pretends to be an iPod to the USB bus thereby fooling iTunes into syncing it as if it was an iPod. Of course it can't play encrypted media content like older music purchases or movies, but will play anything else. But in pretending to be an ipod they had to reverse engineer the communications and hack it all together. This simply cannot be fool proof as anytime Apple updates anything it's likely to break. They definitely did not have apples permission to do this, nor do they have any documentation on the protocol or any ability to keep up with changes except after the fact by continuing to hack out any changes.

So of course with the next iTunes update Apple broke their implementation, and with the next Pre update Palm hacked the new one and got it working again. So they can go back and forth until Apple breaks down and encrypts the whole thing or something that they cannot hack.

Why would they do this? This seems really bone headed to me. Doubly so given how simple it would be to do a separate background sync app that just read iTunes configuration files and copied the files to the device in a way that wasn't hacking the low level protocols. An iPod is not just a mass storage device that you copy files to.

There are API's on the Mac that give you access to all the iTunes information. A separate app could provide you with a list of all the iTunes playlists and media files you could select from in a window exactly the same as the one that iTunes uses to select them. Heck, it wouldn't be hard to do this BETTER than iTunes does in say it's horrible movie selection list for the iPhone where you dont even get to choose playlists but must scroll through all the individual movies. If you dont want to use the API's on the mac then there are apple events. All the data is available for any app that wants to ask it for the links to the files and the ID numbers of every track in the playlists. If you don't want to do that you can directly parse the plist files that it stores it's configuration data in. This is a little more hacky as they will certainly change those over time, but changing how you parse what is basically an XML file is a heck of a lot easier and more reliable to keep up with than changes to a low level USB protocol. Apple events do not exist on windows and I don't know if there is an official API for asking iTunes about it's content for use in other apps, but there are still the xml preferences files that could be loaded.

So those methods would add a single step to the sync process, basically you'd plug in your pre and a separate sync app would launch with all your iTunes data in it. But it would be a proper way of doing it that would be unlikely to make Apple mad at you since these are ways that they endorse for getting access to the iTunes data.

But instead they decide to play a game of chicken with Apple for no gain other than the fun of thumbing their noses at Apple for stealing their market? I can't think of any other reason to do what they have done. I honestly never had much interest in the pre except in learning what they did right and hoping that Apple benefits from a little competition. But given this really stupid move I have less than no interest in the pre. Only their users who expect to be able to sync with iTunes are going to be hurt as this continues to go back and forth and they continue to waste limited resources on fighting a battle that they didn't need to fight to offer exactly the same features. Just stupid palm.

Depending on my Internet connection speed? How on earth could my internet connection speed have anything to do with how clogged up the AT&T server is? It's the difference between transferring my login and password in 100ms or 200ms big deal! This is a disingenuous message and just shows how stupid AT&T thinks their users are. Our site is slow! So instead of fixing it, or just suggesting that we know it's slow, please be patient, (which would actually be OK with me, it's at least honest) they LIE to you and suggest that it's somehow your fault that it's taking them forever to look you up in their overtaxed database. While this message is displaying it's entirely their server which is churning away blowing smoke out it's ears, it has nothing whatsoever to do with you or your internet connection. Over modem or cable modem the difference would be measurable, but meaningless. Blame the user for your stupid, loose the user to another company. As soon as another company gets a contract for the iPhone AT&T will feel the breeze as the air rushes into the james sized hole I'll leave on their ledger books.

Unless, of course, they completely turn around their entire corporate culture before my contract runs out, which is entirely possible however improbable it might be...

PS...

Guess my internet connection is too slow as this is all I can get from their server ;) In all fairness it is another iphone pre-order rush which is causing this to be this bad, I guess they really dont want to sell me one. My original 4gig phone is getting a little long in the tooth and really deserves an upgrade!

cannot seem to get the UPB noise level down around here to the point where it doesn't mimic real UPB Ack's on the powerline. With a low noise level you can get a pulse back from any unit you address letting you know that it heard the command or not. This opens up the possibility of adding features to the program to attempt to resend commands that were not acked to increase reliability. But an Ack pulse is a simple pulse, not a message that can be verified or checksummed. The UPB standard also allows you to ask for such a message, but though I've turned on the flag to request that in ever command I send out I dont seem to get anything back. Perhaps that just isn't implemented in the devices that I have or perhaps I just dont understand something about it. In any case I high noise level will make the PIM think that you've received the ack pulse even when the device has not responded.

Before going to bed last night I checked the noise graph and noticed an interesting drop out after a short power failure we had just after 7 yesterday. Only lasted about 5 seconds, but it make the noise completely disappear for an hour. This makes me wonder about the same simulate preset dim issue I blogged about here Debugging UPB Signals. At 3:30 am or so after laying in bed awake for a while I got up to have a look at the data again. Usually at night there are very few lights on so noise would be lower if it was related to a failing CF ballast but higher if it was related to something dimmed to 0. Notice the dip just before 1am. Checking the XTension logs showed that there was a hit on the porch motion sensor and the deck lights dimmed from 0 to 100 for a while. While the lights were on the noise was low and when it turned them off the noise returned to the higher levels. The thing that makes this particularly weird is that this porch light is just 2 regular 100 watt light bulbs in an outside fixture, no CF no ballast nothing odd or unusual at all. But testing it again manually verifies that when they are on or off or dimmed to any value above 5% there is no noise, but dim them to 0 and they clog the UPB line. These are on a regular X10 wall switch. UPB and X10 are supposed to be able to coexist, but there is something about dimming to 0 that makes UPB unhappy.

This morning now I've checked a bunch of other regular X10 switches that I dim to 0 instead of turning off, so that I can have a gentle startup with them rather than jumping to 100% like they do if you just turn them off and about half of them add to the UPB noise and half do not. I can change a couple to not dim to 0 without too much trouble, but some I will need to debug as I need that functionality. Or just replace with a UPB capable switch that can do ramp rates. The 2 master closet lights are setup this way so that during the night if you walk into them the lights come on dim so as not to disturb a sleeping spouse but come on full during the day. One of the 2 causes this problem, one does not. Replacing the light bulb in the offending one doesn't seem to help so next step will be to replace the switch, or add a filter or something.

Seems very strange indeed that regular bulbs on X10 switches are the culprit here as most of the other problems I've ever had with noise have been due to failing CF ballasts, but nothing like that going on in the house at the moment.

I've been noise hunting for X10 for so long that it's second nature, but now that we're adding new protocols totally different things are going to interfere with them. UPB may be how ever many thousand percent better than X10 and Insteon for reliability, but I just found a way to totally block every UPB signal in the house with noise. And noise that is interesting enough that it passed a lot of the checksums and the interface thought were valid signals, albeit with totally bogus command codes. The unit and network id's were consistent enough that for a while I thought I was receiving valid signals from some other device or from a neighbor or something! My poor interface was sending me packets as fast as it could and I couldn't transmit anything, even to a lamp module plugged into the back of the interface.

What it turns out to be that cause it (after going down the circuit breakers one by one until it stopped) was a CF bulb in the living room. But one that wasn't even on at the time. As I was taking the pictures for my last entry last night I moved around a bunch of the lousy LEd bulbs from one lamp to another to get the comparison photos. I put one of the old candelabra CF bulbs from that lamp into one that previously had a dimmable LED in it. But I failed to reprogram XTension to tell it that was not a dimmable bulb anymore. Using simulate preset dim on a regular X10 appliance module what this is means is that when the light turned itself off last night instead of sending an OFF it dimmed the light to 0. This CF bulb REALLY didn't like that. There is a tiny current flow at dimmed to 0 as opposed to fully off and this was causing the ballast in that bulb to have fits. X10 continued to work fine throughout the house, but UPB was stopped dead.

Sending the lamp a regular OFF stopped the problem. Turning it all the way on and all the way off seems to work fine, but if I dim the lamp to 0 the noise begins again. So we have our first data point in debugging for UPB.

I still have those Lights Of America branded LED bulbs laying around taking up space and decided to compare the one that ran the lumen maintenance test against one that I've never used at all and is still new from the package. They came in a package of 3 after all. I believe I commented in a previous post on a Few LED Lamps to Avoid how poor these lights lasted. I put them into a lamp here and tried to get a picture of just how dim it had become with only a couple weeks of use. The camera did it's best however to make it look much better than it was. The one on the left is the LOA lamp that had been on for the test, the one in the middle is a new one. The one on the left has become less than nightlight output. I still think it's a shame that they are overdriving the LED's or that poor design has let them overheat as the LED's themselves are the perfect color. A warm white LED seems to be a very difficult thing to make. There are no other led bulbs that I've played with that had this good a color temperature. But then I haven't played with the $100 60 watt can replacements yet that I believe may actually be useable because at $100 a piece I just can't make myself imagine they are an option for anybody seriously. But the price is coming down. These sorry bulbs were purchased at SAMS and I've noticed that wallmart has begun to carry some other LED bulbs. There are some offerings from GE that they carry now. On the test bed the last couple of weeks is a $40 GE PAR type bulb that uses 10 watts and has 4 high power LED's in it. It claims a color temperature of 3000k which is usable for high light areas but a life of only 20k hours and in reality I fear it will be much worse. The lamp gets really hot which makes me fear for the life of the LED's inside. LED's dont like to get much hotter than you can hold or it drastically reduces their life. So far just sitting on the desk shining down at my solder station though it doesn't seem to be falling too quickly. I will measure in a few more days and post the results. The bulb has no potential for dimming at all though which is a shame. They also carried a GE branded GUI10 bulb, this is a common type used in track lighting. I am playing with that too and was instantly disappointed by the color temperature, very blue 5000k'ish even though the packaging claims 3050k, there is no way that is accurate to within 2000k. It's a 4 watt bulb and if it weren't for the fact that it flickers horribly and the color temperature is useless it would be a good track light accent light. It also will let you dim it to almost nothing, but again the flickering becomes almost strobe like at lower dim levels. I'll post pictures when I do a review of the GE models soon. I'm not going to bother to do lumen testing of the track light as it's just not a viable lamp in it's current incarnation so whats the point, you wouldn't leave it connected long enough to degrade before you return it for flickering.

In the kids bathroom upstairs the light fixture was 2 4' florescent tubes fixtures for a total of 4 tubes. When we moved in only 1 of the 2 fixtures was working. I chalked it up to dead bulbs and put it at the bottom of my mental to do list. A year later when I happened to be buying new tubes for somewhere else I picked up a couple of new ones for the bathroom too, but even after installing new bulbs the fixture failed to light. Put a new ballast on the list for it then. In the next year or 2 that passed I thought of it only rarely, wondering if a bad ballast wasted a lot of electricity or put a lot of noise onto the powerlines or anything like that which might cause me trouble.

Some time later my mother in law asked me to replace a fixture for her in her kitchen which also refused to light up a new bulb. It was one in a series of tubes that run around the soffits in the kitchen and so was on with the rest of them even though it did not light. When I turned that power off and removed the old ballast it was HOT. Too hot to touch without being burned, it has started to blacken the metal case of the lamp housing it was so hot. I don't know how dangerous this really is, but I felt it was probably a good thing to have replaced it with a nice new, cool running electronic ballast for her. This got me thinking again about the lamps in the kids bathroom and that I should probably replace those ballasts too...

The light switch in the kids bathroom is wired into the Home Automation System. The motion sensor in there creates an event in XTension to turn the lights off in 10 minutes after there is no more motion. The kids just can't seem to remember to turn certain lights off so I've automated it. This stopped working recently and in my mind I knew it was the faulty ballast interfering with the X10 signal to the switch. So that moved it up to the top of the list of stuff to fix.

Yesterday I finally got around to replacing it. The fixture was 2 just bare 2 tube fixtures up in a soffit. The simple metal rectangle that houses the ballast with the tube plugs sticking down at the ends, nothing fancy and very easy to open up and replace the ballast. You just squeeze the sides and the top (or is it the bottom?) of the case will pop off exposing the wiring. Cut out the old ballast and wire in a new one.

Following the tradition of upgrading everything as I fix it around here I did not just replace with 2 more cheap magnetic T12 tube ballasts, but instead upgraded it to a single 4 T8 tube electronic ballast. Since there were 4 tubes in there and the fixtures were only about 3" from each other I just punched out some of the wiring holes that were next to each other, filled in with rubber grommets to keep the sharp metal from cutting the wire insulation over time and ran the wires for the second set of 2 bulbs into the other fixture. Should reduce ballast losses by having only one in what is basically a 4 lamp fixture anyway. T8 tubes are the skinny ones, T12 bulbs are the larger diameter bulbs that you remember from the distant past. T8 tubes generally output the same or more light with less power. A 40 watt T12 tube can be replaced with a 32 watt T8 tube and you'll still get more light. It's not a big difference, but every little bit adds up. Plus you don't have to make any changes to the fixture as the pin spacing on a T8 is the same as the older T12 bulbs. They will fit right into the same sockets. But you do have to get a ballast that is designed for the T8 bulbs. You can't just change out the bulbs without changing out the ballast too.

The old ballasts were interesting, they had already been replaced once as evidenced by the wire nuts in the circuit. The native ballast that comes with the lamp will be wired directly to the tube sockets but once you replace it you'll have to snip those and wire nut in the new ballast. So this was actually the second set of magnetic ballasts to fail in their and this is not that old a house... The one that wasn't working anymore did show signs of having been overheating. The potting compound that they fill them with, whatever it was, was actually leaking out of the corners of the ballast housing.

And while I was in there I actually connected the ground wires that were just floating in the case not screwed down to anything. Another lovely piece of electrical work that and may have contributed to the failure of the ballasts. They all suggest that the case of the lamp must be grounded, not just for safety but for proper operation of the lamps as well.

I don't know if this was a fire hazard or just an annoyance to have only 1 set of dim, flickery tubes in there, but they are all better now and I'm happy with the result. At least the result of the lamps, unfortunately it did not fix the problem with the light switch not being controllable.

It's a switchlink brand non-dimmable florescent capable device, but honestly I've never had good luck with that brand. I decided it must have just lost it's X10 address and needed to be reprogrammed, but after going through that dance half a dozen times it just refuses to respond to anything at all. Scratch one more switchlink device from the rolls of house duty. In the next few days I'll be replacing it with a UPB switch set to non-dimmable. I still have a few UPB commands that i need to build into the system before it's ready to roll out, but it wont be long before I can install these things and move the UPB interface from the test bed here into the house proper.

UPB Support in XTension is now officially in private beta. I spent a year working in the internals of XTension so that it could support any number or combination of input/output devices and that work is finally starting to show some fruit. I've added a bunch of digital I/O and several new wireless protocols since then, but this will be the first (but not the last) new load control protocol. UPB is not the cheapest of the ways out there to control things, but it might be the most reliable and usable. It's nothing new, it's been around a long time and there are several companies making units that speak it, not just one. Frankly I don't think that the much maligned X10 protocol is as bad as people make out, but it does have issues. The thing is that we know what those issues are and we have the tools to find them and fix them, as much work as that is sometimes. With new protocols often the tools and knowledge isn't out there yet to keep it working. UPB doesn't have this problem at all. The behavior of the protocol and devices is well known and well understood. So much so that installers and builders can actually put in place a system and walk away knowing that the home owners will be able to keep it working. This installed base is one thing that makes it exciting for us. A small niche of those people will be ready for some automation beyond what they can get with only the modules themselves or the alarm panel scripting that many of them use and we will be able to fill that.

If you're interested in UPB support in XTension check out the wiki article with notes on the progress so far here UPB Beta for XTension and contact me via email to join in the beta testing.