Dobermann DB-ES-K1A in my FHEM server

Begonnen von olivierbardot, 03 Oktober 2019, 15:07:46

Vorheriges Thema - Nächstes Thema

olivierbardot

Hello everybody !

I wish to integrate a Dobermann DB-ES-K1A in my FHEM server.
https://www.etiger.com/en/products/es-k1a

After having searched the forum, this is what I have done :

1- Analysis with RFXmngr
------------------------------------------------
15/09/2019 10:30:06:519= 08200060A055A00950
Packettype    = Security1
subtype       = X10 security
Sequence nbr  = 96
id1-3         = A055A0 decimal:10507680
status        = Arm Away
battery level = Low
Signal level  = 5  -80dBm


1- Autocreate with RFXCom

1-1 Autocreate disabled
I dial the code on DB-ES-K1A and Event Monitor says :
2019-10-02 21:40:39 Global global UNDEFINED TRX_DS10A_a0a0 TRX_SECURITY DS10A a0a0 Window

1-2 Autocreate enabled
I dial the code on DB-ES-K1A and Event Monitor says :
2019-10-02 21:40:39 Global global DEFINED TRX_DS10A_a0a0
2019-10-02 21:40:39 Global global DEFINED FileLog_TRX_DS10A_a0a0
2019-10-02 21:40:39 Global global DEFINED SVG_TRX_DS10A_a0a0

1-3 I understand that FHEM recognize the device as Window" or "Door" sensor which is normal for ds10a
see : https://forum.fhem.de/index.php/topic,6086.msg24377.html#msg24377

2- Change DEF
So I modify DEF of the device like follows :
DEF : DS10A a0a0 Window -> DEF : kr18 a0a0 Security

I dial the code on DB-ES-K1A and Event Monitor says :

2019-10-02 21:45:36 TRX_SECURITY TRX_DS10A_a0a0 Security: Arm_Away
2019-10-02 21:45:36 TRX_SECURITY TRX_DS10A_a0a0 battery: low
2019-10-02 21:45:36 TRX_SECURITY TRX_DS10A_a0a0 batteryState: low
2019-10-02 21:45:36 TRX_SECURITY TRX_DS10A_a0a0 delay: min
2019-10-02 21:45:36 TRX_SECURITY TRX_DS10A_a0a0 Arm_Away
2019-10-02 21:45:40 TRX_SECURITY TRX_DS10A_a0a0 Security: Disarm
2019-10-02 21:45:40 TRX_SECURITY TRX_DS10A_a0a0 battery: ok
2019-10-02 21:45:40 TRX_SECURITY TRX_DS10A_a0a0 batteryState: ok
2019-10-02 21:45:40 TRX_SECURITY TRX_DS10A_a0a0 delay: min
2019-10-02 21:45:40 TRX_SECURITY TRX_DS10A_a0a0 Disarm
2019-10-02 21:45:44 TRX_SECURITY TRX_DS10A_a0a0 Security: Arm_Home
2019-10-02 21:45:44 TRX_SECURITY TRX_DS10A_a0a0 battery: ok
2019-10-02 21:45:44 TRX_SECURITY TRX_DS10A_a0a0 batteryState: ok
2019-10-02 21:45:44 TRX_SECURITY TRX_DS10A_a0a0 delay: min
2019-10-02 21:45:44 TRX_SECURITY TRX_DS10A_a0a0 Arm_Home
2019-10-02 21:45:49 TRX_SECURITY TRX_DS10A_a0a0 Security: Panic
2019-10-02 21:45:49 TRX_SECURITY TRX_DS10A_a0a0 battery: ok
2019-10-02 21:45:49 TRX_SECURITY TRX_DS10A_a0a0 batteryState: ok
2019-10-02 21:45:49 TRX_SECURITY TRX_DS10A_a0a0 Panic
Device is now recognized as digicode (Type Kerui KR18)
Everything seems perfect !!!

3- But no !!

After a few working properly, I dial the code on DB-ES-K1A and Event Monitor says :
2019-10-02 21:40:39 Global global UNDEFINED TRX_DS10A_a0a0 TRX_SECURITY DS10A a0a0 Window

Device is no more recognized !!!

4- OK Let's go back
I modify DEF of the device like follows :
DEF : kr18 a0a0 Security -> DEF : DS10A a0a0 Window

Device is recognized as Window" or "Door" sensor
I dial the code on DB-ES-K1A and Event Monitor says :
2019-10-03 14:18:22 TRX_SECURITY TRX_DS10A_a0a0 Window: Error
2019-10-03 14:18:22 TRX_SECURITY TRX_DS10A_a0a0 battery: low
2019-10-03 14:18:22 TRX_SECURITY TRX_DS10A_a0a0 batteryState: low
2019-10-03 14:18:22 TRX_SECURITY TRX_DS10A_a0a0 delay: min
2019-10-03 14:18:22 TRX_SECURITY TRX_DS10A_a0a0 Error

and back another time
DEF : DS10A a0a0 Window -> DEF : kr18 a0a0 Security
I dial the code on DB-ES-K1A and Event Monitor says :
2019-10-03 14:20:49 TRX_SECURITY TRX_DS10A_a0a0 Security: Arm_Home
2019-10-03 14:20:49 TRX_SECURITY TRX_DS10A_a0a0 battery: ok
2019-10-03 14:20:49 TRX_SECURITY TRX_DS10A_a0a0 batteryState: ok
2019-10-03 14:20:49 TRX_SECURITY TRX_DS10A_a0a0 delay: min
2019-10-03 14:20:49 TRX_SECURITY TRX_DS10A_a0a0 Arm_Home
Device is now recognized as digicode

5- Sudo reboot on raspberrypi3b+ on which runs FHEM server

I dial the code on DB-ES-K1A and Event Monitor says :
2019-10-03 14:24:24 Global global UNDEFINED TRX_DS10A_a0a0 TRX_SECURITY DS10A a0a0 Window

Device is no more recognized !!!

6-It seems that I swindle FHEM cache

7- I deleted all items, reboot and tried these definitions but it doesn't work either :
define TRX_DS10A_a0a0 RFXX10REC kr18 a0a0 Security
define TRX_DS10A_a0a0 TRX_SECURITY kr18 a0a0 Security
I dial the code on DB-ES-K1A and Event Monitor says :
2019-10-03 15:02:40 Global global UNDEFINED TRX_DS10A_a0a0 TRX_SECURITY DS10A a0a0 Window

Is there a more simple solution than patch the RFXCom module 46_TRX_SECURITY.pm in order to create a TRX_SECURITY DS10A a0a0 Digicode device ?
Any help would be appreciated.
Thanks by advance.
Olivier (France)

olivierbardot

Hello !

When ESK1-A trame signal is parsed by sub TRX_SECURITY_Parse($$) from  46_TRX_SECURITY.pm, it returns rfxcom_data_array=32 0 176 160 85 160 11 105 (from hexdata trame hex=082000b0a055a00b69 which correspond to Arm_home command)

So, when this X10Sec data is parsed by sub TRX_SECURITY_parse_X10Sec($$), it returns as normal $subtype=0 (cause $subtype = $bytes->[1])
As normal, reverse hash table says rec=DS10A Window

At this point of code, it doesn't seems to me possible to redefine cleanly $subtype so that my device could be recognized as KR18.

On the other hand, further, the current command is redefined in window sensors command ($current = "Open" if ($command eq "alert")).
As $subtype remains 0, it doesn't seem possible to redefine it in a Panic command for DS10A like it is done further for KR18 devices ($current = "Security-Panic" if ($command eq "alert")

So, I patched the module code at the beginning when ESK1-A trame signal is parsed by sub TRX_SECURITY_Parse($$), so that it returns rfxcom_data_array=32 2 176 160 85 160 11 105 instead of rfxcom_data_array=32 0 176 160 85 160 11 105 (  if ($rfxcom_data_array[1]==0) {$rfxcom_data_array[1]=2; } - obvious )

As a consequence, ESK1-A is recognized like KR18 device and I have verified that everything from the module works properly, especially after rebooting the system.

But, by the way, every subtype 0 device (DS10A devices) is also recognized like KR18 device, which is very bad !

Does anyone here has an idea to get around this trick ?

Does the X10Sec protocol specify that $bytes[1] (second field of the data frame) =0 implies that the device is a  window sensor, although ESK1-A which is a remote sensor and not a window sensor  also sends a data frame with a second field equal to 0 ?

Thanks
Olivier