mirror of
https://github.com/fhem/fhem-mirror.git
synced 2024-11-22 02:59:49 +00:00
THE SPLIT
git-svn-id: https://svn.fhem.de/fhem/trunk@2076 2b470e98-0d58-463d-a4d8-8e2adae1ed80
This commit is contained in:
parent
6bfffbb57b
commit
a1397d1c34
@ -743,3 +743,80 @@ CM11_Ready($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="CM11"></a>
|
||||
<h3>CM11</h3>
|
||||
<ul>
|
||||
Note: this module requires the Device::SerialPort or Win32::SerialPort module.
|
||||
<br><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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -1022,3 +1022,236 @@ CUL_Attr(@)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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://culfw.de/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>
|
||||
|
||||
Note: this module may require the Device::SerialPort or Win32::SerialPort
|
||||
module if you attach the device via USB and the OS sets strange default
|
||||
parameters for serial devices.
|
||||
|
||||
|
||||
</td><td>
|
||||
<img src="ccc.jpg"/>
|
||||
</td></tr>
|
||||
</table>
|
||||
|
||||
<a name="CULdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> CUL <device> <FHTID></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>
|
||||
|
||||
If the baudrate is "directio" (e.g.: /dev/ttyACM0@directio), then the
|
||||
perl module Device::SerialPort is not needed, and fhem opens the device
|
||||
with simple file io. This might work if the operating system uses sane
|
||||
defaults for the serial parameters, e.g. some Linux distributions and
|
||||
OSX. <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 FHTID is a 4 digit hex number, and it is used when the CUL/CUR talks to
|
||||
FHT devices or when CUR requests data. Set it to 0000 to avoid answering
|
||||
any FHT80b request by the CUL.
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="CULset"></a>
|
||||
<b>Set </b>
|
||||
<ul>
|
||||
<li>raw<br>
|
||||
Issue a CUL firmware command. See the <a
|
||||
href="http://culfw.de/commandref.html">this</a> document
|
||||
for details on CUL commands.
|
||||
|
||||
</li><br>
|
||||
<li>freq / bWidth / rAmpl / sens<br>
|
||||
<a href="#rfmode">SlowRF</a> mode only.<br>
|
||||
Set the CUL frequency / bandwidth / receiver-amplitude / sensitivity<br>
|
||||
|
||||
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>
|
||||
<a name="hmPairForSec"></a>
|
||||
<li>hmPairForSec<br>
|
||||
<a href="#rfmode">HomeMatic</a> mode only.<br>
|
||||
Set the CUL in Pairing-Mode for the given seconds. Any device set into
|
||||
pairing mode in this time will be paired with fhem.
|
||||
</li><br>
|
||||
<a name="hmPairSerial"></a>
|
||||
<li>hmPairSerial<br>
|
||||
<a href="#rfmode">HomeMatic</a> mode only.<br>
|
||||
Try to pair with the given device. The argument is a 10 character
|
||||
string, usually starting with letters and ending with digits, printed on
|
||||
the backside of the device. It is not necessary to put the given device
|
||||
in learning mode if it is a receiver.
|
||||
</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><br>
|
||||
<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, and an "EOB" message is issued to the
|
||||
fhem log.
|
||||
<code>fhtbuf</code> returns the free memory in this buffer (in hex),
|
||||
an empty buffer in the CUL-V2 is 74 bytes, in CUL-V3/CUN 200 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> <br>
|
||||
|
||||
<li>ccconf<br>
|
||||
Read some CUL radio-chip (cc1101) registers (frequency, bandwidth, etc),
|
||||
and display them in human readable form.
|
||||
</li><br>
|
||||
|
||||
<li>cmds<br>
|
||||
Depending on the firmware installed, CULs have a different set of
|
||||
possible commands. Please refer to the README of the firmware of your
|
||||
CUL to interpret the response of this command. See also the raw-
|
||||
command.
|
||||
</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 name="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="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>
|
||||
<li><a name="rfmode">rfmode</a><br>
|
||||
Configure the RF Transceiver of the CUL (the CC1101). Available
|
||||
arguments are:
|
||||
<ul>
|
||||
<li>SlowRF<br>
|
||||
To communicate with FS20/FHT/HMS/EM1010/S300/Hoermann devices @1kHz
|
||||
datarate. This is the default.
|
||||
|
||||
<li>HomeMatic<br>
|
||||
To communicate with HomeMatic type of devices @20kHz datarate
|
||||
|
||||
<li>MAX<br>
|
||||
To communicate with MAX! type of devices @20kHz datarate
|
||||
|
||||
</ul>
|
||||
</li><br>
|
||||
<li><a name="hmId">hmId</a><br>
|
||||
Set the HomeMatic ID of this device. If this attribute is absent, the
|
||||
ID will be F1<FHTID>. Note 1: after setting or changing this
|
||||
attribute you have to relearn all your HomeMatic devices. Note 2: the
|
||||
value _must_ be a 6 digit hex number, and 000000 is not valid. fhem
|
||||
wont complain if it is not correct, but the communication won't work.
|
||||
</li><br>
|
||||
|
||||
<li><a name="hmProtocolEvents">hmProtocolEvents</a><br>
|
||||
Generate events for HomeMatic protocol messages. These are normally
|
||||
used for debugging, by activating "inform timer" in a telnet session,
|
||||
or looking at the "Event Monitor" window in the FHEMWEB frontend.
|
||||
Example:
|
||||
<ul>
|
||||
<code>
|
||||
2012-05-17 09:44:22.515 CUL CULHM RCV L:0B N:81 CMD:A258 SRC:...... DST:...... 0000 (TYPE=88,WAKEMEUP,BIDI,RPTEN)
|
||||
</code>
|
||||
</ul>
|
||||
</li><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -785,3 +785,186 @@ FHZ_Read($)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="FHZ"></a>
|
||||
<h3>FHZ</h3>
|
||||
<ul>
|
||||
Note: this module requires the Device::SerialPort or Win32::SerialPort module
|
||||
if the devices is connected via USB or a serial port.
|
||||
<br><br>
|
||||
|
||||
<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>
|
||||
stopHMS<br>
|
||||
initfull<br>
|
||||
raw<br>
|
||||
open<br>
|
||||
reopen<br>
|
||||
close<br>
|
||||
time<br>
|
||||
</ul>
|
||||
Notes:
|
||||
<ul>
|
||||
<li>raw is used to send out "raw" FS20/FHT messages ("setters" only - no query messages!).
|
||||
See message byte streams in FHEM/00_FHZ.pm and the doc directory for some examples.</li>
|
||||
<li>In order to set the time of your FHT's, schedule this command every
|
||||
minute:<br>
|
||||
<code>define fhz_timer at +*00:01:00 set FHZ time</code><br>
|
||||
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 improve this particular part of such issues.
|
||||
See <a href="http://www.fhem.de/USB.html">our USB page</a>
|
||||
for detailed USB / electromag. interference troubleshooting.</li>
|
||||
<li><code>initfull</code> issues the initialization sequence for the FHZ
|
||||
device:<br>
|
||||
<pre>
|
||||
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>
|
||||
<li><code>stopHMS</code> probably is the inverse of <code>initHMS</code>
|
||||
(I don't have authoritative info on what exactly it does).</li>
|
||||
<li><code>close</code> closes and frees the serial device port until you open
|
||||
it again with <code>open</code>, e.g. useful if you need to temporarily
|
||||
unload the ftdi_sio kernel module to use the <a href="http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-01_BitBang.pdf" target="_blank">bit-bang mode</a>.</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.<br>
|
||||
On the other hand, if you have to debug a given device, setting its
|
||||
loglevel to a smaller value than the value of the global verbose attribute,
|
||||
it will output its messages normally seen only with higher global verbose
|
||||
levels.
|
||||
</li> <br>
|
||||
|
||||
<li><a href="#model">model</a> (fhz1000,fhz1300)</li><br>
|
||||
|
||||
<a name="fhtsoftbuffer"></a>
|
||||
<li>fhtsoftbuffer<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>
|
||||
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -420,3 +420,71 @@ HMLAN_secSince2000()
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="HMLAN"></a>
|
||||
<h3>HMLAN</h3>
|
||||
<ul>
|
||||
<tr><td>
|
||||
The HMLAN is the fhem module for the eQ-3 HomeMatic LAN Configurator.
|
||||
<br><br>
|
||||
The fhem module will emulate a CUL device, so the <a href="#CUL_HM">CUL_HM</a>
|
||||
module can be used to define HomeMatic devices.<br><br>
|
||||
|
||||
In order to use it with fhem you <b>must</b> disable the encryption first
|
||||
with the "HomeMatic Lan Interface Configurator" (which is part of the
|
||||
supplied Windows software), by selecting the device, "Change IP Settings",
|
||||
and deselect "AES Encrypt Lan Communication".<br><br>
|
||||
This device can be used in parallel with a CCU and (readonly) with fhem. To do this:
|
||||
<ul>
|
||||
<li>start the fhem/contrib/tcptee.pl program
|
||||
<li>redirect the CCU to the local host
|
||||
<li>disable the LAN-Encryption on the CCU for the Lan configurator
|
||||
<li>set the dummy attribute for the HMLAN device in fhem
|
||||
</ul>
|
||||
<br><br>
|
||||
|
||||
|
||||
<a name="HMLANdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> HMLAN <ip-address>[:port]</code><br>
|
||||
<br>
|
||||
port is 1000 by default.
|
||||
If the ip-address is called none, then no device will be opened, so you
|
||||
can experiment without hardware attached.<br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="HMLANset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
<li><a href="#hmPairForSec">hmPairForSec</a>
|
||||
<li><a href="#hmPairSerial">hmPairSerial</a>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="HMLANget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
N/A
|
||||
</ul>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<a name="HMLANattr"></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="#loglevel">loglevel</a></li><br>
|
||||
<li><a href="#addvaltrigger">addvaltrigger</a></li><br>
|
||||
<li><a href="#hmId">hmId</a></li><br>
|
||||
<li><a href="#hmProtocolEvents">hmProtocolEvents</a></li><br>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -814,3 +814,238 @@ KM271_SetReading($$$$$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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><br>
|
||||
|
||||
Note: this module requires the Device::SerialPort or Win32::SerialPort module.
|
||||
<br><br>
|
||||
|
||||
<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@2400</code><br>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="KM271set"></a>
|
||||
<b>Set </b>
|
||||
<ul>
|
||||
<code>set KM271 <param> [<value> [<values>]]</code><br><br>
|
||||
where param is one of:
|
||||
<ul>
|
||||
<li>hk1_tagsoll <temp><br>
|
||||
sets the by day temperature for heating circuit 1<br>
|
||||
0.5 celsius resolution - temperature between 10 and 30 celsius</li>
|
||||
<li>hk2_tagsoll <temp><br>
|
||||
sets the by day temperature for heating circuit 2<br>
|
||||
(see above)</li>
|
||||
<li>hk1_nachtsoll <temp><br>
|
||||
sets the by night temperature for heating circuit 1<br>
|
||||
(see above)</li>
|
||||
<li>hk2_nachtsoll <temp><br>
|
||||
sets the by night temperature for heating circuit 2<br>
|
||||
(see above)</li>
|
||||
<li>hk1_betriebsart [automatik|nacht|tag]<br>
|
||||
sets the working mode for heating circuit 1<br>
|
||||
<ul>
|
||||
<li>automatik: the timer program is active and the summer configuration is in effect</li>
|
||||
<li>nacht: manual by night working mode, no timer program is in effect</li>
|
||||
<li>tag: manual by day working mode, no timer program is in effect</li>
|
||||
</ul></li>
|
||||
</li>
|
||||
<li>hk2_betriebsart [automatik|nacht|tag]<br>
|
||||
sets the working mode for heating circuit 2<br>
|
||||
(see above)</li>
|
||||
<li>ww_soll <temp><br>
|
||||
sets the hot water temperature<br>
|
||||
1.0 celsius resolution - temperature between 30 and 60 celsius</li>
|
||||
<li>ww_betriebsart [automatik|nacht|tag]<br>
|
||||
sets the working mode for hot water<br>
|
||||
<ul>
|
||||
<li>automatik: hot water production according to the working modes of both heating circuits</li>
|
||||
<li>nacht: no hot water at all</li>
|
||||
<li>tag: manual permanent hot water</li>
|
||||
</ul></li>
|
||||
<li>ww_on-for-timer [period]<br>
|
||||
start hot water production for the given period<br>
|
||||
period must have the format HH:MM<br>
|
||||
ww_betriebsart is set according to the attribut ww_timermode. For switching-off hot water a single one-time at command is automatically generated which will set ww_betriebsart back to nacht</li>
|
||||
<li>hk1_programm [eigen|familie|frueh|spaet|vormittag|nachmittag|mittag|single|senior]<br>
|
||||
sets the timer program for heating circuit 1<br>
|
||||
<ul>
|
||||
<li>eigen: the custom program defined by the user (see below) is used</li>
|
||||
<li>all others: predefined programs from Buderus for various situations (see Buderus manual for details)</li>
|
||||
</ul></li>
|
||||
<li>hk2_programm [eigen|familie|frueh|spaet|vormittag|nachmittag|mittag|single|senior]<br>
|
||||
sets the timer program for heating circuit 2<br>
|
||||
(see above)</li>
|
||||
<li>hk1_timer [<position> delete|<position> <on-day> <on-time> <off-day> <off-time>]<br>
|
||||
sets (or deactivates) a by day working mode time interval for the custom program of heating circuit 1<br>
|
||||
<ul>
|
||||
<li>position: addresses a slot of the custom timer program and must be between 1 and 21<br>
|
||||
The slot will be set to the interval specified by the following on- and off-timepoints or is deactivated when the next argument is <b>delete</b>.</li>
|
||||
<li>on-day: first part of the on-timepoint<br>
|
||||
valid arguments are [mo|di|mi|do|fr|sa|so]</li>
|
||||
<li>on-time: second part of the on-timepoint<br>
|
||||
valid arguments have the format HH:MM (supported resolution: 10 min)</li>
|
||||
<li>off-day: first part of the off-timepoint<br>
|
||||
(see above)</li>
|
||||
<li>off-time: second part of the off-timepoint<br>
|
||||
valid arguments have the format HH:MM (supported resolution: 10 min)</li>
|
||||
</ul>
|
||||
As the on-timepoint is reached, the heating circuit is switched to by day working mode and when the off-timepoint is attained, the circuit falls back to by night working mode.
|
||||
A program can be build up by chaining up to 21 of these intervals. They are ordered by the position argument. There's no behind the scene magic that will automatically consolidate the list.
|
||||
The consistency of the program is in the responsibility of the user.
|
||||
<br><br>
|
||||
Example:
|
||||
<ul>
|
||||
<code>set KM271 hk1_timer 1 mo 06:30 mo 08:20</code><br>
|
||||
</ul><br>
|
||||
This will toogle the by day working mode every Monday at 6:30 and will fall back to by night working mode at 8:20 the same day.</li>
|
||||
<li>hk2_timer [<position> delete|<position> <on-day> <on-time> <off-day> <off-time>]<br>
|
||||
sets (or deactivates) a by day working mode time interval for the custom program of heating circuit 2<br>
|
||||
(see above)</li>
|
||||
<li>logmode<br>set to logmode / request all readings 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>
|
||||
HK1_Vorlaufisttemperatur, HK2_Vorlaufisttemperatur, Kessel_Vorlaufisttemperatur,
|
||||
Kessel_Integral, Kessel_Integral1<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>
|
||||
<a name="ww_timermode"></a>
|
||||
<li>ww_timermode [automatik|tag]<br>
|
||||
Defines the working mode for the ww_on-for-timer command (default is tag).<br>
|
||||
ww_on-for-timer will set the ww_betriebsart of the heater according to this attribute.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
|
||||
<a name="KM271events"></a>
|
||||
<b>Generated events:</b>
|
||||
<ul>
|
||||
<li>Abgastemperatur
|
||||
<li>Aussentemperatur
|
||||
<li>Aussentemperatur_gedaempft
|
||||
<li>Brenner_Ansteuerung
|
||||
<li>Brenner_Ausschalttemperatur
|
||||
<li>Brenner_Einschalttemperatur
|
||||
<li>Brenner_Laufzeit1_Minuten2
|
||||
<li>Brenner_Laufzeit1_Minuten1
|
||||
<li>Brenner_Laufzeit1_Minuten
|
||||
<li>Brenner_Laufzeit2_Minuten2
|
||||
<li>Brenner_Laufzeit2_Minuten1
|
||||
<li>Brenner_Laufzeit2_Minuten
|
||||
<li>Brenner_Mod_Stellglied
|
||||
<li>ERR_Fehlerspeicher1
|
||||
<li>ERR_Fehlerspeicher2
|
||||
<li>ERR_Fehlerspeicher3
|
||||
<li>ERR_Fehlerspeicher4
|
||||
<li>ERR_Letzter_Fehlerstatus
|
||||
<li>HK1_Ausschaltoptimierung
|
||||
<li>HK1_Betriebswerte1
|
||||
<li>HK1_Betriebswerte2
|
||||
<li>HK1_Einschaltoptimierung
|
||||
<li>HK1_Heizkennlinie_+10_Grad
|
||||
<li>HK1_Heizkennlinie_-10_Grad
|
||||
<li>HK1_Heizkennlinie_0_Grad
|
||||
<li>HK1_Mischerstellung
|
||||
<li>HK1_Pumpe
|
||||
<li>HK1_Raumisttemperatur
|
||||
<li>HK1_Raumsolltemperatur
|
||||
<li>HK1_Vorlaufisttemperatur
|
||||
<li>HK1_Vorlaufsolltemperatur
|
||||
<li>HK2_Ausschaltoptimierung
|
||||
<li>HK2_Betriebswerte1
|
||||
<li>HK2_Betriebswerte2
|
||||
<li>HK2_Einschaltoptimierung
|
||||
<li>HK2_Heizkennlinie_+10_Grad
|
||||
<li>HK2_Heizkennlinie_-10_Grad
|
||||
<li>HK2_Heizkennlinie_0_Grad
|
||||
<li>HK2_Mischerstellung
|
||||
<li>HK2_Pumpe
|
||||
<li>HK2_Raumisttemperatur
|
||||
<li>HK2_Raumsolltemperatur
|
||||
<li>HK2_Vorlaufisttemperatur
|
||||
<li>HK2_Vorlaufsolltemperatur
|
||||
<li>Kessel_Betrieb
|
||||
<li>Kessel_Fehler
|
||||
<li>Kessel_Integral
|
||||
<li>Kessel_Integral1
|
||||
<li>Kessel_Vorlaufisttemperatur
|
||||
<li>Kessel_Vorlaufsolltemperatur
|
||||
<li>Modulkennung
|
||||
<li>NoData
|
||||
<li>Versionsnummer_NK
|
||||
<li>Versionsnummer_VK
|
||||
<li>WW_Betriebswerte1
|
||||
<li>WW_Betriebswerte2
|
||||
<li>WW_Einschaltoptimierung
|
||||
<li>WW_Isttemperatur
|
||||
<li>WW_Pumpentyp
|
||||
<li>WW_Solltemperatur
|
||||
</ul>
|
||||
<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). Most parameters from these records are reverse engeneered, they
|
||||
all start with CFG_ for configuration and PRG_ for timer program information.
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -112,3 +112,52 @@ LIRC_Ready($)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="LIRC"></a>
|
||||
<h3>LIRC</h3>
|
||||
<ul>
|
||||
Use infrared signals received by an lirc device as toggle events.
|
||||
<br><br>
|
||||
Note: this module needs the Lirc::Client perl module.
|
||||
<br><br>
|
||||
|
||||
<a name="LIRCdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
define <name> LIRC <lircrc_file><br>
|
||||
Example:<br>
|
||||
<ul>
|
||||
define Lirc LIRC /etc/lirc/lircrc
|
||||
</ul>
|
||||
Note: In the lirc configuration file you have to define each possible event.
|
||||
If you have this configuration
|
||||
<pre>
|
||||
begin
|
||||
prog = fhem
|
||||
button = pwr
|
||||
config = IrPower
|
||||
end</pre>
|
||||
and you press the pwr button the IrPower toggle event occures at fhem.
|
||||
<pre>
|
||||
define IrPower01 notify IrPower set lamp toggle</pre>
|
||||
turns the lamp on and off.
|
||||
If you want a faster reaction to keypresses you have to change the
|
||||
defaultvalue of readytimeout from 5 seconds to e.g. 1 second in fhem.pl
|
||||
</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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -2088,3 +2088,94 @@ sub OWX_Verify_CUNO ($$) {
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="OWX"></a>
|
||||
<h3>OWX</h3>
|
||||
<ul> FHEM module to commmunicate with 1-Wire bus devices <ul>
|
||||
<li>via an active DS2480/DS2482/DS2490/DS9097U bus master interface attached to an
|
||||
USB port or </li>
|
||||
<li>via a passive DS9097 interface attached to an USB port or</li>
|
||||
<li>via a network-attached CUNO or through a COC on the RaspBerry Pi</li>
|
||||
</ul> Internally these interfaces are vastly different, read the corresponding <a
|
||||
href="http://fhemwiki.de/wiki/Interfaces_f%C3%BCr_1-Wire"> Wiki pages </a>
|
||||
<br />
|
||||
<br />
|
||||
<b>Example</b><br />
|
||||
<ul>
|
||||
<code>define OWio1 OWX /dev/ttyUSB1</code>
|
||||
<br />
|
||||
<code>define OWio2 OWX COC</code>
|
||||
<br />
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWXdefine">
|
||||
<b>Define</b></a>
|
||||
<ul>
|
||||
<code>define <name> OWX <serial-device></code> or <br />
|
||||
<code>define <name> OWX <cuno/coc-device></code>
|
||||
<br /><br /> Define a 1-Wire interface to communicate with a 1-Wire bus.<br />
|
||||
<br />
|
||||
<li>
|
||||
<code><serial-device></code> The serial device (e.g. USB port) to which
|
||||
the 1-Wire bus is attached.</li>
|
||||
<li>
|
||||
<code><cuno-device></code> The previously defined CUNO to which the 1-Wire
|
||||
bus is attached. </li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWXset">
|
||||
<b>Set</b></a>
|
||||
<ul>
|
||||
<li><a name="owx_interval">
|
||||
<code>set <name> interval <value></code>
|
||||
</a>
|
||||
<br /><br /> sets the time period in seconds for "kicking" the 1-Wire bus
|
||||
(default is 300 seconds). This means: <ul>
|
||||
<li>With 1-Wire bus interfaces that do not supply power to the 1-Wire bus
|
||||
(attr buspower parasitic), the 1-Wire bus is reset at these intervals. </li>
|
||||
<li>With 1-Wire bus interfaces that supply power to the 1-Wire bus (attr
|
||||
buspower = real), all temperature measurement devices on the bus receive
|
||||
the command to start a temperature conversion (saves a lot of time when
|
||||
reading) </li>
|
||||
<li>With 1-Wire bus interfaces that contain a busmaster chip, the response
|
||||
to a reset pulse contains information about alarms.</li>
|
||||
</ul><br />
|
||||
</li>
|
||||
<li><a name="owx_followAlarms">
|
||||
<code>set <name> followAlarms on|off</code>
|
||||
</a>
|
||||
<br /><br /> instructs the module to start an alarm search in case a reset pulse
|
||||
discovers any 1-Wire device which has the alarm flag set. </li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWXget">
|
||||
<b>Get</b></a>
|
||||
<ul>
|
||||
<li><a name="owx_alarms"></a>
|
||||
<code>get <name> alarms</code>
|
||||
<br /><br /> performs an "alarm search" for devices on the 1-Wire bus and, if
|
||||
found, generates an event in the log (not with CUNO). </li>
|
||||
<br />
|
||||
<li><a name="owx_devices"></a>
|
||||
<code>get <name> devices</code>
|
||||
<br /><br /> redicovers all devices on the 1-Wire bus. If a device found has a
|
||||
previous definition, this is automatically used. If a device is found but has no
|
||||
definition, it is autocreated. If a defined device is not on the 1-Wire bus, it
|
||||
is autodeleted. </li>
|
||||
<br />
|
||||
<br />
|
||||
</ul>
|
||||
<a name="OWXattr">
|
||||
<b>Attributes</b></a>
|
||||
<ul>
|
||||
<li><a name="OWXbuspower"><code>attr <name> buspower real|parasitic</code></a>
|
||||
<br />tells FHEM whether power is supplied to the 1-Wire bus or not.</li>
|
||||
<li>Standard attributes alias, comment, <a href="#eventMap">eventMap</a>, <a href="#loglevel">loglevel</a>, <a href="#webCmd">webCmd</a></li>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -668,3 +668,84 @@ TCM_Undef($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="TCM"></a>
|
||||
<h3>TCM</h3>
|
||||
<ul>
|
||||
The TCM module serves an USB or TCP/IP connected TCM120 or TCM310 EnOcean
|
||||
Transceiver module. These are mostly packaged together with a serial to USB
|
||||
chip and an antenna, e.g. the BSC BOR contains the TCM120, the EUL from
|
||||
busware contains a TCM310. See also the datasheet available from <a
|
||||
href="http://www.enocean.com">www.enocean.com</a>.
|
||||
<br>
|
||||
As the TCM120 and the TCM310 speak completely different protocols, this
|
||||
module implements 2 drivers in one. It is the "physical" part for the <a
|
||||
href="#EnOcean">EnOcean</a> module.<br><br>
|
||||
|
||||
<a name="TCMdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> TCM [120|310] <device></code> <br>
|
||||
<br>
|
||||
First you have to specify the type of the EnOcean Transceiver Chip , i.e
|
||||
either 120 for the TCM120 or 310 for the TCM310.<br><br>
|
||||
<code>device</code> can take the same parameters (@baudrate, @directio,
|
||||
TCP/IP, none) like the <a href="#CULdefine">CUL</a>, but you probably have
|
||||
to specify the baudrate: the TCM120 should be opened with 9600 Baud, the
|
||||
TCM310 with 57600 baud.
|
||||
Example:
|
||||
<ul><code>
|
||||
define BscBor TCM 120 /dev/ttyACM0@9600<br>
|
||||
define TCM310 TCM 310 /dev/ttyACM0@57600<br>
|
||||
</code></ul>
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="TCMset"></a>
|
||||
<b>Set </b>
|
||||
<ul>
|
||||
<li>idbase<br>
|
||||
Set the ID base. Note: The firmware executes this command only up to
|
||||
then times to prevent misuse.<br><br>
|
||||
<li>modem_off<br>
|
||||
<li>modem_on<br>
|
||||
<li>reset<br>
|
||||
<li>sensitivity<br>
|
||||
<li>sleep<br>
|
||||
<li>wake<br>
|
||||
For details see the datasheet available from
|
||||
www.enocean.com. If you do not understand it, than you probably don't
|
||||
need it :)
|
||||
</li><br>
|
||||
</ul>
|
||||
|
||||
<a name="TCMget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
<li>idbase<br>
|
||||
Get the ID base. You need this command in order to control EnOcean
|
||||
devices, see the <a href="#EnOceandefine">EnOcean</a>
|
||||
paragraph.<br><br>
|
||||
<li>modem_status<br>
|
||||
<li>sensitivity<br>
|
||||
<li>sw_ver<br>
|
||||
for details see the datasheet available from www.enocean.com
|
||||
</li><br>
|
||||
</ul>
|
||||
|
||||
<a name="TCMattr"></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>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -1084,3 +1084,95 @@ sub sendRequest($$)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="TUL"></a>
|
||||
<h3>TUL</h3>
|
||||
<ul>
|
||||
|
||||
<table>
|
||||
<tr><td>
|
||||
The TUL module is the representation of a EIB / KNX connector in FHEM.
|
||||
<a href="#EIB">EIB</a> instances represent the EIB / KNX devices and will need a TUL as IODev to communicate with the EIB / KNX network.<br>
|
||||
The TUL module is designed to connect to EIB network either using EIBD or the <a href="http://busware.de/tiki-index.php?page=TUL" target="_blank">TUL usb stick</a> created by busware.de
|
||||
|
||||
Note: this module may require the Device::SerialPort or Win32::SerialPort
|
||||
module if you attach the device via USB and the OS sets strange default
|
||||
parameters for serial devices.
|
||||
|
||||
</td><td>
|
||||
<img src="http://busware.de/show_image.php?id=269" width="100%" height="100%"/>
|
||||
</td></tr>
|
||||
</table>
|
||||
|
||||
<a name="TULdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> TUL <device> <physical address></code> <br>
|
||||
<br>
|
||||
TUL usb stick / TPUART serial devices:<br><ul>
|
||||
<device> specifies the serial port to communicate with the TUL.
|
||||
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 TUL 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@19200<br><br>
|
||||
Note: For TUL usb stick the baudrate 19200 is needed and this is the default
|
||||
when no baudrate is given.
|
||||
<br><br>
|
||||
|
||||
Example:<br>
|
||||
<code>define tul TUL tul:/dev/ttyACM0 1.1.249</code>
|
||||
</ul>
|
||||
EIBD:<br><ul>
|
||||
<device> specifies the host:port of the eibd device. E.g.
|
||||
eibd:192.168.0.244:2323. When using the standard port, the port can be omitted.
|
||||
<br><br>
|
||||
|
||||
Example:<br>
|
||||
<code>define tul TUL eibd:localhost 1.1.249</code>
|
||||
</ul>
|
||||
<br>
|
||||
If the device is called none, then no device will be opened, so you
|
||||
can experiment without hardware attached.<br>
|
||||
|
||||
The physical address is used as the source address of telegrams sent to EIB network.
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="TULset"></a>
|
||||
<b>Set </b>
|
||||
<ul>
|
||||
<li>raw<br>
|
||||
Issue a TUL raw telegram message
|
||||
</li><br>
|
||||
</ul>
|
||||
|
||||
<a name="TULget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
<li>raw<br>
|
||||
sends a read telegram
|
||||
</li><br>
|
||||
</ul>
|
||||
|
||||
<a name="TULattr"></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>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -534,3 +534,103 @@ ZWDongle_Ready($)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="ZWDongle"></a>
|
||||
<h3>ZWDongle</h3>
|
||||
<ul>
|
||||
This module serves a ZWave dongle, which is attached via USB or TCP/IP, and
|
||||
enables the use of ZWave devices (see also the <a href="#ZWave">ZWave</a>
|
||||
module). It was tested wit a Goodway WD6001, but since the protocol is
|
||||
standardized, it should work with other devices too. A notable exception is
|
||||
the USB device from Merten.
|
||||
<br><br>
|
||||
<a name="ZWDongledefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> ZWDongle <device></code>
|
||||
<br>
|
||||
<br>
|
||||
Upon initial connection the module will get the homeId of the attached
|
||||
device. Since the DevIo module is used to open the device, you can also use
|
||||
devices connected via TCP/IP. See <a href="#CULdefine">this</a> paragraph on
|
||||
device naming details.
|
||||
<br>
|
||||
Example:
|
||||
<ul>
|
||||
<code>define zwdongle_1 ZWDongle /dev/cu.PL2303-000014FA@115200</code><br>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="ZWDongleset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
|
||||
<li>addNode [on|off]<br>
|
||||
Activate (or deactivate) inclusion mode. The controller (i.e. the dongle)
|
||||
will accept inclusion (i.e. pairing/learning) requests only while in this
|
||||
mode. After activating inclusion mode usually you have to press a switch
|
||||
three times within 1.5 seconds on the node to be included into the network
|
||||
of the controller. If autocreate is active, a fhem device will be created
|
||||
after inclusion.
|
||||
|
||||
<li>removeNode [on|off]<br>
|
||||
Activate (or deactivate) exclusion mode. Note: the corresponding fhem
|
||||
device have to be deleted manually.
|
||||
|
||||
<li>createNode id<br>
|
||||
Request the class information for the specified node, and create a fhem
|
||||
device upon reception of the answer. Used for previously included nodes,
|
||||
see the nodeList get command below.
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="ZWDongleget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
<li>nodeList<br>
|
||||
return the list of included nodeIds. Can be used to recreate fhem-nodes
|
||||
with the createNode command.
|
||||
|
||||
<li>homeId<br>
|
||||
return the six hex-digit homeId of the controller.
|
||||
|
||||
<li>caps, ctrlCaps, version<br>
|
||||
return different controller specific information. Needed by developers only.
|
||||
|
||||
<li>nodeInfo<br>
|
||||
return node specific information. Needed by developers only.
|
||||
|
||||
|
||||
<li>raw<br>
|
||||
Send raw data to the controller. Developer only.
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="ZWDongleattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#dummy">dummy</a></li>
|
||||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
<li><a href="#model">model</a></li>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="ZWDongleevents"></a>
|
||||
<b>Generated events:</b>
|
||||
<ul>
|
||||
<li>ZW_ADD_NODE_TO_NETWORK [learnReady|nodeFound|controller|done|failed]
|
||||
<li>ZW_REMOVE_NODE_TO_NETWORK [learnReady|nodeFound|slave|controller|done|failed]
|
||||
<li>UNDEFINED ZWave_${type6}_$id ZWave $homeId $id $classes"
|
||||
</ul>
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -2517,3 +2517,317 @@ FW_Set($@)
|
||||
#####################################
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="FHEMWEB"></a>
|
||||
<h3>FHEMWEB</h3>
|
||||
<ul>
|
||||
FHEMWEB is the builtin web-frontend (webpgm2). It implements a simple web
|
||||
server (optionally with Basic-Auth and HTTPS), so no additional program is
|
||||
needed.
|
||||
<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.<br>
|
||||
To enable listening on IPV6 see the comments <a href="#port">here</a>.
|
||||
<br><br>
|
||||
Feature: http://host:port/fhem/icons/<devicename> will return
|
||||
the icon associated with the current status of <devicename>.
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="FHEMWEBset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
<code>set <name> rereadicons</code>
|
||||
<br><br>
|
||||
Rereads the icons in the icon path and updates the mapping from logical icons to physical files.
|
||||
Use after adding, deleting or changing icons.
|
||||
<br><br>
|
||||
|
||||
</ul>
|
||||
|
||||
<a name="FHEMWEBget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
<li>icon <logical icon><br>
|
||||
|
||||
returns the absolute path to the logical icon. Example:
|
||||
<ul>
|
||||
<code>get myFHEMWEB icon FS20.on<br>
|
||||
/data/Homeautomation/fhem/FHEM/FS20.on.png
|
||||
</code>
|
||||
</ul>
|
||||
<li>pathlist<br>
|
||||
return FHEMWEB specific directories, where files for given types are located
|
||||
<br><br>
|
||||
|
||||
</ul>
|
||||
|
||||
<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 supported on the Android
|
||||
platform by Opera/Firefox and the Internet Explorer before 9
|
||||
needs a plugin.
|
||||
</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.<br><br>
|
||||
If the value is one of day, week, month, year than set the zoom level
|
||||
for this weblink independently of the user specified zoom-level.
|
||||
This is useful for pages with multiple plots: one of the plots is best
|
||||
viewed in with the default (day) zoom, the other one with a week zoom.
|
||||
</li><br>
|
||||
|
||||
<a name="smallscreen"></a>
|
||||
<a name="touchpad"></a>
|
||||
<li>smallscreen, touchpad<br>
|
||||
Optimize for small screen size (i.e. smartphones) or for touchpad
|
||||
devices (i.e. tablets)<br>
|
||||
Note: The default configuration installed with make install-pgm2
|
||||
installs 2 FHEMWEB instances: port 8083 for desktop browsers and
|
||||
port 8084 for smallscreen browsers, both using SVG rendering.
|
||||
On Android SVG is supported by Opera/Firefox.<br>
|
||||
|
||||
WebApp suppport if specifying one of the above options: After viewing
|
||||
the site on the iPhone or iPad in Safari, add it to the home-screen to
|
||||
get full-screen support.
|
||||
</li><br>
|
||||
|
||||
<a name="plotfork"></a>
|
||||
<li>plotfork<br>
|
||||
If set, generate the logs in a parallel process. Note: do not use it
|
||||
on Windows and on systems with small memory foorprint.
|
||||
</li><br>
|
||||
|
||||
<a name="basicAuth"></a>
|
||||
<li>basicAuth, basicAuthMsg<br>
|
||||
request a username/password authentication for access. You have to set
|
||||
the basicAuth attribute to the Base64 encoded value of
|
||||
<user>:<password>, e.g.:<ul>
|
||||
# Calculate first the encoded string with the commandline program<br>
|
||||
$ echo -n fhemuser:secret | base64<br>
|
||||
ZmhlbXVzZXI6c2VjcmV0<br>
|
||||
fhem.cfg:<br>
|
||||
attr WEB basicAuth ZmhlbXVzZXI6c2VjcmV0
|
||||
</ul>
|
||||
You can of course use other means of base64 encoding, e.g. online
|
||||
Base64 encoders. If basicAuthMsg is set, it will be displayed in the
|
||||
popup window when requesting the username/password.<br>
|
||||
<br>
|
||||
If the argument of basicAuth is enclosed in {}, then it will be
|
||||
evaluated, and the $user and $password variable will be set to the
|
||||
values entered. If the return value is true, then the password will be
|
||||
accepted.
|
||||
Example:<br>
|
||||
<code>
|
||||
attr WEB basicAuth { "$user:$password" eq "admin:secret" }<br>
|
||||
attr WEB basicAuth {use FritzBoxUtils;;FB_checkPw("localhost","$password") }
|
||||
</code>
|
||||
|
||||
|
||||
</li><br>
|
||||
|
||||
<a name="HTTPS"></a>
|
||||
<li>HTTPS<br>
|
||||
Enable HTTPS connections. This feature requires the perl module
|
||||
IO::Socket::SSL, to be installed with cpan -i IO::Socket::SSL or
|
||||
apt-get install libio-socket-ssl-perl; OSX and the FritzBox-7390
|
||||
already have this module.<br>
|
||||
|
||||
A local certificate has to be generated into a directory called certs,
|
||||
this directory <b>must</b> be in the <a href="#modpath">modpath</a>
|
||||
directory, at the same level as the FHEM directory.
|
||||
<ul>
|
||||
mkdir certs<br>
|
||||
cd certs<br>
|
||||
openssl req -new -x509 -nodes -out server-cert.pem -days 3650 -keyout server-key.pem
|
||||
</ul>
|
||||
<br><br>
|
||||
</li>
|
||||
|
||||
<li><a href="#allowfrom">allowfrom</a></li>
|
||||
</li><br>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
</li><br>
|
||||
|
||||
<a name="stylesheetPrefix"></a>
|
||||
<li>stylesheetPrefix<br>
|
||||
prefix for the files style.css, svg_style.css and svg_defs.svg. If the file
|
||||
with the prefix is missing, the default file (without prefix) will be used.
|
||||
These files have to be placed into the FHEM directory, and can be selected
|
||||
directly from the "Select style" FHEMWEB menu entry. Example:
|
||||
<ul>
|
||||
attr WEB stylesheetPrefix dark<br>
|
||||
<br>
|
||||
Referenced files:<br>
|
||||
<ul>
|
||||
darksvg_defs.svg<br>
|
||||
darksvg_style.css<br>
|
||||
darkstyle.css<br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<a name="hiddenroom"></a>
|
||||
<li>hiddenroom<br>
|
||||
Komma separated list of rooms to "hide", i.e. not to show. Special
|
||||
values are input, detail and save, in which case the input areas, link
|
||||
to the detailed views or save button is hidden (although each aspect
|
||||
still can be addressed through url manipulation).<br>
|
||||
The list can also contain values from the additional "Howto/Wiki/FAQ"
|
||||
block.
|
||||
</li>
|
||||
<br>
|
||||
|
||||
<a name="longpoll"></a>
|
||||
<li>longpoll<br>
|
||||
Affects devices states in the room overview only.<br>
|
||||
In this mode status update is refreshed more or less instantaneously,
|
||||
and state change (on/off only) is done without requesting a complete
|
||||
refresh from the server.
|
||||
</li>
|
||||
<br>
|
||||
|
||||
<a name="redirectCmds"></a>
|
||||
<li>redirectCmds<br>
|
||||
Clear the browser URL window after issuing the command by redirecting
|
||||
the browser, as a reload for the same site might have unintended
|
||||
side-effects. Default is 1 (enabled). Disable it by setting this
|
||||
attribute to 0 if you want to study the command syntax, in order to
|
||||
communicate with FHEMWEB.
|
||||
</li>
|
||||
<br>
|
||||
|
||||
<a name="webCmd"></a>
|
||||
<li>webCmd<br>
|
||||
Colon separated list of commands to be shown in the room overview for a
|
||||
certain device. On smallscreen devices only the first value is
|
||||
accessible.<br>
|
||||
If the first value references a command, for which "set
|
||||
device ?" lists a number possible choices (e.g. desired-temp for FHT
|
||||
devices), then a select widget will be displayed. If the values are
|
||||
"slider,min,step,max", then a javascript driven slider is displayed.
|
||||
if the value is "time", then a javascript timepicker is displayed.
|
||||
If the command is state, then the value will be used as a command.<br>
|
||||
Examples:
|
||||
<ul>
|
||||
attr lamp webCmd on:off:on-for-timer 10<br>
|
||||
define d1 dummy<br>
|
||||
attr d1 webCmd state<br>
|
||||
attr d1 set setList state:on,off<br>
|
||||
define d2 dummy<br>
|
||||
attr d2 webCmd state<br>
|
||||
attr d2 set setList state:slider,0,1,10<br>
|
||||
define d3 dummy<br>
|
||||
attr d3 webCmd state<br>
|
||||
attr d3 set setList state:time<br>
|
||||
</ul>
|
||||
Note: this is an attribute for the displayed device, not for the FHEMWEB
|
||||
instance.
|
||||
</li>
|
||||
<br>
|
||||
|
||||
<a name="fwmodpath"></a>
|
||||
<li>fwmodpath<br>
|
||||
Set the "modpath" for this intance of FHEMWEB. Used to search .gplot
|
||||
files, pictures, etc. Default is the <a href="#modpath">modpath</a>/FHEM directory.
|
||||
</li>
|
||||
<br>
|
||||
|
||||
<a name="fwcompress"></a>
|
||||
<li>fwcompress<br>
|
||||
Enable compressing the HTML data (default is 1, i.e. yes, use 0 to switch it off).
|
||||
</li>
|
||||
<br>
|
||||
|
||||
<a name="icon"></a>
|
||||
<li>icon<br>
|
||||
Set the icon for a device in the room overview. There is an
|
||||
icon-chooser in FHEMWEB to ease this task. Setting icons for the room
|
||||
itself is indirect: there must exist an icon with the name
|
||||
ico<ROOMNAME>.png in the modpath/fwmodpath directory.
|
||||
</li>
|
||||
<br>
|
||||
|
||||
<a name="reverseLogs"></a>
|
||||
<li>reverseLogs<br>
|
||||
Display the lines from the logfile in a reversed order, newest on the
|
||||
top, so that you dont have to scroll down to look at the latest entries.
|
||||
Note: enabling this attribute will prevent FHEMWEB from streaming
|
||||
logfiles, resulting in a considerably increased memory consumption
|
||||
(about 6 times the size of the file on the disk).
|
||||
</li>
|
||||
<br>
|
||||
|
||||
</ul>
|
||||
|
||||
See also <a href="#room">room</a> and <a href="#group">group</a> attributes.
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -140,3 +140,60 @@ sub HTTPSRV_CGI() {
|
||||
|
||||
|
||||
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="HTTPSRV"></a>
|
||||
<h3>HTTPSRV</h3>
|
||||
<ul>
|
||||
Provides a mini HTTP server plugin for FHEMWEB. It serves files from a given directory.<p>
|
||||
|
||||
HTTPSRV is an extension to <a href="HTTPSRV">FHEMWEB</a>. You must install FHEMWEB to use HTTPSRV.</p>
|
||||
|
||||
<a name="HTTPSRVdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> <infix> <directory> <friendlyname></code><br><br>
|
||||
|
||||
Defines the HTTP server. <code><infix></code> is the portion behind the FHEMWEB base URL (usually
|
||||
<code>http://hostname:8083/fhem</code>), <code><directory></code> is the absolute path the
|
||||
files are served from, and <code><friendlyname></code> is the name displayed in the side menu of FHEMWEB.<p><p>
|
||||
|
||||
Example:
|
||||
<ul>
|
||||
<code>define myJSFrontend HTTPSRV jsf /usr/share/jsfrontend My little frontend</code><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
<a name="HTTPSRVset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
n/a
|
||||
</ul>
|
||||
<br><br>
|
||||
|
||||
<a name="HTTPSRVattr"></a>
|
||||
<b>Attributes</b>
|
||||
<br><br>
|
||||
<ul>
|
||||
<li>directoryindex: if the request is sent with no filename, i.e. the infix (with or without trailing slash) only, the file given in this attribute is loaded. Defaults to <code>index.html</code>.</li>
|
||||
</ul>
|
||||
<br><br>
|
||||
|
||||
<b>Usage information</b>
|
||||
<br><br>
|
||||
<ul>
|
||||
|
||||
The above example on <code>http://hostname:8083/fhem</code> will return the file
|
||||
<code>/usr/share/jsfrontend/foo.html</code> for <code>http://hostname:8083/fhem/jsf/foo.html</code>.
|
||||
If no filename is given, the filename prescribed by the <code>directoryindex</code> attribute is returned.<p>
|
||||
|
||||
Notice: All links are relative to <code>http://hostname:8083/fhem</code>.
|
||||
</ul>
|
||||
<br><br>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -472,3 +472,178 @@ RSS_CGI(){
|
||||
|
||||
|
||||
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="RSS"></a>
|
||||
<h3>RSS</h3>
|
||||
<ul>
|
||||
Provides a freely configurable RSS feed.<p>
|
||||
|
||||
Currently a media RSS feed delivering status pictures in JPEG format is supported. This media
|
||||
RSS feed can be used to feed a status display to a network-enabled photo frame.<p>
|
||||
|
||||
You need to have the perl module <code>GD</code> installed. This module is most likely not
|
||||
available for small systems like Fritz!Box.<p>
|
||||
RSS is an extension to <a href="#FHEMWEB">FHEMWEB</a>. You must install FHEMWEB to use RSS.</p>
|
||||
|
||||
<a name="RSSdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> RSS jpg <hostname> <filename></code><br><br>
|
||||
|
||||
Defines the RSS feed. <code>jpg</code> is a fixed literal to allow for future
|
||||
extensions. <code><hostname></code> is the hostname of the fhem server as
|
||||
seen from the consumer of the RSS feed. <code><filename></code> is the
|
||||
name of the file that contains the <a href="RSSlayout">layout definition</a>.<p>
|
||||
|
||||
Examples:
|
||||
<ul>
|
||||
<code>define FrameRSS RSS jpg host.example.org /etc/fhem/layout</code><br>
|
||||
<code>define MyRSS RSS jpg 192.168.1.222 /var/fhem/conf/layout.txt</code><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
<a name="RSSset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
<code>set <name> rereadcfg</code>
|
||||
<br><br>
|
||||
Rereads the <a href="RSSlayout">layout definition</a> from the file. Useful to enable
|
||||
changes in the layout on-the-fly.
|
||||
<br><br>
|
||||
</ul>
|
||||
|
||||
<a name="RSSattr"></a>
|
||||
<b>Attributes</b>
|
||||
<br><br>
|
||||
<ul>
|
||||
<li>size<br>The dimensions of the JPEG picture in the format
|
||||
<code><width>x<height></code>.</li><br>
|
||||
<li>bg<br>The directory that contains the background pictures (must be in JPEG format).</li><br>
|
||||
<li>tmin<br>The background picture is shown at least <code>tmin</code> seconds,
|
||||
no matter how frequently the RSS feed consumer accesses the page.</li><br>
|
||||
</ul>
|
||||
<br><br>
|
||||
|
||||
<b>Usage information</b>
|
||||
<br><br>
|
||||
<ul>
|
||||
If a least one RSS feed is defined, the menu entry <code>RSS</code> appears in the FHEMWEB
|
||||
side menu. If you click it you get a list of all defined RSS feeds. The URL of any such is
|
||||
RSS feed is <code>http://hostname:port/fhem/rss/name.rss</code> with <code>hostname</code> and
|
||||
<code>name</code> from the RSS feed's <a href="RSSdefine">definition</a> and the <code>port</code>
|
||||
(usually 8083) and literal <code>/fhem</code> from the underlying <a href="#FHEMWEB">FHEMWEB</a>
|
||||
definition.<p>
|
||||
|
||||
Example:
|
||||
<ul><code>http://host.example.org:8083/fhem/rss/FrameRSS.rss</code></ul><p>
|
||||
|
||||
The media RSS feed points to a dynamically generated JPEG picture. The URL of the JPEG picture
|
||||
belonging to the RSS feed is <code>http://hostname:port/fhem/rss/name.jpg</code>, i.e. the URL
|
||||
of the RSS feed with the extension <code>rss</code> changed to <code>jpg</code>.<p>
|
||||
|
||||
Example:
|
||||
<ul><code>http://host.example.org:8083/fhem/rss/FrameRSS.jpg</code></ul><p>
|
||||
|
||||
To render the JPEG picture the current, or, if <code>tmin</code> seconds have elapsed, the next
|
||||
JPEG picture from the directory <code>bg</code> is chosen and scaled to the dimensions given
|
||||
in <code>size</code>. The background is black if no usable JPEG picture can be found. Next the
|
||||
script in the <a href="RSSlayout">layout definition</a> is used to superimpose items on
|
||||
the background.<p>
|
||||
|
||||
You can directly access the URL of the JPEG picture in your browser. Reload the page to see
|
||||
how it works.<p>
|
||||
|
||||
The media RSS feed advertises to refresh after 1 minute (ttl). Some photo frames ignore it and
|
||||
use their preset refresh rate. Go for a photo frame with an adjustable refresh rate (e.g
|
||||
every 5 seconds) if you have the choice!<p>
|
||||
|
||||
This is how the fhem config part might look like:<p>
|
||||
<code>
|
||||
define ui FHEMWEB 8083 global<br><br>
|
||||
|
||||
define FrameRSS RSS jpg host.example.org /etc/fhem/layout<br>
|
||||
attr FrameRSS size 800x600<br>
|
||||
attr FrameRSS bg /usr/share/pictures<br>
|
||||
attr FrameRSS tmin 10<br>
|
||||
</code>
|
||||
|
||||
</ul>
|
||||
|
||||
<a name="RSSlayout"></a>
|
||||
<b>Layout definition</b>
|
||||
<br><br>
|
||||
<ul>
|
||||
The layout definition is a script for placing items on the background. It is read top-down.
|
||||
It consists of layout control commands and items placement commands. Layout control
|
||||
commands define the appearance of subsequent items. Item placement commands actually
|
||||
render items.<p>
|
||||
|
||||
Everything after a # is treated as a comment and ignored. You can fold long lines by
|
||||
putting a \ at the end.<p>
|
||||
|
||||
<i>Layout control commands</i>
|
||||
<ul>
|
||||
<li>font <font><br>Sets the font. <font> is the name of a TrueType font (e.g.
|
||||
<code>Arial</code>) or the full path to a TrueType font
|
||||
(e.g. <code>/usr/share/fonts/truetype/arial.ttf</code>),
|
||||
whatever works on your system.</li><br>
|
||||
|
||||
<li>rgb <color><br>Sets the color. <color> is a 6-digit hex number, every 2 digits
|
||||
determining the red, green and blue color components as in HTML color codes (e.g.
|
||||
<code>FF0000</code> for red, <code>C0C0C0</code> for light gray).</li><br>
|
||||
|
||||
<li>pt <pt><br>Sets the font size in points.</li><br>
|
||||
</ul>
|
||||
|
||||
<i>Item placement commands</i>
|
||||
<ul>
|
||||
<li>text <x> <y> <text><br>Renders the text <text> at the
|
||||
position (<x>, <y>) using the current font, font size and color.
|
||||
(0,0) is the upper left corner. Coordinates equal or
|
||||
greater than 1 are considered to be pixels, coordinates between 0 and 1 are considered to
|
||||
be relative to the total width or height of the picture. You can use
|
||||
<code>{ <a href="#perl"><perl special></a> }</code> for <text> to fully
|
||||
access device readings and do some programming on the fly. See below for examples.</li><br>
|
||||
|
||||
<li>time <x> <y><br>Renders the current time in HH:MM format.</li><br>
|
||||
<li>seconds <x> <y> <format><br>Renders the curent seconds. Maybe usefull for a RSS Clock. With option colon a : </li><br>
|
||||
<li>date <x> <y><br>Renders the current date in DD:MM:YYY format.</li><br>
|
||||
<li>img <x> <y> <s> <imgtype> <srctype> <arg> <br>Renders a picture at the
|
||||
position (<x>, <y>). The <imgtype> is one of <code>gif</code>, <code>jpeg</code>, <code>png</code>.
|
||||
The picture is scaled by the factor <s> (a decimal value). If <srctype> is <code>file</code>, the picture
|
||||
is loaded from the filename <arg>, if <srctype> is <code>url</code>, the picture
|
||||
is loaded from the URL <arg>. You can use
|
||||
<code>{ <a href="#perl"><perl special></a> }</code> for <arg>. See below for example.
|
||||
Notice: do not load the image from URL that is served by fhem as it leads to a deadlock.<br></li>
|
||||
</li><br>
|
||||
</ul>
|
||||
|
||||
This is how a layout definition might look like:<p>
|
||||
<code>
|
||||
font /usr/share/fonts/truetype/arial.ttf # must be a TrueType font<br>
|
||||
rgb c0c0c0 # HTML color notation, RGB<br>
|
||||
pt 48 # font size in points<br>
|
||||
time 0.10 0.90<br>
|
||||
pt 24<br>
|
||||
text 0.10 0.95 { ReadingsVal("MyWeather","temperature","?"). "C" }<br>
|
||||
img 20 530 0.5 png file { "/usr/share/fhem/www/images/weather/" . ReadingsVal("MyWeather","icon","") . ".png" }<br>
|
||||
</code>
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -130,3 +130,75 @@ BS_Parse($$)
|
||||
#############################
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -254,3 +254,63 @@ CUL_FHTTK_Parse($$)
|
||||
#############################
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
<li><a href="#eventMap">eventMap</a></li><br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -176,3 +176,79 @@ USF1000_Parse($$)
|
||||
#############################
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
=end html
|
||||
=cut
|
||||
|
@ -3368,3 +3368,735 @@ CUL_HM_setAttrIfCh($$$$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="CUL_HM"></a>
|
||||
<h3>CUL_HM</h3>
|
||||
<ul>
|
||||
Support for eQ-3 HomeMatic devices via the <a href="#CUL">CUL</a> or the <a
|
||||
href="#HMLAN">HMLAN</a>.<br>
|
||||
<br>
|
||||
<a name="CUL_HMdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code><B>define <name> CUL_HM <6-digit-hex-code|8-digit-hex-code></B></code>
|
||||
|
||||
<br><br>
|
||||
Correct device definition is the key for HM environment simple maintenance.
|
||||
<br>
|
||||
|
||||
Background to define entities:<br>
|
||||
HM devices has a 3 byte (6 digit hex value) HMid - which is key for
|
||||
addressing. Each device hosts one or more channels. HMid for a channel is
|
||||
the device's HMid plus the channel number (1 byte, 2 digit) in hex.
|
||||
Channels should be defined for all multi-channel devices. Channel entities
|
||||
cannot be defined if the hosting device does not exist<br> Note: FHEM
|
||||
mappes channel 1 to the device if it is not defined explicitely. Therefore
|
||||
it does not need to be defined for single channel devices.<br>
|
||||
|
||||
Note: if a device is deleted all assotiated channels will be removed as
|
||||
well. <br> An example for a full definition of a 2 channel switch is given
|
||||
below:<br>
|
||||
|
||||
<ul><code>
|
||||
define livingRoomSwitch CUL_HM 123456<br>
|
||||
define LivingroomMainLight CUL_HM 12345601<br>
|
||||
define LivingroomBackLight CUL_HM 12345602<br><br></code>
|
||||
</ul>
|
||||
|
||||
livingRoomSwitch is the device managing communication. This device is
|
||||
defined prior to channels to be able to setup references. <br>
|
||||
LivingroomMainLight is channel 01 dealing with status of light, channel
|
||||
peers and channel assotiated register. If not defined channel 01 is covered
|
||||
by the device entity.<br> LivingRoomBackLight is the second 'channel',
|
||||
channel 02. Its definition is mandatory to operate this function.<br><br>
|
||||
|
||||
Sender specials: HM threats each button of remotes, push buttons and
|
||||
similar as channels. It is possible (not necessary) to define a channel per
|
||||
button. If all channels are defined access to pairing informatin is
|
||||
possible as well as access to channel related register. Furthermore names
|
||||
make the traces better readable.<br><br>
|
||||
|
||||
define may also be invoked by the <a href="#autocreate">autocreate</a>
|
||||
module, together with the necessary hmClass and subType attributes.
|
||||
Usually you issue a <a href="#CULset">hmPairForSec</a> and press the
|
||||
corresponding button on the device to be paired, or issue a <a
|
||||
href="#CULset">hmPairSerial</a> set command if the device is a receiver
|
||||
and you know its serial number. Autocreate will then create a fhem
|
||||
device and set all necessary attributes. Without pairing the device
|
||||
will not accept messages from fhem. fhem may create the device even if
|
||||
the pairing is not successful. Upon a successful pairing you'll see a
|
||||
CommandAccepted entry in the details section of the CUL_HM device.<br><br>
|
||||
|
||||
If you cannot use autocreate, then you have to specify:<br>
|
||||
<ul>
|
||||
<li>the <6-digit-hex-code>or HMid+ch <8-digit-hex-code><br>
|
||||
It is the unique, hardcoded device-address and cannot be changed (no,
|
||||
you cannot choose it arbitrarily like for FS20 devices). You may
|
||||
detect it by inspecting the fhem log.</li>
|
||||
<li>the hmClass attribute<br>
|
||||
which is either sender or receiver</li>
|
||||
<li>the subType attribute<br>
|
||||
which is one of switch dimmer blindActuator remote sensor swi
|
||||
pushButton threeStateSensor motionDetector keyMatic winMatic
|
||||
smokeDetector</li>
|
||||
</ul>
|
||||
Without these attributes fhem won't be able to decode device messages
|
||||
appropriately. <br><br>
|
||||
|
||||
<b>Notes</b>
|
||||
<ul>
|
||||
<li>If the interface is a CUL device, the <a href="#rfmode">rfmode </a>
|
||||
attribute of the corresponding CUL/CUN device must be set to HomeMatic.
|
||||
Note: this mode is BidCos/Homematic only, you will <b>not</b> receive
|
||||
FS20/HMS/EM/S300 messages via this device. Previously defined FS20/HMS
|
||||
etc devices must be assigned to a different input device (CUL/FHZ/etc).
|
||||
</li>
|
||||
<li>Currently supported device families: remote, switch, dimmer,
|
||||
blindActuator, motionDetector, smokeDetector, threeStateSensor,
|
||||
THSensor, winmatic. Special devices: KS550, HM-CC-TC and the KFM100.
|
||||
</li>
|
||||
<li>Device messages can only be interpreted correctly if the device type is
|
||||
known. fhem will extract the device type from a "pairing request"
|
||||
message, even if it won't respond to it (see <a
|
||||
href="#hmPairSerial">hmPairSerial</a> and <a
|
||||
href="#hmPairForSec">hmPairForSec</a> to enable pairing).
|
||||
As an alternative, set the correct subType and model attributes, for a
|
||||
list of possible subType values see "attr hmdevice ?".</li>
|
||||
<a name="HMAES"></a>
|
||||
<li>The so called "AES-Encryption" is in reality a signing request: if it is
|
||||
enabled, an actor device will only execute a received command, if a
|
||||
correct answer to a request generated by the actor is received. This
|
||||
means:
|
||||
<ul>
|
||||
<li>Reaction to commands is noticably slower, as 3 messages are sent
|
||||
instead of one before the action is processed by the actor.</li>
|
||||
<li>Every command and its final ack from the device is sent in clear,
|
||||
so an outside observer will know the status of each device.</li>
|
||||
<li>The firmware implementation is buggy: the "toggle" event is executed
|
||||
<b>before</b> the answer for the signing request is received, at
|
||||
least by some switches (HM-LC-Sw1-Pl and HM-LC-SW2-PB-FM).</li>
|
||||
<li>The <a href="#HMLAN">HMLAN</a> configurator will answer signing
|
||||
requests by itself, and if it is configured with the 3-byte address
|
||||
of a foreign CCU which is still configurerd with the default
|
||||
password, it is able to answer signing requests correctly.</li>
|
||||
<li>AES-Encryption is not useable with a CUL device as the interface,
|
||||
but it is supported with a HMLAN. Due to the issues above I do not
|
||||
recommend using Homematic encryption at all.</li>
|
||||
</ul>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
</ul><br>
|
||||
|
||||
<a name="CUL_HMset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
Note: devices which are normally send-only (remote/sensor/etc) must be set
|
||||
into pairing/learning mode in order to receive the following commands.
|
||||
<br>
|
||||
<br>
|
||||
|
||||
General commands (available to most hm devices):
|
||||
<ul>
|
||||
<li><B>actiondetect <[hhh:mm]|off></B><a name="CUL_HMactiondetect"></a><br>
|
||||
Supports 'alive' or better 'not alive' detection for devices. [hhh:mm] is the maxumin silent time for the device. Upon no message received in this period an event will be raised "<device> is dead". If the device sends again another notification is posted "<device> is alive". <br>
|
||||
This actiondetect will be autocreated for each device with build in cyclic status report. <br>
|
||||
Controlling entity is a pseudo device "ActionDetector" with HMId "000000". <br>
|
||||
Due to performance considerations the report latency is set to 600sec (10min). It can be controlled by the attribute "actCycle" of "ActionDetector".<br>
|
||||
Once entered to the supervision the HM device has 2 attributes:<br>
|
||||
<ul>
|
||||
actStatus: activity status of the device<br>
|
||||
actCycle: detection period [hhh.mm]<br>
|
||||
</ul>
|
||||
Furthermore the overall function can be viewed checking out the "ActionDetector" entity. Here the status of all entities is present in the READING section. <br>
|
||||
Note: This function can be enabled for devices with non-cyclic messages as well. It is up to the user to enter a reasonable cycletime.
|
||||
</li>
|
||||
<li><B>getConfig</B><a name="CUL_HMgetConfig"></a><br>
|
||||
Will read major configuration items stored in the HM device. Executed
|
||||
on a channel it will read pair Inforamtion, List0, List1 and List3 of
|
||||
the 1st internal peer. Furthermore the peerlist will be retrieved for
|
||||
teh given channel. If executed on a device the command will get the
|
||||
above info or all assotated channels. Not included will be the
|
||||
configuration for additional peers. <br> The command is a shortcut
|
||||
for a selection of other commands.
|
||||
</li>
|
||||
<li><B>getdevicepair</B><a name="CUL_HMgetdevicepair"></a><br>
|
||||
will read the peers (see devicepair) that are assigned to a channel.
|
||||
This command needs to be executed per channel. Information will be
|
||||
stored in the field Peers of the channel (see devicepair for specials
|
||||
about single-channel deivces). <br> For sender the same procedure as
|
||||
described in devicepair is necessary to get a reading. Also note that
|
||||
a proper diaplay will only be possible if define per channel (button)
|
||||
was done - see define. </li>
|
||||
|
||||
<li><B>getpair</B><a name="CUL_HMgetpair"></a><br>
|
||||
read pair information of the device. See also <a
|
||||
href="#CUL_HMpair">pair</a></li>
|
||||
|
||||
<li><B>getRegRaw [List0|List1|List2|List3|List4|List5|List6]
|
||||
<peerChannel> </B><a name="CUL_HMgetRegRaw"></a><br>
|
||||
|
||||
Read registerset in raw format. Description of the registers is beyond
|
||||
the scope of this documentation.<br>
|
||||
|
||||
Registers are structured in so called lists each containing a set of
|
||||
registers.<br>
|
||||
|
||||
List0: device-level settings e.g. CUL-pairing or dimmer thermal limit
|
||||
settings.<br>
|
||||
|
||||
List1: per channel settings e.g. time to drive the blind up and
|
||||
down.<br>
|
||||
|
||||
List3: per 'link' settings - means per peer-channel. This is a lot of
|
||||
data!. It controlls actions taken upon receive of a trigger from the
|
||||
peer.<br>
|
||||
|
||||
List4: settings for channel (button) of a remote<br><br>
|
||||
|
||||
<PeerChannel> paired HMid+ch, i.e. 4 byte (8 digit) value like
|
||||
'12345601'. It is mendatory for List 3 and 4 and can be left out for
|
||||
List 0 and 1. <br>
|
||||
|
||||
'all' can be used to get data of each paired link of the channel. <br>
|
||||
|
||||
'selfxx' can be used to address data for internal channels (associated
|
||||
with the build-in switches if any). xx is the number of the channel in
|
||||
decimal.<br>
|
||||
|
||||
Note1: execution depends on the entity. If List1 is requested on a
|
||||
device rather then a channel the command will retrieve List1 for all
|
||||
channels assotiated. List3 with peerChannel = all will get all link
|
||||
for all channel if executed on a device.<br>
|
||||
|
||||
Note2: for 'sender' see <a href="#CUL_HMremote">remote</a> <br>
|
||||
|
||||
Note3: the information retrieval may take a while - especially for
|
||||
devices with a lot of channels and links. It may be necessary to
|
||||
refresh the web interface manually to view the results <br>
|
||||
|
||||
Note4: the direct buttons on a HM device are hidden by default.
|
||||
Nevertheless those are implemented as links as well. To get access to
|
||||
the 'internal links' it is necessary to issue 'set <name> setReg
|
||||
intKeyVisib 1' or 'set <name> setRegRaw List0 2 81'. Reset it
|
||||
by replacing '81' with '01'<br> example:<br>
|
||||
|
||||
<ul><code>
|
||||
set mydimmer getRegRaw List1<br>
|
||||
set mydimmer getRegRaw List3 all <br>
|
||||
</code></ul>
|
||||
</li>
|
||||
<li><B>pair</B><a name="CUL_HMpair"></a><br>
|
||||
Pair the device again with its known serialNumber (e.g. after a device
|
||||
reset) to the CUL. If paired, devices will report status information to
|
||||
the CUL. If not paired, the device wont respond to requests, and
|
||||
certain status information is also not reported. Paring is on device
|
||||
level and is common for all channels. See also <a
|
||||
href="#CUL_HMgetpair">getPair</a> and <a
|
||||
href="#CUL_HMunpair">unpair</a>.</li>
|
||||
<li><B>regRaw [List0|List1|List2|List3|List4] <addr> <data>
|
||||
<peerChannel> </B><a name="CUL_HMregRaw"></a><br>
|
||||
Will set register for device or channel. See also <a
|
||||
href="#CUL_HMgetRegRaw">getRegRaw</a>.<br> <addr> and
|
||||
<data> are 1 byte values that need to be given in hex.<br>
|
||||
Example:<br>
|
||||
<ul><code>
|
||||
set mydimmer regRaw List1 0B 10 00000000 <br>
|
||||
set mydimmer regRaw List1 0C 00 00000000 <br>
|
||||
</code></ul>
|
||||
will set the max drive time up for a blind actor to 25,6sec</li>
|
||||
<li><B>regSet <regName> <value> <peerChannel></B><a name="CUL_HMregSet"></a><br>
|
||||
For some major register a readable version is implemented supporting
|
||||
register names <regName> and value conversionsing. Only a subset
|
||||
of register can be supproted.<br>
|
||||
<value> is the data in human readable manner that will be written
|
||||
to the register.<br>
|
||||
<peerChannel> is required if this register is defined on a per
|
||||
'devicepair' base. It can be set to '0' other wise.See <a
|
||||
href="CUL_HMgetRegRaw">getRegRaw</a> for full description<br>
|
||||
Supported register for a device can be explored using<br>
|
||||
<ul><code>set regSet ? 0 0</code></ul>
|
||||
Condensed register description will be printed
|
||||
using<br>
|
||||
<ul><code>set regSet <regname> ? 0</code></ul>
|
||||
</li>
|
||||
<li><B>reset</B><a name="CUL_HMreset"></a><br>
|
||||
Factory reset the device. You need to pair it again to use it with
|
||||
fhem.
|
||||
</li>
|
||||
<li><B>sign [on|off]</B><a name="CUL_HMsign"></a><br>
|
||||
Activate or deactivate signing (also called AES encryption, see the <a
|
||||
href="#HMAES">note</a> above). Warning: if the device is attached via
|
||||
a CUL, you won't be able to switch it (or deactivate signing) from
|
||||
fhem before you reset the device directly.
|
||||
</li>
|
||||
<li><B>statusRequest</B><a name="CUL_HMstatusRequest"></a><br>
|
||||
Update device status. For multichannel devices it should be issued on
|
||||
an per channel base
|
||||
</li>
|
||||
<li><B>unpair</B><a name="CUL_HMunpair"></a><br>
|
||||
"Unpair" the device, i.e. make it available to pair with other master
|
||||
devices. See <a href="#CUL_HMpair">pair</a> for description.</li>
|
||||
<li><B>virtual <number of buttons></B><a name="CUL_HMvirtual"></a><br>
|
||||
configures a defined curcuit as virtual remote controll. Then number
|
||||
of button being added is 1 to 255. If the command is issued a second
|
||||
time for the same entity additional buttons will be added. <br>
|
||||
Example for usage:
|
||||
<ul><code>
|
||||
define vRemote CUL_HM 100000 # the selected HMid must not be in use<br>
|
||||
set vRemote virtual 20 # define 20 button remote controll<br>
|
||||
set vRemote_Btn4 devicepair 0 <actorchannel> # pairs Button 4 and 5 to the given channel<br>
|
||||
set vRemote_Btn4 press<br>
|
||||
set vRemote_Btn5 press long<br>
|
||||
</code></ul>
|
||||
see also <a href="#CUL_HMpress">press</a></li>
|
||||
</ul>
|
||||
|
||||
<br>
|
||||
subType (i.e family) dependent commands:
|
||||
<ul>
|
||||
<br>
|
||||
<li>switch
|
||||
<ul>
|
||||
<li><B>on</B> - set the switch on</li>
|
||||
<li><B>off</B> - set the switch off</li>
|
||||
<li><B>on-for-timer <sec></B><a name="CUL_HMonForTimer"></a> -
|
||||
set the switch on for the given seconds [0-85825945].<br> Note:
|
||||
off-for-timer like FS20 is not supported. It needs to be programmed
|
||||
on link level.</li>
|
||||
<li><B>on-till <time></B><a name="CUL_HMonTill"></a> - set the switch on for the given end time.<br>
|
||||
<ul><code>set <name> on-till 20:32:10<br></code></ul>
|
||||
Currently a max of 24h is supported with endtime.<br></li>
|
||||
<li><B>toggle</B> - toggle the switch.</li>
|
||||
</ul>
|
||||
<br></li>
|
||||
<li>dimmer, blindActuator
|
||||
<ul>
|
||||
<li><B>0 - 100 [on-time] [ramp-time]</B><br>
|
||||
set the actuator to the given value (in percent)
|
||||
with a resolution of 0.5.<br>
|
||||
Optional for dimmer on-time and ramp time can be choosen, both in seconds with 0.1s granularity.<br>
|
||||
On-time is analog "on-for-timer".<br>
|
||||
Ramp-time default is 2.5s, 0 means instantanous<br>
|
||||
</li>
|
||||
<li><B>on</B> set level to 100%<br>
|
||||
<li><B>off</B> set level to 0%<br></li>
|
||||
<li><B>toggle</B> - toggle between off and the last on-value
|
||||
</li>
|
||||
<li><B><a href="#CUL_HMonForTimer">on-for-timer <sec></a></B> - Dimmer only! <br>
|
||||
<li><B><a href="#CUL_HMonForTimer">on-till <time></a></B> - Dimmer only! <br>
|
||||
<li><B>stop</B> - stop motion or dim ramp</li>
|
||||
</ul>
|
||||
<br></li>
|
||||
<li>remotes, pushButton<a name="CUL_HMremote"></a><br>
|
||||
This class of devices does not react on requests unless they are put
|
||||
to learn mode. FHEM obeys this behavior by stacking all requests until
|
||||
learn mode is detected. Manual interaction of the user is necessary to
|
||||
activate learn mode. Whether commands are pending is reported on
|
||||
device level with parameter 'protCmdPend'.
|
||||
<ul>
|
||||
<li><B>devicepair <btn_no> <hmDevice> [single|dual]
|
||||
[set|unset] [actor|remote]</B><a name="CUL_HMdevicepair"></a><br>
|
||||
|
||||
Pair/unpair will establish a connection between a sender-channel and
|
||||
an actuator-channel called link in HM nomenclatur. Trigger from
|
||||
sender-channel, e.g. button press, will be processed by the
|
||||
actuator-channel without CCU interaction. Sender-channel waits for an
|
||||
acknowledge of each actuator paired to it. Positive indication will be
|
||||
given once all actuator responded. <br>
|
||||
|
||||
Sender must be set into learning mode after command execution. FHEM
|
||||
postpones the commands until then.<br>
|
||||
|
||||
devicepair can be repeated for an existing devicepair. This will cause
|
||||
parameter reset to HM defaults for this link.<br>
|
||||
|
||||
Even though the command is executed on a remote or push-button it will
|
||||
as well take effect on the actuator directly. Both sides' pairing is
|
||||
virtually independant and has different impact on sender and receiver
|
||||
side.<br>
|
||||
|
||||
Devicepairing of one actuator-channel to multiple sender-channel as
|
||||
well as one sender-channel to multiple Actuator-channel is
|
||||
possible.<br>
|
||||
|
||||
<hmDevice> is the actuator-channel to be paired.<br>
|
||||
|
||||
<btn_no> is the sender-channel (button) to be paired. If
|
||||
'single' is choosen buttons are counted from 1. For 'dual' btn_no is
|
||||
the number of the Button-pair to be used. I.e. '3' in dual is the
|
||||
3rd button pair correcponding to button 5 and 6 in single mode.<br>
|
||||
|
||||
If the command is executed on a channel the btn_no is ignored.<br>
|
||||
|
||||
[single|dual]: this mode impacts the default behavior of the
|
||||
Actuator upon using this button. E.g. a dimmer can be learned to a
|
||||
single button or to a button pair. <br>
|
||||
|
||||
'dual' (default) Button pairs two buttons to one actuator. With a
|
||||
dimmer this means one button for dim-up and one for dim-down. <br>
|
||||
|
||||
'single' uses only one button of the sender. It is useful for e.g. for
|
||||
simple switch actuator to toggle on/off. Nevertheless also dimmer can
|
||||
be learned to only one button. <br>
|
||||
|
||||
'set' will setup pairing for the channels<br>
|
||||
|
||||
'unset' will remove the pairing for the channels<br>
|
||||
|
||||
[actor|remote|both] limits the execution to only actor or only remote.
|
||||
This gives the user the option to redo the pairing on the remote
|
||||
channel while the settings in the actor will not be removed.<br>
|
||||
|
||||
Example:<ul> <code>
|
||||
set myRemote devicepair 2 mySwActChn single set # pair second button to an actuator channel<br>
|
||||
set myRmtBtn devicepair 0 mySwActChn single set #myRmtBtn is a button of the remote. '0' is not processed here<br>
|
||||
set myRemote devicepair 2 mySwActChn dual set #pair button 3 and 4<br>
|
||||
set myRemote devicepair 3 mySwActChn dual unset #remove pairing for button 5 and 6<br>
|
||||
set myRemote devicepair 3 mySwActChn dual unset aktor #remove pairing for button 5 and 6 in actor only<br>
|
||||
set myRemote devicepair 3 mySwActChn dual set remote #pair button 5 and 6 on remote only. Link settings il mySwActChn will be maintained<br>
|
||||
</code></ul>
|
||||
</li>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
</li>
|
||||
<li>virtual<a name="CUL_HMvirtual"></a><br>
|
||||
<ul>
|
||||
<li><B><a href="#CUL_HMdevicepair">devicepair</a></B> see remote</li>
|
||||
<li><B>press [long|short]<a name="CUL_HMpress"></a></B>
|
||||
simulates a button press short (default) or long. Note that the current
|
||||
implementation will not specify the duration for long. Only one trigger
|
||||
will be sent of type "long".
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<li>smokeDetector<br>
|
||||
Note: All these commands work right now only if you have more then one
|
||||
smoekDetector, and you paired them to form a group. For issuing the
|
||||
commands you have to use the master of this group, and currently you
|
||||
have to guess which of the detectors is the master.
|
||||
<ul>
|
||||
<li><B>test</B> - execute a network test</li>
|
||||
<li><B>alarmOn</B> - initiate an alarm</li>
|
||||
<li><B>alarmOff</B> - switch off the alarm</li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<li>4Dis (HM-PB-4DIS-WM)
|
||||
<ul>
|
||||
<li><B>text <btn_no> [on|off] <text1> <text2></B><br>
|
||||
Set the text on the display of the device. To this purpose issue
|
||||
this set command first (or a number of them), and then choose from
|
||||
the teach-in menu of the 4Dis the "Central" to transmit the data.
|
||||
Example:
|
||||
<ul><code>
|
||||
set 4Dis text 1 on On Lamp<br>
|
||||
set 4Dis text 1 off Kitchen Off<br>
|
||||
</code></ul>
|
||||
</ul></li>
|
||||
<br></li>
|
||||
|
||||
<li>Climate-Control (HM-CC-TC)
|
||||
<ul>
|
||||
<li>day-temp <tmp><br>
|
||||
night-temp <tmp><br>
|
||||
party-temp <tmp><br>
|
||||
desired-temp <tmp><br>
|
||||
Set different temperatures. Temp must be between 6 and 30
|
||||
Celsius, and precision is half a degree.</li>
|
||||
<li>tempListSat HH:MM temp ... 24:00 temp<br>
|
||||
tempListSun HH:MM temp ... 24:00 temp<br>
|
||||
tempListMon HH:MM temp ... 24:00 temp<br>
|
||||
tempListTue HH:MM temp ... 24:00 temp<br>
|
||||
tempListThu HH:MM temp ... 24:00 temp<br>
|
||||
tempListWed HH:MM temp ... 24:00 temp<br>
|
||||
tempListFri HH:MM temp ... 24:00 temp<br>
|
||||
Specify a list of temperature intervals. Up to 24 intervals can be
|
||||
specified for each week day, the resolution is 10 Minutes. The
|
||||
last time spec must always be 24:00.<br>
|
||||
Example: set th tempListSat 06:00 19 23:00 22.5 24:00 19<br>
|
||||
Meaning: until 6:00 temperature shall be 19, from then until 23:00 temperature shall be
|
||||
22.5, thereafter until midnight, 19 degrees celsius is desired.</li>
|
||||
<li>displayMode [temp-only|temp-hum]<br>
|
||||
displayTemp [actual|setpoint]<br>
|
||||
displayTempUnit [celsius|fahrenheit]<br>
|
||||
controlMode [manual|auto|central|party]<br>
|
||||
decalcDay <day></li>
|
||||
</ul></li><br>
|
||||
|
||||
<li>OutputUnit (HM-OU-LED16)
|
||||
<ul>
|
||||
<li><B>led [off|red|green|yellow]</B><br>
|
||||
switches the LED of the channel to the color. If the command is
|
||||
executed on a device it will set all LEDs to the specified
|
||||
color.<br>
|
||||
For Expert all LEDs can be set individual by providing a 8-digit hex number to the device.<br></li>
|
||||
<li><B>ilum <brightness><duration> </B><br>
|
||||
<brightness> [0-15] of backlight.<br>
|
||||
<duration> [0-127] in sec. 0 is permanent 'on'.<br>
|
||||
</li>
|
||||
</ul><br></li>
|
||||
|
||||
<li>OutputUnit (HM-OU-CFM-PL)
|
||||
<ul>
|
||||
<li><B>led <color>[,<color>..]</B><br>
|
||||
Possible colors are [redL|greenL|yellowL|redS|greenS|yellowS]. A
|
||||
sequence of colors can be given separating the color entries by ','.
|
||||
White spaces must not be used in the list. 'S' indicates short and
|
||||
'L' long ilumination. <br></li>
|
||||
<li><B>playTone <MP3No>[,<MP3No>..]</B><br>
|
||||
Play a series of tones. List is to be entered separated by ','. White
|
||||
spaces must not be used in the list.<br></li>
|
||||
</ul><br></li>
|
||||
|
||||
<li>HM-RC-19xxx
|
||||
<ul>
|
||||
<li><B>alarm <count></B><br>
|
||||
issue an alarm message to the remote<br></li>
|
||||
<li><B>service <count></B><br>
|
||||
issue an service message to the remote<br></li>
|
||||
<li><B>symbol <symbol> [set|unset]</B><br>
|
||||
activate a symbol as available on the remote.<br></li>
|
||||
<li><B>beep [off|1|2|3]</B><br>
|
||||
activate tone<br></li>
|
||||
<li><B>backlight [off|on|slow|fast]</B><br>
|
||||
activate backlight<br></li>
|
||||
<li><B>display <text> comma unit tone backlight <symbol(s)>
|
||||
</B><br>
|
||||
control display of the remote<br>
|
||||
<text> : up to 5 chars <br>
|
||||
comma : 'comma' activates the comma, 'no' leaves it off <br>
|
||||
[unit] : set the unit symbols.
|
||||
[off|Proz|Watt|x3|C|x5|x6|x7|F|x9|x10|x11|x12|x13|x14|x15]. Currently
|
||||
the x3..x15 display is not tested. <br>
|
||||
|
||||
tone : activate one of the 3 tones [off|1|2|3]<br>
|
||||
|
||||
backlight: activate backlight flash mode [off|on|slow|fast]<br>
|
||||
|
||||
<symbol(s)> activate symbol display. Multople symbols can be
|
||||
acticated at the same time, concatinating them comma separated. Don't
|
||||
use spaces here. Possiblesymbols are
|
||||
|
||||
[bulb|switch|window|door|blind|scene|phone|bell|clock|arrowUp|arrowDown]<br><br>
|
||||
Example:
|
||||
<ul><code>
|
||||
# "hello" in display, symb bulb on, backlight, beep<br>
|
||||
set FB1 display Hello no off 1 on bulb<br>
|
||||
# "1234,5" in display with unit 'W'. Symbols scene,phone,bell and
|
||||
# clock are active. Backlight flashing fast, Beep is second tone<br>
|
||||
set FB1 display 12345 comma Watt 2 fast scene,phone,bell,clock
|
||||
</ul></code>
|
||||
</li>
|
||||
</ul><br></li>
|
||||
|
||||
<li>keyMatic<br><br>
|
||||
<ul>The Keymatic uses the AES signed communication. Therefore the control
|
||||
of the Keymatic is only together with the HM-LAN adapter possible. But
|
||||
the CUL can read and react on the status information of the
|
||||
Keymatic.</ul><br>
|
||||
<ul>
|
||||
<li><B>lock</B><br>
|
||||
The lock bolt moves to the locking position<br></li>
|
||||
<li><B>unlock [sec]</B><br>
|
||||
The lock bolt moves to the unlocking position.<br> [sec]: Sets the
|
||||
delay in seconds after the lock automatically locked again.<br>0 -
|
||||
65535 seconds</li>
|
||||
<li><B>open [sec]</B><br>
|
||||
Unlocked the door so that the door can be opened.<br>
|
||||
[sec]: Sets the delay in seconds after the lock automatically locked
|
||||
again.<br>0 - 65535 seconds</li>
|
||||
<li><B>inhibit [on|off]</B><br>
|
||||
Block / unblock all directly paired remotes and the hardware buttons of the
|
||||
keyMatic. If inhibit set on, the door lock drive can be controlled only by
|
||||
FHEM.<br><br>
|
||||
Examples:
|
||||
<ul><code>
|
||||
# Lock the lock<br>
|
||||
set keymatic lock<br><br>
|
||||
# open the door and relock the lock after 60 seconds<br>
|
||||
set keymatic unlock 60
|
||||
</ul></code>
|
||||
</li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
<br>
|
||||
Debugging:
|
||||
<ul>
|
||||
<li><B>raw <data> ...</B><br>
|
||||
Only needed for experimentation.
|
||||
send a list of "raw" commands. The first command will be
|
||||
immediately sent, the next one after the previous one is acked by
|
||||
the target. The length will be computed automatically, and the
|
||||
message counter will be incremented if the first two charcters are
|
||||
++. Example (enable AES):<pre>
|
||||
set hm1 raw ++A001F100001234560105000000001\
|
||||
++A001F10000123456010802010AF10B000C00\
|
||||
++A001F1000012345601080801\
|
||||
++A001F100001234560106</pre>
|
||||
</li>
|
||||
</ul>
|
||||
</ul><br>
|
||||
|
||||
<a name="CUL_HMget"></a>
|
||||
<b>Get</b><br>
|
||||
<ul>
|
||||
<li><B>param <paramName></B><br>
|
||||
returns the content of the relevant parameter for the entity. <br>
|
||||
Note: if this command is executed on a channel and 'model' is
|
||||
requested the content hosting device's 'model' will be returned.
|
||||
</li>
|
||||
<li><B>reg <addr> <list> <peerID></B><br>
|
||||
returns the value of a register. The data is taken from the storage in
|
||||
FHEM. It is not read again. If registercontent is not present at this
|
||||
point in time please use getReg in advance.<br>
|
||||
|
||||
<addr> address in hex of the register. Registername can be used alternaly if available in FHEM.<br>
|
||||
<list> list from which the register is taken. If rgistername is used list is ignored and can be set to 0.<br>
|
||||
<peerID> identifies the registerbank in case of list3 and list4. It an be set to dummy if not used.<br>
|
||||
</li>
|
||||
<li><B>regList</B><br>
|
||||
returns a list of register that are implemented in FHEM for this device.<br>
|
||||
</li>
|
||||
<br></ul>
|
||||
|
||||
<a name="CUL_HMattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#eventMap">eventMap</a></li>
|
||||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||||
<li><a href="#ignore">ignore</a></li>
|
||||
<li><a href="#dummy">dummy</a></li>
|
||||
<li><a href="#showtime">showtime</a></li>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
<li><a name="hmClass">hmClass</a>,
|
||||
<a name="model">model</a>,
|
||||
<a name="subType">subType</a><br>
|
||||
These attributes are set automatically after a successful pairing.
|
||||
They are not supposed to be set by hand, and are necessary in order to
|
||||
correctly interpret device messages or to be able to send them.</li>
|
||||
<li><a name="rawToReadable">rawToReadable</a><br>
|
||||
Used to convert raw KFM100 values to readable data, based on measured
|
||||
values. E.g. fill slowly your container, while monitoring the
|
||||
values reported with <a href="#inform">inform</a>. You'll see:
|
||||
<ul>
|
||||
10 (at 0%)<br>
|
||||
50 (at 20%)<br>
|
||||
79 (at 40%)<br>
|
||||
270 (at 100%)<br>
|
||||
</ul>
|
||||
Apply these values with: "attr KFM100 rawToReadable 10:0 50:20 79:40 270:100".
|
||||
fhem will do a linear interpolation for values between the bounderies.
|
||||
</li>
|
||||
<li><a name="unit">unit</a><br>
|
||||
set the reported unit by the KFM100 if rawToReadable is active. E.g.<br>
|
||||
attr KFM100 unit Liter
|
||||
</li>
|
||||
</ul>
|
||||
<br>
|
||||
<a name="CUL_HMevents"></a>
|
||||
<b>Generated events:</b>
|
||||
<ul>
|
||||
<li>KS550/HM-WDS100-C6-O:<br>
|
||||
T: $t H: $h W: $w R: $r IR: $ir WD: $wd WDR: $wdr S: $s B: $b
|
||||
<li>HM-CC-TC:<br>
|
||||
T: $t H: $h<br>
|
||||
temperature $t<br>
|
||||
humidity $h<br>
|
||||
actuator $vp %<br>
|
||||
desired-temp $t<br>
|
||||
desired-temp-ack $t<br>
|
||||
tempList$wd hh:mm $t hh:mm $t ...<br>
|
||||
ValveErrorPosition $dname $vep %<br>
|
||||
ValveOffset $dname $of %<br>
|
||||
windowopentemp-$tchan $t (sensor:$tdev)<br>
|
||||
<li>HM-CC-VD:<br>
|
||||
actuator $vp %<br>
|
||||
motor [opening|closing|blocked|loose|adjusting range too small|ok]<br>
|
||||
battery [low|ok]<br>
|
||||
ValveErrorPosition $vep %<br>
|
||||
ValveOffset $dname $of %<br>
|
||||
<li>KFM100:<br>
|
||||
rawValue $v<br>
|
||||
Sequence $s<br>
|
||||
$cv $unit<br>
|
||||
<li>switch/dimmer/blindActuator:<br>
|
||||
deviceMsg [on|off|$val %]<br>
|
||||
poweron [on|off|$val]<br>
|
||||
<li>dimmer:<br>
|
||||
dim: [up|down|stop]<br>
|
||||
<li>HM-LC-BL1-PB-FM:<br>
|
||||
motor: [opening|closing]<br>
|
||||
<li>remote/pushButton<br>
|
||||
<ul> (to $dest) is added if the button is peered and does not send to broadcast<br>
|
||||
Release is provided for peered channels only</ul>
|
||||
Btn$x onShort<br>
|
||||
Btn$x offShort<br>
|
||||
Btn$x onLong $counter<br>
|
||||
Btn$x offLong $counter<br>
|
||||
Btn$x onLongRelease $counter<br>
|
||||
Btn$x offLongRelease $counter<br>
|
||||
Btn$x onShort (to $dest)<br>
|
||||
Btn$x offShort (to $dest)<br>
|
||||
Btn$x onLong $counter (to $dest)<br>
|
||||
Btn$x offLong $counter (to $dest)<br>
|
||||
Btn$x onLongRelease $counter (to $dest)<br>
|
||||
Btn$x offLongRelease $counter (to $dest)<br>
|
||||
battery: [low|ok]<br>
|
||||
<li>swi<br>
|
||||
Btn$x toggle<br>
|
||||
Btn$x toggle (to $dest)<br>
|
||||
battery: [low|ok]<br>
|
||||
<li>motionDetector<br>
|
||||
brightness:$b<br>
|
||||
alive<br>
|
||||
motion<br>
|
||||
cover closed<br>
|
||||
cover open<br>
|
||||
<li>smokeDetector<br>
|
||||
on<br>
|
||||
smoke_detect on<br>
|
||||
all-clear<br>
|
||||
alive<br>
|
||||
test $t<br>
|
||||
<li>threeStateSensor (all)<br>
|
||||
sabotage<br>
|
||||
alive<br>
|
||||
<li>threeStateSensor (HM-SEC-WDS)<br>
|
||||
contact wet<br>
|
||||
contact damp<br>
|
||||
contact dry<br>
|
||||
<li>threeStateSensor (generic)<br>
|
||||
contact closed<br>
|
||||
contact open<br>
|
||||
contact tilted<br>
|
||||
<li>THSensor<br>
|
||||
T: $t H: $h<br>
|
||||
temperature $t<br>
|
||||
humidity $h<br>
|
||||
<li>WDC7000<br>
|
||||
T: $t H: $h AP: $ap<br>
|
||||
temperature $t<br>
|
||||
humidity $h<br>
|
||||
airpress $ap<br>
|
||||
<li>winMatic<br>
|
||||
contact closed<br>
|
||||
contact open<br>
|
||||
contact tilted<br>
|
||||
contact movement_tilted<br>
|
||||
contact movement_closed<br>
|
||||
contact lock_on<br>
|
||||
airing: $air<br>
|
||||
course: tilt<br>
|
||||
course: close<br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -343,3 +343,142 @@ CUL_IR_Attr(@)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="CUL_IR"></a>
|
||||
<h3>CUL_IR</h3>
|
||||
<ul>
|
||||
|
||||
The CUL_IR module interprets Infrared messages received by the CUN/CUNO/CUNOv2/TuxRadio.
|
||||
Those devices can receive Infrared Signals from basically any Remote controller and will transform
|
||||
that information in a so called Button-Code <br><br>
|
||||
|
||||
|
||||
<a name="CUL_IRdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> CUL_IR <<a href="#IODev">IODev</a>></code> <br>
|
||||
<br>
|
||||
<<a href="#IODev">IODev</a>> is the devicename of the IR-receivung device, e.g. CUNO1.<br><br>
|
||||
|
||||
Your definition should look like E.g.:
|
||||
<pre>
|
||||
define IR-Dev CUL_IR CUNO1</pre>
|
||||
</ul>
|
||||
|
||||
<a name="CUL_IRset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
<a name="irLearnForSec"></a>
|
||||
<li>irLearnForSec<br>
|
||||
Sets the CUL_IR device in an IR-Code Learning mode for the given seconds. Any received IR-Code will
|
||||
be stored as a Button attribute for this devices. The name of these attributes is dependent on the two
|
||||
attributes <a href="#CUL_IRattr">learncount</a> and <a href="#CUL_IRattr">learnprefix</a>.<br>
|
||||
Attention: Before learning IR-Codes the CUL_IR device needs to be set in IR-Receiving mode
|
||||
by modifying the <a href="#irReceive">irReceive</a> attribute.
|
||||
</li>
|
||||
<a name="irSend"></a>
|
||||
<li>irSend<br>
|
||||
Sends out IR-commands via the connected IODev. The IR-command can be specified as buttonname according
|
||||
to <a href="#Button.*">Button.*</a> or as IR-Code directly. If a buttonname is specified, the
|
||||
corresponding IR-Code will be sent out.<br>
|
||||
Example: <br>
|
||||
<pre>set IR-Dev irSend ButtonA001 </pre>
|
||||
If defining an IR-Code directly the following Code-Syntax needs to be followed:<br>
|
||||
<pre>IRCode: <PP><AAAA><CCCC><FF> </pre>
|
||||
with P = Protocol; A = Address; C = Command; F = Flags<br>
|
||||
With the Flags you can modify IR-Repetition. Flags between 00-0E will produce
|
||||
0-15 IR-Repetitions.
|
||||
You can type the IR-Code as plain as above, or with a heading "I" as learnt for the buttons.<br>
|
||||
Example: <br>
|
||||
<code>set IR-Dev irSend 0A07070F0F02<br>
|
||||
set IR-Dev irSend I0A07070F0F00 </code>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<a name="CUL_IRget"></a>
|
||||
<b>Get</b>
|
||||
<ul>N/A</ul>
|
||||
|
||||
<a name="CUL_IRattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<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="#irReceive">irReceive</a><br>
|
||||
Configure the IR Transceiver of the <<a href="#IODev">IODev</a>> (the CUNO1). Available
|
||||
arguments are:
|
||||
<ul>
|
||||
<li>OFF<br>
|
||||
Switching off the reception of IR signals. This is the default.
|
||||
|
||||
<li>ON<br>
|
||||
Switching on the reception of IR signals. This is WITHOUT filtering repetitions. This is
|
||||
not recommended as many remote controls do repeat their signals.
|
||||
|
||||
<li>ON_NR<br>
|
||||
Switching on the reception of IR signals with filtering of repetitions. This is
|
||||
the recommended modus operandi.
|
||||
</ul>
|
||||
</li><br>
|
||||
|
||||
<li><a name="Button.*"></a>Button.*<br>
|
||||
Button.* is the wildcard for all learnt IR-Codes. IR-Codes are learnt as Button-Attributes.
|
||||
The name for a learnt Button - IR-Code is compiled out of three elements:<br>
|
||||
<pre>
|
||||
Button<learnprefix><learncount>
|
||||
</pre>
|
||||
When the CUL_IR device is set into <a href="#irLearnForSec">learning mode</a> it will generate a
|
||||
new button-attribute for each new IR-Code received.This is done according to the following syntax:<br>
|
||||
<pre>
|
||||
<Button-Attribute-Name> <IR-Code></pre>
|
||||
Examples of learnt button-attributes with EMPTY <learnprefix> and <learncount> starting from 1:<br>
|
||||
<pre>
|
||||
Button001 I02029A000000
|
||||
Button002 I02029A000001</pre>
|
||||
To make sure that something happens when this IR-code is received later on one has to modify the attribute
|
||||
and to add commands as attribute values.
|
||||
Examples:
|
||||
<pre>
|
||||
Button001 I02029A000000 set WZ_Lamp on
|
||||
Button002 I02029A000001 set Switch on</pre>
|
||||
The syntax for this is:
|
||||
<pre>
|
||||
attr <device-name> <attribute-name> <IR-Code> <command>
|
||||
</pre>
|
||||
</li>
|
||||
<li><a name="Group.*"></a>Group.*<br>
|
||||
Group.* is the wildcard for IR-Code groups. With these attributes one can define
|
||||
IR-Code parts, which may match to several Button-IR-Codes.<br>
|
||||
This is done by defining group-attributes that contain only parts of the IR-Code.
|
||||
The syntax is:
|
||||
<pre>
|
||||
<Group-Attribute-Name> <IR-Code></pre>
|
||||
Examples of a group-attribute is:<br>
|
||||
<pre>
|
||||
Group001 I02029A</pre>
|
||||
With this all IR-Codes starting with I02029A will match the Group001.
|
||||
</li><br>
|
||||
<li><a name="learncount"></a>learncount<br>
|
||||
learncount is used to store the next button-code-number that needs to be learned.
|
||||
By manually modifying this attribute new button sequences can be arranged.
|
||||
</li><br>
|
||||
<li><a name="learnprefix"></a>learnprefix<br>
|
||||
learnprefix is a string which will be added to the button-attribute-name. <br>
|
||||
A button-attribute-name is constructed by:
|
||||
<pre>
|
||||
Button<learnprefix><learncount> </pre>
|
||||
If learnprefix is empty the button-attribute-name only contains the term
|
||||
"Button" and the actual number of <a href="#learncount">learncount</a>.
|
||||
</li><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -445,3 +445,122 @@ eib_name2hex($)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="EIB"></a>
|
||||
<h3>EIB / KNX</h3>
|
||||
<ul>
|
||||
EIB/KNX is a standard for building automation / home automation.
|
||||
It is mainly based on a twisted pair wiring, but also other mediums (ip, wireless) are specified.
|
||||
|
||||
While the module <a href="#TUL">TUL</a> represents the connection to the EIB network,
|
||||
the EIB modules represent individual EIB devices. This module provides a basic set of operations (on, off, on-till, etc.)
|
||||
to switch on/off EIB devices. Sophisticated setups can be achieved by combining a number of
|
||||
EIB module instances or by sending raw hex values to the network (set <devname> raw <hexval>).
|
||||
|
||||
EIB/KNX defines a series of Datapoint Type as standard data types used
|
||||
to allow general interpretation of values of devices manufactured by diferent companies.
|
||||
This datatypes are used to interpret the status of a device, so the state in FHEM will then
|
||||
show the correct value.
|
||||
|
||||
<br><br>
|
||||
<a name="EIBdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> EIB <main group> [<additional group> ..]</code>
|
||||
<br><br>
|
||||
|
||||
Define an EIB device, connected via a <a href="#TUL">TUL</a>. The
|
||||
<group> parameters are either a group name notation (0-15/0-15/0-255) or the hex representation of the value (0-f0-f0-ff).
|
||||
The <main group> is used for sending of commands to the EIB network.
|
||||
The state of the instance will be updated when a new state is received from the network for any of the given groups.
|
||||
This is usefull for example for toggle switches where a on command is send to one group and the real state (on or off) is
|
||||
responded back on a second group.
|
||||
|
||||
For actors and sensors the
|
||||
<a href="#autocreate">autocreate</a> module may help.<br>
|
||||
|
||||
Example:
|
||||
<ul>
|
||||
<code>define lamp1 EIB 0/10/12</code><br>
|
||||
<code>define lamp1 EIB 0/10/12 0/0/5</code><br>
|
||||
<code>define lamp1 EIB 0A0C</code><br>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="EIBset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
<code>set <name> <value> [<time> g<groupnr>]</code><br>
|
||||
where value one of:
|
||||
<li><b>on</b> switch on device
|
||||
<li><b>off</b> switch off device
|
||||
<li><b>on-for-timer</b> <secs> switch on the device for the given time. After the specified seconds a switch off command is sent.
|
||||
<li><b>on-till</b> <time spec> switches the device on. The device will be switched off at the given time.
|
||||
<li><b>value</b> <hexvalue> sends the given value as raw data to the device.
|
||||
|
||||
<br>Example:
|
||||
<ul><code>
|
||||
set lamp1 on<br>
|
||||
set lamp1 off<br>
|
||||
set lamp1 on-for-timer 10<br>
|
||||
set lamp1 on-till 13:15:00<br>
|
||||
set lamp1 value 234578<br>
|
||||
</code></ul>
|
||||
</li>
|
||||
|
||||
When as last argument a g<groupnr> is present, the command will be sent
|
||||
to the EIB group indexed by the groupnr (starting by 1, in the order as given in Define).
|
||||
<br>Example:
|
||||
<ul><code>
|
||||
define lamp1 EIB 0/10/01 0/10/02<br>
|
||||
set lamp1 on g2 (will send "on" to 0/10/02)
|
||||
</code></ul>
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="EIBattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#eventMap">eventMap</a></li>
|
||||
<li><a href="#webCmd">webCmd</a></li>
|
||||
<li><a href="#IODev">IODev</a></li>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||||
<li><a href="#ignore">ignore</a></li>
|
||||
<li><a href="#dummy">dummy</a></li>
|
||||
<li><a href="#showtime">showtime</a></li>
|
||||
<li><a href="#model">model</a>
|
||||
set the model according to the datapoint types defined by the (<a href="http://www.sti.uniurb.it/romanell/110504-Lez10a-KNX-Datapoint%20Types%20v1.5.00%20AS.pdf" target="_blank">EIB / KNX specifications</a>).<br>
|
||||
The device state in FHEM is interpreted and shown according to the specification.
|
||||
<ul>
|
||||
<li>dpt5</li>
|
||||
<li>percent</li>
|
||||
<li>dpt7</li>
|
||||
<li>length-mm</li>
|
||||
<li>current-mA</li>
|
||||
<li>brightness</li>
|
||||
<li>timeperiod-ms</li>
|
||||
<li>timeperiod-min</li>
|
||||
<li>timeperiod-h</li>
|
||||
<li>dpt9</li>
|
||||
<li>tempsensor</li>
|
||||
<li>lightsensor</li>
|
||||
<li>dpt10</li>
|
||||
<li>time</li>
|
||||
<li>dpt11</li>
|
||||
<li>date</li>
|
||||
<li>dpt12</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -540,3 +540,218 @@ EnOcean_A5Cmd($$$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="EnOcean"></a>
|
||||
<h3>EnOcean</h3>
|
||||
<ul>
|
||||
Devices sold by numerous hardware verndors (e.g. Eltako, Peha, etc), using
|
||||
the RF Protocol provided by the EnOcean Alliance.
|
||||
<br><br>
|
||||
<a name="EnOceandefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> EnOcean <ID></code>
|
||||
<br><br>
|
||||
|
||||
Define an EnOcean device, connected via a <a href="#TCM">TCM</a>. The
|
||||
<ID> parameter is an 8 digit hex number. For remotes and sensors the
|
||||
<a href="#autocreate">autocreate</a> module may help you.<br>
|
||||
|
||||
Example:
|
||||
<ul>
|
||||
<code>define switch1 EnOcean ffc54500</code><br>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="EnOceanset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
<li>MD15 commands. Note: The command is not sent until the MD15
|
||||
wakes up and sends a mesage, usually every 10 minutes.
|
||||
<ul>
|
||||
<li>actuator <value><br>
|
||||
Set the actuator to the specifed percent value (0-100)</li>
|
||||
<li>desired-temp <value><br>
|
||||
Use the builtin PI regulator, and set the desired temperature to the
|
||||
specified degree. The actual value will be taken from the temperature
|
||||
reported by the MD15 or from the attribute actualTemp if it is set</li>
|
||||
<li>unattended<br>
|
||||
Do not regulate the MD15.</li>
|
||||
</ul></li>
|
||||
|
||||
<li>subType dimmCtrl, tested with ElTako Dimmer only
|
||||
<ul>
|
||||
<li>teach<br>
|
||||
initiate teach-in mode
|
||||
<li>dimm percent [time 01-FF FF:slowest] [on/off]<br>
|
||||
issue dim command.
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<li>all other:
|
||||
<ul>
|
||||
<code>set switch1 <value></code>
|
||||
<br><br>
|
||||
where <code>value</code> is one of A0,AI,B0,BI,C0,CI,D0,DI, combinations of
|
||||
these and released, in fact we are trying to emulate a PTM100 type remote.
|
||||
<br>
|
||||
|
||||
If you define an <a href="#eventMap">eventMap</a> attribute with on/off,
|
||||
then you'll be able to easily set the device from the <a
|
||||
href="#FHEMWEB">WEB</a> frontend.<br><br>
|
||||
In order to control devices, you cannot reuse the ID's of other devices
|
||||
(like remotes), instead you have to create your own, which must be in the
|
||||
allowed ID-Range of the underlying IO device. For this first query the
|
||||
TCM with the "<code>get <tcm> idbase</code>" command. You can use
|
||||
up to 128 ID's starting with the base shown there. If you are using an
|
||||
ID outside of the allowed range, you'll see an ERR_ID_RANGE message in the
|
||||
fhem log.<br>
|
||||
|
||||
Example:
|
||||
<ul><code>
|
||||
set switch1 BI<br>
|
||||
set switch1 B0,CI<br>
|
||||
attr eventMap BI:on B0:off<br>
|
||||
set switch1 on<br>
|
||||
</code></ul>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="EnOceanget"></a>
|
||||
<b>Get</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="EnOceanattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#eventMap">eventMap</a></li>
|
||||
<li><a href="#IODev">IODev</a></li>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||||
<li><a href="#ignore">ignore</a></li>
|
||||
<li><a href="#showtime">showtime</a></li>
|
||||
<li><a href="#model">model</a></li>
|
||||
<li><a href="#subType">subType</a></li>
|
||||
<li><a name="actualTemp">actualTemp</a><br>
|
||||
The value of the actual temperature, used when controlling MD15 devices.
|
||||
Should by filled via a notify from a distinct temperature sensor. If
|
||||
absent, the reported temperature from the MD15 is used.
|
||||
</li>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="EnOceanevents"></a>
|
||||
<b>Generated events:</b>
|
||||
<ul>
|
||||
<li>switch. Switches (remotes) with more than one (pair) of buttons
|
||||
are separate devices with separate address.
|
||||
<ul>
|
||||
<li>A0
|
||||
<li>AI
|
||||
<li>B0
|
||||
<li>BI
|
||||
<li>C0
|
||||
<li>CI
|
||||
<li>D0
|
||||
<li>DI
|
||||
<li>A0,BI
|
||||
<li><BtnX,BtnY> where BtnX and BtnY is one of the above, e.g.
|
||||
A0,BI or D0,CI
|
||||
<li>buttons:released
|
||||
<li>buttons:<BtnX> released<br>
|
||||
</ul>
|
||||
|
||||
<li>FSB61/FSM61 (set model to FSB61 or FSM61 manually)<br>
|
||||
<ul>
|
||||
<li>released<br>
|
||||
The status of the device my become "released", this is not the case
|
||||
for a normal switch.
|
||||
</ul>
|
||||
|
||||
<li>windowHandle (HOPPE SecuSignal). Set the subType attr to windowHandle.
|
||||
<ul>
|
||||
<li>closed
|
||||
<li>open
|
||||
<li>tilted
|
||||
<li>open from tilted
|
||||
</ul>
|
||||
<li>keycard. Set the subType attr to keycard. (untested)
|
||||
<ul>
|
||||
<li>keycard inserted
|
||||
<li>keycard removed
|
||||
</ul>
|
||||
<li>STM-250 Door and window contact.
|
||||
<ul>
|
||||
<li>closed
|
||||
<li>open
|
||||
<li>learnBtn: on
|
||||
</ul>
|
||||
<li>SR04* (Temp sensor + Presence button and desired temp dial).<br>
|
||||
Set the
|
||||
model attribute to one of SR04 SR04P SR04PT SR04PST SR04PMS or the
|
||||
subType attribute to SR04.
|
||||
<ul>
|
||||
<li>temperature: XY.Z
|
||||
<li>set_point: [0..255]
|
||||
<li>fan: [0|1|2|3|Auto]
|
||||
<li>present: yes
|
||||
<li>learnBtn: on
|
||||
<li>T: XY.Z SP: [0..255] F: [0|1|2|3|Auto] P: [yes|no]
|
||||
</ul>
|
||||
<li>MD15-FtL-HE (Heating/Valve-regulator)<br>
|
||||
The subType attibute must be MD15. This is done if the device was created by
|
||||
autocreate.<br>
|
||||
<ul>
|
||||
<li>$actuator %
|
||||
<li>currentValue: $actuator
|
||||
<li>serviceOn: [yes|no]
|
||||
<li>energyInput: [enabled|disabled]
|
||||
<li>energyStorage: [charged|empty]
|
||||
<li>battery: [ok|empty]
|
||||
<li>cover: [open|closed]
|
||||
<li>tempSensor: [failed|ok]
|
||||
<li>window: [open|closed]
|
||||
<li>actuator: [ok|obstructed]
|
||||
<li>temperature: $tmp
|
||||
</ul>
|
||||
|
||||
<li>Ratio Presence Sensor Eagle PM101.<br>
|
||||
Set the model attribute to PM101<br>
|
||||
<ul>
|
||||
<li>brightness: $lux
|
||||
<li>channel1: [on|off]
|
||||
<li>channel2: [on|off]
|
||||
</ul>
|
||||
|
||||
<li>FAH60,FAH63,FIH63 brigthness senor.<br>
|
||||
Set subType to FAH or model to FAH60/FAH63/FIH63 manually.<br>
|
||||
<ul>
|
||||
<li>brightness: $lux
|
||||
<li>state: $lux
|
||||
</ul>
|
||||
|
||||
<li>FABH63,FBH55,FBH63,FIBH63 Motion/brightness sensor.<br>
|
||||
Set subType to FBH or model to FABH63/FBH55/FBH63/FIBH63 manually.<br>
|
||||
<ul>
|
||||
<li>brightness: $lux
|
||||
<li>motion:[yes|no]
|
||||
<li>state: [motion: yes|no]
|
||||
</ul>
|
||||
<li>FTF55 Temperature sensor.<br>
|
||||
Set subType to FTF or model to FTF55 manually.<br>
|
||||
<ul>
|
||||
<li>temperature: $temp
|
||||
<li>state: $temp
|
||||
</ul>
|
||||
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -470,3 +470,241 @@ four2hex($$)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>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>
|
||||
|
||||
<a name="eventMap"></a>
|
||||
<li>eventMap<br>
|
||||
Replace event names and set arguments. The value of this attribute
|
||||
consists of a list of space separated values, each value is a colon
|
||||
separated pair. The first part specifies the "old" value, the second
|
||||
the new/desired value. If the first character is slash(/) or komma(,)
|
||||
then split not by space but by this character, enabling to embed spaces.
|
||||
Examples:<ul><code>
|
||||
attr store eventMap on:open off:closed<br>
|
||||
attr store eventMap /on-for-timer 10:open/off:closed/<br>
|
||||
set store open
|
||||
</code></ul>
|
||||
</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>
|
||||
schedule a "setstate off;trigger off" for the time specified as argument to
|
||||
the on-for-timer command. Or the same with on, if the command is
|
||||
off-for-timer.
|
||||
</li><br>
|
||||
|
||||
<a name="follow-on-timer"></a>
|
||||
<li>follow-on-timer<br>
|
||||
Like with follow-on-for-timer schedule a "setstate off;trigger off", but
|
||||
this time for the time specified as argument in seconds to this attribute.
|
||||
This is used to follow the pre-programmed timer, which was set previously
|
||||
with the timer command or manually by pressing the button on the device,
|
||||
see your manual for details.
|
||||
</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>: fs20fms fs20hgs fs20irl fs20kse fs20ls
|
||||
fs20pira fs20piri fs20piru fs20s16 fs20s20 fs20s4 fs20s4a fs20s4m
|
||||
fs20s4u fs20s4ub fs20s8 fs20s8m fs20sd fs20sn fs20sr fs20ss
|
||||
fs20str fs20tc1 fs20tc6 fs20tfk fs20tk fs20uts fs20ze fs20bf<br><br>
|
||||
|
||||
<b>Dimmer</b>: fs20di fs20di10 fs20du<br><br>
|
||||
|
||||
<b>Receiver/Actor</b>: fs20as1 fs20as4 fs20ms2 fs20rgbsa fs20rst
|
||||
fs20rsu fs20sa fs20sig fs20sm4 fs20sm8 fs20st fs20su fs20sv fs20ue1
|
||||
fs20usr fs20ws1
|
||||
</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><br>
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="FS20events"></a>
|
||||
<b>Generated events:</b>
|
||||
<ul>
|
||||
From an FS20 device you can receive one of the following events.
|
||||
<li>on
|
||||
<li>off
|
||||
<li>toggle
|
||||
<li>dimdown
|
||||
<li>dimup
|
||||
<li>dimupdown
|
||||
<li>on-for-timer
|
||||
Which event is sent is device dependent and can sometimes configured on
|
||||
the device.
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -304,3 +304,196 @@ IT_Parse($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="IT"></a>
|
||||
<h3>IT - InterTechno</h3>
|
||||
<ul>
|
||||
The InterTechno 433MHZ protocol is used by a wide range of devices, which are either of
|
||||
the sender/sensor category or the receiver/actuator category. As we right now are only
|
||||
able to SEND InterTechno commands, but CAN'T receive them, this module at the moment
|
||||
supports just devices like switches, dimmers, etc. through an <a href="#CUL">CUL</a> device, so this must be defined first.
|
||||
|
||||
<br><br>
|
||||
|
||||
<a name="ITdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> IT <housecode> <on-code> <off-code>
|
||||
[<dimup-code>] [<dimdown-code>] </code>
|
||||
<br>or<br>
|
||||
<code>define <name> IT <ITRotarySwitches|FLS100RotarySwitches> </code>
|
||||
<br><br>
|
||||
|
||||
The value of housecode is a 10-digit InterTechno Code, consisting of 0/1/F as it is
|
||||
defined as a tri-state protocol. These digits depend on your device you are using.
|
||||
<br>
|
||||
Bit 11/12 are used for switching/dimming. As different manufacturers are using
|
||||
different bit-codes you can specifiy here the 2-digit code for off/on/dimup/dimdown
|
||||
in the same form: 0/1/F.
|
||||
<br>
|
||||
The value of ITRotarySwitches consist of the value of the alpha switch A-P and
|
||||
the numeric switch 1-16 as set on the intertechno device. E.g. A1 or G12.
|
||||
<br>
|
||||
The value of FLS100RotarySwitches consist of the value of the I,II,II,IV switch
|
||||
and the numeric 1,2,3,4 swicht. E.g. I2 or IV4.
|
||||
<br>
|
||||
The value of ITRotarySwitches and FLS100RotarySwitches is internaly translated
|
||||
into a houscode value.
|
||||
<br>
|
||||
<ul>
|
||||
<li><code><housecode></code> is a 10 digit tri-state number (0/1/F) depending on
|
||||
your device setting (see list below).</li>
|
||||
<li><code><on-code></code> is a 2 digit tri-state number for switching your device on;
|
||||
It is appended to the housecode to build the 12-digits IT-Message.</li>
|
||||
<li><code><off-code></code> is a 2 digit tri-state number for switching your device off;
|
||||
It is appended to the housecode to build the 12-digits IT-Message.</li>
|
||||
<li>The optional <code><dimup-code></code> is a 2 digit tri-state number for dimming your device up;
|
||||
It is appended to the housecode to build the 12-digits IT-Message.</li>
|
||||
<li>The optional <code><dimdown-code></code> is a 2 digit tri-state number for dimming your device down;
|
||||
It is appended to the housecode to build the 12-digits IT-Message.</li>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
Examples:
|
||||
<ul>
|
||||
<code>define lamp IT 01FF010101 11 00 01 10</code><br>
|
||||
<code>define roll1 IT 111111111F 11 00 01 10</code><br>
|
||||
<code>define otherlamp IT 000000000F 11 10 00 00</code><br>
|
||||
<code>define otherroll1 IT FFFFFFF00F 11 10</code><br>
|
||||
<code>define itswitch1 IT A1</code><br>
|
||||
<code>define lamp IT J10</code><br>
|
||||
<code>define flsswitch1 IT IV1</code><br>
|
||||
<code>define lamp IT II2</code>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="ITset"></a>
|
||||
<b>Set </b>
|
||||
<ul>
|
||||
<code>set <name> <value> [<time>]</code>
|
||||
<br><br>
|
||||
where <code>value</code> is one of:<br>
|
||||
<pre>
|
||||
dimdown
|
||||
dimup
|
||||
off
|
||||
on
|
||||
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 off</code><br>
|
||||
</ul>
|
||||
<br>
|
||||
Notes:
|
||||
<ul>
|
||||
<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="ITattr"></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 a CUL.
|
||||
Note: Upon startup fhem DOES NOT assigns an InterTechno device an
|
||||
IODevice! The attribute IODev needs to be used AT ANY TIME!</li><br>
|
||||
|
||||
<a name="eventMap"></a>
|
||||
<li>eventMap<br>
|
||||
Replace event names and set arguments. The value of this attribute
|
||||
consists of a list of space separated values, each value is a colon
|
||||
separated pair. The first part specifies the "old" value, the second
|
||||
the new/desired value. If the first character is slash(/) or komma(,)
|
||||
then split not by space but by this character, enabling to embed spaces.
|
||||
Examples:<ul><code>
|
||||
attr store eventMap on:open off:closed<br>
|
||||
attr store eventMap /on-for-timer 10:open/off:closed/<br>
|
||||
set store open
|
||||
</code></ul>
|
||||
</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>
|
||||
|
||||
<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 switch, "dim..%" to dimmers 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>
|
||||
<b>Sender/Sensor</b>: itremote<br>
|
||||
|
||||
<b>Dimmer</b>: itdimmer<br>
|
||||
|
||||
<b>Receiver/Actor</b>: itswitch
|
||||
</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><br>
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="ITevents"></a>
|
||||
<b>Generated events:</b>
|
||||
<ul>
|
||||
From an IT device you can receive one of the following events.
|
||||
<li>on
|
||||
<li>off
|
||||
<li>dimdown
|
||||
<li>dimup<br>
|
||||
Which event is sent is device dependent and can sometimes configured on
|
||||
the device.
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -475,3 +475,202 @@ ZWave_Undef($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="ZWave"></a>
|
||||
<h3>ZWave</h3>
|
||||
<ul>
|
||||
This module is used to control ZWave devices via FHEM, see <a
|
||||
href="http://www.z-wave.com">www.z-wave.com</a> on details for this device family.
|
||||
This module is a client of the <a href="#ZWDongle">ZWDongle</a> module, which
|
||||
is directly attached to the controller via USB or TCP/IP.
|
||||
<br><br>
|
||||
<a name="ZWavedefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> ZWave <homeId> <id> [classes]</code>
|
||||
<br>
|
||||
<br>
|
||||
<homeId> is the homeId of the controller node, and id is the id of the
|
||||
slave node in the network of this controller.<br>
|
||||
classes is a hex-list of ZWave device classes. This argument is usually
|
||||
specified by autocreate when creating a device. If you wish to manually
|
||||
create a device, use the classes attribute instead, see below for details.
|
||||
Defining a ZWave device the first time is usually done by autocreate.
|
||||
<br>
|
||||
Example:
|
||||
<ul>
|
||||
<code>define lamp ZWave 00ce2074 9</code><br>
|
||||
<code>attr lamp classes SWITCH_BINARY BASIC MANUFACTURER_SPECIFIC VERSION SWITCH_ALL ASSOCIATION METER CONFIGURATION ALARM</code><br>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
Note: the sets/gets/generated events of a gven node depend on the classes
|
||||
supported by this node. If a node supports 3 classes, then the union of
|
||||
these sets/gets/events will be available for this node.<br>
|
||||
Commands for battery operated nodes will be queues internally, and sent when
|
||||
the node sends a message. Answer to get commands appear then as events, the
|
||||
corresponding readings will be updated.
|
||||
<br><br>
|
||||
|
||||
<a name="ZWaveset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
|
||||
<br><b>Class BASIC</b>
|
||||
<li>basicValue value<br>
|
||||
Send value (0-255) to this device. The interpretation is device dependent,
|
||||
e.g. for a SWITCH_BINARY device 0 is off and anything else is on.
|
||||
|
||||
<br><br><b>Class SWITCH_BINARY</b>
|
||||
<li>on<br>
|
||||
switch the device on
|
||||
<li>off<br>
|
||||
switch the device off
|
||||
<li>reportOn,reportOff<br>
|
||||
activate/deactivate the reporting of device state changes to the association group.
|
||||
|
||||
<br><br><b>Class CONFIGURATION</b>
|
||||
<li>configByte cfgAddress 8bitValue<br>
|
||||
configWord cfgAddress 16bitValue<br>
|
||||
configLong cfgAddress 32bitValue<br>
|
||||
Send a configuration value for the parameter cfgAddress. cfgAddress and
|
||||
value is node specific.
|
||||
<li>configDefault cfgAddress<br>
|
||||
Reset the configuration parameter for the cfgAddress parameter to its default value.
|
||||
See the device documentation to determine this value.
|
||||
|
||||
<br><br><b>Class WAKE_UP</b>
|
||||
<li>wakeupInterval value<br>
|
||||
Set the wakeup interval of battery operated devices to the given value in
|
||||
seconds. Upon wakeup the device sends a wakeup notification.
|
||||
|
||||
<br><br><b>Class ASSOCIATION</b>
|
||||
<li>associationAdd groupId nodeId ...<br>
|
||||
Add the specified list of nodeIds to the assotion group groupId.<br>
|
||||
Note: upon creating a fhem-device for the first time fhem will automatically
|
||||
add the controller to the first association group of the node corresponding
|
||||
to the fhem device, i.e it issues a "set name associationAdd 1 controllerNodeId"
|
||||
|
||||
<li>associationDel groupId nodeId ...<br>
|
||||
Remove the specified list of nodeIds from the assotion group groupId.
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="ZWaveget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
|
||||
<br><b>Class BASIC</b>
|
||||
<li>basicStatus<br>
|
||||
return the status of the node as basicReport:XY. The value (XY) depends on
|
||||
the node, e.g a SWITCH_BINARY device report 00 for off and FF (255) for on.
|
||||
|
||||
<br><br><b>Class SWITCH_BINARY</b>
|
||||
<li>swbStatus<br>
|
||||
return the status of the node, as state:on or state:off.
|
||||
|
||||
<br><br><b>Class SENSOR_BINARY</b>
|
||||
<li>sbStatus<br>
|
||||
return the status of the node, as state:open or state:closed.
|
||||
|
||||
<br><br><b>Class CONFIGURATION</b>
|
||||
<li>config cfgAddress<br>
|
||||
return the value of the configuration parameter cfgAddress. The value is
|
||||
device specific.
|
||||
|
||||
<br><br><b>Class ALARM</b>
|
||||
<li>alarm alarmId<br>
|
||||
return the value for alarmId. The value is device specific.
|
||||
|
||||
<br><br><b>Class BATTERY</b>
|
||||
<li>battery<br>
|
||||
return the charge of the battery in %, as battery:value %
|
||||
|
||||
<br><br><b>Class WAKE_UP</b>
|
||||
<li>wakeupInterval<br>
|
||||
return the wakeup interval in seconds, in the form<br>
|
||||
wakeupReport:interval:seconds target:id
|
||||
|
||||
<br><br><b>Class ASSOCIATION</b>
|
||||
<li>association groupId<br>
|
||||
return the list of nodeIds in the association group groupId in the form:<br>
|
||||
assocGroup_X:Max:Y Nodes:id,id...
|
||||
|
||||
<br><br><b>Class VERSION</b>
|
||||
<li>version<br>
|
||||
return the version information of this node in the form:<br>
|
||||
Lib:A Prot:x.y App:a.b
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="ZWaveattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#IODev">IODev</a></li>
|
||||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||||
<li><a href="#ignore">ignore</a></li>
|
||||
<li><a href="#dummy">dummy</a></li>
|
||||
<li><a href="#showtime">showtime</a></li>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
<li><a href="#model">model</a></li>
|
||||
<li><a href="#classes">classes</a>
|
||||
This attribute is needed by the ZWave module, as the list of the possible
|
||||
set/get commands depends on it. It contains a space separated list of
|
||||
class names (capital letters).
|
||||
</li>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="ZWaveevents"></a>
|
||||
<b>Generated events:</b>
|
||||
<ul>
|
||||
|
||||
<br><b>Class BASIC</b>
|
||||
<li>basicReport:XY
|
||||
|
||||
<br><br><b>Class SWITCH_BINARY</b>
|
||||
<li>state:on
|
||||
<li>state:off
|
||||
|
||||
<br><br><b>Class SENSOR_BINARY</b>
|
||||
<li>state:open
|
||||
<li>state:closed
|
||||
|
||||
<br><br><b>Class METER</b>
|
||||
<li>power:val [kWh|kVAh|W|pulseCount]
|
||||
<li>gas:val [m3|feet3|pulseCount]
|
||||
<li>water:val [m3|feet3|USgallons|pulseCount]
|
||||
|
||||
<br><br><b>Class CONFIGURATION</b>
|
||||
<li>config_X:Y
|
||||
|
||||
<br><br><b>Class ALARM</b>
|
||||
<li>alarm_type_X:level Y
|
||||
|
||||
<br><br><b>Class BATTERY</b>
|
||||
<li>battery:chargelevel %
|
||||
|
||||
<br><br><b>Class WAKE_UP</b>
|
||||
<li>wakeup:notification
|
||||
<li>wakeupReport:interval:X target:Y
|
||||
|
||||
<br><br><b>Class ASSOCIATION</b>
|
||||
<li>assocGroup_X:Max:Y Nodes:A,B,...
|
||||
|
||||
<br><br><b>Class VERSION</b>
|
||||
<li>Lib:A Prot:x.y App:a.b
|
||||
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -677,3 +677,315 @@ getFhtBuffer($)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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
|
||||
refreshvalues
|
||||
mode
|
||||
holiday1 holiday2 # see mode holiday_short or holiday
|
||||
manu-temp # No clue what it does.
|
||||
year month day hour minute
|
||||
time date
|
||||
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>
|
||||
</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 surprised 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>time sets hour and minute to local time</li><br>
|
||||
|
||||
<li>date sets year, month and date to local time</li><br>
|
||||
|
||||
<li>refreshvalues is an alias for report1 255 report2 255</li><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</li><br>
|
||||
|
||||
<li><code>mode</code> is one of <code>auto, manual, holiday or
|
||||
holiday_short.</code><br>
|
||||
If the mode is holiday, then the mode switches back to either auto or
|
||||
manual at 00:00 of the day specified by the following:
|
||||
<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 (party mode)
|
||||
<ul>
|
||||
<li> holiday1 sets the absolute hour to switch back from this
|
||||
mode (in 10-minute steps, max 144)
|
||||
<li> holiday2 sets the day of month to switch back from this mode
|
||||
(can only be today or tomorrow, since holiday1 accepts only 24 hours).
|
||||
Example:
|
||||
<ul>
|
||||
<li> current date is 29 Jan, time is 18:05
|
||||
<li> you want to switch to party mode until tomorrow 1:00
|
||||
<li> set holiday1 to 6 (6 x 10min = 1hour) and holiday2 to 30
|
||||
</ul>
|
||||
</ul>
|
||||
The temperature for the holiday period is set by the desired-temperature
|
||||
parameter. <br> Note that you cannot set holiday mode for days earlier than the
|
||||
day after tomorrow, for this you must use holiday_short.<br>
|
||||
Note also, you cannot set parameters seperately, you must set them in one command.
|
||||
Example:
|
||||
<br>
|
||||
<code>set FHT1 mode holiday holiday1 24 holiday2 12 desired-temp 14</code>
|
||||
</li>
|
||||
<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>
|
||||
|
||||
<li>To synchronize the FHT time and to "wake" muted FHTs it is adviseable
|
||||
to schedule following command:<br>
|
||||
<code>define fht_sync at +*3:30 set TYPE=FHT time</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>
|
||||
<li> 2: tuesday</li>
|
||||
<li> 4: thursday</li>
|
||||
<li> 8: wednesday</li>
|
||||
<li>16: friday</li>
|
||||
<li>32: saturday</li>
|
||||
<li>64: sunday</li>
|
||||
</ul>
|
||||
measured-temp and actuator is sent along if it is considered
|
||||
appropriate
|
||||
by the FHT.
|
||||
<br><br>
|
||||
<b>Note:</b> This command generates a lot of RF traffic, which can
|
||||
lead to further problems, especially if the reception is not clear.
|
||||
<br><br></li>
|
||||
|
||||
<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>
|
||||
<li><a href="#eventMap">eventMap</a></li><br>
|
||||
<li><a href="#event-on-update-reading">event-on-update-reading</a></li>
|
||||
<li><a href="#event-on-change-reading">event-on-change-reading</a></li>
|
||||
|
||||
<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>
|
||||
|
||||
<a name="FHTevents"></a>
|
||||
<b>Generated events:</b>
|
||||
<ul>
|
||||
<li>actuator
|
||||
<li>actuator1 actuator2 actuator3 actuator4<br>
|
||||
actuator5 actuator6 actuator7 actuator8<br>
|
||||
(sent if you configured an offset for the associated valve)
|
||||
<li>mon-from1 mon-to1 mon-from2 mon-to2
|
||||
<li>tue-from1 tue-to1 tue-from2 tue-to2
|
||||
<li>wed-from1 wed-to1 wed-from2 wed-to2
|
||||
<li>thu-from1 thu-to1 thu-from2 thu-to2
|
||||
<li>fri-from1 fri-to1 fri-from2 fri-to2
|
||||
<li>sat-from1 sat-to1 sat-from2 sat-to2
|
||||
<li>sun-from1 sun-to1 sun-from2 sun-to2
|
||||
<li>mode
|
||||
<li>holiday1 holiday2
|
||||
<li>desired-temp
|
||||
<li>measured-temp measured-low measured-high
|
||||
<li>warnings
|
||||
<li>manu-temp
|
||||
<li>year month day hour minute
|
||||
<li>day-temp night-temp lowtemp-offset windowopen-temp
|
||||
<li>ack can-xmit can-rcv ack2 start-xmit end-xmit
|
||||
(only if the CUL is configured to transmit FHT protocol data)
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -106,3 +106,81 @@ FHT8V_Get($@)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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">dummy</a></li>
|
||||
<li><a href="#ignore">ignore</a></li>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
<li><a href="#eventMap">eventMap</a></li><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -235,3 +235,83 @@ HMS_Parse($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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="#eventMap">eventMap</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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -332,3 +332,75 @@ KS300_Parse($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
<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="#eventMap">eventMap</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> (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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -143,3 +143,63 @@ CUL_TX_Parse($$)
|
||||
|
||||
1;
|
||||
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="CUL_TX"></a>
|
||||
<h3>CUL_TX</h3>
|
||||
<ul>
|
||||
The CUL_TX module interprets TX2/TX3 type of messages received by the CUL,
|
||||
see also http://www.f6fbb.org/domo/sensors/tx3_th.php.
|
||||
This protocol is used by the La Crosse TX3-TH thermo/hygro sensor and other
|
||||
wireless themperature sensors. Please report the manufacturer/model of other
|
||||
working devices. <br><br>
|
||||
|
||||
<a name="CUL_TXdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> CUL_TX <code> [corr] [minsecs]</code> <br>
|
||||
|
||||
<br>
|
||||
<code> is the code of the autogenerated address of the TX device (0
|
||||
to 127)<br>
|
||||
corr is a correction factor, which will be added to the value received from
|
||||
the device.<br>
|
||||
minsecs are the minimum seconds between two log entries or notifications
|
||||
from this device. <br>E.g. if set to 300, logs of the same type will occure
|
||||
with a minimum rate of one per 5 minutes even if the device sends a message
|
||||
every minute. (Reduces the log file size and reduces the time to display
|
||||
the plots)
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="CUL_TXset"></a>
|
||||
<b>Set</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="CUL_TXget"></a>
|
||||
<b>Get</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="CUL_TXattr"></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>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="CUL_TXevents"></a>
|
||||
<b>Generated events:</b>
|
||||
<ul>
|
||||
<li>temperature: $temp
|
||||
<li>humidity: $hum
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -358,3 +358,48 @@ CUL_WS_Attr(@)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
<li><a href="#eventMap">eventMap</a></li><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -250,3 +250,77 @@ CUL_EM_Parse($$)
|
||||
|
||||
1;
|
||||
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
<li><a href="#eventMap">eventMap</a></li><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -138,3 +138,80 @@ CUL_RFR_AddPrefix($$)
|
||||
|
||||
1;
|
||||
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -266,3 +266,97 @@ SIS_PMS_Set($@)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -60,3 +60,43 @@ CUL_HOERMANN_Parse($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -218,3 +218,149 @@ OWFS_Undef($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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: 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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -532,3 +532,123 @@ X10_Parse($$)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
<li><a href="#eventMap">eventMap</a></li><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -1035,3 +1035,146 @@ sub OWXAD_SetPage($$) {
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="OWAD"></a>
|
||||
<h3>OWAD</h3>
|
||||
<ul>FHEM module to commmunicate with 1-Wire A/D converters<br /><br /> Note:<br /> This
|
||||
1-Wire module so far works only with the OWX interface module. Please define an <a
|
||||
href="#OWX">OWX</a> device first. <br />
|
||||
<br /><b>Example</b><br />
|
||||
<ul>
|
||||
<code>define OWX_AD OWAD 724610000000 45</code>
|
||||
<br />
|
||||
<code>attr OWX_AD DAlarm high</code>
|
||||
<br />
|
||||
<code>attr OWX_AD DFactor 31.907097</code>
|
||||
<br />
|
||||
<code>attr OWX_AD DHigh 50.0</code>
|
||||
<br />
|
||||
<code>attr OWX_AD DName relHumidity|humidity</code>
|
||||
<br />
|
||||
<code>attr OWX_AD DOffset -0.8088</code>
|
||||
<br />
|
||||
<code>attr OWX_AD DUnit percent|%</code>
|
||||
<br />
|
||||
</ul><br />
|
||||
<a name="OWADdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> OWAD [<model>] <id> [<interval>]</code>
|
||||
<br /><br /> Define a 1-Wire A/D converter.<br /><br />
|
||||
<li>
|
||||
<code>[<model>]</code><br /> Defines the A/D converter model (and thus
|
||||
1-Wire family id), currently the following values are permitted: <ul>
|
||||
<li>model DS2450 with family id 20 (default if the model parameter is
|
||||
omitted)</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<code><id></code>
|
||||
<br />12-character unique ROM id of the converter device without family id and
|
||||
CRC code </li>
|
||||
<li>
|
||||
<code><interval></code>
|
||||
<br />Measurement interval in seconds. The default is 300 seconds. </li>
|
||||
<br />
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWADset">
|
||||
<b>Set</b></a>
|
||||
<ul>
|
||||
<li><a name="owad_interval">
|
||||
<code>set <name> interval <int></code></a><br /> Measurement
|
||||
interval in seconds. The default is 300 seconds. </li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWADget">
|
||||
<b>Get</b></a>
|
||||
<ul>
|
||||
<li><a name="owad_id">
|
||||
<code>get <name> id</code></a>
|
||||
<br /> Returns the full 1-Wire device id OW_FAMILY.ROM_ID.CRC </li>
|
||||
<li><a name="owad_present">
|
||||
<code>get <name> present</code>
|
||||
</a>
|
||||
<br /> Returns 1 if this 1-Wire device is present, otherwise 0. </li>
|
||||
<li><a name="owad_interval2">
|
||||
<code>get <name> interval</code></a><br />Returns measurement interval
|
||||
in seconds. </li>
|
||||
<li><a name="owad_reading">
|
||||
<code>get <name> reading</code></a><br />Obtain the measuement values. </li>
|
||||
<li><a name="owad_alarm">
|
||||
<code>get <name> alarm</code></a><br />Obtain the alarm values. </li>
|
||||
<li><a name="owad_status">
|
||||
<code>get <name> status</code></a><br />Obtain the i/o status values.
|
||||
</li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWADattr">
|
||||
<b>Attributes</b></a>
|
||||
<ul>
|
||||
<li><a name="owad_stateAL0"><code>attr <name> stateAL0
|
||||
<string></code></a>
|
||||
<br />character string for denoting low normal condition, default is green down
|
||||
triangle, e.g. the code <span
|
||||
style="color:green">&#x25BE;</span> leading to the sign <span
|
||||
style="color:green">▾</span>
|
||||
</li>
|
||||
<li><a name="owad_stateAH0"><code>attr <name> stateAH0
|
||||
<string></code></a>
|
||||
<br />character string for denoting high alarm condition, default is green
|
||||
upward triangle, e.g. the code <span
|
||||
style="color:green">&#x25B4;</span> leading to the sign <span
|
||||
style="color:green">▴</span>
|
||||
</li>
|
||||
<li><a name="owad_stateAL1"><code>attr <name> stateAL1
|
||||
<string></code></a>
|
||||
<br />character string for denoting low alarm condition, default is red down
|
||||
triangle, e.g. the code <span style="color:red">&#x25BE;</span>
|
||||
leading to the sign <span style="color:red">▾</span></li>
|
||||
<li><a name="owad_stateAH1"><code>attr <name> stateAH1
|
||||
<string></code></a>
|
||||
<br />character string for denoting high alarm condition, default is red upward
|
||||
triangle, e.g. the code <span style="color:red">&#x25B4;</span>
|
||||
leading to the sign <span style="color:red">▴</span>
|
||||
</li>
|
||||
</ul> For each of the following attributes, the channel identification A,B,C,D may be
|
||||
used. <ul>
|
||||
<li><a name="owad_cname"><code>attr <name> <channel>Name
|
||||
<string>|<string></code></a>
|
||||
<br />name for the channel | a type description for the measured value. </li>
|
||||
<li><a name="owad_cunit"><code>attr <name> <channel>Unit
|
||||
<string>|<string></code></a>
|
||||
<br />unit of measurement for this channel | its abbreviation. </li>
|
||||
<li><a name="owad_coffset"><code>attr <name> <channel>Offset
|
||||
<float></code></a>
|
||||
<br />offset added to the reading in this channel. </li>
|
||||
<li><a name="owad_cfactor"><code>attr <name> <channel>Factor
|
||||
<float></code></a>
|
||||
<br />factor multiplied to (reading+offset) in this channel. </li>
|
||||
<li><a name="owad_calarm"><code>attr <name> <channel>Alarm
|
||||
<string></code></a>
|
||||
<br />alarm setting in this channel, either both, low, high or none (default). </li>
|
||||
<li><a name="owad_clow"><code>attr <name> <channel>Low
|
||||
<float></code></a>
|
||||
<br />measurement value (on the scale determined by offset and factor) for low
|
||||
alarm. </li>
|
||||
<li><a name="owad_chigh"><code>attr <name> <channel>High
|
||||
<float></code></a>
|
||||
<br />measurement value (on the scale determined by offset and factor) for high
|
||||
alarm. </li>
|
||||
<li><a name="owad_event"><code>attr <name> event on-change|on-update
|
||||
</code></a>This attribte work similarly, but not identically to the standard event-on-update-change/event-on-update-reading attribute.
|
||||
<ul><li><code>event on-update</code> (default) will write a notify/FileLog event any time a measurement is received.</li>
|
||||
<li><code>event on-change</code> will write a notify/FileLog event only when a measurement is different from the previous one.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Standard attributes alias, comment, <a href="#eventMap">eventMap</a>, <a href="#loglevel">loglevel</a>, <a href="#webCmd">webCmd</a></li>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -1018,3 +1018,119 @@ sub OWXCOUNT_SetPage($$$) {
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="OWCOUNT"></a>
|
||||
<h3>OWCOUNT</h3>
|
||||
<ul>FHEM module to commmunicate with 1-Wire Counter/RAM DS2423 #<br /><br /> Note:<br />
|
||||
This 1-Wire module so far works only with the OWX interface module. Please define an <a
|
||||
href="#OWX">OWX</a> device first. <br />
|
||||
<br /><b>Example</b><br />
|
||||
<ul>
|
||||
<code>define OWX_C OWCOUNT DS2423 CE780F000000 300</code>
|
||||
<br />
|
||||
<code>attr OWX_C AName Water|volume</code>
|
||||
<br />
|
||||
<code>attr OWX_C AUnit liters|l</code>
|
||||
<br />
|
||||
<code>attr OWX_CAMode daily</code>
|
||||
<br />
|
||||
</ul><br />
|
||||
<a name="OWCOUNTdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> OWCOUNT [<model>] <id>
|
||||
[<interval>]</code>
|
||||
<br /><br /> Define a 1-Wire counter.<br /><br />
|
||||
<li>
|
||||
<code>[<model>]</code><br /> Defines the counter model (and thus 1-Wire
|
||||
family id), currently the following values are permitted: <ul>
|
||||
<li>model DS2423 with family id 1D (default if the model parameter is
|
||||
omitted)</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<code><id></code>
|
||||
<br />12-character unique ROM id of the converter device without family id and
|
||||
CRC code </li>
|
||||
<li>
|
||||
<code><interval></code>
|
||||
<br />Measurement interval in seconds. The default is 300 seconds. </li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWCOUNTset">
|
||||
<b>Set</b></a>
|
||||
<ul>
|
||||
<li><a name="owcount_interval">
|
||||
<code>set <name> interval <int></code></a><br /> Measurement
|
||||
interval in seconds. The default is 300 seconds. </li>
|
||||
<li><a name="owcount_memory">
|
||||
<code>set <name> memory <page></code></a><br />Write 32 bytes to
|
||||
memory page 0..13 </li>
|
||||
<li><a name="owcount_midnight">
|
||||
<code>set <name> midnight <channel-name></code></a><br />Write
|
||||
the day's starting value for counter <channel> (A, B or named channel, see
|
||||
below)</li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWCOUNTget">
|
||||
<b>Get</b></a>
|
||||
<ul>
|
||||
<li><a name="owcount_id">
|
||||
<code>get <name> id</code></a>
|
||||
<br /> Returns the full 1-Wire device id OW_FAMILY.ROM_ID.CRC </li>
|
||||
<li><a name="owcount_present">
|
||||
<code>get <name> present</code>
|
||||
</a>
|
||||
<br /> Returns 1 if this 1-Wire device is present, otherwise 0. </li>
|
||||
<li><a name="owcount_interval2">
|
||||
<code>get <name> interval</code></a><br />Returns measurement interval
|
||||
in seconds. </li>
|
||||
<li><a name="owcount_memory2">
|
||||
<code>get <name> memory <page></code></a><br />Obtain 32 bytes
|
||||
from memory page 0..13 </li>
|
||||
<li><a name="owcount_midnight2">
|
||||
<code>get <name> midnight <channel-name></code></a><br />Obtain
|
||||
the day's starting value for counter <channel> (A, B or named channel, see
|
||||
below)</li>
|
||||
<li><a name="owcount_counter">
|
||||
<code>get <name> counter <channel-name></code></a><br />Obtain
|
||||
the current value for counter <channel> (A, B or named channel, see
|
||||
below)</li>
|
||||
<li><a name="owcount_counters">
|
||||
<code>get <name> counters</code></a><br />Obtain the current value
|
||||
both counters</li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWCOUNTattr">
|
||||
<b>Attributes</b></a>
|
||||
<ul>For each of the following attributes, the channel identification A,B may be used.
|
||||
<li><a name="owcount_cname"><code>attr <name> <channel>Name
|
||||
<string>|<string></code></a>
|
||||
<br />name for the channel | a type description for the measured value. </li>
|
||||
<li><a name="owcount_cunit"><code>attr <name> <channel>Unit
|
||||
<string>|<string></code></a>
|
||||
<br />unit of measurement for this channel | its abbreviation. </li>
|
||||
<li><a name="owcount_coffset"><code>attr <name> <channel>Offset
|
||||
<float></code></a>
|
||||
<br />offset added to the reading in this channel. </li>
|
||||
<li><a name="owcount_cfactor"><code>attr <name> <channel>Factor
|
||||
<float></code></a>
|
||||
<br />factor multiplied to (reading+offset) in this channel. </li>
|
||||
<li><a name="owcount_cmode"><code>attr <name> <channel>Mode daily |
|
||||
normal</code></a>
|
||||
<br />factor multiplied to (reading+offset) in this channel. </li>
|
||||
<li><a name="owcount_event"><code>attr <name> event on-change|on-update
|
||||
</code></a>This attribte work similarly, but not identically to the standard event-on-update-change/event-on-update-reading attribute.
|
||||
<ul><li><code>event on-update</code> (default) will write a notify/FileLog event any time a measurement is received.</li>
|
||||
<li><code>event on-change</code> will write a notify/FileLog event only when a measurement is different from the previous one.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Standard attributes alias, comment, <a href="#eventMap">eventMap</a>, <a href="#loglevel">loglevel</a>, <a href="#webCmd">webCmd</a></li>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -210,3 +210,44 @@ sub OWID_Undef ($) {
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="OWID"></a>
|
||||
<h3>OWID</h3>
|
||||
<ul>FHEM module for 1-Wire devices that know only their unique ROM ID<br />
|
||||
<br />Note:<br /> This 1-Wire module so far works only with the OWX interface module.
|
||||
Please define an <a href="#OWX">OWX</a> device first. <br />
|
||||
<br /><b>Example</b><br />
|
||||
<ul>
|
||||
<code>define ROM1 OWX_ID OWCOUNT CE780F000000</code>
|
||||
<br />
|
||||
</ul><br />
|
||||
<a name="OWIDdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> OWID <id> </code>
|
||||
<br /><br /> Define a 1-Wire device.<br /><br />
|
||||
<li>
|
||||
<code><id></code>
|
||||
<br />12-character unique ROM id of the converter device without family id and
|
||||
CRC code </li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWIDget">
|
||||
<b>Get</b></a>
|
||||
<ul>
|
||||
<li><a name="owid_id">
|
||||
<code>get <name> id</code></a>
|
||||
<br /> Returns the full 1-Wire device id OW_FAMILY.ROM_ID.CRC </li>
|
||||
<li><a name="owid_present">
|
||||
<code>get <name> present</code>
|
||||
</a>
|
||||
<br /> Returns 1 if this 1-Wire device is present, otherwise 0. </li>
|
||||
</ul>
|
||||
<br />
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -1035,3 +1035,97 @@ sub OWXLCD_SetMemory($$$) {
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="OWLCD"></a>
|
||||
<h3>OWLCD</h3>
|
||||
<ul>FHEM module to commmunicate with the <a
|
||||
href="http://www.louisswart.co.za/1-Wire_Overview.html">1-Wire LCD controller</a>
|
||||
from Louis Swart (1-Wire family id FF). See also the corresponding <a
|
||||
href="http://fhemwiki.de/wiki/1-Wire_Textdisplay">Wiki page.</a><br /><br />
|
||||
Note:<br /> This 1-Wire module so far works only with the OWX interface module. Please
|
||||
define an <a href="#OWX">OWX</a> device first. <br />
|
||||
<br /><b>Example</b><br />
|
||||
<ul>
|
||||
<code>define OWX_LCD OWLCD 9F0700000100</code>
|
||||
<br />
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWLCDdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> OWLCD <id></code>
|
||||
<br /><br /> Define a 1-Wire LCD device.<br /><br />
|
||||
<li>
|
||||
<code><id></code>
|
||||
<br />12-character unique ROM id of the converter device without family id and
|
||||
CRC code </li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWLCDset">
|
||||
<b>Set</b></a>
|
||||
<ul>
|
||||
<li><a name="owlcd_icon">
|
||||
<code>set <name> icon <int> on|off|blink</code></a><br /> Set
|
||||
one of the icons 0..14 on, off or blinking</li>
|
||||
<li><a name="owlcd_icon2">
|
||||
<code>set <name> icon 15 0..6</code></a><br /> Set icon 15 to one of
|
||||
its values</li>
|
||||
<li><a name="owlcd_icon3">
|
||||
<code>set <name> icon none</code></a><br /> Set all icons off</li>
|
||||
<li><a name="owlcd_line">
|
||||
<code>set <name> line <int> <string></code></a><br />
|
||||
Write LCD line 0..3 with some content </li>
|
||||
<li><a name="owlcd_memory">
|
||||
<code>set <name> memory <page>
|
||||
<string></code></a><br />Write memory page 0..6</li>
|
||||
<li><a name="owlcd_gpio">
|
||||
<code>set <name> gpio <value></code></a><br />Write state for
|
||||
all three gpio pins (value = 0..7, for each bit 0=ON, 1=OFF)</li>
|
||||
<li><a name="owlcd_bl">
|
||||
<code>set <name> backlight ON|OFF</code></a><br />Switch backlight on
|
||||
or off</li>
|
||||
<li><a name="owlcd_lcd">
|
||||
<code>set <name> lcd ON|OFF</code></a><br />Switch LCD power on or
|
||||
off</li>
|
||||
<li><a name="owlcd_gpio">
|
||||
<code>set <name> reset</code></a><br />Reset the display</li>
|
||||
<li><a name="owlcd_gpio">
|
||||
<code>set <name> test</code></a><br />Test the display</li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="owlcdget">
|
||||
<b>Get</b></a>
|
||||
<ul>
|
||||
<li><a name="owlcd_id">
|
||||
<code>get <name> id</code></a>
|
||||
<br /> Returns the full 1-Wire device id OW_FAMILY.ROM_ID.CRC </li>
|
||||
<li><a name="owlcd_present">
|
||||
<code>get <name> present</code>
|
||||
</a>
|
||||
<br /> Returns 1 if this 1-Wire device is present, otherwise 0. </li>
|
||||
<li><a name="owlcd_memory2">
|
||||
<code>get <name> memory <page></code></a><br />Read memory page
|
||||
0..6 </li>
|
||||
<li><a name="owlcd_gpio">
|
||||
<code>get <name> gpio</code></a><br />Obtain state of all four input
|
||||
channels (15 = all off, 0 = all on)</li>
|
||||
<li><a name="owlcd_counter">
|
||||
<code>get <name> gpio</code></a><br />Obtain state of all four input
|
||||
counters (4 x 16 Bit)</li>
|
||||
<li><a name="owlcd_version">
|
||||
<code>get <name> version</code></a><br />Obtain firmware version of
|
||||
the controller</li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="owlcdattr">
|
||||
<b>Attributes</b></a>
|
||||
<ul>
|
||||
<li>Standard attributes alias, comment, <a href="#eventMap">eventMap</a>, <a href="#loglevel">loglevel</a>, <a href="#webCmd">webCmd</a></li>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -848,3 +848,115 @@ sub OWXMULTI_SetValues($@) {
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="OWMULTI"></a>
|
||||
<h3>OWMULTI</h3>
|
||||
<ul>FHEM module to commmunicate with 1-Wire multi-sensors, currently the DS2438 smart battery monitor<br /><br /> Note:<br /> This
|
||||
1-Wire module so far works only with the OWX interface module. Please define an <a
|
||||
href="#OWX">OWX</a> device first. <br />
|
||||
<br /><b>Example</b><br />
|
||||
<ul>
|
||||
<code>define OWX_M OWMULTI 7C5034010000 45</code>
|
||||
<br />
|
||||
<code>attr OWX_M VName relHumidity|humidity</code>
|
||||
<br />
|
||||
<code>attr OWX_M VUnit percent|%</code>
|
||||
<br />
|
||||
<code>attr OWX_M VFunction (161.29 * V / VDD - 25.8065)/(1.0546 - 0.00216 * T)</code>
|
||||
<br />
|
||||
</ul><br />
|
||||
<a name="OWMULTIdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> OWMULTI [<model>] <id> [<interval>]</code>
|
||||
<br /><br /> Define a 1-Wire multi-sensor<br /><br />
|
||||
<li>
|
||||
<code>[<model>]</code><br /> Defines the sensor model (and thus
|
||||
1-Wire family id), currently the following values are permitted: <ul>
|
||||
<li>model DS2438 with family id 26 (default if the model parameter is
|
||||
omitted). Measured is a temperature value, an external voltage and the current supply voltage</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<code><id></code>
|
||||
<br />12-character unique ROM id of the converter device without family id and
|
||||
CRC code </li>
|
||||
<li>
|
||||
<code><interval></code>
|
||||
<br />Measurement interval in seconds. The default is 300 seconds. </li>
|
||||
<br />
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWMULTIset">
|
||||
<b>Set</b></a>
|
||||
<ul>
|
||||
<li><a name="owmulti_interval">
|
||||
<code>set <name> interval <int></code></a><br /> Measurement
|
||||
interval in seconds. The default is 300 seconds. </li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWMULTIget">
|
||||
<b>Get</b></a>
|
||||
<ul>
|
||||
<li><a name="owmulti_id">
|
||||
<code>get <name> id</code></a>
|
||||
<br /> Returns the full 1-Wire device id OW_FAMILY.ROM_ID.CRC </li>
|
||||
<li><a name="owmulti_present">
|
||||
<code>get <name> present</code>
|
||||
</a>
|
||||
<br /> Returns 1 if this 1-Wire device is present, otherwise 0. </li>
|
||||
<li><a name="owmulti_interval2">
|
||||
<code>get <name> interval</code></a><br />Returns measurement interval
|
||||
in seconds. </li>
|
||||
<li><a name="owmulti_reading">
|
||||
<code>get <name> reading</code></a><br />Obtain the measurement value from VFunction. </li>
|
||||
<li><a name="owmulti_temperature">
|
||||
<code>get <name> temperature</code></a><br />Obtain the temperature value. </li>
|
||||
<li><a name="owmulti_vdd">
|
||||
<code>get <name> VDD</code></a><br />Obtain the current supply voltage.
|
||||
</li>
|
||||
<li><a name="owmulti_raw">
|
||||
<code>get <name> V</code> or <code>get <name> raw</code></a><br />Obtain the raw external voltage measurement.
|
||||
</li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWMULTIattr">
|
||||
<b>Attributes</b></a>
|
||||
<ul>
|
||||
<li><a name="owmulti_vname"><code>attr <name> VName
|
||||
<string>|<string></code></a>
|
||||
<br />name for the channel | a type description for the measured value. </li>
|
||||
<li><a name="owmulti_vunit"><code>attr <name> VUnit
|
||||
<string>|<string></code></a>
|
||||
<br />unit of measurement for this channel | its abbreviation. </li>
|
||||
<li><a name="owmulti_vfunction"><code>attr <name> VFunction
|
||||
<string></code></a>
|
||||
<br />arbitrary functional expression involving the values VDD, V, T. Example see above.
|
||||
<ul>
|
||||
<li>VDD is replaced by the measured supply voltage in Volt,</li>
|
||||
<li> V by the measured external voltage,</li>
|
||||
<li>T by the measured and corrected temperature in its unit</li>
|
||||
</ul></li>
|
||||
<li><a name="owmulti_tempOffset"><code>attr <name> tempOffset
|
||||
<float></code>
|
||||
</a>
|
||||
<br />temperature offset in °C added to the raw temperature reading. </li>
|
||||
<li><a name="owmulti_tempUnit"><code>attr <name> tempUnit
|
||||
Celsius|Kelvin|Fahrenheit|C|K|F</code>
|
||||
</a>
|
||||
<br />unit of measurement (temperature scale), default is Celsius = °C </li>
|
||||
<li><a name="owmulti_event"><code>attr <name> event on-change|on-update
|
||||
</code></a>This attribte work similarly, but not identically to the standard event-on-update-change/event-on-update-reading attribute.
|
||||
<ul><li><code>event on-update</code> (default) will write a notify/FileLog event any time a measurement is received.</li>
|
||||
<li><code>event on-change</code> will write a notify/FileLog event only when a measurement is different from the previous one.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Standard attributes alias, comment, <a href="#eventMap">eventMap</a>, <a href="#loglevel">loglevel</a>, <a href="#webCmd">webCmd</a></li>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -900,3 +900,108 @@ sub OWXSWITCH_SetState($$) {
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="OWSWITCH"></a>
|
||||
<h3>OWSWITCH</h3>
|
||||
<ul>FHEM module to commmunicate with 1-Wire Programmable Switches <br /><br /> Note:<br />
|
||||
This 1-Wire module so far works only with the OWX interface module. Please define an <a
|
||||
href="#OWX">OWX</a> device first. <br />
|
||||
<br /><b>Example</b><br />
|
||||
<ul>
|
||||
<code>define OWX_S OWSWITCH DS2413 B5D502000000 60</code>
|
||||
<br />
|
||||
<code>attr OWX_S AName Lampe|light</code>
|
||||
<br />
|
||||
<code>attr OWX_S AUnit AN|AUS</code>
|
||||
<br />
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWSWITCHdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> OWSWITCH [<model>] <id>
|
||||
[<interval>]</code>
|
||||
<br /><br /> Define a 1-Wire switch.<br /><br />
|
||||
<li>
|
||||
<code>[<model>]</code><br /> Defines the switch model (and thus 1-Wire
|
||||
family id), currently the following values are permitted: <ul>
|
||||
<li>model DS2413 with family id 3A (default if the model parameter is
|
||||
omitted). 2 Channel switch with onboard memory</li>
|
||||
<li>model DS2406 with family id 12. 2 Channel switch </li>
|
||||
<li>model DS2406 with family id 29. 8 Channel switch</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<code><id></code>
|
||||
<br />12-character unique ROM id of the converter device without family id and
|
||||
CRC code </li>
|
||||
<li>
|
||||
<code><interval></code>
|
||||
<br />Measurement interval in seconds. The default is 300 seconds. </li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWSWITCHset">
|
||||
<b>Set</b></a>
|
||||
<ul>
|
||||
<li><a name="owswitch_interval">
|
||||
<code>set <name> interval <int></code></a><br /> Measurement
|
||||
interval in seconds. The default is 300 seconds. </li>
|
||||
<li><a name="owswitch_output">
|
||||
<code>set <name> output <channel-name> ON |
|
||||
OFF</code></a><br />Set value for channel (A,B,... or defined channel name). 1 = OFF, 0 = ON in normal usage.
|
||||
See also the note above</li>
|
||||
<li><a name="owswitch_gpio">
|
||||
<code>set <name> gpio <value></code></a><br />Set values for channels (For 2 channels: 3 = A and B OFF, 1 = B ON 2 = A ON 0 = both ON)</li>
|
||||
<li><a name="owswitch_init">
|
||||
<code>set <name> init yes</code></a><br /> Re-initialize the device</li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWSWITCHget">
|
||||
<b>Get</b></a>
|
||||
<ul>
|
||||
<li><a name="owswitch_id">
|
||||
<code>get <name> id</code></a>
|
||||
<br /> Returns the full 1-Wire device id OW_FAMILY.ROM_ID.CRC </li>
|
||||
<li><a name="owswitch_present">
|
||||
<code>get <name> present</code>
|
||||
</a>
|
||||
<br /> Returns 1 if this 1-Wire device is present, otherwise 0. </li>
|
||||
<li><a name="owswitch_interval2">
|
||||
<code>get <name> interval</code></a><br />Returns measurement interval
|
||||
in seconds. </li>
|
||||
<li><a name="owswitch_input">
|
||||
<code>get <name> input <channel-name></code></a><br />
|
||||
state for channel (A,B, ... or defined channel name)
|
||||
This value reflects the measured value, not necessarily the one set as
|
||||
output state, because the output transistors are open collector switches. A measured
|
||||
state of 1 = OFF therefore corresponds to an output state of 1 = OFF, but a measured
|
||||
state of 0 = ON can also be due to an external shortening of the output.</li>
|
||||
<li><a name="owswitch_gpio">
|
||||
<code>get <name> gpio</code></a><br />Obtain state of all
|
||||
channels</li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWSWITCHattr">
|
||||
<b>Attributes</b></a> For each of the following attributes, the channel
|
||||
identification A,B,... may be used. <ul>
|
||||
<li><a name="owswitch_cname"><code>attr <name> <channel>Name
|
||||
<string>|<string></code></a>
|
||||
<br />name for the channel | a type description for the measured value. </li>
|
||||
<li><a name="owswitch_cunit"><code>attr <name> <channel>Unit
|
||||
<string>|<string></code></a>
|
||||
<br />display for on | off condition </li>
|
||||
<li><a name="owswitch_event"><code>attr <name> event on-change|on-update
|
||||
</code></a>This attribte work similarly, but not identically to the standard event-on-update-change/event-on-update-reading attribute.
|
||||
<ul><li><code>event on-update</code> (default) will write a notify/FileLog event any time a measurement is received.</li>
|
||||
<li><code>event on-change</code> will write a notify/FileLog event only when a measurement is different from the previous one.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Standard attributes alias, comment, <a href="#eventMap">eventMap</a>, <a href="#loglevel">loglevel</a>, <a href="#webCmd">webCmd</a></li>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -489,3 +489,123 @@ OWTEMP_Undef($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -818,3 +818,126 @@ sub OWXTHERM_SetValues($@) {
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="OWTHERM"></a>
|
||||
<h3>OWTHERM</h3>
|
||||
<ul>FHEM module to commmunicate with 1-Wire bus digital thermometer devices<br /><br />
|
||||
Note:<br /> This is the only 1-Wire module which so far works with both the OWFS and the
|
||||
OWX interface module. Please define an <a href="#OWFS">OWFS</a> device or an <a
|
||||
href="#OWX">OWX</a> device first. <br />
|
||||
<br /><b>Example</b><br />
|
||||
<ul>
|
||||
<code>define OWX_T OWTHERM DS18B20 E8D09B030000 300</code>
|
||||
<br />
|
||||
<code>attr OWX_T tempUnit Kelvin</code>
|
||||
<br />
|
||||
</ul><br />
|
||||
<a name="OWTHERMdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> OWTHERM [<model>] <id>
|
||||
[<interval>]</code>
|
||||
<br /><br /> Define a 1-Wire digital thermometer device.<br /><br />
|
||||
<li>
|
||||
<code>[<model>]</code><br /> Defines the thermometer model (and thus
|
||||
1-Wire family id) currently the following values are permitted: <ul>
|
||||
<li>model DS1820 with family id 10 (default if the model parameter is
|
||||
omitted)</li>
|
||||
<li>model DS1822 with family id 22</li>
|
||||
<li>model DS18B20 with family id 28</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<code><id></code>
|
||||
<br />12-character unique ROM id of the thermometer device without family id and
|
||||
CRC code </li>
|
||||
<li>
|
||||
<code><interval></code>
|
||||
<br /> Temperature measurement interval in seconds. The default is 300 seconds. </li>
|
||||
<br /> Example: <br />
|
||||
<code>define Temp1 OWTHERM 14B598010800 300 </code><br />
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWTHERMset">
|
||||
<b>Set</b></a>
|
||||
<ul>
|
||||
<li><a name="owtherm_interval">
|
||||
<code>set <name> interval <int></code></a><br /> Temperature
|
||||
measurement intervall in seconds. The default is 300 seconds.</li>
|
||||
<li><a name="owtherm_tempHigh">
|
||||
<code>set <name> tempHigh <float></code></a>
|
||||
<br /> The high alarm temperature (on the temperature scale chosen by the
|
||||
attribute value) </li>
|
||||
<li><a name="owtherm_tempLow">
|
||||
<code>set <name> tempLow <float></code></a>
|
||||
<br /> The low alarm temperature (on the temperature scale chosen by the
|
||||
attribute value) </li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWTHERMget">
|
||||
<b>Get</b></a>
|
||||
<ul>
|
||||
<li><a name="owtherm_id">
|
||||
<code>get <name> id</code></a>
|
||||
<br /> Returns the full 1-Wire device id OW_FAMILY.ROM_ID.CRC </li>
|
||||
<li><a name="owtherm_present">
|
||||
<code>get <name> present</code></a>
|
||||
<br /> Returns 1 if this 1-Wire device is present, otherwise 0. </li>
|
||||
<li><a name="owtherm_interval2">
|
||||
<code>get <name> interval</code></a><br />Returns temperature
|
||||
measurement interval in seconds.</li>
|
||||
<li><a name="owtherm_temperature">
|
||||
<code>get <name> temperature</code></a><br />Obtain the temperature. </li>
|
||||
<li><a name="owtherm_alarm">
|
||||
<code>get <name> alarm</code></a><br />Obtain the alarm temperature
|
||||
values. </li>
|
||||
</ul>
|
||||
<br />
|
||||
<a name="OWTHERMattr">
|
||||
<b>Attributes</b></a>
|
||||
<ul>
|
||||
<li><a name="owtherm_stateAL"><code>attr <name> stateAL <string></code>
|
||||
</a>
|
||||
<br />character string for denoting low alarm condition, default is red down
|
||||
triangle, e.g. the code <span style="color:red">&#x25BE;</span>
|
||||
leading to the sign <span style="color:red">▾</span>
|
||||
</li>
|
||||
<li><a name="owtherm_stateAH"><code>attr <name> stateAH <string></code>
|
||||
</a>
|
||||
<br />character string for denoting high alarm condition, default is red upward
|
||||
triangle, e.g. the code <span style="color:red">&#x25B4;</span>
|
||||
leading to the sign <span style="color:red">▴</span>
|
||||
</li>
|
||||
<li><a name="owtherm_tempOffset"><code>attr <name> tempOffset
|
||||
<float></code>
|
||||
</a>
|
||||
<br />temperature offset in °C added to the raw temperature reading. </li>
|
||||
<li><a name="owtherm_tempUnit"><code>attr <name> tempUnit
|
||||
Celsius|Kelvin|Fahrenheit|C|K|F</code>
|
||||
</a>
|
||||
<br />unit of measurement (temperature scale), default is Celsius = °C </li>
|
||||
<li><a name="owtherm_tempHigh2">
|
||||
<code>attr <name> tempHigh <float></code>
|
||||
</a>
|
||||
<br /> high alarm temperature (on the temperature scale chosen by the attribute
|
||||
value). </li>
|
||||
<li><a name="owtherm_tempLow2">
|
||||
<code>attr <name> tempLow <float></code>
|
||||
</a>
|
||||
<br /> low alarm temperature (on the temperature scale chosen by the attribute
|
||||
value). </li>
|
||||
<li><a name="owtherm_event"><code>attr <name> event on-change|on-update
|
||||
</code></a>This attribte work similarly, but not identically to the standard event-on-update-change/event-on-update-reading attribute.
|
||||
<ul><li><code>event on-update</code> (default) will write a notify/FileLog event any time a measurement is received.</li>
|
||||
<li><code>event on-change</code> will write a notify/FileLog event only when a measurement is different from the previous one.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Standard attributes alias, comment, <a href="#eventMap">eventMap</a>, <a href="#loglevel">loglevel</a>, <a href="#webCmd">webCmd</a></li>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -158,3 +158,66 @@ ALL3076_Define($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="ALL3076"></a>
|
||||
<h3>ALL3076</h3>
|
||||
<ul>
|
||||
Note: this module needs the HTTP::Request and LWP::UserAgent perl modules.
|
||||
<br><br>
|
||||
<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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -230,3 +230,53 @@ ALL4027_GetStatus($)
|
||||
}
|
||||
}
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="ALL4027"></a>
|
||||
<h3>ALL4027</h3>
|
||||
<ul>
|
||||
Note: this module needs the HTTP::Request and LWP::UserAgent perl modules.
|
||||
<br><br>
|
||||
<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
|
||||
on-for-timer <Seconds>
|
||||
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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -161,3 +161,46 @@ WEBIO_GetStatus($)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="WEBIO"></a>
|
||||
<h3>WEBIO</h3>
|
||||
<ul>
|
||||
Note: this module needs the HTTP::Request and LWP::UserAgent perl modules.
|
||||
<br><br>
|
||||
<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>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -198,3 +198,45 @@ WEBIO_12DIGITAL_GetStatus($)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="WEBIO_12DIGITAL"></a>
|
||||
<h3>WEBIO_12DIGITAL</h3>
|
||||
<ul>
|
||||
Note: this module needs the HTTP::Request and LWP::UserAgent perl modules.
|
||||
<br><br>
|
||||
<a name="WEBIO_12DIGITALdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> WEBIO_12DIGITAL <ip-address> <outputport> <delay></code>
|
||||
<br><br>
|
||||
Defines an Web-IO-Digital device (Box with up to 12 digital in/outputs, www.wut.de) via ip address. The status of the device is also pooled (delay interval).<br><br>
|
||||
|
||||
Examples:
|
||||
<ul>
|
||||
<code>define motor1 WEBIO_12DIGITAL 192.168.8.200 1 60</code><br>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="WEBIO_12DIGITALset"></a>
|
||||
<b>Set </b>
|
||||
<ul>
|
||||
<code>set <name> <value></code>
|
||||
<br><br>
|
||||
where <code>value</code> is one of:<br>
|
||||
<pre>
|
||||
on off
|
||||
</pre>
|
||||
Examples:
|
||||
<ul>
|
||||
<code>set motor1 on</code><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -279,3 +279,104 @@ NetIO230B_GetConfiguration($)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="NetIO230B"></a>
|
||||
<h3>NetIO230B</h3>
|
||||
<ul>
|
||||
<p>
|
||||
fhem-module for NetIO 230B Power Distribution Unit (see: <a
|
||||
href="http://www.koukaam.se/showproduct.php?article_id=1502">NetIO 230B
|
||||
(koukaam.se)</a>)
|
||||
</p>
|
||||
Note: this module needs the HTTP::Request and LWP::UserAgent perl modules.
|
||||
<br />
|
||||
Please also note: the PDU must use firmware 3.1 or later and set to unencrypted mode.
|
||||
<br /><br />
|
||||
<a name="NETIO230Bdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
|
||||
<li><code>define <name> NetIO230B <ip-address> <socket number(s)
|
||||
> [<user name> <password>]</code></li>
|
||||
|
||||
<li><code>define <name> NetIO230B <ip-address> <socket number(s)
|
||||
> [<config file path>]</code></li>
|
||||
|
||||
<p>
|
||||
Defines a switching device, where sockets can be switched
|
||||
</p>
|
||||
<ul>
|
||||
<li>separately (just use 0-4 as socket number)</li>
|
||||
<li>all together (use 1234 as socket number)</li>
|
||||
<li>in arbitrary groups (e.g 13 switches socket 1 and 3, 42
|
||||
switches socket 2 and 4, etc...), invalid numbers are
|
||||
ignored</li>
|
||||
</ul>
|
||||
<p>
|
||||
User name and password are optional. When no user name or
|
||||
password is passed, the module looks for a configfile at
|
||||
'/var/log/fhem/netio.conf'. If no config file is found, it
|
||||
uses 'admin/admin' as user/pass, since this is the default
|
||||
configuration for the device.
|
||||
<p>
|
||||
Alternatively you can pass a path to a configfile instead of
|
||||
the user/pass combo. (e.g. /var/tmp/tmp.conf)
|
||||
Configfile-Format:<br />
|
||||
<ul>
|
||||
<code>
|
||||
%config= (<br />
|
||||
host => "192.168.61.40",<br />
|
||||
user => "admin",<br />
|
||||
password => "admin"<br />
|
||||
);</code>
|
||||
<br /><br /><small>(All settings optional)</small>
|
||||
</ul>
|
||||
</p>
|
||||
<p>Examples:</p>
|
||||
<ul>
|
||||
<li><code>define Socket3 NetIO230B 192.168.178.10 3</code></li>
|
||||
<li><code>define Socket1_and_4 NetIO230B 192.168.178.10 14</code></li>
|
||||
<li><code>define coffeemaker NetIO230B 192.168.178.10 1 username secretpassword</code></li>
|
||||
<li><code>define coffeemaker_and_light NetIO230B 192.168.178.10 23 /var/log/kitchen.conf</code></li>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="NETIO230Bget"></a>
|
||||
<b>Get </b>
|
||||
<ul>
|
||||
<code>get <name> state</code>
|
||||
<br><br>
|
||||
returns the state of the socket(s)<br>
|
||||
|
||||
Example:
|
||||
<ul>
|
||||
<code>get coffeemaker_and_light</code> => <code>on or off</code><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
<a name="NETIO230Bset"></a>
|
||||
<b>Set </b>
|
||||
<ul>
|
||||
<code>set <name> <value></code>
|
||||
<br><br>
|
||||
where <code>value</code> is one of:<br>
|
||||
<pre>
|
||||
on
|
||||
off
|
||||
</pre>
|
||||
Examples:
|
||||
<ul>
|
||||
<code>set coffeemaker_and_light on</code><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -386,3 +386,86 @@ RFXCOM_Ready($)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="RFXCOM"></a>
|
||||
<h3>RFXCOM</h3>
|
||||
<ul>
|
||||
<table>
|
||||
<tr><td>
|
||||
This module is for the old <a href="http://www.rfxcom.com">RFXCOM</a> USB or LAN based 433 Mhz RF receivers and transmitters (order order code 80002 and others). It does not support the new RFXtrx433 transmitter because it uses a different protocol. See <a href="#RFXTRX">RFXTRX</a> for support of the RFXtrx433 transmitter.<br>
|
||||
These receivers supports many protocols like Oregon Scientific weather sensors, RFXMeter devices, X10 security and lighting devices and others. <br>
|
||||
Currently the following parser modules are implemented: <br>
|
||||
<ul>
|
||||
<li> 41_OREGON.pm (see device <a href="#OREGON">OREGON</a>): Process messages Oregon Scientific weather sensors.
|
||||
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.
|
||||
Until now the following Oregon Scientific weather sensors have been tested successfully: BTHR918, BTHR918N, PCR800, RGR918, THGR228N, THGR810, THR128, THWR288A, WTGR800, WGR918. It will probably work with many other Oregon sensors supported by RFXCOM receivers. Please give feedback if you use other sensors.<br>
|
||||
</li>
|
||||
<li> 42_RFXMETER.pm (see device <a href="#RFXMETER">RFXMETER</a>): Process RFXCOM RFXMeter devices. See <a href="http://www.rfxcom.com/sensors.htm">http://www.rfxcom.com/sensors.htm</a>.</li>
|
||||
<li> 43_RFXX10REC.pm (see device <a href="#RFXX10REC">RFXX10REC</a>): Process X10 security and X10 lighting devices. </li>
|
||||
</ul>
|
||||
<br>
|
||||
Note: this module requires the Device::SerialPort or Win32::SerialPort module
|
||||
if the devices is connected via USB or a serial port.
|
||||
<br><br>
|
||||
<a name="RFXCOMdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> RFXCOM <device> [noinit] </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>
|
||||
<ul>
|
||||
noninit is optional and issues that the RFXCOM device should not be
|
||||
initialized. This is useful if you share a RFXCOM device. It is also useful
|
||||
for testing to simulate a RFXCOM receiver via netcat or via FHEM2FHEM.
|
||||
<br>
|
||||
<br>
|
||||
Example: <br>
|
||||
<code>define RFXCOMTCP RFXCOM 192.168.1.5:10001
|
||||
<br>
|
||||
<code>define RFXCOMTCP2 RFXCOM 192.168.1.121:10001 noinit
|
||||
<br>
|
||||
</ul>
|
||||
<br>
|
||||
</table>
|
||||
<ul>
|
||||
<li><a href="#attrdummy">dummy</a></li><br>
|
||||
<li>longids<br>
|
||||
Comma separated list of device-types for RFXCOM that should be handled using long IDs. This additional ID is a one byte hex string and is generated by the Oregon sensor when is it powered on. The value seems to be randomly generated. This has the advantage that you may use more than one Oregon sensor of the same type even if it has no switch to set a sensor id. For example the author uses two BTHR918N sensors at the same time. All have different deviceids. The drawback is that the deviceid changes after changing batteries. All devices listed as longids will get an additional one byte hex string appended to the device name.<br>
|
||||
Default is to use long IDs for all devices.
|
||||
<br><br>
|
||||
Examples:<PRE>
|
||||
# Do not use any long IDs for any devices:
|
||||
attr RFXCOMUSB longids 0
|
||||
# Use any long IDs for all devices (this is default):
|
||||
attr RFXCOMUSB longids 1
|
||||
# Use longids for BTHR918N devices.
|
||||
# Will generate devices names like BTHR918N_f3.
|
||||
attr RFXCOMUSB longids BTHR918N
|
||||
# Use longids for TX3_T and TX3_H devices.
|
||||
# Will generate devices names like TX3_T_07, TX3_T_01 ,TX3_H_07.
|
||||
attr RFXCOMUSB longids TX3_T,TX3_H</PRE>
|
||||
</li><br>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -1073,3 +1073,47 @@ OREGON_Parse($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="OREGON"></a>
|
||||
<h3>OREGON</h3>
|
||||
<ul>
|
||||
The OREGON module interprets Oregon sensor messages received by a RFXCOM receiver. You need to define a RFXCOM receiver first.
|
||||
See <a href="#RFXCOM">RFXCOM</a>.
|
||||
|
||||
<br><br>
|
||||
|
||||
<a name="OREGONdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> OREGON <deviceid></code> <br>
|
||||
<br>
|
||||
<deviceid> is the device identifier of the Oregon sensor. It consists of the sensors name and a one byte hex string (00-ff) that identifies the sensor. The define statement with the deviceid is generated automatically by autocreate. The following sensor names are used:
|
||||
BTHR918, BTHR918N, PCR800 RGR918, RTGR328N, THN132N, THGR228N, THGR328N, THGR918, THR128, THWR288A, THGR810, UV138, UVN800, WGR918, WGR800, WTGR800_A, WTGR800_T.
|
||||
<br>
|
||||
The one byte hex string is generated by the Oregon sensor when is it powered on. The value seems to be randomly generated. This has the advantage that you may use more than one Oregon sensor of the same type even if it has no switch to set a sensor id. For exampple the author uses three BTHR918 sensors at the same time. All have different deviceids. The drawback is that the deviceid changes after changing batteries.
|
||||
<br><br>
|
||||
Example: <br>
|
||||
<code>define Kaminzimmer OREGON BTHR918N_ab</code>
|
||||
<br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="OREGONset"></a>
|
||||
<b>Set</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="OREGONget"></a>
|
||||
<b>Get</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="OREGONattr"></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>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -247,3 +247,52 @@ RFXMETER_Parse($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="RFXMETER"></a>
|
||||
<h3>RFXMETER</h3>
|
||||
<ul>
|
||||
The RFXMETER module interprets RFXCOM RFXMeter messages received by a RFXCOM receiver. You need to define an RFXCOM receiver first.
|
||||
See the <a href="#RFXCOM">RFXCOM</a>.
|
||||
|
||||
<br><br>
|
||||
|
||||
<a name="RFXMETERdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> RFXMETER <deviceid> [<scalefactor>] [<unitname>]</code> <br>
|
||||
<br>
|
||||
<deviceid> is the device identifier of the RFXMeter sensor and is a one byte hexstring (00-ff).
|
||||
<br>
|
||||
<scalefactor> is an optional scaling factor. It is multiplied to the value that is received from the RFXmeter sensor.
|
||||
<br>
|
||||
<unitname> is an optional string that describes the value units. It is added to the Reading generated to describe the values.
|
||||
<br><br>
|
||||
Example: <br>
|
||||
<code>define RFXWater RFXMETER 00 0.5 ltr</code>
|
||||
<br>
|
||||
<code>define RFXPower RFXMETER 01 0.001 kwh</code>
|
||||
<br>
|
||||
<code>define RFXGas RFXMETER 02 0.01 cu_m</code>
|
||||
<br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="RFXMETERset"></a>
|
||||
<b>Set</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="RFXMETERget"></a>
|
||||
<b>Get</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="RFXMETERattr"></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>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -565,3 +565,86 @@ RFXX10REC_Parse($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="RFXX10REC"></a>
|
||||
<h3>RFXX10REC</h3>
|
||||
<ul>
|
||||
The RFXX10REC module interprets X10 security and X10 lighting messages received by a RFXCOM RF receiver. Reported also to work with KlikAanKlikUit. You need to define an RFXCOM receiver first.
|
||||
See <a href="#RFXCOM">RFXCOM</a>.
|
||||
|
||||
<br><br>
|
||||
|
||||
<a name="RFXX10RECdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> RFXX10REC <type> <deviceid> <devicelog> [<deviceid> <devicelog>] </code> <br>
|
||||
<br>
|
||||
<code><type></code>
|
||||
<ul>
|
||||
specifies the type of the X10 device: <br>
|
||||
X10 security devices:
|
||||
<ul>
|
||||
<li> <code>ds10a</code> (X10 security ds10a Door/Window Sensor or compatible devices. This device type reports the status of the switch [Open/Closed], status of the delay switch [min|max]], and battery status [ok|low].)</li>
|
||||
<li> <code>ms10a</code> (X10 security ms10a motion sensor. This device type reports the status of motion sensor [normal|alert] and battery status [ok|low].))</li>
|
||||
<li> <code>sd90</code> (Marmitek sd90 smoke detector. This device type reports the status of the smoke detector [normal|alert] and battery status [ok|low].)</li>
|
||||
<li> <code>kr18</code> (X10 security remote control. Report the Reading "Security" with values [Arm|Disarm], "ButtonA" and "ButtonB" with values [on|off] )</li>
|
||||
</ul>
|
||||
X10 lighting devices:
|
||||
<ul>
|
||||
<li> <code>ms14a</code> (X10 motion sensor. Reports [normal|alert] on the first deviceid (motion sensor) and [on|off] for the second deviceid (light sensor)) </li>
|
||||
<li> <code>x10</code> (All other x10 devices. Report [on|off] on both deviceids.)</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
<code><deviceid></code>
|
||||
<ul>
|
||||
specifies the first device id of the device. X10 security have a a 16-Bit device id which has to be written as a hex-string (example "5a54").
|
||||
A X10 lighting device has a house code A..P followed by a unitcode 1..16 (example "B1").
|
||||
</ul>
|
||||
<br>
|
||||
<code><devicelog></code>
|
||||
<ul>
|
||||
is the name of the Reading used to report. Suggested: "Window" or "Door" for ds10a, "motion" for motion sensors, "Smoke" for sd90.
|
||||
</ul>
|
||||
<br>
|
||||
<code><deviceid2></code>
|
||||
<ul>
|
||||
is optional and specifies the second device id of the device if it exists. For example sd90 smoke sensors can be configured to report two device ids. ms14a motion sensors report motion status on the first deviceid and the status of the light sensor on the second deviceid.
|
||||
</ul>
|
||||
<br>
|
||||
<code><devicelog2></code>
|
||||
<ul>
|
||||
is optional for the name used for the Reading of <code><deviceid2></code>.
|
||||
</ul>
|
||||
<br>
|
||||
Example: <br>
|
||||
<code>define livingroom_window RFXX10REC ds10a 72cd Window</code>
|
||||
<br>
|
||||
<code>define motion_sensor1 RFXX10REC ms10a 55c6 motion</code>
|
||||
<br>
|
||||
<code>define smoke_sensor1 RFXX10REC sd90 54d3 Smoke 54d3 Smoketest</code>
|
||||
<br>
|
||||
<code>define motion_sensor2 RFXX10REC ms14a A1 motion A2 light</code>
|
||||
<br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="RFXX10RECset"></a>
|
||||
<b>Set</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="RFXX10RECget"></a>
|
||||
<b>Get</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="RFXX10RECattr"></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>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -405,3 +405,94 @@ TRX_Ready($)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="TRX"></a>
|
||||
<h3>TRX</h3>
|
||||
<ul>
|
||||
<table>
|
||||
<tr><td>
|
||||
This module is for the <a href="http://www.rfxcom.com">RFXCOM</a> RFXtrx433 USB based 433 Mhz RF transmitters.
|
||||
This USB based transmitter is able to receive and transmit many protocols like Oregon Scientific weather sensors, X10 security and lighting devices, ARC ((address code wheels) HomeEasy, KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO,
|
||||
AB600, Duewi, DomiaLite, COCO) and others. <br>
|
||||
Currently the following parser modules are implemented: <br>
|
||||
<ul>
|
||||
<li> 46_TRX_WEATHER.pm (see device <a href="#TRX">TRX</a>): Process messages Oregon Scientific weather sensors.
|
||||
See <a href="http://www.rfxcom.com/oregon.htm">http://www.rfxcom.com/oregon.htm</a> for a list of
|
||||
Oregon Scientific weather sensors that could be received by the RFXtrx433 tranmitter.
|
||||
Until now the following Oregon Scientific weather sensors have been tested successfully: BTHR918, BTHR918N, PCR800, RGR918, THGR228N, THGR810, THR128, THWR288A, WTGR800, WGR918. It will also work with many other Oregon sensors supported by RFXtrx433. Please give feedback if you use other sensors.<br>
|
||||
</li>
|
||||
<li> 46_TRX_SECURITY.pm (see device <a href="#TRX_SECURITY">TRX_SECURITY</a>): Receive X10, KD101 and Visonic security sensors.</li>
|
||||
<li> 46_TRX_LIGHT.pm (see device <a href="#RFXX10REC">RFXX10REC</a>): Process X10, ARC, ELRO AB400D, Waveman, Chacon EMW200, IMPULS, RisingSun, Philips SBC, AC, HomeEasy EU and ANSLUT lighting devices (switches and remote control). ARC is a protocol used by devices from HomeEasy, KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi, DomiaLite and COCO with address code wheels. AC is the protocol used by different brands with units having a learning mode button:
|
||||
KlikAanKlikUit, NEXA, CHACON, HomeEasy UK.</li>
|
||||
</ul>
|
||||
<br>
|
||||
Note: this module requires the Device::SerialPort or Win32::SerialPort module
|
||||
if the devices is connected via USB or a serial port.
|
||||
<br><br>
|
||||
<a name="TRXdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> TRX <device> [noinit] </code><br>
|
||||
</ul>
|
||||
<br>
|
||||
USB-connected:<br><ul>
|
||||
<device> specifies the USB port to communicate with the RFXtrx433 receiver.
|
||||
Normally on Linux the device will be named /dev/ttyUSBx, where x is a number.
|
||||
For example /dev/ttyUSB0. Please note that RFXtrx433 normally operates at 38400 baud. You may specify the baudrate used after the @ char.<br>
|
||||
<br>
|
||||
Example: <br>
|
||||
<code>define RFXTRXUSB TRX /dev/ttyUSB0@38400</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>
|
||||
<ul>
|
||||
noninit is optional and issues that the RFXtrx433 device should not be
|
||||
initialized. This is useful if you share a RFXtrx433 device via LAN. It is
|
||||
also useful for testing to simulate a RFXtrx433 receiver via netcat or via
|
||||
FHEM2FHEM.
|
||||
|
||||
<br>
|
||||
<br>
|
||||
Example: <br>
|
||||
<code>define RFXTRXTCP TRX 192.168.1.5:10001
|
||||
<br>
|
||||
<code>define RFXTRXTCP2 TRX 192.168.1.121:10001 noinit
|
||||
<br>
|
||||
</ul>
|
||||
<br>
|
||||
</table>
|
||||
|
||||
<a name="TRXattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#attrdummy">dummy</a></li><br>
|
||||
<li>longids<br>
|
||||
Comma separated list of device-types for TRX_WEATHER that should be handled using long IDs. This additional ID is a one byte hex string and is generated by the Oregon sensor when is it powered on. The value seems to be randomly generated. This has the advantage that you may use more than one Oregon sensor of the same type even if it has no switch to set a sensor id. For example the author uses two BTHR918N sensors at the same time. All have different deviceids. The drawback is that the deviceid changes after changing batteries. All devices listed as longids will get an additional one byte hex string appended to the device name.<br>
|
||||
Default is to use no long IDs.
|
||||
<br><br>
|
||||
Examples:<PRE>
|
||||
# Do not use any long IDs for any devices (this is default):
|
||||
attr RFXCOMUSB longids 0
|
||||
# Use long IDs for all devices:
|
||||
attr RFXCOMUSB longids 1
|
||||
# Use longids for BTHR918N devices.
|
||||
# Will generate devices names like BTHR918N_f3.
|
||||
attr RFXTRXUSB longids BTHR918N
|
||||
# Use longids for TX3_T and TX3_H devices.
|
||||
# Will generate devices names like TX3_T_07, TX3_T_01 ,TX3_H_07.
|
||||
attr RFXTRXUSB longids TX3_T,TX3_H</PRE>
|
||||
</li><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -551,3 +551,112 @@ TRX_LIGHT_Parse($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="TRX_LIGHT"></a>
|
||||
<h3>TRX_LIGHT</h3>
|
||||
<ul>
|
||||
The TRX_LIGHT module receives and sends X10, ARC, ELRO AB400D, Waveman, Chacon EMW200, IMPULS, RisingSun, AC, HomeEasy EU and ANSLUT lighting devices (switches and remote control). Allows to send Philips SBC (receive not possible). ARC is a protocol used by devices from HomeEasy, KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi, DomiaLite and COCO with address code wheels. AC is the protocol used by different brands with units having a learning mode button:
|
||||
KlikAanKlikUit, NEXA, CHACON, HomeEasy UK. <br> You need to define an RFXtrx433 transceiver receiver first.
|
||||
See <a href="#TRX">TRX</a>.
|
||||
|
||||
<br><br>
|
||||
|
||||
<a name="TRX_LIGHTdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> TRX_LIGHT <type> <deviceid> <devicelog> [<deviceid2> <devicelog2>] </code> <br>
|
||||
<br>
|
||||
<code><type></code>
|
||||
<ul>
|
||||
specifies the type of the device: <br>
|
||||
X10 lighting devices:
|
||||
<ul>
|
||||
<li> <code>MS14A</code> (X10 motion sensor. Reports [normal|alert] on the first deviceid (motion sensor) and [on|off] for the second deviceid (light sensor)) </li>
|
||||
<li> <code>X10</code> (All other x10 devices. Report [off|on|dim|bright|all_off|all_on] on both deviceids.)</li>
|
||||
<li> <code>ARC</code> (ARC devices. ARC is a protocol used by devices from HomeEasy, KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi, DomiaLite and COCO with address code wheels. Report [off|on|all_off|all_on|chime].)</li>
|
||||
<li> <code>AB400D</code> (ELRO AB400D devices. Report [off|on].)</li>
|
||||
<li> <code>WAVEMAN</code> (Waveman devices. Report [off|on].)</li>
|
||||
<li> <code>EMW200</code> (Chacon EMW200 devices. Report [off|on|all_off|all_on].)</li>
|
||||
<li> <code>IMPULS</code> (IMPULS devices. Report [off|on].)</li>
|
||||
<li> <code>RISINGSUN</code> (RisingSun devices. Report [off|on].)</li>
|
||||
<li> <code>PHILIPS_SBC</code> (Philips SBC devices. Send [off|on|all_off|all_on].)</li>
|
||||
<li> <code>AC</code> (AC devices. AC is the protocol used by different brands with units having a learning mode button: KlikAanKlikUit, NEXA, CHACON, HomeEasy UK. Report [off|on|level <NUM>|all_off|all_on|all_level <NUM>].)</li>
|
||||
<li> <code>HOMEEASY</code> (HomeEasy EU devices. Report [off|on|level|all_off|all_on|all_level].)</li>
|
||||
<li> <code>ANSLUT</code> (Anslut devices. Report [off|on|level|all_off|all_on|all_level].)</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
<code><deviceid></code>
|
||||
<ul>
|
||||
specifies the first device id of the device. <br>
|
||||
A lighting device normally has a house code A..P followed by a unitcode 1..16 (example "B1").<br>
|
||||
For AC, HomeEasy EU and ANSLUT it is a 10 Character-Hex-String for the deviceid, consisting of <br>
|
||||
- unid-id: 8-Char-Hex: 00000001 to 03FFFFFF<br>
|
||||
- unit-code: 2-Char-Hex: 01 to 10 <br>
|
||||
</ul>
|
||||
<br>
|
||||
<code><devicelog></code>
|
||||
<ul>
|
||||
is the name of the Reading used to report. Suggested: "motion" for motion sensors.
|
||||
</ul>
|
||||
<br>
|
||||
<code><deviceid2></code>
|
||||
<ul>
|
||||
is optional and specifies the second device id of the device if it exists. For example ms14a motion sensors report motion status on the first deviceid and the status of the light sensor on the second deviceid.
|
||||
</ul>
|
||||
<br>
|
||||
<code><devicelog2></code>
|
||||
<ul>
|
||||
is optional for the name used for the Reading of <code><deviceid2></code>.
|
||||
</ul>
|
||||
<br>
|
||||
Example: <br>
|
||||
<code>define motion_sensor2 TRX_LIGHT MS14A A1 motion A2 light</code>
|
||||
<br>
|
||||
<code>define Steckdose TRX_LIGHT ARC G2 light</code>
|
||||
<br>
|
||||
<code>define light TRX_LIGHT AC 0101010101 light</code>
|
||||
<br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="TRX_LIGHTset"></a>
|
||||
<b>Set </b>
|
||||
<ul>
|
||||
<code>set <name> <value> [<levelnum>]</code>
|
||||
<br><br>
|
||||
where <code>value</code> is one of:<br>
|
||||
<pre>
|
||||
off
|
||||
on
|
||||
dim # only for X10, KOPPLA
|
||||
bright # only for X10, KOPPLA
|
||||
all_off # only for X10, ARC, EMW200, AC, HOMEEASY, ANSLUT
|
||||
all_on # only for X10, ARC, EMW200, AC, HOMEEASY, ANSLUT
|
||||
chime # only for ARC
|
||||
level <levelnum> # only AC, HOMEEASY, ANSLUT: set level to <levelnum> (range: 0=0% to 15=100%)
|
||||
</pre>
|
||||
Example: <br>
|
||||
<code>set Steckdose on</code>
|
||||
<br>
|
||||
</ul><br>
|
||||
|
||||
<a name="TRX_LIGHTget"></a>
|
||||
<b>Get</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="TRX_LIGHTattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#ignore">ignore</a></li>
|
||||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||||
<li><a href="#event-on-update-reading">event-on-update-reading</a></li>
|
||||
<li><a href="#event-on-change-reading">event-on-change-reading</a></li>
|
||||
</ul>
|
||||
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -377,3 +377,81 @@ TRX_SECURITY_Parse($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="TRX_SECURITY"></a>
|
||||
<h3>TRX_SECURITY</h3>
|
||||
<ul>
|
||||
The TRX_SECURITY module interprets X10, KD101 and Visonic security sensors received by a RFXCOM RFXtrx433 RF receiver. You need to define an RFXtrx433 receiver first. See <a href="#TRX">TRX</a>.
|
||||
|
||||
<br><br>
|
||||
|
||||
<a name="TRX_SECURITYdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> TRX_SECURITY <type> <deviceid> <devicelog> [<deviceid2> <devicelog2>] </code> <br>
|
||||
<br>
|
||||
<code><type></code>
|
||||
<ul>
|
||||
specifies one of the following security devices:
|
||||
<ul>
|
||||
<li> <code>DS10A</code> (X10 security ds10a Door/Window Sensor or compatible devices. This device type reports the status of the switch [Open/Closed], status of the delay switch [min|max]], and battery status [ok|low].)</li>
|
||||
<li> <code>MS10A</code> (X10 security ms10a motion sensor. This device type reports the status of motion sensor [normal|alert] and battery status [ok|low].))</li>
|
||||
<li> <code>SD90</code> (Marmitek sd90 smoke detector. This device type reports the status of the smoke detector [normal|alert] and battery status [ok|low].)</li>
|
||||
<li> <code>KR18</code> (X10 security remote control. Report the Reading "Security" with values [Arm|Disarm], "ButtonA" and "ButtonB" with values [on|off] )</li>
|
||||
<li> <code>KD101</code> (KD101 smoke sensor. Report the Reading "smoke" with values [normal|alert])</li>
|
||||
<li> <code>VISONIC_WINDOW</code> (VISONIC security Door/Window Sensor or compatible devices. This device type reports the status of the switch [Open/Closed] and battery status [ok|low].)</li>
|
||||
<li> <code>VISONIC_MOTION</code> (VISONIC security motion sensor. This device type reports the status of motion sensor [normal|alert] and battery status [ok|low].))</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
<code><deviceid></code>
|
||||
<ul>
|
||||
specifies the first device id of the device. X10 security (DS10A, MS10A) and SD90 have a a 16 bit device id which has to be written as a hex-string (example "5a54"). All other devices have a 24 bit device id.
|
||||
</ul>
|
||||
<br>
|
||||
<code><devicelog></code>
|
||||
<ul>
|
||||
is the name of the Reading used to report. Suggested: "Window" or "Door" for ds10a, "motion" for motion sensors, "smoke" for sd90.
|
||||
</ul>
|
||||
<br>
|
||||
<code><deviceid2></code>
|
||||
<ul>
|
||||
is optional and specifies the second device id of the device if it exists. For example sd90 smoke sensors can be configured to report two device ids.
|
||||
</ul>
|
||||
<br>
|
||||
<code><devicelog2></code>
|
||||
<ul>
|
||||
is optional for the name used for the Reading of <code><deviceid2></code>.
|
||||
</ul>
|
||||
<br>
|
||||
Example: <br>
|
||||
<code>define livingroom_window TRX_SECURITY ds10a 72cd Window</code>
|
||||
<br>
|
||||
<code>define motion_sensor1 TRX_SECURITY ms10a 55c6 motion</code>
|
||||
<br>
|
||||
<code>define smoke_sensor1 TRX_SECURITY sd90 54d3 Smoke 54d3 Smoketest</code>
|
||||
<br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="TRX_SECURITYset"></a>
|
||||
<b>Set</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="TRX_SECURITYget"></a>
|
||||
<b>Get</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="TRX_SECURITYattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#ignore">ignore</a></li>
|
||||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||||
<li><a href="#event-on-update-reading">event-on-update-reading</a></li>
|
||||
<li><a href="#event-on-change-reading">event-on-change-reading</a></li>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -907,3 +907,74 @@ TRX_WEATHER_Parse($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="TRX_WEATHER"></a>
|
||||
<h3>TRX_WEATHER</h3>
|
||||
<ul>
|
||||
The TRX_WEATHER module interprets weather sensor messages received by a RTXtrx receiver. See <a href="http://www.rfxcom.com/oregon.htm">http://www.rfxcom.com/oregon.htm</a> for a list of
|
||||
Oregon Scientific weather sensors that could be received by the RFXtrx433 tranmitter. You need to define a RFXtrx433 receiver first. See
|
||||
See <a href="#TRX">TRX</a>.
|
||||
|
||||
<br><br>
|
||||
|
||||
<a name="TRX_WEATHERdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> OREGON <deviceid></code> <br>
|
||||
<br>
|
||||
<deviceid> is the device identifier of the Oregon sensor. It consists of the sensors name and (only if the attribute longids is set of the RFXtrx433) an a one byte hex string (00-ff) that identifies the sensor. If an sensor uses an switch to set an additional is then this is also added. The define statement with the deviceid is generated automatically by autocreate. The following sensor names are used: <br>
|
||||
"THR128" (for THR128/138, THC138),<br>
|
||||
"THGR132N" (for THC238/268,THN132,THWR288,THRN122,THN122,AW129/131),<br>
|
||||
"THWR800", <br>
|
||||
"RTHN318", <br>
|
||||
"TX3_T" (for LaCrosse TX3, TX4, TX17),<br>
|
||||
"THGR228N" (for THGN122/123, THGN132, THGR122/228/238/268),<br>
|
||||
"THGR810",<br>
|
||||
"RTGR328",<br>
|
||||
"THGR328",<br>
|
||||
"WTGR800_T" (for temperature of WTGR800),<br>
|
||||
"THGR918" (for THGR918, THGRN228, THGN500),<br>
|
||||
"TFATS34C" (for TFA TS34C),<br>
|
||||
"BTHR918",<br>
|
||||
"BTHR918N (for BTHR918N, BTHR968),<br>
|
||||
"RGR918" (for RGR126/682/918),<br>
|
||||
"PCR800",<br>
|
||||
"TFA_RAIN" (for TFA rain sensor),<br>
|
||||
"WTGR800_A" (for wind sensor of WTGR800),<br>
|
||||
"WGR800" (for wind sensor of WGR800),<br>
|
||||
"WGR918" (for wind sensor of STR918 and WGR918),<br>
|
||||
"TFA_WIND" (for TFA wind sensor)
|
||||
<br>
|
||||
<br><br>
|
||||
Example: <br>
|
||||
<code>define Tempsensor TRX_WEATHER TX3_T</code><br>
|
||||
<code>define Tempsensor3 TRX_WEATHER THR128_3</code><br>
|
||||
<code>define Windsensor TRX_WEATHER WGR918_A</code><br>
|
||||
<code>define Regensensor TRX_WEATHER RGR918</code><br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="TRX_WEATHERset"></a>
|
||||
<b>Set</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="TRX_WEATHERget"></a>
|
||||
<b>Get</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="TRX_WEATHERattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#ignore">ignore</a></li>
|
||||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||||
<li><a href="#event-on-update-reading">event-on-update-reading</a></li>
|
||||
<li><a href="#event-on-change-reading">event-on-change-reading</a></li>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -309,3 +309,183 @@ IPCAM_guessFileFormat($) {
|
||||
# vim: ts=2:et
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="IPCAM"></a>
|
||||
<h3>IPCAM</h3>
|
||||
<ul>
|
||||
<br>
|
||||
|
||||
<a name"IPCAMdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> IPCAM <ip[:port]></code>
|
||||
<br><br>
|
||||
|
||||
Defines a network camera device to trigger snapshots on events.<br><br>
|
||||
|
||||
Network cameras (IP cameras) usually have a build-in function to create
|
||||
snapshot images. This module enables the event- or time-controlled
|
||||
recording of these images.<br>
|
||||
In addition, this module allows the recording of many image formats like
|
||||
JPEG, PNG, GIF, TIFF, BMP, ICO, PPM, XPM, XBM and SVG. The only requirement
|
||||
is that the recorded image must be accessible via a URL.<br>
|
||||
So it is also possible to record images of e.g. a public Weather Camera
|
||||
from the internet or any picture of a website.<br><br>
|
||||
|
||||
Examples:<br><br>
|
||||
A local ip-cam takes 5 snapshots with 10 seconds delay per call:<br>
|
||||
<ul>
|
||||
<code>define ipcam IPCAM 192.168.1.205</code><br>
|
||||
<code>attr ipcam delay 10</code><br>
|
||||
<code>attr ipcam path snapshot.cgi?user=foo&pwd=bar</code><br>
|
||||
<code>attr ipcam snapshots 5</code><br>
|
||||
<code>attr ipcam storage /srv/share/surveillance/snapshots</code><br>
|
||||
</ul><br>
|
||||
|
||||
A notify on a motion detection of a specified device:<br>
|
||||
<ul>
|
||||
<code>define MOTION.not.01 notify GH.ga.SEC.MD.01:.*on.* get ipcam image</code><br>
|
||||
</ul><br>
|
||||
|
||||
Send an eMail after snapshots are taken:<br>
|
||||
<ul>
|
||||
<code>define MOTION.not.02 notify ipcam:.*snapshots.* { myEmailFunction("%NAME") }</code><br>
|
||||
</ul><br>
|
||||
|
||||
A public web-cam takes only 1 snapshot per call:<br>
|
||||
<ul>
|
||||
<code>define schloss IPCAM http://www2.braunschweig.de</code><br>
|
||||
<code>attr schloss path webcam/schloss.jpg</code><br>
|
||||
<code>attr schloss storage /srv/share/surveillance/snapshots</code><br>
|
||||
</ul><br>
|
||||
|
||||
An at-Job takes every hour a snapshot:<br>
|
||||
<ul>
|
||||
<code>define snapshot_schloss at +*00:01:00 get schloss image</code><br>
|
||||
</ul><br>
|
||||
|
||||
</ul>
|
||||
|
||||
<b>Set</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="IPCAMget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
<code>get <name> <value></code>
|
||||
<br><br>
|
||||
where <code>value</code> is one of:<br>
|
||||
<ul>
|
||||
<li>
|
||||
<code>image</code><br>
|
||||
Get one or more images of the defined IP-Cam. The number of images<br>
|
||||
and the time interval between images can be specified using the<br>
|
||||
attributes <code>snapshots</code> and <code>delay</code>.
|
||||
</li>
|
||||
<li>
|
||||
<code>last</code><br>
|
||||
Show the name of the last snapshot.
|
||||
</li>
|
||||
<li>
|
||||
<code>snapshots</code><br>
|
||||
Show the total number of a image sequence.
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="IPCAMattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li>
|
||||
credentials<br>
|
||||
Defines the location of the credentials file.<br>
|
||||
If you prefer to store your cam credentials in a file instead be a part of the
|
||||
URI (see attributes <code>path</code> and <code>query</code>), set the full path
|
||||
with filename on this attribute.<br>
|
||||
Example: <code>attr ipcam3 credentials /etc/fhem/ipcam.conf</code><br><br>
|
||||
|
||||
The credentials file has the following structure:<br>
|
||||
<pre>
|
||||
#
|
||||
# Webcam credentials
|
||||
#
|
||||
$credentials{<name_cam1>}{username} = "<your_username>";
|
||||
$credentials{<name_cam1>}{password} = "<your_password>";
|
||||
$credentials{<name_cam2>}{username} = "<your_username>";
|
||||
$credentials{<name_cam2>}{password} = "<your_password>";
|
||||
...
|
||||
</pre>
|
||||
Replace <code><name_cam1></code> respectively <code><name_cam2></code>
|
||||
with the names of your defined ip-cams and <code><your_username></code> respectively
|
||||
<code><your_password></code> with your credentials (all without the brackets
|
||||
<code><</code> and <code>></code>!).
|
||||
</li>
|
||||
<li>
|
||||
delay<br>
|
||||
Defines the time interval between snapshots in seconds.<br>
|
||||
If more then one snapshot is taken, then it makes sense to define a short delay
|
||||
between the snapshots. On the one hand, the camera is not addressed in short intervals
|
||||
and the second may be better represented movements between images.<br>
|
||||
Example: <code>attr ipcam3 delay 10</code>
|
||||
</li>
|
||||
<li><a href="#disable">disable</a></li>
|
||||
<li><a href="#do_not_notify">do_not_notify</a></li>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
<li>
|
||||
path<br>
|
||||
Defines the path and query component of the complete <a href="http://de.wikipedia.org/wiki/Uniform_Resource_Identifier" target="_blank">URI</a> to get a snapshot of the
|
||||
camera. Is the full URI of your ip-cam for example <code>http://CAMERA_IP/snapshot.cgi?user=admin&pwd=password</code>,
|
||||
then only the path and query part is specified here (without the leading slash (/).<br>
|
||||
Example: <code>attr ipcam3 path snapshot.cgi?user=admin&pwd=password</code><br><br>
|
||||
|
||||
If you prefer to store the credentials in a file (take a look at the attribute <code>credentials</code>)
|
||||
you have to set the placeholder <code>USERNAME</code> and <code>PASSWORD</code> in the path string. These placeholders
|
||||
will be replaced with the values from the credentials file.<br>
|
||||
Example: <code>attr ipcam3 path snapshot.cgi?user=USERNAME&pwd=PASSWORD</code>
|
||||
</li>
|
||||
<li><a href="#showtime">showtime</a></li>
|
||||
<li>
|
||||
snapshots<br>
|
||||
Defines the total number of snapshots to be taken with the <code>get <name> image</code> command.
|
||||
If this attribute is not defined, then the default value is 1.<br>
|
||||
The snapshots are stored in the given path of the attribute <code>storage</code> and are
|
||||
numbered sequentially (starts with 1) like <code>snapshot_01</code>, <code>snapshot_02</code>, etc.
|
||||
Furthermore, an additional file <code>last</code> will be saved, which is identical with
|
||||
the last snapshot-image. The module checks the imagetype and stores all these files with
|
||||
the devicename and a correct extension, e.g. <code><devicename>_snapshot_01.jpg</code>.<br>
|
||||
If you like a timestamp instead a sequentially number, take a look at the attribute <code>timestamp</code>.<br>
|
||||
All files are overwritten on every <code>get <name> image</code> command (except: snapshots
|
||||
with a timestamp. So, keep an eye on your diskspace if you use a timestamp extension!).<br>
|
||||
Example: <code>attr ipcam3 snapshots 5</code>
|
||||
</li>
|
||||
<li>
|
||||
storage<br>
|
||||
Defines the location for the file storage of the snapshots. Default: <code>$modpath/www/snapshots</code><br>
|
||||
Example: <code>attr ipcam3 storage /srv/share/surveillance/snapshots</code>
|
||||
</li>
|
||||
<li>
|
||||
timestamp<br>
|
||||
If this attribute is unset or set to 0, snapshots are stored with a sequentially number
|
||||
like <code><devicename>_snapshot_01.jpg</code>, <code><devicename>_snapshot_02.jpg</code>, etc.<br>
|
||||
If you like filenames with a timestamp postfix, e.g. <code><devicename>_20121023_002602.jpg</code>,
|
||||
set this attribute to 1.
|
||||
</li>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="IPCAMevents"></a>
|
||||
<b>Generated events</b>
|
||||
<ul>
|
||||
<li>last: <name_of_device>_snapshot.<image_extension></li>
|
||||
<li>snapshots: <total_number_of_taken_snapshots_at_end></li>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -604,3 +604,69 @@ NEXTPOLL:
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
<li><a href="#event-on-update-reading">event-on-update-reading</a></li>
|
||||
<li><a href="#event-on-change-reading">event-on-change-reading</a></li>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -489,3 +489,78 @@ POKEYS_Disconnect($)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="POKEYS"></a>
|
||||
<h3>POKEYS</h3>
|
||||
<ul>
|
||||
The POKEYS module is used to control the LAN POKEYS device (<a href="http://www.poscope.com/pokeys56e">POKEYS56e</a>) which supports
|
||||
up to 56 digital input, analog inputs, counter inputs and digital outputs.
|
||||
Each port/pin has to be configured before it can be used.
|
||||
|
||||
<br>
|
||||
<br>
|
||||
<a name="POKEYSdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> POKEYS <ip-address> <pin> <io-state> [<time in ms>]</code> <br>
|
||||
<br>
|
||||
<code><ip-address></code> the IP address where the POKEYS device can be accessed<br>
|
||||
<code><pin></code> the pin number which should be configured<br>
|
||||
<code><io-state></code> the new io state of the pin <code>Obsolete(=undef) DigIn DigOut AdcIn DigInCtRise DigInCtFall ExtDigOut GetBasic </code> <br>
|
||||
<code><time in ms></code> optional else 1000ms: cyclic update time for Input pin <br>
|
||||
|
||||
<br>
|
||||
Example:
|
||||
<ul>
|
||||
<code>define PoInfo POKEYS 192.168.178.34 0 GetBasic</code><br>
|
||||
# creates a virtual pin for getting infos about the device with the <code>get</code> command<br>
|
||||
<code>define Pin44in POKEYS 192.168.178.34 44 DigIn 200</code><br>
|
||||
# creates a digitial input port on pin 44<br>
|
||||
<code>define Pin25out POKEYS 192.168.178.34 25 DigOut</code><br>
|
||||
# creates a digial output port on pin 25<br>
|
||||
</ul>
|
||||
</ul> <br>
|
||||
|
||||
<a name="POKEYSset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
<code>set <name> <state> [<time in ms>]</code> <br>
|
||||
<br>
|
||||
<code><state></code> can be <code>OFF ON OFF_PULSE ON_PULSE </code><br>
|
||||
<code><time in ms></code> optional else 1000ms hold time for the <code>ON_PULSE OFF_PULSE</code> state<br>
|
||||
<br>
|
||||
Example:
|
||||
<ul>
|
||||
<code>set Pin25out ON</code><br>
|
||||
# sets Pin25out to ON (0V)<br>
|
||||
</ul>
|
||||
</ul><br>
|
||||
|
||||
<a name="POKEYSget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
<code>get <name> <type> </code> <br>
|
||||
<br>
|
||||
only supported for pins of type <code>GetBasic</code><br>
|
||||
<code><type></code> can be <code>Version DevName Serial User CPUload</code><br>
|
||||
<br>
|
||||
Example:
|
||||
<ul>
|
||||
<code>get PoInfo Version</code><br>
|
||||
# gets the version of the POKEYS device<br>
|
||||
</ul>
|
||||
</ul><br>
|
||||
|
||||
<a name="POKEYSattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
todo <br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -863,3 +863,205 @@ sub Calendar_Undef($$) {
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="Calendar"></a>
|
||||
<h3>Calendar</h3>
|
||||
<ul>
|
||||
<br>
|
||||
|
||||
<a name="Calendardefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> Calendar ical url <URL> [<interval>]</code><br>
|
||||
<br>
|
||||
Defines a calendar device.<br><br>
|
||||
|
||||
A calendar device periodically gathers calendar events from the source calendar at the given URL. The file at the given URL
|
||||
must be in ICal format.<br><br>
|
||||
|
||||
If the URL
|
||||
starts with <code>https://</code>, the perl module IO::Socket::SSL must be installed
|
||||
(use <code>cpan -i IO::Socket::SSL</code>).<br><br>
|
||||
|
||||
Note for users of Google Calendar: You can literally use the private ICal URL from your Google Calendar.
|
||||
Google App accounts do not work since requests to the URL
|
||||
get redirected first and the fhem mechanism for retrieving data via http/https cannot handle this. If your Google Calendar
|
||||
URL starts with <code>https://</code> and the perl module IO::Socket::SSL is not installed on your system, you can
|
||||
replace it by <code>http://</code>.<br><br>
|
||||
|
||||
The optional parameter <code>interval</code> is the time between subsequent updates
|
||||
in seconds. It defaults to 3600 (1 hour).<br><br>
|
||||
|
||||
Examples:
|
||||
<pre>
|
||||
define MyCalendar Calendar ical url https://www.google.com/calendar/ical/john.doe%40example.com/private-foo4711/basic.ics
|
||||
define YourCalendar Calendar ical url http://www.google.com/calendar/ical/jane.doe%40example.com/private-bar0815/basic.ics 86400
|
||||
</pre>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="Calendarset"></a>
|
||||
<b>Set </b>
|
||||
<ul>
|
||||
<code>set <name> update</code><br><br>
|
||||
|
||||
Forces the retrieval of the calendar from the URL. The next automatic retrieval is scheduled to occur
|
||||
<code>interval</code> seconds later.<br><br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
|
||||
<a name="Calendarget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
<code>get <name> full|text|summary|location|alarm|start|end <reading>|<uid></code><br><br>
|
||||
|
||||
Returns, line by line, the full state or a textual representation or the summary (subject, title) or the
|
||||
location or the alarm time or the start time or the end time
|
||||
of the calendar event(s) listed in the
|
||||
reading <reading> or identified by the UID <uid>.<br><br>
|
||||
|
||||
<code>get <name> find <regexp></code><br><br>
|
||||
|
||||
Returns, line by line, the UIDs of all calendar events whose summary matches the regular expression
|
||||
<regexp>.<br><br>
|
||||
|
||||
</ul>
|
||||
|
||||
<br>
|
||||
|
||||
<a name="Calendarattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#event-on-update-reading">event-on-update-reading</a></li>
|
||||
<li><a href="#event-on-change-reading">event-on-change-reading</a></li>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<b>Description</b>
|
||||
<ul>
|
||||
|
||||
A calendar is a set of calendar events. A calendar event has a summary (usually the title shown in a visual
|
||||
representation of the source calendar), a start time, an end time, and zero, one or more alarm times. The calendar events are
|
||||
fetched from the source calendar at the given URL. In case of multiple alarm times for a calendar event, only the
|
||||
earliest alarm time is kept. Recurring calendar events are currently not supported.<p>
|
||||
|
||||
A calendar event is identified by its UID. The UID is taken from the source calendar. All non-alphanumerical characters
|
||||
are stripped off the UID to make your life easier.<p>
|
||||
|
||||
A calendar event can be in one of the following states:
|
||||
<table border="1">
|
||||
<tr><td>new</td><td>The calendar event was first seen at the most recent update. Either this was your first retrieval of
|
||||
the calendar or you newly added the calendar event to the source calendar.</td></tr>
|
||||
<tr><td>known</td><td>The calendar event was already there before the most recent update.</td></tr>
|
||||
<tr><td>updated</td><td>The calendar event was already there before the most recent update but it has changed since it
|
||||
was last retrieved.</td></tr>
|
||||
<tr><td>deleted</td><td>The calendar event was there before the most recent update but is no longer. You removed it from the source calendar. The calendar event will be removed from all lists at the next update.</td></tr>
|
||||
</table><br>
|
||||
Calendar events that lie completely in the past (current time on wall clock is later than the calendar event's end time)
|
||||
are not retrieved and are thus not accessible through the calendar.
|
||||
<p>
|
||||
|
||||
A calendar event can be in one of the following modes:
|
||||
<table border="1">
|
||||
<tr><td>upcoming</td><td>Neither the alarm time nor the start time of the calendar event is reached.</td></tr>
|
||||
<tr><td>alarm</td><td>The alarm time has passed but the start time of the calendar event is not yet reached.</td></tr>
|
||||
<tr><td>start</td><td>The start time has passed but the end time of the calendar event is not yet reached.</td></tr>
|
||||
<tr><td>end</td><td>The end time of the calendar event has passed.</td></tr>
|
||||
</table><br>
|
||||
A calendar event transitions from one mode to another immediately when the time for the change has come. This is done by waiting
|
||||
for the earliest future time among all alarm, start or end times of all calendar events.
|
||||
<p>
|
||||
|
||||
A calendar device has several readings. Except for <code>calname</code>, each reading is a semicolon-separated list of UIDs of
|
||||
calendar events that satisfy certain conditions:
|
||||
<table border="1">
|
||||
<tr><td>calname</td><td>name of the calendar</td></tr>
|
||||
<tr><td>all</td><td>all events</td></tr>
|
||||
<tr><td>modeAlarm</td><td>events in alarm mode</td></tr>
|
||||
<tr><td>modeAlarmOrStart</td><td>events in alarm or start mode</td></tr>
|
||||
<tr><td>modeAlarmed</td><td>events that have just transitioned from upcoming to alarm mode</td></tr>
|
||||
<tr><td>modeChanged</td><td>events that have just changed their mode somehow</td></tr>
|
||||
<tr><td>modeEnd</td><td>events in end mode</td></tr>
|
||||
<tr><td>modeEnded</td><td>events that have just transitioned from start to end mode</td></tr>
|
||||
<tr><td>modeStart</td><td>events in start mode</td></tr>
|
||||
<tr><td>modeStarted</td><td>events that have just transitioned to start mode</td></tr>
|
||||
<tr><td>modeUpcoming</td><td>events in upcoming mode</td></tr>
|
||||
<tr><td>stateChanged</td><td>events that have just changed their state somehow</td></tr>
|
||||
<tr><td>stateDeleted</td><td>events in state deleted</td></tr>
|
||||
<tr><td>stateNew</td><td>events in state new</td></tr>
|
||||
<tr><td>stateUpdated</td><td>events in state updated</td></tr>
|
||||
</table>
|
||||
</ul>
|
||||
<p>
|
||||
|
||||
When a calendar event has changed, an event is created in the form
|
||||
<code>changed: UID mode</code> with mode being the current mode the calendar event is in after the change.
|
||||
|
||||
<p>
|
||||
|
||||
<b>Usage scenarios</b>
|
||||
<ul>
|
||||
<i>Show all calendar events with details</i><br><br>
|
||||
<ul>
|
||||
<code>
|
||||
get MyCalendar full all<br>
|
||||
2767324dsfretfvds7dsfn3e4dsa234r234sdfds6bh874googlecom known alarm 31.05.2012 17:00:00 07.06.2012 16:30:00-07.06.2012 18:00:00 Erna for coffee<br>
|
||||
992hydf4y44awer5466lhfdsrgl7tin6b6mckf8glmhui4googlecom known upcoming 08.06.2012 00:00:00-09.06.2012 00:00:00 Vacation
|
||||
</code><br><br>
|
||||
</ul>
|
||||
|
||||
<i>Show calendar events in your photo frame</i><br><br>
|
||||
<ul>
|
||||
Put a line in the <a href="#RSSlayout">layout description</a> to show calendar events in alarm or start mode:<br><br>
|
||||
<code>text 20 60 { fhem("get MyCalendar text modeAlarmOrStart") }</code><br><br>
|
||||
This may look like:<br><br>
|
||||
<code>
|
||||
07.06.12 16:30 Erna for coffee<br>
|
||||
08.06.12 00:00 Vacation
|
||||
</code><br><br>
|
||||
</ul>
|
||||
|
||||
<i>Switch the light on when Erna comes</i><br><br>
|
||||
<ul>
|
||||
First find the UID of the calendar event:<br><br>
|
||||
<code>
|
||||
get MyCalendar find .*Erna.*<br>
|
||||
2767324dsfretfvds7dsfn3e4dsa234r234sdfds6bh874googlecom
|
||||
</code><br><br>
|
||||
Then define a notify:<br><br>
|
||||
<code>
|
||||
define ErnaComes notify MyCalendar:modeStarted.*2767324dsfretfvds7dsfn3e4dsa234r234sdfds6bh874googlecom.* set MyLight on
|
||||
</code><br><br>
|
||||
You can also do some logging:<br><br>
|
||||
<code>
|
||||
define LogErna notify MyCalendar:modeAlarmed.*2767324dsfretfvds7dsfn3e4dsa234r234sdfds6bh874googlecom.* { Log 1, "ALARM name=%NAME event=%EVENT part1=%EVTPART0 part2=%EVTPART1" }
|
||||
</code><br><br>
|
||||
</ul>
|
||||
|
||||
<i>Switch actors on and off</i><br><br>
|
||||
<ul>
|
||||
Think about a calendar with calendar events whose summaries (subjects, titles) are the names of devices in your fhem installation.
|
||||
You want the respective devices to switch on when the calendar event starts and to switch off when the calendar event ends.<br><br>
|
||||
<code>
|
||||
define SwitchActorOn notify MyCalendar:modeStarted.* { my $uid= "%EVTPART1";; my $actor= fhem("get MyCalendar summary $uid");; fhem("set $actor on") }<br><br>
|
||||
define SwitchActorOff notify MyCalendar:modeEnded.* { my $uid= "%EVTPART1";; my $actor= fhem("get MyCalendar summary $uid");; fhem("set $actor off") }
|
||||
</code><br><br>
|
||||
You can also do some logging:<br><br>
|
||||
<code>
|
||||
define LogActors notify MyCalendar:mode(Started|Ended).* { my $reading= "%EVTPART0";; my $uid= "%EVTPART1";; my $actor= fhem("get MyCalendar summary $uid");; Log 1, "Actor: $actor, Reading $reading" }
|
||||
</code><br><br>
|
||||
</ul>
|
||||
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -439,3 +439,144 @@ HCS_getValves($$) {
|
||||
# vim: ts=2:et
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="HCS"></a>
|
||||
<h3>HCS</h3>
|
||||
<ul>
|
||||
Defines a virtual device for monitoring heating valves (FHT, HM-CC-VD) to control
|
||||
a central heating unit.<br><br>
|
||||
|
||||
<a name="HCSdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> HCE <device> <interval> <valveThresholdOn> <valveThresholdOff></code>
|
||||
<br><br>
|
||||
|
||||
<ul>
|
||||
<li><code><device></code> the name of a predefined device to switch.</li>
|
||||
<li><code><interval></code> is a digit number. The unit is minutes.</li>
|
||||
<li><code><valveThresholdOn></code> is a digit number. Threshold upon which device is switched on (heating required).</li>
|
||||
<li><code><valveThresholdOff></code> is a digit number. Threshold upon which device is switched off (idle).</li>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
The HCS (heating control system) device monitors the state of all detected
|
||||
valves in a free definable interval (by default: 10 min).
|
||||
<br><br>
|
||||
|
||||
Regulation for heating requirement or suppression of the request can be controlled by
|
||||
valve position using also free definable thresholds.
|
||||
<br><br>
|
||||
|
||||
In doing so, the HCS device also includes the hysteresis between two states.
|
||||
<br><br>
|
||||
|
||||
Example:<br>
|
||||
Threshold valve position for heating requirement: 40% (default)
|
||||
Threshold valve position for idle: 35% (default)
|
||||
<br><br>
|
||||
|
||||
Heating is required when the "open" position of a valve is more than 40%. HCS
|
||||
then activates the defined device until the "open" position of the valve has
|
||||
lowered to 35% or less (threshold for idle).
|
||||
<br><br>
|
||||
|
||||
In addition, the HCS device supports an optional temp-sensor. The valve-position oriented
|
||||
regulation can be overriden by the reading of the temp-sensor.
|
||||
<br><br>
|
||||
|
||||
Example:<br>
|
||||
Threshold temperature reading for heating requirement: 10° Celsius
|
||||
Threshold temperature reading for idle: 18° Celsius
|
||||
<br><br>
|
||||
|
||||
Is a valve reaching or exceeding the threshold for heating requirement (>=40%), but the
|
||||
temperature reading is more than 18° Celcius, the selected device will stay deactivated.
|
||||
The valve-position oriented regulation has been overridden by the temperature reading in this example.
|
||||
<br><br>
|
||||
|
||||
The HCS device automatically detects devices which are ignored. Furthermore, certain
|
||||
devices can also be excluded of the monitoring manually.
|
||||
<br><br>
|
||||
|
||||
<a name="HCSget"></a>
|
||||
<b>Get </b>
|
||||
<ul>
|
||||
<li>valves<br>
|
||||
returns the actual valve positions
|
||||
</li><br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="HCSset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
<li>interval<br>
|
||||
modifies the interval of reading the actual valve positions. The unit is minutes.
|
||||
</li><br>
|
||||
<li>on<br>
|
||||
restarts the monitoring after shutdown by <code>off</code> switch.<br>
|
||||
HCS device starts up automatically upon FHEM start or after new device implementation!
|
||||
</li><br>
|
||||
<li>off<br>
|
||||
shutdown of monitoring, can be restarted by using the <code>on</code> command.
|
||||
</li><br>
|
||||
<li>valveThresholdOn<br>
|
||||
defines threshold upon which device is switched on (heating required).
|
||||
</li><br>
|
||||
<li>valveThresholdOff<br>
|
||||
defines threshold upon which device is switched off (idle).
|
||||
</li><br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="HCSattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li>device<br>
|
||||
optional; used to change the device. This is normally done in the <code>define</code> tag.
|
||||
</li><br>
|
||||
<li>deviceCmdOn<br>
|
||||
command to activate the device, e.g. <code>on</code>.
|
||||
</li><br>
|
||||
<li>deviceCmdOff<br>
|
||||
command to deactivate the device, e.g. <code>off</code>.
|
||||
</li><br>
|
||||
<li>sensor<br>
|
||||
device name of the temp-sensor (optional).
|
||||
</li><br>
|
||||
<li>sensorThresholdOn<br>
|
||||
threshold for temperature reading activating the defined device
|
||||
Must be set if <code>sensor</code> has been defined
|
||||
</li><br>
|
||||
<li>sensorThresholdOff<br>
|
||||
threshold for temperature reading deactivating the defined device.
|
||||
Must be set if <code>sensor</code> has been defined
|
||||
</li><br>
|
||||
<li>sensorReading<br>
|
||||
name which is used for saving the "reading" of the defined temp-sensor.
|
||||
</li><br>
|
||||
<li>valvesExcluded<br>
|
||||
space separated list of devices (FHT or HM-CC-TC) for excluding
|
||||
<li>valveThresholdOn<br>
|
||||
see Set
|
||||
</li><br>
|
||||
<li>valveThresholdOff<br>
|
||||
</li>see Set<br>
|
||||
<li><a href="#do_not_notify">do_not_notify</a></li><br>
|
||||
<li><a href="#showtime">showtime</a></li><br>
|
||||
<li><a href="#event-on-update-reading">event-on-update-reading</a></li><br>
|
||||
<li><a href="#event-on-change-reading">event-on-change-reading</a></li><br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -317,3 +317,88 @@ Twilight_getWeatherHorizon($)
|
||||
}
|
||||
1;
|
||||
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="Twilight"></a>
|
||||
<h3>Twilight</h3>
|
||||
<ul>
|
||||
<br>
|
||||
|
||||
<a name="Twilightdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> Twilight <latitude> <longitude> [<indoor_horizon> [<Weather_Position>]]</code><br>
|
||||
<br>
|
||||
Defines a virtual device for Twilight calculations <br><br>
|
||||
|
||||
A Twilight device periodically calculates the times of different twilight phases throughout the day.
|
||||
It calculates a virtual "light" element, that gives an indicator about the amount of the current daylight.
|
||||
Besides the location on earth it is influenced by a so called "indoor horizon" (e.g. if there are high buildings, mountains) as well as by weather conditions. Very bad weather conditions lead to a reduced daylight for nearly the whole day.
|
||||
The light calculated spans between 0 and 6, where the values mean the following:<br><br>
|
||||
<code>0 - total night, sun is at least -18 degree below horizon</code><br>
|
||||
<code>1 - astronomical twilight, sun is between -12 and -18 degree below horizon</code><br>
|
||||
<code>2 - nautical twilight, sun is between -6 and -12 degree below horizon</code><br>
|
||||
<code>3 - civil twilight, sun is between 0 and -6 degree below horizon</code><br>
|
||||
<code>4 - indoor twilight, sun is between the indoor_horizon and 0 degree below horizon (not used if indoor_horizon=0)</code><br>
|
||||
<code>5 - weather twilight, sun is between indoor_horizon and a virtual weather horizon (the weather horizon depends on weather conditions (optional)</code><br>
|
||||
<code>6 - maximum daylight</code><br>
|
||||
<br>
|
||||
|
||||
The parameters <code>latitude</code> and <code>longitude</code> are decimal numbers which give the position on earth for which the twilight states shall be calculated.<br>
|
||||
The parameter indoor_horizon gives a virtual horizon higher than 0, that shall be used for calculation of indoor twilight (typical values are between 0 and 6)<br>
|
||||
The parameter Weather_Position is the yahoo weather id used for getting the weather condition. Go to http://weather.yahoo.com/ and enter a city or zip code. In the upcoming webpage, the id is a the end of the URL. Example: Munich, Germany -> 676757<br>
|
||||
|
||||
Example:
|
||||
<pre>
|
||||
define myTwilight Twilight 49.962529 10.324845 3 676757
|
||||
</pre>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="Twilightset"></a>
|
||||
<b>Set </b>
|
||||
<ul>
|
||||
N/A
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
|
||||
<a name="Twilightget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
|
||||
<code>get <name> <reading></code><br><br>
|
||||
<table>
|
||||
<tr><td>light</td><td>the current virtual daylight value</td></tr>
|
||||
<tr><td>nextEvent</td><td>the name of the next event</td></tr>
|
||||
<tr><td>nextEventTime</td><td>the time when the next event will probably happen (durint light phase 5 and 6 this is updated when weather conditions change</td></tr>
|
||||
<tr><td>sr_astro</td><td>time of astronomical sunrise</td></tr>
|
||||
<tr><td>sr_naut</td><td>time of nautical sunrise</td></tr>
|
||||
<tr><td>sr_civil</td><td>time of civil sunrise</td></tr>
|
||||
<tr><td>sr</td><td>time of sunrise</td></tr>
|
||||
<tr><td>sr_indoor</td><td>time of indoor sunrise</td></tr>
|
||||
<tr><td>sr_weather</td><td>time of weather sunrise</td></tr>
|
||||
<tr><td>ss_weather</td><td>time of weather sunset</td></tr>
|
||||
<tr><td>ss_indoor</td><td>time of indoor sunset</td></tr>
|
||||
<tr><td>ss</td><td>time of sunset</td></tr>
|
||||
<tr><td>ss_civil</td><td>time of civil sunset</td></tr>
|
||||
<tr><td>ss_nautic</td><td>time of nautic sunset</td></tr>
|
||||
<tr><td>ss_astro</td><td>time of astro sunset</td></tr>
|
||||
</table>
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="Twilightattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#event-on-update-reading">event-on-update-reading</a></li>
|
||||
<li><a href="#event-on-change-reading">event-on-change-reading</a></li>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -488,3 +488,103 @@ WeatherAsHtml($)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="Weather"></a>
|
||||
<h3>Weather</h3>
|
||||
<ul>
|
||||
<br>
|
||||
|
||||
<a name="Weatherdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> Weather <location> [<interval> [<language>]]</code><br>
|
||||
<br>
|
||||
Defines a virtual device for weather forecasts.<br><br>
|
||||
|
||||
A Weather device periodically gathers current and forecast weather conditions
|
||||
from the Yahoo Weather API.<br><br>
|
||||
|
||||
The parameter <code>location</code> is the WOEID (WHERE-ON-EARTH-ID), go to
|
||||
<a href="http://weather.yahoo.com">http://weather.yahoo.com</a> to find it out for your location.<br><br>
|
||||
|
||||
The optional parameter <code>interval</code> is the time between subsequent updates
|
||||
in seconds. It defaults to 3600 (1 hour).<br><br>
|
||||
|
||||
The optional language parameter may be one of
|
||||
<code>de</code>,
|
||||
<code>en</code>,
|
||||
<code>nl</code>,
|
||||
|
||||
It determines the natural language in which the forecast information appears.
|
||||
It defaults to <code>en</code>. If you want to set the language you also have to set the interval.<br><br>
|
||||
|
||||
Examples:
|
||||
<pre>
|
||||
define MyWeather Weather 673513
|
||||
define Forecast Weather 673513 1800
|
||||
</pre>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="Weatherset"></a>
|
||||
<b>Set </b>
|
||||
<ul>
|
||||
<code>set <name> update</code><br><br>
|
||||
|
||||
Forces the retrieval of the weather data. The next automatic retrieval is scheduled to occur
|
||||
<code>interval</code> seconds later.<br><br>
|
||||
</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 1, 2 and stands
|
||||
for today, tomorrow):<br>
|
||||
<table>
|
||||
<tr><td>city</td><td>name of town returned for location</td></tr>
|
||||
<tr><td>code</td><td>current condition code</td></tr>
|
||||
<tr><td>condition</td><td>current condition</td></tr>
|
||||
<tr><td>current_date_time</td><td>last update of forecast on server</td></tr>
|
||||
<tr><td>fc?_code</td><td>forecast condition code</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>forecast icon</td></tr>
|
||||
<tr><td>fc?_low_c</td><td>forecasted daily low in degrees centigrade</td></tr>
|
||||
<tr><td>humidity</td><td>current humidity in %</td></tr>
|
||||
<tr><td>icon</td><td>relative path for current icon</td></tr>
|
||||
<tr><td>pressure</td><td>air pressure in hPa</td></tr>
|
||||
<tr><td>pressure_trend</td><td>air pressure trend (0= steady, 1= rising, 2= falling)</td></tr>
|
||||
<tr><td>pressure_trend_txt</td><td>textual representation of air pressure trend</td></tr>
|
||||
<tr><td>pressure_trend_sym</td><td>symbolic representation of air pressure trend</td></tr>
|
||||
<tr><td>temperature</td><td>current temperature in degrees centigrade</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>visibility</td><td>visibility in km</td></tr>
|
||||
<tr><td>wind</td><td>wind speed in km/h</td></tr>
|
||||
<tr><td>wind_chill</td><td>wind chill in degrees centigrade</td></tr>
|
||||
<tr><td>wind_condition</td><td>wind direction and speed</td></tr>
|
||||
<tr><td>wind_direction</td><td>direction wind comes from in degrees (0 = north wind)</td></tr>
|
||||
<tr><td>wind_speed</td><td>same as wind</td></tr>
|
||||
</table>
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="Weatherattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#event-on-update-reading">event-on-update-reading</a></li>
|
||||
<li><a href="#event-on-change-reading">event-on-change-reading</a></li>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -423,3 +423,63 @@ EmGetDevData($)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -183,3 +183,74 @@ EMWZ_Define($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -137,3 +137,57 @@ EMEM_Define($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -170,3 +170,63 @@ EMGZ_Define($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -281,3 +281,48 @@ ESA2000_Parse($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="ESA2000"></a>
|
||||
<h3>ESA2000</h3>
|
||||
<ul>
|
||||
The ESA2000 module interprets ESA2000 type of messages received by the CUL,
|
||||
currently only for ESA2000 LED devices.
|
||||
<br><br>
|
||||
|
||||
<a name="ESA2000define"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> ESA2000 <code>
|
||||
[base1 base2]</code> <br>
|
||||
<br>
|
||||
<code> is the 4 digit HEX code identifying the devices.<br><br>
|
||||
|
||||
<b>base1/2</b> is added to the total kwh as a base (Hoch- und Niedertarifzählerstand).
|
||||
</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> (ESA2000_LED)</li><br>
|
||||
<li><a href="#IODev">IODev</a></li><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -631,3 +631,190 @@ ECMD_Write($$)
|
||||
#####################################
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="ECMD"></a>
|
||||
<h3>ECMD</h3>
|
||||
<ul>
|
||||
Any physical device with request/response-like communication capabilities
|
||||
over a TCP connection can be defined as ECMD device. A practical example
|
||||
of such a device is the AVR microcontroller board AVR-NET-IO from
|
||||
<a href="http://www.pollin.de">Pollin</a> with
|
||||
<a href="http://www.ethersex.de/index.php/ECMD">ECMD</a>-enabled
|
||||
<a href="http://www.ethersex.de">Ethersex</a> firmware.<p>
|
||||
|
||||
A physical ECMD device can host any number of logical ECMD devices. Logical
|
||||
devices are defined as <a href="#ECMDDevice">ECMDDevice</a>s in fhem.
|
||||
ADC 0 to 3 and I/O port 0 to 3 of the above mentioned board
|
||||
are examples of such logical devices. ADC 0 to 3 all belong to the same
|
||||
device class ADC (analog/digital converter). I/O port 0 to 3 belong to the device
|
||||
class I/O port. By means of extension boards you can make your physical
|
||||
device drive as many logical devices as you can imagine, e.g. IR receivers,
|
||||
LC displays, RF receivers/transmitters, 1-wire devices, etc.<p>
|
||||
|
||||
Defining one fhem module for any device class would create an unmanageable
|
||||
number of modules. Thus, an abstraction layer is used. You create a device class
|
||||
on the fly and assign it to a logical ECMD device. The
|
||||
<a href="#ECMDClassdef">class definition</a>
|
||||
names the parameters of the logical device, e.g. a placeholder for the number
|
||||
of the ADC or port, as well as the get and set capabilities. Worked examples
|
||||
are to be found in the documentation of the <a href="#ECMDDevice">ECMDDevice</a> device.
|
||||
<br><br>
|
||||
|
||||
Note: this module requires the Device::SerialPort or Win32::SerialPort module
|
||||
if the module is connected via serial Port or USB.
|
||||
<br><br>
|
||||
|
||||
<a name="ECMDdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> ECMD telnet <IPAddress:Port></code><br><br>
|
||||
or<br><br>
|
||||
<code>define <name> ECMD serial <SerialDevice>[<@BaudRate>]</code>
|
||||
<br><br>
|
||||
|
||||
Defines a physical ECMD device. The keywords <code>telnet</code> or
|
||||
<code>serial</code> are fixed.<br><br>
|
||||
|
||||
Examples:
|
||||
<ul>
|
||||
<code>define AVRNETIO ECMD telnet 192.168.0.91:2701</code><br>
|
||||
<code>define AVRNETIO ECMD serial /dev/ttyS0</code><br>
|
||||
<code>define AVRNETIO ECMD serial /sev/ttyUSB0@38400</code><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
<a name="ECMDset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
<code>set <name> classdef <classname> <filename></code>
|
||||
<br><br>
|
||||
Creates a new device class <code><classname></code> for logical devices.
|
||||
The class definition is in the file <code><filename></code>. You must
|
||||
create the device class before you create a logical device that adheres to
|
||||
that definition.
|
||||
<br><br>
|
||||
Example:
|
||||
<ul>
|
||||
<code>define AVRNETIO classdef /etc/fhem/ADC.classdef</code><br>
|
||||
</ul>
|
||||
<br>
|
||||
<code>set <name> reopen</code>
|
||||
<br><br>
|
||||
Closes and reopens the device. Could be handy if connection is lost and cannot be
|
||||
reestablished automatically.
|
||||
<br><br>
|
||||
</ul>
|
||||
|
||||
|
||||
<a name="ECMDget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
<code>get <name> raw <command></code>
|
||||
<br><br>
|
||||
Sends the command <code><command></code> to the physical ECMD device
|
||||
<code><name></code> and reads the response.
|
||||
</ul>
|
||||
<br><br>
|
||||
|
||||
<a name="ECMDattr"></a>
|
||||
<b>Attributes</b>
|
||||
<br><br>
|
||||
<ul>
|
||||
<li>classdefs<br>A colon-separated list of <classname>=<filename>.
|
||||
The list is automatically updated if a class definition is added. You can
|
||||
directly set the attribute.</li>
|
||||
</ul>
|
||||
<br><br>
|
||||
|
||||
|
||||
<a name="ECMDClassdef"></a>
|
||||
<b>Class definition</b>
|
||||
<br><br>
|
||||
<ul>
|
||||
|
||||
The class definition for a logical ECMD device class is contained in a text file.
|
||||
The text file is made up of single lines. Empty lines and text beginning with #
|
||||
(hash) are ignored. Therefore make sure not to use hashes in commands.<br>
|
||||
|
||||
The following commands are recognized in the device class definition:<br><br>
|
||||
<ul>
|
||||
<li><code>params <parameter1> [<parameter2> [<parameter3> ... ]]</code><br><br>
|
||||
Declares the names of the named parameters that must be present in the
|
||||
<a href="#ECMDDevicedefine">definition of the logical ECMD device</a>.
|
||||
<br><br>
|
||||
</li>
|
||||
|
||||
<li><code>set <commandname> cmd { <a href="#perl"><perl special></a> }</code>
|
||||
<br><br>
|
||||
Declares a new set command <code><commandname></code>.
|
||||
<br><br>
|
||||
</li>
|
||||
|
||||
<li><code>get <commandname> cmd { <a href="#perl"><perl special></a> }</code>
|
||||
<br><br>
|
||||
Declares a new get command <code><commandname></code>.
|
||||
<br><br>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<code>set <commandname> postproc { <perl command> }</code><br>
|
||||
<code>get <commandname> postproc { <perl command> }</code>
|
||||
<br><br>
|
||||
Declares a postprocessor for the command <code><commandname></code>.
|
||||
<br><br>
|
||||
</li>
|
||||
|
||||
|
||||
<li>
|
||||
<code>set <commandname> params <parameter1> [<parameter2> [<parameter3> ... ]]</code><br>
|
||||
<code>get <commandname> params <parameter1> [<parameter2> [<parameter3> ... ]]</code>
|
||||
<br><br>
|
||||
Declares the names of the named parameters that must be present in the
|
||||
set or get command <code><commandname></code></a>. Be careful not to use a parameter name that
|
||||
is already used in the device definition (see <code>params</code> above).
|
||||
<br><br>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
The perl specials in the definitions of the set and get commands can
|
||||
contain macros. Apart from the rules outlined in the <a
|
||||
href="#perl">documentation of perl specials</a> in fhem, the following
|
||||
rules apply:<br><br>
|
||||
<ul>
|
||||
<li>The character @ will be replaced with the device
|
||||
name. To use @ in the text itself, use the double mode (@@).</li>
|
||||
|
||||
<li>The macro <code>%NAME</code> will expand to the device name (same
|
||||
as <code>@</code>).</li>
|
||||
|
||||
<li>The macro <code>%<parameter></code> will expand to the
|
||||
current value of the named parameter. This can be either a parameter
|
||||
from the device definition or a parameter from the set or get
|
||||
command.</li>
|
||||
|
||||
<li>The macro substitution occurs before perl evaluates the
|
||||
expression. It is a plain text substitution.</li>
|
||||
|
||||
<li>If in doubt what happens, run the commands with loglevel 5 and
|
||||
observe the log file.</li>
|
||||
</ul><br><br>
|
||||
|
||||
<!--Neither apply the rules outlined in the <a href="#perl">documentation of perl specials</a>
|
||||
for the <code><perl command></code> in the postprocessor definitions nor can it contain macros.
|
||||
This is to avoid undesired side effects from e.g. doubling of semicolons.<br><br>-->
|
||||
The rules outlined in the <a href="#perl">documentation of perl specials</a>
|
||||
for the <code><perl command></code> in the postprocessor definitions apply.
|
||||
<b>Note:</b> Beware of undesired side effects from e.g. doubling of semicolon!
|
||||
|
||||
The <code>perl command</code> acts on <code>$_</code>. The result of the perl command is the
|
||||
final result of the get or set command.
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -259,3 +259,150 @@ ECMDDevice_Define($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="ECMDDevice"></a>
|
||||
<h3>ECMDDevice</h3>
|
||||
<ul>
|
||||
<br>
|
||||
<a name="ECMDDevicedefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> ECMDDevice <classname> [<parameter1> [<parameter2> [<parameter3> ... ]]]</code>
|
||||
<br><br>
|
||||
|
||||
Defines a logical ECMD device. The number of given parameters must match those given in
|
||||
the <a href="#ECMDClassdef">class definition</a> of the device class <code><classname></code>.
|
||||
<br><br>
|
||||
|
||||
Examples:
|
||||
<ul>
|
||||
<code>define myADC ECMDDevice ADC</code><br>
|
||||
<code>define myRelais1 ECMDDevice relais 8</code><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
<a name="ECMDDeviceset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
<code>set <name> <commandname> [<parameter1> [<parameter2> [<parameter3> ... ]]]</code>
|
||||
<br><br>
|
||||
The number of given parameters must match those given for the set command <code><commandname></code> definition in
|
||||
the <a href="#ECMDClassdef">class definition</a>.<br><br>
|
||||
If <code>set <commandname></code> is invoked the perl special in curly brackets from the command definition
|
||||
is evaluated and the result is sent to the physical ECMD device.
|
||||
<br><br>
|
||||
Example:
|
||||
<ul>
|
||||
<code>set myRelais1 on</code><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
|
||||
<a name="ECMDDeviceget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
<code>get <name> <commandname> [<parameter1> [<parameter2> [<parameter3> ... ]]]</code>
|
||||
<br><br>
|
||||
The number of given parameters must match those given for the get command <code><commandname></code> definition in
|
||||
the <a href="#ECMDClassdef">class definition</a>.<br><br>
|
||||
If <code>get <commandname></code> is invoked the perl special in curly brackets from the command definition
|
||||
is evaluated and the result is sent to the physical ECMD device. The response from the physical ECMD device is returned
|
||||
and the state of the logical ECMD device is updated accordingly.
|
||||
<br><br>
|
||||
Example:
|
||||
<ul>
|
||||
<code>get myADC value 3</code><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
|
||||
<a name="ECMDDeviceattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
<li><a href="#eventMap">eventMap</a></li>
|
||||
<li><a href="#event-on-update-reading">event-on-update-reading</a></li>
|
||||
<li><a href="#event-on-change-reading">event-on-change-reading</a></li>
|
||||
</ul>
|
||||
<br><br>
|
||||
|
||||
|
||||
<b>Example 1</b>
|
||||
<br><br>
|
||||
<ul>
|
||||
The following example shows how to access the ADC of the AVR-NET-IO board from
|
||||
<a href="http://www.pollin.de">Pollin</a> with
|
||||
<a href="http://www.ethersex.de/index.php/ECMD">ECMD</a>-enabled
|
||||
<a href="http://www.ethersex.de">Ethersex</a> firmware.<br><br>
|
||||
|
||||
The class definition file <code>/etc/fhem/ADC.classdef</code> looks as follows:<br><br>
|
||||
<code>
|
||||
get value cmd {"adc get %channel"} <br>
|
||||
get value params channel<br>
|
||||
</code>
|
||||
<br>
|
||||
In the fhem configuration file or on the fhem command line we do the following:<br><br>
|
||||
<code>
|
||||
define AVRNETIO ECMD telnet 192.168.0.91:2701 # define the physical device<br>
|
||||
set AVRNETIO classdef ADC /etc/fhem/ADC.classdef # define the device class ADC<br>
|
||||
define myADC ECDMDevice ADC # define the logical device myADC with device class ADC<br>
|
||||
get myADC value 1 # retrieve the value of analog/digital converter number 1<br>
|
||||
</code>
|
||||
<br>
|
||||
The get command is evaluated as follows: <code>get value</code> has one named parameter
|
||||
<code>channel</code>. In the example the literal <code>1</code> is given and thus <code>%channel</code>
|
||||
is replaced by <code>1</code> to yield <code>"adc get 1"</code> after macro substitution. Perl
|
||||
evaluates this to a literal string which is send as a plain ethersex command to the AVR-NET-IO. The
|
||||
board returns something like <code>024</code> for the current value of analog/digital converter number 1.
|
||||
<br><br>
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
<b>Example 2</b>
|
||||
<br><br>
|
||||
<ul>
|
||||
The following example shows how to switch a relais driven by pin 3 (bit mask 0x08) of I/O port 2 on for
|
||||
one second and then off again.<br><br>
|
||||
|
||||
The class definition file <code>/etc/fhem/relais.classdef</code> looks as follows:<br><br>
|
||||
<code>
|
||||
params pinmask<br>
|
||||
set on cmd {"io set ddr 2 ff\nioset port 2 0%pinmask\nwait 1000\nio set port 2 00"}<br>
|
||||
set on postproc {s/^OK\nOK\nOK\nOK$/success/; "$_" eq "success" ? "ok" : "error"; }<br>
|
||||
</code>
|
||||
<br>
|
||||
In the fhem configuration file or on the fhem command line we do the following:<br><br>
|
||||
<code>
|
||||
define AVRNETIO ECMD telnet 192.168.0.91:2701 # define the physical device<br>
|
||||
set AVRNETIO classdef relais /etc/fhem/relais.classdef # define the device class relais<br>
|
||||
define myRelais ECMDDevice 8 # define the logical device myRelais with pin mask 8<br>
|
||||
set myRelais on # execute the "on" command<br>
|
||||
</code>
|
||||
<br>
|
||||
The set command is evaluated as follows: <code>%pinmask</code>
|
||||
is replaced by <code>8</code> to yield
|
||||
<code>"io set ddr 2 ff\nioset port 2 08\nwait 1000\nio set port 2 00"</code> after macro substitution. Perl
|
||||
evaluates this to a literal string which is send as a plain ethersex command to the AVR-NET-IO line by line.
|
||||
<br>
|
||||
For any of the four plain ethersex commands, the AVR-NET-IO returns the string <code>OK</code>. They are
|
||||
concatenated and separated by line breaks (\n). The postprocessor takes the result from <code>$_</code>,
|
||||
substitutes it by the string <code>success</code> if it is <code>OK\nOK\nOK\nOK</code>, and then either
|
||||
returns the string <code>ok</code> or the string <code>error</code>.
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -272,3 +272,59 @@ DONE:
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -525,3 +525,119 @@ sub nonblockGetLinesSISPM {
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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;"> -->
|
||||
<div>
|
||||
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 Fritz!Box
|
||||
72xx and 73xx should be fine.)
|
||||
|
||||
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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -335,3 +335,51 @@ energy_Undef($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="SML"></a>
|
||||
|
||||
<h3>SML</h3>
|
||||
<ul><p>
|
||||
This module supports "Intelligenter Strom Zhler"(ENBW) and "Sparzhler" (Yellow Strom).<br>
|
||||
The electricity meter will be polled in a defined interval for new values.
|
||||
</p>
|
||||
<b>Define</b><br>
|
||||
<code>define <name> SML <host> <port> [<interval> <timeout>]</code><br>
|
||||
<p>
|
||||
Example:<br>
|
||||
define StromZ1 SML 192.168.178.20 <br>
|
||||
define StromZ2 SML 192.168.10.25 300 60 <br>
|
||||
</p>
|
||||
|
||||
<b>Set</b><br>
|
||||
set <name> <value> <nummber><br>where value is one of:<br><br>
|
||||
<ul>
|
||||
<li><code>TOTALPOWER</code> </li>
|
||||
<li><code>YEARPOWER </code> </li>
|
||||
<li><code>MONTHPOWER</code> </li>
|
||||
<li><code>DAYPOWER </code> </li>
|
||||
<li><code>Interval </code> </li>
|
||||
</ul>
|
||||
<br>Example:<br>
|
||||
set <name> TOTALPOWER 12345 <br><br>
|
||||
|
||||
<b>Get</b><br>
|
||||
get <name> <value> <br>where value is one of:<br>
|
||||
<ul>
|
||||
<li><code>TOTALPOWER</code></li>
|
||||
<li><code>YEARPOWER </code></li>
|
||||
<li><code>MONTHPOWER</code></li>
|
||||
<li><code>DAYPOWER </code></li>
|
||||
<li><code>Interval </code> </li>
|
||||
</ul>
|
||||
<br>Example:<br>
|
||||
get <name> DAYPOWER<br>
|
||||
get <name> YEARPOWER<br><br>
|
||||
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -346,3 +346,39 @@ if ( $kind ne 0 ){
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="STV"></a>
|
||||
|
||||
<h3>STV</h3>
|
||||
<ul><p>
|
||||
This module supports Samsung TV devices with few commands. It's developed and tested with Samsung LE39B650.<br>
|
||||
</p>
|
||||
<b>Define</b><br>
|
||||
<code>define <name> STV <host>]</code><br>
|
||||
<p>
|
||||
Example:<br>
|
||||
define Television1 STV 192.168.178.20 <br>
|
||||
</p>
|
||||
<b>Set</b><br>
|
||||
set <name> <value> <nummber><br>where value is one of:<br><br>
|
||||
<ul>
|
||||
<li><code>mute</code> </li>
|
||||
<li><code>volume </code> </li>
|
||||
<li><code>call</code> </li>
|
||||
<li><code>sms </code> </li>
|
||||
<li><code>date </code> </li>
|
||||
</ul>
|
||||
<br>Example:<br>
|
||||
set <name> mute <br>
|
||||
set <name> volume 20 <br>
|
||||
set <name> call Peter 012345678 Phone 87654321 <br><br>
|
||||
|
||||
<b>Get</b><br>
|
||||
<ul>N/A</ul><br>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -331,3 +331,72 @@ sub nonblockGetLinesTellStick {
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="TellStick"></a>
|
||||
<h3>TellStick</h3>
|
||||
<ul>
|
||||
<br>
|
||||
|
||||
<a name="TellStickdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> TellStick </path/to/tdtool></code>
|
||||
<br><br>
|
||||
|
||||
<!--<div style="background-color: #ffaaaa;"> -->
|
||||
<div>
|
||||
Defines a path to the program "tdtool", which is used to control a (locally attached)
|
||||
"Telldus TellStick [Duo]" USB device. A TellStick controls a wide range of 433 MHz
|
||||
devices, like the widely available switchable power outlets from InterTechno.<br><br>
|
||||
To keep things simple, FHEM interfaces with the telldus-core suite (available
|
||||
for Linux, Windows, Mac OSX) via the supplied tool, "tdtool". This FHEM module
|
||||
will initially use "tdtool --list" to receive a list of configured devices, then let
|
||||
autocreate (if enabled) create them as <a href="#SIS_PMS">SIS_PMS</a> devices.<br></br>
|
||||
<i>Please make sure</i> that the user running FHEM under ("fhem" in a standard setup on
|
||||
Linux) has the <i>r/w-right to access the stick's device</i> ("/dev/tellstick"
|
||||
in telldus-core version 2.0) — if the state of your devices do not change when
|
||||
modified im FHEM, access rights problems are the most probable cause
|
||||
(<code>chmod o+rw /dev/tellstick</code> should fix that; you may want to automate it
|
||||
via udev or adding the fhem user to the proper group ;))<br></br>
|
||||
This module has only been tested with the 2.0 branch of teldus-core because of a known bug
|
||||
in 2.1, <a href="http://www.telldus.com/forum/viewtopic.php?f=15&t=1645"> preventing
|
||||
version 2.1 working properly with some TellSticks</a> and/or "tdtool" application; FTR, the
|
||||
"Batch: 8" version a was granted usage of for writing this module was impacted by it ...
|
||||
|
||||
To actually control any power sockets, you need to define a <a href="#SIS_PMS">SIS_PMS</a>
|
||||
device — TellStick.pm uses SIS_PMS devices ("socket" is te:ll:st:ck:01, "socketnr"
|
||||
is the ID of the device in "tdtool"), as as of now only on/off switching is supported and
|
||||
this was the easiest implementation path. SIS_PMS is supported by <a href="http://sites.google.com/site/andfhem/">andFHEM</a>, the Android
|
||||
frontend, so this make some sense. (Furthermore, I don't own dimmable devices and they are
|
||||
actually not really cheap; >15 EUR/socket compared to the 15 EUR for 5 switch-only, non-self
|
||||
learning socket adapters from Intertechno at your local home improvement store.)
|
||||
<br><br>
|
||||
|
||||
Example:
|
||||
<ul>
|
||||
<code>define TStick TellStick /usr/bin/tdtool</code><br>
|
||||
<code>define Deckenfluter SIS_PMS te:ll:st:ck:01 2</code><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
<a name="TellStickset"></a>
|
||||
<b>Set</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="TellStickget"></a>
|
||||
<b>Get</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="TellStickattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li>none <!--<a href="#model">model</a> (TellStick)--></li>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -643,3 +643,65 @@ USBWX_Disconnected($)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="USBWX"></a>
|
||||
<h3>USBWX</h3>
|
||||
<ul>
|
||||
The USBWX module interprets the messages received by the ELV <a
|
||||
href="http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=29870">USB-WDE1</a>
|
||||
weather receiver. This receiver is compaptible with the following ELV sensors:
|
||||
KS200/KS300, S300IA, S300TH, ASH2200, PS50. It also known to work with Conrad
|
||||
weather sensors KS555, S555TH and ASH555.<br> This module was tested with ELV
|
||||
S300TH, ELV ASH2200, ELV KS300, Conrad S555TH and Conrad KS555. <br> Readings
|
||||
and STATE of temperature/humidity sensors are compatible with the CUL_WS
|
||||
module. For KS300/KS555 sensors STATE is compatible with the KS300 module. The
|
||||
module is integrated into autocreate to generate the appropriate filelogs and
|
||||
weblinks automatically.
|
||||
<br><br>
|
||||
Note: this module requires the Device::SerialPort or Win32::SerialPort module
|
||||
if the devices is connected via USB or a serial port.
|
||||
<br><br>
|
||||
|
||||
<a name="USBWXdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> USBWX <serial device></code>
|
||||
<br>
|
||||
<br>Defines USB-WDE1 attached via usb.<br>
|
||||
<br>
|
||||
<code>define <name> USBWX <code> [corr1...corr4]</code> <br>
|
||||
<br>
|
||||
<code> is the code which must be set on the sensor. Valid values
|
||||
are 1 through 8. <br> 9 is used as the sensor id of the ks300 sensor.<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.
|
||||
<br>
|
||||
<br>
|
||||
Example:<pre>
|
||||
define USBWDE1 USBWX /dev/ttyUSB0
|
||||
define USBWX_1 USBWX 1
|
||||
define USBWX_livingroom USBWX 2
|
||||
define USBWX_ks300 USBWX 9
|
||||
</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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -443,3 +443,170 @@ sub nonblockGetLines {
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -411,3 +411,105 @@ sub getCommandParam($$)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="YAMAHA_AVR"></a>
|
||||
<h3>YAMAHA_AVR</h3>
|
||||
<ul>
|
||||
|
||||
<a name="YAMAHA_AVRdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> YAMAHA_AVR <ip-address> [<status_interval>]</code>
|
||||
<br><br>
|
||||
|
||||
This module controls AV receiver from Yamaha via network connection. You are able
|
||||
to power your AV reveiver on and off, query it's power state,
|
||||
select the input (HDMI, AV, AirPlay, internet radio, Tuner, ...), select the volume
|
||||
or mute/unmute the volume.<br><br>
|
||||
Defining a YAMAHA_AVR device will schedule an internal task (interval can be set
|
||||
with optional parameter <status_interval> in seconds, if not set, the value is 60 seconds), which periodically reads
|
||||
the status of the AV receiver (power state, selected input, volume and mute status)
|
||||
and triggers notify/filelog commands.<br><br>
|
||||
|
||||
Example:
|
||||
<ul>
|
||||
<code>define AV_Receiver YAMAHA_AVR 192.168.0.10</code><br>
|
||||
</ul>
|
||||
<a name="YAMAHA_AVRset"></a>
|
||||
<b>Set </b>
|
||||
<ul>
|
||||
<code>set <name> <command> [<parameter>]</code>
|
||||
<br><br>
|
||||
Currently, the following commands are defined; the available inputs are depending on the used receiver.
|
||||
The module only offers the real available inputs. The following input commands are just an example and can differ.
|
||||
|
||||
<pre>on
|
||||
off
|
||||
input hdmi1
|
||||
input hdmi2
|
||||
input hdmi3
|
||||
input hdmi4
|
||||
input av1
|
||||
input av2
|
||||
input av3
|
||||
input av3
|
||||
input av4
|
||||
input av5
|
||||
input av6
|
||||
input usb
|
||||
input airplay
|
||||
input tuner
|
||||
input v-aux
|
||||
input audio
|
||||
input server
|
||||
volume -80..16 (volume between -80 and +16 dB)
|
||||
mute on
|
||||
mute off</pre>
|
||||
</ul>
|
||||
|
||||
<a name="YAMAHA_AVRget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
<code>get <name> <what></code>
|
||||
<br><br>
|
||||
Currently, the following commands are defined and return the current state of the receiver.
|
||||
<pre>power
|
||||
input
|
||||
mute
|
||||
volume</pre>
|
||||
</ul>
|
||||
<a name="YAMAHA_AVRattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
<li><a href="#event-on-update-reading">event-on-update-reading</a></li>
|
||||
<li><a href="#event-on-change-reading">event-on-change-reading</a></li><br>
|
||||
<li><a name="volume-smooth-change">volume-smooth-change</a></li>
|
||||
Optional attribute to activate a smooth volume change.
|
||||
<br><br>
|
||||
Possible values: 0 => off , 1 => on<br><br>
|
||||
<li><a name="volume-smooth-steps">volume-smooth-steps</a></li>
|
||||
Optional attribute to define the number of volume changes between the
|
||||
current and the desired volume. Default value is 5 steps<br><br>
|
||||
<li><a name="volume-smooth-time">volume-smooth-time</a></li>
|
||||
Optional attribute to define the time window for the volume smoothing in seconds.
|
||||
For example the value 2 means the smooth process in general should take 2 seconds.
|
||||
The value 0 means "as fast as possible". Default value is 0.
|
||||
</ul>
|
||||
<br>
|
||||
<b>Implementator's note</b>
|
||||
<ul>
|
||||
The module is only usable if you activate "Network Standby" on your receiver.<br><br>
|
||||
Technically there are many more commands and readings possible, but I think
|
||||
these are the main usecases within FHEM.
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -134,3 +134,66 @@ return undef;
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="FB_CALLMONITOR"></a>
|
||||
<h3>FB_CALLMONITOR</h3>
|
||||
<ul>
|
||||
<tr><td>
|
||||
The FB_CALLMONITOR module connects to a AVM FritzBox Fon and listens for telephone
|
||||
events (Receiving incoming call, Making a call)
|
||||
<br><br>
|
||||
In order to use this module with fhem you <b>must</b> enable the CallMonitor feature via
|
||||
telephone shortcode.<br><br>
|
||||
<ul>
|
||||
<code>#96*5* - for activating<br>#96*4* - for deactivating</code>
|
||||
</ul>
|
||||
|
||||
<br>
|
||||
Just dial the shortcode for activating on one of your phones, after 3 seconds just hang up. The feature is now activated.
|
||||
<br>
|
||||
After activating the CallMonitor-Support in your FritzBox, this module is able to
|
||||
generate an event for each call.
|
||||
<br><br>
|
||||
This module work with any FritzBox Fon model.
|
||||
<br><br>
|
||||
|
||||
<a name="FB_CALLMONITORdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> FB_CALLMONITOR <ip-address>[:port]</code><br>
|
||||
<br>
|
||||
port is 1012 by default.
|
||||
<br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="FB_CALLMONITORset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
N/A
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="FB_CALLMONITORget"></a>
|
||||
<b>Get</b>
|
||||
<ul>
|
||||
N/A
|
||||
</ul>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<a name="FB_CALLMONITORattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#loglevel">loglevel</a></li><br>
|
||||
<li><a href="#event-on-update-reading">event-on-update-reading</a></li>
|
||||
<li><a href="#event-on-change-reading">event-on-change-reading</a></li>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -196,3 +196,61 @@ MSG_Define($$)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="MSG"></a>
|
||||
<h3>MSG</h3>
|
||||
<ul>
|
||||
The MSG device is the backend device for all the message handling (I/O-engine).
|
||||
Under normal conditions only one MSG device is needed to serve multiple frontend
|
||||
message devices like file or email.
|
||||
<br><br>
|
||||
<a name="MSGdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> MSG </code><br><br>
|
||||
Specifies the MSG device. A single MSG device could serve multiple MSG frontends.
|
||||
But, for special conditions there could be defined more than one MSG device.
|
||||
</ul>
|
||||
<br>
|
||||
<a name="MSGset"></a>
|
||||
<b>Set</b>
|
||||
<ul>
|
||||
<code>set <name> send|write <devicename></code><br><br>
|
||||
</ul>
|
||||
Notes:
|
||||
<ul>
|
||||
To send the data, both send or write could be used.<br>
|
||||
The devicename is the name of a frontenddevice previously
|
||||
defined. Based on the type of the frontend device, the MSG device
|
||||
will send out the lines of data.
|
||||
<br>
|
||||
Frontend devices are available for:<br>
|
||||
<ul><li><a href="#MSGFile">File</a></li>
|
||||
<li><a href="#MSGMail">EMail with SSL Authentification</a></li></ul>
|
||||
For details about this devices, please review the device-definitions.<br>
|
||||
After sending/writing the data, the data stills exists with the
|
||||
frontend device, MSG do not delete/purge any data, this must be done
|
||||
by the frontend device.
|
||||
<br><br>
|
||||
Examples:
|
||||
<ul>
|
||||
<code>define myMsg MSG</code>
|
||||
</ul>
|
||||
</ul>
|
||||
<a name="MSGVattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#IODev">IODev</a></li>
|
||||
<li><a href="#dummy">dummy</a></li>
|
||||
<li><a href="#ignore">ignore</a></li>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
<li><a href="#eventMap">eventMap</a></li><br>
|
||||
</ul>
|
||||
</ul>
|
||||
<br><br>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -152,3 +152,82 @@ MSGFile_Undef($$)
|
||||
return undef;
|
||||
}
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="MSGFile"></a>
|
||||
<h3>MSGFile</h3>
|
||||
<ul>
|
||||
The MSGFile device is a frontend device for message handling.
|
||||
With a MSGFile device data is written to disk (or other media).
|
||||
Multiple MSGFile devices could be defined.
|
||||
To write the data to disk, a MSG device is necessary.
|
||||
A MSGFile device needs the operating systems rights to write to the filesystem.
|
||||
To set the rights for a directory, please use OS related commands.
|
||||
<br><br>
|
||||
|
||||
<a name="MSGFileDefine"></a>
|
||||
<b>Define</b>
|
||||
<ul><br>
|
||||
<code>define <name> MSGFile <filename></code><br><br>
|
||||
Specifies the MSGFile device. At definition the message counter is set to 0.
|
||||
A filename must be specified at definition.
|
||||
</ul>
|
||||
<br>
|
||||
Examples:
|
||||
<ul>
|
||||
<code>define myFile MSGFile</code>
|
||||
</ul><br>
|
||||
<a name="MSGFileSet"></a>
|
||||
|
||||
<b>Set</b><br>
|
||||
<ul><code>set <name> add|clear|list [text]</code><br>
|
||||
Set is used to manipulate the message buffer of the device. The message
|
||||
buffer is an array of lines of data, stored serial based on the incoming
|
||||
time into the buffer. Lines of data inside the buffer could not be deleted
|
||||
anymore, except of flashing the whole buffer.<br>
|
||||
<ul><b>add</b><br> to add lines of data to the message buffer. All data behind
|
||||
"add" will be interpreted as text message. To add a carriage return to the data,
|
||||
please use the CR attribute.
|
||||
</ul>
|
||||
<ul><b>clear</b><br> to flash the message buffer and set the line counter to 0.
|
||||
All the lines of data are deleted and the buffer is flushed.</ul>
|
||||
<ul><b>list</b><br> to list the message buffer.</ul><br>
|
||||
</ul><br>
|
||||
Examples:
|
||||
<ul>
|
||||
<code>set myFile add Dies ist Textzeile 1</code><br>
|
||||
<code>set myFile add Dies ist Textzeile 2</code><br>
|
||||
<code>set myFile clear</code><br><br>
|
||||
Full working example to write two lines of data to a file:<br>
|
||||
<code>define myMsg MSG</code><br>
|
||||
<code>define myFile MSGFile /tmp/fhemtest.txt</code><br>
|
||||
<code>attr myFile filemode append</code><br>
|
||||
<code>set myFile add Textzeile 1</code><br>
|
||||
<code>set myFile add Textzeile 2</code><br>
|
||||
<code>set myMsg write myFile</code><br>
|
||||
<code>set myFile clear</code><br>
|
||||
</ul><br>
|
||||
|
||||
<a name="MSGFileVattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="MSGFilefilename">filename</a><br>
|
||||
sets the filename, must be a fully qualified filename.
|
||||
FHEM must have the rights to write this file to the directory</li>
|
||||
<li><a href="MSGFilefilemode">filemode</a><br>
|
||||
sets the filemode, valid are "new" or "append"<br>
|
||||
new creates a new, empty file and writes the data to this file. Existing files are cleared, the data is lost!<br>
|
||||
append uses, if available, an existing file and writes the
|
||||
buffer data to the end of the file. If the file do not exist, it will
|
||||
be created</li>
|
||||
<li><a href="MSGFilenameCR">CR</a><br>
|
||||
set the option to write a carriage return at the end of the line.
|
||||
CR could be set to 0 or 1, 1 enables this feature</li>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -156,3 +156,109 @@ MSGMail_Undef($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="MSGMail"></a>
|
||||
<h3>MSGMail</h3>
|
||||
<ul>
|
||||
The MSGMail device is a frontend device for mail message handling.
|
||||
With a MSGMaildevice data is fowarded to a mail provider and send to a recipent.
|
||||
Multiple MSGMail devices could be defined.
|
||||
MSGMail supports by the moment only mail provider, which uses SSL secured connection
|
||||
like Googlemail, GMX, Yahoo or 1und1 for example.
|
||||
To send an email, a MSG device is necessary.<br>
|
||||
<b>MAIL::Lite</b> and <b>Net::SMTP::SSL</b> from CPAN is needed to use MSGMail!!
|
||||
<br><br>
|
||||
|
||||
<a name="MSGMailDefine"></a>
|
||||
<b>Define</b>
|
||||
<ul><br>
|
||||
<code>define <name> MSGMail <from> <to> <smtphost> <authfile></code><br><br>
|
||||
Specifies the MSGMail device. At definition the message counter is set to 0.
|
||||
From, To, SMTPHost and the authfile (see attributes below) need to be defined
|
||||
at definition time.
|
||||
</ul>
|
||||
<br>
|
||||
Examples:
|
||||
<ul>
|
||||
<code>define myMail MSGMail from@address.com to@address.com smtp.provider.host /etc/msgauthfile</code>
|
||||
</ul><br>
|
||||
|
||||
<a name="MSGMailSet"></a>
|
||||
<b>Set</b><br>
|
||||
<ul><code>set <name> add|clear|list [text]</code><br>
|
||||
Set is used to manipulate the message buffer of the device. The message
|
||||
buffer is an array of lines of data, stored serial based on the incoming
|
||||
time into the buffer. Lines of data inside the buffer could not be deleted
|
||||
anymore, except of flashing the whole buffer.<br>
|
||||
<ul><b>add</b><br> to add lines of data to the message buffer. All data behind
|
||||
"add" will be interpreted as text message. To add a carriage return to the data,
|
||||
please use the CR attribute.
|
||||
</ul>
|
||||
<ul><b>clear</b><br> to flash the message buffer and set the line counter to 0.
|
||||
All the lines of data are deleted and the buffer is flushed.</ul>
|
||||
<ul><b>list</b><br> to list the message buffer.<br></ul><br>
|
||||
<br>
|
||||
Examples:
|
||||
<ul>
|
||||
<code>set myMail add Dies ist Textzeile 1</code><br>
|
||||
<code>set myMail add Dies ist Textzeile 2</code><br>
|
||||
<code>set myMail clear</code><br><br>
|
||||
Full working example to send two lines of data to a recipent:<br>
|
||||
<code>define myMsg MSG</code><br>
|
||||
<code>define myMail MSGMail donald.duck@entenhausen.com dagobert.duck@duck-banking.com smtp.entenhausen.net /etc/fhem/msgmailauth</code><br>
|
||||
<code>attr myMail smtpport 9999</code><br>
|
||||
<code>attr myMail subject i need more money</code><br>
|
||||
<code>attr myMail CR 0</code><br>
|
||||
<code>set myMail add Please send me </code><br>
|
||||
<code>set myMail add 1.000.000 Taler</code><br>
|
||||
<code>set myMsg send myMail</code><br>
|
||||
<code>set myMail clear</code><br>
|
||||
</ul><br>
|
||||
</ul>
|
||||
|
||||
<a name="MSGMailattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
Almost all of these attributes are not optional, most of them could set at definition.<br>
|
||||
<li><a href="MSGMailFrom">from</a><br>
|
||||
sets the mail address of the sender</li>
|
||||
<li><a href="MSGMailTo">to</a><br>
|
||||
sets the mail address of the recipent</li>
|
||||
<li><a href="MSGMailsmtphost">smtphost</a><br>
|
||||
sets the name of the smtphost, for example for GMX
|
||||
you could use mail.gmx.net or for Googlemail the smtphost is
|
||||
smtp.googlemail.com</li>
|
||||
<li><a href="MSGMailsmtphost">smtpport</a> (optional)<br>
|
||||
sets the port of the smtphost, for example for GMX
|
||||
or for Googlemail the smtport is 465, which is also
|
||||
the default and do not need to be set</li>
|
||||
<li><a href="MSGMailsubject">subject</a> (optional)<br>
|
||||
sets the subject of this email. Per default the subject is set to "FHEM"<br>
|
||||
</li>
|
||||
<li><a href="MSGMailauthfile">authfile</a><br>
|
||||
sets the authfile for the SSL connection to the SMTP host<br>
|
||||
the authfile is a simple textfile with the userid in line 1 and
|
||||
the password in line 2.<br>
|
||||
Example:<br>
|
||||
<code>123user45</code><br>
|
||||
<code>strenggeheim</code><br>
|
||||
It is a good behaviour to protect this data and put the file, for
|
||||
example into the /etc directory and set the rights to 440
|
||||
(chmod 440 /etc/msgmailauthfile), so that not everyone could see the contents
|
||||
of the file. FHEM must have access to this file to read the userid and password.
|
||||
<br>
|
||||
</li>
|
||||
<li><a href="MSGFilenameCR">CR</a><br>
|
||||
set the option to write a carriage return at the end of the line.
|
||||
CR could be set to 0 or 1, 1 enables this feature.
|
||||
Per default this attribute is enabled</li>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -345,3 +345,91 @@ DONE:
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -303,3 +303,64 @@ xxLG7000GetData($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -252,3 +252,91 @@ M232Counter_Define($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -243,3 +243,94 @@ LGTV_Define($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -115,3 +115,57 @@ M232Voltage_Define($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -539,3 +539,80 @@ WS2000_List($$)
|
||||
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -139,3 +139,29 @@ ALL4000T_GetStatus($)
|
||||
|
||||
1;
|
||||
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="ALL4000T"></a>
|
||||
<h3>ALL4000T</h3>
|
||||
<ul>
|
||||
Note: this module requires the following perl modules: XML::Simple LWP::UserAgent
|
||||
HTTP::Request.
|
||||
<br><br>
|
||||
<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>
|
||||
=end html
|
||||
=cut
|
||||
|
@ -148,3 +148,75 @@ IPWE_GetStatus($)
|
||||
|
||||
1;
|
||||
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
=end html
|
||||
=cut
|
||||
|
@ -135,3 +135,52 @@ ITACH_RELAY_Define($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="ITACH_RELAY"></a>
|
||||
<h3>ITACH_RELAY</h3>
|
||||
<ul>
|
||||
Note: this module needs the Net::Telnet module.
|
||||
<br><br>
|
||||
<a name="ITACH_RELAYdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> ITACH_RELAY <ip-address> <port></code>
|
||||
<br><br>
|
||||
Defines an Global Cache iTach Relay device (Box with 3 relays) via its ip address. <br><br>
|
||||
|
||||
|
||||
Examples:
|
||||
<ul>
|
||||
<code>define motor1 ITACH_RELAY 192.168.8.200 1</code><br>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="ITACH_RELAYset"></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 motor1 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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -337,3 +337,57 @@ VantagePro2_GetStatus($)
|
||||
|
||||
1;
|
||||
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="VantagePro2"></a>
|
||||
<h3>VantagePro2</h3>
|
||||
<ul>
|
||||
Note: this module needs the Net::Telnet perl module.
|
||||
<br><br>
|
||||
<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>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -141,3 +141,29 @@ WEBCOUNT_GetStatus($)
|
||||
|
||||
1;
|
||||
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="WEBCOUNT"></a>
|
||||
<h3>WEBCOUNT</h3>
|
||||
<ul>
|
||||
Note: this module needs the HTTP::Request and LWP::UserAgent perl modules.
|
||||
<br><br>
|
||||
<a name="WEBCOUNTdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> WEBCOUNT <ip-address> <port> <delay></code>
|
||||
<br><br>
|
||||
Defines an WEBCOUNT device (Box with 6 count pulses, www.wut.de) via ip address. The device is pooled (delay interval).<br><br>
|
||||
|
||||
|
||||
Examples:
|
||||
<ul>
|
||||
<code>define pump WEBCOUNT 192.168.8.200 1 60</code><br>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
=end html
|
||||
=cut
|
||||
|
@ -215,3 +215,132 @@ at_State($$$$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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 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>
|
||||
|
||||
<a name="alignTime"></a>
|
||||
<li>alignTime<br>
|
||||
Applies only to relative at definitions: adjust the time of the next
|
||||
command execution so, that it will also be executed at the desired
|
||||
alignTime. The argument is a timespec, see above for the
|
||||
definition.<br>
|
||||
Example:<br>
|
||||
<ul>
|
||||
# Make sure that it chimes when the new hour begins<br>
|
||||
define at2 at +*01:00 set Chime on-for-timer 1<br>
|
||||
attr atr2 alignTime 00:00<br>
|
||||
</ul>
|
||||
</li><br>
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -103,3 +103,116 @@ notify_Attr(@)
|
||||
return undef;
|
||||
}
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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. The space separated event "parts" are
|
||||
available as %EVTPART0, %EVTPART1, etc. 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</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>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
<a name="forwardReturnValue"></a>
|
||||
<li>forwardReturnValue<br>
|
||||
Forward the return value of the executed command to the caller,
|
||||
default is disabled (0). If enabled (1), then e.g. a set command which
|
||||
triggers this notify will also return this value. This can cause e.g
|
||||
FHEMWEB to display this value, when clicking "on" or "off", which is
|
||||
often not intended.</li>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -116,3 +116,50 @@ sequence_Undef($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="sequence"></a>
|
||||
<h3>sequence</h3>
|
||||
<ul>
|
||||
<br>
|
||||
|
||||
<a name="sequencedefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> sequence <re1> <timeout1> <re2> [<timeout2> <re3> ...]</code>
|
||||
<br><br>
|
||||
|
||||
A sequence is used to allow to trigger events for a certain combination of
|
||||
button presses on a remote. E.g. to switch on a lamp when pressing the
|
||||
Btn1:on, then Btn2:off and at last Btn1:on one after the other you could
|
||||
define the following:<br>
|
||||
<br>
|
||||
<ul>
|
||||
<code>
|
||||
define lampseq sequence Btn1:on 0.5 Btn2:off 0.5 Btn1:on<br>
|
||||
define lampon notify lampseq:trigger set lamp on
|
||||
</code>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="sequenceset"></a>
|
||||
<b>Set</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="sequenceget"></a>
|
||||
<b>Get</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="sequenceattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#disable">disable</a></li>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -146,3 +146,87 @@ watchdog_Undef($$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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>
|
||||
# Request data from the FHT80 _once_ if we do not receive any message for
|
||||
# 15 Minutes.
|
||||
define w watchdog FHT80 00:15:00 SAME set FHT80 date
|
||||
|
||||
# Request data from the FHT80 _each_ time we do not receive any message for
|
||||
# 15 Minutes, i.e. reactivate the watchdog after it triggered. Might be
|
||||
# dangerous, as it can trigger in a loop.
|
||||
define w watchdog FHT80 00:15:00 SAME set FHT80 date;; trigger w .
|
||||
|
||||
# Shout once if the HMS100-FIT is not alive
|
||||
define w watchdog HMS100-FIT 01:00:00 SAME "alarm-fit.sh"
|
||||
|
||||
# Send mail if the window is left open
|
||||
define w watchdog contact1:open 00:15 contact1:closed "mail_me close window1"
|
||||
attr w regexp1WontReactivate
|
||||
</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><regexp1> resets the timer of a running watchdog, to avoid it
|
||||
use the regexp1WontReactivate attribute.
|
||||
<li>if <regexp2> is SAME, then it will be the same as the first
|
||||
regexp, and it will be reactivated, when it is received.
|
||||
</li>
|
||||
<li>trigger <watchdogname> . will activate the trigger if its state
|
||||
is defined, and set it into state defined if its state is
|
||||
triggered. You always have to reactivate the watchdog with this
|
||||
command once it has triggered (unless you restart fhem)</li>
|
||||
<li>a generic watchdog (one watchdog responsible for more devices) is
|
||||
currently not possible.</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>
|
||||
<li><a name="regexp1WontReactivate">regexp1WontReactivate</a><br>
|
||||
When a watchdog is active, a second event matching regexp1 will
|
||||
normally reset the timeout. Set this attribute to prevents this.
|
||||
</li>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -485,3 +485,203 @@ seekTo($$$$)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<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 device name
|
||||
devicename:event or timestamp:devicename:event combination.
|
||||
The regexp must match the complete string, not just a part of it.
|
||||
<br>
|
||||
<code><filename></code> may contain %-wildcards of the
|
||||
POSIX strftime function of the underlying OS (see your strftime manual).
|
||||
Common used wildcards are:
|
||||
<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>%W</code> week number of year with Monday as first day of week (00..53)
|
||||
</ul>
|
||||
FHEM also replaces <code>%L</code> by the value of the global logdir attribute.<br>
|
||||
Before using <code>%V</code> for ISO 8601 week numbers check if it is
|
||||
correctly supported by your system (%V may not be replaced, replaced by an
|
||||
empty string or by an incorrect ISO-8601 week number, especially
|
||||
at the beginning of the year)
|
||||
If you use <code>%V</code> you will also have to use %G
|
||||
instead of %Y for the year!<br>
|
||||
Examples:
|
||||
<ul>
|
||||
<code>define lamplog FileLog %L/lamp.log lamp</code><br>
|
||||
<code>define wzlog FileLog /var/tmp/wz-%Y-%U.log
|
||||
wz:(measured-temp|actuator).*</code><br>
|
||||
With ISO 8601 week numbers, if supported:<br>
|
||||
<code>define wzlog FileLog /var/tmp/wz-%G-%V.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>
|
||||
<br>
|
||||
|
||||
|
||||
<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, used by frontends to plot data without direct
|
||||
access to the file.<br>
|
||||
|
||||
<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 are set,
|
||||
then nrarchive old logfiles are kept along the current one while older
|
||||
ones are 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 fslog FileLog log/fs20dev-%Y-%U.log fs20dev
|
||||
</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 log/fht1-%Y-%U.log fht1:.*(temp|actuator).*</code>
|
||||
|
||||
</li>
|
||||
<li>temp4rain10<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 ks300log FileLog log/fht1-%Y-%U.log ks300:.*H:.*
|
||||
</li>
|
||||
<li>hum6wind8<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 temp4rain10:Temp/Rain,hum6wind8:Hum/Wind,text:Raw-data
|
||||
</li><br>
|
||||
|
||||
|
||||
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -291,3 +291,93 @@ FHEM2FHEM_SimpleRead($)
|
||||
}
|
||||
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="FHEM2FHEM"></a>
|
||||
<h3>FHEM2FHEM</h3>
|
||||
<ul>
|
||||
FHEM2FHEM is a helper module to connect separate fhem installations.
|
||||
<br><br>
|
||||
<a name="FHEM2FHEMdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> FHEM2FHEM <host>[:<portnr>][:SSL] [LOG:regexp|RAW:devicename] {portpassword}
|
||||
</code>
|
||||
<br>
|
||||
<br>
|
||||
Connect to the <i>remote</i> fhem on <host>. <portnr> is a telnet
|
||||
port on the remote fhem, defaults to 7072. The optional :SSL suffix is
|
||||
needed, if the remote fhem configured SSL for this telnet port. In this case
|
||||
the IO::Socket::SSL perl module must be installed for the local host too.<br>
|
||||
|
||||
Note: if the remote fhem is on a separate host, the telnet port on the remote
|
||||
fhem musst be specified with the global option.<br>
|
||||
|
||||
The next parameter specifies the connection
|
||||
type:
|
||||
<ul>
|
||||
<li>LOG<br>
|
||||
Using this type you will receive all events generated by the remote fhem,
|
||||
just like when using the <a href="#inform">inform on</a> command, and you
|
||||
can use these events just like any local event for <a
|
||||
href="#FileLog">FileLog </a> or <a href="#notify">notify</a>.
|
||||
The regexp will prefilter the events distributed locally, for the syntax
|
||||
see the notify definition.<br>
|
||||
Drawbacks: the remote devices wont be created locally, so list wont
|
||||
show them and it is not possible to manipulate them from the local
|
||||
fhem. It is possible to create a device with the same name on both fhem
|
||||
instances, but if both of them receive the same event (e.g. because both
|
||||
of them have a CUL attached), then all associated FileLogs/notifys will be
|
||||
triggered twice. </li>
|
||||
|
||||
<li>RAW<br>
|
||||
By using this type the local fhem will receive raw events from the remote
|
||||
fhem device <i>devicename</i>, just like if it would be attached to the
|
||||
local fhem.
|
||||
Drawback: only devices using the Dispatch function (CUL, FHZ, CM11,
|
||||
SISPM, RFXCOM, TCM, TRX, TUL) generate raw messages, and you must create a
|
||||
FHEM2FHEM instance for each remote device.<br>
|
||||
<i>devicename</i> must exist on the local
|
||||
fhem server too with the same name and same type as the remote device, but
|
||||
with the device-node "none", so it is only a dummy device.
|
||||
All necessary attributes (e.g. <a href="#rfmode">rfmode</a> if the remote
|
||||
CUL is in HomeMatic mode) must also be set for the local device.
|
||||
Do not reuse a real local device, else duplicate filtering (see dupTimeout)
|
||||
won't work correctly.
|
||||
</li>
|
||||
</ul>
|
||||
The last parameter specifies an optional portpassword, if the remote server
|
||||
activated <a href="#portpassword">portpassword</a>.
|
||||
<br>
|
||||
Examples:
|
||||
<ul>
|
||||
<code>define ds1 FHEM2FHEM 192.168.178.22:7072 LOG:.*</code><br>
|
||||
<br>
|
||||
<code>define RpiCUL CUL none 0000</code><br>
|
||||
<code>define ds2 FHEM2FHEM 192.168.178.22:7072 RAW:RpiCUL</code><br>
|
||||
and on the RPi (192.168.178.22):<br>
|
||||
<code>rename CUL_0 RpiCUL</code><br>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="FHEM2FHEMset"></a>
|
||||
<b>Set</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="FHEM2FHEMget"></a>
|
||||
<b>Get</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="FHEM2FHEMattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a href="#dummy">dummy</a></li>
|
||||
<li><a href="#loglevel">loglevel</a></li>
|
||||
</ul>
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
@ -694,3 +694,156 @@ FP_input(@)
|
||||
return "<input type=\"$type\"$title$size$maxlength $addition name=\"$n\" value=\"$v\"/>\n";
|
||||
}
|
||||
1;
|
||||
|
||||
=pod
|
||||
=begin html
|
||||
|
||||
<a name="FLOORPLAN"></a>
|
||||
<h3>FLOORPLAN</h3>
|
||||
<ul>
|
||||
Implements an additional entry "Floorplans" to your fhem menu, leading to a userinterface without fhem-menu, rooms or devicelists.
|
||||
Devices can be displayed at a defined coordinate on the screen, usually with a clickable icon allowing to switch
|
||||
the device on or off by clicking on it. A background-picture can be used - use e.g. a floorplan of your house, or any picture.
|
||||
Use floorplanstyle.css to adapt the representation.<br>
|
||||
Step-by-step setup guides are available in
|
||||
<a href="http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/docs/fhem-floorplan-installation-guide.pdf">english</a> and
|
||||
<a href="http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/docs/fhem-floorplan-installation-guide_de.pdf">german</a>. <br>
|
||||
<br>
|
||||
|
||||
<a name="FLOORPLANdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> FLOORPLAN </code>
|
||||
<br><br>
|
||||
|
||||
<b>Hint:</b> Store fp_<name>.png in your image folder (www/images/default , www/pgm2 or FHEM) to use it as background picture.<br><br>
|
||||
Example:
|
||||
<ul>
|
||||
<code>
|
||||
define Groundfloor FLOORPLAN<br>
|
||||
fp_Groundfloor.png
|
||||
</code><br>
|
||||
</ul>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="FLOORPLANset"></a>
|
||||
<b>Set </b>
|
||||
<ul>
|
||||
<li>N/A</li>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="FLOORPLANget"></a>
|
||||
<b>Get </b>
|
||||
<ul>
|
||||
<li>N/A</li>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="FLOORPLANattr"></a>
|
||||
<b>Attributes</b>
|
||||
<ul>
|
||||
<li><a name="fp_fpname">userattr fp_<name> <top>,<left>[,<style>[,<description>]]</a><br><br>
|
||||
A <a href="#userattr">userattr</a> fp_<name> will be created automatically if it does not exist yet.<br>
|
||||
<ul>
|
||||
<li>top = screen-position, pixels from top of screen
|
||||
<li>left = screen-position, pixels from left of screen
|
||||
<li>style =
|
||||
<ul>
|
||||
<li>0 icon/state only
|
||||
<li>1 devicename and icon/state
|
||||
<li>2 devicename, icon/state and commands
|
||||
<li>3 device-reading and optional description
|
||||
<li>4 S300TH-specific, displays temperature above humidity
|
||||
<li>5 icon/state and commands
|
||||
<li>6 device-reading, reading-timestamp and optional description
|
||||
</ul>
|
||||
<li>description will be displayed instead of the original devicename
|
||||
</ul><br>
|
||||
Examples:<br>
|
||||
<ul>
|
||||
<table>
|
||||
<tr><td><code>attr lamp1 fp_Groundfloor 100,100</code></td><td><code>#display lamp1 with icon only at screenposition 100,100</code></td></tr>
|
||||
<tr><td><code>attr lamp2 fp_Groundfloor 100,140,1,Art-Deco</code></td><td><code>#display lamp2 with description 'Art-Deco-Light' at 100,140</code></td></tr>
|
||||
<tr><td><code>attr lamp2 fp_FirstFloor 130,100,1</code></td><td><code>#display the same device at different positions on other floorplans</code></td></tr>
|
||||
<tr><td><code>attr myFHT fp_Groundfloor 300,20,10,Temperature</code></td><td><code>#display given Text + FHT-temperature</code></td></tr>
|
||||
</table>
|
||||
</ul>
|
||||
<b>Hint:</b> no blanks between parameters<br><br>
|
||||
|
||||
|
||||
<li><a name="fp_arrange">fp_arrange</a><br>
|
||||
Activates the "arrange mode" which shows an additional menu on the screen,
|
||||
allowing to place devices easily on the screen.<br>
|
||||
Example:
|
||||
<ul>
|
||||
<code>attr Groundfloor fp_arrange 1</code><br>
|
||||
<code>attr Groundfloor fp_arrange detail #displays the devices with infos room, type, alias</code><br>
|
||||
<code>attr Groundfloor fp_arrange WEB #activates arrange mode for frontend-device WEB only</code><br><br>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a name="stylesheet">stylesheet</a><br>
|
||||
Explicitely sets your personal stylesheet for the floorplan. This overrides the standard stylesheet.
|
||||
The standard stylesheet for floorplans is <code>floorplanstyle.css</code>. If the <a href="#stylesheetPrefix">stylesheetPrefix</a> is set for the corresponding FHEMWEB instance, this same
|
||||
<code>stylesheetPrefix</code> is also prepended to the stylesheet for floorplans.<br>
|
||||
All stylesheets must be stored in the stylesheet subfolder of the fhem filesystem hierarchy. Store your personal
|
||||
stylesheet along with <code>floorplanstyle.css</code> in the same folder.<br>
|
||||
Example:
|
||||
<ul>
|
||||
<code>attr Groundfloor stylesheet myfloorplanstyle.css</code><br><br>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<li><a name="fp_default">fp_default</a><br>
|
||||
The floorplan startscreen is skipped if this attribute is assigned to one of the floorplans in your installation.
|
||||
</li>
|
||||
Example:
|
||||
<ul>
|
||||
<code>attr Groundfloor fp_default 1</code><br><br>
|
||||
</ul>
|
||||
|
||||
<li><a name="fp_noMenu">fp_noMenu</a><br>
|
||||
Suppresses the menu which usually shows the links to all your floorplans.
|
||||
</li>
|
||||
Example:
|
||||
<ul>
|
||||
<code>attr Groundfloor fp_noMenu 1</code><br><br>
|
||||
</ul>
|
||||
|
||||
<li><a name="commandfield">commandfield</a><br>
|
||||
Adds a fhem-commandfield to the floorplan screen.
|
||||
</li>
|
||||
Example:
|
||||
<ul>
|
||||
<code>attr Groundfloor commandfield 1</code><br><br>
|
||||
</ul>
|
||||
|
||||
<li><a name="fp_backgroundimg">fp_backgroundimg</a><br>
|
||||
Allows to choose a background-picture independent of the floorplan-name.
|
||||
</li>
|
||||
Example:
|
||||
<ul>
|
||||
<code>attr Groundfloor fp_backgroundimg foobar.png</code><br><br>
|
||||
</ul>
|
||||
|
||||
<li><a name="fp_inherited">Inherited from FHEMWEB</a><br>
|
||||
The following attributes are inherited from the underlying <a href="#FHEMWEB">FHEMWEB</a> instance:<br>
|
||||
<ul>
|
||||
<a href="#smallscreen">smallscreen</a><br>
|
||||
<a href="#touchpad">touchpad</a><br>
|
||||
<a href="#refresh">refresh</a><br>
|
||||
<a href="#plotmode">plotmode</a><br>
|
||||
<a href="#plotsize">plotsize</a><br>
|
||||
<a href="#webname">webname</a><br>
|
||||
<a href="#redirectCmds">redirectCmds</a><br>
|
||||
</ul>
|
||||
</li><br>
|
||||
</ul>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
=end html
|
||||
=cut
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user