diff --git a/docs/commandref.html b/docs/commandref.html
index 3068a6135..09b213b2c 100644
--- a/docs/commandref.html
+++ b/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
+ Setting this attribute implements an "unlimited" software buffer.
Default is disabled (i.e. not set or set to 0).
@@ -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.
+
fhtbuf
+ CUL has a message buffer for the FHT. If the buffer is full, then newly
+ issued commands will be dropped, if the attribute fhtsoftbuffer is not set. Instead, a "EOB" message is issued.
+ fhtbuf 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
+ set is a good idea. The first reason is, that
+ these FHT commands are sent at once to the FHT.
+
+
ccconf
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
attr CUN3 sendpool CUN1,CUN2,CUN3
+ fhtsoftbuffer
+ 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.
+ Default is disabled (i.e. not set or set to 0).
addvaltrigger
Create triggers for additional device values. Right now these are RSSI
and RAWMSG for the CUL family and RAWMSG for the FHZ.
@@ -2966,7 +2985,7 @@ Attributes:
dimup
off
on
- toggle
+ toggle
Examples:
@@ -3008,7 +3027,7 @@ Attributes:
define <name> ALL4027 <ip-address> <port> <relay_nr> <delay>
Defines an Allnet 4027 device (Box with 8 relays) connected to an ALL4000 via its ip address. The status of the device is also pooled (delay interval), because someone else is able to change the state via the webinterface of the device.
-
+
Examples:
@@ -3026,7 +3045,7 @@ Attributes:
off
on
- toggle
+ toggle
Examples:
@@ -3775,13 +3794,13 @@ audio
For testing purposes you may also use the LAN based receivers. However
the code for LAN access is still in beta stage and not fault tolerant. Therefore you should use the USB attached receiver.
- Currently one parser module (41_Oregon.pm) is implemented to parse and process messages for
+ Currently one parser module (41_Oregon.pm) is implemented to parse and process messages for
Oregon Scientific weather sensors. If you need to process other devices that are supported
by RFXCOM, you have to implement a new parsing module.
- See http://www.rfxcom.com/oregon.htm of
+ See http://www.rfxcom.com/oregon.htm of
Oregon Scientific weather sensors that could be received by the RFXCOM receivers.
Please note that not all sensors are currently implemented in the parser module right now.
- The parsing module ist based on the Perl xPL
+ The parsing module ist based on the Perl xPL
project parsing modules. Thanks to Mark Hindess from the xPL project for writing this code.
Until now the following Oregon Scientific weather sensors have been tested: BTHR918N, THGR810, THR128, THWR288A, WTGR800.
@@ -3794,7 +3813,7 @@ audio
USB-connected (80002):
<device> specifies the USB port to communicate with the RFXCOM receiver.
- Normally on Linux the device will be named /dev/ttyUSBx, where x is a number.
+ Normally on Linux the device will be named /dev/ttyUSBx, where x is a number.
For example /dev/ttyUSB0.
Example:
define RFXCOMUSB RFXCOM /dev/ttyUSB0
@@ -3806,7 +3825,7 @@ audio
192.168.1.5:10001
-
+
@@ -4590,7 +4609,7 @@ Terminating
-
+
@@ -5500,9 +5519,9 @@ isday
filenames.
You can specify a path to which the files will be
rendered. If you also specify a prefix, this will be used to build the
resulting filename.
-
+
multiprocess
- This defines if the Renderer works in a multiprocessing mode.
+ This defines if the Renderer works in a multiprocessing mode.
You can set multiprocessing either to on / off and the renderer will draw the
time-scheduled tasks either in multiprocessing mode, or not.
NOTE: Direct GET calls, except for a general GET (for all weblinks) will be renderer
diff --git a/docs/faq.html b/docs/faq.html
index 088cfe35d..de5d738d9 100644
--- a/docs/faq.html
+++ b/docs/faq.html
@@ -106,7 +106,7 @@
@@ -140,10 +140,17 @@
+
+
+
+
-->
@@ -534,5 +541,18 @@ See
USB compendium for help.
+
+
21. What is "unknown message: EOB" from a CUL device?
+
+ 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 attr CUL fhtsoftbuffer 1
+ to activate a quasi unlimited software buffer in fhem itself to avoid this
+ behavior.
+
+ By the way, set CUL raw T01abcd (abcd= FHT house code) resets
+ the CUL FHT subsystem, no need to unplug/replug the CUL device in case of
+ the aforementioned issue.
+