Situation: You want to use an X-10 PalmPad and your existing X-10 interface on your HomeSeer system to control Z-Wave devices. Or, you have both X-10 and Z-Wave devices on the same devicecodes (or on the different housecodes but the same unitcodes), and you want to ensure that if you turn on the X-10 one from a PalmPad, the Z-Wave one comes on as well.
Solution: Create a single event in HomeSeer. The trigger should be X-10 Received. Select the housecode that the X-10 devices are on. For the unitcode, choose Any, and for the command, choose Any. The action is a script command, as follows:
If the devices are on the same housecode:
&hs.ExecX10 hs.StringItem(hs.LastX10,2,";"), hs.StringItem(";on;off;dim",hs.StringItem(hs.LastX10,3,";"),";")
If the devices are on different housecodes:
&hs.ExecX10 "q" & mid(hs.StringItem(hs.LastX10,2,";"),2), hs.StringItem(";on;off;dim",hs.StringItem(hs.LastX10,3,";"),";")
Change the q in the latter to whatever housecode you want to control. For instance, to use a PalmPad set on housecode D to control Z-Wave (or indeed, any) devices on housecode R, make the event trigger be housecode D, and change the "q" to "r".
Limitations: This will work for on and off, but not quite for dim; that requires a tiny bit more smarts, but more than will fit in a one-liner. Maybe someday I'll write an actual script to do that; it would only be a few lines long.
This depends on you receiving X-10 commands into HomeSeer in some way; usually that's a PalmPad, keychain remote, sticky-switch, motion sensor, etc. working through an MR26A, TM751, W800, etc. but it could also be other devices putting X-10 onto the powerline (such as PowerFlashes) and this being picked up by your CM11A, Ocelot, etc. Simply operating the local control on an X-10 device will not generally do this, since most will not transmit when operated locally.
Doing this the other way around (Z-Wave to X-10) would be harder since not all Z-Wave devices will notify HomeSeer when they've been changed, whether locally or remotely, and since the Z-Wave USB interface won't tell HomeSeer when someone has used a remote control to operate a device. That said, it'd be very easy to write a little script that would trigger on status change of devices and echo the command; the echo would simply be delayed until the next polling interval for most Z-Wave devices, since that's the first time HomeSeer would know anything changed.
Subscribe to:
Post Comments (Atom)
1 comment:
Why isn't a capability like this built into HomeSeer? Good question. Plenty of people have asked for it, but HomeSeer doesn't seem interested in either doing it, or giving a straight answer about why.
The excuse they give is that it would be too hard and too complicated to implement mapping across protocols and device types. They also threw in a litlte bit of noise about the need to be able to configure it.
In fact, HomeSeer has had the native capability to do precisely that mapping across device types since the first day they added support for non-X10 devices. It's built right into the hs.ExecX10 command that is the meat-and-potatoes of all HomeSeer scripting. That's how this one-liner works; it just asks HomeSeer to repeat the last command, and relies on HomeSeer's native ability to map across device types and protocols to do all the rest of the work.
It seems plain that the real reason they don't want to implement this feature, no matter how many people beg for it, is that it would create a few extra support questions they'd have to answer. That would mean they'd have to take a few of their existing FAQ items and copy-paste them. "Why doesn't HomeSeer update my Z-Wave device status immediately when I use the remote?" would be copied into "Why doesn't HomeSeer echo commands to my X-10 devices immediately when I use my Z-Wave remote?"
This is a perfect example of how HomeSeer is going into the toilet. It's not that they're in it for the money: they always were and there's nothing at all wrong with that. And it's not that they're looking to "dumb down" the program: they've been trying to make it more accessible to everyday users for years, and that's precisely what they had to do. Those things are good and fine.
But they've cut themselves off from their users. They no longer listen. They do what they want, not what the market wants. They have created an antagonistic relationship with the people they need the most; in every way they act like their users are a problem they are forced to deal with, a burden, rather than their best resource, the thing that got them where they are today.
They're inches from a bad fall and crawling closer every day. But that's okay, because when it happens, they'll have all their blame lined up in advance. And blame is more important than actually solving problems. See, it's a very tidy and self-correcting attitude problem.
Post a Comment