Docs updated on fhtsoftbuffer for CUL.

git-svn-id: https://fhem.svn.sourceforge.net/svnroot/fhem/trunk/fhem@712 2b470e98-0d58-463d-a4d8-8e2adae1ed80

docs/commandref.html

@@ -1097,7 +1097,7 @@ A line ending with \ will be concatenated with the next one, so long lines
         As the FHZ command buffer for FHT devices is limited (see fhtbuf),
         and commands are only sent to the FHT device every 120 seconds,
         the hardware buffer may overflow and FHT commands get lost.
-        Setting this attribute implements an "unlimited" software buffer<br>
+        Setting this attribute implements an "unlimited" software buffer.<br>
         Default is disabled (i.e. not set or set to 0).</li><br>
   </ul>
   <br>
@@ -1787,6 +1787,18 @@ A line ending with \ will be concatenated with the next one, so long lines
         the CUL. See the CUL firmware README document for details on CUL
         commands.
         </li><br>
+    <li>fhtbuf<br>
+          CUL has a message buffer for the FHT. If the buffer is full, then newly
+          issued commands will be dropped, if the attribute <a
+          href="#culfhtsoftbuffer">fhtsoftbuffer</a> is not set. Instead, a "EOB" message is issued.
+          <code>fhtbuf</code> returns the free memory in this buffer (in hex),
+          an empty buffer in the CUL is 40 (64 bytes).
+          A message occupies 3 + 2x(number of FHT commands) bytes,
+          this is the second reason why sending multiple FHT commands with one
+          <a href="#set">set</a> is a good idea. The first reason is, that
+          these FHT commands are sent at once to the FHT.
+          </li>
+</li><br>
     <li>ccconf<br>
         Read some CUL radio-chip (cc1101) registers (frequency, bandwidth, etc),
         and display them in human readable form.
@@ -1812,6 +1824,13 @@ A line ending with \ will be concatenated with the next one, so long lines
         attr CUN2 sendpool CUN1,CUN2,CUN3<br>
         attr CUN3 sendpool CUN1,CUN2,CUN3<br>
         </li><br>
+    <li><a name="culfhtsoftbuffer">fhtsoftbuffer</a><br/>
+        As the CUL command buffer for FHT devices is limited (see fhtbuf),
+        and commands are only sent to the FHT device every 120 seconds,
+        the hardware buffer may overflow and FHT commands get lost or errors
+        may occur.
+        Setting this attribute implements an "unlimited" software buffer.<br>
+        Default is disabled (i.e. not set or set to 0).</li><br>
     <li><a href="#addvaltrigger">addvaltrigger</a><br>
         Create triggers for additional device values. Right now these are RSSI
         and RAWMSG for the CUL family and RAWMSG for the FHZ.

docs/faq.html

@@ -140,10 +140,17 @@
 
 <div id="dist">
 <a href="#faq20">
-  20. Why do my Sunrise/Sunset times differ from the ones on webseite
+  20. Why do my Sunrise/Sunset times differ from the ones on website
   XXX?</a>
   </div>
 
+<div id="dist">
+<a href="#faq21">
+  21. What is "unknown message: EOB" from a CUL device?</a>
+  </div>
+
+
+
 <br/>
 <br/>
 -->
@@ -534,5 +541,18 @@ See <a href="USB.html">USB compendium</a> for help.
 
 </ul>
 
+<a name="faq21"></a>
+<h4>21. What is "unknown message: EOB" from a CUL device?</h4>
+<ul>
+  If too many messages for FHT devices are queued in CUL, the fht buffer
+  subsystem of CUL overflows. You get EOB (end of buffer) messages and
+  likely LOVF (limit overflow) messages, too. define <code>attr CUL fhtsoftbuffer 1</code>
+  to activate a quasi unlimited software buffer in fhem itself to avoid this
+  behavior.<br><br>
+
+  By the way, <code>set CUL raw T01abcd</code> (abcd= FHT house code) resets
+  the CUL FHT subsystem, no need to unplug/replug the CUL device in case of
+  the aforementioned issue.
+</ul>
 </body>
 </html>