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:
parent
5c7cad7d55
commit
cdbc7a8dd0
fhem
@ -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>
|
||||
|
Loading…
x
Reference in New Issue
Block a user