| ECS Home Automation and Security Archives |
| Subject: From: Date: | Re: [ecs] [ecs] NOT RECOMMENDED devices by Applied Digital William Smith Thu, 27 Sep 2007 12:51:59 -0700 (PDT) |
I was not aware of the IR issue, I did not remember seeing it mentioned in the ECS documentation...could have missed it. As far as I remember from the ECS documentation, the Ocelot is the only interface that support ECS learning and saving the signals instead of the hardware device performing this function, like the Homevision. I was considering investing in some Applied Digital hardware for my system, but their lack of response on these bugs is a deal breaker. Plenty of other options for analog and digital I/O with ECS. Thanks for the detailed follow-up. Bill Mark Gilmore <mark3@OmnipotenceSoftware.com> wrote: Hi Bill, A detailed description of these problems follows. I have sent this info to Applied Digital 3-4 times during the past few years (the latest being a around a week ago). They have never conveyed a significant interest in addressing them. Regards, Mark Ocelot problem #1: NOTE: THIS problem IS CRITICAL, as it will cause the host software (e.g. ECS, HomeSeer, etc) to interpret the inserted FF as the 1st byte of the I/O-data array. Hence, the entire array will be skewed and *every* digital input state will be corrupted. If these inputs are used for security, numerous/erroneous alarm conditions could/will result. The problem scenario is as follows: Note: During init, host pgm (ECS) issues a WT_CPUXA_PARAM_DATA cmd, which tells the Ocelot to report I/O changes (via FF byte). 1) Ocelot detects an I/O change on a digital-input and sends FF to ECS to denote same. 2) ECS issues a GET_LATCHED_IO cmd to read the updated inputs. 3) Ocelot sends cmd ack (6/0/6) with I/O data *to follow*. 4) At this precise time, the Ocelot *asynchronously* detects another I/O change and sends FF to ECS. 5) Ocelot sends the requested I/O data. Now the host software cannot determine whether this "inserted" FF is to be interpreted as I/O data or an I/O-change report byte. It *could* check the remaining # of bytes of the serial FIFO and assume an I/O-report byte if the total is 1 greater than the data response. But what if additional async data (such as X10 data) followed ? Not pretty. This problem could be corrected by blocking the transmission of the FF until the *complete* response to any given cmd is transmitted. Ocelot problem #2: Ocelot occasionally sends a triad of 3 zero bytes (which have no meaning per the protocol spec). Example packets (both lead with the 00 00 00 triad): 00 00 00 fc 9d 00 fc 9d 00 (00 00 00, followed by 2 transmissions of my TV-Volume IR signal) 00 00 00 fb 01 01 fb 01 12 (00 00 00, followed by 2 A/DIM X10 transmissions) As I generally send the volume signal numerous times and X10 DIMs are also frequently sent numerous times, I strongly suspect that this problem is related to the *multiple* transmission of IR signals and X10 cmds. Perhaps the 00 00 00 was intended to be one of these, but was zeroed out somehow ? This problem is not of the same priority/importance as #1 (as it will not trigger any significantly harmful results). However, the fact that bytes are being zeroed-out could be indicative of a more serious (internal) problem. Ocelot problem #3: Ocelot occasionally reports a 0 for some analog-inputs: Incorrect (0) response (see val in asterisks): Get SECU ani data 8/04 07:29:45 TX: 2a 00 00 8b b4 00 a4 78 8/04 07:29:45 RX: 2a 00 00 8b b4 00 29 00 27 00 fd 00 fd 00 *00* 00 ff ff ff Correct (36/x24) response: Get SECU ani data 8/04 07:30:46 TX: 2a 00 00 8b b4 00 a4 78 8/04 07:30:46 RX: 2a 00 00 8b b4 00 29 00 27 00 fd 00 fd 00 *24* 00 ff ff ff At 08:47 PM 9/26/2007, you wrote: >I noticed that the following supported devices on the ECS home page >are annotated "not recommended due to a bug in module's >firmware". Does anyone know the background on this bug? I was under >the impression that some of the ECS users were using these devices. >Here is the excerpt from the ECS home page: > > >BobCat (ADICON, not >recommended due to a bug in module's firmware) / >Applied Digital >" SECU-16 (ADICON, not >recommended due to a bug in module's firmware) / >Applied Digital >" SECU-16I (ADICON, >not recommended due to a bug in module's firmware) / >Applied Digital > >Best regards, >Bill > > >Take the Internet to Go: Yahoo!Go puts the >Internet >in your pocket: mail, news, photos & more. Mark Gilmore http://OmnipotenceSoftware.com --------------------------------- Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search.