Scott Hiles
2003-05-22 14:20:36 UTC
For quite some time I have known that the log looked odd when working with
devices that provide feedback on the X10 line. This is mostly limited to
two-way switches. The protocol for X10 isn't specific in how a switch must
respond to a status request and so some switches respond with just their
status while others send out their address followed by their status.
The former category is relying on the address put on the line from the
originator of the request to be the last address on the line such that the
response matches to that address. By the protocol standard, until another
address is received after a function is transmitted, any other functions
seen on the line are to be assumed to be for the last address. This allows
you to send "E10, E ON, E OFF, E ON, E OFF" to blink the light at E10.
But, this caused a problem for drivers that utilized the fakereceive=1
argument (the default for CM11A, CM17A, and PowerLinc USB) because the
internal state machine was only updated after the transmitter had completed
its work and returned a success. The benefit to this was that the state
machine was only updated if the transmitter completed. The transmitter may
not have completed if there was lots of noise on the line resulting in the
number of retries being exceeded. But, it had the artifact that it reversed
the order of any responses received from the line during transmission. So,
instead of seeing "T E10, T E STATUS, R E STATUS=OFF" you would see "R E
STATUS=OFF, T E10, T E STATUS". This was a result of the driver being
interruptible and reentrant (as required) such that the X10 network would
transmit the response before the driver could finish the transmit function.
Version 1.6.3 changes the behavior such that the transmission is faked
before the transmit actually occurs. This results in a more accurate
representation of the internal state of the network and most importantly, an
accurate representation in the logs. As a result, if using wishweb, the
two-way devices will be correctly reported and maintained in the GUI.
One other addition to the package is a little script called "mkrpm.sh" which
is what I use to create the RPMs for distributing the pre-compiled objects.
It requires a couple of arguments manually and is a trivial script. If you
can make this little script work better, I am more than happy to accept code
changes.
Scott
devices that provide feedback on the X10 line. This is mostly limited to
two-way switches. The protocol for X10 isn't specific in how a switch must
respond to a status request and so some switches respond with just their
status while others send out their address followed by their status.
The former category is relying on the address put on the line from the
originator of the request to be the last address on the line such that the
response matches to that address. By the protocol standard, until another
address is received after a function is transmitted, any other functions
seen on the line are to be assumed to be for the last address. This allows
you to send "E10, E ON, E OFF, E ON, E OFF" to blink the light at E10.
But, this caused a problem for drivers that utilized the fakereceive=1
argument (the default for CM11A, CM17A, and PowerLinc USB) because the
internal state machine was only updated after the transmitter had completed
its work and returned a success. The benefit to this was that the state
machine was only updated if the transmitter completed. The transmitter may
not have completed if there was lots of noise on the line resulting in the
number of retries being exceeded. But, it had the artifact that it reversed
the order of any responses received from the line during transmission. So,
instead of seeing "T E10, T E STATUS, R E STATUS=OFF" you would see "R E
STATUS=OFF, T E10, T E STATUS". This was a result of the driver being
interruptible and reentrant (as required) such that the X10 network would
transmit the response before the driver could finish the transmit function.
Version 1.6.3 changes the behavior such that the transmission is faked
before the transmit actually occurs. This results in a more accurate
representation of the internal state of the network and most importantly, an
accurate representation in the logs. As a result, if using wishweb, the
two-way devices will be correctly reported and maintained in the GUI.
One other addition to the package is a little script called "mkrpm.sh" which
is what I use to create the RPMs for distributing the pre-compiled objects.
It requires a couple of arguments manually and is a trivial script. If you
can make this little script work better, I am more than happy to accept code
changes.
Scott