Using EZBridge/Serve with JDS Controllers 2008-09-10T17:22:36+00:00

HOME Forums Gateways EZSrve Using EZBridge/Serve with JDS Controllers

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
  • Mitch@MDH
    Post count: 29
    #40054 |

    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 < ?XML .... line is not necessary; 2) make ONE macro
    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]
    ASCII-Out:’<0><17><255> [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…..


    Rock on!


    Post 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:

    ASCII-Out:’’ [COM3]
    ASCII-Out:’’ [COM3]
    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)
    DELAY 0:00:00
    (THEN MACRO: Dining Insteon ON)
    (THEN MACRO: Entry Insteon ON)
    DELAY 0:00:00

    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:



    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.


Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.