-
Notifications
You must be signed in to change notification settings - Fork 130
Insteon for X10
- NOTES
- This page has not been editted in quite some time and contains some significantly out of date information. If you are new to Misterhouse and Insteon please stick to the rather detailed Insteon page for the time being. It has been significantly revised to make it more accurate
include component="pageList" hideInternal="true" tag="insteon" limit="10"
First of all, misterhouse's Insteon support allows for everything you could do with X10 on unix and more (send commands, run random code on receipt of a code equivalent, and querying devices for their status).
While with X10 you send a code broadcast on the line (A10 on) or listen for that code, with insteon, you need to pair the sender (switch, motion sensor or remote) to the receiver (other switch, lamplink/appliancelink, or PLM). Linking is crucial as it is required for the sender to make sure its targets acknowledged the command, and the only way for targets to respond to a command.
3(-N) way switches on Insteon work by having a single switch control the load while the other switch(es) doesn't/don't toggle any load but is/are used as a remote for the first switch. Switches only send a code when they are physically toggled, if they are toggled remotely, they do not send a command to the other devices they are paired with. This is how in a 3 way switch situation, if you physically toggle switch #1, it will tell switch #2 to toggle, but remotely toggled switch #2 will not try to send a command back to switch #1. This however means that for switch status consistency, when you use mh to control a light on a 3/N way switch, you need to send the on command to all switches, even if only one of them actually controls the lights.
Back to switching from X10 to Insteon: on linux, you'd use heyu to send X10 signals and xtend to listen for X10 codes and run programs. There are some ways to send commands to insteon devices without mh (plmsend), and no way I found to receive insteon commands without mh, so you want mh :) (remember that your plm should not receive commands without being paired with the senders anyway).
With misterhouse, you can also ask a switch for its status, although mh tries to keep switch states by asking you to configure switches so that they notify the PLM (power line modem) that mh talks to. The main reason for mh to keep switch/device states internally is that querying devices periodically generates a lot of traffic, so you'll want to have mh be configured so that it knows what your switch to device relationships are, and configure all your switches, remotes, and motion sensors so that they send toggle updates to your PLM. That way, mh will know what your device state is without querying everything all the time.
As far as an X10 -> Insteon/mh mapping goes:
- In dual X10/Insteon environments, mh receives and deals with X10 and Insteon commands the same way, transparently to you.
- for any heyu command, you just tell mh to control the switch, like $fmr_light->set(ON).
- for xtend commands, you need to write mh code that goes in the main loop and you can query the current mh kept state with $fmr_light->status() or state changes: $fmr_light->status_now(). Note that in my testing, mh receives an X10 code through my PLM 2-3 seconds faster than xtend does through a CM11a.
- for the few X10 devices with extended codes that allow you to query their status, first you should not have to query devices for their state directly since mh is supposed to keep track of that state for you if you properly configured it with all the switch relationships, but if things got out of sync, or you have other senders that mh doesn't know about, you can use $fmr_mast->request_status(); print_log "status ".$fmr_mast->state_now();. Note however that this is not something you should run in a loop since it would generate too much Insteon traffic.
So, in an ideal world you can buy solely Insteon devices, but you may find out that re-using some old X10 devices works well enough, or you may want to purchase at least X10 RF devices, like <$10 MS13a or MS16a motion sensors, or dirty cheap wireless remotes. I have read that the more Insteon devices, the more they will interfere with X10, which is plausible, especially as X10 doesn't retransmit commands and Insteon devices only retransmit/amplify Insteon commands, not X10 ones. So if and X10 command gets lost or has a collision the first time, it will not make it to destination. That said, especially if you have an active phase coupler/amplifier, X10 still works well enough for non mission critical cases (i.e. nothing that involves keeping animals alive, water from not overflowing, or your garage door to remain closed :) ), and it works great for using wireless X10 RF remotes where you can press the button again if the first press didn't work. Note that X10 active phase couplers do not bridge Insteon commands, just X10 ones (a passive X10 bridge should bridge Insteon too, but a) you should really bridge Insteon with APs anyway and b) X10 can get weak enough that you do want to invest in a $100 active phase coupler if you are going to use X10. You'll thank yourself later in the time you didn't spend debugging X10 not working :) Also, remember that while mh can't upload a pairing of an X10 switch/remote to an insteon device, insteon devices can be programmed so that they directly respond to one X10 code, you just need to program this on the switch directly (you won't need for mh to be in the middle and gateway a single X10 to a single Insteon command). One caveat with enabling X10 support on your Insteon switches is that it's possible for your switches to toggle due to spurious X10 commands you did not originate (i.e. noise on the line). If you get unexplained toggles on your switches, consider turning their X10 code support off.
Insteon does have a motion sensor, although it costs about 5 times the price of the X10 ones ($50-ish vs $10). With an X10-RF bridge, you can retransmit those X10 codes and keep using those cheap keyfobs, and glue on wall light swiches. To support X10, you can either have the X10 code go to MH for processing, or configure your Insteon switch to repond to one X10 code, but that programming is done on the switch itself, not through mh. There is also a X10RF to Insteon converter which leverages your cheap X10 RF senders but never sends X10 codes on your powerline, they are directly converted to more reliable Insteon commands (some other people use a PC interface meant to receive those X10 RF codes and feed them directly into the PC, assuming your PC and/or antenna are close enough to the RF transmitters). Because wireless remotes, or multi button switches on Insteon and others cost in the range of $50 or more, it may be attractive to use less reliable X10 ones for the times where you can afford potential signal loss (which you hopefully won't with an active X10 couple/amplifier).