AnonymousInactiveSeptember 10, 2008 at 5:22 pmPost count: 29
People out there who use JDS X10 controllers (Stargate, Comstar, Timecommander, etc) may find this useful for Insteon integration.
Stargate speaks Insteon
After a series of false starts and mistakes I have been successful
getting the SG to speak Insteon. Since Insteon was introduced I’ve
been waiting for the post to a forum like this from the person who
figured out how to make it work. So, maybe there are people out there
that have made it work and are just not sharing with us? In any case,
I decided to dig in and give it a try. Please excuse my rambling as
we go through a step-by-step history of my attempts, successes, and
failures. But I learned a lot about how Insteon, serial
communication, and the SG system work along the way, so reading
through this you might be beneficial for a range of DIYers out there.
Below there are two different solutions to the SG-Insteon
communication problem. The first installment discusses using the XML
language over your intranet. The second has the SG talking directly
to an Insteon PLM…..and both work.
1. First installment- let’s try sending XML packets.
I got this idea after SimpleHomeNet (SNH) released their EZBridge
(EZB). This has since been updated to the EZServe, which has the
bridge board built in to an Insteon PLM case. The EZB is the same as
EZSServe but the bridge has an ethernet port and speaks XML. The
firmware updates posted (monthly almost!) at the SNH web site work the
same on the bridge and serve devices, and include a web interface as
well as a utility for creating macros, timers, and controlling Insteon
or X10 devices. This system is very flexible with scenes and groups
that can be controlled in concert. After I figured out that I had to
link the switch and the PLM in both directions (master-slave and PLM
as the slave to the switch) to get the macros to work I have been very
happy with it (it transmits X10 addresses to update them in SG’s
database whenever somebody presses an Insteon switch paddle). I also
like this MUCH better than the Houselinc software, which is a horrible
product and should not have been released in it’s current condition.
Unlike HL, linking the PLM to devices is quick and painless using
SNH’s web interface. Macros and timers are also easy to define,
although these are all based on single conditions (no complex `If this
and that is true then…’).
Jeff informed me that the WebX was not capable of speaking XML, so my
idea was to obtain a serial to ethernet converter (an eCov 110 in my
case) to have the SG send XML as ascii through com3 (com2 is busy
talking to my Rain8Net). This actually works, but you have to make
some adjustments and it has some major drawbacks:
1. Lines of ascii characters have to be less than 32 each- so you
need to send one only line of XML per ascii-out command.
2. The eCov needs a delimiter so it knows when to send a packet of
code. This is easy to define in the eCov web interface (I used the
period [.] – 2e in hex) and then you just put a period at the end of
the last line of XML. Insteon in XML that turns on a switch looks like
SndIns 0X0B 0X97 0X94 0X00 0X11 0XFF.
Parameters 1 – 3 are the three hex codes of the Insteon address. The
last two are the command – this case 11.FF means turn on full bright.
You can ignore P4 for the most part.
3. FIRST PROBLEM – XML uses the
brackets to delineate
commands. Unfortunately, SG uses the same characters to embrace a
variable you are trying to send. So, when you send the code above to
SG what actually come out the serial port is this:
And the EZB just says `huh?’ At this point I wrote Jeff and he
pointed out that I could use the binary (actually decimal) output in
SG’s ascii out window to indicate
characters (decimal 060 and
062). You can also just type this: <60> and <62> to send the
decimal code for the
ascii characters (leading zeros or not-
doesn’t seem to matter). At this point little lights started going
off in my head about using this to talk straight to the PLM- more on
that below. So now, just replace all the
with <60> and <62>
and it works! Yes, it really works. I actually put the binary
commands in separate ascii out commands (not sure that is necessary),
which runs us into the next problem….
4. PROBLEM – too many then statements error from WinEVM. Ok, so you
can just divi up the ascii out commands to a series of if-then’s in a
macro and it works fine.
5. ANOTHER PROBLEM – The EZB/EZS devices send a steady stream of
insteon and X10 responses over the internet to the eCov, and then
straight into com3. Not a problem with many devices, but SG cannot
live without the occasional carriage return. The guys at SNH added
LF’s and thought that would solve my problem, but no- it’s gotta be
CR’s or SG just locks up (the top red led stops blinking and all
network communication is locked). The only solution I have for this
so far is to cut the Rx wire coming into SG so it never hears the
babble (making it effectively deaf). But do not despair! We still
have insteon commands going out of SG doing everything you might want
to do to a device (dims, groups, scenes, you name it). But notice,
that’s a lot of ascii out commands…. .
6. NEXT PROBLEM – I ran out of memory on the SG board! Yes, you
need a macro with many lines just to turn a light on or off. I have
about 4,000 lines of code with variable-based count-down timers, HVAC,
and home theater control with maybe 60 controllable switches in the
house. Before adding Insteon macros my mem usage was at 95%. You
can make XML control of Insteon a lot more efficient if you 1) leave
off the first line for the each device (just through parameter 3), and make one macro for
each ON, OFF, and DIM levels. Then you can just link macros like this….
Event: Insteon XML on
(DI:Front door) Goes on
(THEN MACRO: Insteon ID Entry light)
(THEN MACRO: Insteon ON)
Just make sure your ON and OFF commands have the delimiter at the end
of the XML code so your eCov (or whatever) knows when to send the packet.
Assessment: Using XML packets with the SNH devices works very well
for controlling Insteon devices. I was amazed at how fast lights came
on in response to a motion detector or door. The speed of sending
ascii code is not limited as X10 commands are – X10 requires a
built-in delay between commands. That means you the SG will always be
sending code like this: X10 and wait and X10 and wait and X10
…..etc. This slows down device responses and slows your whole
schedule. Even with the large XML packets it was more like RF-RF-RF
with no delays. The difference was noticeable. It got even a bit
faster when I cranked up the SG and eCov serial communication to 19200
from the 9600 kbs I was using for testing. Oh yes, and very reliable-
no errors during a few days of testing. So, this would be a very good
solution if your schedule is not too big (like mine is). The commands
are very reliable, and macros in the EZB allows to keep up with status
changes in your X10 addresses (note that I removed all my X10
addresses from my Switchlinc V2’s for all this testing). Keep your
addresses updated within your SG using the X10 status commands (avoids
sending X10 code over your power lines).
2. Second installment- let’s try talking directly to the PLM. So, as
I said above, once I finally realized that SG can send binary
(decimal) codes (it’s not in the manual!) it occurred to me that yes,
we can speak directly to the PLM without all that cumbersome XML code.
Here’s what you need:
Lesson 1 – I had to learn how ascii, hex, and decimal codes work.
Get yourself a serial PLM (2412s) from Smarthome and download the
trial version of Docklight Scripting to talk to it with your computer.
You can also find a `PLM_Basic_Command_ Set’ from Insteon to get you
started (don’t have the url off hand). Configure your SG com port to
19200 8N1. A typical command in hex to the PLM will look like this:
02 62 11 11 11 00 11 FF
The 02 62 means `Send Insteon’
The 11 11 11 is where your device address goes
and 00 11 FF means turn on full bright.
In decimal (binary in winEVM) it translates to:
002 098 017 017 017 000 017 255
So the Insteon commands to send out of com3 to the PLM looks like this:
ASCII-Out:’<2><98><17><17> <17>‘ [COM3]
-You cannot use ascii because the translation does not work: 02 hex
in ascii, which is several chars and not just one. SG would
interpret it as 5 chars even without the < > problem)
– Note that you need a at the end of each line to avoid sending CRs
and to link the lines of code together. If you do not add the at
the end of the lines SG adds the CR (0D in hex) and the PLM just says
– Second note: You still need to clip the Rx line on your serial cable
that goes into SG or you will have the same lock-up problem I had with
the eCov. You will have to make your own cable, but pretty easy with
RJ-11 and -45 connectors and the crimp tool from your local Home Depot.
Yes, this works! It really works very well for single commands.
You can add X10 address `Status’ changes (change the status without
sending X10 codes) paired with your Insteon commands to keep track of
device statuses and this will work very nice. You can define say a
flag associated with on/off insteon commands – set and clear the flag
in winEVM and watch the light go off and on real quick – fun! But, as
always, there are a couple of issues to overcome:
1. Closing the circle- updating SG after device actions. You can
update SG after somebody turns and Insteon switch on/off using macros
in the EZB or EZS (or ISY or some software – not Houselinc!). In a
complete Insteon installation the only X10 traffic would be to send
these updates to SG- you could even put them on an isolated line to
avoid any noise problems. My guess is that your schedule should also
run much faster since you won’t be bogged down with X10 send delays.
SNH could make our lives much easier if they would add another serial
port to EZB and allow us to configure it to add the CR delimiter- then
we could use ascii-in commands to update the address directly and
avoid X10 altogether.
2. PROBLEM- without the Rx line connected there is no coordination of
communication between SG and the PLM (I think). The problem is that
if you send two consecutive commands the second one will have no
effect. Realize that I am not a techoid, but I think the PLM is
echoing the first Insteon command at the same time the SG is trying to
send it the next command. The easy fix to this problem is to insert
commands between Insteon commands to slow down the SG before it sends
the next command to the PLM. I had to add three delays for 0 seconds
to make this work reliably, the result is much slower even than clunky
ole X10 would be. It works just fine, but it is slow. I also expect
the occasional command failure as the SG sends are bound to conflict
with PLM responses once in a while.
To solve this I am in the process of getting a serial switch with
buffers on each input/output ($10 – $100 on ebay – a Black Box Data
Broadcast DB8/25 in my case). I hope this will have the capability of
doing all the traffic control for me and should allow consecutive
Insteon commands from SG to work just fine. It should also allow me to
hook both the SG and the EZBridge to the same PLM (instead of two
separate PLMs). So, I will test this in a few days….. (How many
times have you read a post like this ending with “I’m waiting for ….
I’ll let you know….”). So- sorry I don’t have the final solution
yet- I am very hopeful. But now we can at least dismiss all the old
myths and nay-says, because we know that…..
STARGATE DOES SPEAK INSTEON!
Mitch@MDHAnonymousInactiveSeptember 13, 2008 at 8:28 pmPost count: 29
Stargate-Insteon Integration: Update
I now have my PLM command sequences in then Macros. Each consists of two lines of ASCII-Out code (decimal numbers) and an X10 address status update like this:
X10:A-3 Set State to On
The X10 “Set State” commands change the state in the SG memory (displayed in the MegaController window) without sending X10 signals. A series of Then Macros can then be called like this:
(THEN MACRO: Kitchen 1 Insteon ON)
(THEN MACRO: Kitchen 2 Insteon ON)
(THEN MACRO: Dining Insteon ON)
(THEN MACRO: Entry Insteon ON)
Note that the DELAY commands for zero seconds are inserted every two Insteon commands to give the PLM a chance to process (three in a row creates errors). It turns out that the PLM controls flow from a host by sending ACK or NACK bytes at the end of its response to each command. If the host sees a NACK in response to a command it is suppose to resend the same command. Since the SG does not see these, we need to use this ‘Duct tape’ solution to control data flow to the PLM (using the buffered switch mentioned in the previous post did not help at all). BUT- I did an acid test with this method and it worked great. Here’s what I did:
I created an event that turned on five Insteon lights in sequence, then turned the same five lights off, and repeated this five times for a rapid sequence of 50 on/off commands. I then had my kid start the sequence while I timed from when the first light came on to the last light going off- this was consistently 6 – 7 seconds! Really fast! After doing this 10 or some times we saw no errors in the light status at the end of each trial (all five lights were off). I also have had no errors in a week of testing this method. So, I’m expecting that I might get more errors as I increase the number of Insteon devices (I have six right now), but for now this is a very reliable and simple solution for Insteon integration.
Just for grins we tried the same experiment with X10 lights – 5 lights with 50 on/off sequences same as above. We just tried this once (the kid was getting impatient), but it too 47 seconds to from the first on to the last off – that’s almost one second per X10 command whereas Insteon is doing 7 or 8 per second.
So, for now I’m settled on using the PLM but am keeping my eCov 110 in reserve in case I need it down the road. One good thing is that the folks at SimpleHomeNet have made higher level XML commands that are simpler and more intuitive. This is the SendInsteon command set available at this site:
The commands look like this:00.4F.AA
But note that you still have to use the Binary command (decimal and ) for the bracket characters – . The command set includes lots of dim levels but currently is pretty limited.
I would be interested to hear about anybody else’s trials with these methods, or maybe somebody can figure out how to solve the serial communication problem with the SG. Apparently the ISY controllers have an extra serial port that could be used to directly communicate with the SG. I don’t have the bucks to shell out for one of those, so unless Universal Devices is willing to give me one to experiment with, somebody else will have to tackle that one.
- You must be logged in to reply to this topic.