Clarification on XML socket read/write desired 2009-05-06T04:34:41+00:00

HOME Forums Gateways EZSrve Clarification on XML socket read/write desired

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • Anonymous
    Post count: 35
    #40158 |

    I have developed an automation/security solution in Java (called JASM) and am having many problems with Insteon package I’ve created to support it.

    JASM consists of a design-time IDE with ability to write event handlers, etc. Very graphical and component-based. You only import packages of components, customize created components, and then wire them together.

    JASM supports other similiar devices (a Caddx NX8E security panel, onewire, etc.) and I’m not having same problems with my code getting reliable event reporting and message sending.

    Some of the problems I’m seeing with Insteon:

    1. No documentation on low-level aspect of socket r/w behaviour

    I’ve spent weeks begging/borrowing/stealing Insteon and other docs. It’s a royal pain to get basic info…but you all know this already.

    I’ve read thru ALL forum posts and only saw one reference to xml behaviour…I believe regarding xml root elem being only sent at beg of socket session. One other solitary post on timeouts and whether it was necessary to create an event read thread and separate writer.

    2. My EZRain sometimes produces INVALID xml (can’t be dom parsed) events thru the EZServe. xml root elem is sometimes missing.

    3. Often I get event responses interleaved with message responses

    4. When I use LstDevices command to pre-read state of devices…I get bogus values for current state. Often it shows 0xFF for a light and light isn’t even on.

    Point#4 is kind of odd as I’ve had near 100% reliable message sending and event reporting…just can’t seem to get good state values from LstDevices.

    I was “hoping” to use LstDevices to “scan” what’s already setup and auto-enter this into my IDE JASM. Perhaps I need to make individual getState calls rather than use lst command (sigh)…it’s been several long weeks and I still don’t have a lock on EZServe operation.

    By the way…

    I’m using BufferedReader/BufferedWriter in jdk and am using a SINGLE thread for all reading and writing.

    When my EZBridge “component” starts up in JASM it first starts event reader thread to “drain events” that may be pending. Then when another thread (like from http) wants to send a message I “pause” my event reader, send the msg/get response (hopefully) and then unpause the event reader.

    This doesn’t always work reliably…getting intermingled responses with events…very bad.

    Clues anybody?

    Anonymous
    Post count: 35

    I decided to let my event reader thread read everything…events and responses. There is separate writer thread for issuing requests. Using this scheme I obviously can’t track response for request…but then again the failure of a light or sprinkler to turn on is in no way catastrophic so I can live with this behaviour for now.

    I thought I would show an XML dump which illustrates corrupt XML coming from my EZBridge. There is a null byte at beg of 1st event (just after response from req). As long as I remove this null…code works fine.

    parm name=name, parm value=livingRoomLight
    parm name=action, parm value=off

    Insteon MessageProcessor sending request…
    INSTEON REQUEST START:
    SendInsteon

    0F.AD.81

    Off
    Off

    INSTEON REQUEST END!

    event reader:
    event reader: SendInsteon
    event reader: Sent message
    event reader:
    event reader:
    THE LINE ABOVE IS CORRUPT AND HAS 0x0 in message…fixing it!
    fixed:
    event reader: SndIns
    event reader: 0X2
    event reader: 0X62
    event reader: 0XF
    event reader: 0XAD
    event reader: 0X81
    event reader: 0XF
    event reader: 0X13
    event reader: 0X00
    event reader: 0X6
    event reader:
    event reader:
    event reader: InsStdMsg
    event reader: 0X2
    event reader: 0X50
    event reader: 0XF
    event reader: 0XAD
    event reader: 0X81
    event reader: 0X9
    event reader: 0X38
    event reader: 0X32
    event reader: 0X2B
    event reader: 0X13
    event reader: 0X00
    event reader:
    InsStdMsg Response
    FROM: 0F.AD.81 TO: 09.38.32 MSG_FLAGS: 2B CMD1: 13 CMD2: 00

    *****shouldAlarm?
    insteon device livingRoomLight is off…
    LoggingService: Event = Wed May 06 00:21:32 PDT 2009 livingRoomLight off Living room sconce lights was turned off. null
    LoggingService: Event = Wed May 06 00:21:32 PDT 2009 livingRoomLight lightOff Living room sconce lights was turned off. null
    VoiceLogger: Attempting to speak “Living room sconce lights was turned off.”

    Anonymous
    Post count: 1001

    I was able to reproduce the situation of the leading 0x00 at the beginning of the sequence. I saw this only after the high level Insteon command call. As EZSrve Version 2 is in Beta this may be something you will have to continue to program around for now.

    Anonymous
    Post count: 35

    Are there any docs which discuss the EXACT xml representation once connected to socket?

    Should I expect to see multiple root elems (I think so)…should I expect to see an xml element before every response or event?

    Will insteon batch send all past events (within window) once client reconnects? My security system (Caddx) does this…but perhaps Insteon events aren’t considered as critical…although events from motion detectors could be.

    Tonight I will test whether individual getState calls work better than LstDevices. I guess I can broadcast for an ezserve…then use LstDevices to ‘discover’ rest…then invoke individual getState on each. LstDevices w/be cool as I can auto-gen much of metadata in my solution….less data entry.

    Will new firmware fix problem of events being sent to clients that are connected only for purposes of sending a req and expecting a resp? If not…then my message writer will have to handle these unexpected events in stream and pass them to eventReader for processing after messageWriter is completed.

    Thanks for all your help grif.

    Anonymous
    Post count: 1001

    In the Downloads section, XML Samples, and in the Wiki, XML API Version 1.X, which is the latest I have seen on V1 XML. I don’t think you will find any document from any source that would qualify as EXACT for any aspect of Insteon. Of the various companies distributing Insteon products, SimpleHomeNet provides the most detail I have seen for its products, above what you can expect from Smarthome. They describe the hardware memory map, commands for their devices, content of link database link records, etc., something Smarthome has not made public information. However, with the evolution of Insteon itself and products that run in the Insteon environment just do not have the years of stable environment which would allow the documentation to reach the level of detail many folks would like to see.

    It has been my experience that responses start with , The caveat is I have not tried every command so I would not take that as an absolute.

    No component, hardware or software, stores Insteon messages to be passed to an application at a later time.

    There is no mechanism to direct EZSrve to return only responses to specifically issued commands.

    Anonymous
    Post count: 35

    @grif091 wrote:

    I was able to reproduce the situation of the leading 0x00 at the beginning of the sequence. I saw this only after the high level Insteon command call. As EZSrve Version 2 is in Beta this may be something you will have to continue to program around for now.

    After some googling I see this bug has been around for over a year….

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