diff --git a/fhem/CHANGED b/fhem/CHANGED index 4f885d11b..31af1e45a 100644 --- a/fhem/CHANGED +++ b/fhem/CHANGED @@ -6,6 +6,7 @@ - bugfix: CUL get should not digest foreign events (fhtsoftbuffer) - bugfix: S300TH sanity check won't allow negative temperatures. - feature: decode CUL uptime + - feature: USB doc changes, FHZ initFS20_02/stopHMS parameters by Andreas. - 2010-08-15 (5.0) - **NOTE*: The default installation path is changed to satisfy lintian diff --git a/fhem/FHEM/00_FHZ.pm b/fhem/FHEM/00_FHZ.pm index 08e1f63d3..0f7e94a84 100755 --- a/fhem/FHEM/00_FHZ.pm +++ b/fhem/FHEM/00_FHZ.pm @@ -14,20 +14,36 @@ sub FHZ_CheckCrc($); sub FHZ_XmitLimitCheck($$); sub FHZ_DoInit($$$); -my $msgstart = pack('H*', "81");# Every msg starts wit this +my $msgstart = pack('H*', "81");# Every msg starts with this + +# See also "FHZ1000 Protocol" http://fhz4linux.info/tiki-index.php?page=FHZ1000%20Protocol + +# NOTE: for protocol analysis, especially the "serial" vs. "FHTcode" case +# is interestingly different yet similar: +# - code 0x84 (FHZ area) vs. 0x83 (FHT area), +# - register 0x57, _read_ vs. 0x9e, _write_ (hmm, or is this "house code" 0x9e01?) +# - _read_ 8 nibbles (4 bytes serial), _write_ 1 (1 byte FHTcode - align-corrected to two nibbles, right?) +# I did some few tests already (also scripted tests), no interesting findings so far, +# but despite that torture my 1300PC still works fine ;) my %gets = ( "init1" => "c9 02011f64", "init2" => "c9 02011f60", "init3" => "c9 02011f0a", "serial" => "04 c90184570208", - "fhtbuf" => "04 c90185", + "fhtbuf" => "04 c90185", # get free FHZ memory (e.g. 23 bytes free) + # NOTE: there probably is another command to return the number of pending + # FHT msg submissions in FHZ (including last one), IOW: 1 == "empty"; + # see thread "Kommunikation FHZ1000PC zum FHT80b" for clues; + # TODO: please analyze in case you use homeputer!! ); my %sets = ( "time" => "c9 020161", "initHMS" => "04 c90186", + "stopHMS" => "04 c90197", "initFS20" => "04 c90196", - "FHTcode" => "04 c901839e0101", + "initFS20_02" => "04 c9019602", # some alternate variant + "FHTcode" => "04 c901839e0101", # (parameter range 1-99, "Zentralencode" in contronics speak; randomly chosen - and forgotten!! - by FHZ, thus better manually hardcode it in fhem.cfg) "raw" => "xx xx", "initfull" => "xx xx", @@ -36,7 +52,9 @@ my %sets = ( my %setnrparam = ( "time" => 0, "initHMS" => 0, + "stopHMS" => 0, "initFS20" => 0, + "initFS20_02" => 0, "FHTcode" => 1, "raw" => 2, "initfull" => 0, diff --git a/fhem/FHEM/11_FHT.pm b/fhem/FHEM/11_FHT.pm index 5e2f57ba6..26b68acd5 100755 --- a/fhem/FHEM/11_FHT.pm +++ b/fhem/FHEM/11_FHT.pm @@ -595,7 +595,7 @@ doSoftBuffer($) } } - # Check if it is still in th CUL buffer. + # Check if it is still in the CUL buffer. if($io->{TYPE} eq "CUL") { my $cul = CallFn($io->{NAME}, "GetFn", $io, (" ", "raw", "T02")); my $arg = uc($h->{ARG}); diff --git a/fhem/docs/USB.html b/fhem/docs/USB.html index f5e36f9a8..4584b6840 100644 --- a/fhem/docs/USB.html +++ b/fhem/docs/USB.html @@ -1,6 +1,6 @@
-This document summarizes some findings on the issue. They are taken from -users' experience and from a web research. This compendium is written for Linux +users' experience and from a web research. This USB compendium is written for Linux users. @@ -89,12 +89,10 @@ might be a cure. It is not known how to achieve this (see [5]).
ack:
s received when sending values),
+ (re-)pairing FHT80b units was pretty much impossible, too,
+ but many can-rcv: 50
from several FHTs received while pairing was not successful
+ (hmm, perhaps this is a special ID for indication of pairing protocol issues,
+ since it's exactly half of FHTID 100??)initFS20
or rereadcfg
or other
+ reset command is executed, but as soon as the first other LED activity
+ (interference? FHT traffic?) happens, any FS20 reception whatsoever drops dead again.
+ And this specifically affects FS20 handling in FHZ1300PC,
+ since specifically initFS20
does correct it (IIRC initHMS
doesn't)
+ and (some parts of) FHT protocol reception still does work in the meantime.