Reading TempLinc temperature codes?

[Charles Sullivan]

Roger:
I have no problem with the reversed-bits in
the preset dim level any more than I have
with the hodge-podge encoding of the
housecode and unit codes, and that's a non-
problem.  What causes the mess is the
substitution of the dim level in the location
where a non-preset-enabled module expects to
see the housecode, so the normal module
addressing/unaddressing rules can get screwed
up if preset commands become intermixed with
other X10 addresses and functions on the
power line.

Due to the way X10 is normally used, most
people won't experience a problem, but it's
there.

[roger1818]

Charles:  That is why X10 never used the
presetdim command and replaced it with
the "extended dim" command.  Initially they
were trying to keep a consistant 9 bit
message length and considering that 4 bits
were used for the house code, 4 bits were
used for the function and 1 bit was used to
identify that it was a function and not an
address, something had to give to specify
the brigthness.

[Charles Sullivan]

Roger:
I understand that. But they left a gap that
third parties like ACT and Smarthome rushed
to fill, and now there's no going back.

[roger1818]

ACT has been using extended dim for about a
decade now.  They may have previously used
the preset dim command though (I am not
sure).

SmartHome apperently developed their
modules about 5 years after the preset dim
was labled obsolete by X10.

[jonk]

Got the templinc yesterday and have it
reporting temps per the sdk thanks to the
invaluable information provided in this
forum. The statusrequest actually fires two
recvactions. The first recvaction in vparm1
gives the house/unit code per the owners
manual (unit 11-16) and vparm2 gives the
request type. (StatusRequest in this case.)
The second recvaction returns the dim level
as house/unit code in vparm1.(the unit code
is not relevant to anything here as far as I
can tell.) vparm2 gives the presetdim1 or
presetdim2 result. After a little string
parsing and thread sleeping....voila! Thanks
again for all of the helpful info. I learned
a lot from this thread.

[roger1818]

Jon:  Thanks for the update.  I am glad you
got things working.

[jonk]

May have spoke too soon. The templinc is very
intermittently reporting both recvactions. I
am receiving the first part as I mentioned
below about 95% of the time and am only
getting the second (presetdim portion) about
1% of the time. I do notice that the status
report in activehome itself shows

d1 statusrequest
d15
statusrequest
extended data transfer

...almost always when i send the status
request. It's almost as if the sdk is not
able to receive the extended data transfer
portion. I've gone the usual x10
troubleshooting route of unplugging
everything I can think of and nothing is
helping. I went ahead and ordered two
filterlincs anyway though. Any other thoughts
would be greatly appreciated.

[roger1818]

Jon:  I have been thinking about this, and I
am not sure what the cause of your problem
is.  Let us know if you resolve it.

[jonk]

Just a quick note to say that i am still
working on this. Got the filterlinc's and
installed them to no avail. There is
something different about the way the sdk
handles the presetdim responses than the way
activehome handles them. Activehome always
responds with the "extended data transfer"
while the sdk recvaction doesn't seem to
respond to the actual extended data transfer
with any degree of reliability.

[roger1818]

Sounds like both AHP and the SDK are buggy
when it comes to receiving “Pre-set Dim”
commands.  In the original standard
(http://www.x10.com/support/technology1.htm)
the following commands were specified (among
others):

Extended Code           0111
Pre-set Dim             101x
Extended Data Transfer  1100

(x represents the Most Significant Bit of the
level)

As you can see, “Extended Data Transfer” is
unrelated to “Pre-set Dim” so neither AHP or
the SDK should report a “Pre-set Dim” command
as “Extended Data Transfer.”

FYI, in the early 90s, X10 revised the
standard
(ftp://ftp.x10.com/pub/manuals/xtc798.doc)
and the following commands were specified
instead which could explain why they aren’t
supporting “Pre-set Dim” properly:

EXTENDED CODE 1    0111 FOR DATA/CONTROL
EXTENDED CODE 3    1010 FOR SECURITY MESSAGES
UNUSED             1011
EXTENDED CODE 2    1100 FOR METER READ & DSM

[jonk]

My concern is that at least AHP is consistent
in receiving the extended data transfer
message   from the templinc and that the sdk
is so sporadic. The sdk seems to almost
always receive the first portion (j15 status
request)  of the message and rarely the
preset dim portion.
When the sdk does work, it is also
consistent for about an hour or so. Then it
just quits. It may take hours before it
starts working again. This leads me to
believe that the message is somehow
encapsulated in the extended data transfer
but that message is somehow garbled enough
that the sdk can't interpret it. Thats why i
got the filterlinc's to try and eliminate as
much powerline noise as possible.

[jonk]

BTW Here's a screenshot of the web app i have
been working
on...http://12.160.70.148/JONK/ACTHM.BMP

[jonk]

I noticed this in my event log:

12/7/2005 8:31:23 AM :recvplc b5 PresetDim1
12/7/2005 8:31:23 AM :recvplc j15 StatusRequest

Notice the times! It seems that the response
may only differ by milliseconds. It may be
that the sdk doesn't quite keep up with the
recvaction and therefore doesn't update the
eventlog in time for anything to read it.

[roger1818]

Jon:  That is very strange.  X10
communication is very slow and only one
address/function can be transmitted at a
time.  It takes 0.83 seconds for an address
and a command to be transmitted so it is
unlikely that you would receive two unrelated
commands on the same second.  One other
thing, J StatusRequest is the most probable
command to be “received” inadvertently.

I think I might know what the problem may be.
Most commands use the house code in the
function part of the command to ensure that
the function is valid.  Since PresetDim uses
the house code to set the dim level, AHP and
the SDK may be ignoring PresetDim commands
with a house code that has never been
addressed.  Try sending A16, B16, C16, D16 …
P16 (assuming none of those addresses are
used) at the beginning of your program to
make sure that every house code has been
addressed.  I hope this helps.

[jonk]

Roger: That definitely improved the receiving
of the preset dim commands. It rarely misses.
However, (there' s always a "however") now
the first portion is rarely received. i.e.
the "j15 statusrequest" part. I am getting
j16 status request most of the time which
seems to somehow be tied to addressing the
J16 that i send per your suggestion. I tried
sending j1-j16 along with the rest but that
always returns "j1 statusrequest-j16
statusrequest". I also tried omitting the j
housecode all together. Thanks for all of
your help on this. Once again you have taught
me a great deal about x10. I have a long way
to go..........