2
0
mirror of https://github.com/fhem/fhem-mirror.git synced 2025-02-28 02:44:53 +00:00

HM-SWI-3-FM support

git-svn-id: https://svn.fhem.de/fhem/trunk@1454 2b470e98-0d58-463d-a4d8-8e2adae1ed80
This commit is contained in:
rudolfkoenig 2012-04-15 16:24:00 +00:00
parent 5c7cad7d55
commit cdbc7a8dd0
2 changed files with 67 additions and 60 deletions

@ -92,7 +92,7 @@ my %culHmModel=(
"0043" => "HM-SEC-TIS",
"0044" => "HM-SEN-EP",
"0045" => "HM-SEC-WDS", # Tested by peterp
"0046" => "HM-SWI-3-FM",
"0046" => "HM-SWI-3-FM", # Tested by NorbertW
"0047" => "KFM-Display",
"0048" => "IS-WDS-TH-OD-S-R3",
"0049" => "KFM-Sensor",
@ -112,9 +112,9 @@ my %culHmModel=(
"0059" => "HM-LC-DIM1T-FM",
"005A" => "HM-LC-DIM2T-SM",
"005C" => "HM-OU-CF-PL",
"005F" => "HM-SCI-3-FM",
"005F" => "HM-SCI-3-FM", # Tested by fhem-hm-knecht
"0060" => "HM-PB-4DIS-WM", # Tested
"0061" => "HM-LC-SW4-DR", # Tested by fhem-hm-knecht.
"0061" => "HM-LC-SW4-DR", # Tested by fhem-hm-knecht
"0062" => "HM-LC-SW2-DR",
"0066" => "HM_LC_Sw4-WM", # Tested by peterp
"006C" => "HM-LC-SW1-PCB", # By jan (unsure if working)
@ -613,7 +613,17 @@ CUL_HM_Parse($$)
CUL_HM_SendCmd($shash, "++8002".$id.$src."0101". # Send Ack.
($state =~ m/on/?"C8":"00")."00", 1, 0);
}
}
} elsif($st eq "swi") { ################################################
# Raw data by NorbertW
if($cmd =~ m/^..4./ && $p =~ m/^(..)(..)$/) {
my ($button, $bno) = (hex($1), hex($2));
push @event, "state:Btn$button toggle$target";
if($id eq $dst && $cmd ne "8002") { # Send Ack
CUL_HM_SendCmd($shash, "++8002".$id.$src."01010000",1,0) # Send Ack.
}
}
} elsif($st eq "motionDetector") { #####################################

@ -2793,64 +2793,8 @@ A line ending with \ will be concatenated with the next one, so long lines
<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>.
href="#HMLAN">HMLAN</a>.<br>
<br>
Prerequisites:
<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>The protocol used by HomeMatic devices (BidCos, known as AskSin
in the culfw) must be enabled in the culfw firmware. This is done for all
CUN and for newer CUL (i.e. V3.0 and greater) devices with culfw firmware
version 1.38 and newer. For CUL hardware version before 3.0 there is a
separate firmware with HomeMatic support which lacks FHT support.
</li>
</ul>
<b>Notes</b>
<ul>
<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>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>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>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 (the address is part of the signing request), it is
able to answer signing requests correctly. In the reality this will
only work reliably if the foreign CCU is switched off, else it
will also answer to the signing request in parallel, and the actor
will not receive a clear confirmation.
<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.
</ul>
</ul>
<br><br>
<a name="CUL_HMdefine"></a>
<b>Define</b>
<ul>
@ -2864,6 +2808,10 @@ A line ending with \ will be concatenated with the next one, so long lines
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>
@ -2881,6 +2829,52 @@ A line ending with \ will be concatenated with the next one, so long lines
appropriately.
</ul>
<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>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>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>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 (the address is part of the signing request), it is
able to answer signing requests correctly. In the reality this will
only work reliably if the foreign CCU is switched off, else it
will also answer to the signing request in parallel, and the actor
will not receive a clear confirmation.
<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.
</ul>
</ul>
</ul><br>
<a name="CUL_HMset"></a>
@ -3092,6 +3086,9 @@ A line ending with \ will be concatenated with the next one, so long lines
Btn$x offLong $counter (to $dest)<br>
Btn$x onLongRelease $counter (to $dest)<br>
Btn$x offLongRelease $counter (to $dest)<br>
<li>swi<br>
Btn$x toggle<br>
Btn$x toggle (to $dest)<br>
<li>motionDetector<br>
brightness:$b<br>
alive<br>