USB doc changes, FHZ stopHMS/initFS20_02 by Andreas

git-svn-id: https://svn.fhem.de/fhem/trunk@747 2b470e98-0d58-463d-a4d8-8e2adae1ed80
2025-01-31 12:49:34 +00:00 · 2010-11-02 14:19:57 +00:00 · 2010-11-02 14:19:57 +00:00 · 99158e7b6f
commit 99158e7b6f
parent c5f97acb28
7 changed files with 97 additions and 20 deletions
--- 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
--- 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,
--- 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});
--- a/fhem/docs/USB.html
+++ b/fhem/docs/USB.html
@ -1,6 +1,6 @@
 <html>
  <head>
-    <title>USB compendium</title>
+    <title>USB / interference compendium</title>
  </head>
  <body>

@ -11,7 +11,7 @@ devices. This is not an issue of fhem but a problem of hardware and/or USB
 drivers.<P>

 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]).

 <H3>4. Electromagnetic interferences</H3>

-Bad shielding of cables or devices might lead to interferences with electric
-devices nearby (fridges, light switches, ...). A computer can cope with this
-problem better or worse. Changing the computer's hardware helps (confirmed,
-see [7]). If this is not feasible, use a ferrite ring (see [8] for instance)
-or two around the ends of the cable (unconfirmed).
+EMI appears to be a large issue with FHZ1x00 (for one thing, there are MANY reports
+of people mysteriously unable to pair some FHT80b, despite trying very hard).

+For many details, see <a href="#emi">Electro-magnetic interference</a> below.

 <H3>5. USB Power management</H3>

@ -124,6 +122,51 @@ an USB cable. This drives the USB to its limits and may cause all sorts of
 problems on the bus. Either do not use USB extenders (confirmed, see [10]) at all
 or put an active (self-powered) hub in the middle (unconfirmed).

+<H1>Electro-magnetic interference (EMI) compendium</H1>
+
+Bad shielding of cables or devices might lead to interferences with electric
+devices nearby (fridges, light switches, fluorescent lamps, ...).
+A computer can cope with this problem better or worse.
+Changing the computer's hardware helps (confirmed, see [7]).
+If this is not feasible, use a ferrite ring (see [8] for instance)
+or two around the ends of the FHZ cable (semi-confirmed).
+(or on other interference-inducing cables!)
+
+Confirmed, AndiM: MANY issues with interference on FHZ1300PC,
+which can be observed via drastically increased receiver LED activity
+e.g. when a nearby (1m) PC is running - despite some countermeasures.<br>
+
+Symptoms of trouble with interference:<br>
+<ul>
+ <li>Almost no successful bi-di communication (almost never <code>ack:</code>s received when sending values),
+     (re-)pairing FHT80b units was pretty much impossible, too,
+     but many <code>can-rcv: 50</code> 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??)</li>
+ <li>FS20 button reception does work directly after an <code>initFS20</code> or <code>rereadcfg</code> 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 <code>initFS20</code> does correct it (IIRC <code>initHMS</code> doesn't)
+     and (some parts of) FHT protocol reception still does work in the meantime.</li>
+</ul>
+
+Swapping the 1m USB cable with a 1.5m cable (but not overly long - this is said to be problematic as well!)
+and adding a ferrite ring (currently at the FHZ1300PC-side cable end) did do wonders,
+it completely eliminated all problems (although not sure yet which of these measures contributed by how much,
+the increase of the distance from interference-causing parts or the ferrite ring).
+
+Please also note that it is recommended to keep an FHT at least 1.5m from a FHZ, otherwise <a href="http://www.razyboard.com/system/morethread-anmeldung-fht80b-funktioniert-nicht-haforum-53111-2713680-0.html">people experienced pairing problems</a>.
+
+<H1> Misc. issues / hints </H1>
+
+<ul>
+<li>Make sure to have correct (and also unique, BTW) FHT codes, otherwise FHZ buffers may fill up due to trying to communicate with an unavailable FHT code
+(<a href="http://www.razyboard.com/system/morethread-kommunikation-fhz1000pc-zum-fht80b-haforum-53111-1988993-0.html">Kommunikation FHZ1000PC zum FHT80b</a>).</li>
+<li>Diagnosing large-scale 868 MHz band distortion: <a href="http://groups.google.com/group/fhem-users/browse_thread/thread/7e183113f6c95f2">empf&auml;nger empfangen nicht mer</a>.
+<li>Still reception / interference issues? Try updating components to use a Superhet receiver (<a href="http://www.ip-symcon.de/forum/f19/fs20-st-superhet-empfangsmodul-3580/index3.html#post29481">FS20-ST &amp; Superhet Empfangsmodul</a>)</li>
+</ul>
+
 <H2>C. Suggested reading</H2>

 [1] <A HREF="http://www.mikrocontroller.net/topic/116263">http://www.mikrocontroller.net/topic/116263</A><BR>
--- a/fhem/docs/commandref.html
+++ b/fhem/docs/commandref.html
@ -989,13 +989,14 @@ A line ending with \ will be concatenated with the next one, so long lines
  <a name="FHZset"></a>
  <b>Set </b>
  <ul>
-    <code>set FHZ &lt;variable&gt; [&lt;value&gt]</code>
+    <code>set FHZ &lt;variable&gt; [&lt;value&gt;]</code>
    <br><br>
    where <code>value</code> is one of:<br>
    <ul>
      FHTcode<br>
      initFS20<br>
      initHMS<br>
+      stopHMS<br>
      initfull<br>
      raw<br>
      reopen<br>
@ -1003,8 +1004,8 @@ A line ending with \ will be concatenated with the next one, so long lines
    </ul>
    Notes:
    <ul>
-      <li>raw is used to send out "raw" FS20/FHT messages.  See the doc
-          directory for some examples</li>
+      <li>raw is used to send out "raw" FS20/FHT messages (&quot;setters&quot; only - no query messages!).
+          See message byte streams in FHEM/00_FHZ.pm and the doc directory for some examples.</li>
      <li>In order to set the time of your FHT's, schedule this command every
      minute:<br>
 	  <code>define fhz_timer at +*00:01:00 set FHZ time</code><br>
@ -1022,7 +1023,9 @@ A line ending with \ will be concatenated with the next one, so long lines
          ceases to work completely. If all else fails, shutdown fhem, unplug
          and replug the FHZ device. Problems with FHZ may also be related to
          long USB cables or insufficient power on the USB - use a powered hub
-          to avoid such issues.</li>
+          to improve this particular part of such issues.
+          See <a href="http://www.koeniglich.de/fhem/USB.html">our USB page</a>
+          for detailed USB / electromag. interference troubleshooting.</li>
      <li><code>initfull</code> issues the initialization sequence for the FHZ
          device:<br>
          <pre>
@ -1035,6 +1038,8 @@ A line ending with \ will be concatenated with the next one, so long lines
      <li><code>reopen</code> closes and reopens the serial device port. This
          implicitly initializes the FHZ and issues the
          <code>initfull</code> command sequence.</li>
+      <li><code>stopHMS</code> probably is the inverse of <code>initHMS</code>
+          (I don't have authoritative info on what exactly it does).</li>
    </ul>
  </ul>
  <br>
--- a/fhem/docs/faq.html
+++ b/fhem/docs/faq.html
@ -70,7 +70,7 @@

 <div id="dist">
 <a href="#faq8">
-  8. The time specification of the builtin at command is not very flexible.
+  8. The time specification of the builtin <code>at</code> command is not very flexible.
  Please add day/month/weekday to it.</a>
  </div>

@ -249,11 +249,13 @@ Help me!</h4>
   with the new one.
   <ul>
     <li>Set the FHTcode: The problem with this method is that I don't know how
-     to read out the value, we just can change it with<br>
-     <code>set FHZ FHTcode &lt;hex-code&gt;</code></li>
+     to read out the value [nothing discovered yet either -AndiM],
+     we just can change it with<br>
+     <code>set FHZ FHTcode &lt;hex-code&gt;</code> (1 byte, range 1 to 99)</li>
     <li>Resync the FHT80b: Press PROG until "Sond" appears, then select "CEnt"
     with the wheel, press PROG again, Select "nA" with the wheel, press PROG
-     again.</li>
+     again. For more details, see <a href="http://www.ip-symcon.de/wiki/index.php/FHT">IP-Symcon Wiki</a> (especially Fredje's comment)
+     and <a href="http://www.contronics.de/BedAnl_Studio/homeputerStudio_web/html/hard6vl3.htm">Contronics &quot;Anmelden von Raumreglern FHT80b&quot;</a>.</li>

   </ul>
 </ul>
--- a/fhem/examples/03_fht
+++ b/fhem/examples/03_fht
@ -16,6 +16,14 @@ attr global modpath .                   # where our FHEM directory is

 define FHZ FHZ /dev/tts/USB0 # the serial port of an FHZ 1000 PC

+# Since it is said that FHZ1x00 sometimes forgets its own random-initialized
+# FHTcode (Contronics speak: "Zentralencode"; sometimes called "fhtid"),
+# it's probably a good idea to manually hard-code it.
+# Changing the value (range is 1 to 99) needs re-registration of FHT80b
+# via their "cent" menu item (instructions see FAQ).
+# set FHZ FHTcode XX
+
+
 define wz FHT 3232          # type FHT, transmitter code 3232 (default value)

 #########################