mirror of
https://github.com/fhem/fhem-mirror.git
synced 2025-04-28 17:12:32 +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
parent
5c7cad7d55
commit
cdbc7a8dd0
@ -92,7 +92,7 @@ my %culHmModel=(
|
|||||||
"0043" => "HM-SEC-TIS",
|
"0043" => "HM-SEC-TIS",
|
||||||
"0044" => "HM-SEN-EP",
|
"0044" => "HM-SEN-EP",
|
||||||
"0045" => "HM-SEC-WDS", # Tested by peterp
|
"0045" => "HM-SEC-WDS", # Tested by peterp
|
||||||
"0046" => "HM-SWI-3-FM",
|
"0046" => "HM-SWI-3-FM", # Tested by NorbertW
|
||||||
"0047" => "KFM-Display",
|
"0047" => "KFM-Display",
|
||||||
"0048" => "IS-WDS-TH-OD-S-R3",
|
"0048" => "IS-WDS-TH-OD-S-R3",
|
||||||
"0049" => "KFM-Sensor",
|
"0049" => "KFM-Sensor",
|
||||||
@ -112,9 +112,9 @@ my %culHmModel=(
|
|||||||
"0059" => "HM-LC-DIM1T-FM",
|
"0059" => "HM-LC-DIM1T-FM",
|
||||||
"005A" => "HM-LC-DIM2T-SM",
|
"005A" => "HM-LC-DIM2T-SM",
|
||||||
"005C" => "HM-OU-CF-PL",
|
"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
|
"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",
|
"0062" => "HM-LC-SW2-DR",
|
||||||
"0066" => "HM_LC_Sw4-WM", # Tested by peterp
|
"0066" => "HM_LC_Sw4-WM", # Tested by peterp
|
||||||
"006C" => "HM-LC-SW1-PCB", # By jan (unsure if working)
|
"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.
|
CUL_HM_SendCmd($shash, "++8002".$id.$src."0101". # Send Ack.
|
||||||
($state =~ m/on/?"C8":"00")."00", 1, 0);
|
($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") { #####################################
|
} 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>
|
<h3>CUL_HM</h3>
|
||||||
<ul>
|
<ul>
|
||||||
Support for eQ-3 HomeMatic devices via the <a href="#CUL">CUL</a> or the <a
|
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>
|
<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>
|
<a name="CUL_HMdefine"></a>
|
||||||
<b>Define</b>
|
<b>Define</b>
|
||||||
<ul>
|
<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.
|
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.
|
Autocreate will then create a fhem device and set all necessary attributes.
|
||||||
Without pairing the device will not accept messages from fhem.
|
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>
|
<br><br>
|
||||||
If you cannot use autocreate, then you have to specify:<br>
|
If you cannot use autocreate, then you have to specify:<br>
|
||||||
<ul>
|
<ul>
|
||||||
@ -2881,6 +2829,52 @@ A line ending with \ will be concatenated with the next one, so long lines
|
|||||||
appropriately.
|
appropriately.
|
||||||
|
|
||||||
</ul>
|
</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>
|
</ul><br>
|
||||||
|
|
||||||
<a name="CUL_HMset"></a>
|
<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 offLong $counter (to $dest)<br>
|
||||||
Btn$x onLongRelease $counter (to $dest)<br>
|
Btn$x onLongRelease $counter (to $dest)<br>
|
||||||
Btn$x offLongRelease $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>
|
<li>motionDetector<br>
|
||||||
brightness:$b<br>
|
brightness:$b<br>
|
||||||
alive<br>
|
alive<br>
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user