Re: Survey: Home Control Software

["John J. Bengii" <nobody@xxxxxxxxxxxxxx>]

LOL. I doubt I will have lots of time to troubleshoot. I am building
the home, mostly myself. This wasn't intentional but it is hard to
find decent labout at a realistic price around that area.

The worst problem I have is my sunrise halogen that I progressively
briighten on work mornings. Some days the wall wart dimmer will not
shut off and I have to unplug it. I have tried different units with
the same success. I suspected I was pushing the unit's heat rating
(300W) and got a 200Watt bulb with the same result. Basically there is
nothing else on the circuit and it appears to work fine in the another
circuit. I have checked all the electrical connections and suspect
some kind of resonant tuned circuit in the cable length. My TW523 is
at the service panel for centralization with a 100' RS-232 connection
to the computer.

Basically I would also like to get something that will run on a
Windoze machine with network access to the beast. Currently I can only
run in DOS and I cannot for the life of me remember how to get all the
NIC drivers working. Win 3.11 used to set them all up for you and then
you just dropped the GUI. I wrote my own code for the CM-11 but can't
get through some of the protocol spec published. AFAIC it just doesn't
work in spots. On a power blink it needs to be accessed and relaod
macros or something (been a long time now) and haven't been able to
make it talk that part of it. I am sure there is all kinds of code and
drivers out there that are good for an old hack like me to boost his
starting point.

Is code writing for hacks supported with the Insteon i/f also?


"Dave Houston" <nobody@xxxxxxxxxxxx> wrote in message
news:4773e7e2.24639250@xxxxxxxxxxxxxxxx
> There's a "gotcha" with the gradual replacement scenario. Each
> Insteon
> device is two-way and the transmitters attenuate X-10 signals in the
> same
> manner as two-way X-10 devices do. The more Insteon devices, the
> better the
> Insteon reliability but the bigger the hit on X-10 reliability. It
> depends
> on how many total devices you have but at some point you'll probably
> find
> you need to convert all remaining X-10 devices.
>
> All that said, most of the people using Insteon report good
> reliability
> although some report problems. While Insteon is subject to the same
> signal
> attenuators and noise sources as X-10, filters will fix most
> problems as
> they do for X-10. There are some persistent complainers on the
> Insteon forum
> but I suspect most are from people who really do not understand it.
>
> I think an ESM1 signal meter is almost a necessity. It lets you see
> X-10 and
> Insteon signals (although it cannot interpret Insteon) and measure
> relative
> amplitudes. It can eliminate most of the guesswork.
> AutomatedOutlet.com will
> even loan you one - knowing full well that 98% (my WAG) of the
> loaners turn
> into purchases.
>
>
> http://www.automatedoutlet.com/product.php?productid=463&cat=0&page=1
>
> Insteon prices have edged up plus they have apparently discontinued
> some of
> their lower priced "value" lines but I think it is still the best
> choice for
> new installations where the user doesn't want to spend far more for
> hard-wired low voltage control. However, someone who has a large
> X-10
> investment and understands the ins and outs is probably better off
> sticking
> with it.
>
> Given that you've had X-10 problems, you may continue to have them
> with
> Insteon. You probably need to run the the problems down before
> deciding.
>
> Whichever way you go, as you move into the new house, deploy
> switches and
> modules in sub-groups so you can find and fix problems before you
> have a a
> large number of devices. Troubleshooting a limited number of devices
> is
> easier to manage. You'll have lots of time to troubleshoot.
>
> "John J. Bengii" <nobody@xxxxxxxxxxxxxx> wrote:
>
>>I was not aware of the RF missing factor on these devices. You are
>>correct on the overhype. They discuss this technique in depth and
>>give
>>the impression all Insteon devices are "fully equipped" but when
>>examining their remote units, the RF is never mentioned.
>>
>>The units are quite pricey and the slow replacement of X10 devices
>>seems attractive. Most of mine have been removed from service due to
>>several reasons
>>- I am building a new home and recovering units for the move.
>>- many operated unreliabily or not at all despite two powerline
>>signal
>>bridges and neighbour blocking devices.
>>- too may light left on for days is costing me energy money on my
>>bill, despite software to shut them down a few times a day for "just
>>in case" scenarios.
>>- too many "all lights on" in the middle of the night from wireless
>>receivers (I think)
>>
>>I short the three of four dozen units and 15 years of trying to
>>perfect the system has resulted in a complete distrust for X10 units
>>and there is only a few spots where flakey can be useful. Soon I
>>will
>>retire and won't need my "sunrise" algorythm for a 300W halogen
>>anymore either. I was hoping Inteon may be an answer for a
>>technology
>>hungry kid.
>>
>>"Dave Houston" <nobody@xxxxxxxxxxxx> wrote in message
>>news:4775911c.2425218@xxxxxxxxxxxxxxxx
>>> Unless you're using something that receives RF directly, you
>>> cannot
>>> see the
>>> RF messages. You only see powerline messages so the incorrect
>>> command has
>>> already made it to the powerline before your software is aware of
>>> it.
>>>
>>> Even if your software does receive direct RF messages, there are
>>> seldom
>>> collisions between RF codes and when there are, the result is
>>> garbage -
>>> there's no possible way to sort out what the two colliding
>>> messages
>>> were.
>>> The RF messages do contain data which allows a receiver to check
>>> validity
>>> but any corruption will merely cause an invalid message it will
>>> not
>>> cause
>>> one message to be transformed into another. IOW, corrupt RF
>>> messages
>>> never
>>> make it to the powerline from any X-10 transceiver.
>>>
>>> Bream Rockmetteller <bream(dot)rockmetteller(at)mac(dot)com>
>>> wrote:
>>>
>>>>Regarding the software, the reason it knows it has received a
>>>>"bad"
>>>>message is because I told it so. When I have a light act in a
>>>>strange
>>>>manner, I look at the log that Indigo keeps.
>>>>
>>>>If I see that an RF switch somehow transmitted "turn on E10"
>>>>instead
>>>>of
>>>>"turn on the kitchen lights" which are E1, I'll  add a script in
>>>>the
>>>>"Trigger Actions" sections that says something like "If you
>>>>receive
>>>>a
>>>>message to turn on E10, send a message to turn on the kitchen
>>>>lights."
>>>>That way, even if the switch or the receiver or some random noise
>>>>has
>>>>caused the message to go bad, the software will re-transmit the
>>>>correct
>>>>message.
>>>>
>>>>I hope this helps...
>>>
>>>
>>> http://davehouston.net  http://davehouston.org
>>> http://tech.groups.yahoo.com/group/roZetta/
>>> roZetta-subscribe@xxxxxxxxxxxxxxx
>>
>
>
> http://davehouston.net  http://davehouston.org
> http://tech.groups.yahoo.com/group/roZetta/
> roZetta-subscribe@xxxxxxxxxxxxxxx