From 3b49d97b295e5814a281fe14f3bbe27fc9ea6528 Mon Sep 17 00:00:00 2001
From: rudolfkoenig <rudolfkoenig@2b470e98-0d58-463d-a4d8-8e2adae1ed80>
Date: Sun, 15 Apr 2012 16:24:00 +0000
Subject: [PATCH] HM-SWI-3-FM support

git-svn-id: https://fhem.svn.sourceforge.net/svnroot/fhem/trunk/fhem@1454 2b470e98-0d58-463d-a4d8-8e2adae1ed80
---
 FHEM/10_CUL_HM.pm    |  16 +++++--
 docs/commandref.html | 111 +++++++++++++++++++++----------------------
 2 files changed, 67 insertions(+), 60 deletions(-)

diff --git a/FHEM/10_CUL_HM.pm b/FHEM/10_CUL_HM.pm
index c7d99072d..31a8019e2 100755
--- a/FHEM/10_CUL_HM.pm
+++ b/FHEM/10_CUL_HM.pm
@@ -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") { #####################################
diff --git a/docs/commandref.html b/docs/commandref.html
index dfefd9b5d..2aea08688 100644
--- a/docs/commandref.html
+++ b/docs/commandref.html
@@ -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>