FHEM/fhem-mirror
2
0
Fork 0
mirror of https://github.com/fhem/fhem-mirror.git synced 2025-01-31 12:49:34 +00:00
Code Issues Releases Wiki Activity

Docs updated on fhtsoftbuffer for CUL.

Browse Source 
git-svn-id: https://svn.fhem.de/fhem/trunk@712 2b470e98-0d58-463d-a4d8-8e2adae1ed80
This commit is contained in:
borisneubert 2010-09-06 17:12:33 +00:00
parent f581862267
commit aa890479ae
2 changed files with 53 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
fhem/docs/commandref.html
View File

@ -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.

22
fhem/docs/faq.html
View File

@ -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>