mirror of
https://github.com/fhem/fhem-mirror.git
synced 2025-01-31 18:59:33 +00:00
5909 lines
190 KiB
HTML
5909 lines
190 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
|
||
<head>
|
||
<title>fhem reference</title>
|
||
<style type="text/css">
|
||
body { background-color: #FFFFE7;}
|
||
#left { position:absolute; top:20px; left:20px; width:140px; }
|
||
#right { position:absolute; top:20px; left:180px; bottom:20px; right:10px; }
|
||
body>div#left { position:fixed; }
|
||
h2,h3,h4 { color:#52865D; line-height:1.3;
|
||
margin-top:1.5em; font-family:Arial,Sans-serif; }
|
||
div#block { border:1px solid gray; background: #F8F8E0; padding:0.7em; }
|
||
div#dist { padding-top:0.3em; }
|
||
a { color: #278727; }
|
||
</style>
|
||
</head>
|
||
|
||
|
||
<body>
|
||
|
||
<div id="left">
|
||
<img src="fhem.png">
|
||
<h3>fhem.pl reference</h3>
|
||
</div>
|
||
|
||
<div id="right">
|
||
|
||
<h3>Contents</h3>
|
||
<ul>
|
||
<a href="#intro">Introduction</a><br>
|
||
<a href="#command">Fhem command types</a><br>
|
||
<a href="#devspec">Device specification</a><br>
|
||
|
||
<br>
|
||
<b>fhem commands</b>
|
||
<ul>
|
||
|
||
<a href="#attr">attr</a>
|
||
<a href="#define">define</a>
|
||
<a href="#delete">delete</a>
|
||
<a href="#deleteattr">deleteattr</a>
|
||
<a href="#get">get</a>
|
||
<a href="#getstate">getstate</a>
|
||
<a href="#help">?,help</a>
|
||
<a href="#include">include</a>
|
||
<a href="#inform">inform</a>
|
||
<a href="#list">list</a>
|
||
<a href="#modify">modify</a>
|
||
<a href="#quit">quit</a>
|
||
<a href="#reload">reload</a>
|
||
<a href="#rename">rename</a>
|
||
<a href="#rereadcfg">rereadcfg</a>
|
||
<a href="#save">save</a>
|
||
<a href="#set">set</a>
|
||
<a href="#setdefaultattr">setdefaultattr</a>
|
||
<a href="#setstate">setstate</a>
|
||
<a href="#shutdown">shutdown</a>
|
||
<a href="#sleep">sleep</a>
|
||
<a href="#trigger">trigger</a>
|
||
<a href="#xmllist">xmllist</a>
|
||
|
||
</ul>
|
||
|
||
<br>
|
||
<b>Devices</b>
|
||
<ul>
|
||
<a href="#global">global</a><br>
|
||
|
||
<a href="#ALL3076">ALL3076</a>
|
||
<a href="#ALL4000T">ALL4000T</a>
|
||
<a href="#ALL4027">ALL4027</a>
|
||
<a href="#BS">BS</a>
|
||
<a href="#CM11">CM11</a>
|
||
<a href="#CUL">CUL</a>
|
||
<a href="#CUL_EM">CUL_EM</a>
|
||
<a href="#CUL_FHTTK">CUL_FHTTK</a>
|
||
<a href="#CUL_HOERMANN">CUL_HOERMANN</a>
|
||
<a href="#CUL_RFR">CUL_RFR</a>
|
||
<a href="#CUL_WS">CUL_WS</a>
|
||
<a href="#DS18S20">DS18S20</a>
|
||
<a href="#EM">EM</a>
|
||
<a href="#EMEM">EMEM</a>
|
||
<a href="#EMGZ">EMGZ</a>
|
||
<a href="#EMWZ">EMWZ</a>
|
||
<a href="#FHT">FHT</a>
|
||
<a href="#FHT8V">FHT8V</a>
|
||
<a href="#FHZ">FHZ</a>
|
||
<a href="#FS20">FS20</a>
|
||
<a href="#HMS">HMS</a>
|
||
<a href="#IPWE">IPWE</a>
|
||
<a href="#KM271">KM271</a>
|
||
<a href="#KS300">KS300</a>
|
||
<a href="#LGTV">LGTV</a>
|
||
<a href="#LIRC">LIRC</a>
|
||
<a href="#M232">M232</a>
|
||
<a href="#M232Counter">M232Counter</a>
|
||
<a href="#M232Voltage">M232Voltage</a>
|
||
<a href="#OWFS">OWFS</a>
|
||
<a href="#OWTEMP">OWTEMP</a>
|
||
<a href="#RFXCOM">RFXCOM</a>
|
||
<a href="#SCIVT">SCIVT</a>
|
||
<a href="#SISPM">SISPM</a>
|
||
<a href="#SIS_PMS">SIS_PMS</a>
|
||
<a href="#USF1000">USF1000</a>
|
||
<a href="#USBWX">USBWX</a>
|
||
<a href="#VantagePro2">VantagePro2</a>
|
||
<a href="#WEBIO">WEBIO</a>
|
||
<a href="#WS2000">WS2000</a>
|
||
<a href="#WS300">WS300</a>
|
||
<a href="#WS3600">WS3600</a>
|
||
<a href="#Weather">Weather</a>
|
||
<a href="#X10">X10</a>
|
||
<a href="#xxLG7000">xxLG7000</a>
|
||
|
||
|
||
</ul>
|
||
|
||
<br>
|
||
<b>Helper modules</b>
|
||
<ul>
|
||
<a href="#DbLog">DbLog</a>
|
||
<a href="#FHEMRENDERER">FHEMRENDERER</a>
|
||
<a href="#FHEMWEB">FHEMWEB</a>
|
||
<a href="#FileLog">FileLog</a>
|
||
<a href="#PachLog">PachLog</a>
|
||
<a href="#PID">PID</a>
|
||
<a href="#SUNRISE_EL">SUNRISE_EL</a>
|
||
<a href="#at">at</a>
|
||
<a href="#autocreate">autocreate</a>
|
||
<a href="#dummy">dummy</a>
|
||
<a href="#dumpdef">dumpdef</a>
|
||
<a href="#holiday">holiday</a>
|
||
<a href="#notify">notify</a>
|
||
<a href="#structure">structure</a>
|
||
<a href="#watchdog">watchdog</a>
|
||
<a href="#weblink">weblink</a>
|
||
|
||
</ul>
|
||
|
||
<br>
|
||
<a href="#perl">Perl specials</a><br>
|
||
</ul>
|
||
|
||
|
||
<a name="intro"></a>
|
||
<h3>Introduction</h3>
|
||
<ul>
|
||
Fhem is mainly used for home automation, but it is suitable for other tasks
|
||
too, where notification, timers and logging plays an important role.<br>
|
||
<br>
|
||
|
||
It supports different hardware devices to interface with certain protocols
|
||
(e.g. FHZ1000 to interface FS20 and HMS, CM11 to access X10), and logical
|
||
devices like FS20 or FHT to digest the messages for a certain device type using
|
||
this protocol.<br>
|
||
<br>
|
||
|
||
Fhem is modular. The different devices are represented through modules which
|
||
implement certain functions (e.g. define, get, set). Even seemingly integral
|
||
parts of fhem like triggers (<a href="#notify">notify</a>) and timers (<a
|
||
href="#at">at</a>) are implemented this way, giving the possibility to
|
||
replace/extend this functionality.<br> <br>
|
||
|
||
Fhem is controlled through readable / ascii commands, which are specified in
|
||
files (e.g. the configuration file), or issued over a TCP/IP connection, either
|
||
directly in a telnet session, with a fhem.pl in client mode or from one of the
|
||
web frontends.<br> <br>
|
||
|
||
When starting the server you have to specify a configuration file:<br>
|
||
<ul>
|
||
<code>fhem.pl ~/.fhem</code>
|
||
</ul>
|
||
<br>
|
||
|
||
A minimal configuration file: <pre>
|
||
attr global <a href="#logfile">logfile</a> /tmp/fhem.log
|
||
attr global <a href="#statefile">statefile</a> /tmp/fhem.save
|
||
attr global <a href="#verbose">verbose</a> 3
|
||
attr global <a href="#port">port</a> 7072
|
||
attr global <a href="#modpath">modpath</a> /usr/share/fhem
|
||
<a href="#define">define</a> FHZ FHZ /dev/tts/USB0
|
||
|
||
<a href="#define">define</a> lamp FS20 8765 01</pre>
|
||
|
||
For other configuration files see the examples subdirectory.<br>
|
||
<br>
|
||
|
||
TCP/IP communication with fhem can either happen in a "session" (via
|
||
telnet) or single client command (via fhem.pl). Example:
|
||
<ul>
|
||
<code>telnet localhost 7072<br>
|
||
<NL> </code>(This newline switches into "prompt" mode)<code><br>
|
||
<command>...<br>
|
||
quit</code><br>
|
||
</ul>
|
||
or
|
||
<ul>
|
||
<code>fhem.pl 7072 "set lamp off"</code>
|
||
</ul>
|
||
</ul>
|
||
|
||
|
||
<a href="#command"></a>
|
||
<h3>Fhem command types</h3>
|
||
<ul>
|
||
There are three types of commands: "fhem" commands (described in this
|
||
document), shell commands (they must be enclosed in double quotes ") and perl
|
||
expressions (enclosed in curly brackets {}). shell commands or perl expressions
|
||
are needed for complex <a href="#at">at</a> or <a href="#notify">notify</a>
|
||
arguments, but can also issued as a "normal" command.<br>
|
||
<br>
|
||
E.g. the following three commands all do the same when issued from a telnet
|
||
prompt:<br>
|
||
<ul>
|
||
set lamp off<br>
|
||
"fhem.pl 7072 "set lamp off""<br>
|
||
{fhem("set lamp off")}<br>
|
||
</ul>
|
||
<br>
|
||
|
||
Shell commands will be executed in the background, perl expressions and
|
||
fhem commands will be executed in the main "thread". In order to make perl
|
||
expressions easier to write, some special functions and variables are
|
||
available. See the section <a href="#perl">Perl special</a> for a description.
|
||
To trigger fhem commands from a shell script (this is the "other way round"),
|
||
use the client form of fhem.pl (described above).<br>
|
||
<br>
|
||
|
||
Multiple fhem commands are separated by semicolon (;). In order to use semicolon
|
||
in perl code or shell programs, they have to be escaped by the double semicolon
|
||
(;;). See the <b>Notes</b> section of the <a href="#notify">notify</a>
|
||
chapter on command parameters and escape rules.<br>
|
||
|
||
E.g. the following first command switches Lamp1 off at 07:00 and Lamp2
|
||
immediately (at the point of definition), the second one switches both lamps
|
||
off at 07:00.<br>
|
||
<ul>
|
||
define lampoff at 07:00 set Lamp1 off; set Lamp2 off<br>
|
||
define lampoff at 07:00 set Lamp1 off;; set Lamp2 off<br>
|
||
</ul>
|
||
<br>
|
||
|
||
|
||
Commands can be either typed in plain, or read from a file (e.g. the
|
||
configuration file at startup). The commands are either executed directly, or
|
||
later if they are arguments to the <a href="#at">at</a> and <a
|
||
href="#notify">notify</a> fhem commands.<br>
|
||
<br>
|
||
|
||
A line ending with \ will be concatenated with the next one, so long lines
|
||
(e.g. multiple perl commands) can be split in multiple lines. Some web fronteds
|
||
(e.g. webpgm2) make editing of multiline commands transparent for you (i.e. there is no need for \) .<br>
|
||
<br>
|
||
</ul>
|
||
|
||
|
||
<a name="devspec"></a>
|
||
<h3>Device specification (devspec)</h3>
|
||
<ul>
|
||
The commands
|
||
<a href="#attr">attr</a>,
|
||
<a href="#deleteattr">deleteattr</a>,
|
||
<a href="#delete">delete</a>,
|
||
<a href="#get">get</a>,
|
||
<a href="#list">list</a>,
|
||
<a href="#set">set</a>,
|
||
<a href="#setstate">setstate</a>,
|
||
<a href="#trigger">trigger</a>
|
||
can take a more complex device specification as argument, which will be
|
||
expanded to a list of devices. A device specification (short devspec) can be:
|
||
<ul>
|
||
<li>a single device name. This is the most common case.</li>
|
||
<li>a list of devices, separated by comma (,)</li>
|
||
<li>a range of devices, separated by dash (-)</li>
|
||
<li>a regular expression, if the the spec contains on e of the following
|
||
characters: ^*[]$</li>
|
||
<li>an attribute of the device, followed by an equal sign (=) and then a
|
||
regexp for this attribute. As attribute you can specify either attributes
|
||
set with the attr command or one of the "internal" attributes DEF, STATE
|
||
and TYPE.</li>
|
||
</ul>
|
||
Example:
|
||
<ul>
|
||
<code>set lamp1 on</code><br>
|
||
<code>set lamp1,lamp2,lamp3 on</code><br>
|
||
<code>set lamp[1-3] on</code><br>
|
||
<code>set lamp.* on</code><br>
|
||
<code>set lamp1-lamp3 on</code><br>
|
||
<code>set lamp1-lamp3,lamp3 on</code><br>
|
||
<code>set room=kitchen off</code><br>
|
||
<code>list disabled=</code><br>
|
||
<code>list TYPE=FS20</code><br>
|
||
</ul>
|
||
Notes:
|
||
<ul>
|
||
<li>first the spec is separated by komma, then the range or the regular
|
||
expression operations are executed.</li>
|
||
<li>if there is a device which exactly corresponds to the spec, then
|
||
no special processing is done.</li>
|
||
<li>the returned list can contain the same device more than once, so
|
||
"set lamp1-lamp3,lamp3 on" switches lamp3 twice.</li>
|
||
<li>for more complex structuring demands see the <a href="#structure">
|
||
structure</a> device.
|
||
</ul>
|
||
</ul>
|
||
|
||
<a name="help"></a>
|
||
<h3>?, help</h3>
|
||
<ul>
|
||
<code>?</code><br>
|
||
<code>help</code><br>
|
||
<br>
|
||
Get a list of all commands and short description for each one
|
||
</ul>
|
||
|
||
<a name="attr"></a>
|
||
<h3>attr</h3>
|
||
<ul>
|
||
<code>attr <devspec> <attrname> [<value>] </code><br>
|
||
|
||
<br>Set an attribute for a device defined by <a href="#define">define</a>.
|
||
You can define your own attributes too to use them in other applications.
|
||
|
||
Use "attr <name> ?" to get a list of possible attributes.
|
||
See the <a href="#devspec">Device specification</a> section for details on
|
||
<devspec>.
|
||
<br><br>
|
||
|
||
Attributes used by all devices:
|
||
<ul>
|
||
<a name="comment"></a>
|
||
<li>comment<br>
|
||
Add an arbitrary comment.
|
||
|
||
<a name="room"></a>
|
||
<li>room<br>
|
||
Filter/group devices. Recognized by web-pgm2 and web-pgm3.
|
||
Devices in the room hidden will not appear in the web output.</li>
|
||
|
||
<a name="showtime"></a>
|
||
<li>showtime<br>
|
||
Used in the webfrontend pgm2 to show the time of last activity
|
||
instead of the state in the summary view. Useful e.g. for FS20 PIRI
|
||
devices.
|
||
</li>
|
||
</ul>
|
||
<br>
|
||
|
||
Device specific attributes are documented in the corresponding device section.
|
||
<br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>attr global verbose 3</code><br>
|
||
<code>attr lamp room kitchen</code><br>
|
||
<code>attr lamp loglevel 6</code><br/>
|
||
</ul>
|
||
<br>
|
||
|
||
Notes:<br>
|
||
<ul>
|
||
<li>See <a href="#deleteattr">deleteattr</a> to delete attributes.</li>
|
||
</ul>
|
||
</ul>
|
||
|
||
<a name="setdefaultattr"></a>
|
||
<h3>setdefaultattr</h3>
|
||
<ul>
|
||
<code>setdefaultattr [<attrname> [<value>]] </code><br>
|
||
|
||
<br>Add a default attribute. Each device defined from now on will receive
|
||
this attribute.<br> If no attrname is specified, then the default attribute
|
||
list will be deleted.
|
||
<br><br>
|
||
|
||
Example to set the attribute "room kitchen" and "loglevel 4" to
|
||
each of the lamps:
|
||
<ul>
|
||
<code>setdefaultattr room kitchen</code><br>
|
||
<code>setdefaultattr loglevel 4</code><br>
|
||
<code>define lamp1 FS20 1234 11</code><br>
|
||
<code>define lamp2 FS20 1234 12</code><br>
|
||
<code>define lamp3 FS20 1234 13</code><br>
|
||
<code>setdefaultattr</code><br>
|
||
</ul>
|
||
<br>
|
||
|
||
Notes:<br>
|
||
<ul>
|
||
<li>There is no way to delete a single default-attribute from the list</li>
|
||
</ul>
|
||
</ul>
|
||
|
||
|
||
|
||
<a name="define"></a>
|
||
<h3>define</h3>
|
||
<ul>
|
||
<code>define <name> <type> <type-specific></code><br>
|
||
<br>
|
||
Define a device. You need devices if you want to manipulate them (e.g.
|
||
set on/off), and the logfile is also more readable if it contains e.g.
|
||
"lamp off" instead of "Device 5673, Button 00, Code 00 (off)". <br>
|
||
Use "define <name> ?" to get a list of possible types.<br>
|
||
After definition, the global event "DEFINED" will be generated, see the
|
||
notify section for details.<br>
|
||
<br><br>
|
||
|
||
Each device takes different additional arguments at definition, see the
|
||
corresponding device section for details.<br>
|
||
<br>
|
||
</ul>
|
||
|
||
|
||
<a name="deleteattr"></a>
|
||
<h3>deleteattr</h3>
|
||
<ul>
|
||
<code>deleteattr <devspec> [<attrname>]</code> <br>
|
||
<br>
|
||
Delete either a single attribute (see the <a href="#attr">attr</a> command)
|
||
or all attributes for a device (if no <attrname> is defined).
|
||
See the <a href="#devspec">Device specification</a> section for details on
|
||
<devspec>.<br>
|
||
<br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>deleteattr lamp follow-on-for-timer</code><br>
|
||
<code>deleteattr lamp</code><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="delete"></a>
|
||
<h3>delete</h3>
|
||
<ul>
|
||
<code>delete <devspec></code> <br>
|
||
<br>
|
||
Delete something created with the <a href="#define">define</a> command.
|
||
See the <a href="#devspec">Device specification</a> section for details on
|
||
<devspec>.<br>
|
||
After deletion, the global event "DELETED" will be generated, see the notify
|
||
section for details.<br>
|
||
Examples:
|
||
<ul>
|
||
<code>delete lamp</code><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="get"></a>
|
||
<h3>get</h3>
|
||
<ul>
|
||
<code>get <devspec> <type-specific></code>
|
||
<br><br>
|
||
Ask a value directly from the device, and wait for an answer. In general, you
|
||
can get a list of possible parameters by
|
||
<ul>
|
||
<code>get <device> ?</code>
|
||
</ul>
|
||
See the <a href="#devspec">Device specification</a> section for details on
|
||
<devspec>.<br>
|
||
<br>
|
||
Each device has different get parameters, see the corresponding device
|
||
section for details.<br>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
|
||
<a name="getstate"></a>
|
||
<h3>getstate</h3>
|
||
<ul>
|
||
<code>getstate <devspec></code>
|
||
<br><br>
|
||
Output a short space seperated status for <devspec>. It is useful for
|
||
monitoring the device in e.g. Cacti.<br>
|
||
Examples:
|
||
<ul>
|
||
<pre><code> getstate lamp
|
||
state:1
|
||
|
||
getstate fl
|
||
ack:0 actuator:2 day-temp:21.5 desired-temp:22.5 [...] measured-temp:22.9 [...]
|
||
</code></pre>
|
||
</ul>
|
||
Note: to use this command copy the file contrib/getstate/99_getstate.pm into
|
||
your FHEM directory.
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
|
||
<a name="include"></a>
|
||
<h3>include</h3>
|
||
<ul>
|
||
<code>include <filename></code> <br>
|
||
<br>
|
||
Read in the file, and process every line as a fhem command. Makes
|
||
configuration files more modular and enables to reread them.
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="inform"></a>
|
||
<h3>inform</h3>
|
||
<ul>
|
||
<code>inform [on|off|timer]</code> <br>
|
||
<br>
|
||
If set to on, and a device state changes, send a notification to the current
|
||
client. This command can be used by other programs/modules to receive a
|
||
notification.<br>
|
||
The option timer prepends a timerstamp to the line. Note: this command is
|
||
a nice way to check which events are generated, to help you when creating
|
||
<a href="#notify">notify</a> or <a href="#FileLog">FileLog</a> entries.
|
||
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="list"></a>
|
||
<h3>list</h3>
|
||
<ul>
|
||
<code>list [devspec] [value]</code>
|
||
<br><br>
|
||
Output a list of all definitions, all notify settings and all at
|
||
entries. This is one of the few commands which return a string in a
|
||
normal case.
|
||
See the <a href="#devspec">Device specification</a> section for details on
|
||
<devspec>.
|
||
<br>
|
||
If value is specified, then output this property (like DEF, TYPE, etc) or
|
||
reading (actuator, measured-temp) for all devices from the devspec.
|
||
<br><br>
|
||
Example:
|
||
<pre><code> fhem> list
|
||
|
||
Type list <name> for detailed info.
|
||
|
||
Internal:
|
||
global (Internal)
|
||
|
||
FHZ:
|
||
FHZ (fhtbuf: 23)
|
||
|
||
FS20:
|
||
Btn4 (on-old-for-timer)
|
||
Roll1 (on)
|
||
Stehlampe (off)
|
||
|
||
FHT:
|
||
fl (measured-temp: 21.1 (Celsius))
|
||
|
||
KS300:
|
||
out1 (T: 2.9 H: 74 W: 2.2 R: 8.2 IR: no)
|
||
|
||
at:
|
||
at_rollup (Next: 07:00:00)
|
||
|
||
notify:
|
||
ntfy_btn4 (active)
|
||
|
||
FileLog:
|
||
avglog (active)
|
||
|
||
</code></pre>
|
||
If specifying <code>name</code>, then a detailed status for <code>name</code>
|
||
will be displayed, e.g.:
|
||
<pre><code> fhem> list fl
|
||
|
||
Internals:
|
||
CODE 5102
|
||
DEF 5102
|
||
NAME fl
|
||
NR 15
|
||
STATE measured-temp: 21.1 (Celsius)
|
||
TYPE FHT
|
||
IODev FHZ
|
||
Attributes:
|
||
room Heizung
|
||
Readings:
|
||
2006-11-02 09:45:56 actuator 19%
|
||
[...]
|
||
</code></pre>
|
||
</ul>
|
||
|
||
|
||
<a name="modify"></a>
|
||
<h3>modify</h3>
|
||
<ul>
|
||
<code>modify <name> <type-dependent-options></code>
|
||
<br><br>
|
||
|
||
Used to modify some definitions. Useful for changing some <a
|
||
href="#at">at</a> or <a href="#notify">notify</a> definitions. If specifying
|
||
one argument to an at type definition, only the time part will be changed. In
|
||
case of a notify type definition, only the regex part will be changed. All
|
||
other values (state, attributes, etc) will remain intact.
|
||
<br><br>
|
||
Example:
|
||
<ul>
|
||
<code>define lampon at 19:00 set lamp on</code><br>
|
||
<code>modify lampon *19:00</code><br>
|
||
<code>modify lampon 19:00 set lamp on-for-timer 16</code><br>
|
||
</ul>
|
||
</ul>
|
||
|
||
<a name="quit"></a>
|
||
<h3>quit</h3>
|
||
<ul>
|
||
<code>quit</code>
|
||
<br><br>
|
||
If used in a TCP/IP session, terminate the client session.<br>
|
||
If used in a script, terminate the parsing of the current script.
|
||
<br><br>
|
||
Example:
|
||
<ul>
|
||
<code>quit</code>
|
||
</ul>
|
||
</ul>
|
||
|
||
|
||
<a name="reload"></a>
|
||
<h3>reload</h3>
|
||
<ul>
|
||
<code>reload <module></code>
|
||
<br><br>
|
||
Reload the given module from the module directory. It is a convenient way to
|
||
test modules whithout restarting the program.
|
||
<br><br>
|
||
Example:
|
||
<ul>
|
||
<code>reload 99_PRIV</code>
|
||
</ul>
|
||
</ul>
|
||
|
||
<a name="rename"></a>
|
||
<h3>rename</h3>
|
||
<ul>
|
||
<code>rename <oldname> <newname></code>
|
||
<br><br>
|
||
Rename a device from the <oldname> to <newname>, together with
|
||
its attributes. The global event RENAMED will be generated, see the notify
|
||
section for details.
|
||
<br><br>
|
||
Example:
|
||
<ul>
|
||
<code>rename FHT_1234 fht.kitchen</code>
|
||
</ul>
|
||
</ul>
|
||
|
||
|
||
<a name="rereadcfg"></a>
|
||
<h3>rereadcfg</h3>
|
||
<ul>
|
||
<code>rereadcfg</code>
|
||
<br><br>
|
||
Re-read the configuration file.
|
||
Note: The statefile will be saved first, then the config file will be read
|
||
(all devices will be initialized again), and at last the statefile will be
|
||
reloaded.
|
||
<br><br>
|
||
Example:
|
||
<ul>
|
||
<code>rereadcfg</code>
|
||
</ul>
|
||
</ul>
|
||
|
||
<a name="save"></a>
|
||
<h3>save</h3>
|
||
<ul>
|
||
<code>save [<configfile>]</code>
|
||
<br><br>
|
||
Save first the <a href="#statefile">statefile</a>, then the
|
||
<a href="#configfile">configfile</a> information. If a parameter is specified,
|
||
it will be used instead the global configfile attribute.<br><br>
|
||
Notes:
|
||
<ul>
|
||
<li>save only writes out definitions and attributes, but no commands
|
||
which were previously part of the config file. Put such commands in the
|
||
<a href="#lastinclude">lastinclude</a> file.
|
||
</ul>
|
||
</ul>
|
||
|
||
|
||
<a name="set"></a>
|
||
<h3>set</h3>
|
||
<ul>
|
||
<code>set <devspec> <type-specific></code>
|
||
<br><br>
|
||
Set parameters of a device / send signals to a device. You can
|
||
get a list of possible parameters by
|
||
<ul>
|
||
<code>set <name> ?</code>
|
||
</ul>
|
||
See the <a href="#devspec">Device specification</a> section for details on
|
||
<devspec>. The set command returns only a value on error.<br>
|
||
<br>
|
||
Each device has different set parameters, see the corresponding device
|
||
section for details.<br>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
|
||
<a name="setstate"></a>
|
||
<h3>setstate</h3>
|
||
<ul>
|
||
<code>setstate <devspec> <value></code>
|
||
<br><br>
|
||
Set the "STATE" for <code><name></code> as shown in paranthesis in the
|
||
<a href="#list">list</a> command
|
||
to <code><value></code> without sending any signals to the device
|
||
itself. This command is also used in the <a href="#statefile">statefile</a>.
|
||
See the <a href="#devspec">Device specification</a> section for details on
|
||
<devspec>.
|
||
<br><br>
|
||
Examples:
|
||
<ul>
|
||
setstate lamp on
|
||
</ul>
|
||
Note:
|
||
<ul>
|
||
<li>The statefile uses another version of this command, don't be surprised.
|
||
</li>
|
||
</ul>
|
||
</ul>
|
||
|
||
|
||
<a name="shutdown"></a>
|
||
<h3>shutdown</h3>
|
||
<ul>
|
||
<code>shutdown</code>
|
||
<br><br>
|
||
Shut down the server (after saving the <a href="#statefile">state information
|
||
</a>)
|
||
<br><br>
|
||
Example:
|
||
<ul>
|
||
<code>shutdown</code>
|
||
</ul>
|
||
</ul>
|
||
|
||
|
||
<a name="trigger"></a>
|
||
<h3>trigger</h3>
|
||
<ul>
|
||
<code>trigger <devspec> <state></code>
|
||
<br><br>
|
||
Trigger a <a href="#notify">notify</a> definition.
|
||
See the <a href="#devspec">Device specification</a> section for details on
|
||
<devspec>.
|
||
|
||
<br><br>
|
||
Example:
|
||
<ul>
|
||
<code>trigger btn3 on</code>
|
||
</ul>
|
||
</ul>
|
||
|
||
<a name="sleep"></a>
|
||
<h3>sleep</h3>
|
||
<ul>
|
||
<code>sleep <sec></code>
|
||
<br><br>
|
||
Sleep for a given amount, millisecond accuracy.
|
||
<br><br>
|
||
Example:
|
||
<ul>
|
||
<code>sleep 0.5</code><br>
|
||
<code>notify btn3 set lamp toggle;;sleep 0.5;;set lamp toggle</code>
|
||
</ul>
|
||
<br>
|
||
Note: As the server is <b>not</b> multithreaded, everything is blocked for
|
||
the given amount.<br>
|
||
|
||
</ul>
|
||
|
||
|
||
<a name="xmllist"></a>
|
||
<h3>xmllist</h3>
|
||
<ul>
|
||
<code>xmllist</code>
|
||
<br><br>
|
||
Returns an XML tree of all definitions, all notify settings and all at
|
||
entries. It is not intended for human consumption.
|
||
<br><br>
|
||
Example:
|
||
<pre> fhem> xmllist
|
||
<FHZINFO>
|
||
<internal_LIST>
|
||
<internal name="global" state="internal" sets="" attrs="room configfile logfile modpath pidfilename port statefile userattr verbose version">
|
||
<INT key="DEF" value="<no definition>"/>
|
||
<INT key="NR" value="0"/>
|
||
<INT key="STATE" value="internal"/>
|
||
[...]
|
||
|
||
</pre>
|
||
</ul>
|
||
|
||
<h2>Devices</h2>
|
||
|
||
<a name="global"></a>
|
||
<h3>global</h3>
|
||
<ul>
|
||
The global device is used to set different global attributes. It will be
|
||
automatically defined, it cannot be deleted or renamed and has no set or get
|
||
parameters<br>
|
||
<br>
|
||
|
||
<b>Define</b><ul>N/A</ul><br>
|
||
|
||
<b>Set </b><ul>N/A</ul><br>
|
||
|
||
<b>Get</b><ul>N/A</ul><br>
|
||
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<a name="autoload_undefined_devices"></a>
|
||
<li>autoload_undefined_devices<br>
|
||
If set, automatically load the corresponding module when a message
|
||
of this type is received. This is used by the <a href="#autocreate">
|
||
autocreate</a> device, to automatically create a fhem device upon
|
||
receiving a corresponding message.
|
||
</li><br>
|
||
|
||
|
||
<a name="allowfrom"></a>
|
||
<li>allowfrom<br>
|
||
Comma (,) separated list of ip-addresses or hostnames. If set,
|
||
only connections from these addresses are allowed.
|
||
</li><br>
|
||
|
||
<a name="configfile"></a>
|
||
<li>configfile<br>
|
||
Contains the name of the fhem configuration file. If <a
|
||
href="#save">save</a> is called without argument, then the output will
|
||
be written to this file.
|
||
</li><br>
|
||
|
||
<a name="holiday2we"></a>
|
||
<li>holday2we<br>
|
||
If this attribute is set, then the <a href="#perl">$we</a> variable
|
||
will be true, if the value of the <a href="#holiday">holiday</a>
|
||
variable referenced by this attribute is not none.<br>
|
||
Example:<br>
|
||
<ul>
|
||
attr global holiday2we hessen
|
||
</ul>
|
||
</li><br>
|
||
|
||
<a name="lastinclude"></a>
|
||
<li>lastinclude<br>
|
||
If this attribute is set, then the last command of the generated
|
||
configfile (see the <a href="#save">save</a> command) will be<br>
|
||
include <lastinclude-value><br>
|
||
This file is needed, as the save command will write only defines and
|
||
attributes to the config file, any other commands / includes will be
|
||
lost. E.g. it makes sense to set the <a href="FHZset">FHTcode</a> in
|
||
this file.
|
||
</li><br>
|
||
|
||
<a name="logfile"></a>
|
||
<li>logfile<br>
|
||
Specify the logfile to write. You can use "-" for
|
||
stdout, in this case the server won't background itself.<br>
|
||
The logfile name can also take wildcards for easier logfile rotation,
|
||
see the <a href="#FileLog">FileLog</a> section.
|
||
</li><br>
|
||
|
||
<a name="modpath"></a>
|
||
<li>modpath<br>
|
||
Specify the path to the modules directory <code>FHEM</code>. The path
|
||
does <b>not</b> contain the directory FHEM. Upon setting the
|
||
attribute, the directory will be scanned for filenames of the form
|
||
NN_<NAME>.pm, and make them available for device definition under
|
||
<NAME>. If the first device of type <NAME> is defined, the
|
||
module will be loaded, and its function with the name
|
||
<NAME>_Initialize will be called. Exception to this rule are
|
||
modules with NN=99, these are considered to be utility modules
|
||
containing only perl helper functions, they are loaded at startup (i.e.
|
||
modpath attribute definition time).
|
||
</li><br>
|
||
|
||
<a name="mseclog"></a>
|
||
<li>mseclog<br>
|
||
If set, the timestamp in the logfile will contain a millisecond part.
|
||
</li><br>
|
||
|
||
<a name="nofork"></a>
|
||
<li>nofork<br>
|
||
If set and the logfile is not "-", do not try to background. Needed
|
||
on some Fritzbox installations.
|
||
</li><br>
|
||
|
||
<a name="pidfilename="></a>
|
||
<li>pidfilename<br>
|
||
Write the process id of the perl process to the specified file. The
|
||
server runs as a daemon, and some distributions would like to check by
|
||
the pid if we are still running. The file will be deleted upon
|
||
shutdown.
|
||
</li><br>
|
||
|
||
<a name="port"></a>
|
||
<li>port<br>
|
||
Listen on the TCP/IP port <code><number></code> for incoming
|
||
connections. To offer at least a little bit of security, the server
|
||
will only listen for connections from the localhost per default. If
|
||
there is a second value "global" then the server will listen for
|
||
non-localhost connections too.
|
||
</li><br>
|
||
|
||
<a name="statefile"></a>
|
||
<a name="statefile"></a>
|
||
<li>statefile<br>
|
||
Set the filename where the state and certain <a href="#at">at</a>
|
||
information will be saved before shutdown. If it is not specified, then
|
||
no information will be saved.
|
||
</li><br>
|
||
|
||
<a name="title"></a>
|
||
<li>title<br>
|
||
Used by the web frontend fhemweb.pl (webpgm2) as a Page title.
|
||
</li><br>
|
||
|
||
<a name="userattr"></a>
|
||
<li>userattr<br>
|
||
A space separated list which contains the names of additional
|
||
attributes. Without specifying them you will not be able to set them
|
||
(in order to prevent typos).
|
||
</li><br>
|
||
|
||
<a name="verbose"></a>
|
||
<li>verbose<br>
|
||
Set the verbosity level. Possible values:
|
||
<ul>
|
||
<li>0 - server start/stop
|
||
<li>1 - error messages or unknown packets
|
||
<li>2 - major events/alarms.
|
||
<li>3 - commands sent out will be logged.
|
||
<li>4 - you'll see whats received by the different devices.
|
||
<li>5 - debugging.</li>
|
||
</ul>
|
||
Recommended level is 3 for normal use.
|
||
</li><br>
|
||
|
||
</ul>
|
||
</ul>
|
||
|
||
|
||
|
||
<a name="FHZ"></a>
|
||
<h3>FHZ</h3>
|
||
<ul>
|
||
|
||
<a name="FHZdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> FHZ <serial-device></code> <br>
|
||
<br>
|
||
Specifies the serial port to communicate with the FHZ1000PC or FHZ1300PC.
|
||
The name(s) of the serial-device(s) depends on your distribution. <br>
|
||
|
||
If the serial-device is called none, then no device will be opened, so you
|
||
can experiment without hardware attached.<br>
|
||
|
||
The program can service multiple devices, FS20 and FHT device commands will
|
||
be sent out through the last FHZ device defined before the definition of
|
||
the FS20/FHT device. To change the association, use the IODev attribute.<br>
|
||
<br>
|
||
|
||
For GNU/Linux you may want to read our <a href="linux.html">hints for
|
||
GNU/Linux</a> about <a href="linux.html#multipledevices">multiple USB
|
||
devices</a>.<br>
|
||
|
||
<b>Note:</b>The firmware of the FHZ1x00 will drop commands if the airtime
|
||
for the last hour would exceed 1% (which corresponds roughly to 163
|
||
commands). For this purpose there is a command counter for the last hour
|
||
(see list FHZDEVICE), which triggers with "TRANSMIT LIMIT EXCEEDED" if
|
||
there were more than 163 commands in the last hour.<br><br>
|
||
|
||
If you experience problems (for verbose 4 you get a lot of "Bad CRC
|
||
message" in the log), then try to define your device as <br> <code>define
|
||
<name> FHZ <serial-device> strangetty</code><br>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="FHZset"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set FHZ <variable> [<value>]</code>
|
||
<br><br>
|
||
where <code>value</code> is one of:<br>
|
||
<ul>
|
||
FHTcode<br>
|
||
initFS20<br>
|
||
initHMS<br>
|
||
initfull<br>
|
||
raw<br>
|
||
reopen<br>
|
||
time<br>
|
||
</ul>
|
||
Notes:
|
||
<ul>
|
||
<li>raw is used to send out "raw" FS20/FHT messages. See 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>
|
||
See the <a href="#loglevel">loglevel</a> to prevent logging of
|
||
this command.
|
||
</li>
|
||
<li>FHTcode is a two digit hex number (from 00 to 63?) and sets the
|
||
central FHT code, which is used by the FHT devices. After changing
|
||
it, you <b>must</b> reprogram each FHT80b with: PROG (until Sond
|
||
appears), then select CEnt, Prog, Select nA.</li>
|
||
<li>If the FHT ceases to work for FHT devices whereas other devices
|
||
(e.g. HMS, KS300) continue to work, a<ul>
|
||
<code>set FHZ initfull</code></ul> command could help. Try<ul>
|
||
<code>set FHZ reopen</code></ul> if the FHZ
|
||
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>
|
||
<li><code>initfull</code> issues the initialization sequence for the FHZ
|
||
device:<br>
|
||
<pre>
|
||
get FHZ init2
|
||
get FHZ serial
|
||
set FHZ initHMS
|
||
set FHZ initFS20
|
||
set FHZ time
|
||
set FHZ raw 04 01010100010000</pre></li>
|
||
<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>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="FHZget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get FHZ <value></code>
|
||
<br><br>
|
||
where <code>value</code> is one of:<br>
|
||
<ul>
|
||
init1<br>
|
||
init2<br>
|
||
init3<br>
|
||
serial<br>
|
||
fhtbuf<br>
|
||
</ul>
|
||
Notes:
|
||
<ul>
|
||
<li>The mentioned codes are needed for initializing the FHZ1X00</li>
|
||
<li>The answer for a command is also displayed by <code>list FHZ</code>
|
||
</li>
|
||
<li>
|
||
The FHZ1x00PC has a message buffer for the FHT (see the FHT entry in
|
||
the <a href="#set">set</a> section). If the buffer is full, then newly
|
||
issued commands will be dropped, if the attribute <a
|
||
href="#fhtsoftbuffer">fhtsoftbuffer</a> is not set.
|
||
<code>fhtbuf</code> returns the free memory in this buffer (in hex),
|
||
an empty buffer in the FHZ1000 is 2c (42 bytes), in the FHZ1300 is 4a
|
||
(74 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>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="FHZattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<a name="do_not_notify"></a>
|
||
<li>do_not_notify<br>
|
||
Disable FileLog/notify/inform notification for a device. This affects
|
||
the received signal, the set and trigger commands.</li><br>
|
||
|
||
<li><a href="#attrdummy">dummy</a></li><br>
|
||
|
||
<li><a href="#showtime">showtime</a></li><br>
|
||
|
||
<a name="loglevel"></a>
|
||
<li>loglevel<br>
|
||
Set the device loglevel to e.g. 6 if you do not wish messages from a
|
||
given device to appear in the global logfile (FHZ/FS20/FHT). E.g. to
|
||
set the FHT time, you should schedule "set FHZ time" every minute, but
|
||
this in turn makes your logfile unreadable. These messages will not be
|
||
generated if the FHZ attribute loglevel is set to 6.</li><br>
|
||
|
||
<li><a href="#model">model</a> (fhz1000,fhz1300)</li><br>
|
||
|
||
<a name="fhtsoftbuffer"></a>
|
||
<li>fhtsoftbuffer<br/>
|
||
Can be applied to FHZ devices.<br/>
|
||
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>
|
||
Default is disabled (i.e. not set or set to 0).</li><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
|
||
|
||
<a name="FS20"></a>
|
||
<h3>FS20</h3>
|
||
<ul>
|
||
The FS20 protocol is used by a wide range of devices, which are either of
|
||
the sender/sensor category or the receiver/actuator category. The radio
|
||
(868.35 MHz) messages are either received through an <a href="#FHZ">FHZ</a>
|
||
or an <a href="#CUL">CUL</a> device, so this must be defined first.
|
||
|
||
<br><br>
|
||
|
||
<a name="FS20define"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> FS20 <housecode> <button>
|
||
[fg <fgaddr>] [lm <lmaddr>] [gm FF] </code>
|
||
<br><br>
|
||
|
||
The values of housecode, button, fg, lm, and gm can be either defined as
|
||
hexadecimal value or as ELV-like "quad-decimal" value with digits 1-4. We
|
||
will reference this ELV-like notation as ELV4 later in this document. You
|
||
may even mix both hexadecimal and ELV4 notations, because FHEM can detect
|
||
the used notation automatically by counting the digits.<br>
|
||
|
||
<ul>
|
||
<li><code><housecode></code> is a 4 digit hex or 8 digit ELV4 number,
|
||
corresponding to the housecode address.</li>
|
||
<li><code><button></code> is a 2 digit hex or 4 digit ELV4 number,
|
||
corresponding to a button of the transmitter.</li>
|
||
<li>The optional <code><fgaddr></code> specifies the function group.
|
||
It is a 2 digit hex or 4 digit ELV address. The first digit of the hex
|
||
address must be F or the first 2 digits of the ELV4 address must be
|
||
44.</li>
|
||
<li>The optional <code><lmaddr></code> specifies the local
|
||
master. It is a 2 digit hex or 4 digit ELV address. The last digit of the
|
||
hex address must be F or the last 2 digits of the ELV4 address must be
|
||
44.</li>
|
||
<li>The optional gm specifies the global master, the address must be FF if
|
||
defined as hex value or 4444 if defined as ELV4 value.</li>
|
||
</ul>
|
||
<br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define lamp FS20 7777 00 fg F1 gm F</code><br>
|
||
<code>define roll1 FS20 7777 01</code><br>
|
||
<code>define otherlamp FS20 24242424 1111 fg 4412 gm 4444</code><br>
|
||
<code>define otherroll1 FS20 24242424 1114</code>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="FS20set"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set <name> <value> [<time>]</code>
|
||
<br><br>
|
||
where <code>value</code> is one of:<br>
|
||
<pre>
|
||
dim06% dim12% dim18% dim25% dim31% dim37% dim43% dim50%
|
||
dim56% dim62% dim68% dim75% dim81% dim87% dim93% dim100%
|
||
dimdown
|
||
dimup
|
||
dimupdown
|
||
off
|
||
off-for-timer
|
||
on # dimmer: set to value before switching it off
|
||
on-for-timer # see the note
|
||
on-old-for-timer # set to previous (before switching it on)
|
||
ramp-on-time # time to reach the desired dim value on dimmers
|
||
ramp-off-time # time to reach the off state on dimmers
|
||
reset
|
||
sendstate
|
||
timer
|
||
toggle # between off and previous dim val
|
||
on-till # Special, see the note
|
||
</pre>
|
||
Examples:
|
||
<ul>
|
||
<code>set lamp on</code><br>
|
||
<code>set lamp1,lamp2,lamp3 on</code><br>
|
||
<code>set lamp1-lamp3 on</code><br>
|
||
<code>set lamp on-for-timer 12</code><br>
|
||
</ul>
|
||
<br>
|
||
Notes:
|
||
<ul>
|
||
<li>Use reset with care: the device forgets even the housecode.
|
||
</li>
|
||
<li>As the FS20 protocol needs about 0.22 seconds to transmit a
|
||
sequence, a pause of 0.22 seconds is inserted after each command.
|
||
</li>
|
||
<li>The FS20ST switches on for dim*%, dimup. It does not respond to
|
||
sendstate.</li>
|
||
<li>If the timer is set (i.e. it is not 0) then on, dim*,
|
||
and *-for-timer will take it into account (at least by the FS20ST).
|
||
</li>
|
||
<li>The <code>time</code> argument ranges from 0.25sec to 4 hours and
|
||
16 minutes.
|
||
As the time is encoded in one byte there are only 112 distinct
|
||
values, the resolution gets coarse with larger values. The program
|
||
will report the used timeout if the specified one cannot be set
|
||
exactly. The resolution is 0.25 sec from 0 to 4 sec, 0.5 sec from 4
|
||
to 8 sec, 1 sec from 8 to 16 sec and so on. If you need better
|
||
precision for large values, use <a href="#at">at</a> which has a 1
|
||
sec resolution.</li>
|
||
<li>If the attribute follow-on-for-timer is set for the device and the
|
||
on-for-timer command is sent to the device with a time parameter,
|
||
the program automatically schedules a "setstate off" for the
|
||
specified time.</li>
|
||
<li>on-till requires an absolute time in the "at" format (HH:MM:SS, HH:MM
|
||
or { <perl code> }, where the perl-code returns a time
|
||
specification).
|
||
If the current time is greater than the specified time, then the
|
||
command is ignored, else an "on" command is generated, and for the
|
||
given "till-time" an off command is scheduleld via the at command.
|
||
</li>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="FS20attr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<a name="IODev"></a>
|
||
<li>IODev<br>
|
||
Set the IO or physical device which should be used for sending signals
|
||
for this "logical" device. An example for the physical device is an FHZ
|
||
or a CUL. Note: Upon startup fhem assigns each logical device
|
||
(FS20/HMS/KS300/etc) the last physical device which can receive data
|
||
for this type of device. The attribute IODev needs to be used only if
|
||
you attached more than one physical device capable of receiving signals
|
||
for this logical device.</li><br>
|
||
|
||
<li><a href="#do_not_notify">do_not_notify</a></li><br>
|
||
<a name="attrdummy"></a>
|
||
<li>dummy<br>
|
||
Set the device attribute dummy to define devices which should not
|
||
output any radio signals. Associated notifys will be executed if
|
||
the signal is received. Used e.g. to react to a code from a sender, but
|
||
it will not emit radio signal if triggered in the web frontend.
|
||
</li><br>
|
||
|
||
<a name="follow-on-for-timer"></a>
|
||
<li>follow-on-for-timer<br>
|
||
the program automatically schedules a "setstate off" for the time
|
||
specified as argument to the on-for-timer command (for the specified
|
||
device only).
|
||
</li><br>
|
||
|
||
<li><a href="#loglevel">loglevel</a></li><br>
|
||
|
||
<li><a href="#showtime">showtime</a></li><br>
|
||
|
||
<a name="model"></a>
|
||
<li>model<br>
|
||
The model attribute denotes the model type of the device.
|
||
The attributes will (currently) not be used by the fhem.pl directly.
|
||
It can be used by e.g. external programs or web interfaces to
|
||
distinguish classes of devices and send the appropriate commands
|
||
(e.g. "on" or "off" to a fs20st, "dim..%" to fs20du etc.).
|
||
The spelling of the model names are as quoted on the printed
|
||
documentation which comes which each device. This name is used
|
||
without blanks in all lower-case letters. Valid characters should be
|
||
<code>a-z 0-9</code> and <code>-</code> (dash),
|
||
other characters should be ommited. Here is a list of "official"
|
||
devices:<br><br>
|
||
<b>Sender/Sensor</b>: fs20hgs fs20ls fs20pira fs20piri fs20s20 fs20s8
|
||
fs20s4 fs20s4a fs20s4m fs20s4u fs20s4ub fs20sd fs20sn fs20sr fs20ss
|
||
fs20str fs20tfk fs20tk fs20uts fs20ze<br><br>
|
||
|
||
<b>Receiver/Actor</b>: fs20as1 fs20as4 fs20di fs20du fs20ms2
|
||
fs20rst fs20sa fs20sig fs20st fs20sv fs20sv fs20usr
|
||
</li><br>
|
||
|
||
|
||
<a name="ignore"></a>
|
||
<li>ignore<br>
|
||
Ignore this device, e.g. if it belongs to your neighbour. The device
|
||
won't trigger any FileLogs/notifys, issued commands will silently
|
||
ignored (no RF signal will be sent out, just like for the <a
|
||
href="#attrdummy">dummy</a> attribute). The device won't appear in the
|
||
list command (only if it is explicitely asked for it), nor will it
|
||
appear in commands which use some wildcard/attribute as name specifiers
|
||
(see <a href="#devspec">devspec</a>). You still get them with the
|
||
"ignored=1" special devspec. </li>
|
||
|
||
</ul>
|
||
</ul>
|
||
|
||
<a name="FHT"></a>
|
||
<h3>FHT</h3>
|
||
<ul>
|
||
Fhem can receive FHT radio (868.35 MHz) messages either through an <a
|
||
href="#FHZ">FHZ</a> or an <a href="#CUL">CUL</a> device, so this must be
|
||
defined first.<br><br>
|
||
|
||
<a name="FHTdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> FHT <housecode></code>
|
||
<br><br>
|
||
|
||
<code><housecode></code> is a four digit hex number,
|
||
corresponding to the address of the FHT80b device.
|
||
<br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define wz FHT 3232</code><br>
|
||
</ul>
|
||
<br>
|
||
See the FHT section in <a href="#set">set</a> for more.
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="FHTset"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set <name> <valuetype> <value></code>
|
||
<br><br>
|
||
where <code>value</code> is one of:<br>
|
||
<pre>
|
||
desired-temp
|
||
day-temp night-temp
|
||
report1 report2
|
||
mode
|
||
holiday1 holiday2 # Not verified
|
||
manu-temp # No clue what it does.
|
||
year month day hour minute
|
||
lowtemp-offset # Alarm-Temp.-Differenz
|
||
windowopen-temp
|
||
mon-from1 mon-to1 mon-from2 mon-to2
|
||
tue-from1 tue-to1 tue-from2 tue-to2
|
||
wed-from1 wed-to1 wed-from2 wed-to2
|
||
thu-from1 thu-to1 thu-from2 thu-to2
|
||
fri-from1 fri-to1 fri-from2 fri-to2
|
||
sat-from1 sat-to1 sat-from2 sat-to2
|
||
sun-from1 sun-to1 sun-from2 sun-to2
|
||
</pre>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>set wz desired-temp 22.5</code><br>
|
||
<code>set fl desired-temp 20.5 day-temp 19.0 night-temp 16.0</code><br>
|
||
</ul>
|
||
<br>
|
||
|
||
Notes:
|
||
<ul>
|
||
<li>Following events are reported (more or less regularly) by each FHT
|
||
device: <code>measured-temp actuator actuator1...actuator8
|
||
warnings</code><br>
|
||
You can use these strings for <a href="#notify">notify</a> or
|
||
<a href="#FileLog">FileLog</a> definitions.
|
||
<ul>
|
||
<li>warnings can contain following strings:
|
||
none, Battery low,Temperature too low, Window open,
|
||
Fault on window sensor
|
||
</li>
|
||
<li>actuator (without a suffix) stands for all actuators.
|
||
<li>actuator or actuator1..8 can take following values:
|
||
<ul>
|
||
<li><value>%<br>
|
||
This is the normal case, the actuator is instructed to
|
||
open to this value.
|
||
<li>offset <value>%<br>
|
||
The actuator is running with this offset.
|
||
<li>lime-protection<br>
|
||
The actuator was instructed to execute the lime-protection
|
||
procedure.
|
||
<li>synctime<br>
|
||
If you select Sond/Sync on the FHT80B, you'll see a count
|
||
down.
|
||
<li>test<br>
|
||
The actuator was instructed by the FHT80b to emit a beep.
|
||
<li>pair<br>
|
||
The the FHT80b sent a "you-belong-to-me" to this actuator.
|
||
</ul>
|
||
Note:
|
||
</ul>
|
||
<br>
|
||
|
||
<li>The FHT is very economical (or lazy), it accepts one message from the
|
||
FHZ1x00 every 115+x seconds, where x depends on the housecode. Don't
|
||
be surprized if your command is only accepted 10 minutes later by the
|
||
device. FHT commands are buffered in the FHZ1x00/CUL till they are
|
||
sent to the FHT, see the related <code>fhtbuf</code> entry in the
|
||
<code><a href="#get">get</a></code> section.<br> You can send up to 8
|
||
commands in one message at once to the FHT if you specify them all as
|
||
arguments to the same set command, see the example above.<br><br>
|
||
|
||
<li>All <code>*-temp</code> values need a temperature
|
||
as argument, which will be rounded to 0.5 Celsius.<br/>
|
||
Temperature values must between 5.5 and 30.5 Celsius. Value 5.5 sets
|
||
the actuator to OFF, value 30.5 set the actuator to ON<br><br>
|
||
|
||
<li><code>mode</code> is one of <code>auto, manual, holiday or
|
||
holiday_short.</code><br>
|
||
If the mode is holiday, then
|
||
<ul>
|
||
<li>holiday1 sets the end-day of the holiday</li>
|
||
<li>holiday2 sets the end-month of the holiday</li>
|
||
</ul>
|
||
For holiday_short
|
||
<ul>
|
||
<li>holiday1 sets the time, in 10-minute steps</li>
|
||
<li>holiday2 sets number of days from now on.</li>
|
||
</ul>
|
||
<br>
|
||
|
||
<li>The <code>*-from1/*-from2/*-to1/*-to2</code> valuetypes need a time
|
||
spec as argument in the HH:MM format. They define the periods, where
|
||
the day-temp is valid. The minute (MM) will be rounded to 10, and
|
||
24:00 means off.
|
||
<br><br>
|
||
|
||
<li>As the FHT stops sending the values every 5-10
|
||
days, it is adviseable to schedule following command regularly:<br>
|
||
<code>define fht_report at +*06:00:00
|
||
set <name> report1 255 report2 255</code>
|
||
<br><br>
|
||
|
||
<li><code>report1</code> with parameter 255 requests all settings for
|
||
monday till sunday to be sent. The argument is a bitfield, to request
|
||
unique values add up the following:
|
||
<ul>
|
||
<li> 1: monday
|
||
<li> 2: tuesday
|
||
<li> 4: thursday
|
||
<li> 8: wednesday
|
||
<li>16: friday
|
||
<li>32: saturday
|
||
<li>64: sunday
|
||
</ul>
|
||
measured-temp and actuator is sent along if it is considered
|
||
appropriate
|
||
by the FHT.
|
||
<br><br>
|
||
|
||
<li><code>report2</code> with parameter 255 requests the following
|
||
settings to be reported: day-temp night-temp windowopen-temp
|
||
lowtemp-offset desired-temp measured-temp mode warnings.
|
||
The argument is (more or less) a bitfield, to request unique values
|
||
add up the following:
|
||
<ul>
|
||
<li> 1: warnings
|
||
<li> 2: mode
|
||
<li> 4: day-temp, night-temp, windowopen-temp
|
||
<li>64: lowtemp-offset
|
||
</ul>
|
||
measured-temp and actuator is sent along if it is considered
|
||
appropriate
|
||
|
||
by the FHT.
|
||
<br><br>
|
||
|
||
<li><code>lowtemp-offset</code> needs a temperature as argument, valid
|
||
values must be between 1.0 and 5.0 Celsius.<br/> It will trigger a
|
||
warning if <code>desired-temp - measured-temp >
|
||
lowtemp-offset</code> in a room for at least 1.5 hours after the last
|
||
desired-temp change. <br><br>
|
||
|
||
<li>FHEM optionally has an internal software buffer for FHT devices.
|
||
This buffer should prevent transmission errors. If there is no
|
||
confirmation for a given period, FHEM resends the command. You can
|
||
see the queued commands with <a href="#list">list</a>
|
||
<fht-device>.
|
||
See the <a href="#fhtsoftbuffer">fhtsoftbuffer</a>,
|
||
<a href="#retrycount">retrycount</a> and
|
||
<a href="#minfhtbuffer">minfhtbuffer</a> attributes for details.
|
||
<br><br>
|
||
|
||
<li>If a buffer is still in the softbuffer, it will be sent in the
|
||
following order:<br/> <code>desired-temp,mode,report1,report2,
|
||
holiday1,holiday2,day-temp,night-temp, [all other commands]</code>
|
||
<br><br>
|
||
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="FHTattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#ignore">ignore</a></li><br>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li><br>
|
||
<li><a href="#attrdummy">dummy</a><br>
|
||
<b>Note:</b>It makes sense to define an FHT device even for an FHT8b,
|
||
else you will receive "unknown FHT device, please define one" message
|
||
for each FHT8b as the CUL is reporting the 8b valve messages. But you
|
||
should set the dummy attribute for these devices, else the internal FHT
|
||
buffer of the CUL will be filled with data for the 8b's which is never
|
||
consumed. If the buffer is full, you'll get "EOB" messages from the CUL,
|
||
and you cannot transmit any data to the 80b's</li><br>
|
||
|
||
<li><a href="#loglevel">loglevel</a></li><br>
|
||
<li><a href="#model">model</a> (fht80b)</li><br>
|
||
<li><a href="#showtime">showtime</a></li><br>
|
||
<li><a href="#IODev">IODev</a></li><br>
|
||
|
||
<a name="retrycount"></a>
|
||
<li>retrycount<br/>
|
||
If the <a href="#fhtsoftbuffer">fhtsoftbuffer</a> attribute is set, then
|
||
resend commands <code>retrycount</code> times if after 240 seconds
|
||
no confirmation message is received from the corresponding FHT
|
||
device.<br>
|
||
Default is 3.</li><br>
|
||
|
||
<a name="minfhtbuffer"></a>
|
||
<li>minfhtbuffer<br/>
|
||
FHEM won't send commands to the FHZ if its fhtbuffer is below
|
||
this value, default is 0. If this value is low, then the ordering of
|
||
fht commands (see the note in the FHT section of <a href="#set">set</a>)
|
||
has little effect, as only commands in the softbuffer can be
|
||
prioritized. The maximum value should be 7 below the hardware maximum
|
||
(see fhtbuf).
|
||
</li><br>
|
||
|
||
<a name="lazy"></a>
|
||
<li>lazy<br/>
|
||
If the lazy attribute is set, FHEM won't send commands to the FHT if
|
||
the current reading and the value to be set are already identical. This
|
||
may help avoiding conflicts with the max-1%-time-on-air rule in large
|
||
installations. Not set per default.
|
||
</li><br>
|
||
|
||
<a name="tmpcorr"></a>
|
||
<li>tmpcorr<br/>
|
||
Correct the temperature reported by the FHT by the value specified.
|
||
Note: only the measured-temp value reported by fhem (used for logging)
|
||
will be modified.
|
||
</li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="FHT8V"></a>
|
||
<h3>FHT8V</h3>
|
||
<ul>
|
||
Fhem can directly control FHT8V type valves via a <a href="#CUL">CUL</a>
|
||
device without an intermediate FHT. This paragraph documents one of the
|
||
building blocks, the other is the <a href="#PID">PID</a> device.
|
||
<br>
|
||
<br>
|
||
|
||
<a name="FHT8Vdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> FHT <housecode> [IODev]</code>
|
||
<br><br>
|
||
|
||
<code><housecode></code> is a four digit hex number,
|
||
and must have the following relation to the housecode of the corresponding CUL
|
||
device:
|
||
<ul>given the CUL housecode as AABB, then this housecode must be
|
||
of the form CCBB, where CC is greater or equal to AA, but less then AA+8.
|
||
</ul>
|
||
This form is chosen so that the CUL can update all FHT8V valve states
|
||
within 2 minutes.
|
||
<br>
|
||
<br>
|
||
<code><IODev></code> must be specified if the last defined CUL device
|
||
is not the one to use. Usually this is done voa the <a
|
||
href="#IODev">IODev</a> attribute, but as the address checked is performed
|
||
at the definition, we must use an exception here.
|
||
<br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define wz FHT8V 3232</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="FHT8Vset"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<li>set <name> valve <value;><br>
|
||
Set the valve to the given value (in percent, from 0 to 100).
|
||
</li>
|
||
<li>set <name> pair<br>
|
||
Pair the valve with the CUL.
|
||
</li>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="FHT8Vget"></a>
|
||
<b>Get </b>
|
||
<ul>
|
||
<li>get <name> valve<br>
|
||
Read back the valve position from the CUL FHT buffer, and convert it to percent (from 0 to 100).
|
||
</li>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="FHT8Vattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#IODev">IODev</a></li>
|
||
<li><a href="#dummy">loglevel</a></li>
|
||
<li><a href="#ignore">ignore</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
|
||
<a name="PID"></a>
|
||
<h3>PID</h3>
|
||
<ul>
|
||
The PID device is a loop controller, used to set the value e.g of a heating
|
||
valve dependent of the current and desired temperature.
|
||
<br>
|
||
<br>
|
||
|
||
<a name="FHT8Vdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> PID sensor[:reading:regexp] actor[:cmd:min:max] [p i d]</code>
|
||
<br><br>
|
||
|
||
<code>sensor[:reading:regexp]</code> specifies the sensor, which is an
|
||
already defined fhem device, e.g. a S300TH temperature sensor. The reading
|
||
and regexp fields are necessary only for unknown devices (currently <a
|
||
href="#CUL_WS">CUL_WS</a> and <a href="#HMS">HMS</a> devices are "known").
|
||
Reading specifies the READINGS field of the sensor, and the regexp extracts
|
||
the number from this field. E.g. for the complete definition for a CUL_WS
|
||
device is: <code>s300th_dev:temperature:([\d\.]*)</code>
|
||
<br><br>
|
||
|
||
<code>actor[:cmd:min:max]</code> specifies the actor, which is an
|
||
already defined fhem device, e.g. an FHT8V valve. The cmd, min and max
|
||
fields are necessary only for unknown devices (currently <a
|
||
href="#FHT8V">FHT8V</a> is "known"). cmd specifies the command name for the
|
||
actor, min the minimum value and max the maximum value. The complete
|
||
definition for an FHT8V device is:<code>fht8v_dev:valve:0:100</code>
|
||
<br><br>
|
||
|
||
p, i and d are the parameters use to controlling, see also the <a
|
||
href="http://de.wikipedia.org/wiki/Regler">this</a> wikipedia entry.
|
||
The default values are around 25.5, 3 and 5.88, you probably need to tune
|
||
these values. They can be also changed later.
|
||
<br><br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define wz_pid PID wz_th wz_fht8v</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="PIDset"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<li>set <name> factors p i d<br>
|
||
Set the p, i and d factors, as described above.
|
||
</li>
|
||
<li>set <name> desired <value><br>
|
||
Set the desired value (e.g. temperature). Note: until this value is not
|
||
set, no command is issued.
|
||
</li>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="FHT8Vget"></a>
|
||
<b>Get </b>
|
||
<ul>
|
||
N/A
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="FHT8Vattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#disable">disable</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
|
||
|
||
<a name="CUL_FHTTK"></a>
|
||
<h3>CUL_FHTTK</h3>
|
||
<ul>
|
||
This module handles messages from the FHT80 TF "Fenster-T<>r-Kontakt" (Window-Door-Contact)
|
||
which are normally only acted upon by the <a href="#FHT">FHT80B</a>. With this module,
|
||
FHT80 TFs are in a limited way (see <a href="http://fhz4linux.info/tiki-index.php?page=FHT+protocol">Wiki</a>
|
||
for detailed explanation of TF's mode of operation) usable similar to HMS100 TFK. The name
|
||
of the module was chosen as a) only CUL will spill out the datagrams and b) "TF" designates
|
||
usually temperature+humidity sensors (no clue, why ELV didn't label this one "TFK" like with
|
||
FS20 and HMS).<br><br>
|
||
As said before, FHEM can receive FHT80 TF radio (868.35 MHz) messages only through an
|
||
<a href="#CUL">CUL</a> device, so this must be defined first.<br><br>
|
||
|
||
<a name="CUL_FHTTKdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> CUL_FHTTK <devicecode></code>
|
||
<br><br>
|
||
|
||
<code><devicecode></code> is a six digit hex number, given to the FHT80 TF during
|
||
production, i. e. it is not changeable. (Yes, it keeps this code after changing batteries
|
||
as well.)<br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define TK_TEST CUL_FHTTK 965AB0</code>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="CUL_FHTTKset"></a>
|
||
<b>Set </b>
|
||
<ul> Nothing to set here yet ... </ul>
|
||
<br>
|
||
|
||
<b>Get</b>
|
||
<ul> No get implemented yet ...
|
||
</ul><br>
|
||
|
||
<a name="CUL_FHTTKattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li><br>
|
||
<li><a href="#loglevel">loglevel</a></li><br>
|
||
<li><a href="#model">model</a> (FHT80TF)</li><br>
|
||
<li><a href="#showtime">showtime</a></li><br>
|
||
<li><a href="#IODev">IODev</a></li><br>
|
||
<li><a href="#ignore">ignore</a></li><br>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
|
||
<a name="HMS"></a>
|
||
<h3>HMS</h3>
|
||
<ul>
|
||
<a name="HMSdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> HMS <housecode></code>
|
||
<br><br>
|
||
|
||
<code><housecode></code> is a four digit hex number,
|
||
corresponding to the address of the HMS device.
|
||
<br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define temp HMS 1234</code><br>
|
||
</ul>
|
||
Notes:<br>
|
||
<ul>
|
||
<li>There is _NO_ guarantee that the code will work as expected in all
|
||
circumstances, the authors are not liable for any damage occuring as a
|
||
result of incomplete or buggy code</li>
|
||
|
||
<li>Currently supported devices are the HMS100-T HMS100-TF HMS100-WD
|
||
HMS100-MG HMS100-TFK HMS100-CO HMS100-FIT RM100-2 RM100-3</li>
|
||
|
||
<li>The housecode of the HMS devices may change if the battery is renewed.
|
||
In order to make life easier, you can define a "wildcard" device for each
|
||
type of HMS device. First the real device-id will be checked, then the
|
||
wildcard device id. The wildcards are:
|
||
<ul>
|
||
<li>1000 for the HMS100-TF</li>
|
||
<li>1001 for the HMS100-T</li>
|
||
<li>1002 for the HMS100-WD</li>
|
||
<li>1003 for the RM100-2</li>
|
||
<li>1004 for the HMS100-TFK/li>
|
||
<li>1006 for the HMS100-MG</li>
|
||
<li>1008 for the HMS100-CO</li>
|
||
<li>100e for the HMS100-FIT</li>
|
||
</ul>
|
||
</li>
|
||
|
||
<li>Some battery low notifications are not yet implemented (RM100,
|
||
HMS100WD).</li>
|
||
<li>Please test your installation before relying on the
|
||
functionality.</li>
|
||
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="HMSset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="HMSget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="HMSattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#ignore">ignore</a></li><br>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li><br>
|
||
<li><a href="#loglevel">loglevel</a></li><br>
|
||
<li><a href="#showtime">showtime</a></li><br>
|
||
<li><a href="#IODev">IODev</a></li><br>
|
||
<li><a href="#model">model</a> (hms100-t hms100-tf hms100-wd hms100-mg
|
||
hms100-co hms100-tfk hms100-fit rm100-2)</li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="CUL"></a>
|
||
<h3>CUL</h3>
|
||
<ul>
|
||
|
||
<table>
|
||
<tr><td>
|
||
The CUL/CUR/CUN is a family of RF devices sold by <a
|
||
href="http://www.busware.de">busware.de</a>.
|
||
|
||
With the opensource firmware (see this <a
|
||
href="http://www.koeniglich.de/culfw/culfw.html">link</a>) they are capable
|
||
to receive and send different 868MHz protocols (FS20/FHT/S300/EM/HMS).
|
||
It is even possible to use these devices as range extenders/routers, see the
|
||
<a href="#CUL_RFR">CUL_RFR</a> module for details.
|
||
<br>
|
||
|
||
<br>
|
||
Some protocols (FS20, FHT and KS300) are converted by this module so that
|
||
the same logical device can be used, irrespective if the radio telegram is
|
||
received by a CUL or an FHZ device.<br> Other protocols (S300/EM) need their
|
||
own modules. E.g. S300 devices are processed by the CUL_WS module if the
|
||
signals are received by the CUL, similarly EMWZ/EMGZ/EMEM is handled by the
|
||
CUL_EM module.<br>
|
||
|
||
<br>
|
||
It is possible to attach more than one device in order to get better
|
||
reception, fhem will filter out duplicate messages.<br><br>
|
||
|
||
</td><td>
|
||
<img src="ccc.jpg"/>
|
||
</td></tr>
|
||
</table>
|
||
|
||
<a name="CULdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> CUL <device> <housecode></code> <br>
|
||
<br>
|
||
USB-connected devices (CUL/CUR/CUN):<br><ul>
|
||
<device> specifies the serial port to communicate with the CUL or
|
||
CUR. The name of the serial-device depends on your distribution, under
|
||
linux the cdc_acm kernel module is responsible, and usually a
|
||
/dev/ttyACM0 device will be created. If your distribution does not have a
|
||
cdc_acm module, you can force usbserial to handle the CUL by the
|
||
following command:<ul>modprobe usbserial vendor=0x03eb
|
||
product=0x204b</ul>In this case the device is most probably
|
||
/dev/ttyUSB0.<br><br>
|
||
You can also specify a baudrate if the device name contains the @
|
||
character, e.g.: /dev/ttyACM0@38400<br><br>
|
||
</ul>
|
||
Network-connected devices (CUN):<br><ul>
|
||
<device> specifies the host:port of the device. E.g.
|
||
192.168.0.244:2323
|
||
</ul>
|
||
<br>
|
||
If the device is called none, then no device will be opened, so you
|
||
can experiment without hardware attached.<br>
|
||
|
||
The housecode is a 4 digit hex number, and it is used when the CUL/CUR
|
||
talks to FHT devices or when CUR requests data.
|
||
</ul>
|
||
<br>
|
||
<a name="CULset"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<li>verbose<br>
|
||
Set a CUL "verbose" level. See the CUL firmware README document for
|
||
details. Note: only X00/X01/X21/X25 is supported by the fhem CUL
|
||
module, the other flags may crash fhem.
|
||
</li><br>
|
||
<li>raw<br>
|
||
Issue a CUL firmware command. See the CUL firmware README document for
|
||
details on CUL commands.
|
||
</li><br>
|
||
<li>freq / bWidth / rAmpl / sens<br>
|
||
Set the CUL frequency / bandwidth / receiver-amplitude / sensitivity.
|
||
Use it with care, it may destroy your hardware and it even may be
|
||
illegal to do so. Note: the parameters used for RFR transmission are
|
||
not affected.<br>
|
||
<ul>
|
||
<li>freq sets both the reception and transmission frequency. Note:
|
||
although the CC1101 can be set to frequencies between 315 and 915
|
||
MHz, the antenna interface and the antenna of the CUL is tuned for
|
||
exactly one frequency. Default is 868.3MHz (or 433MHz)
|
||
<li>bWidth can be set to values between 58kHz and 812kHz. Large values
|
||
are susceptible to interference, but make possible to receive
|
||
inaccurate or multiple transmitters. It affects tranmission too.
|
||
Default is 325kHz.
|
||
<li>rAmpl is receiver amplification, with values between 24 and 42 dB.
|
||
Bigger values allow reception of weak signals. Default is 42.
|
||
<li>sens is the decision boundery between the on and off values, and it
|
||
is 4, 8, 12 or 16 dB. Smaller values allow reception of less clear
|
||
signals. Default is 4dB.
|
||
</ul>
|
||
</li><br>
|
||
<li>led<br>
|
||
Set the CUL led off (00), on (01) or blinking (02).
|
||
</li><br>
|
||
</ul>
|
||
|
||
<a name="CULget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<li>version<br>
|
||
return the CUL firmware version
|
||
</li><br>
|
||
<li>uptime<br>
|
||
return the CUL uptime (time since CUL reset).
|
||
<li>raw<br>
|
||
Issue a CUL firmware command, and wait for one line of data returned by
|
||
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.
|
||
</li><br>
|
||
</ul>
|
||
|
||
<a name="CULattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li><br>
|
||
<li><a href="#attrdummy">dummy</a></li><br>
|
||
<li><a href="#showtime">showtime</a></li><br>
|
||
<li><a href="#loglevel">loglevel</a></li><br>
|
||
<li><a href="#model">model</a> (CUL,CUN,CUR)</li><br>
|
||
<li><a href="#sendpool">sendpool</a><br>
|
||
If using more than one CUL/CUN for covering a large area, sending
|
||
different events by the different CUL's might disturb each other. This
|
||
phenomenon is also known as the Palm-Beach-Resort effect.
|
||
Putting them in a common sendpool will serialize sending the events.
|
||
E.g. if you have three CUN's, you have to specify following
|
||
attributes:<br>
|
||
attr CUN1 sendpool CUN1,CUN2,CUN3<br>
|
||
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.
|
||
</li><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="CUL_WS"></a>
|
||
<h3>CUL_WS</h3>
|
||
<ul>
|
||
The CUL_WS module interprets S300 type of messages received by the CUL.
|
||
<br><br>
|
||
|
||
<a name="CUL_WSdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> CUL_WS <code> [corr1...corr4]</code> <br>
|
||
<br>
|
||
<code> is the code which must be set on the S300 device. Valid values
|
||
are 1 through 8.<br>
|
||
corr1..corr4 are up to 4 numerical correction factors, which will be added
|
||
to the respective value to calibrate the device. Note: rain-values will be
|
||
multiplied and not added to the correction factor.
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="CUL_WSset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="CUL_WSget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="CUL_WSattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#ignore">ignore</a></li><br>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li><br>
|
||
<li><a href="#showtime">showtime</a></li><br>
|
||
<li><a href="#loglevel">loglevel</a></li><br>
|
||
<li><a href="#model">model</a> (S300,KS300,WS7000)</li><br>
|
||
<li><a href="#IODev">IODev</a></li><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="CUL_EM"></a>
|
||
<h3>CUL_EM</h3>
|
||
<ul>
|
||
The CUL_EM module interprets EM type of messages received by the CUL, notably
|
||
from EMEM, EMWZ or EMGZ devices.
|
||
<br><br>
|
||
|
||
<a name="CUL_EMdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> CUL_EM <code> [corr1 corr2
|
||
CostPerUnit BasicFeePerMonth]</code> <br>
|
||
<br>
|
||
<code> is the code which must be set on the EM device. Valid values
|
||
are 1 through 12. 1-4 denotes EMWZ, 5-8 EMEM and 9-12 EMGZ devices.<br><br>
|
||
|
||
<b>corr1</b> is used to correct the current number, <b>corr2</b>
|
||
for the total number.
|
||
<ul>
|
||
<li>for EMWZ devices you should specify the rotation speed (R/kW)
|
||
of your watt-meter (e.g. 150) for corr1 and 12 times this value for
|
||
corr2</li>
|
||
<li>for EMEM devices the corr1 value is 0.01, and the corr2 value is
|
||
0.001 </li>
|
||
</ul>
|
||
<br>
|
||
|
||
<b>CostPerUnit</b> and <b>BasicFeePerMonth</b> are used to compute your
|
||
daily and mothly fees. Your COST will appear in the log, generated once
|
||
daiy (without the basic fee) or month (with the bassic fee included). Your
|
||
definition should look like E.g.:
|
||
<pre>
|
||
define emwz 1 75 900 0.15 12.50</pre>
|
||
and the Log looks like:
|
||
<pre>
|
||
CUM_DAY: 6.849 CUM: 60123.4 COST: 1.02
|
||
CUM_MONTH: 212.319 CUM: 60123.4 COST: 44.34</pre>
|
||
|
||
Tipp: You can configure your EMWZ device to show in the CUM column of the
|
||
STATE reading the current reading of your meter. For this purpose: multiply
|
||
the current reading (from the real device) with the corr1 value (RperKW),
|
||
and substract the RAW CUM value from it. Now set the basis reading of your
|
||
EMWZ device (named emwz) to this value.<br>
|
||
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="CUL_EMset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="CUL_EMget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="CUL_EMattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#ignore">ignore</a></li><br>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li><br>
|
||
<li><a href="#showtime">showtime</a></li><br>
|
||
<li><a href="#loglevel">loglevel</a></li><br>
|
||
<li><a href="#model">model</a> (EMEM,EMWZ,EMGZ)</li><br>
|
||
<li><a href="#IODev">IODev</a></li><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="CUL_HOERMANN"></a>
|
||
<h3>CUL_HOERMANN</h3>
|
||
<ul>
|
||
The CUL_HOERMANN module registers the 868MHz Hoermann Garage-Door-Opener
|
||
signals received by the CUL. <b>Note</b>: As the structure of this signal is
|
||
not understood, no checksum is verified, so it is likely to receive bogus
|
||
messages.
|
||
<br><br>
|
||
|
||
<a name="CUL_HOERMANNdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> CUL_HOERMANNEM <10-digit-hex-code></code>
|
||
<br>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="CUL_HOERMANNset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="CUL_HOERMANNget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="CUL_HOERMANNattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||
<li><a href="#showtime">showtime</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
|
||
<a name="CUL_RFR"></a>
|
||
<h3>CUL_RFR</h3>
|
||
<ul>
|
||
<table>
|
||
<tr><td>
|
||
The CUL_RFR module is used to "attach" a second CUL to your base CUL, and
|
||
use it as a repeater / range extender. RFR is shorthand for RF_ROUTER.
|
||
Transmission of the data uses the CC1101 packet capabilities with GFSK
|
||
modulation at 250kBaud after pinging the base CUL at the usual 1kBaud. When
|
||
configured, the RFR device can be used like another CUL connected directly to
|
||
fhem.
|
||
|
||
|
||
<br><br>
|
||
Before you can use this feature in fhem, you have to enable/configure RF
|
||
ROUTING in both CUL's:
|
||
<ul>
|
||
<li>First give your base CUL (which remains connected to the PC) an RFR ID
|
||
by issuing the fhem command "set MyCUL raw ui0100". With this command
|
||
the base CUL will get the ID 01, and it will not relay messages to other
|
||
CUL's (as the second number is 00).
|
||
<li>Now replace the base CUL with the RFR CUL, and set its id by issuing
|
||
the fhem command "set MyCUL raw ui0201". Now remove this CUL and attach the
|
||
original, base CUL again. The RFR CUL got the id 02, and will relay every
|
||
message to the base CUL with id 01.
|
||
<li>Take the RFR CUL, and attach it to an USB power supply, as seen on
|
||
the image. As the configured base id is not 00, it will activate RF
|
||
reception on boot, and will start sending messages to the base CUL.
|
||
<li>Now you have to define this RFR cul as a fhem device:
|
||
</ul>
|
||
|
||
</td><td>
|
||
<img src="cul_rfr.jpg"/>
|
||
</td></tr>
|
||
</table>
|
||
<br>
|
||
|
||
<a name="CUL_RFRdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> CUL_RFR <own-id> <base-id></code> <br>
|
||
<br>
|
||
<own-id> is the id of the RFR CUL <b>not</b> connected to the PC,
|
||
<base-id> is the id of the CUL connected to the PC. Both parameters
|
||
have two characters, each representing a one byte hex number.<br>
|
||
Example:
|
||
<ul>
|
||
<code>set MyCUL raw ui0100</code><br>
|
||
# Now replace the base CUL with the RFR CUL<br>
|
||
<code>set MyCUL raw ui0201</code><br>
|
||
# Reattach the base CUL to the PC and attach the RFR CUL to a
|
||
USB power supply<br>
|
||
<code>define MyRFR CUL_RFR 02 01</code><br>
|
||
</ul>
|
||
</ul> <br>
|
||
|
||
<a name="CUL_RFRset"></a>
|
||
<b>Set</b> <ul>Same as for the <a href="#CULset">CUL</a>.</ul><br>
|
||
|
||
<a name="CUL_RFRget"></a>
|
||
<b>Get</b> <ul>Same as for the <a href="#CULget">CUL</a>.</ul><br>
|
||
|
||
<a name="CUL_RFRattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#ignore">ignore</a></li><br>
|
||
<li><a href="#IODev">IODev</a></li><br>
|
||
The rest of the attributes is the same as for the <a href="#CUL">CUL</a>.</ul><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
|
||
<a name="EM"></a>
|
||
<h3>EM</h3>
|
||
<ul>
|
||
<a name="EMdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> EM <em1010pc-device></code>
|
||
<br><br>
|
||
|
||
Define a EM1010PC USB device. As the EM1010PC was not designed to be used
|
||
with a PC attached to it all the time, it won't transmit received signals
|
||
automatically, fhem has to poll it every 5 minutes.<br>
|
||
|
||
Currently there is no way to read the internal log of the EM1010PC with
|
||
fhem, use the program em1010.pl in the contrib directory for this
|
||
purpose.<br><br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define em EM /dev/elv_em1010pc</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="EMset"></a>
|
||
<b>Set</b>
|
||
<ul>
|
||
<code>set EM <value></code>
|
||
<br><br>
|
||
where <code>value</code> is either time or reset.<br>
|
||
If time has arguments of the form YYYY-MM-DD HH:MM:SS, then the specified
|
||
time will be set, else the time from the host.<br>
|
||
Note: after reset you should set the time.
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="EMget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get EM <value></code>
|
||
<br><br>
|
||
where <code>value</code> is either version or time.
|
||
</ul>
|
||
|
||
<a name="EMattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#model">model</a> (em1010pc)</li>
|
||
<li><a href="#attrdummy">dummy</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="EMWZ"></a>
|
||
<h3>EMWZ</h3>
|
||
<ul>
|
||
<a name="EMWZdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> EMWZ <device-number></code>
|
||
<br><br>
|
||
|
||
Define up to 4 EM1000WZ attached to the EM1010PC. The device number must
|
||
be between 1 and 4. Defining an EMWZ will schedule an internal task, which
|
||
reads the status of the device every 5 minutes, and triggers notify/filelog
|
||
commands. <br><br>
|
||
|
||
Example:
|
||
<ul>
|
||
<code>define emwz EMWZ 1</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="EMWZset"></a>
|
||
<b>Set</b>
|
||
<ul>
|
||
<code>set EMWZdevice <param> <value></code><br><br>
|
||
where param is one of:
|
||
<ul>
|
||
<li>rperkw<br>
|
||
Number of rotations for a KiloWatt of the EM1000WZ device (actually
|
||
of the device where the EM1000WZ is attached to). Without setting
|
||
this correctly, all other readings will be incorrect.
|
||
<li>alarm<br>
|
||
Alarm in WATT. if you forget to set it, the default value is
|
||
rediculously low (random), and if a value above this threshold is
|
||
received, the EM1010PC will start beeping once every minute. It can
|
||
be very annoying.
|
||
<li>price<br>
|
||
The price of one KW in EURO (use e.g. 0.20 for 20 Cents). It is used
|
||
only on the EM1010PC display, it is of no interest for FHEM.
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
|
||
<a name="EMWZget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get EMWZ status</code>
|
||
<br><br>
|
||
This is the same command which is scheduled every 5 minutes internally.
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="EMWZattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#model">model</a> (EM1000WZ)</li>
|
||
<li><a href="#attrdummy">dummy</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#IODev">IODev</a></li><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
|
||
<a name="EMGZ"></a>
|
||
<h3>EMGZ</h3>
|
||
<ul>
|
||
<a name="EMGZdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> EMGZ <device-number></code>
|
||
<br><br>
|
||
|
||
Define up to 4 EM1000GZ attached to the EM1010PC. The device number must
|
||
be between 9 and 12.
|
||
Defining an EMGZ will schedule an internal task, which reads the
|
||
status of the device every 5 minutes, and triggers notify/filelog commands.
|
||
<br><br>
|
||
|
||
Example:
|
||
<ul>
|
||
<code>define emgz EMGZ 9</code><br>
|
||
</ul>
|
||
</ul>
|
||
|
||
<a name="EMGZset"></a>
|
||
<b>Set</b>
|
||
<ul>
|
||
<code>set EMGZdevice <param> <value></code><br><br>
|
||
where param is:
|
||
<ul>
|
||
<li>price<br>
|
||
The price of one KW in EURO (use e.g. 0.20 for 20 Cents). It is used
|
||
only on the EM1010PC display, it is of no interest for FHEM.
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="EMGZget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get EMGZ status</code>
|
||
<br><br>
|
||
This is the same command which is scheduled every 5 minutes internally.
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="EMGZattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#model">model</a> (EM1000GZ)</li>
|
||
<li><a href="#attrdummy">dummy</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#IODev">IODev</a></li><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="EMEM"></a>
|
||
<h3>EMEM</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="EMEMdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> EMEM <device-number></code>
|
||
<br><br>
|
||
|
||
Define up to 4 EM1000EM attached to the EM1010PC. The device number must
|
||
be between 5 and 8.
|
||
Defining an EMEM will schedule an internal task, which reads the
|
||
status of the device every 5 minutes, and triggers notify/filelog commands.
|
||
<br>Note: Currently this device does not support a "set" function.
|
||
<br><br>
|
||
|
||
Example:
|
||
<ul>
|
||
<code>define emem EMEM 5</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
|
||
<a name="EMEMget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get EMEM status</code>
|
||
<br><br>
|
||
This is the same command which is scheduled every 5 minutes internally.
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="EMEMattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#model">model</a> (EM1000EM)</li>
|
||
<li><a href="#attrdummy">dummy</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#IODev">IODev</a></li><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="KM271"></a>
|
||
<h3>KM271</h3>
|
||
<ul>
|
||
KM271 is the name of the communication device for the Buderus Logamatic 2105
|
||
or 2107 heating controller. It is connected via a serial line to the fhem
|
||
computer. The fhem module sets the communication device into log-mode, which
|
||
then will generate an event on change of the inner parameters. There are
|
||
about 20.000 events a day, the FHEM module ignores about 90% of them, if the
|
||
<a href="#all_km271_events">all_km271_events</a> attribute is not set.<br>
|
||
<br>
|
||
Following events are known:
|
||
<div id="block">
|
||
<pre> HK1_Betriebswerte1
|
||
HK1_Betriebswerte2
|
||
HK1_Vorlaufsolltemperatur
|
||
HK1_Vorlaufisttemperatur
|
||
HK1_Raumsolltemperatur
|
||
HK1_Raumisttemperatur
|
||
HK1_Einschaltoptimierungszeit
|
||
HK1_Ausschaltoptimierungszeit
|
||
HK1_Pumpenleistung
|
||
HK1_Mischerstellung
|
||
HK1_Heizkennlinie_bei_+_10_Grad
|
||
HK1_Heizkennlinie_bei_0_Grad
|
||
HK1_Heizkennlinie_bei_-_10_Grad
|
||
|
||
HK2_Betriebswerte1
|
||
HK2_Betriebswerte2
|
||
HK2_Vorlaufsolltemperatur
|
||
HK2_Vorlaufisttemperatur
|
||
HK2_Raumsolltemperatur
|
||
HK2_Raumisttemperatur
|
||
HK2_Einschaltoptimierungszeit
|
||
HK2_Ausschaltoptimierungszeit
|
||
HK2_Pumpenleistung
|
||
HK2_Mischerstellung
|
||
HK2_Heizkennlinie_bei_+_10_Grad
|
||
HK2_Heizkennlinie_bei_0_Grad
|
||
HK2_Heizkennlinie_bei_-_10_Grad
|
||
|
||
WW_Betriebswerte1
|
||
WW_Betriebswerte2
|
||
WW_Solltemperatur
|
||
WW_Isttemperatur
|
||
WW_Einschaltoptimierungszeit
|
||
WW_Ladepumpe
|
||
|
||
Kessel_Vorlaufsolltemperatur
|
||
Kessel_Vorlaufisttemperatur
|
||
Brenner_Einschalttemperatur
|
||
Brenner_Ausschalttemperatur
|
||
Kessel_Integral1
|
||
Kessel_Integral
|
||
Kessel_Fehler
|
||
Kessel_Betrieb
|
||
Brenner_Ansteuerung
|
||
Abgastemperatur
|
||
Brenner_Stellwert
|
||
Brenner_Laufzeit1_Minuten2
|
||
Brenner_Laufzeit1_Minuten1
|
||
Brenner_Laufzeit1_Minuten
|
||
Brenner_Laufzeit2_Minuten2
|
||
Brenner_Laufzeit2_Minuten1
|
||
Brenner_Laufzeit2_Minuten
|
||
|
||
Aussentemperatur
|
||
Aussentemperatur_gedaempft
|
||
Versionsnummer_VK
|
||
Versionsnummer_NK
|
||
Modulkennung</pre>
|
||
</div>
|
||
<br>
|
||
As I cannot explain all the values, I logged data for a period and plotted
|
||
each received value in the following logs:
|
||
<ul>
|
||
<li><a href="km271/km271_Aussentemperatur.png">Aussentemperatur</a></li>
|
||
<li><a href="km271/km271_Betriebswerte.png">Betriebswerte</a></li>
|
||
<li><a href="km271/km271_Brenneransteuerung.png">Brenneransteuerung</a></li>
|
||
<li><a href="km271/km271_Brennerlaufzeit.png">Brennerlaufzeit</a></li>
|
||
<li><a href="km271/km271_Brennerschalttemperatur.png">Brennerschalttemperatur</a></li>
|
||
<li><a href="km271/km271_Heizkennlinie.png">Heizkennlinie</a></li>
|
||
<li><a href="km271/km271_Kesselbetrieb.png">Kesselbetrieb</a></li>
|
||
<li><a href="km271/km271_Kesselintegral.png">Kesselintegral</a></li>
|
||
<li><a href="km271/km271_Ladepumpe.png">Ladepumpe</a></li>
|
||
<li><a href="km271/km271_Raumsolltemperatur_HK1.png">Raumsolltemperatur_HK1</a></li>
|
||
<li><a href="km271/km271_Vorlauftemperatur.png">Vorlauftemperatur</a></li>
|
||
<li><a href="km271/km271_Warmwasser.png">Warmwasser</a></li>
|
||
</ul>
|
||
All of these events are reported directly after initialization (or after
|
||
requesting logmode), along with some 60 configuration records (6byte long
|
||
each). About 20 parameters from these records are reverse engeneered, they
|
||
all start with CFG_.
|
||
</ul>
|
||
|
||
|
||
|
||
<a name="KM271define"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> KM271 <serial-device-name></code>
|
||
<br><br>
|
||
Example:
|
||
<ul>
|
||
<code>define KM271 KM271 /dev/ttyS0</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="KM271set"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set KM271 <param> [<value>]</code><br><br>
|
||
where param is one of:
|
||
<ul>
|
||
<li>hk1_nachtsoll <temp><br>(0.5 celsius resolution)</li>
|
||
<li>hk1_tagsoll <temp><br>(0.5 celsius resolution)</li>
|
||
<li>hk1_betriebsart [automatik|nacht|tag]</li>
|
||
<li>ww_soll <temp><br>(1.0 celsius resolution)</li>
|
||
<li>ww_betriebsart [automatik|nacht|tag]</li>
|
||
<li>logmode<br>set to logmode / request all parameters again</li>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="KM271get"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
N/A
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="KM271attr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<a name="all_km271_events"></a>
|
||
<li>all_km271_events<br>
|
||
If this attribute is set to 1, do not ignore following events:<br>
|
||
Vorlaufisttemperatur_HK1, Kesselvorlaufisttemperatur,
|
||
Kesselintegral_1, "Kesselintegral_2<br>
|
||
These events account for ca. 92% of all events.<br>
|
||
All UNKNOWN events are ignored too, most of them were only seen
|
||
directly after setting the device into logmode.
|
||
</li>
|
||
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="KS300"></a>
|
||
<h3>KS300</h3>
|
||
<ul>
|
||
Fhem can receive the KS300 radio (868.35 MHz) messages through <a
|
||
href="#FHZ">FHZ</a>, <a href="WS300">WS300</a> or an <a href="#CUL">CUL</a>
|
||
device, so one of them must be defined first.<br>
|
||
This module services messages received by the FHZ device, if you use one of
|
||
the other alternetives, see the <a href="#WS300">WS300</a> or <a
|
||
href="#CUL_WS">CUL_WS</a> entries.<br>
|
||
Note: The KS555 is also reported to work.<br>
|
||
<br>
|
||
|
||
<a name="KS300define"></a>
|
||
<a name="KS300"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> KS300 <housecode> [ml/raincounter [wind-factor]]</code>
|
||
<br><br>
|
||
|
||
<code><housecode></code> is a four digit hex number,
|
||
corresponding to the address of the KS300 device, right now it is ignored.
|
||
The ml/raincounter defaults to 255 ml, but it must be specified if you wish
|
||
to set the wind factor, which defaults to 1.0.
|
||
<br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define ks1 KS300 1234</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="KS300set"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
N/A
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="KS300get"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
N/A
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="KS300attr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#ignore">ignore</a></li>
|
||
<li><a href="#IODev">IODev</a></li>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||
<li><a href="#showtime">showtime</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#model">model</a> (ks300)</li>
|
||
<li>rainadjustment<br>
|
||
If this attribute is set, fhem automatically accounts for rain counter
|
||
resets after a battery change and random counter switches as experienced
|
||
by some users. The raw rain counter values are adjusted by an offset
|
||
in order to flatten out the sudden large increases and decreases in
|
||
the received rain counter values. Default is off.</li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="CM11"></a>
|
||
<h3>CM11</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="CM11define"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> CM11 <serial-device></code>
|
||
<br><br>
|
||
CM11 is the X10 module to interface X10 devices with the PC.<br><br>
|
||
|
||
The current implementation can evaluate incoming data on the powerline of
|
||
any kind. It can send on, off, dimdown and dimup commands.
|
||
<br><br>
|
||
The name of the serial-device depends on your distribution. If
|
||
serial-device is none, then no device will be opened, so you can experiment
|
||
without hardware attached.<br>
|
||
|
||
If you experience problems (for verbose 4 you get a lot of "Bad CRC message"
|
||
in the log), then try to define your device as <br>
|
||
<code>define <name> FHZ <serial-device> strangetty</code><br>
|
||
<br>
|
||
|
||
Example:
|
||
<ul>
|
||
<code>define x10if CM11 /dev/ttyUSB3</code><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="CM11set"></a>
|
||
<b>Set</b>
|
||
<ul>
|
||
<code>set <name> reopen</code>
|
||
<br><br>
|
||
Reopens the serial port.
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="CM11get"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get <name> fwrev</code>
|
||
<br><br>
|
||
Reads the firmware revision of the CM11 device. Returns <code>error</code>
|
||
if the serial connection to the device times out. Can be used for error
|
||
detection.
|
||
<br><br>
|
||
|
||
<code>get <name> time</code>
|
||
<br><br>
|
||
Reads the internal time of the device which is the total uptime (modulo one
|
||
year), since fhem sets the time to 0.00:00:00 if the device requests the time
|
||
to be set after being powered on. Returns <code>error</code>
|
||
if the serial connection to the device times out. Can be used for error
|
||
detection.
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="CM11attr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||
<li><a href="#attrdummy">dummy</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#model">model</a> (CM11)</li>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="X10"></a>
|
||
<h3>X10</h3>
|
||
<ul>
|
||
<a name="X10define"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> X10 <model> <housecode>
|
||
<unitcode></code>
|
||
<br><br>
|
||
|
||
Defines an X10 device via its model, housecode and unitcode.<br><br>
|
||
|
||
Notes:
|
||
<ul>
|
||
<li><code><model></code> is one of
|
||
<ul>
|
||
<li><code>lm12</code>: lamp module, dimmable</li>
|
||
<li><code>lm15</code>: lamp module, not dimmable</li>
|
||
<li><code>am12</code>: appliance module, not dimmable</li>
|
||
<li><code>tm12</code>: tranceiver module, not dimmable. Its
|
||
unitcode is 1.</li>
|
||
</ul>
|
||
Model determines whether a dim command is reasonable to be sent
|
||
or not.</li>
|
||
<li><code><housecode></code> ranges from A to P.</li>
|
||
<li><code><unitcode></code> ranges from 1 to 16.</li>
|
||
</ul>
|
||
<br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define lamp1 X10 lm12 N 10</code><br>
|
||
<code>define pump X10 am12 B 7</code><br>
|
||
<code>define lamp2 X10 lm15 N 11</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="X10set"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set <name> <value> [<argument>]</code>
|
||
<br><br>
|
||
where <code>value</code> is one of:<br>
|
||
<pre>
|
||
dimdown # requires argument, see the note
|
||
dimup # requires argument, see the note
|
||
off
|
||
on
|
||
on-till # Special, see the note
|
||
on-for-timer # Special, see the note
|
||
</pre>
|
||
Examples:
|
||
<ul>
|
||
<code>set lamp1 dimup 10</code><br>
|
||
<code>set lamp1,lamp2 off</code><br>
|
||
<code>set pump off</code><br>
|
||
<code>set lamp2 on-till 19:59</code><br>
|
||
<code>set lamp2 on-for-timer 00:02:30</code><br>
|
||
</ul>
|
||
<br>
|
||
Notes:
|
||
<ul>
|
||
<li>Only switching and dimming are supported by now.</li>
|
||
<li>Dimming is valid only for a dimmable device as specified by
|
||
the <code>model</code> argument in its <code>define</code>
|
||
statement.
|
||
<li>An X10 device has 210 discrete brightness levels. If you use a
|
||
X10 sender, e.g. a remote control or a wall switch to dim, a
|
||
brightness step is 100%/210.</li>
|
||
<li><code>dimdown</code> and <code>dimup</code> take a number in the
|
||
range from 0 to 22 as argument. It is assumed that argument 1 is
|
||
a 1% brightness change (microdim) and arguments 2 to 22 are
|
||
10%..100% brightness changes. The meaning of argument 0 is
|
||
unclear.</li>
|
||
<li>This currently leads to some confusion in the logs as the
|
||
<code>dimdown</code> and <code>dimup</code> codes are logged with
|
||
different meaning of the arguments depending on whether the commands
|
||
were sent from the PC or from a remote control or a wall switch.</li>
|
||
<li><code>dimdown</code> and <code>dimup</code> from on and off states may
|
||
have unexpected results. This seems to be a feature of the X10
|
||
devices.</li>
|
||
<li><code>on-till</code> requires an absolute time in the "at" format
|
||
(HH:MM:SS, HH:MM) or { <perl code> }, where the perl code
|
||
returns a time specification).
|
||
If the current time is greater than the specified time, then the
|
||
command is ignored, else an "on" command is generated, and for the
|
||
given "till-time" an off command is scheduleld via the at command.
|
||
</li>
|
||
<li><code>on-for-timer</code> requires a relative time in the "at" format
|
||
(HH:MM:SS, HH:MM) or { <perl code> }, where the perl code
|
||
returns a time specification).
|
||
</li>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="X10get"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="X10attr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||
<li><a href="#attrdummy">dummy</a></li>
|
||
<li><a href="#showtime">showtime</a></li>
|
||
<li><a href="#model">model</a> (lm12,lm15,am12,tm13)</li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#IODev">IODev</a></li><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="LIRC"></a>
|
||
<h3>LIRC</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="LIRCdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> LIRC <device></code>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="LIRCset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="LIRCget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="LIRCattr"></a>
|
||
<b>Attributes</b> <ul>N/A</ul><br>
|
||
</ul>
|
||
|
||
<a name="WS300"></a>
|
||
<h3>WS300</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="WS300define"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define WS300Device WS300 <serial device></code><br>
|
||
or<br>
|
||
<code>define <devname> WS300 [0-9]</code><br>
|
||
<br>
|
||
The first line is mandatory if you have a WS300 device: it defines the
|
||
input device with its USB port. The name of this device is fixed and must
|
||
be WS300Device. It must be the first defined WS300 device.<br>
|
||
|
||
For each additional device (with number 0 to 9) you have to define another
|
||
WS300 device, with an arbitrary name. The WS300 device which reports the
|
||
readings will be defined with the port number 9, an optional KS300 with the
|
||
port number 8.<br><br>
|
||
|
||
Examples:
|
||
<pre>
|
||
define WS300Device WS300 /dev/ttyUSB1
|
||
define ash2200.1 WS300 0
|
||
define ks300 WS300 8
|
||
define ws300 WS300 9
|
||
</pre>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="WS300set"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set WS300Device <interval(min.)> <height(m)> <rainvalume(ml)></code>
|
||
<br><br>
|
||
Set some WS300 configuration parameters.
|
||
</ul>
|
||
|
||
|
||
<a name="WS300get"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
N/A
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="WS300attr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#model">model</a> (ws300)</li>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
|
||
<a name="Weather"></a>
|
||
<h3>Weather</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="Weatherdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> Weather <location> [<interval>]</code><br>
|
||
<br>
|
||
Defines a virtual device for weather forecasts. You need to have the perl
|
||
module Weather::Google installed to use this device. If you do not have it,
|
||
use <i>cpan -i Weather::Google</i> to install it.<br><br>
|
||
|
||
A Weather device periodically gathers current and forecast weather conditions
|
||
from the Google Weather API.<br><br>
|
||
|
||
The parameter <code>location</code> is any string that is recognized as a
|
||
location, either a town name or a zip code. Browse to the URL
|
||
<code>http://www.google.de/ig/api?weather=location&hl=en</code>
|
||
to see the raw output for your location.<br><br>
|
||
|
||
The parameter <code>interval</code> is the time between subsequent updates
|
||
in seconds. It defaults to 3600 (1 hour).<br><br>
|
||
|
||
Examples:
|
||
<pre>
|
||
define MyWeather Weather "Frankfurt,HE"
|
||
define Forecast Weather "Amsterdam,NL" 1800
|
||
define weather Weather "30000,France"
|
||
</pre>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="Weatherset"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
N/A
|
||
</ul>
|
||
<br>
|
||
|
||
|
||
<a name="Weatherget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get <name> <reading></code><br><br>
|
||
|
||
Valid readings and their meaning (? can be one of 0, 1, 2, 3 and stands
|
||
for today, tomorrow, ...):<br>
|
||
<table>
|
||
<tr><td>city</td><td>name of town returned for location</td></tr>
|
||
<tr><td>condition</td><td>current condition, one of Sunny, Clear, Partly Cloudy, Mostly Cloudy, Overcast, Chance of Rain</td></tr>
|
||
<tr><td>current_date_time</td><td>last update of forecast on server</td></tr>
|
||
<tr><td>fc?_condition</td><td>forecast condition</td></tr>
|
||
<tr><td>fc?_day_of_week</td><td>day of week for day +?</td></tr>
|
||
<tr><td>fc?_high_c</td><td>forecasted daily high in degrees centigrade</td></tr>
|
||
<tr><td>fc?_icon</td><td>relative path for forecast icon, prefix with <code>http://www.google.com</code> to form a valid URL for display in web interfaces</td></tr>
|
||
<tr><td>fc?_low_c</td><td>forecasted daily low in degrees centigrade</td></tr>
|
||
<tr><td>humidity</td><td>current humidity</td></tr>
|
||
<tr><td>icon</td><td>relative path for current icon</td></tr>
|
||
<tr><td>postal_code</td><td>location sent to server</td></tr>
|
||
<tr><td>temp_c</td><td>current temperature in degrees centigrade</td></tr>
|
||
<tr><td>temp_f</td><td>current temperature in degrees Fahrenheit</td></tr>
|
||
<tr><td>wind_condition</td><td>wind direction and speed</td></tr>
|
||
</table>
|
||
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="Weatherattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
N/A
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
|
||
<a name="USF1000"></a>
|
||
<h3>USF1000</h3>
|
||
<ul>
|
||
Fhem can receive your tank's fill level from the USF1000S device
|
||
through a <a href="#FHZ">FHZ</a> device, so one must be defined first.
|
||
The state contains the fill level in % (lower case v in the device state)
|
||
and the current volume in liters (upper case V in the device state).
|
||
Measured distance to the liquid's surface, fill level, volume and warnings
|
||
(Test mode, Battery low) are available. Due to the design of the USF1000S
|
||
protocol, you can have only one USF1000S in range of your FHZ as these
|
||
devices cannot be distinguished.<br>
|
||
<br>
|
||
|
||
<a name="USF1000Define"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> USF1000 <geometry></code>
|
||
<br><br>
|
||
|
||
<code><geometry></code> determines the form of the tank and the
|
||
position of the sensor. The following geometries are currently
|
||
supported:<br><br>
|
||
<ul>
|
||
<li><code>cub <length> <width> <height> <offset></code></li>
|
||
<li><code>cylv <diameter> <height> <offset></code></li>
|
||
</ul>
|
||
<br>
|
||
<code>cub</code> stands for a cuboid whose base is <length> × <width>.
|
||
<code>cylv</code> stands for a vertical cylinder whose diameter is <diameter>.
|
||
<height> is the distance of the surface of the liquid from the ground
|
||
if the tank is full. <offset> is the distance of the sensor relative to
|
||
the surface of the liquid. All quantities are expressed in meters.<br>
|
||
<br>
|
||
|
||
Example:<br>
|
||
<ul>
|
||
<code>define MyTank USF1000 cylv 2 1 0.3</code>: a cylindrical water tank with
|
||
2 meters diameter. The water stands 1 meter high if the tank is full. The
|
||
sensor is fixed 1,3 meters above ground.<br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="USF1000set"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
N/A
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="USF1000get"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
N/A
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="USF1000attr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#IODev">IODev</a></li><br>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||
<li><a href="#showtime">showtime</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#model">model</a> (usf1000s)</li>
|
||
<li><a href="#ignore">ignore</a></li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
<a name="WEBIO"></a>
|
||
<h3>WEBIO</h3>
|
||
<ul>
|
||
<a name="WEBIOdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> WEBIO <ip-address> <port> <delay></code>
|
||
<br><br>
|
||
Defines an Web-IO device (Box with 2 Analog-In/Out 0..10V, www.wut.de) via ip address. The status of the device is also pooled (delay interval).<br><br>
|
||
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define pumpspeed WEBIO 192.168.8.200 1 60</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="WEBIOset"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set <name> <value></code>
|
||
<br><br>
|
||
where <code>value</code> is one of:<br>
|
||
<pre>
|
||
0.00 - 10.00
|
||
</pre>
|
||
Examples:
|
||
<ul>
|
||
<code>set pumpspeed 6.75</code><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="VantagePro2"></a>
|
||
<h3>VantagePro2</h3>
|
||
<ul>
|
||
<a name="VantagePro2define"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> <ip-address> <port> <delay></code>
|
||
<br><br>
|
||
Defines a Davis VantagePro2 weatherstation attached on transparent ethernet/usb|serial server accessable by telnet.<br><br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define AUSSEN.wetterstation VantagePro2 192.168.8.127 4999 60</code><br>
|
||
<code>
|
||
fhem> list AUSSEN.wetterstation<br>
|
||
Internals:<br>
|
||
DEF 192.168.8.127 4999 60<br>
|
||
Host 192.168.8.127<br>
|
||
NAME AUSSEN.wetterstation<br>
|
||
NR 5<br>
|
||
Port 4999<br>
|
||
STATE T-OUT: 22.78 T-IN: 26.50 H-OUT: 55 H-IN: 45 W: 1.61 W-AV: 1.61 WS 257 R: 0.00 S: 770 UV: 4.1 RD: 0 RM: 41 RY: 241 BM: 76.27 BT: Steady<br>
|
||
TYPE VantagePro2<br>
|
||
Readings:<br>
|
||
2010-08-04 10:15:17 10 min. average windspeed 1.61 (km/h)<br>
|
||
2010-08-04 10:15:17 UV 4.1 (UV/Index)<br>
|
||
2010-08-04 10:15:17 barometer 76.27 (Millimeters)<br>
|
||
2010-08-04 10:15:17 barometer trend Steady<br>
|
||
2010-08-04 10:15:17 day rain 0 (mm/day)<br>
|
||
2010-08-04 10:15:17 humidity inside 45 (%)<br>
|
||
2010-08-04 10:15:17 humidity outside 55 (%)<br>
|
||
2010-08-04 10:15:17 month rain 41 (mm/month)<br>
|
||
2010-08-04 10:15:17 rainrate 0.00 (mm/h)<br>
|
||
2010-08-04 10:15:17 solar 770 (Watt/m^2)<br>
|
||
2010-08-04 10:15:17 temperature-inside 26.50 (Celsius)<br>
|
||
2010-08-04 10:15:17 temperature-outside 22.78 (Celsius)<br>
|
||
2010-08-04 10:15:17 wind direction 257 (Degrees)<br>
|
||
2010-08-04 10:15:17 windspeed 1.61 (km/h)<br>
|
||
2010-08-04 10:15:17 year rain 241 (mm/year)<br>
|
||
Attributes:<br>
|
||
delay 60<br>
|
||
</code><br>
|
||
</ul>
|
||
</ul>
|
||
</ul>
|
||
|
||
<a name="ALL3076"></a>
|
||
<h3>ALL3076</h3>
|
||
<ul>
|
||
<a name="ALL3076define"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> ALL3076 <ip-address> </code>
|
||
<br><br>
|
||
Defines an Allnet 3076 device (Dimmable lightswitch) via its ip address or dns name<br><br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define lamp1 ALL3076 192.168.1.200</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="ALL3076set"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set <name> <value></code>
|
||
<br><br>
|
||
where <code>value</code> is one of:<br>
|
||
<pre>
|
||
dimdown
|
||
dim10%
|
||
dim20%
|
||
dim30%
|
||
dim40%
|
||
dim50%
|
||
dim60%
|
||
dim70%
|
||
dim80%
|
||
dim90%
|
||
dim100%
|
||
dim[0-100]%
|
||
dimup
|
||
off
|
||
on
|
||
toggle
|
||
</pre>
|
||
Examples:
|
||
<ul>
|
||
<code>set lamp1 on</code><br>
|
||
<code>set lamp1 dim11%</code><br>
|
||
<code>set lamp2 toggle</code><br>
|
||
</ul>
|
||
<br>
|
||
Notes:
|
||
<ul>
|
||
<li>Toggle is special implemented. List name returns "on" or "off" even after a toggle command</li>
|
||
</ul>
|
||
</ul>
|
||
</ul>
|
||
|
||
<a name="ALL4000T"></a>
|
||
<h3>ALL4000T</h3>
|
||
<ul>
|
||
<a name="ALL4000Tdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> ALL4000T <ip-address> <port> <delay></code>
|
||
<br><br>
|
||
Defines a temperature sensor connected on an Allnet 4000 device via its ip address and port. Use the delay argument to define the delay between polls.<br><br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define AUSSEN.POOL.TEMP.vorlauf ALL4000T 192.168.68.20 t2 120</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
<a name="ALL4027"></a>
|
||
<h3>ALL4027</h3>
|
||
<ul>
|
||
<a name="ALL4027define"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> ALL4027 <ip-address> <port> <relay_nr> <delay></code>
|
||
<br><br>
|
||
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.<br><br>
|
||
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define lamp1 ALL4027 192.168.8.200 0 7 60</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="ALL4027set"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set <name> <value></code>
|
||
<br><br>
|
||
where <code>value</code> is one of:<br>
|
||
<pre>
|
||
off
|
||
on
|
||
toggle
|
||
</pre>
|
||
Examples:
|
||
<ul>
|
||
<code>set poolpump on</code><br>
|
||
</ul>
|
||
<br>
|
||
Notes:
|
||
<ul>
|
||
<li>Toggle is special implemented. List name returns "on" or "off" even after a toggle command</li>
|
||
</ul>
|
||
</ul>
|
||
</ul>
|
||
|
||
<a name="BS"></a>
|
||
<h3>BS</h3>
|
||
<ul>
|
||
The module BS allows to collect data from a brightness sensor through a
|
||
<a href="#FHZ">FHZ</a> device. For details on the brightness sensor see
|
||
<a href="http://www.busware.de/tiki-index.php?page=CPM-BS">busware wiki</a>.
|
||
You can have at most nine different brightness sensors in range of your
|
||
FHZ.<br>
|
||
<br>
|
||
|
||
The state contains the brightness in % (reading <code>brightness</code>) and
|
||
the brightness in lux (reading <code>lux</code>). The <code>flags</code>
|
||
reading is always zero. The meaning of these readings is explained in more
|
||
detail on the above mentioned wiki page.<br>
|
||
<br>
|
||
|
||
<a name="BSDefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> BS <sensor#> [<RExt>]</code>
|
||
<br><br>
|
||
|
||
<code><sensor#></code> is the number of sensor in the brightness
|
||
sensor address system that runs from 1 to 9.<br>
|
||
<br>
|
||
<code><RExt></code> is the value of the resistor on your brightness
|
||
sensor in Ω (Ohm). The brightness reading in % is proportional to the resistance, the
|
||
lux reading is proportional to the resistance squared. The value is
|
||
optional. The default resistance is RExt= 50.000Ω.<br>
|
||
<br>
|
||
|
||
Example:<br>
|
||
<ul>
|
||
<code>define bs1 BS 1 40000</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="BSset"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
N/A
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="BSget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
N/A
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="BSattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||
<li><a href="#showtime">showtime</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#model">model</a> (bs)</li>
|
||
<li><a href="#ignore">ignore</a></li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
|
||
|
||
|
||
<a name="SCIVT"></a>
|
||
<h3>SCIVT</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="SCIVTdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> SCIVT <SCD-device></code>
|
||
<br><br>
|
||
|
||
Define a SCD series solar controler device. Details see <a
|
||
href="http://english.ivt-hirschau.de/content.php?parent_id=CAT_64&doc_id=DOC_118">here</a>.
|
||
You probably need a Serial to USB controller like the PL2303.
|
||
<br>
|
||
Defining an SCIVT device will schedule an internal task, which reads the
|
||
status of the device every 5 minutes, and triggers notify/filelog commands.
|
||
<br>Note: Currently this device does not support a "set" function, only
|
||
a single get function which reads the device status immediately.
|
||
<br><br>
|
||
|
||
Example:
|
||
<ul>
|
||
<code>define scd SCIVT /dev/ttyUSB2</code><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="SVICTset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="SVICTget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get SCVIT data</code>
|
||
<br>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="SVICTattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#model">model</a> (SCD)</li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="M232"></a>
|
||
<h3>M232</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="M232define"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> M232 <m232-device></code>
|
||
<br><br>
|
||
|
||
Define a M232 device. You can attach as many M232 devices as you like. A
|
||
M232 device provides 6 analog inputs (voltage 0..5V with 10 bit resolution)
|
||
and 8 bidirectional digital ports. The eighth digital port can be used as a
|
||
16 bit counter (maximum frequency 3kHz). The M232 device needs to be
|
||
connected to a 25pin sub-d RS232 serial port. A USB-to-serial converter
|
||
works fine if no serial port is available.<br><br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define m232 M232 /dev/ttyUSB2</code><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="M232set"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set <name> stop</code>
|
||
<br><br>
|
||
Stops the counter.
|
||
<br><br>
|
||
<code>set <name> start</code>
|
||
<br><br>
|
||
Resets the counter to zero and starts it.
|
||
<br><br>
|
||
<code>set <name> octet <value></code>
|
||
<br><br>
|
||
Sets the state of all digital ports at once, value is 0..255.
|
||
<br><br>
|
||
<code>set <name> io0..io7 0|1</code>
|
||
<br><br>
|
||
Turns digital port 0..7 off or on.
|
||
<br><br>
|
||
</ul>
|
||
|
||
|
||
<a name="M232get"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get <name> [an0..an5]</code>
|
||
<br><br>
|
||
Gets the reading of analog input 0..5 in volts.
|
||
<br><br>
|
||
<code>get <name> [io0..io7]</code>
|
||
<br><br>
|
||
Gets the state of digital ports 0..7, result is 0 or 1.
|
||
<br><br>
|
||
<code>get <name> octet</code>
|
||
<br><br>
|
||
Gets the state of all digital ports at once, result is 0..255.
|
||
<br><br>
|
||
<code>get <name> counter</code>
|
||
<br><br>
|
||
Gets the number of ticks of the counter since the last reset. The counter
|
||
wraps around from 65,535 to 0 and <i>then stops</i>.
|
||
See <a href="#M232Counter">M232Counter</a> for how we care about this.
|
||
<br><br>
|
||
</ul>
|
||
|
||
|
||
<a name="M232attr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#model">model</a> (m232)</li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
|
||
<a name="M232Counter"></a>
|
||
<h3>M232Counter</h3>
|
||
<ul>
|
||
|
||
<a name="M232Counterdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> M232Counter [unit [factor [deltaunit [deltafactor]]]]</code>
|
||
<br><br>
|
||
|
||
Define at most one M232Counter for a M232 device. Defining a M232Counter
|
||
will schedule an internal task, which periodically reads the status of the
|
||
counter, and triggers notify/filelog commands. <code>unit</code> is the unit
|
||
name, <code>factor</code> is used to calculate the reading of the counter
|
||
from the number of ticks. <code>deltaunit</code> is the unit name of the counter
|
||
differential per second, <code>deltafactor</code> is used to calculate the
|
||
counter differential per second from the number of ticks per second.<br><br>
|
||
Default values:
|
||
<ul>
|
||
<li>unit: ticks</li>
|
||
<li>factor: 1.0</li>
|
||
<li>deltaunit: ticks per second</li>
|
||
<li>deltafactor: 1.0</li>
|
||
</ul>
|
||
<br>Note: the parameters in square brackets are optional. If you wish to
|
||
specify an optional parameter, all preceding parameters must be specified
|
||
as well.
|
||
<br><br>Examples:
|
||
<ul>
|
||
<code>define counter M232Counter turns</code><br>
|
||
<code>define counter M232Counter kWh 0.0008 kW 2.88</code>
|
||
(one tick equals 1/1250th kWh)<br>
|
||
</ul>
|
||
<br>
|
||
Do not forget to start the counter (with <code>set .. start</code> for
|
||
M232) or to start the counter and set the reading to a specified value
|
||
(with <code>set ... value</code> for M232Counter).<br><br>
|
||
To avoid issues with the tick count reaching the end point, the device's
|
||
internal counter is automatically reset to 0 when the tick count is 64,000
|
||
or above and the reading <i>basis</i> is adjusted accordingly.
|
||
<br><br>
|
||
</ul>
|
||
|
||
<a name="M232Counterset"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set <name> value <value></code>
|
||
<br><br>
|
||
Sets the reading of the counter to the given value. The counter is reset
|
||
and started and the offset is adjusted to value/unit.
|
||
<br><br>
|
||
<code>set <name> interval <interval></code>
|
||
<br><br>
|
||
Sets the status polling interval in seconds to the given value. The default
|
||
is 60 seconds.
|
||
<br><br>
|
||
</ul>
|
||
|
||
|
||
<a name="M232Counterget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get <name> status</code>
|
||
<br><br>
|
||
Gets the reading of the counter multiplied by the factor from the
|
||
<code>define</code> statement. Wraparounds of the counter are accounted for
|
||
by an offset (see reading <code>basis</code> in the output of the
|
||
<code>list</code> statement for the device).
|
||
<br><br>
|
||
</ul>
|
||
|
||
<a name="M232Counterattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#attrdummy">dummy</a></li><br>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#model">model</a> (M232Counter)</li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="M232Voltage"></a>
|
||
<h3>M232Voltage</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="M232Voltagedefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> M232Voltage [an0..an5] [unit [factor]]</code>
|
||
<br><br>
|
||
|
||
Define as many M232Voltages as you like for a M232 device. Defining a
|
||
M232Voltage will schedule an internal task, which reads the status of the
|
||
analog input every minute, and triggers notify/filelog commands.
|
||
<code>unit</code> is the unit name, <code>factor</code> is used to
|
||
calibrate the reading of the analog input.<br><br>
|
||
|
||
Note: the unit defaults to the string "volts", but it must be specified
|
||
if you wish to set the factor, which defaults to 1.0. <br><br>
|
||
|
||
Example:
|
||
<ul>
|
||
<code>define volt M232Voltage an0</code><br>
|
||
<code>define brightness M232Voltage an5 lx 200.0</code><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="M232Voltageget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get <name> status</code>
|
||
<br><br>
|
||
</ul>
|
||
|
||
<a name="M232Voltageattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#attrdummy">dummy</a></li><br>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#model">model</a> (M232Voltage)</li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="xxLG7000"></a>
|
||
<h3>xxLG7000</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="xxLG7000define"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> xxLG7000 <serial-device></code>
|
||
<br><br>
|
||
|
||
Defines a serial link to a TV set of LG's xxLG70yy (e. g. 47LG7000) series
|
||
and similar TV sets from <a href="http://www.lge.com/">LG</a>. As of January 2010, the following TV sets should
|
||
be compatible:<br><br>
|
||
<ul>
|
||
<li><code>xxLG7000</code>, e. g. 47LG7000 (tested)</li>
|
||
<li><code>xxPG7000</code>, e. g. 50PG7000 (same Manual as 47LG7000 ;))</li>
|
||
<li><code>PS3000/6000/7000/8000 series</code> (according to <a href="http://www.lge.com/uk/products/documents/LGSV09-LR.pdf">LG brochure</a>; no liabilities assumed)</li>
|
||
<li><code>PQ3000/6000 series</code> (see PS3000)</li>
|
||
<li><code>LU4000/5000 series</code> (<i>not LU7000</i>; see PS3000)</li>
|
||
<li><code>LH2000/3000/4000/5000 series</code> (see PS3000)</li>
|
||
<li><code>SL9500/9000/8000 series</code> (see PS3000)</li>
|
||
</ul><br>
|
||
These TV sets feature a serial connector which can officially be used to control
|
||
the TV set (see your Onwer's Manual, there's an Appendix labelled "External Control
|
||
Device setup", referening to cabling and command set). The xxLG7000 module is
|
||
the FHEM module to actually utilize this. (BTW, those TVs run Linux internally ;))<br><br>
|
||
To exercise control over your TV set, use the <a href="#LGTV">LGTV</a> module and
|
||
bind it ("attr <LGTV-name> IODev <xxLG7000-name>") to xxLG7000.<br><br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define myLG7k xxLG7000 /dev/ttyUSB1</code><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="xxLG7000set"></a>
|
||
<b>Set </b>
|
||
<ul> Not used, nothing to set directly. </ul>
|
||
|
||
<a name="xxLG7000get"></a>
|
||
<b>Get</b>
|
||
<ul> Not used, nothing to get directly. </ul>
|
||
|
||
<a name="xxLG7000attr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li>SetID (1, 2, ...; see your TV's Owner's Manual how to set it. Defaults to 1 if unset.)</li>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
|
||
<a name="LGTV"></a>
|
||
<h3>LGTV</h3>
|
||
<ul>
|
||
|
||
<a name="LGTVdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> LGTV</code>
|
||
<br><br>
|
||
|
||
This module is expected to work with <a href="#xxLG7000">xxLG7000</a> as it's
|
||
IODev. With LGTV and a compatible hardware module (currently, there's only
|
||
xxLG7000), you are able to power your TV set on and off, query it's power state,
|
||
select the input (AV, RGB, Composites, analogue TV, DVB-T, HDMI) or mute/unmute
|
||
the volume.<br>
|
||
Defining a LGTV device will schedule an internal task, which periodically reads
|
||
the status of the TV set (power state; if power is on, query the selected input)
|
||
and triggers notify/filelog commands.<br><br>
|
||
|
||
Example:
|
||
<ul>
|
||
<code>define 47LG7000 LGTV</code><br>
|
||
<code>attr 47LG7000 IODev <a href="#xxLG7000">myLG7k</a></code>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="LGTVset"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set <name> <what> <value></code>
|
||
<br><br>
|
||
Currently, the following commands are defined; not all may be available on a
|
||
given TV set. An error messages should be recorded if e. g. the input in question
|
||
is not usable.
|
||
|
||
<pre>power on
|
||
power off
|
||
input AV1
|
||
input AV2
|
||
input AV3
|
||
input AV3
|
||
input Component
|
||
input RGB
|
||
input HDMI1
|
||
input HDMI2
|
||
input HDMI3
|
||
input HDMI4
|
||
input DVBT
|
||
input PAL
|
||
audio mute
|
||
audio normal</pre>
|
||
</ul>
|
||
|
||
<a name="LGTVget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get <name> <what></code>
|
||
<br><br>
|
||
Currently, the following commands are defined; not all may be available on a
|
||
given TV set. An error messages should be recorded if e. g. the input in question
|
||
is not usable.
|
||
<pre>power
|
||
input
|
||
audio</pre>
|
||
</ul>
|
||
|
||
<a name="LGTVattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#attrdummy">dummy</a></li><br>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<!-- <li><a href="#model">model</a> (M232Counter)</li> -->
|
||
</ul>
|
||
<br>
|
||
<b>Implementator's note</b>
|
||
<ul>
|
||
The commands listed above are send 1:1 to the underlying IODev (e. g. xxLG7000); that IODev
|
||
is responsible for translation into <i>whatever means</i> to invoke the function on the TV.
|
||
It is my hope that other's will adopt this idea and write compatible low level drivers for other
|
||
TV sets, to make this module (even ;)) more useful.
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="OWFS"></a>
|
||
<h3>OWFS</h3>
|
||
<ul>
|
||
OWFS is a suite of programs that designed to make the 1-wire bus and its
|
||
devices easily accessible. The underlying priciple is to create a virtual
|
||
filesystem, with the unique ID being the directory, and the individual
|
||
properties of the device are represented as simple files that can be read
|
||
and written.<br><br>
|
||
|
||
Note:<br>
|
||
You need the owperl module from <a href="http://owfs.org/index.php?page=owperl">http://owfs.org/</a>.
|
||
<br><br>
|
||
|
||
<a name="OWFSdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> OWFS <owserver-ip:port> <model> [<id>]</code>
|
||
<br><br>
|
||
|
||
Define a 1-wire device to communicate with an OWFS-Server.<br><br>
|
||
|
||
<code><owserver-ip:port></code>
|
||
<ul>
|
||
IP-address:port from OW-Server.
|
||
</ul>
|
||
<code><model></code>
|
||
<ul>
|
||
Define the <a href="#owfs_type">type</a> of the input device.
|
||
Currently supportet: <code>DS1420, DS9097 (for passive Adapter)</code>
|
||
</ul>
|
||
<code><id></code>
|
||
<ul>
|
||
Corresponding to the <a href="#owfs_id">id</a> of the input device. Only for active Adapter.
|
||
<br><br>
|
||
</ul>
|
||
|
||
Note:<br>
|
||
If the <code>owserver-ip:port</code> is called <code>none</code>, then
|
||
no device will be opened, so you can experiment without hardware attached.<br><br>
|
||
|
||
Example:
|
||
<ul>
|
||
<code>#define an active Adapter:<br>
|
||
define DS9490R OWFS 127.0.0.1:4304 DS1420 93302D000000</code><br>
|
||
</ul>
|
||
<br>
|
||
<ul>
|
||
<code>#define a passive Adapter:<br>
|
||
define DS9097 OWFS 127.0.0.1:4304 DS9097</code><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="OWFSget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get <name> <value></code>
|
||
<br><br>
|
||
where <code>value</code> is one of (not supported by passive Devices e.g. DS9097):<br>
|
||
<ul>
|
||
<li><a name="owfs_address"></a>
|
||
<code>address</code> (read-only)<br>
|
||
The entire 64-bit unique ID. address starts with the family code.<br>
|
||
Given as upper case hexidecimal digits (0-9A-F).
|
||
</li>
|
||
<li><a name="owfs_crc8"></a>
|
||
<code>crc8</code> (read-only)<br>
|
||
The 8-bit error correction portion. Uses cyclic redundancy check. Computed
|
||
from the preceeding 56 bits of the unique ID number.<br>
|
||
Given as upper case hexidecimal digits (0-9A-F).
|
||
</li>
|
||
<li><a name="owfs_family"></a>
|
||
<code>family</code> (read-only)<br>
|
||
The 8-bit family code. Unique to each type of device.<br>
|
||
Given as upper case hexidecimal digits (0-9A-F).
|
||
</li>
|
||
<li><a name="owfs_id"></a>
|
||
<code>id</code> (read-only)<br>
|
||
The 48-bit middle portion of the unique ID number. Does not include the
|
||
family code or CRC.<br>
|
||
Given as upper case hexidecimal digits (0-9A-F).
|
||
</li>
|
||
<li><a name="owfs_locator"></a>
|
||
<code>locator</code> (read-only)<br>
|
||
Uses an extension of the 1-wire design from iButtonLink company that
|
||
associated 1-wire physical connections with a unique 1-wire code. If
|
||
the connection is behind a Link Locator the locator will show a unique
|
||
8-byte number (16 character hexidecimal) starting with family code FE.<br>
|
||
If no Link Locator is between the device and the master, the locator
|
||
field will be all FF.
|
||
</li>
|
||
<li><a name="owfs_present"></a>
|
||
<code>present</code> (read-only)<br>
|
||
Is the device currently present on the 1-wire bus?
|
||
</li>
|
||
<li><a name="owfs_type"></a>
|
||
<code>type</code> (read-only)<br>
|
||
Part name assigned by Dallas Semi. E.g. DS2401 Alternative packaging
|
||
(iButton vs chip) will not be distiguished.
|
||
</li>
|
||
<br>
|
||
</ul>
|
||
Examples:
|
||
<ul>
|
||
<code>get DS9490R type</code><br>
|
||
<code>DS9490R type => DS1420</code><br><br>
|
||
<code>get DS9490R address</code><br>
|
||
<code>DS9490R address => 8193302D0000002B</code>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="OWFSattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#attrdummy">dummy</a></li>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#showtime">showtime</a></li>
|
||
<li><a name="owfs_temp-scale"></a>
|
||
temp-scale<br>
|
||
Specifies the temperature-scale unit:
|
||
<ul>
|
||
<li><code>C</code><br>
|
||
Celsius. This is the default.</li>
|
||
<li><code>F</code><br>
|
||
Fahrenheit</li>
|
||
<li><code>K</code><br>
|
||
Kelvin</li>
|
||
<li><code>R</code><br>
|
||
Rankine</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="OWTEMP"></a>
|
||
<h3>OWTEMP</h3>
|
||
<ul>
|
||
High-Precision 1-Wire Digital Thermometer.
|
||
<br><br>
|
||
|
||
Note:<br>
|
||
Please define an <a href="#OWFS">OWFS</a> device first.
|
||
<br><br>
|
||
|
||
<a name="OWTEMPdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> OWTEMP <id> [<interval>] [<alarminterval>]</code>
|
||
<br><br>
|
||
|
||
Define a 1-wire Digital Thermometer device.<br><br>
|
||
|
||
<code><id></code>
|
||
<ul>
|
||
Corresponding to the <a href="#owfs_id">id</a> of the input device.<br>
|
||
Set <id> to <code>none</code>for demo mode.
|
||
</ul>
|
||
<code><interval></code>
|
||
<ul>
|
||
Sets the status polling intervall in seconds to the given value. The default is 300 seconds.
|
||
</ul>
|
||
<code><alarminterval></code>
|
||
<ul>
|
||
Sets the alarm polling intervall in seconds to the given value. The default is 300 seconds.
|
||
<br><br>
|
||
</ul>
|
||
|
||
Note:<br>
|
||
Currently supported <a href="#owfs_type">type</a>: <code>DS18S20</code>.<br><br>
|
||
|
||
Example:
|
||
<ul>
|
||
<code>define KG.hz.TF.01 OWTEMP 14B598010800 300 60</code><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="OWTEMPset"></a>
|
||
<b>Set</b>
|
||
<ul>
|
||
<code>set <name> <value></code>
|
||
<br><br>
|
||
where <code>value</code> is one of:<br>
|
||
<ul>
|
||
<li><a name="owtemp_templow"></a>
|
||
<code>templow</code> (read-write)<br>
|
||
The upper limit for the low temperature alarm state.
|
||
</li>
|
||
<li><a name="owtemp_temphigh"></a>
|
||
<code>temphigh</code> (read-write)<br>
|
||
The lower limit for the high temperature alarm state.
|
||
</li>
|
||
<li><a name="owtemp_ALARMINT"></a>
|
||
<code>ALARMINT</code> (write-only)<br>
|
||
Sets the alarm polling intervall in seconds to the given value.
|
||
</li>
|
||
<li><a name="owtemp_INTERVAL"></a>
|
||
<code>INTERVAL</code> (write-only)<br>
|
||
Sets the status polling intervall in seconds to the given value.
|
||
</li>
|
||
</ul>
|
||
</ul><br>
|
||
|
||
<a name="OWTEMPget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get <name> <value></code>
|
||
<br><br>
|
||
where <code>value</code> is one of:<br>
|
||
<ul>
|
||
<li><a href="#owfs_address">address</a> (read-only)</li>
|
||
<li><a href="#owfs_crc8">crc8</a> (read-only)</li>
|
||
<li><a href="#owfs_family">family</a> (read-only)</li>
|
||
<li><a href="#owfs_id">id</a> (read-only)</li>
|
||
<li><a href="#owfs_locator">locator</a> (read-only)</li>
|
||
<li><a href="#owfs_present">present</a> (read-only)</li>
|
||
<li><a name="owtemp_temperature"></a>
|
||
<code>temperature</code> (read-only)<br>
|
||
Read by the chip at high resolution (~12 bits). Units are selected from
|
||
the defined OWFS Device. See <a href="#owfs_temp-scale">temp-scale</a> for choices.
|
||
</li>
|
||
<li><a href="#owtemp_templow">templow</a> (read-write)</li>
|
||
<li><a href="#owtemp_temphigh">temphigh</a> (read-write)</li>
|
||
<li><a href="#owfs_type">type</a> (read-only)</li>
|
||
<br>
|
||
</ul>
|
||
Examples:
|
||
<ul>
|
||
<code>get KG.hz.TF.01 type</code><br>
|
||
<code>KG.hz.TF.01 type => DS18S20</code><br><br>
|
||
<code>get KG.hz.TF.01 temperature</code><br>
|
||
<code>KG.hz.TF.01 temperature => 38.2500 (Celsius)</code>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="OWTEMPattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li><a href="#showtime">showtime</a></li>
|
||
<li><a href="#IODev">IODev</a></li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="RFXCOM"></a>
|
||
<h3>RFXCOM</h3>
|
||
<ul>
|
||
<table>
|
||
<tr><td>
|
||
<a href="http://www.rfxcom.com">RFXCOM</a> sells RF receivers and transmitters
|
||
for a variety of protocols. The 433.92MHz receivers support many Oregon Scientific weather sensors. <br>
|
||
<br>
|
||
This module supports receiving messages for the USB attached receivers (Order code: 80002, see <a href="http://www.rfxcom.com/receivers.htm">http://www.rfxcom.com/receivers.htm</a>).
|
||
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.<br>
|
||
<br>
|
||
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.<br>
|
||
See <a href="http://www.rfxcom.com/oregon.htm">http://www.rfxcom.com/oregon.htm</a> 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 <a href="http://www.xpl-perl.org.uk/">Perl xPL</a>
|
||
project parsing modules. Thanks to Mark Hindess from the xPL project for writing this code. <br>
|
||
<br>
|
||
Until now the following Oregon Scientific weather sensors have been tested: BTHR918N, THGR810, THR128, THWR288A, WTGR800. <br>
|
||
<br>
|
||
<a name="RFXCOMdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> RFXCOM <device> </code><br>
|
||
</ul>
|
||
<br>
|
||
USB-connected (80002):<br><ul>
|
||
<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.
|
||
For example /dev/ttyUSB0.<br><br>
|
||
Example: <br>
|
||
<code>define RFXCOMUSB RFXCOM /dev/ttyUSB0</code>
|
||
<br>
|
||
</ul>
|
||
<br>
|
||
Network-connected devices:<br><ul>
|
||
<device> specifies the host:port of the device. E.g.
|
||
192.168.1.5:10001
|
||
</ul>
|
||
<br>
|
||
</table>
|
||
</ul>
|
||
|
||
<a name="structure"></a>
|
||
<h3>structure</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="structuredefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> structure <struct_type> <dev1> <dev2> ...</code>
|
||
<br><br>
|
||
|
||
The structure device is used to organize/structure a devices in order to
|
||
set groups of them at once (e.g. switching everything off in a house).<br>
|
||
|
||
The list of attached devices can be modified through the addstruct /
|
||
delstruct commands. Each attached device will get the attribute
|
||
<struct_type>=<name><br> when it is added to the list, and the
|
||
attribute will be deleted if the device is deleted from the structure.
|
||
The structure devices can also be added to a structure, e.g. you can have
|
||
a building consisting of levels which consists of rooms of devices.
|
||
<br>
|
||
Example:<br>
|
||
<ul>
|
||
<li>define kitchen structure room lamp1 lamp2</li>
|
||
<li>addstruct kitchen TYPE=FS20</li>
|
||
<li>delstruct kitchen lamp1</li>
|
||
<li>define house structure building kitchen living</li>
|
||
<li>set house off</li>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="structureset"></a>
|
||
<b>Set</b>
|
||
<ul>
|
||
Every set command is propagated to the attached devices. Exception: if an
|
||
attached devices has an attribute structexcluse, and the attribute value
|
||
matches (as a regexp) the name of the current structure.
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="structureget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
get is not supported through a structure device.
|
||
</ul>
|
||
<br>
|
||
|
||
|
||
<a name="structureattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li>structexclude<br>
|
||
exclude the device from set operations, see the set command above.</li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="WS2000"></a>
|
||
<h3>WS2000</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="WS2000define"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> WS2000 <device_to_connect></code>
|
||
<br><br>
|
||
|
||
Define a WS2000 series raw receiver device sold by ELV. Details see <a
|
||
href="http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=6724">here</a>.
|
||
Unlike 86_FS10.pm it will handle the complete device communication itself
|
||
and doesnt require an external program. For this reason you can now use
|
||
this also on windows.
|
||
<br>
|
||
This Device will be usually connect to a serial port, but you can also
|
||
define a raw network redirector like lantronix XPORT(TM).
|
||
<br>Note: Currently this device does not support a "set" function
|
||
<br><br>
|
||
|
||
Attributes:
|
||
<ul>
|
||
<li><code>rain</code>: factor for calculating amount of rain in ml/count</li>
|
||
<li><code>altitude</code>: height in meters to calculate pressure for NN (not used yet)</li>
|
||
</ul>
|
||
<br>
|
||
Example:
|
||
<ul>
|
||
<code>define WS2000 WS2000 /dev/ttyS0</code><br>
|
||
</ul>
|
||
<ul>
|
||
<code>define WS2000 WS2000 xport:10001</code><br>
|
||
</ul>
|
||
<ul>
|
||
<code>attr WS2000 rain 366</code> : use factor 366 ml/count for rain sensor S2000R<br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="WS2000get"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get <name> list</code>
|
||
<br>
|
||
Gets the last reading of all received sensord
|
||
<br><br>
|
||
<code>get <name> [TH0..TH7, T0..T7, I0..I7, R0..R7, W0..W7, L0..L7, P0..P7,LAST,RAW]</code><br>
|
||
get the last reading for the name sensor, <br>
|
||
<code>LAST</code>: Last received Sensor
|
||
<br><br>
|
||
<code>RAW</code>: original Data from interface
|
||
<br><br>
|
||
</ul>
|
||
|
||
|
||
<a name="WS2000attr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#model">model</a> (ws2000)</li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
<li>rain</li>
|
||
<li>altitude</li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="WS3600"></a>
|
||
<h3>WS3600</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="WS3600define"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> WS3600 </path/to/fetch3600></code>
|
||
<br><br>
|
||
|
||
Define a WS3600 series weather station (Europe Supplies, technotrade, etc; refer to
|
||
<a href="http://www.wetterstationsforum.de/ws3600_master-touch.php">Wetterstationen.info</a>
|
||
(german) for details on this model); the station is queried by means of an external program,
|
||
fetch3600. It talks to the attached weather station (several WS do supply an RS323 interface
|
||
but seem to use some kind of "morse code" on the RTS, CTS wires instead of using propper
|
||
serial communication (RX, TX); it's no use to recode that crap into FHEM when there is a
|
||
stable package of tools to talk to the station available: <a href=http://open3600.fast-mail.nl/tiki-index.php>open3600</a>)
|
||
and delivers the current readings line by line as reading-value-pairs. These are read in
|
||
and translated into more readable names for FHEM by the module WS3600.pm.<br><br>
|
||
As the WS3600 is rather similar to the <a href=http://www.wetterstationsforum.de/ws2300_matrix.php>WS2300</a>
|
||
and open3600 basically is a modified offspring of <a href=http://www.lavrsen.dk/twiki/bin/view/Open2300/WebHome>open2300</a>, by exchanging the /path/to/fetch3600 with /path/to/fetch2300 this module
|
||
should be able to handle the WS2300 was well.<br><br>
|
||
Currently, it is expected that the WS is attached to the local computer and fetch3600 is run
|
||
locally. Basically the executable called needs to supply on stdout an output similar to what
|
||
fetch3600 returns; how to implement a "networked setup" is left as an excercise to the reader.
|
||
<br>
|
||
For the records, this is an output of fetch3600:<pre>
|
||
Date 14-Nov-2009
|
||
Time 10:50:22
|
||
Ti 22.8
|
||
Timin 20.8
|
||
Timax 27.9
|
||
TTimin 10:27
|
||
DTimin 15-10-2009
|
||
TTimax 23:31
|
||
DTimax 20-08-2009
|
||
To 14.2
|
||
Tomin -0.4
|
||
Tomax 35.6
|
||
TTomin 07:03
|
||
DTomin 15-10-2009
|
||
TTomax 16:52
|
||
DTomax 20-08-2009
|
||
DP 9.2
|
||
DPmin -2.2
|
||
DPmax 20.3
|
||
TDPmin 07:03
|
||
DDPmin 15-10-2009
|
||
TDPmax 11:58
|
||
DDPmax 20-08-2009
|
||
RHi 48
|
||
RHimin 32
|
||
RHimax 57
|
||
TRHimin 17:03
|
||
DRHimin 21-10-2009
|
||
TRHimax 22:24
|
||
DRHimax 07-10-2009
|
||
RHo 72
|
||
RHomin 27
|
||
RHomax 96
|
||
TRHomin 16:41
|
||
DRHomin 20-08-2009
|
||
TRHomax 06:28
|
||
DRHomax 02-11-2009
|
||
WS 0.0
|
||
DIRtext WSW
|
||
DIR0 247.5
|
||
DIR1 247.5
|
||
DIR2 247.5
|
||
DIR3 247.5
|
||
DIR4 247.5
|
||
DIR5 247.5
|
||
WC 14.2
|
||
WCmin -0.4
|
||
WCmax 35.6
|
||
TWCmin 07:03
|
||
DWCmin 15-10-2009
|
||
TWCmax 16:52
|
||
DWCmax 20-08-2009
|
||
WSmin 0.0
|
||
WSmax 25.6
|
||
TWSmin 10:44
|
||
DWSmin 14-11-2009
|
||
TWSmax 19:08
|
||
DWSmax 24-09-2009
|
||
R1h 0.00
|
||
R1hmax 24.34
|
||
TR1hmax 22:34
|
||
DR1hmax 07-10-2009
|
||
R24h 0.00
|
||
R24hmax 55.42
|
||
TR24hmax 07:11
|
||
DR24hmax 08-10-2009
|
||
R1w 29.00
|
||
R1wmax 95.83
|
||
TR1wmax 00:00
|
||
DR1wmax 12-10-2009
|
||
R1m 117.58
|
||
R1mmax 117.58
|
||
TR1mmax 00:00
|
||
DR1mmax 01-11-2009
|
||
Rtot 3028.70
|
||
TRtot 03:29
|
||
DRtot 18-09-2005
|
||
RP 992.200
|
||
AP 995.900
|
||
RPmin 970.300
|
||
RPmax 1020.000
|
||
TRPmin 05:25
|
||
DRPmin 04-11-2009
|
||
TRPmax 09:19
|
||
DRPmax 11-09-2009
|
||
Tendency Falling
|
||
Forecast Cloudy</pre>
|
||
|
||
There is no expectation on the readings received from the fetch3600 binary; so, in
|
||
essence, if you have a similar setup (unsupported, attached weather station and a
|
||
means to get it's reading into an output similar to above's), you <em>should be able</em>
|
||
to use WS3600.pm with a custom written script to interface FHEM with your station
|
||
as well. WS3600.pm <em>only recognizes the above readings</em> (and translates these
|
||
into, e. g., <code>Temp-inside</code> for <code>Ti</code> for use within FHEM), other
|
||
lines are silently dropped on the floor.<br><br>
|
||
|
||
fetch3600 is available as binary for the Windows OS as well, <em>but I haven't tested operation
|
||
under that OS, use it at your own risk and you mileage may vary ...</em>
|
||
<br>Note: Currently this device does not support a "set" function nor anything to "get". The
|
||
later would be possible to implement if neccessary, though.
|
||
<br><br>
|
||
|
||
Implementation of WS3600.pm tries to be nice, that is it reads from the pipe only
|
||
non-blocking (== if there is data), so it should be safe even to use it via ssh or
|
||
a netcat-pipe over the Internet, but this, as well, has not been tested yet.
|
||
<br><br>
|
||
|
||
Attributes:
|
||
<ul>
|
||
<li><code>model</code>: <code>WS3600</code> or <code>WS2300</code> (not used for anything, yet)</li>
|
||
</ul>
|
||
<br>
|
||
Example:
|
||
<ul>
|
||
<code>define my3600 W36000 /usr/local/bin/fetch360</code><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="WS3600set"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="WS3600get"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="WS3600attr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#model">model</a> (WS3600, WS2300)</li>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="SISPM"></a>
|
||
<h3>SISPM</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="SISPMdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> SISPM </path/to/sispmctl></code>
|
||
<br><br>
|
||
|
||
<div style="background-color: #ffaaaa;">
|
||
<i><b>PLEASE NOTE:</b> This module is still work in progess; please treat it as such.
|
||
(That is, don't but your central heating on SISPM in a cold winter just yet ;))</i><br><br>
|
||
Further tests should be done regarding the interaction between "set" commands and the sheduled
|
||
status reading. (Testing with FIFOs seems as if it's working without blocking nor interference,
|
||
but that's on a mostly unloaded, fast system.)<br><br>
|
||
When <i>using multiple SIS PMs on one host</i>, sispmctl up to and including V 2.7 has a bug:
|
||
<pre>plug-2:# sispmctl -v -s -d 1 -g all -d 2 -g all
|
||
|
||
SiS PM Control for Linux 2.7
|
||
|
||
(C) 2004, 2005, 2006, 2007, 2008 by Mondrian Nuessle, (C) 2005, 2006 by Andreas Neuper.
|
||
This program is free software.
|
||
[...]
|
||
|
||
Gembird #0 is USB device 013.This device is a 4-socket SiS-PM.
|
||
[...]
|
||
|
||
Gembird #1 is USB device 015.This device is a 4-socket SiS-PM.
|
||
[...]
|
||
|
||
Accessing Gembird #1 USB device 015
|
||
Status of outlet 1: on
|
||
Status of outlet 2: on
|
||
Status of outlet 3: on
|
||
Status of outlet 4: on
|
||
Error performing requested action
|
||
Libusb error string: error sending control message: Invalid argument
|
||
Terminating
|
||
*** glibc detected *** sispmctl: double free or corruption (fasttop): 0x000251e0 ***
|
||
[...]</pre>
|
||
Well, the fix is simple and will be sent upstream, but in case it's not incorporated
|
||
at the time you need it, here it is; it's easy to apply even by hand ;-)
|
||
<pre>
|
||
--- src/main.c-old 2010-01-19 16:56:15.000000000 +0100
|
||
+++ src/main.c 2010-01-19 16:54:56.000000000 +0100
|
||
@@ -441,7 +441,7 @@
|
||
}
|
||
break;
|
||
case 'd': // replace previous (first is default) device by selected one
|
||
- if(udev!=NULL) usb_close (udev);
|
||
+ if(udev!=NULL) { usb_close (udev); udev=NULL; }
|
||
devnum = atoi(optarg);
|
||
if(devnum>=count) devnum=count-1;
|
||
break;
|
||
</pre></div><br>
|
||
|
||
Defines a path to the program "sispmctl", which is used to control (locally attached)
|
||
"Silver Shield Power Manager" devices. Usually these are connected to the local computer
|
||
via USB, more than one "sispm" device per computer is supported. (Please note that, due
|
||
to neglections in their USB driver, AVM's Fritz!Box 7170 (and derivates, like Deutsche
|
||
Telekom's Speedport W901V) <b>is not</b> able to talk to these devices ...)
|
||
|
||
The communication between FHEM and the Power Manager device is done by using the open
|
||
source <a href="http://sispmctl.sourceforge.net/">sispmctl</a> program. Thus, for the
|
||
time being, THIS functionality is only available running FHEM on Linux (or any other platform
|
||
where you can get the sispmctl program compiled and running). On the bright side: by
|
||
interfacing via commandline, it is possible to define multiple SISPM devices, e. g. with
|
||
a wrapper that does execute sispmctl on a remote (Linux) system. And: sispmctl runs happily
|
||
on Marvells SheevaPlug ;) <i>Please note:</i> if you're not running FHEM as root, you most likely
|
||
have to make sispmctl setuid root (<code>chmod 4755 /path/to/sispmctl</code>) or fiddle with
|
||
udev so that the devices of the Power Manager are owned by the user running FHEM.
|
||
|
||
After defining a SISPM device, a first test is done, identifying attached PMs. If this
|
||
succeeds, an internal task is scheduled to read the status every 30 seconds. (Reason
|
||
being that someone else could have switched sockets externally to FHEM.)
|
||
|
||
To actually control any power sockets, you need to define a <a href="#SIS_PMS">SIS_PMS</a>
|
||
device ;) If autocreate is enabled, those should be autocreated for your convenience as
|
||
soon as the first scan took place (30 seconds after the define).
|
||
|
||
Implementation of SISPM.pm tries to be nice, that is it reads from the pipe only
|
||
non-blocking (== if there is data), so it should be safe even to use it via ssh or
|
||
a netcat-pipe over the Internet, but this, as well, has not been tested extensively yet.
|
||
<br><br>
|
||
|
||
Attributes:
|
||
<ul>
|
||
<li><code>model</code>: <code>SISPM</code> (ignored for now)</li>
|
||
</ul>
|
||
<br>
|
||
Example:
|
||
<ul>
|
||
<code>define PMS_Terrarium SISPM /usr/bin/sispmctl</code><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="SISPMset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="SISPMget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="SISPMattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#model">model</a> (SISPM)</li>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="SIS_PMS"></a>
|
||
|
||
<h3>SIS_PMS</h3>
|
||
<ul>
|
||
This module is responsible for handling the actual sockets (power on,
|
||
power off, toggle) on a "Silver Shield Power Manager", see <a href="#SISPM">SISPM</a>
|
||
for how to define access to one (SIS_PMS stands for "Silver Shield Power Manager Socket").
|
||
<br><br>
|
||
|
||
<a name="SIS_PMSdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> SIS_PMS <serial> <socket></code>
|
||
<br><br>
|
||
|
||
To securely distinguish multiple attached Power Manager devices, the
|
||
serial number of those is used. You get these with "sispmctl -s" - or
|
||
just let autocreate define the sockets attached for you.<br>
|
||
|
||
<ul>
|
||
<li><code><serial></code> is the serial number of the Power Manager device, see above.</li>
|
||
<li><code><socket></code> is a number between 1 and 4 (for a 4 socket model)</li>
|
||
</ul>
|
||
<br>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define lamp SIS_PMS 01:02:03:04:05 1</code><br>
|
||
<code>define otherlamp SIS_PMS 01:02:03:04:05 3</code><br>
|
||
<code>define tv SIS_PMS 01:01:38:44:55 1</code>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="SIS_PMSset"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set <name> <value> [<time>]</code>
|
||
<br><br>
|
||
where <code>value</code> is one of:<br>
|
||
<pre>
|
||
off
|
||
on
|
||
toggle
|
||
on-till # Special, see the note
|
||
off-till # Special, see the note
|
||
</pre>
|
||
Examples:
|
||
<ul>
|
||
<code>set lamp on</code><br>
|
||
<code>set lamp1,lamp2,lamp3 on</code><br>
|
||
<code>set lamp1-lamp3 on</code><br>
|
||
<code>set hql_lamp on-till 18:45</code><br>
|
||
</ul>
|
||
<br>
|
||
Notes:
|
||
<ul>
|
||
<li>As an external program is used, a noticeable delay may occur.</li>
|
||
<li>*-till requires an absolute time in the "at" format (HH:MM:SS, HH:MM
|
||
or { <perl code> }, where the perl-code returns a time
|
||
specification).
|
||
If the current time is greater than the specified time, then the
|
||
command is ignored, else an "on" or "off" command, respectively, is
|
||
generated, and for the given time an "off"/"on" command is
|
||
scheduleld via the at command.</li>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="SIS_PMSattributes"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li><br>
|
||
<a name="attrdummy"></a>
|
||
<li>dummy<br>
|
||
Set the device attribute dummy to define devices which should not
|
||
output any signals. Associated notifys will be executed if the signal
|
||
is received. Used e.g. to react to a code from a sender, but it will
|
||
not actually switch if triggered in the web frontend.
|
||
</li><br>
|
||
|
||
<li><a href="#loglevel">loglevel</a></li><br>
|
||
</ul>
|
||
</ul>
|
||
|
||
<a name="IPWE"></a>
|
||
<h3>IPWE</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="IPWEdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> IPWE <hostname> [<delay>]</code>
|
||
<br><br>
|
||
|
||
Define a IPWE network attached weather data receiver device sold by ELV. Details see <a
|
||
href="http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=21508">here</a>.
|
||
It's intended to receive the same sensors as WS300 (8 T/H-Sensors and one kombi sensor),
|
||
but can be accessed via http and telnet.
|
||
<br>
|
||
For unknown reason, my try to use the telnet interface was not working neither with raw sockets
|
||
nor with Net::Telnet module. Therefore i choosed here the "easy" way
|
||
to simple readout the http page and extract all data from the offered table. For this reason this module doesnt
|
||
contain any option to configure this device.
|
||
<br><br><b>Note:</b> You should give your sensors a name within the web interface, once they a received the first time.
|
||
<br>To extract a single sensor simply match for this name or sensor id<br>
|
||
<br>
|
||
|
||
Attributes:
|
||
<ul>
|
||
<li><code>delay</code>: seconds between read accesses(default 300s)</li>
|
||
|
||
</ul>
|
||
<br>
|
||
Example:
|
||
<ul>
|
||
<code>define ipwe IPWE ipwe1 120</code><br>
|
||
</ul>
|
||
<ul>
|
||
<code>attr ipwe delay 600</code> : 10min between readouts<br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="IPWEget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get <name> status</code>
|
||
<br><br>
|
||
Gets actual data from device for sensors with data
|
||
<br><br>
|
||
<code>get <name> <sensorname> </code>
|
||
<br><br>
|
||
will grep output from device for this sensorname
|
||
<br><br>
|
||
</ul>
|
||
|
||
|
||
<a name="IPWEattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#model">model</a> (ipwe)</li>
|
||
<li>delay</li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="USBWX"></a>
|
||
<h3>USBWX</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="USBWXdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> USBWX <serial device></code>
|
||
<br><br>
|
||
|
||
Defines an ELV <a href="http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=24916&flv=1">USB-WDE1</a> weatherstation attached via usb.<br>
|
||
|
||
<br>
|
||
The WDE1 is able to receive the following sensors:<br>
|
||
<ul>
|
||
<li>S 300 TH (implemented and tested)
|
||
<li>S 300 IA (implemented)
|
||
<li>ASH 2200 (implemented)
|
||
<li>PS 50 (implemented)
|
||
<li>KS 200/300 (NOT yet implemented)
|
||
</ul>
|
||
<br>
|
||
Example:<pre>
|
||
define WDE1Device USBWX /dev/ttyUSB0
|
||
</pre>
|
||
</ul>
|
||
|
||
<a name="USBWXset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
<a name="USBWXget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="USBWXattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#model">model</a></li>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="weblink"></a>
|
||
<h3>weblink</h3>
|
||
<ul>
|
||
|
||
<a name="weblinkdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> weblink [link|fileplot|image]
|
||
<argument></code>
|
||
<br><br>
|
||
This is a placeholder used with webpgm2 to be able to integrate links
|
||
into it, and to be able to put more than one gnuplot/SVG picture on one
|
||
page. It has no set or get methods.
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define homepage weblink link http://www.fhem.de</code><br>
|
||
<code>define MyPlot weblink fileplot <logdevice>:<gnuplot-file>:<logfile></code><br>
|
||
<code>define webcam weblink image http://w.x.y.z/current.jpg</code><br>
|
||
</ul>
|
||
<br>
|
||
|
||
Notes:
|
||
<ul>
|
||
<li>Normally you won't have to define fileplot weblinks manually, as
|
||
FHEMWEB makes it easy for you, just plot a logfile (see
|
||
<a href="#logtype">logtype</a>) and convert it to weblink. Now you
|
||
can group these weblinks by putting them into rooms. If you convert
|
||
the current logfile to a weblink, it will always refer to the current
|
||
file, even if its name changes regularly (and not the one you
|
||
originally specified).</li> </ul> </ul>
|
||
|
||
<a name="weblinkset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="weblinkget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="weblinkattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#fixedrange">fixedrange</a></li>
|
||
<li><a href="#plotsize">plotsize</a></li>
|
||
<li><a href="#plotmode">plotmode</a></li>
|
||
<a name="label"></a>
|
||
<li>label<br>
|
||
Colon separated list of values. The values will be used to replace
|
||
<L#> type of strings in the .gplot file, with # beginning at 1
|
||
(<L1>, <L2>, etc.). Each value will be evaluated as a perl
|
||
expression, so you have access e.g. to the $value hash.<br><br>
|
||
|
||
If the plotmode is gnuplot-scroll or SVG, you can also use the min, max,
|
||
avg, cnt, sum, lastv (last value) and lastd (last date) values of the
|
||
individual curves, by accessing the corresponding values from the data
|
||
hash, see the example below:<br>
|
||
|
||
<ul>
|
||
<li>Fixed text for the right and left axis:<br>
|
||
<ul>
|
||
<li>Fhem config:<br>
|
||
attr wl_1 label "Temperature":"Humidity"</li>
|
||
<li>.gplot file entry:<br>
|
||
set ylabel <L1><br>
|
||
set y2label <L2></li>
|
||
</ul></li>
|
||
<li>Title with maximum and current values of the 1st curve (FileLog)
|
||
<ul>
|
||
<li>Fhem config:<br>
|
||
attr wl_1 label "Max $data{max1}, Current $data{currval1}"</li>
|
||
<li>.gplot file entry:<br>
|
||
set title <L1><br>
|
||
</ul></li>
|
||
</ul>
|
||
</li>
|
||
<a name="title"></a>
|
||
<li>title<br>
|
||
A special form of label (see above), which replaces the string <TL>
|
||
in the .gplot file. It defaults to the filename of the logfile.
|
||
</li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="FHEMWEB"></a>
|
||
<h3>FHEMWEB</h3>
|
||
<ul>
|
||
FHEMWEB is the builtin web-frontend (webpgm2). It implements a simple web
|
||
server, so no additional program is needed. However, if HTTPS is desired,
|
||
FHEMWEB must be configured to run behind a webserver (e.g. apache) which
|
||
translates the HTTPS from the outside to HTTP for FHEMWEB.<br> <br>
|
||
|
||
<a name="FHEMWEBdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> FHEMWEB <tcp-portnr> [global]</code>
|
||
<br><br>
|
||
Enable the webfrontend on port <tcp-portnr>. If global is specified,
|
||
then requests from all interfaces (not only localhost / 127.0.0.1) are
|
||
serviced.
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="FHEMWEBset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="FHEMWEBget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="FHEMWEBattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<a name="webname"></a>
|
||
<li>webname<br/>
|
||
Path after the http://hostname:port/ specification. Defaults to fhem,
|
||
i.e the default http address is http://localhost:8083/fhem
|
||
</li><br>
|
||
|
||
<a name="refresh"></a>
|
||
<li>refresh<br/>
|
||
If set, a http-equiv="refresh" entry will be genererated with the given
|
||
argument (i.e. the browser will reload the page after the given
|
||
seconds).
|
||
</li><br>
|
||
|
||
<a name="plotmode"></a>
|
||
<li>plotmode<br/>
|
||
Specifies how to generate the plots:
|
||
<ul>
|
||
<li>gnuplot<br>
|
||
Call the gnuplot script with each logfile. The filename
|
||
specification of the <a href="#FileLog">FileLog</a> device will
|
||
determine what is in the plot. The data is converted into an
|
||
image on the backend with gnuplot.</li>
|
||
<li>gnuplot-scroll<br>
|
||
Fhemweb will offer zoom and scroll buttons in order to navigate
|
||
in the current logfile, i.e. you can select just a part of the
|
||
data to be displayed. The more data is contained in a single
|
||
logfile, the easier you can navigate. The recommendation is to
|
||
store the data for a whole year in one logfile. The data is
|
||
converted into an image on the backend with gnuplot.</li>
|
||
<li>SVG<br>
|
||
The same scrolling as with gnuplot scroll, but the data is sent
|
||
as an SVG script to the frontend, which will compute
|
||
the image: no need for gnuplot on the backend.
|
||
This is the default. Note: SVG is not supported on the Android
|
||
platform and the Internet Explorer needs a plugin (as of
|
||
2010-05-15)
|
||
</li>
|
||
</ul>
|
||
See also the attribute fixedrange.
|
||
Note: for gnuplot & gnuplot-scroll mode the gnuplot output is
|
||
redirected to the file gnuplot.err in the /tmp directory
|
||
</li><br>
|
||
|
||
<a name="plotsize"></a>
|
||
<li>plotsize<br/>
|
||
the default size of the plot, in pixels, separated by comma:
|
||
width,height. You can set individual sizes by setting the plotsize of
|
||
the weblink. Default is 800,160 for desktop, and 480,160 for
|
||
smallscreen.
|
||
</li><br>
|
||
|
||
<a name="fixedrange"></a>
|
||
<li>fixedrange<br/>
|
||
Can be applied to weblink devices (FHEMWEB).<br/>
|
||
Contains two time specs in the form YYYY-MM-DD separated by a space.
|
||
In plotmode gnuplot-scroll or SVG the given time-range will be used,
|
||
and no scrolling for this weblinks will be possible. Needed e.g. for
|
||
looking at last-years data without scrolling.
|
||
</li><br>
|
||
|
||
<a name="smallscreen"></a>
|
||
<li>smallscreen<br/>
|
||
Optimize for small screen size, e.g. smartphones.
|
||
Note: The default configuration installed with make install-pgm2
|
||
installs 2 FHEMWEB instances: port 8083 for desktop browsers and
|
||
port 8084 for smallscreen browsers. <b>Note:</b>After viewing the
|
||
site on the iPhone in Safari, try to add it to the home-screen.
|
||
</li><br>
|
||
|
||
</li></ul>
|
||
|
||
</ul>
|
||
|
||
</ul>
|
||
|
||
|
||
|
||
<a name="at"></a>
|
||
<h3>at</h3>
|
||
<ul>
|
||
|
||
Start an arbitrary fhem.pl command at a later time.<br>
|
||
<br>
|
||
|
||
<a name="atdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> at <timespec> <command></code><br>
|
||
<br>
|
||
<code><timespec></code> format: [+][*{N}]<timedet><br>
|
||
<ul>
|
||
The optional <code>+</code> indicates that the specification is
|
||
<i>relative</i>(i.e. it will be added to the current time).<br>
|
||
The optional <code>*</code> indicates that the command should be
|
||
executed <i>repeatedly</i>.<br>
|
||
The optional <code>{N}</code> after the * indicates,that the command
|
||
should be repeated <i>N-times</i> only.<br>
|
||
<timedet> is either HH:MM, HH:MM:SS or {perlfunc()}, where perlfunc
|
||
must return a HH:MM or HH:MM:SS date.
|
||
</ul>
|
||
<br>
|
||
|
||
Examples:
|
||
<PRE>
|
||
# absolute ones:
|
||
define a1 at 17:00:00 set lamp on # fhem command
|
||
define a2 at 17:00:00 { Log 1, "Teatime" } # Perl command
|
||
define a3 at 17:00:00 "/bin/echo "Teatime" > /dev/console" # shell command
|
||
define a4 at *17:00:00 set lamp on # every day
|
||
|
||
# relative ones
|
||
define a5 at +00:00:10 set lamp on # switch the lamp on in 10 seconds
|
||
define a6 at +00:00:02 set lamp on-for-timer 1 # Blink once in 2 seconds
|
||
define a7 at +*{3}00:00:02 set lamp on-for-timer 1 # Blink 3 times
|
||
|
||
# Blink 3 times if the piri sends a command
|
||
define n1 notify piri:on.* define a8 at +*{3}00:00:02 set lamp on-for-timer 1
|
||
|
||
# Switch the lamp on from sunset to 11 PM
|
||
define a9 at +*{sunset_rel()} set lamp on
|
||
define a10 at *23:00:00 set lamp off
|
||
|
||
# More elegant version, works for sunset > 23:00 too
|
||
define a11 at +*{sunset_rel()} set lamp on-till 23:00
|
||
|
||
# Only do this on weekend
|
||
define a12 at +*{sunset_rel()} { fhem("set lamp on-till 23:00") if($we) }
|
||
|
||
# Switch lamp1 and lamp2 on from 7:00 till 10 minutes after sunrise
|
||
define a13 at *07:00 set lamp1,lamp2 on-till {sunrise(+600)}
|
||
|
||
# Switch the lamp off 2 minutes after sunrise each day
|
||
define a14 at +{sunrise(+120)} set lamp on
|
||
|
||
# Switch lamp1 on at sunset, not before 18:00 and not after 21:00
|
||
define a15 at *{sunset(0,"18:00","21:00")} set lamp1 on
|
||
|
||
</PRE>
|
||
|
||
Notes:<br>
|
||
<ul>
|
||
<li>if no <code>*</code> is specified, then a command will be executed
|
||
only once, and then the <code>at</code> entry will be deleted. In
|
||
this case the command will be saved to the statefile (as it
|
||
considered volatile, i.e. entered by cronjob) and not to the
|
||
configfile (see the <a href="#save">save</a> command.)
|
||
</li>
|
||
|
||
<li>if the current time is greater than the time specified, then the
|
||
command will be executed tomorrow.</li>
|
||
|
||
<li>For even more complex date handling you either have to call fhem from
|
||
cron or filter the date in a perl expression, see the last example and
|
||
the section <a href="#perl">Perl special</a>.
|
||
</li>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
|
||
<a name="atset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="atget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="atattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<a name="disable"></a>
|
||
<li>disable<br>
|
||
Can be applied to at/watchdog/notify/FileLog devices.<br>
|
||
Disables the corresponding at/notify or FileLog device. Note:
|
||
If applied to an <a href="#at">at</a>, the command will not be executed,
|
||
but the next time will be computed.</li><br>
|
||
|
||
<a name="skip_next"></a>
|
||
<li>skip_next<br>
|
||
Used for at commands: skip the execution of the command the next
|
||
time.</li><br>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="autocreate"></a>
|
||
<h3>autocreate</h3>
|
||
<ul>
|
||
|
||
Automatically create not yet defined fhem devices upon reception of a message
|
||
generated by this device. Note: devices which are polled (like the EMEM/EMWZ
|
||
accessed through the EM1010PC) will NOT be automatically created.
|
||
|
||
<br>
|
||
|
||
<a name="autocreatedefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> autocreate</code><br>
|
||
<br>
|
||
<ul>
|
||
It makes no sense to create more than one instance of this module.
|
||
By defining an instance, the global attribute <a href=
|
||
"#autoload_undefined_devices">autoload_undefined_devices</a>
|
||
is set, so that modules for unknnown devices are automatically loaded.
|
||
The autocreate module intercepts the UNDEFINED event generated by each
|
||
module, creates a device and optionally also FileLog and weblink
|
||
entries.<br>
|
||
<b>Note:</b>devices will be created with a unique name, which contains
|
||
the type and a unique id for this type. When <a href="#rename">renaming
|
||
</a> the device, the automatically created filelog and weblink devices
|
||
will also be renamed.
|
||
|
||
</ul>
|
||
<br>
|
||
|
||
Example:<PRE>
|
||
define autocreate autocreate
|
||
attr autocreate autosave
|
||
attr autocreate device_room %TYPE
|
||
attr autocreate filelog test2/log/%NAME-%Y.log
|
||
attr autocreate weblink
|
||
attr autocreate weblink_room Plots
|
||
</PRE>
|
||
</ul>
|
||
|
||
|
||
<a name="autocreateset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="autocreateget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="autocreateattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<a name="autosave"></a>
|
||
<li>autosave<br>
|
||
After creating a device, automatically save the config file with the
|
||
command <a href="#save">save</a> command.</li><br>
|
||
|
||
<a name="device_room"></a>
|
||
<li>device_room<br>
|
||
"Put" the newly created device in this room. The name can contain the
|
||
wildcards %TYPE and %NAME, see the example above.</li><br>
|
||
|
||
<a name="filelog"></a>
|
||
<li>filelog<br>
|
||
Create a filelog associated with the device. The filename can contain
|
||
the wildcards %TYPE and %NAME, see the example above. The filelog will
|
||
be "put" in the same room as the device.</li><br>
|
||
|
||
<a name="weblink"></a>
|
||
<li>weblink<br>
|
||
Create a weblinkn associated with the device/filelog.</li><br>
|
||
|
||
<a name="weblink_room"></a>
|
||
<li>weblink_room<br>
|
||
"Put" the newly weblink in this room. The name can contain the
|
||
wildcards %TYPE and %NAME, see the example above.</li><br>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="holiday"></a>
|
||
<h3>holiday</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="holidaydefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> holiday</code>
|
||
<br><br>
|
||
Define a set of holidays. The module will try to open the file
|
||
<name>.holiday in the <a href="#modpath">modpath</a>/FHEM directory.
|
||
If an entry in the holiday file matches the current day, then the STATE of
|
||
this holiday instance displayed in the <a href="#list">list</a> command
|
||
will be set to the holiday, else the state is set to the text none. Most
|
||
probably you'll want to query this value in some perl script: see $value in
|
||
the <a href="#perl">perl</a> section or the global attribute <a
|
||
href="#holiday2we"> holiday2we</a>.<br>
|
||
The file will be reread once every night, to compute the value for the
|
||
current day, and by each get command (see below).<br>
|
||
<br>
|
||
|
||
Holiday file definition:<br>
|
||
The file may contain comments (beginning with #) or empty lines.
|
||
Significant lines begin with a number (type) and contain some space
|
||
separated words, depending on the type. The different types are:<br>
|
||
<ul>
|
||
<li>1<br>
|
||
Exact date. Arguments: <MM-DD> <holiday-name><br>
|
||
Exampe: 1 12-24 Christmas
|
||
</li>
|
||
<li>2<br>
|
||
Easter-dependent date. Arguments: <day-offset>
|
||
<holiday-name>.
|
||
The offset is counted from Easter-Sunday. Note: the perl module
|
||
DateTime::Event::Easter must be installed to use this type of
|
||
holiday.<br>
|
||
Exampe: 2 1 Easter-Monday
|
||
</li>
|
||
<li>3<br>
|
||
Month dependent date. Arguments: <nth> <weekday>
|
||
<month <holiday-name>.<br>
|
||
Examples:<br>
|
||
<ul>
|
||
3 1 Mon 05 First Monday In May<br>
|
||
3 2 Mon 05 Second Monday In May<br>
|
||
3 -1 Mon 05 Last Monday In May<br>
|
||
3 0 Mon 05 Each Monday In May<br>
|
||
</ul>
|
||
</li>
|
||
<li>4<br>
|
||
Interval. Arguments: <MM-DD> <MM-DD> <holiday-name>
|
||
.<br>
|
||
Example:<br>
|
||
<ul>
|
||
4 01-06 31-06 Summer holiday<br>
|
||
</ul>
|
||
</li>
|
||
<li>5<br>
|
||
Date relative, weekday fixed holiday. Arguments: <nth>
|
||
<weekday> <month> <day> < holiday-name><br>
|
||
Note that while +0 or -0 as offsets are not forbidden, their behaviour
|
||
is undefined in the sense that it might change without notice.<br>
|
||
Examples:<br>
|
||
<ul>
|
||
5 -1 Wed 11 23 Buss und Bettag (first Wednesday before Nov, 23rd)<br>
|
||
5 1 Mon 01 31 First Monday after Jan, 31st (1st Monday in February)<br>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
See also he.holiday in the contrib directory for official holidays in the
|
||
german country of Hessen, and by.holiday for the Bavarian definition.
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="holidayset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="holidayget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get <name> <MM-DD></code>
|
||
<br><br>
|
||
Return the holiday name of the specified date or the text none.
|
||
<br><br>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="holidayattr"></a>
|
||
<b>Attributes</b><ul>N/A</ul><br>
|
||
|
||
</ul>
|
||
|
||
<a name="notify"></a>
|
||
<h3>notify</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="notifydefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> notify <pattern> <command></code>
|
||
<br><br>
|
||
Execute a command when received an event for the <a
|
||
|
||
href="#define">definition</a> <code><pattern></code>. If
|
||
<command> is enclosed in {}, then it is a perl expression, if it is
|
||
enclosed in "", then it is a shell command, else it is a "plain" fhem.pl
|
||
command (chain). See the <a href="#trigger">trigger</a> command for
|
||
testing it.
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define b3lampV1 notify btn3 set lamp %</code><br>
|
||
<code>define b3lampV2 notify btn3 { fhem "set lamp %" }</code><br>
|
||
<code>define b3lampV3 notify btn3 "/usr/local/bin/setlamp "%""</code><br>
|
||
<code>define b3lampV3 notify btn3 set lamp1 %;;set lamp2 %</code><br>
|
||
<code>define wzMessLg notify wz:measured.* "/usr/local/bin/logfht @ "%""</code><br>
|
||
<!-- <code>define LogHToDB notify .*H:.* {DbLog("@","%")}</code><br> -->
|
||
<code>define LogUndef notify global:UNDEFINED.* "send-me-mail.sh "%""</code><br>
|
||
</ul>
|
||
<br>
|
||
|
||
Notes:
|
||
<ul>
|
||
<li>The character <code>%</code> will be replaced with the received event,
|
||
e.g. with <code>on</code> or <code>off</code> or <code>measured-temp: 21.7
|
||
(Celsius)</code><br> It is advisable to put the <code>%</code> into double
|
||
quotes, else the shell may get a syntax error.</li>
|
||
|
||
<li>The character <code>@</code> will be replaced with the device
|
||
name.</li>
|
||
|
||
<li>To use % or @ in the text itself, use the double mode (%% or @@).</li>
|
||
|
||
<li>Instead of <code>%</code> and <code>@</code>, the parameters
|
||
<code>%EVENT</code> (same as <code>%</code>), <code>%NAME</code>
|
||
(same as <code>@</code>) and <code>%TYPE</code> (contains the device
|
||
type, e.g. <code>FHT</code>) can be used. A single <code>%</code>
|
||
looses its special meaning if any of these parameters appears in the
|
||
definition.</li>
|
||
|
||
<li><code><pattern></code> may also be a compound of
|
||
<code>definition:event</code> to filter for events.</li>
|
||
|
||
<li><code><pattern></code> must completely (!)
|
||
match either the device name, or the compound of the device name and the
|
||
event. The event is either the string you see in the <a
|
||
href="#list">list</a> output in paranthesis after the device name, or the
|
||
string you see when you do a detailed list of the device.</li>
|
||
|
||
<li>To use database logging, copy the file contrib/91_DbLog.pm into your
|
||
modules directory, and change the $dbconn parameter in the file.</li>
|
||
|
||
<li>Following special events will be generated for the device "global"
|
||
<ul>
|
||
<li>INITIALIZED after initialization is finished.
|
||
<li>DEFINED <devname> after a device is defined.
|
||
<li>DELETED <devname> after a device was deleted.
|
||
<li>RENAMED <old> <new> after a device was renamed.
|
||
<li>UNDEFINED <defspec> upon reception of a message for an
|
||
undefined device.
|
||
</ul>
|
||
|
||
<li>Notify can be used to store macros for manual execution. Use the <a
|
||
href="#trigger">trigger</a> command to execute the macro.
|
||
E.g.<br>
|
||
<code>fhem> define MyMacro notify MyMacro { Log 1, "Hello"}</code><br>
|
||
<code>fhem> trigger MyMacro</pre></code><br>
|
||
|
||
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
|
||
<a name="notifyset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="notifyget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="notifyattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#disable">disable</a></li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="watchdog"></a>
|
||
<h3>watchdog</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="watchdogdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> watchdog <regexp1> <timespec> <regexp2> <command></code><br>
|
||
<br>
|
||
Start an arbitrary fhem.pl command if after <timespec> receiving an
|
||
event matching <regexp1> no event matching <regexp2> is
|
||
received.<br>
|
||
The syntax for <regexp1> and <regexp2> is the same as the
|
||
regexp for <a href="#notify">notify</a>.<br>
|
||
<timespec> is HH:MM[:SS]<br>
|
||
<command> is a usual fhem command like used int the <a
|
||
href="#at">at</a> or <a href="#notify">notify</a>
|
||
<br><br>
|
||
|
||
Examples:
|
||
<pre>
|
||
# "Reset" the FHT80 if we do not receive any message for 15 Minutes
|
||
define w watchdog FHT80 00:15:00 SAME set FHT80 refreshvalues
|
||
# Shout if the HMS100-FIT is not alive
|
||
define w watchdog HMS100-FIT 01:00:00 SAME "alarm-fit.sh"
|
||
</pre>
|
||
|
||
Notes:<br>
|
||
<ul>
|
||
<li>if <regexp1> is . (dot), then activate the watchdog at
|
||
definition time. Else it will be activated when the first matching event
|
||
is received.</li>
|
||
|
||
<li>if <regexp2> is SAME, then it will be the same as the first
|
||
regexp, and it will be reactivated, when it is received. This is probably
|
||
the normal operation.</li>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="watchdogset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="watchdogget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="watchdogattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#disable">disable</a></li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="DbLog"></a>
|
||
<h3>DbLog</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="DbLogdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> DbLog <configfilename> <regexp></code>
|
||
<br><br>
|
||
|
||
Log events to a database. The database connection is defined in
|
||
<code><configfilename></code> (see sample configuration file
|
||
<code>db.conf</code>). The configuration is stored in a separate file
|
||
to avoid storing the password in the main configuration file and to have it
|
||
visible in the output of the <a href="#list">list</a> command.
|
||
<br><br>
|
||
|
||
You must have <code>93_DbLog.pm</code> in the <code>FHEM</code> subdirectory
|
||
to make this work. Additionally, the modules <code>DBI</code> and
|
||
<code>DBD::<dbtype></code> need to be installed (use
|
||
<code>cpan -i <module></code> if your distribution does not have it).
|
||
<br><br>
|
||
<code><regexp></code> is the same as in <a href="#FileLog">FileLog</a>.
|
||
<br><br>
|
||
Sample code to create a MySQL database is in <code>fhemdb_create.sql</code>.
|
||
The database contains two tables: <code>current</code> and
|
||
<code>history</code>. The latter contains all events whereas the former only
|
||
contains the last event for any given reading and device.
|
||
The columns have the following meaning:
|
||
<ol>
|
||
<li>TIMESTAMP: timestamp of event, e.g. <code>2007-12-30 21:45:22</code></li>
|
||
<li>DEVICE: device name, e.g. <code>Wetterstation</code></li>
|
||
<li>TYPE: device type, e.g. <code>KS300</code></li>
|
||
<li>EVENT: event specification as full string,
|
||
e.g. <code>humidity: 71 (%)</code></li>
|
||
<li>READING: name of reading extracted from event,
|
||
e.g. <code>humidity</code></li>
|
||
<li>VALUE: actual reading extracted from event,
|
||
e.g. <code>71</code></li>
|
||
<li>UNIT: unit extracted from event, e.g. <code>%</code></li>
|
||
</ol>
|
||
The content of VALUE is optimized for automated post-processing, e.g.
|
||
<code>yes</code> is translated to <code>1</code>.
|
||
<br><br>
|
||
The current values can be retrieved by means of the perl script
|
||
<code>fhemdb_get.pl</code>. Its output is adapted to what a
|
||
<a href="www.cacti.net">Cacti</a> data input method expects.
|
||
Call <code>fhemdb_get.pl</code> without parameters to see the usage
|
||
information.
|
||
<br><br>
|
||
Examples:
|
||
<ul>
|
||
<code># log everything to database</code><br>
|
||
<code>define logdb DbLog /etc/fhem/db.conf .*:.*</code>
|
||
</ul>
|
||
</ul>
|
||
|
||
|
||
<a name="DbLogset"></a>
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<a name="DbLogget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="DbLogattr"></a>
|
||
<b>Attributes</b> <ul>N/A</ul><br>
|
||
|
||
</ul>
|
||
|
||
<a name="FileLog"></a>
|
||
<h3>FileLog</h3>
|
||
<ul>
|
||
<br>
|
||
|
||
<a name="FileLogdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> FileLog <filename> <regexp></code>
|
||
<br><br>
|
||
|
||
Log events to <code><filename></code>. The log format is
|
||
<pre>
|
||
YYYY:MM:DD_HH:MM:SS <device> <event></pre>
|
||
The regexp will be checked against the (complete!) device name
|
||
or against the (complete!) devicename:event combination.
|
||
<br>
|
||
<code><filename></code> may contain one or more of the following
|
||
wildcards (a subset of the Unix date command arguments):
|
||
<ul>
|
||
<li><code>%d</code> day of month (01..31)</li>
|
||
<li><code>%m</code> month (01..12)</li>
|
||
<li><code>%Y</code> year (1970...)
|
||
<li><code>%w</code> day of week (0..6); 0 represents Sunday
|
||
<li><code>%j</code> day of year (001..366)
|
||
<li><code>%U</code> week number of year with Sunday as first day of week (00..53)
|
||
<li><code>%V</code> week number of year with Monday as first day of week (01..53)
|
||
</ul>
|
||
|
||
Examples:
|
||
<ul>
|
||
<code>define lamplog FileLog /var/tmp/lamp.log lamp</code><br>
|
||
<code>define wzlog FileLog /var/tmp/wz-%Y-%U.log
|
||
wz:(measured-temp|actuator).*</code><br>
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="FileLogset"></a>
|
||
<b>Set </b>
|
||
<ul>
|
||
<code>set <name> reopen</code><br>
|
||
|
||
Used to reopen a FileLog after making some manual changes to the logfile.
|
||
<br>
|
||
</ul>
|
||
|
||
|
||
<a name="FileLogget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get <name> <infile> <outfile> <from>
|
||
<to> <column_spec> </code>
|
||
<br><br>
|
||
Read data from the logfile.
|
||
<ul>
|
||
<li><infile><br>
|
||
Name of the logfile to grep. "-" is the current logfile, or you can
|
||
specify an older file (or a file from the archive).</li>
|
||
<li><outfile><br>
|
||
If it is "-", you get the data back on the current connection, else it
|
||
is the prefix for the output file. If more than one file is specified,
|
||
the data is separated by a comment line for "-", else it is written in
|
||
separate files, numerated from 0.
|
||
</li>
|
||
<li><from> <to><br>
|
||
Used to grep the data. The elements should correspond to the
|
||
timeformat or be an initial substring of it.</li>
|
||
<li><column_spec><br>
|
||
For each column_spec return a set of data in a separate file or
|
||
separated by a comment line on the current connection.<br>
|
||
Syntax: <col>:<regexp>:<default>:<fn><br>
|
||
<ul>
|
||
<li><col>
|
||
The column number to return, starting at 1 with the date.
|
||
If the column is enclosed in double quotes, then it is a fix text,
|
||
not a column nuber.</li>
|
||
<li><regexp>
|
||
If present, return only lines containing the regexp. Case sensitive.
|
||
</li>
|
||
<li><default><br>
|
||
If no values were found and the default value is set, then return
|
||
one line containing the from value and this default. We need this
|
||
feature as gnuplot aborts if a dataset has no value at all.
|
||
</li>
|
||
<li><fn>
|
||
One of the following:
|
||
<ul>
|
||
<li>int<br>
|
||
Extract the integer at the beginning og the string. Used e.g.
|
||
for constructs like 10%</li>
|
||
<li>delta-h or delta-d<br>
|
||
Return the delta of the values for a given hour or a given day.
|
||
Used if the column contains a counter, as is the case for the
|
||
KS300 rain column.</li>
|
||
<li>everything else<br>
|
||
The string is evaluated as a perl expression. @fld is the
|
||
current line splitted by spaces. Note: The string/perl
|
||
expression cannot contain spaces, as the part after the space
|
||
will be considered as the next column_spec.</li>
|
||
</ul></li>
|
||
</ul></li>
|
||
</ul>
|
||
<br><br>
|
||
Example:
|
||
<pre>get outlog out-2008.log - 2008-01-01 2008-01-08 4:IR:int: 9:IR::</pre>
|
||
<br><br>
|
||
</ul>
|
||
|
||
<a name="FileLogattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<a name="archivedir"></a>
|
||
<a name="archivecmd"></a>
|
||
<a name="nrarchive"></a>
|
||
<li>archivecmd / archivedir / nrarchive<br>
|
||
When a new FileLog file is opened, the FileLog archiver wil be called.
|
||
This happens only, if the name of the logfile has changed (due to
|
||
time-specific wildcards, see the <a href="#FileLog">FileLog</a>
|
||
section), and there is a new entry to be written into the file.
|
||
<br>
|
||
|
||
If the attribute archivecmd is specified, then it will be started as a
|
||
shell command (no enclosing " is needed), and each % in the command
|
||
will be replaced with the name of the old logfile.<br>
|
||
|
||
If this attribute is not set, but nrarchive and/or archivecmd is set,
|
||
then all superfluous logfiles will be moved to archivedir (or deleted if
|
||
archivedir is not set).</li><br>
|
||
|
||
<li><a href="#disable">disable</a></li>
|
||
|
||
<a name="logtype"></a>
|
||
<li>logtype<br>
|
||
Used by the pgm2 webfrontend to offer gnuplot/SVG images made from the
|
||
logs. The string is made up of tokens separated by comma (,), each
|
||
token specifies a different gnuplot program. The token may contain a
|
||
colon (:), the part before the colon defines the name of the program,
|
||
the part after is the string displayed in the web frontend. Currently
|
||
following types of gnuplot programs are implemented:<br>
|
||
<ul>
|
||
<li>fs20<br>
|
||
Plots on as 1 and off as 0. The corresponding filelog definition
|
||
for the device fs20dev is:<br>
|
||
define FileLog fslog fs20dev /var/log/fs20dev-%Y-%U.log
|
||
</li>
|
||
<li>fht<br>
|
||
Plots the measured-temp/desired-temp/actuator lines. The
|
||
corresponding filelog definitions (for the FHT device named
|
||
fht1) looks like:<br>
|
||
<code>define fhtlog1 FileLog fht1:.*(temp|actuator).* /var/log/fht1-%Y-%U.log</code>
|
||
|
||
</li>
|
||
<li>ks300<br>
|
||
Plots the temperature and rain (per hour and per day) of a
|
||
ks300. The corresponding filelog definitions (for the KS300
|
||
device named ks300) looks like:<br>
|
||
define FileLog ks300log ks300:.*H:.*
|
||
/var/log/ks300-%Y-%U.log
|
||
</li>
|
||
<li>ks300_2<br>
|
||
Plots the humidity and wind values of a
|
||
ks300. The corresponding filelog definition is the same as
|
||
above, both programs evaluate the same log.
|
||
</li>
|
||
<li>text<br>
|
||
Shows the logfile as it is (plain text). Not gnuplot definition
|
||
is needed.
|
||
</li>
|
||
</ul>
|
||
Example:<br>
|
||
attr ks300log1 logtype ks300_1:Temp/Rain,ks300_2:Hum/Wind,text:Raw-data
|
||
</li><br>
|
||
|
||
|
||
|
||
</ul>
|
||
<br>
|
||
</ul>
|
||
|
||
<a name="dummy"></a>
|
||
<h3>dummy</h3>
|
||
<ul>
|
||
|
||
Define a dummy. A dummy can take via <a href="#set">set</a> any values.
|
||
Used for programming.
|
||
<br><br>
|
||
|
||
<a name="dummydefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> dummy</code>
|
||
<br><br>
|
||
|
||
Example:
|
||
<ul>
|
||
<code>define myvar dummy</code><br>
|
||
<code>set myvar 7</code><br>
|
||
</ul>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="dummyset"></a>
|
||
<b>Set</b>
|
||
<ul>
|
||
<code>set <name> <value></code><br>
|
||
Set any value.
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="dummyget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="dummyattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#loglevel">loglevel</a></li>
|
||
</ul>
|
||
<br>
|
||
|
||
</ul>
|
||
|
||
<a name="SUNRISE_EL"></a>
|
||
<h3>SUNRISE_EL</h3>
|
||
<ul>
|
||
This module is used to define the functions<pre>
|
||
sunrise, sunset,
|
||
sunrise_rel, sunset_rel
|
||
sunrise_abs, sunset_abs
|
||
isday</pre>
|
||
perl functions, to be used in <a href="#at">at</a> or FS20 on-till commands.<br>
|
||
First you should edit SUNRISE_EL.pm, and set long and lat to the exact longitude
|
||
and latitude values (see e.g. maps.google.com for the exact values, which
|
||
should be in the form of a floating point value). The default value is
|
||
Frankfurt am Main, Germany.
|
||
<br><br>
|
||
The default altitude ($altit in SUNRISE_EL.pm) defines the sunrise/sunset
|
||
for Civil twilight (i.e. one can no longer read outside without artificial
|
||
illumination), which differs from sunrise/sunset times found on different
|
||
websites. See perldoc "DateTime::Event::Sunrise" for alternatives.
|
||
<br><br>
|
||
|
||
sunrise()/sunset() returns the absolute time of the next sunrise/sunset,
|
||
adding 24 hours if the next event is tomorrow, to use it in the timespec of
|
||
an at device or for the on-till command for FS20 devices.<br>
|
||
|
||
sunrise_rel()/sunset_rel() returns the relative time to the next
|
||
sunrise/sunset. <br>
|
||
sunrise_abs()/sunset_abs() return the absolute time of the corresponding
|
||
event today (no 24 hours added).<br>
|
||
All functions take up to three arguments:<br>
|
||
<ul>
|
||
<li>The first specifies an offset (in seconds), which will be added to the
|
||
event.
|
||
<li>The second and third specify min and max values (format: "HH:MM").
|
||
</ul>
|
||
<br>
|
||
|
||
isday() can be used in some notify or at commands to check if the sun is up or
|
||
down.
|
||
<br><br>
|
||
|
||
<b>Define</b> <ul>N/A</ul><br>
|
||
|
||
<b>Set</b> <ul>N/A</ul><br>
|
||
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<b>Attributes</b> <ul>N/A</ul><br>
|
||
</ul>
|
||
|
||
<a name="FHEMRENDERER"></a>
|
||
<h3>FHEMRENDERER</h3>
|
||
<ul>
|
||
The FHEMRENDERER module is intended to render (draw) graphics based on the FHEM Log-Files.
|
||
This can be done either based on a timer (used in the module) or based on a direct call of GET.
|
||
The rendered graphics will be stored in a pre-defined directory with a predefined prefix of the files. The renderer can also work in a multi-process mode,
|
||
which doesn't block the main FHEM-Loop.
|
||
<br> <br>
|
||
|
||
<a name="FHEMRENDERERdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<code>define <name> FHEMRENDERER [global]</code>
|
||
<br><br>
|
||
This defines a new "device", that is of type FHEMRENDERER. The option 'global' can be used if needed for sorting reasons.
|
||
Otherwise this option has no real meaning for FHEMRENDERER.<br>
|
||
<br>
|
||
As a side-effect of defining this "device" the following attributes will be set for this "device":<br>
|
||
plotmode gnuplot <br>
|
||
plotsize 800,200 <br>
|
||
refresh 00:10:00 <br>
|
||
room Unsorted <br>
|
||
status off <br>
|
||
tmpfile /tmp/ <br>
|
||
multiprocess off <br>
|
||
<br>
|
||
NOTE: The Logfile will report (with LogLevel 2) that the FHEMRENDERER has been defined.
|
||
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="FHEMRENDERERset"></a>
|
||
<b>Set</b>
|
||
<ul>
|
||
<code>set <name> <value></code><br>
|
||
Set either on or off.<br>
|
||
<br>
|
||
This switches the timer-based rendering on/off. The attribute 'status' will be modified accordingly.<br>
|
||
NOTE: only WebLink based graphics will be rendered.
|
||
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="FHEMRENDERERget"></a>
|
||
<b>Get</b>
|
||
<ul>
|
||
<code>get <name> <[[file-name] device type logfile [pos=zoom=XX&off=YY]]></code><br>
|
||
<br>
|
||
The get function supports different sets of arguments: <br>
|
||
Arguments:<br />
|
||
NONE: all WebLink based FilePlots will be rerendered<br>
|
||
The resulting filename will be '<attr-tmpfile><weblinkname>.png'<br>
|
||
THREE: device type logfile <br>
|
||
In this case only one specific graphic will be rendered:<br>
|
||
A graphic will be rendered for 'device', where device is a FileLog, based on the type 'type' based on the given 'logfile'<br>
|
||
The resulting filename will be 'attr-tmpfile logfile.png'<br>
|
||
FOUR: file-name device type logfile<br>
|
||
In this case only one specific graphic will be rendered:<br>
|
||
A graphic will be rendered for 'device', where device is a FileLog, based on the type 'type' based on the given 'logfile'<br>
|
||
The resulting filename will be 'attr-tmpfile file-name.png'<br>
|
||
FIVE: file-name device type logfile pos=zoom=XX&off=YYY <br>
|
||
In this case only one specific graphic will be rendered assuming that plotmode is 'gnuplot-scroll':<br>
|
||
A graphic will be rendered for 'device', where device is a FileLog, based on the type 'type' based on the given 'logfile'<br>
|
||
The 'zoom' will be either qday/day/week/month/year (same as used in FHEMWEB).<br>
|
||
The offset 'off' is either 0 (then the second part can be omitted, or -1/-2.... to jump back in time.<br>
|
||
The resulting filename will be 'attr-tmpfile file-name.png'<br>
|
||
<br>
|
||
NOTE: If you want to use zoom AND offset then you have to concatenate via '&' !!<br>
|
||
<br>
|
||
NOTE: combinations are possible in limited ranges:<br>
|
||
meaning: you can add the 'pos=zoom=XX&off=YY' to any of the first three sets. <br>
|
||
This may e.g. result in rendering all WebLinks with a specific zoom or offset <br>
|
||
(if you just pass the 'pos=zoom=xx&off=yy' parameter);<br>
|
||
<br>
|
||
Any rendered image (one or all WebLinks) will be stored in 'attr-tmpfile' followed by a 'filename.png'. The filename will be
|
||
either derived (from weblink-name or logfile-name) or, for single files, can be assigend.<br>
|
||
|
||
</ul>
|
||
<br>
|
||
|
||
|
||
<a name="FHEMRENDERERattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<a name="plotmode"></a>
|
||
<li>plotmode<br/>
|
||
Specifies how to generate the plots:
|
||
<ul>
|
||
<li>gnuplot<br>
|
||
Call the gnuplot script with each logfile. The filename
|
||
specification of the <a href="#FileLog">FileLog</a> device will
|
||
determine what is in the plot. The data is converted into an
|
||
image on the backend with gnuplot.</li>
|
||
<li>gnuplot-scroll<br>
|
||
FHEMRENDERER will offer zoom and offset possibilities in order to navigate
|
||
in the current logfile, i.e. you can select just a part of the
|
||
data to be displayed. The more data is contained in a single
|
||
logfile, the easier you can navigate. The recommendation is to
|
||
store the data for a whole year in one logfile. The data is
|
||
converted into an image on the backend with gnuplot.</li>
|
||
</ul>
|
||
</li><br>
|
||
|
||
<a name="plotsize"></a>
|
||
<li>plotsize<br/>
|
||
the default size of the plot, in pixels, separated by comma:
|
||
width,height. You can set individual sizes by setting the plotsize of
|
||
the weblink.
|
||
</li><br>
|
||
<a name="status="></a>
|
||
<li>status<br/>
|
||
Reflects the status, if the renderer timer has been set to ON or OFF.
|
||
By reading the status, you can detect, if the timer is running, or not.
|
||
</li><br>
|
||
|
||
<a name="refresh"></a>
|
||
<li>refresh<br/>
|
||
This defines the time-interval in which a new rendering of the defined
|
||
WebLinks will be done.
|
||
</li><br>
|
||
|
||
<a name="tmpfile"></a>
|
||
<li>tmpfile<br/>
|
||
This gives the path and a possible prefix for the rendered
|
||
filenames.<br/> 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.
|
||
</li><br>
|
||
<li>multiprocess<br/>
|
||
This defines if the Renderer works in a multiprocessing mode.<br/>
|
||
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
|
||
in an interactive mode, meaning that the FHEM-Loop will be block as long as the graphics are rendered.
|
||
If you want to use multiprocessing, set the RENDERER and multiprocessing to on and the
|
||
weblink-graphics will be rendered in the background.
|
||
</li><br></li> </ul>
|
||
</ul>
|
||
|
||
</ul>
|
||
|
||
|
||
<a name="PachLog"></a>
|
||
<h3>PachLog</h3>
|
||
<ul>
|
||
The PachLog-Module Logs SensorData like (temperature and humidity) to <a href=http://www.pachube.com>www.pachube.com</a>.
|
||
<br>
|
||
<br>
|
||
<a name="PachLogdefine"></a>
|
||
<b>Define</b>
|
||
<ul>
|
||
<br><code>define <name> PachLog <Pachube-API-Key></code> <br>
|
||
<br>
|
||
<Pachube-API-Key>:<br>
|
||
The Pachube-API-Key however is what you need in your code to authenticate your application's access the Pachube service.<br>
|
||
Don't share this with anyone: it's just like any other password.<br>
|
||
<a href=http://www.pachube.com>www.pachube.com</a><br>
|
||
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="PachLogset"></a>
|
||
<b>Set</b>
|
||
<ul>
|
||
<br>
|
||
Add a new Device for Logging to www.pachube.com<br><br>
|
||
<code>set <NAME> ADD <FHEM-DEVICENAME> FEED-NR:ID:READING:ID:READING</code><br><br>
|
||
Example: KS300-Weather-Data<br><br>
|
||
READINGS: temperature humidity wind rain<br><br>
|
||
1. Generate Input-Feed on www.pachube.com => Yout get your FEED-NR: 1234<br>
|
||
2. Add Datastreams to the Feed:<br>
|
||
<ul>
|
||
<table>
|
||
<tr><td>ID</td><td>0</td><td>temperature</td></tr>
|
||
<tr><td>ID</td><td>1</td><td>humidity</td></tr>
|
||
<tr><td>ID</td><td>2</td><td>wind</td></tr>
|
||
<tr><td>ID</td><td>3</td><td>rain</td></tr></table><br>
|
||
</ul>
|
||
3. Add the KS300 to your PachLog-Device<br><br>
|
||
<code>set <NAME> ADD <My-KS300> 1234:0temperature:1:humidity:2:wind:3:rain</code><br><br>
|
||
Delete a Device form Logging to www.pachube.com<br><br>
|
||
<code>set <NAME> DEL <FHEM-DEVICENAME></code><br><br>
|
||
</ul>
|
||
<br>
|
||
|
||
<a name="PachLogget"></a>
|
||
<b>Get</b> <ul>N/A</ul><br>
|
||
|
||
<a name="PachLogattr"></a>
|
||
<b>Attributes</b>
|
||
<ul>
|
||
<li><a href="#do_not_notify">do_not_notify</a></li><br>
|
||
<li><a href="#loglevel">loglevel</a></li><br>
|
||
<a name="disable"></a>
|
||
<li>disable<br>
|
||
Disables PachLog.
|
||
Nor more Logging to www.pachube.com
|
||
</ul><br>
|
||
|
||
|
||
</ul>
|
||
|
||
<a name="dumpdef"></a>
|
||
<h3>dumpdef</h3>
|
||
<ul>
|
||
<code>dumpdef <options></code>
|
||
<br><br>
|
||
Data::Dumper for FHEM-Devices/Hashes<br><br>
|
||
Dumps the content of <options> to FHEMWEB<br><br>
|
||
Options:<br><br>
|
||
<ul>
|
||
<table>
|
||
<tr><td><code>FHEM-DEVICENAME</code></td><td>=></td><td><code>%defs{FHEM-DEVICENAME}+%attr{FHEM-DEVICENAME}</code></td></tr>
|
||
<tr><td><code>MOD</code></td><td>=></td><td><code>%modules</code></td></tr>
|
||
<tr><td><code>SEL</code></td><td>=></td><td><code>%selectlist</code></td></tr>
|
||
<tr><td><code>DAT</code></td><td>=></td><td><code>%data</code></td></tr>
|
||
<tr><td><code>CMD</code></td><td>=></td><td><code>%cmd</code></td></tr>
|
||
</table>
|
||
</ul>
|
||
<br><br>
|
||
Example:
|
||
<ul><br>
|
||
<code>dumpdef TEST</code><br><br>
|
||
<ul><code>CALLER => main: /opt/fhz/FHEM/01_FHEMWEB.pm LINE: 194 SUB: main::FW_AnswerCall<br>
|
||
SUB-NAME: main::Commanddumpdef<br>
|
||
DUMP-DEVICE: TEST <br>
|
||
$VAR1 = {<ul><code>
|
||
'IODev' => {},<br>
|
||
'NAME' => 'TEST',<br>
|
||
'NR' => 64,<br>
|
||
'STATE' => '???',<br>
|
||
'TYPE' => 'dummy'<br>
|
||
};</code></ul>
|
||
<code>DUMP-DEVICE-ATTR<br>
|
||
$VAR1 = {</code><ul><code>
|
||
'room' => 'DEF_DUMMY,GRP.TEST'<br>
|
||
};</ul></code>
|
||
</code></ul><br>
|
||
</ul>
|
||
</ul>
|
||
|
||
<a name="perl"></a>
|
||
<h3>Perl specials</h3>
|
||
<ul>
|
||
<li>To test perl oneliners, type them on the prompt by enclosing it in {}, e.g.<br>
|
||
<ul>
|
||
{ Log 1, "Hallo" }
|
||
</ul>
|
||
</li>
|
||
|
||
<li>To store some macros, see the Notes in the <a href="#notify">notify</a>
|
||
description.</li>
|
||
|
||
<li>To use fhem commands from the perl expression, use the function "fhem",
|
||
which takes a string argument, this string will be evaluated as a fhem
|
||
command chain.<br>
|
||
Example:
|
||
<ul>
|
||
define n1 notify piri:on { fhem "set light on" }
|
||
</ul></li>
|
||
|
||
<li>To make date and time handling easier, before evaluating a perl
|
||
expression the variables $sec, $min, $hour, $mday, $month, $year, $wday,
|
||
$yday, $isdst are set (see perldoc -f localtime), with the exception that
|
||
$month is in the range of 1 to 12, and $year is also corrected by 1900 (as
|
||
one would normally expect). Additionally $we is 1 if it is weekend (i.e
|
||
$wday == 0 || $wday == 6), and 0 otherwise. If the <a
|
||
href="#holiday2we">holida2we</a> global attribute is set, $we is 1 for
|
||
holidays too.
|
||
Example:
|
||
|
||
<ul>
|
||
define n2 notify piri:on { if($hour > 18 || $hour < 5) { fhem "set
|
||
light on" } }
|
||
</ul></li>
|
||
|
||
<li>
|
||
The following small helper functions are defined in 99_Util.pm (which will
|
||
be loaded automatically):
|
||
<ul>
|
||
<li>min(a,b), max(a,b)</li>
|
||
<li>time_str2num("YYYY-MM-DD HH:MM:SS") returns a numerical value,
|
||
which makes computation of time differences easier</li>
|
||
<li>abstime2rel("HH:MM:SS") converts an absolute time to a relative one,
|
||
to compare it with the sunrise commands in the following example:<br>
|
||
# Switch lamp1 on at sunrise, but not before 07:00<br>
|
||
define a13 at +*{max(abstime2rel("07:00"),sunrise_rel())} set lamp1
|
||
on
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
|
||
<li>
|
||
<b>Note</b>: do not forget to escape the semicolon (;) with two semicolons
|
||
(;;), else your perl code will be interpreted as an fhem command and you
|
||
most certainly get syntax errors.
|
||
</li>
|
||
|
||
<li>
|
||
The current value (the string you see in paranthesis in the output of the
|
||
list command) is available in the <code>value</code> hash; to access it
|
||
use $value{<devicename>}<br>
|
||
If you need the old value (and time) of the currently triggered device,
|
||
then you can access it with <code>$oldvalue{$dev}{TIME}</code> and
|
||
<code>$oldvalue{$dev}{VAL}</code>.<br>
|
||
</li>
|
||
|
||
<li>
|
||
To access the numerical value of an FS20 command (e.g. toggle), use the
|
||
hash <code>fs20_c2b</code>. E.g. { Log 2, $fs20_c2b{"toggle"} }
|
||
</li>
|
||
|
||
<li>
|
||
By using the 99_SUNRISE_EL.pm module, you have access to the following
|
||
functions: <br>
|
||
<ul>
|
||
sunset_rel()<br>
|
||
sunset_abs()<br>
|
||
sunrise_rel()<br>
|
||
sunrise_abs()<br>
|
||
isday()<br>
|
||
</ul>
|
||
The _rel functions should be used as "at" spec, and the _abs functions as
|
||
argument to the on-till argument of the set command.<br>
|
||
isday returns 1 if the sun is visible, and 0 else.
|
||
</li>
|
||
|
||
</ul>
|
||
|
||
</body>
|
||
</html>
|