FHEM Forum

I had a WD18 water sensor and a GB18 gaz detector (which I define as GD18, I think it is a typo in the code), which seem to work OK with 46_TRX_SECURITY.pm

I just bought a 2nd hand pack with WD18, COD18 (CO detector), GB18 and SD18 (smoke detector). I had to patch the code in order to make SD18 work properly as it seems to give opposite values as compared to the others. Does anybody else noticed the same behavior or is it mine which is malfunctioning?

Here is my patch (I also defined values for COD18 and SD18) :

Zitat--- 46_TRX_SECURITY.pm   2013-09-30 23:16:14.000000000 +0200
+++ 46_TRX_SECURITY.pm.new   2013-09-29 23:31:40.000000000 +0200
@@ -231,14 +231,14 @@ TRX_SECURITY_Define($$)
   $type = uc($type);
 
   my $my_type;
-  if ($type eq "WD18" || $type eq "GD18" ) {
+  if ($type eq "WD18" || $type eq "GD18" || $type eq "SD18" || $type eq "COD18") {
    $my_type = "DS10A"; # device will be received as DS10A   
   } else {
    $my_type = $type;
   }
   my $device_name = "TRX".$DOT.$my_type.$DOT.$deviceid;
 
-  if ($type ne "DS10A" && $type ne "SD90" && $type ne "MS10A" && $type ne "MS14A" && $type ne "KR18" && $type ne "KD101" && $type ne "VISONIC_WINDOW" & $type ne "VISONIC_MOTION" & $type ne "VISONIC_REMOTE" && $type ne "GD18" && $type ne "WD18") {
+  if ($type ne "DS10A" && $type ne "SD90" && $type ne "MS10A" && $type ne "MS14A" && $type ne "KR18" && $type ne "KD101" && $type ne "VISONIC_WINDOW" && $type ne "VISONIC_MOTION" & $type ne "VISONIC_REMOTE" && $type ne "GD18" && $type ne "WD18" && $type ne "SD18" && $type ne "COD18") {
      Log3 $hash, 1,"TRX_SECURITY_Define() wrong type: $type";
      return "TRX_SECURITY: wrong type: $type";
   }
@@ -447,12 +447,18 @@ sub TRX_SECURITY_parse_X10Sec($$) {
    $current = "Error";
    $current = "Open" if ($command eq "alert");
    $current = "Closed" if ($command eq "normal");
-  } elsif ($device_type eq "WD18" || $device_type eq "GD18") {
+  } elsif ($device_type eq "WD18" || $device_type eq "GD18" || $device_type eq "COD18") {
    $current = "Error";
    $current = "normal" if ($command eq "alert");
    $current = "alert" if ($command eq "normal");
    $delay = "";  
    $option = "";  
+  } elsif ($device_type eq "SD18") {
+   $current = "Error";
+   $current = "normal" if ($command eq "normal");
+   $current = "alert" if ($command eq "alert");
+   $delay = "";  
+   $option = "";  
   }
 
   readingsBeginUpdate($def);

I have two GD-18, see http://www.eurox10.com/Product/Security/HomeProtector/GD-18.htm (//www.eurox10.com/Product/Security/HomeProtector/GD-18.htm) and also two WD18.

Both are set with switch to S (Sensor).

My gas sensor GD18 is really labeled as GD18.
It works nice as a gas sensor, but is very bad to be used with FHEM:
- RF range is very low
- It will also generate a new code after power off. Looks like I can only use it with FHEM using an USV...

Because of this I do not really use them with FHEM.

I have now put them near my RFXtrx433 to test it.

It may be that I did not correctly implement the GD18. Maybe alert and normal is reversed?

How does it work with the GB18?

What is the SD18? Does is also have the R/S switch?

Does ist send a keepalive signal?

-- Willi

You are right for the gas sensor : mine is also labeled GD18. That's the user's guide (//support.domadoo.com/index.php?/Knowledgebase/Article/View/61/72/cod18-manuel-dinstallation) which has a typo !

The SD18 is a smoke detector

All these sensors (//www.planete-domotique.com/pack-securite-domestique-x10-radio-fumee-gaz-monoxyde-eau.html) (COD18 GB18 SD18 WD18) have an R/S switch (Remote / Sensor) :
- they send a keepalive signal in S mode and are recognized as KR18
- they are recognized as DS10A in R mode and only trigger alarms (seems to)
It also seems from the manual addendum that you cannot use them with a SC18 SC28 Home Protector console in S mode (which I do not have, so I don't care). See also http://board.homeseer.com/showthread.php?t=152638 (//board.homeseer.com/showthread.php?t=152638) about S mode which sends incorrect information too (seems you filtered it in the code)

The behavior difference I see is with the SD18, which seems to have alert and normal reverted as compared to the others, that's why I changed your code for this one.
I will check when I first use my chimney if my sensor works properly as it was not new when I bought it!

I have no problem with RF range : it works in my house
But these sensors drain batteries fast ...

Zitat von: Willi schrieb am Do, 03 Oktober 2013 19:30- It will also generate a new code after power off. Looks like I can only use it with FHEM using an USV...

What is an USV ?
I have a suggestion : would it we possible to add a command similar to absorb in FileLog, in order to replace the code in an existing definition by the code in another one
ex:
I have defined a good definition  
define flooding_alert TRX_SECURITY WD18 8671 water
attr flooding_alert alias alerte inondation
attr flooding_alert devStateIcon normal:message_ok alert:message_attention
attr flooding_alert icon scene_bath
attr flooding_alert room Maison
but code has changed to 66b9 and I get a new one :
define TRX_DS10A_66b9 TRX_SECURITY DS10A 66b9 Window
attr TRX_DS10A_66b9 room TRX_SECURITY
define FileLog_TRX_DS10A_66b9 FileLog ./log/TRX_DS10A_66b9-%Y-%m.log TRX_DS10A_66b9
attr FileLog_TRX_DS10A_66b9 logtype fht80tf:Window,text
attr FileLog_TRX_DS10A_66b9 room TRX_SECURITY
define SVG_TRX_DS10A_66b9 SVG fileplot FileLog_TRX_DS10A_66b9:fht80tf:CURRENT
attr SVG_TRX_DS10A_66b9 label "TRX_DS10A_66b9 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_TRX_DS10A_66b9 room Plots
We could have
set flooding_alert replace TRX_DS10A_66b9
which would remove all the TRX_DS10A_66b9 FileLog_TRX_DS10A and SVG_TRX_DS10A_66b9 stuff and would replace 8671 by 66b9 in the flooding_alert definition

Olivier

Zitat von: oliv06 schrieb am Fr, 04 Oktober 2013 01:02We could have

Code Auswählen Erweitern

set flooding_alert replace TRX_DS10A_66b9
which would remove all the TRX_DS10A_66b9 FileLog_TRX_DS10A and SVG_TRX_DS10A_66b9 stuff and would replace 8671 by 66b9 in the flooding_alert definition

I do not know how to extend FHEM this way.

Within my modules I will get the new ID as a DS10A and will generade UNDEFINED. autocreate does the rest.

Unfortunateley I can not differ between a GD18, WD18, DS10A and all the others that user X10.
So I see no way to see that GD18 has changed its ID.

For the new replace command, please as the developers section.

-- Willi

Hello Willi,
Could you integrate my patch (see first post) in your code so it is not overided by updates.
It has been working for a while now and I do not see any problem
Thanks a lot
Olivier