FHEM Forum

Hallo,

hat jemand schon das neue 8-Kanal Sendemodul (ist jetzt lieferbar!) getestet, bzw. in FHEM die Integration überlegt?

Interessant finde ich die Möglichkeit, wie in den technischen Daten des Moduls beschrieben wird, daß die Eingänge auch als analoge Spannungseingänge genutzt werden können. Damit könnte man diverse Sensoren und Messsysteme entwickeln, mit bis zu 8 Kanälen.

Gruß Borney.

Hallo

ich hab bei der letzten Gutschein Bestellung von ELV auch einen bestellt, bin schon gespannt.

Gruß Hannes

Das Modul besitzt zwar neben den 8 Tastereingängen (Taster gegen GND werden erkannt) auch 8 Spannungseingänge, diese steuern jedoch nur Transistoren an, die die jeweiligen Eingänge parallel ansteuern. Als Eingangsbereich werden 2-24V angegeben, d.h. eine Spannung in diesem Bereich schaltet den Eingang aktiv. Nix analog.

Meins liegt hier, wird aber von FHEM (noch) nicht erkannt, model unknown.

Martin, brauchst Du RAW-Messages zum Einbauen? (wie ging das gleich nochmal ...  :o)

Das ist schade, keine analogen Eingänge!

Nun gut, wenn das Modul nur mit digitalen Eingängen ausgestattet ist, kann ich es dennoch mit vorgeschalteten Komparatoren zur Überwachung von Spannungen (Solarmodul im Gartenhaus) verwenden.

Dann erst mal Danke für die Info, würde mich freuen, wenn das Modul mit Fhem nutzbar würde.

Hab mein HM-MOD-EM8 gelöscht, resetted und neu angelernt.

1. Es meldet sich als CUL_HM_ID_00D9_312F44.
"get hm models" (HMInfo) liefert eine (neue) weitgehend leere Zeile, die ID 00D9 scheint also neu zu sein:
...
pushButton       ROTO_ZEL-STG-RM-WT-2     007D config,wakeup,lazyConf         1,4
                                          00D9 normal
motionDetector   HM-Sen-MDIR-O            005D config,wakeup,lazyConf   00:10 1,4
...

2. Das habe ich nach "attr global verbose 1; attr global mseclog 1, attr HMLAN1 logIDs all,sys" in meiner Log gefunden:
2014.10.03 18:08:53.806 0: HMLAN_Send:  HMLAN1 S:SD6C56675 stat:  00 t:00000000 d:01 r:D6C56675 m:3D 8401 1411AB 000000 010A4C455131313133373530
2014.10.03 18:08:54.450 0: HMLAN_Parse: HMLAN1 R:RD6C56675 stat:0002 t:00000000 d:FF r:7FFF     m:3D 8401 1411AB 000000 010A4C455131313133373530
2014.10.03 18:08:55.933 0: HMLAN_Parse: HMLAN1 R:E23B2D0   stat:0000 t:00E72317 d:FF r:FFE4     m:B0 A641 23B2D0 1411AB 01D52D80
2014.10.03 18:08:56.030 0: HMLAN_Send:  HMLAN1 S:SD6C56ED2 stat:  00 t:00000000 d:01 r:D6C56ED2 m:B0 8002 1411AB 23B2D0 01012D00
2014.10.03 18:08:56.317 0: HMLAN_Parse: HMLAN1 R:RD6C56ED2 stat:0002 t:00000000 d:FF r:7FFF     m:B0 8002 1411AB 23B2D0 01012D00
2014.10.03 18:08:58.527 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:00E72D39 d:FF r:FFC6     m:01 8400 312F44 000000 1000D94C45513131313337353040080000
Use of uninitialized value in hash element at fhem.pl line 1320.
Use of uninitialized value in split at ./FHEM/10_CUL_HM.pm line 4696.
2014.10.03 18:09:03.573 0: HMLAN_Send:  HMLAN1 I:+312F44,00,01,00
2014.10.03 18:09:05.970 0: HMLAN_Parse: HMLAN1 R:E23B2D0   stat:0000 t:00E74A4E d:FF r:FFE4     m:B1 8410 23B2D0 1411AB 06012D00
2014.10.03 18:09:07.210 0: HMLAN_Send:  HMLAN1 I:K
2014.10.03 18:09:07.218 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:HEQ0136973 d:141B13 O:1411AB t:00E74F32 IDcnt:001C
Use of uninitialized value in string eq at FHEM/Blocking.pm line 86.
Use of uninitialized value in string eq at FHEM/Blocking.pm line 86.
Use of uninitialized value in string eq at FHEM/Blocking.pm line 86.
2014.10.03 18:09:32.222 0: HMLAN_Send:  HMLAN1 I:K
2014.10.03 18:09:32.233 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:HEQ0136973 d:141B13 O:1411AB t:00E7B0EA IDcnt:001C
2014.10.03 18:09:57.231 0: HMLAN_Send:  HMLAN1 I:K
2014.10.03 18:09:57.239 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:HEQ0136973 d:141B13 O:1411AB t:00E8129D IDcnt:001C

3. Jetzt wird es richtig verwirrend: Ich habe das Logging nochmal gestartet und anschließend alle 8 Eingänge "durchgetastet", immer etwa eine Sekunde gedrückt, zwei losgelassen, dann nächste Taste:
2014.10.03 18:30:38 1: HM-Logging gestartet...
2014.10.03 18:30:43.717 0: HMLAN_Send:  HMLAN1 I:K
2014.10.03 18:30:43.731 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:HEQ0136973 d:141B13 O:1411AB t:000D0CDD IDcnt:001C
2014.10.03 18:30:43.774 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D0D04 d:FF r:FFCC     m:06 8440 312F44 000000 4102
2014.10.03 18:30:44.045 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D0E13 d:FF r:FFCC     m:07 8440 312F44 000000 4102
2014.10.03 18:30:44.318 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D0F23 d:FF r:FFCC     m:08 8440 312F44 000000 4102
2014.10.03 18:30:44.589 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D1034 d:FF r:FFCE     m:09 8440 312F44 000000 4102
2014.10.03 18:30:44.862 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D1144 d:FF r:FFCE     m:0A 8440 312F44 000000 4102
2014.10.03 18:30:46.946 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D1969 d:FF r:FFCC     m:0B 8440 312F44 000000 4201
2014.10.03 18:30:47.218 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D1A79 d:FF r:FFCC     m:0C 8440 312F44 000000 4201
2014.10.03 18:30:47.490 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D1B89 d:FF r:FFCC     m:0D 8440 312F44 000000 4201
2014.10.03 18:30:47.762 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D1C99 d:FF r:FFCE     m:0E 8440 312F44 000000 4201
2014.10.03 18:30:49.858 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D24C9 d:FF r:FFCB     m:0F 8440 312F44 000000 4301
2014.10.03 18:30:50.130 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D25D9 d:FF r:FFCB     m:10 8440 312F44 000000 4301
2014.10.03 18:30:50.402 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D26E9 d:FF r:FFCB     m:11 8440 312F44 000000 4301
2014.10.03 18:30:50.674 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D27F9 d:FF r:FFCD     m:12 8440 312F44 000000 4301
2014.10.03 18:30:52.722 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D2FF8 d:FF r:FFCB     m:13 8440 312F44 000000 4401
2014.10.03 18:30:52.992 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D3109 d:FF r:FFCB     m:14 8440 312F44 000000 4401
2014.10.03 18:30:53.264 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D3219 d:FF r:FFCB     m:15 8440 312F44 000000 4401
2014.10.03 18:30:53.536 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D3329 d:FF r:FFCD     m:16 8440 312F44 000000 4401
2014.10.03 18:30:55.592 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D3B31 d:FF r:FFCB     m:17 8440 312F44 000000 4501
2014.10.03 18:30:55.863 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D3C40 d:FF r:FFCB     m:18 8440 312F44 000000 4501
2014.10.03 18:30:56.135 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D3D50 d:FF r:FFCB     m:19 8440 312F44 000000 4501
2014.10.03 18:30:56.407 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D3E60 d:FF r:FFCD     m:1A 8440 312F44 000000 4501
2014.10.03 18:30:58.493 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D4686 d:FF r:FFCB     m:1B 8440 312F44 000000 4601
2014.10.03 18:30:58.764 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D4795 d:FF r:FFCB     m:1C 8440 312F44 000000 4601
2014.10.03 18:30:59.036 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D48A5 d:FF r:FFCB     m:1D 8440 312F44 000000 4601
2014.10.03 18:30:59.308 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D49B5 d:FF r:FFCD     m:1E 8440 312F44 000000 4601
2014.10.03 18:31:01.282 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D516C d:FF r:FFCC     m:1F 8440 312F44 000000 4701
2014.10.03 18:31:01.553 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D527B d:FF r:FFCB     m:20 8440 312F44 000000 4701
2014.10.03 18:31:01.826 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D538C d:FF r:FFCB     m:21 8440 312F44 000000 4701
2014.10.03 18:31:02.098 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D549C d:FF r:FFCD     m:22 8440 312F44 000000 4701
2014.10.03 18:31:03.992 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D5C02 d:FF r:FFCB     m:23 8440 312F44 000000 4801
2014.10.03 18:31:04.264 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D5D12 d:FF r:FFCB     m:24 8440 312F44 000000 4801
2014.10.03 18:31:04.536 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D5E22 d:FF r:FFCB     m:25 8440 312F44 000000 4801
2014.10.03 18:31:04.808 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:000D5F32 d:FF r:FFCE     m:26 8440 312F44 000000 4801
2014.10.03 18:31:07.421 1: HM-Logging gestoppt

Hoffe, daraus lässt sich die Zuordnung der Kanäle lesen?

Sehe gerade, dass das Modul hinterher nicht gepairt war. Also nochmal:
2014.10.03 18:39:55 1: HM-Logging gestartet...
2014.10.03 18:40:14.744 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:0015C3AA d:FF r:FFD2     m:31 8400 312F44 000000 1000D94C45513131313337353040080000
Use of uninitialized value in split at ./FHEM/10_CUL_HM.pm line 4696.
Use of uninitialized value in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 2389.
2014.10.03 18:40:14.839 0: HMLAN_Send:  HMLAN1 S:SD6E21A17 stat:  00 t:00000000 d:01 r:D6E21A17 m:16 A001 1411AB 312F44 00050000000000
2014.10.03 18:40:14.997 0: HMLAN_Parse: HMLAN1 R:RD6E21A17 stat:0001 t:0015C4AC d:FF r:FFCE     m:16 8002 312F44 1411AB 00
2014.10.03 18:40:15.097 0: HMLAN_Send:  HMLAN1 S:SD6E21AED stat:  00 t:00000000 d:01 r:D6E21AED m:17 A001 1411AB 312F44 000802010A140B110CAB
2014.10.03 18:40:15.394 0: HMLAN_Parse: HMLAN1 R:RD6E21AED stat:0001 t:0015C639 d:FF r:FFCE     m:17 8002 312F44 1411AB 00
2014.10.03 18:40:15.494 0: HMLAN_Send:  HMLAN1 S:SD6E21C7A stat:  00 t:00000000 d:01 r:D6E21C7A m:18 A001 1411AB 312F44 0006
2014.10.03 18:40:15.803 0: HMLAN_Parse: HMLAN1 R:RD6E21C7A stat:0001 t:0015C7D2 d:FF r:FFD0     m:18 8002 312F44 1411AB 00
2014.10.03 18:40:15.903 0: HMLAN_Send:  HMLAN1 S:SD6E21E17 stat:  00 t:00000000 d:01 r:D6E21E17 m:19 A001 1411AB 312F44 00040000000000
2014.10.03 18:40:16.213 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:0015C967 d:FF r:FFCE     m:19 A010 312F44 1411AB 02020105000A140B110CAB120014031800
2014.10.03 18:40:16.325 0: HMLAN_Parse: HMLAN1 R:RD6E21E17 stat:0001 t:0015C96C d:FF r:FFCE     m:19 A010 312F44 1411AB 02020105000A140B110CAB120014031800
2014.10.03 18:40:16.457 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:0015CA5B d:FF r:FFD1     m:19 A010 312F44 1411AB 020000
2014.10.03 18:40:18.806 0: HMLAN_Send:  HMLAN1 S:SD6E229BD stat:  00 t:00000000 d:01 r:D6E229BD m:1A A001 1411AB 312F44 00040000000000
2014.10.03 18:40:18.944 0: HMLAN_Send:  HMLAN1 I:K
2014.10.03 18:40:18.951 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:HEQ0136973 d:141B13 O:1411AB t:0015D41E IDcnt:001C
2014.10.03 18:40:19.413 0: HMLAN_Parse: HMLAN1 R:RD6E229BD stat:0008 t:00000000 d:FF r:7FFF     m:1A A001 1411AB 312F44 00040000000000
2014.10.03 18:40:19.415 0: HMLAN_Parse: HMLAN1 no ACK from 312F44
2014.10.03 18:40:24.103 0: HMLAN_Send:  HMLAN1 S:SD6E23E6D stat:  00 t:00000000 d:01 r:D6E23E6D m:1A A001 1411AB 312F44 00040000000000
2014.10.03 18:40:24.710 0: HMLAN_Parse: HMLAN1 R:RD6E23E6D stat:0008 t:00000000 d:FF r:7FFF     m:1A A001 1411AB 312F44 00040000000000
2014.10.03 18:40:24.712 0: HMLAN_Parse: HMLAN1 no ACK from 312F44
2014.10.03 18:40:28.352 0: HMLAN_Send:  HMLAN1 S:SD6E24F06 stat:  00 t:00000000 d:01 r:D6E24F06 m:1A A001 1411AB 312F44 00040000000000
2014.10.03 18:40:28.959 0: HMLAN_Parse: HMLAN1 R:RD6E24F06 stat:0008 t:00000000 d:FF r:7FFF     m:1A A001 1411AB 312F44 00040000000000
2014.10.03 18:40:28.961 0: HMLAN_Parse: HMLAN1 no ACK from 312F44
2014.10.03 18:40:32.877 0: HMLAN_Parse: HMLAN1 R:E2D9AAE   stat:0000 t:00160A81 d:FF r:FFCB     m:2C 8653 2D9AAE 000000 004100A94200E543FFC444003C
2014.10.03 18:40:34.114 0: HMLAN_Send:  HMLAN1 S:SD6E26588 stat:  00 t:00000000 d:01 r:D6E26588 m:1A A001 1411AB 312F44 00040000000000
2014.10.03 18:40:34.521 1: HM-Logging gestoppt

Ein erneutes "getConfig" liefert jetzt diese Readings:

.D-devInfo              080000    2014-10-03 18:41:59
.D-stc                     40           2014-10-03 18:41:59
.protLastRcv            2014-10-03 18:42:02 2014-10-03 18:42:02
CommandAccepted  yes          2014-10-03 18:40:15
D-firmware             1.0          2014-10-03 18:41:59
D-serialNr               LEQ1113750 2014-10-03 18:41:59
PairedTo                 0x1411AB 2014-10-03 18:42:02
R-pairCentral          0x1411AB 2014-10-03 18:40:16
RegL_00: 02:01 05:00 0A:14 0B:11 0C:AB 12:00 14:03 18:00 00:00     2014-10-03 18:42:02
state RESPONSE TIMEOUT:RegisterRead

und an letzterem ändert sich jetzt wieder mal nichts...

ist eingebaut.
er sollte jetzt wir eine "normale" remote funktionieren.
Ein getConfig würde noch helfen, ob weitere Register existieren

Zitat von: martinp876 am 03 Oktober 2014, 19:31:36
ist eingebaut.

Du bist wie immer schneller als die Polizei erlaubt. Was wäre die HM-Fraktion ohne Dich!

Wird morgen nach dem Update alles gecheckt, inkl. Register

Zitater sollte jetzt wir eine "normale" remote funktionieren.

Das könnte noch spannend werden.
Die Anleitung (die wohl leider nicht online verfügbar ist, außer im ELV-Journal) gibt sich da ja sehr ominös - im Prinzip aber ist die recht neue 8-Kanal-Fernbedienung ja auch zunächst im direkten Anlernen wie eine 2-Tasten-(Aus-Ein)-Fernbedienung, die sich in FHEM auch eintastig peeren und über Shorts und Longs abfragen lässt.
Das Modul soll aber daneben noch eine weitere Betriebsart beherrschen, die im Prinzip dem Schalterinterface SCI3 ähnelt - hier sendet das Gerät wohl nur eine Statusänderung bei sich änderndem Eingang, statt wie bei einer Remote üblich Longs über die gesamte Tastendruckzeit. Dieser Modus ist der eigentlich interessante. Mal sehen, wie das in Gang zu bekommen ist. Das dürfte Neuland werden, da mir kein vergleichbares Device bekannt ist.

So, Update und - funktioniert wie von Martin vorgegeben einwandfrei als Remote mit Short, Long x und LongRelease.

Zitat von: martinp876 am 03 Oktober 2014, 19:31:36
Ein getConfig würde noch helfen, ob weitere Register existieren

@Martin: Liefert lesbar keine neuen Erkenntnisse. Hilft Dir da ein erneuter Rohmessage-Mitschnitt mehr?
Und für mich zum Verstehen: geben die Devices irgendwie selbst die Namen ihrer Register preis oder programmierst Du die Registernamen selbst (ggf. nach bekannten Vorlagen)?

.D-devInfo
080000
2014-10-04 13:44:34
.D-stc
40
2014-10-04 13:44:34
.protLastRcv
2014-10-04 13:47:10
2014-10-04 13:47:10
CommandAccepted
yes
2014-10-03 18:40:15
D-firmware
1.0
2014-10-04 13:44:34
D-serialNr
LEQ1113750
2014-10-04 13:44:34
PairedTo
0x1411AB
2014-10-04 13:44:09
R-localResDis
off
2014-10-04 13:44:09
R-lowBatLimit
0 V
2014-10-04 13:44:09
R-pairCentral
0x1411AB
2014-10-04 13:44:09
R-transmDevTryMax
3
2014-10-04 13:44:09
RegL_00:
02:01 05:00 0A:14 0B:11 0C:AB 12:00 14:03 18:00 00:00
2014-10-04 13:44:09
battery
ok
2014-10-04 13:47:10
state
CMDs_done
2014-10-04 13:47:10
trigDst_vccu
noConfig

Zitat von: martinp876 am 03 Oktober 2014, 19:31:36
ist eingebaut.
er sollte jetzt wir eine "normale" remote funktionieren.
Ein getConfig würde noch helfen, ob weitere Register existieren

Hallo Martin,

hier ein getConfig

2014.10.04 15:40:07 3: CUL_HM set DEV_va_Em_8 getConfig
2014.10.04 15:40:07 0: HMLAN_Send:  HMLAN1 S:SDB638DAD stat:  00 t:00000000 d:01 r:DB638DAD m:44 B001 1399AE 312F2C 00040000000000
2014.10.04 15:40:09 0: HMLAN_Parse: HMLAN1 R:RDB638DAD stat:0008 t:00000000 d:FF r:7FFF     m:44 B001 1399AE 312F2C 00040000000000
2014.10.04 15:40:09 0: HMLAN_Parse: HMLAN1 no ACK from 312F2C
2014.10.04 15:40:12 0: HMLAN_Send:  HMLAN1 S:SDB63A0C9 stat:  00 t:00000000 d:01 r:DB63A0C9 m:44 B001 1399AE 312F2C 00040000000000
2014.10.04 15:40:14 0: HMLAN_Parse: HMLAN1 R:RDB63A0C9 stat:0008 t:00000000 d:FF r:7FFF     m:44 B001 1399AE 312F2C 00040000000000
2014.10.04 15:40:14 0: HMLAN_Parse: HMLAN1 no ACK from 312F2C
2014.10.04 15:40:15 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CD67728 d:FF r:FFC6     m:03 8400 312F2C 1399AE 1000D94C45513131313337373640080000
2014.10.04 15:40:50 3: CUL_HM set DEV_va_Em_8 getConfig
2014.10.04 15:40:50 0: HMLAN_Send:  HMLAN1 S:SDB64362C stat:  00 t:00000000 d:01 r:DB64362C m:45 B001 1399AE 312F2C 00040000000000
2014.10.04 15:40:52 0: HMLAN_Parse: HMLAN1 R:RDB64362C stat:0008 t:00000000 d:FF r:7FFF     m:45 B001 1399AE 312F2C 00040000000000
2014.10.04 15:40:52 0: HMLAN_Parse: HMLAN1 no ACK from 312F2C
2014.10.04 15:40:55 0: HMLAN_Send:  HMLAN1 S:SDB644AE4 stat:  00 t:00000000 d:01 r:DB644AE4 m:45 B001 1399AE 312F2C 00040000000000
2014.10.04 15:40:57 0: HMLAN_Parse: HMLAN1 R:RDB644AE4 stat:0008 t:00000000 d:FF r:7FFF     m:45 B001 1399AE 312F2C 00040000000000
2014.10.04 15:40:57 0: HMLAN_Parse: HMLAN1 no ACK from 312F2C
display


Als Ergebnis kommt:
RESPONSE TIMEOUT:RegisterRead

Jetzt nochmals komplett, weiß jedoch nicht warum es vorher nicht richtig geklappt hat:

2014.10.04 15:55:06 3: CUL_HM set DEV_va_Em_8 getConfig
2014.10.04 15:55:06 0: HMLAN_Send:  HMLAN1 S:SDB714697 stat:  00 t:00000000 d:01 r:DB714697 m:46 B001 1399AE 312F2C 00040000000000
2014.10.04 15:55:08 0: HMLAN_Parse: HMLAN1 R:RDB714697 stat:0008 t:00000000 d:FF r:7FFF     m:46 B001 1399AE 312F2C 00040000000000
2014.10.04 15:55:08 0: HMLAN_Parse: HMLAN1 no ACK from 312F2C
2014.10.04 15:55:10 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE41F87 d:FF r:FFC0     m:04 8400 312F2C 1399AE 1000D94C45513131313337373640080000
2014.10.04 15:55:11 0: HMLAN_Send:  HMLAN1 S:SDB715869 stat:  00 t:00000000 d:01 r:DB715869 m:46 B001 1399AE 312F2C 00040000000000
2014.10.04 15:55:11 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE42440 d:FF r:FFBC     m:46 A010 312F2C 1399AE 02020105000A130B990CAE120014031800
2014.10.04 15:55:12 0: HMLAN_Parse: HMLAN1 R:RDB715869 stat:0001 t:0CE42445 d:FF r:FFBC     m:46 A010 312F2C 1399AE 02020105000A130B990CAE120014031800
2014.10.04 15:55:12 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE42534 d:FF r:FFC5     m:46 A010 312F2C 1399AE 020000
2014.10.04 15:55:12 0: HMLAN_Send:  HMLAN1 S:+312F2C,00,01,00
2014.10.04 15:55:12 0: HMLAN_Send:  HMLAN1 S:SDB715BA3 stat:  00 t:00000000 d:01 r:DB715BA3 m:47 A001 1399AE 312F2C 01040000000001
2014.10.04 15:55:12 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE42741 d:FF r:FFC1     m:47 A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:12 0: HMLAN_Parse: HMLAN1 R:RDB715BA3 stat:0001 t:0CE42747 d:FF r:FFC1     m:47 A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:12 0: HMLAN_Send:  HMLAN1 S:SDB715E6F stat:  00 t:00000000 d:01 r:DB715E6F m:48 A001 1399AE 312F2C 0103
2014.10.04 15:55:13 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE42941 d:FF r:FFC1     m:48 A010 312F2C 1399AE 01000000
2014.10.04 15:55:13 0: HMLAN_Parse: HMLAN1 R:RDB715E6F stat:0001 t:0CE42946 d:FF r:FFC1     m:48 A010 312F2C 1399AE 01000000
2014.10.04 15:55:13 0: HMLAN_Send:  HMLAN1 S:+312F2C,00,01,00
2014.10.04 15:55:13 0: HMLAN_Send:  HMLAN1 S:SDB716066 stat:  00 t:00000000 d:01 r:DB716066 m:49 A001 1399AE 312F2C 02040000000001
2014.10.04 15:55:13 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE42B52 d:FF r:FFC0     m:49 A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:13 0: HMLAN_Parse: HMLAN1 R:RDB716066 stat:0001 t:0CE42B57 d:FF r:FFC0     m:49 A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:14 0: HMLAN_Send:  HMLAN1 S:SDB716332 stat:  00 t:00000000 d:01 r:DB716332 m:4A A001 1399AE 312F2C 0203
2014.10.04 15:55:14 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE42D9D d:FF r:FFC0     m:4A A010 312F2C 1399AE 01000000
2014.10.04 15:55:14 0: HMLAN_Parse: HMLAN1 R:RDB716332 stat:0001 t:0CE42DA2 d:FF r:FFC0     m:4A A010 312F2C 1399AE 01000000
2014.10.04 15:55:14 0: HMLAN_Send:  HMLAN1 S:+312F2C,00,01,00
2014.10.04 15:55:14 0: HMLAN_Send:  HMLAN1 S:SDB7164C2 stat:  00 t:00000000 d:01 r:DB7164C2 m:4B A001 1399AE 312F2C 03040000000001
2014.10.04 15:55:14 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE42FAE d:FF r:FFBF     m:4B A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:14 0: HMLAN_Parse: HMLAN1 R:RDB7164C2 stat:0001 t:0CE42FB3 d:FF r:FFBF     m:4B A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:14 0: HMLAN_Send:  HMLAN1 S:SDB7166DA stat:  00 t:00000000 d:01 r:DB7166DA m:4C A001 1399AE 312F2C 0303
2014.10.04 15:55:15 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE431AD d:FF r:FFC0     m:4C A010 312F2C 1399AE 01000000
2014.10.04 15:55:15 0: HMLAN_Parse: HMLAN1 R:RDB7166DA stat:0001 t:0CE431B2 d:FF r:FFC0     m:4C A010 312F2C 1399AE 01000000
2014.10.04 15:55:15 0: HMLAN_Send:  HMLAN1 S:+312F2C,00,01,00
2014.10.04 15:55:15 0: HMLAN_Send:  HMLAN1 S:SDB7168D2 stat:  00 t:00000000 d:01 r:DB7168D2 m:4D A001 1399AE 312F2C 04040000000001
2014.10.04 15:55:15 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE433BE d:FF r:FFC0     m:4D A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:15 0: HMLAN_Parse: HMLAN1 R:RDB7168D2 stat:0001 t:0CE433C3 d:FF r:FFC0     m:4D A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:16 0: HMLAN_Send:  HMLAN1 S:SDB716AEA stat:  00 t:00000000 d:01 r:DB716AEA m:4E A001 1399AE 312F2C 0403
2014.10.04 15:55:16 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE435BD d:FF r:FFC0     m:4E A010 312F2C 1399AE 01000000
2014.10.04 15:55:16 0: HMLAN_Parse: HMLAN1 R:RDB716AEA stat:0001 t:0CE435C2 d:FF r:FFC0     m:4E A010 312F2C 1399AE 01000000
2014.10.04 15:55:16 0: HMLAN_Send:  HMLAN1 S:+312F2C,00,01,00
2014.10.04 15:55:16 0: HMLAN_Send:  HMLAN1 S:SDB716CE3 stat:  00 t:00000000 d:01 r:DB716CE3 m:4F A001 1399AE 312F2C 05040000000001
2014.10.04 15:55:16 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE437CE d:FF r:FFC0     m:4F A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:16 0: HMLAN_Delay: HMLAN1 312F2C
2014.10.04 15:55:16 0: HMLAN_Parse: HMLAN1 R:RDB716CE3 stat:0001 t:0CE437D3 d:FF r:FFC0     m:4F A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:16 0: HMLAN_SdDly: HMLAN1 312F2C
2014.10.04 15:55:16 0: HMLAN_Send:  HMLAN1 S:SDB716E2C stat:  00 t:00000000 d:01 r:DB716E2C m:50 A001 1399AE 312F2C 0503
2014.10.04 15:55:17 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE439CD d:FF r:FFC1     m:50 A010 312F2C 1399AE 01000000
2014.10.04 15:55:17 0: HMLAN_Parse: HMLAN1 R:RDB716E2C stat:0001 t:0CE439D2 d:FF r:FFC1     m:50 A010 312F2C 1399AE 01000000
2014.10.04 15:55:17 0: HMLAN_Send:  HMLAN1 S:+312F2C,00,01,00
2014.10.04 15:55:17 0: HMLAN_Send:  HMLAN1 S:SDB7170F3 stat:  00 t:00000000 d:01 r:DB7170F3 m:51 A001 1399AE 312F2C 06040000000001
2014.10.04 15:55:17 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE43BDE d:FF r:FFC1     m:51 A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:17 0: HMLAN_Parse: HMLAN1 R:RDB7170F3 stat:0001 t:0CE43BE3 d:FF r:FFC1     m:51 A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:18 0: HMLAN_Send:  HMLAN1 S:SDB71730B stat:  00 t:00000000 d:01 r:DB71730B m:52 A001 1399AE 312F2C 0603
2014.10.04 15:55:18 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE43DDD d:FF r:FFC1     m:52 A010 312F2C 1399AE 01000000
2014.10.04 15:55:18 0: HMLAN_Parse: HMLAN1 R:RDB71730B stat:0001 t:0CE43DE2 d:FF r:FFC1     m:52 A010 312F2C 1399AE 01000000
2014.10.04 15:55:18 0: HMLAN_Send:  HMLAN1 S:+312F2C,00,01,00
2014.10.04 15:55:18 0: HMLAN_Send:  HMLAN1 S:SDB717503 stat:  00 t:00000000 d:01 r:DB717503 m:53 A001 1399AE 312F2C 07040000000001
2014.10.04 15:55:18 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE43FEE d:FF r:FFC1     m:53 A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:18 0: HMLAN_Parse: HMLAN1 R:RDB717503 stat:0001 t:0CE43FF3 d:FF r:FFC1     m:53 A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:19 0: HMLAN_Send:  HMLAN1 S:SDB71771B stat:  00 t:00000000 d:01 r:DB71771B m:54 A001 1399AE 312F2C 0703
2014.10.04 15:55:19 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE441ED d:FF r:FFC0     m:54 A010 312F2C 1399AE 01000000
2014.10.04 15:55:19 0: HMLAN_Parse: HMLAN1 R:RDB71771B stat:0001 t:0CE441F2 d:FF r:FFC0     m:54 A010 312F2C 1399AE 01000000
2014.10.04 15:55:19 0: HMLAN_Send:  HMLAN1 S:+312F2C,00,01,00
2014.10.04 15:55:19 0: HMLAN_Send:  HMLAN1 S:SDB717913 stat:  00 t:00000000 d:01 r:DB717913 m:55 A001 1399AE 312F2C 08040000000001
2014.10.04 15:55:19 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE443FE d:FF r:FFC1     m:55 A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:20 0: HMLAN_Parse: HMLAN1 R:RDB717913 stat:0001 t:0CE44403 d:FF r:FFC1     m:55 A010 312F2C 1399AE 020410080020602305300392230000
2014.10.04 15:55:20 0: HMLAN_Send:  HMLAN1 S:SDB717B2E stat:  00 t:00000000 d:01 r:DB717B2E m:56 A001 1399AE 312F2C 0803
2014.10.04 15:55:20 0: HMLAN_Parse: HMLAN1 R:E312F2C   stat:0000 t:0CE445FD d:FF r:FFC1     m:56 A010 312F2C 1399AE 01000000
2014.10.04 15:55:20 0: HMLAN_Parse: HMLAN1 R:RDB717B2E stat:0001 t:0CE44602 d:FF r:FFC1     m:56 A010 312F2C 1399AE 01000000


Wie kann man, den Remote so umstellen, dass er als Fensterkontakt Abfrage funktioniert, d.h. nur bei Zustandsänderungen etwas sendet?
Laut Beschreibung von ELV kann man diese Betriebsart nur über CCU2 einstellen, leider besitze keine solche.
Geht dass evtl. auch via FHEM?

Gruß Hannes

Zitat von: AHA1805 am 04 Oktober 2014, 15:43:44
RESPONSE TIMEOUT:RegisterRead

Das hatte ich seit Martins Eingriff und dem Update heute früh dann (endlich) nicht mehr ... ?

ZitatWie kann man, den Remote so umstellen, dass er als Fensterkontakt Abfrage funktioniert, d.h. nur bei Zustandsänderungen etwas sendet?

Siehe meinen letzten Post von gestern. Ich glaub, soweit sind wir noch nicht.

Im Prinzip haben wir aktuell ein Tasterinterface, aber Du möchtest (wie ich) ein Schalterinterface. Das wird spannend! Offenbar ist aber die CCU2 aktuell selbst noch nicht in der Lage, Zitat aus dem Beileger:

Zitat"Die volle Funktionalität für die Betriebsmodeeinstellung steht in der CCU2 ab Version 2.11.x zur Verfügung (Voraussichtlicher Release-Termin ist November 2014".

Wenn Martin (oder jemand anderes) herausbekommt, welches Register da wie zu programmieren ist, hätten wir's...

NACHTRAG @AHA1805: Guckst Du mal in die Readings, ob Dein EM-8 wirklich gepairt ist (und nicht nur FHEM bekannt)? So lange rückt das Modul nämlich keine Configs raus. Ich musste mein Modul auch zweimal pairen...

Zitat von: Pfriemler am 04 Oktober 2014, 16:11:04

NACHTRAG @AHA1805: Guckst Du mal in die Readings, ob Dein EM-8 wirklich gepairt ist (und nicht nur FHEM bekannt)? So lange rückt das Modul nämlich keine Configs raus. Ich musste mein Modul auch zweimal pairen...

Danke Pfriemler,

ja es war richtig gepaired,
weiß jedoch nicht warum es beim ersten mal nicht funktionierte.
Irgendwie hatte das Device Anfangs Schwierigkeiten  ;).
Hoffe, dass die Funktion mit dem Schalterinterface bald geknackt wird :)

     2014-10-04 16:03:27   CommandAccepted yes
     2014-10-04 16:03:27   D-firmware      1.0
     2014-10-04 16:03:27   D-serialNr      LEQ1113776
     2014-10-04 15:55:12   PairedTo        0x1399AE
     2014-10-04 15:34:46   R-localResDis   off
     2014-10-04 15:34:46   R-lowBatLimit   0 V
     2014-10-04 15:35:44   R-pairCentral   0x1399AE
     2014-10-04 15:34:46   R-transmDevTryMax 3
     2014-10-04 15:55:12   RegL_00:          02:01 05:00 0A:13 0B:99 0C:AE 12:00 14:03 18:00  00:00
     2014-10-04 15:59:55   battery         ok
     2014-10-04 16:03:27   sabotageAttack  ErrIoAttack cnt:12
     2014-10-04 16:03:26   state           CMDs_done


Gruß Hannes

ein Button hat folgende Register
list:         register | range              | peer     | description
   1: dblPress         |   0 to 1.5s        |          | time to detect double press
   1: eventFilterTime  |   0 to 7620s       |          | event filter time
   1: longPress        | 0.3 to 1.8s        |          | time to detect key long press
   1: msgScdPosA       |     literal        |          | Message for position A options:lvlNormal,noMsg
   1: msgScdPosB       |     literal        |          | Message for position B options:lvlAddStrong,lvlAdd,lvlNormal,noMsg
   1: msgScdPosC       |     literal        |          | Message for position C options:lvlAddStrong,lvlAdd,lvlNormal,noMsg
   1: msgScdPosD       |     literal        |          | Message for position D options:lvlAddStrong,lvlAdd,lvlNormal,noMsg
   1: sign             |     literal        |          | signature (AES) options:on,off
   1: transmitTryMax   |   1 to 10          |          | max message re-transmit
   4: expectAES        |     literal        | required | expect AES options:on,off
   4: peerNeedsBurst   |     literal        | required | peer expects burst options:on,off


wobei doublePress nicht implementiert ist.
msgScdPosA/B/C/D sind unklar. Sicher ist, dass man einstellen kann, welche message bei welcher Position kommt. Fraglich ist, wieviele Positionen der Schalter hat. Max könnten es 4 sein (sofern das format halbwegs stimmt).
Die "Position" könnte evtl vom Spannungslevel abhängen. Es könnte auch nur On /off sein... Spannung da/nicht da.
Es gibt noch ein weiteres Register, das bisher noch nicht genutzt wurde (0x92). Was das machen könnte ist unklar.

Ihr könnt das verändern mit
set y_Btn_01 regBulk 1: 92:<data>

Aktuell steht 23 (also 0x23) drin, dezimal 35
set y_Btn_01 regBulk 1: 92:23
ist also orginal, alles ander ist unbekannt.

Zitat von: martinp876 am 04 Oktober 2014, 18:22:24
... Die "Position" könnte evtl vom Spannungslevel abhängen. Es könnte auch nur On /off sein... Spannung da/nicht da.

Das denke ich auch. Die Eingangsbeschaltung verbal beschrieben:
- Eingänge PE0 bis PE7 des Prozessors jeweils vorgespannt mit 1M gegen +UB
- Tastereingänge (gegen Masse) ziehen die Prozessoreingänge über 1k nach GND
- normale npn-Transistoren ziehen die Prozessoreingänge parallel dazu gegen GND (E an GND, C an Prozessor)
- Basen der Transistoren mit 10k gegen "IN0" bis "IN7", Basis gegen GND mit 100k geklemmt.
Die Prozessoreingänge sind zusätzlich mit 100n und einer 3,3V-Zener gegen Spikes und Überspannungen gesichert.

So eine Beschaltung lässt keine Luft für irgendwelche Spannungswerte.
Übrigens sind die Eingänge ziemlich "saugend" (2,4mA bei 24V). Da kann man problemlos noch Vorwiderstände setzen, weil 3 µA gegen GND zu ziehen (1M an 3,3V UB) schaffen die Transis ja mit links ... ich schätze 7µA (erzeugen 0,7V am 100k-Basisklemmwiderstand) reichen zum Ansteuern aus.
Es sei denn, der Prozessoreingang liefert auch irgendwelchen Saft.

Dann machen wir uns mal mutig an das Programmieren der 0x92 ...

Übrigens fehlt uns neben dem Betriebsmodus noch ein Flag zum Einschalten der platineneigenen LED bei Tastenbetätigungen. Derzeit leuchtet die LED nur bei Aktionen mit dem aufgelöteten Konfigurationstaster. Für die HM-typische Quittungs-LED sind hingegen zwei Extra-Anschlüsse herausgeführt, die immer funktionieren.

Da ich noch neu bin beim Ausforschen von HM: Ist es denkbar, dass jemand mit einer CCU2 das Teil mal richtig konfiguriert und FHEM dabei die Messages mitloggt, um die Register zu sehen, die manipuliert werden? Oder wird das anderweitig längst so gemacht ...?

led-register ist eingebaut.
batterie-level ist angepasst (0-15V)

im XML Version 15 ist der em drin. Es gibt keine Infos zu "event mit value". Nach diesen infos kann der em nur an/aus melden. Auch das Register 92 ist nicht vermerkt. Somit ist es aktuell durch HM-SW nicht steuern.

Also beim Rumprobieren mit msgScdPosA/B/C/D habe ich bisher keine Veränderung am Verhalten entdecken können.

Jetzt tut sich was: Wenn man das Register 92 auf 0x21 oder 0x22 setzt, bekommt man den toggle Modus. Jede ansteigende und abfallende Flanke erzeugt ein Short Signal. Dabei wird die eventFilterTime berücksichtigt, d.h. innerhalb der Filtertime wird nicht neu gesendet.

Ist das Register 92 auf Null gesetzt, wird nchts mehr gesendet.

Die register msg steuern welche msg zu welchem ereigniss gesendet wird. Man kann bei einem 3state sensor festlegen, wann 0,100 oder 200 gesendet wird. Das sind 0,50 oder100 %
Damit kann man offen bei fenster zu schicken. Wenn man will

Das register 92 solltest du ggf als bitfeld betrachten. 21=00010101bin, 22=00010110
Probiere es also mit 1, 2 oder 0. Es koennen natuerlich auch gruppen der 8 bits eine kombination bilden. Sehr aufwendige tests ohne anhaltspunkt
Wenn du ergebnisse hast kann ich versuchen es auf andere register zu mappen um die idee von hm zu erraten

Die Woche ist die Hölle bei mir, danke an MEitelwein. Wie war das 0x92 default? Ansonsten kann ich Martin nur recht geben, das Durchprobieren ist nervig. ledMode geht schon mal prima übrigens.

Auf Bitmap bin ich auch gleich gekommen - sonst wäre ich wohl jetzt noch am Probieren...

Der default war 0x23 = 00100011

Der Schaltmodus verändert sich über die 2 niedrigsten Bits (0x21 und 0x22) in den Fensterkontaktmodus - scheinbar ohne Unterschied. Mehr habe ich allerdings auch nicht ausprobiert.

MEitelwein, kannst Du mir mal kurz flüstern, wie Du an das default gekommen bist? Ich saß gestern abend in meinem täglichen 10-Minuten-Slot für FHEM (von denen ich in acht endlich den %$"&§!"!-RT-DN gepairt bekommen habe) wie der Ochs vor den Befehlen und verstand nur Bahnhof. Stichpunkte reichen.

Ich muss nochmal der Vollständigkeit nachhaken:
1. Das Register setzt Du bei einem Channel? D.h. der Modus kann pro Kanal festgelegt werden? Das wäre ja toll.
2. Hast Du jetzt wirklich den Fensterkontaktmodus oder einen Toggle? Es gibt ja bereits ein Schalter-Interfaces von eQ3, welches bei einer Schaltezustandsänderung ein Short sendet (etwa um damit Schalter zu toggeln) - ideal um bestehende Wechselschalter in eine HM-basierte getoggelte Wechselschaltung umzusetzen. Daneben aber auch das Schalterinterface, welches bei Zustandsänderung den Zustand sendet. Das könnte der Unterschied zwischen 0x21 und 0x22 sein. Guckst Du mal auf die Antworten, oder sind die wirklich gleich?
x23 wäre dann der Remote-Modus (aktiver Eingang sendet Shorts und Longs).
Schaltet auch x20 den Kanal ganz ab?

Ich habe noch ein wenig rumprobiert .

Der Modus kann pro Kanal festgelegt werden.
0x21 ist der Togglemodus
0x22 ist der Fensterkontaktmodus

Wenn ein Peering auf ein virtuelles Gerät gemacht wird, dann läßt sich der Zustand der Kontakte auch im Fhem darstellen und abfragen.

set xy_01 regBulk 1: 92:22

define virt_Btn_01 CUL_HM ABC123
set virt_Btn_01 virtual 2

set xy_01 peerChan 1 virt_Btn_01 single

Gruß Ralf

Zitat von: Ralf9 am 12 Oktober 2014, 02:04:39
Ich habe noch ein wenig rumprobiert .

Der Modus kann pro Kanal festgelegt werden.
0x21 ist der Togglemodus
0x22 ist der Fensterkontaktmodus

Wenn ein Peering auf ein virtuelles Gerät gemacht wird, dann läßt sich der Zustand der Kontakte auch im Fhem darstellen und abfragen.

set xy_01 regBulk 1: 92:22

define virt_Btn_01 CUL_HM ABC123
set virt_Btn_01 virtual 2

set xy_01 peerChan 1 virt_Btn_01 single

Gruß Ralf

Hallo Ralf,

Dass habt ihr ja schnell geknackt  :D
Bei wird aber nichts an dem virtuellen Button angezeigt.
Es steht auf beiden Kanälen ein ???.

An was könnte das liegen?

SCHÖNE GRÜßE
Hannes

Zitat von: AHA1805 am 13 Oktober 2014, 21:36:11
Bei wird aber nichts an dem virtuellen Button angezeigt.
Es steht auf beiden Kanälen ein ???.

evtl stimmen beim peerChan die Namen der channel nicht.
set name_channel_a peerChan 1 virt_Btn_01_Btn1 single


Da beim Fensterkontaktmodus nur die Zustandsänderungen übertragen werden und nicht der Zustand, ist er für mich nur eingeschränkt brauchbar.
Wenn z.B. während eines Stromausfalls oder während fhem nicht läuft, sich der Zustand eines Kontaktes ändert, stimmt in fhem die Anzeige des Zustandes nicht mehr.

Ich möchte gerne in Fhem den "virtActState" umschalten können. Ich habe es durch anpassen des webCmd versucht:
"attr virt_Btn_01_Btn1 webCmd on:off"
Damit funktioniert es aber nicht. Beim klicken auf on oder off kommt nur eine Fehlermeldung.

Gruß Ralf

Zitat von: Ralf9 am 13 Oktober 2014, 23:11:51
evtl stimmen beim peerChan die Namen der channel nicht.
set name_channel_a peerChan 1 virt_Btn_01_Btn1 single

Wieso 1? Das peeren eines Remote-Channels (nicht einer Tastengruppe des Remote-Devices) funktioniert doch mit 0, also set name_channel_a peerChan 0 virt_Btn_01_Btn1 single ...?

Folgende neue Erkenntnisse:
1. Das peeren eines Channels vom EM-8 mit einem virtuellen Button einer vccu klappt prima (bei mir also bspw. set EM8_Btn_08 peerChan 0 vccu_Btn8). Die Quittung kommt, allerdings zeigt der Button nichts außer "???". Das ist bei mir also genauso.
Wenn ich aber mit einem virtuellen Button eines HM-Dummys peere, zeigt der so eine Art Zustand (ON bzw. OFF). Ich glaub, das ist so normal.

2. Ich habe zur besseren Untersuchung der Register-92-Modi mal mit einem Kanal eines Re-8 gepeert.
Der richtige Befehl zum Setzen des Registers ist übrigens bswp. "set EM8_Btn_08 regBulk 1 92:23" (also kein : nach der 1, sondern zwischen 92 und dem zu schreibenden Wert)
Gesetzt, CLOSE ist der geschlossene und OPEN der offene Tastereingang, dann passiert folgendes
- 23: CLOSE kurz, OPEN: (wie eine kurze Tastenbetätigung): sendet "short", Aktor toggelt bei jeder Aktion
- 23: CLOSE lang (lange Tastenbetätigung): sendet "long", aber - obacht! - Aktor toggelt selbständig hin und her.
         Zu untersuchen wäre, ob das die Standardaktion des Aktors bei "long" ist. Der o.g. virtuelle Button eines HM-Dummies läuft übrigens parallel dazu ein/aus
- 22: CLOSE bzw. OPEN (beliebige Dauer): Beim Zustandswechsel sendet der EM-8 nur kurz, der Aktor toggelt bei jedem Telegramm.
- 21: CLOSE bzw. OPEN (beliebige Dauer): Auch hier sendet der EM-8 nur kurz, der Aktor toggelt aber nur beim Öffnen-Telegramm.

Wie Ralf9 also sagt, wird's so kein echtes Kontaktinterface. 22 wäre dann ein Schalterinterface (jede Schaltzustandsänderung ändert), 21 eher ein Tasterinterface - oder s.u.. Der Unterschied zum Remote-Modus (23) wäre dann, dass die Tastenbetätigung beliebig lang sein darf, ohne dass der EM-8 "long"s sendet. Sinnvollerweise würde man dann aber einen Öffner-Taster nehmen müssen (also normally closed), damit das Aktionstelegramm zu Beginn der Betätigung (also beim Öffnen des Kontakts) gesendet wird und nicht erst beim Loslassen.

Wieso der EM-8 dann überhaupt was sendet, wenn der Aktor nicht reagiert, verstehe ich jetzt noch nicht. Idee: Wenn ich bspw. einen Neigungssensor mit einem Aktor peere, dann toggelt der Aktor genauso wie in der (21): Erst ein vollständiges Kippeln schaltet den Aktor. Der Neigungssensor überträgt bei seinen Telegrammen Werte - wenn man den Aktor nun auf die Werte reagieren lässt, bekommt man eine echte Zustandsspiegelung. Details kann man in http://forum.fhem.de/index.php/topic,21848.msg153108.html#msg153108 (http://forum.fhem.de/index.php/topic,21848.msg153108.html#msg153108) nachlesen.

Mode (21),
mitgeloggt ein Schließen und ein Öffnen des Eingangs. Beim 2. Telegramm toggelt der Aktor. 312F44 der EM-8, 2C05AE ist der Aktor.

Zitat2014.10.21 11:58:54 1: HM-Logging gestartet...
2014.10.21 11:59:00.287 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:4E179164 d:FF r:FFD1     m:EB B441 312F44 2C05AE 087300
2014.10.21 11:59:00.566 0: HMLAN_Parse: HMLAN1 R:E2C05AE   stat:0000 t:4E1791E4 d:FF r:FFD4     m:EB 8002 2C05AE 312F44 0108000000
2014.10.21 11:59:02.900 0: HMLAN_Send:  HMLAN1 I:K
2014.10.21 11:59:02.910 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:HEQ0136973 d:141B13 O:1411AB t:4E179BA8 IDcnt:0020
2014.10.21 11:59:04.296 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:4E17A110 d:FF r:FFD4     m:EC B441 312F44 2C05AE 0874C8
2014.10.21 11:59:04.456 0: HMLAN_Parse: HMLAN1 R:E2C05AE   stat:0000 t:4E17A18F d:FF r:FFD4     m:EC 8002 2C05AE 312F44 0108C80000
2014.10.21 11:59:07.892 1: HM-Logging gestoppt

Wenn ich das richtig interpretiere, sendet der EM-8 in diesem Modus einen Wert 0 beim Schließen und 200 (hex C8) beim Öffnen des Kontaktes. 73 und 74 ist ein fortlaufender Zähler?
Das wäre dann unser Kontaktinterface. Wenn Martin uns das Device (später) mal so programmiert wie bswp. den Neigungssensor, hätten wir eine direkt auszuwertende Zustandsmeldung.

Im Modus (22):

Zitat2014.10.21 12:06:45 1: HM-Logging gestartet...
2014.10.21 12:06:50.866 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:4E1EBFD8 d:FF r:FFD2     m:F1 B440 312F44 2C05AE 0877
2014.10.21 12:06:51.116 0: HMLAN_Parse: HMLAN1 R:E2C05AE   stat:0000 t:4E1EC058 d:FF r:FFD4     m:F1 8002 2C05AE 312F44 0108C80000
2014.10.21 12:06:54.776 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:4E1ECF1F d:FF r:FFD4     m:F2 B440 312F44 2C05AE 0878
2014.10.21 12:06:54.938 0: HMLAN_Parse: HMLAN1 R:E2C05AE   stat:0000 t:4E1ECF9E d:FF r:FFD4     m:F2 8002 2C05AE 312F44 0108000000
2014.10.21 12:06:56.735 1: HM-Logging gestoppt

sendet der EM-8 nur 08, gefolgt vom Counter, aber ohne Wert.

Nun habe ich den EM-8 wieder auf (21) gesetzt und am Aktor Re-8 testweise das Register shCtOff (für diesen peer) von "geLo" auf "ltLo" gesetzt, siehe den Neigungssensorthread aus dem vorigen Post.
Und siehe da: Ganz egal, wie ich händisch den Aktor toggle: Beim Schließen des Tastereingangs geht er an, beim Öffnen aus.
Fertig ist das Kontaktinterface. Martin, was brauchst Du noch?

Zitat von: Pfriemler am 21 Oktober 2014, 12:21:43
Martin, was brauchst Du noch?

Das war natürlich nicht bös oder drängelnd gemeint. Ich meinte damit, dass wir jetzt die wesentlichen Zustände zusammen haben - falls noch was fehlt, müssten wir's noch nachtesten. Natürlich könnte man nun noch auf die Unterstützung durch die CCU2 warten und die Einstellungen, die diese dann vornimmt, mal mitsniffen - aber für den Anfang...
Ein Versuch der Zusammenfassung:
Liste 1 Register 92 Wert:
23: Tastereingänge wie Buttons einer Fernbedienung, Verhalten ähnlich HM-PBI4-FM - nein, stimmt noch nicht ganz, das Toggeln des Re-8 muss ich noch untersuchen.
22: Anschluss von Schaltern, Verhalten ähnlich HM-SWI-3-FM (?)
21: Anschluss von Schaltern, Verhalten wie HM-SCI-3-FM (?), bzw. Neigungssensor, Tür/Fensterkontakte, ...

Sendet das SCI-3-FM auch Trigger mit Werten? Jawohl, so ist es. Hier für Kanal 1 eines SCI-3 (in den obigen Beispielen zum EM-8 hatte ich Kanal 8 verwendet)

Zitat
2014.10.21 15:48:54.891 0: HMLAN_Parse: HMLAN1 R:E2447B5   stat:0000 t:4EEA15AD d:FF r:FFC4     m:57 A441 2447B5 1411AB 010A00
2014.10.21 15:48:57.390 0: HMLAN_Parse: HMLAN1 R:E2447B5   stat:0000 t:4EEA1F71 d:FF r:FFC4     m:58 A441 2447B5 1411AB 010BC8

Außerdem können SCI-3-FM & Co doch ab Werk auch einen Aktor so anlernen, dass er den Zustand spiegelt... wie man das in FHEM peert, weiß ich gerade nicht, geht aber bestimmt auch schon.

Genialerweise müsste FHEM dann nach Kenntnis des Registers die entsprechenden Internals und Attribute anbieten, auf jeden Fall wäre aber "setMode" oder ähnliches mit Klarschriftangabe statt der Registermanipulation hilfreich.

@Martin als Mod: Ist es möglich, den Betreff des Freds mal zu ändern - das mit den analogen Eingängen war ja ein Missverständnis des TE.

Also ich kann Entwarnung geben für value 23: ungepeert fängt FHEM ganz normale Long X (heraufzählend) ab.
Mit dem Re-8 bleibt das seltsame Verhalten. Aber das ist hier offtopic.


Jetzt warten wir auf das Einbauen durch einen kompetenten FHEM-Programmierer, oder?

also lasst mich einmal zusammenfassen, was ich mitgeommen habe:
Mode 21 simuliert einen "sensor". der liefert zustände mit wie offen und zu in Form von 0 und 200 (100%). Was wann kommt kann man meist drehen. er sendet wahrscheinlich nur "short"

mode 22 ist dann ein typischer schalter. Der sendet keine Werte mit, sollte aber long und short können.

Also test: jeweils mit mode 21 und 22 einmal lange und kurz drücken (und loggen).

Das mit 23 habe ich nicht verstanden. Wie sehen die logs aus? ist da ein unterschied zu 21?

Ich vermute, dass nur Bit 0 zwischen "schalter" und "sensor" unterscheidet.

Danke für Meldung ... Jein ... also ich erklärs gern nochmal, wie ich es sehe:

ZitatMode 21 simuliert einen "sensor". der liefert zustände mit wie offen und zu in Form von 0 und 200 (100%). Was wann kommt kann man meist drehen. er sendet wahrscheinlich nur "short"

Genau. Kurze einmalige Telegramme bei jeder Zustandsänderung am Kontakt, wenn Du das meinst, allerdings mit einem Wert hintendran - erinnert mich stark an den SCI-3, der ganz offenbar in gleicher weise auch 0 (closed) bzw. 200 (open) sendet. Drehen brauchst Du da nix - die Auswertung wäre dann identisch zum SCI-3.

Zitatmode 22 ist dann ein typischer schalter. Der sendet keine Werte mit, sollte aber long und short können.

Nein, auch der sendet nur kurze Telegramme bei jeder Zustandsänderung, aber ohne Wert. Entspricht im Verhalten damit dem SWI-3, welches bei jeder Zustandsänderung ein "short" sendet - von eQ3 z.B. für Wechselschaltungen-Ersatz empfohlen - jede Schalterzustandsänderung kann somit einen Aktor toggeln, aber der Zustand des Schalters wird nicht übertragen.

ZitatDas mit 23 habe ich nicht verstanden. Wie sehen die logs aus? ist da ein unterschied zu 21?

23, also der Defaultwert, ist eine klassische Fernbedienung - nur in diesem Modus sendet das Teil wiederholte Trigger, und wenn ich das richtig verstanden habe, long-Trigger, inkl. einem LongRelease, wenn der Kontakt wieder geöffnet wird.

"Kontakt" bezieht sich dabei allerdings auf die Tastereingänge des Moduls (für Taster gegen GND) - das Anlegen einer Spannung an die Spannungseingänge ist schaltungs- und auswertungstechnisch identisch zum Schließen des Tasterkontakts, siehe ganz anfangs im Fred.

ZitatIch vermute, dass nur Bit 0 zwischen "schalter" und "sensor" unterscheidet.

Nö. Binär ausgedrückt (die Bedeutung der ersten Bits ist unklar, haben wir nicht untersucht)
(000101)01 0010 0001 = Schalterzustand
(000101)10 0010 0010 = Schaltersensor
(000101)11 0010 0011 = Fernbedienung/Taster
(edit: fälschlich dezimal > binär statt hex > binär, korrigiert ... )
Logs habe ich in den Beiträgen zuvor und auch in Thread zum Re-8 gepostet (das ist aber eine andere Baustelle).

'tschulljung, das Log zum Remotemode (23) war ich schuldig geblieben, im Re-8-Fred sind mehr die meiner RC-4.

hier nochmal nachgeschoben das Verhalten des Moduls (312F44) im Modus (23), gepeert mit einem UP-Dimmer (26FC58):
2014.10.24 22:09:02 1: HM-Logging gestartet... (Die Antworten vom Dimmer an die vccu sind hier mit dabei))
2014.10.24 22:09:07.588 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FB9D35A d:FF r:FFD7     m:21 A040 312F44 26FC58 460F #short
2014.10.24 22:09:07.717 0: HMLAN_Parse: HMLAN1 R:E26FC58   stat:0000 t:5FB9D3DA d:FF r:FFC1     m:21 8002 26FC58 312F44 0101000051A4 #ack
2014.10.24 22:09:09.956 0: HMLAN_Send:  HMLAN1 I:K
2014.10.24 22:09:09.965 0: HMLAN_Parse: HMLAN1 R:E26FC58   stat:0000 t:5FB9DC9E d:FF r:FFC1     m:22 A410 26FC58 1411AB 060100008000
2014.10.24 22:09:10.225 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:HEQ0136973 d:141B13 O:1411AB t:5FB9DCA7 IDcnt:0020
2014.10.24 22:09:17.565 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FB9FA54 d:FF r:FFD8     m:22 A440 312F44 26FC58 0610 # short
2014.10.24 22:09:17.692 0: HMLAN_Parse: HMLAN1 R:E26FC58   stat:0000 t:5FB9FAD4 d:FF r:FFC0     m:22 8002 26FC58 312F44 010100004DA4
2014.10.24 22:09:20.863 0: HMLAN_Parse: HMLAN1 R:E26FC58   stat:0000 t:5FBA0737 d:FF r:FFC0     m:23 A410 26FC58 1411AB 060100008000
2014.10.24 22:09:24.723 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA164C d:FF r:FFD7     m:23 A440 312F44 26FC58 0611 #short
2014.10.24 22:09:24.851 0: HMLAN_Parse: HMLAN1 R:E26FC58   stat:0000 t:5FBA16CC d:FF r:FFC1     m:23 8002 26FC58 312F44 010100004EA4
2014.10.24 22:09:28.452 0: HMLAN_Parse: HMLAN1 R:E26FC58   stat:0000 t:5FBA2292 d:FF r:FFC1     m:24 A410 26FC58 1411AB 060100008000
2014.10.24 22:09:34.544 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA3CAA d:FF r:FFD8     m:24 A440 312F44 26FC58 0612 #short
2014.10.24 22:09:34.672 0: HMLAN_Parse: HMLAN1 R:E26FC58   stat:0000 t:5FBA3D2A d:FF r:FFC1     m:24 8002 26FC58 312F44 010100005CA4
2014.10.24 22:09:34.963 0: HMLAN_Send:  HMLAN1 I:K
2014.10.24 22:09:34.972 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:HEQ0136973 d:141B13 O:1411AB t:5FBA3E5A IDcnt:0020
2014.10.24 22:09:36.009 0: HMLAN_Parse: HMLAN1 R:E283AEA   stat:0000 t:5FBA4263 d:FF r:FFBC     m:CC 845E 283AEA 000000 8075C600000000000922FE
2014.10.24 22:09:37.467 0: HMLAN_Parse: HMLAN1 R:E26FC58   stat:0000 t:5FBA4815 d:FF r:FFC0     m:25 A410 26FC58 1411AB 060100008000
2014.10.24 22:09:41.626 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA5855 d:FF r:FFDA     m:25 8440 312F44 26FC58 4613 #hier sendet er long, wie sich das gehört
2014.10.24 22:09:41.898 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA5965 d:FF r:FFDA     m:26 8440 312F44 26FC58 4613
2014.10.24 22:09:42.170 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA5A75 d:FF r:FFDA     m:27 8440 312F44 26FC58 4613
2014.10.24 22:09:42.442 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA5B85 d:FF r:FFDA     m:28 8440 312F44 26FC58 4613
2014.10.24 22:09:42.714 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA5C95 d:FF r:FFDA     m:29 8440 312F44 26FC58 4613
2014.10.24 22:09:42.986 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA5DA5 d:FF r:FFDA     m:2A 8440 312F44 26FC58 4613
2014.10.24 22:09:43.258 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA5EB5 d:FF r:FFDA     m:2B 8440 312F44 26FC58 4613
2014.10.24 22:09:43.529 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA5FC5 d:FF r:FFDA     m:2C 8440 312F44 26FC58 4613
2014.10.24 22:09:43.801 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA60D5 d:FF r:FFDA     m:2D 8440 312F44 26FC58 4613
2014.10.24 22:09:44.073 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA61E5 d:FF r:FFD8     m:2E A040 312F44 26FC58 4613 # und das müsste das LongRelease sein...
2014.10.24 22:09:44.202 0: HMLAN_Parse: HMLAN1 R:E26FC58   stat:0000 t:5FBA6265 d:FF r:FFC1     m:2E 8002 26FC58 312F44 0101000051A4 #ack
2014.10.24 22:09:46.570 0: HMLAN_Parse: HMLAN1 R:E26FC58   stat:0000 t:5FBA6BA6 d:FF r:FFC0     m:2F A410 26FC58 1411AB 060100008000 #meldung an vccu
2014.10.24 22:09:48.594 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA738E d:FF r:FFDA     m:2F 8440 312F44 26FC58 4614 #long again ...
2014.10.24 22:09:48.865 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA749D d:FF r:FFDA     m:30 8440 312F44 26FC58 4614
2014.10.24 22:09:49.137 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA75AD d:FF r:FFDA     m:31 8440 312F44 26FC58 4614
2014.10.24 22:09:49.410 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA76BE d:FF r:FFDA     m:32 8440 312F44 26FC58 4614
2014.10.24 22:09:49.682 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA77CF d:FF r:FFDA     m:33 8440 312F44 26FC58 4614
2014.10.24 22:09:49.954 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA78DF d:FF r:FFDA     m:34 8440 312F44 26FC58 4614
2014.10.24 22:09:50.226 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA79EF d:FF r:FFDA     m:35 8440 312F44 26FC58 4614
2014.10.24 22:09:50.497 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA7AFF d:FF r:FFDA     m:36 8440 312F44 26FC58 4614
2014.10.24 22:09:50.770 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA7C0F d:FF r:FFDA     m:37 8440 312F44 26FC58 4614
2014.10.24 22:09:51.041 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA7D1F d:FF r:FFD8     m:38 8440 312F44 26FC58 4614
2014.10.24 22:09:51.313 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:5FBA7E2F d:FF r:FFD8     m:39 A040 312F44 26FC58 4614 # ... release
2014.10.24 22:09:51.441 0: HMLAN_Parse: HMLAN1 R:E26FC58   stat:0000 t:5FBA7EAF d:FF r:FFC0     m:39 8002 26FC58 312F44 0101000051A4 #ack
2014.10.24 22:09:53.272 0: HMLAN_Parse: HMLAN1 R:E26FC58   stat:0000 t:5FBA85D5 d:FF r:FFC1     m:3A A410 26FC58 1411AB 060100008000 #vccu
2014.10.24 22:09:56.437 1: HM-Logging gestoppt

Sieht für mich sauber und lupenrein aus wie eine Fernbedienung/Taster.

Zitat(000101)01 = Schalterzustand
(000101)10 = Schaltersensor
(000101)11 = Fernbedienung/Taster

geht ihr dezimal ein? ich dachte hex. Jedenfalls bit 0/1 bleiben gleich.

mode 21 sendet wie ein 3-state sensor eine 0x41 mit dem zugehörigen statuswert.
Mode 22 sendet einen trigger, der dem von 23 identisch ist. Wo siehst du einen Unterschied?

Dein erster short ist eigentlich ein long release. warst du etwas lang auf der taste? Die nächsten short stimmen.

Mode 23 ist somit identisch zu mode22 (so du mir den Unterschied in den messages nicht klar machen kannst). Zumindest bei den aktuellen Versuchen.

Dein test von Mode21/22 waren zu einem burst-device gerichtet - mache es einmal ohne burst.

Meine Interpretation
das Feld ist min 2 Bit lang und hat damit min 4 werte
0:(mode 20 - keine logs vorhanden) vermutlich "remote-like"
1:(mode 21) "sensor-like"
2:(mode 22) "remote-like". Ist default wert
3:(mode 23) "remote-like". evtl. nicht freigegeben, macht halt zufällig "2"

Nein, Entschuldigung, Blödsinn, die Bit-Umsetzung war falsch, 0x21 ist natürlich 0010 0001 usw. das ändert aber prinzipiell nichts an den letzten beiden Bits, die sind (zufälligerweise) in beiden Lesarten identisch, wenn ich gerade richtig nachgerechnet habe.

Ich meinte immer die Hex-Werte.

Zitatmode 21 sendet wie ein 3-state sensor eine 0x41 mit dem zugehörigen statuswert.

In "EB B441 312F44 2C05AE 087300" (ein Long vom EM-8 an den Re-8, s.o., Mode 0x21) entdecke ich nur eine 0x41, links markiert.
Ist das nach Deiner Lesart Byte 3 oder Byte 2?

ZitatMode 22 sendet einen trigger, der dem von 23 identisch ist.

... hm, stimmt! in "F1 B440 312F44 2C05AE 0877" (dito EM-8 an Re-8, Mode 0x22) steht an der Stelle eine 0x40, und es fehlt hinten im Telegramm der Wert". Im Modus 0x23 ist das auch ein 0x40, also identischer Aufbau.

Logisch sollte ja auch kein Unterschied zwischen den beiden Short-Triggern sein (oder ich habe die Funktionsweise eines SWI-3 nicht verstanden).
Praktisch ist der Unterschied zwischen den Modi 0x22 und 0x23, dass der EM-8 in Modus 0x22 gar keine Longs sendet (das macht er nur in 0x23), sondern nur einen Trigger zu Beginn der Schaltzustandsänderung. Der Unterschied zwischen einem SWI-3 und einer Fernbedienung sollte auch nicht anders sein ... ?

Oder anders gesagt: 0x21 sendet States mit Wert beim Öffnen und Schließen, 0x22 sendet nur shorts (dies aber auch beim Öffnen des Kontakts), 0x23 sendet shorts und longs beim Schließen (und dann logischerweise eine ACK-Aufforderung beim letzten Long, wenn es sowas wie ein LongRelease gar nicht gibt ...)

So, noch ein Bug vom EM-8, wie ich vermute ... habe ich in http://forum.fhem.de/index.php/topic,25719.msg211496.html#msg211496 (http://forum.fhem.de/index.php/topic,25719.msg211496.html#msg211496) schon vermutet und in http://forum.fhem.de/index.php/topic,25719.msg210958.html#msg210958 (http://forum.fhem.de/index.php/topic,25719.msg210958.html#msg210958) zuerst bemängelt:

Bei Betrieb in Modus 0x23 und dem Senden an gepeerte Burst-Devices sendet ein EM-8 bei "langen Tastendrücken" nach dem Erhalt der Quittung vom Burst-Empfänger weitere Longs mit fortlaufender Tastendrucknummer, was den Empfänger dazu veranlasst, fleißig ein- und auszuschalten in Folge. Wie sich andere Sender da verhalten, kann in den Links nachgelesen werden.

Nachdem ich nun beim Re-8 schon Abbitte getan habe, weil eine RC-4 sich gegenüber einem HM-LC-SW4-BA-PCB genau so verhält wie mit dem Re-8,
hier nun das Gespräch zwischen dem EM-8 und eben dem HM-LC-SW4-BA-PCB ... und das toggelt genauso bei langem Tastendruck wie der Re-8 ...

Damit ist für mich das EM-8 schuldig ....


2014.10.25 16:11:14.095 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:6398A818 d:FF r:FFD2     m:4C B440 312F44 529E82 0512    # short mit Burst und ACK
2014.10.25 16:11:14.373 0: HMLAN_Parse: HMLAN1 R:E529E82   stat:0000 t:6398A898 d:FF r:FFDC     m:4C 8002 529E82 312F44 0103C80000 # und an, wie sichs gehört
2014.10.25 16:11:17.850 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:6398B6C4 d:FF r:FFD2     m:4D B440 312F44 529E82 0513   # short mit Burst und ACK
2014.10.25 16:11:18.034 0: HMLAN_Parse: HMLAN1 R:E529E82   stat:0000 t:6398B743 d:FF r:FFDC     m:4D 8002 529E82 312F44 0103000000 - und aus.
2014.10.25 16:11:22.323 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:6398C83E d:FF r:FFD2     m:4E B440 312F44 529E82 4514    # hier kommt der Long
2014.10.25 16:11:22.511 0: HMLAN_Parse: HMLAN1 R:E529E82   stat:0000 t:6398C8BD d:FF r:FFDC     m:4E 8002 529E82 312F44 0103C80000  und da ist das ACK
2014.10.25 16:11:22.865 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:6398CA5C d:FF r:FFD2     m:4F B440 312F44 529E82 4515   # und hier sendet EM-8 wieder ein Long
# mit neuer Tastendrucknummer, obwohl ich die ganze Zeit ...
2014.10.25 16:11:23.055 0: HMLAN_Parse: HMLAN1 R:E529E82   stat:0000 t:6398CADC d:FF r:FFDC     m:4F 8002 529E82 312F44 0103000000 #aus
2014.10.25 16:11:23.408 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:6398CC7B d:FF r:FFD2     m:50 B440 312F44 529E82 4516
2014.10.25 16:11:23.592 0: HMLAN_Parse: HMLAN1 R:E529E82   stat:0000 t:6398CCFA d:FF r:FFDC     m:50 8002 529E82 312F44 0103C80000 # an
2014.10.25 16:11:23.950 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:6398CE99 d:FF r:FFD2     m:51 B440 312F44 529E82 4517
2014.10.25 16:11:24.136 0: HMLAN_Parse: HMLAN1 R:E529E82   stat:0000 t:6398CF18 d:FF r:FFDC     m:51 8002 529E82 312F44 0103000000 #aus
2014.10.25 16:11:24.494 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:6398D0B7 d:FF r:FFD2     m:52 B440 312F44 529E82 4518
2014.10.25 16:11:24.676 0: HMLAN_Parse: HMLAN1 R:E529E82   stat:0000 t:6398D137 d:FF r:FFDC     m:52 8002 529E82 312F44 0103C80000 #an
2014.10.25 16:11:25.035 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:6398D2D6 d:FF r:FFD2     m:53 B440 312F44 529E82 4519
2014.10.25 16:11:25.218 0: HMLAN_Parse: HMLAN1 R:E529E82   stat:0000 t:6398D355 d:FF r:FFDC     m:53 8002 529E82 312F44 0103000000 #aus
2014.10.25 16:11:25.577 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:6398D4F4 d:FF r:FFD2     m:54 B440 312F44 529E82 451A
# ... bis hierher gar nicht von der Taste heruntergegangen bin.
2014.10.25 16:11:25.761 0: HMLAN_Parse: HMLAN1 R:E529E82   stat:0000 t:6398D573 d:FF r:FFDC     m:54 8002 529E82 312F44 0103C80000 # letztes ACK, bleibt an.


Macht das Sinn, das eQ3 mal ins Poesiealbum zu schreiben?

Zitatas ändert aber prinzipiell nichts an den letzten beiden Bits

klar - wie gesagt.

ZitatIst das nach Deiner Lesart Byte 3 oder Byte 2?

2. Byte. Lesart HM (und allgemein in der Informatic)

ZitatLogisch sollte ja auch kein Unterschied zwischen den beiden Short-Triggern sein (oder ich habe die Funktionsweise eines SWI-3 nicht verstanden).

der trigger ist der gleiche. Schön wäre, wenn der SWI eine 41 schicken würde und dabei "offen" und "zu" signalisiert. Habe keinen zum testen- ich denke aber logs gesehen zu haben, in denen 40 geschickt wird. m.e. ungeschickt von HM - aber ein fakt (oder du schickst einmal logs und wiederlegst es).

ZitatPraktisch ist der Unterschied zwischen den Modi 0x22 und 0x23, dass der EM-8 in Modus 0x22 gar keine Longs sendet (das macht er nur in 0x23), sondern nur einen Trigger zu Beginn der Schaltzustandsänderung

wenn du das sagst... gesehen habe ich es nicht. gesehen habe ich nur logs, die ein burst device ansprechen. kannst du die Aussage untermauern mit einem Log an ein non-burst device?

Zitat
Der Unterschied zwischen einem SWI-3 und einer Fernbedienung sollte auch nicht anders sein ... ?

hm - könnte sein. Ein SWI schickt ein short gemäß remote beim eintreten des Device.
Ich würde dann nie einen SWI mode einsetzen (wenn das so ist) sondern immer eine sensor mode. Da bekomme ich den Wert kostenlos dazu und kann - wenn ich will - diesen auswerten. Meinen Aktor muss ich darauf vorbereiten.

Ja, ich denke auch, dass dies im EM ein Bug ist.
generell halte ich das Verhalten der RC-4 auch nicht für sinnvoll im Zusammenhang mit burst. Aber der EM ist schlimmer
Warum nicht HM anschreiben

ZitatSchön wäre, wenn der SWI eine 41 schicken würde und dabei "offen" und "zu" signalisiert

Nein, denn genau dafür gibt es ja den SCI. Schön wäre, wenn man die Modi kanalweise umschalten könnte wie jetzt beim EM-8. Aber bisher hatte eQ3 nur getrennte Devices dafür im Angebot.

ZitatHabe keinen zum testen- ich denke aber logs gesehen zu haben, in denen 40 geschickt wird. m.e. ungeschickt von HM - aber ein fakt (oder du schickst einmal logs und wiederlegst es).

Habe selbst keinen, aber ich finde es auch nicht ungeschickt. Ein SWI-3 soll einfach nichts anderes als einen Short bei Zustandswechsel senden. Das ideale Device eben für Wechselschaltungsaufgaben und unkompliziert im Handling auch ohne CCU2 & Co.

EM-8 Modus 0x22 und nur shorts ...

Zitatwenn du das sagst... gesehen habe ich es nicht. gesehen habe ich nur logs, die ein burst device ansprechen. kannst du die Aussage untermauern mit einem Log an ein non-burst device?

Das Log liefere ich noch nach, aber die Sende-LED des Moduls zeigt ja auch, dass im Modus 0x22 nur bei Zustandsänderung gesendet wird (wie auch im Modus 0x21, da aber eben mit Zustandsübermittlung), während die LED im 0x23(Remote) dauerleuchtet, solange der Kontakt geschlossen ist. Was sonst?

ZitatIch würde dann nie einen SWI mode einsetzen (wenn das so ist) sondern immer eine sensor mode. Da bekomme ich den Wert kostenlos dazu und kann - wenn ich will - diesen auswerten. Meinen Aktor muss ich darauf vorbereiten.

Das werden wohl die meisten so machen und deswegen habe ich ja auch noch kein SWI gekauft, sondern den SCI.

ZitatNein, denn genau dafür gibt es ja den SCI.

hast du sicher recht.
dennoch sehe ich die notwendigkeit eines SWI aus Protokollgründen nicht. Er sendet eine trigger 40 wenn sich etwas ändert. Long kann er nicht (da er flankengetriggert arbeitet).
Der SCI sendet eine trigger wenn sich etwas ändert (41) - auch flankengetriggert. Und er sendet noch eine Wert mit, welchen der Zustände er jetzt hat. Beide können kein Long.
Am Aktor kann es zu probleme führen (eigentlich nicht, man muss nur die ConditionTable entsprechend setzen) wenn man einen wert mitliefert. Sonst kenne ich keinen Unterschied zwischen 40 und 41 am Aktor.
=> der einzige mir ersichtliche Grund, dass der SWI 40 nutzt ist, dass es potentielle Probleme mit der CT ausschließt.
Preis ist, dass man nicht deterministisch den Schaltzustand einer wippe (oben=an, unten=auf) vorhersagen und einstellen kann. Den Wunsch hat es mindestens schon 3 mal gegeben - geht aber eben nicht.

Wir werden es natürlich als modi vorsehen, auch wenn ich es nie einstellen würde.
die ersten beiden Bits werden so einstellbar sein:
Register: triggerMode
unknown=>0,sensor=>1,switch=>2,button=>3

wäre noch cool herauszu finden, was 0 ist.

die 0x20 kennen wir noch nicht (also Bits 2-7)

msgScPosA und  msgScPosB sind dann sicher mit "sensor mode" korreliert.

Ist eingecheckt.

Hier der EM-8 (diesmal Kanal 1) im Modus 0x22 mit meinem LED-Zwischendeckendimmer:
2014.10.26 17:23:24 1: HM-Logging gestartet...
# kurze Wischer (Kontakt an/aus, nicht üblich für ein Schalterinterface, nur zur Demo:
# EM-8 sendet darauf zwei Telegramme im Abstand von 0,7s, beide wurden grün quittiert
# der kurze Abstand hat das Dimmermodul aber nur dazu gebracht, sich von ein(wie er war)  auf aus zu schalten (also kein Toggle)
2014.10.26 17:23:32.066 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:69385495 d:FF r:FFC5     m:8D A440 312F44 29765C 011F
2014.10.26 17:23:32.421 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:69385515 d:FF r:FFC0     m:8D 8002 29765C 312F44 0101BE203DC8
2014.10.26 17:23:32.744 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:69385586 d:FF r:FFC1     m:8E A440 312F44 29765C 0120
2014.10.26 17:23:33.009 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:69385606 d:FF r:FFC0     m:8E 8002 29765C 312F44 010100003D6C
2014.10.26 17:23:34.393 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:69385DAD d:FF r:FFC0     m:8F A410 29765C 1411AB 060100008000
# das gleiche noch einmal
2014.10.26 17:23:34.994 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:69386006 d:FF r:FFC5     m:8F A440 312F44 29765C 0121
2014.10.26 17:23:35.263 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:69386086 d:FF r:FFC0     m:8F 8002 29765C 312F44 010114103E00
2014.10.26 17:23:35.583 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:693860F7 d:FF r:FFC2     m:90 A440 312F44 29765C 0122
2014.10.26 17:23:35.848 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:69386177 d:FF r:FFC0     m:90 8002 29765C 312F44 0101C8003E64
2014.10.26 17:23:37.490 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:693869C6 d:FF r:FFC0     m:91 A410 29765C 1411AB 0601C80080C8
# nun ist der wieder an.
# Übrigens sendet der Dimmer in beiden Fällen seinen Status auch nochmal explizit an die Zentrale (1411AB) ... ?

# und wieder ein "Wischer"
2014.10.26 17:23:37.981 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:693869E7 d:FF r:FFC4     m:91 A440 312F44 29765C 0123
2014.10.26 17:23:38.242 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:69386AF7 d:FF r:FFC2     m:91 A040 312F44 29765C 0123
# ein resend des EM-8! allerdings mit Byte 1 A0 statt A4 ...?
2014.10.26 17:23:38.254 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:69386B77 d:FF r:FFC0     m:91 8002 29765C 312F44 0101BE203EC8
2014.10.26 17:23:38.584 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:69386BE7 d:FF r:FFC1     m:92 A440 312F44 29765C 0124
2014.10.26 17:23:38.848 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:69386C67 d:FF r:FFC0     m:92 8002 29765C 312F44 010100003E73
2014.10.26 17:23:40.027 0: HMLAN_Parse: HMLAN1 R:E23B2D0   stat:0000 t:693873B0 d:FF r:FFC4     m:9F 8410 23B2D0 1411AB 06012100 # das ist was davon unabhängiges
2014.10.26 17:23:40.588 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:693875DF d:FF r:FFC0     m:92 A410 29765C 1411AB 060100008000
# und aus.
# jetzt habe ich (schalterinterfacerichtig) den Kontakt geschlossen und gehalten:
2014.10.26 17:23:42.292 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:69387C4E d:FF r:FFC4     m:93 A440 312F44 29765C 0125 #send
2014.10.26 17:23:42.558 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:69387CCE d:FF r:FFC0     m:93 8002 29765C 312F44 010114103E00 #ack
2014.10.26 17:23:45.282 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:69388837 d:FF r:FFC0     m:94 A410 29765C 1411AB 0601C80080C8 #und wieder an die Zentrale

# und hier losgelassen:
2014.10.26 17:23:51.129 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:69389F0D d:FF r:FFC1     m:94 A440 312F44 29765C 0126
2014.10.26 17:23:51.436 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:69389F8D d:FF r:FFC0     m:94 8002 29765C 312F44 0101BE203CC8
2014.10.26 17:23:53.774 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:6938A964 d:FF r:FFC0     m:95 A410 29765C 1411AB 060100008000

# geschlossen/gedrückt gehalten ...
2014.10.26 17:23:57.161 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:6938B6A0 d:FF r:FFC2     m:95 A440 312F44 29765C 0127
2014.10.26 17:23:57.424 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:6938B720 d:FF r:FFC0     m:95 8002 29765C 312F44 010114103E00
2014.10.26 17:23:59.968 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:6938C197 d:FF r:FFC0     m:96 A410 29765C 1411AB 0601C80080C8
# losgelassen
2014.10.26 17:24:02.733 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:6938CC65 d:FF r:FFC1     m:96 A440 312F44 29765C 0128
2014.10.26 17:24:02.997 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:6938CCE5 d:FF r:FFC0     m:96 8002 29765C 312F44 0101BE203BC8
2014.10.26 17:24:05.764 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:6938D83A d:FF r:FFC0     m:97 A410 29765C 1411AB 060100008000


Also ich erkenne ACK-Anforderungen, keine Bursts, und nur Shorts. Alles wie es sein soll. Der Test mit dem ganz kurzen "Prellen" am Anfang war mal dazu gedacht zu sehen, wie das Gerät auf zwei extrem kurze Statuswechsel reagiert. Der Em-8 sendet's, der Dimmer ignorierts. Aha.

Zitatdennoch sehe ich die notwendigkeit eines SWI aus Protokollgründen nicht. Er sendet eine trigger 40 wenn sich etwas ändert. Long kann er nicht (da er flankengetriggert arbeitet).

Über den Sinn des Modus brauchen wir nicht streiten. Das Modul bietet es an, es gibt ein vergleichbares Gerät bereits, also einbauen, meine ich.

ZitatAm Aktor kann es zu probleme führen (eigentlich nicht, man muss nur die ConditionTable entsprechend setzen) wenn man einen wert mitliefert. Sonst kenne ich keinen Unterschied zwischen 40 und 41 am Aktor.

Oh doch. Vielleicht erinnerst Du Dich an meinen hier irgendwo schon zitierten Post, als ich den Neigungssensor testweise mit einem Relaimodul peerte, als Toggle. Ich war verwundert, dass das Modul nur auf jedes Kippen des Sensors reagierte (open, value 200), aber nicht auf das Geradestellen (closed, value 0). Der Aktor hat den Wert 0 nicht als gültigen Trigger erkannt (Schwelle 50) und schlicht ignoriert. Damals hat man mir geraten, ein Register im Aktor umzuprogrammieren - das meinst Du ja mit der CT-Anpassung.
Vielleicht ist der Unterschied zwischen 40 und 41 schlicht der, dass nach der 41 halt noch der Wert folgen muss ...?

ZitatPreis ist, dass man nicht deterministisch den Schaltzustand einer wippe (oben=an, unten=auf) vorhersagen und einstellen kann. Den Wunsch hat es mindestens schon 3 mal gegeben - geht aber eben nicht.

Ganz klar, aber wie gesagt - den Sinn müssen wir nicht diskutieren, wer weiß, wofür das doch nützlich sein kann.

Zitatwäre noch cool herauszu finden, was 0 ist.

Das hatte MEitelwein schon in http://forum.fhem.de/index.php/topic,27536.msg205762.html#msg205762 (http://forum.fhem.de/index.php/topic,27536.msg205762.html#msg205762) erwähnt. 0x20 schaltet den  Kanal quasi ab, er sendet keine Telegramme mehr bei Zustandsänderung. Soeben verifiziert.

Habe bei der Gelegenheit nun auch gemerkt, dass im low-Teil des Byte 9 nichts anderes als die Kanalnummer steht, oder?
m:94 A440 312F44 29765C 0126

Gedanken zur Moduseinstellung ... je Entity werden doch auch Internals angelegt und gespeichert im Statefile (?). Eigentlich genügt doch entweder das Setzen des Modus oder ein getConfig, und FHEM kann den Modus des Moduls erkennen und sich merken, ebenso sollte ein entsprechendes reading erzeugt werden, oder? Danach lässt sich dann einstellen, ob das Device "shorts/longs" (0x23, 0x22) oder einen State "open/closed" (0x21) meldet (den man dann mit Notifys wie beim SCI-3 auswerten kann).
An die restlichen Bits würde ich nicht gehen - den zwischengespeicherten Wert als Basis nehmen und nur die Bits 0+1 kippen. Einen Default von 0x23 für Register 0x92 würde ich auch nicht vorsehen - den soll ein getConfig liefern, sonst wird die Modusumstellung verweigert.
Damit kann uns dann erst mal egal sein, was der Rest von Register 0x92 ist ... oder?

Was rede ich schon wieder ... Wahrscheinlich hast Du's längst so oder besser gemacht ...

edit: ich bin gespannt, als was wir das Gerät künftig default begrüßen wollen - es ist ja im Grunde sowohl ein Remote als auch ein ThreeState, je nach Einstellung im Kanal ... das ist auch FHEM-HM-Neuland, oder?

Noch ein seltsamer Nebeneffekt: Im Moment des Umstellens von 0x23 auf 0x22 hat das Modul einen Short an den gepeerten Aktor gesendet, er hat daraufhin geschaltet. Das hatte ich tatsächlich schon öfter. Keine Ahnung, warum, ich würde es ignorieren.

ZitatDer Em-8 sendet's, der Dimmer ignorierts. Aha.

ignoriert hat er es nicht unbedingt. er hat beide empfangen.Der Dimmer ist evtl dabei eine rampe zu fahren - was soll er in diesem transienten Zustand machen, wenn noch ein trigger kommt?

ZitatDas Modul bietet es an, es gibt ein vergleichbares Gerät bereits, also einbauen, meine ich.

korrekt - wie beschrieben kannst du es bereits aus SVN laden und probieren. Schon Geschichte.

ZitatDer Aktor hat den Wert 0 nicht als gültigen Trigger erkannt (Schwelle 50) und schlicht ignoriert.

genau das wollte ich beschrieben haben. Der default im Aktor macht probleme. Das Problem ist demnach der User, der nicht wirklich alles versteht oder programmiert.
Könnte man mit einem template lösen. Eigentlich nur ein Problem bei Betrieb ohne Zentrale.

Aber auch hier sind wir uns eigentlich einig.

ZitatGanz klar, aber wie gesagt - den Sinn müssen wir nicht diskutieren, wer weiß, wofür das doch nützlich sein kann.

zur Beruhigung: Ich habe bisher ALLE mir bekannten Configurationen eingebaut,egal ob ich sie verstehe, ob sie dokumentiert sind oder ich sie für sinnvoll halte. Da habe ich evtl. eine Meinung - blockiere aber nie etwas.

Zitat0x20 schaltet den  Kanal quasi ab,

#
ist nachgearbeitet.

ZitatHabe bei der Gelegenheit nun auch gemerkt, dass im low-Teil des Byte 9 nichts anderes als die Kanalnummer steht, oder?

oder!
es steht "meist" der Kanal drin. Der geht aber nur bis in die 50. Die oberen Bits haben gelegentlich andere Funktionen. Das Long hast du ja schon selbst dekodiert.

Zitatje Entity werden doch auch Internals angelegt und gespeichert im Statefile (?).

angelegt, nicht gespeichert

ZitatEigentlich genügt doch entweder das Setzen des Modus oder ein getConfig, und FHEM kann den Modus des Moduls erkennen und sich merken, ebenso sollte ein entsprechendes reading erzeugt werden, oder?

getConfig lasse ich gelten. Setzen der Readings kommt von getConfig - oder einem regSet als temp-value. "set_"

ZitatDanach lässt sich dann einstellen, ob das Device "shorts/longs" (0x23, 0x22) oder einen State "open/closed" (0x21) meldet (den man dann mit Notifys wie beim SCI-3 auswerten kann).

danach? Damit!
du setzt den modus und das Device arbeitet nach dem Modus. Was der Modus bedeutet sollte im Wiki stehen. Einzustellen gibt es nichts mehr. Notifies könnenerklärt werden (wiki)

ZitatAn die restlichen Bits würde ich nicht gehen - den zwischengespeicherten Wert als Basis nehmen und nur die Bits 0+1 kippen.

so arbeitet das CUL_HM modul immer.

ZitatEinen Default von 0x23 für Register 0x92 würde ich auch nicht vorsehen

es gibt keine defaults für Register imCUL_HM modul

Zitat- den soll ein getConfig liefern, sonst wird die Modusumstellung verweigert.

schon wieder stimmen wir überein - ist so seit dem ich das setzen von Registern eingebaut habe.

Nebenbei: Das ist der Grund, warum man für partial-byte zugriffe erst ein erfolgreiches getConfig braucht. Oder man nutzt das nachladen gesicherter registerbänke aus einem register-config file.
schon einmal mit HMInfo und dort saveConfig oder besser archConfig beschäftigt?
Zum handling von Registern insbesondere für interessierte User empfehle ich HMInfo (siehe Wiki)
templates
tempListen
archiveConfig
sichern und laden
machanismen zum laden von registern van config-devices (bei denen ein automatisches getConfig nicht geht) zum Start von FHEM
kopieren von Register von "peer" zu "peer" oder device/channel zu device/channel

genug - gerne testen und feedback - aber in einem anderen Threat

ZitatDamit kann uns dann erst mal egal sein, was der Rest von Register 0x92 ist ... oder?

ja. Der Wert ist somit "nur" über regBulk zu ändern. Da darf der User alles. Wenn jemand rausfindet, was die anderen Bits machen werden wir dies addieren.

ZitatWas rede ich schon wieder ... Wahrscheinlich hast Du's längst so oder besser gemacht ...

so - nicht besser

Zitat
Noch ein seltsamer Nebeneffekt: Im Moment des Umstellens von 0x23 auf 0x22 hat das Modul einen Short an den gepeerten Aktor gesendet, er hat daraufhin geschaltet. Das hatte ich tatsächlich schon öfter. Keine Ahnung, warum, ich würde es ignorieren.

man kann/sollte es im Wiki erwähnen. Vielleicht schreibt jemand etwas.

Danke für alle Aufklärungen und Tipps! Ich werde mich drum kümmern. Wahrscheinlich wäre ich jetzt auch mit dem Wiki dran (wäre mein erster Beitrag). Aber das muss ja eh mal sein.

Zitat von: martinp876 am 26 Oktober 2014, 18:49:49
...
Der Wert ist somit "nur" über regBulk zu ändern. Da darf der User alles. Wenn jemand rausfindet, was die anderen Bits machen werden wir dies addieren.

Erst mal? Denn Du hast ja schon ein neues Register angelegt names triggerMode:
   1: triggerMode      |     literals       |          | define type of event report  options:switch,sensor,button,off
Mit den Bezeichnungen haderte ich anfangs, aber jetzt finde ich sie - in Anlehnung an bestehende Devices - völlig richtig. Reihenfolge ist ja egal.

So ganz fertig ist das Ganze aber noch nicht ...
Nur zur Sicherheit: HMConfig.pm herunterladen, einspielen, FHEM neu starten - oder habe ich was übersehen?

Der Kanal 8 (Modus 0x21) liefert mir jetzt

Internals:
   .triggerUsed 1
   DEF        312F4408
   NAME       8BattSensor1_Btn_08
   NR         293
   STATE      Short (to vccu)
   TYPE       CUL_HM
   chanNo     08
   device     8BattSensor1
   Readings:
     2014-10-21 11:10:24   R-8BattAktor1N8-expectAES off
     2014-10-21 11:10:24   R-8BattAktor1N8-peerNeedsBurst on
     2014-10-23 18:17:11   R-SzDeckenlicht-expectAES set_off
     2014-10-23 18:17:11   R-SzDeckenlicht-peerNeedsBurst set_off
     2014-10-21 11:03:17   R-eventFilterTime 5 s
     2014-10-21 11:03:17   R-longPress     0.4 s
     2014-10-26 19:15:53   R-msgScPosA     closed
     2014-10-21 11:03:17   R-msgScdPosA    lvlNormal
     2014-10-21 11:03:17   R-msgScdPosB    lvlAddStrong
     2014-10-21 11:03:17   R-msgScdPosC    noMsg
     2014-10-21 11:03:17   R-msgScdPosD    noMsg
     2014-10-26 19:15:53   R-sign          off
     2014-10-26 19:15:53   R-transmitTryMax 3
     2014-10-26 19:15:53   R-triggerMode   sensor s
     2014-10-26 19:15:53   RegL_01:          04:10 08:00 20:60 23:05 30:03 92:21 00:00
     2014-10-26 19:20:51   state           Short (to vccu)
     2014-10-26 19:20:51   trigDst_vccu    noConfig
     2014-10-26 19:20:51   trigger         Short_29
   Helper:
     peerIDsRaw ,00000000
     Role:
       chn        1
     Shadowreg:
Attributes:
   model      HM-MOD-Em-8
   peerIDs    00000000,
   room       Spielwiese

Da fehlt noch der State "closed/open" ... noch stehen "short"s drin, ohne Wert.
Und was soll "R-triggerMode   sensor s" bzw.  " ... switch s", " ... button s" ?

edit: Tut mir leid, fällt mir jetzt erst auf: ELV nennt das Gerät HM-MOD-EM-8 (statt -Em-8), der kleine Buchstabe rutscht nur beim HM-MOD-Re-8 rein ... vielleicht auch gleich noch fixen ...

Wiki-Artikel ist erstellt, wer mag: http://www.fhemwiki.de/wiki/HM-MOD-EM-8_8-Kanal-Sendemodul (http://www.fhemwiki.de/wiki/HM-MOD-EM-8_8-Kanal-Sendemodul)

Zitat von: Pfriemler am 26 Oktober 2014, 19:46:33
...
So ganz fertig ist das Ganze aber noch nicht ...
Da fehlt noch der State "closed/open" ... noch stehen "short"s drin, ohne Wert.
Und was soll "R-triggerMode   sensor s" bzw.  " ... switch s", " ... button s" ?
...
ELV nennt das Gerät HM-MOD-EM-8 (statt -Em-8), der kleine Buchstabe rutscht nur beim HM-MOD-Re-8 rein ... vielleicht auch gleich noch fixen ...

*schieb* ... schon zwei Updates und noch keine Änderung. Oder muss ich das Ding neu anlernen? Denke mal nicht, denn die letzten Änderungen haben es ja auch so geschafft.
:-[

ZitatUnd was soll "R-triggerMode   sensor s" bzw.  " ... switch s", " ... button s" ?

ist die Einheit, habe ich gelöscht.

ZitatTut mir leid, fällt mir jetzt erst auf: ELV nennt das Gerät HM-MOD-EM-8 (statt -Em-8), der kleine Buchstabe rutscht nur beim HM-MOD-Re-8 rein ... vielleicht auch gleich noch fixen ...

könnte ich - aber dann müssen alle entweder einmal config drücken oder es im Config ändern.
es gibt in FHEM einige kleine Buchstaben. ist kein Problem, da es FHEM intern ist. Würde ich jetzt nicht ändern

ZitatDa fehlt noch der State "closed/open" ... noch stehen "short"s drin, ohne Wert.

hm ja...

Kurze Zwischenfrage: Kann das Modul sign-on ?

Das müsste Martin besser wissen ... in der neuesten CCU2 ist der EM-8 jetzt unterstützt, vielleicht kann man das da mal nachsehen. Aber ich schätze eher nicht...
edit: mit der heutigen HMConfig.pm (1.11.14 18:04) wird das Register "R-sign" jetzt angezeigt.

@Martin: state im Modus "sensor" klappt immer noch nicht, es kommen immer noch shorts. Stehe ab sofort als Versuchskarnickel bis 8.11. nicht zur Verfügung... Dienstreise.

sign sollte unterstützt werden - das register sollte in FHEM angezeigt sein
Register wie sign werden nicht erwähnt (leider). da hilft die CCU2 leider nicht.

Zitatstate im Modus "sensor" klappt immer noch nicht, es kommen immer noch shorts.

kein wunder, ich habe nichts geändert  ;)

jetzt kannst du einmal probieren

Zitat von: martinp876 am 01 November 2014, 20:18:07
kein wunder, ich habe nichts geändert  ;)
jetzt kannst du einmal probieren

hm ... noch nicht ganz. States sind "unknown:00" (=closed) und "unknown:C8" (=open)

Hier mal das aktuelle Listing:
Internals:
   .triggerUsed 1
   DEF        312F4408
   NAME       8BattSensor1_Btn_08
   NR         293
   STATE      unknown:C8
   TYPE       CUL_HM
   chanNo     08
   device     8BattSensor1
   Readings:
     2014-10-21 11:10:24   R-8BattAktor1N8-expectAES off
     2014-10-21 11:10:24   R-8BattAktor1N8-peerNeedsBurst on
     2014-10-23 18:17:11   R-SzDeckenlicht-expectAES set_off
     2014-10-23 18:17:11   R-SzDeckenlicht-peerNeedsBurst set_off
     2014-10-21 11:03:17   R-eventFilterTime 5 s
     2014-10-21 11:03:17   R-longPress     0.4 s
     2014-11-01 21:54:12   R-msgScPosA     closed
     2014-10-21 11:03:17   R-msgScdPosA    lvlNormal
     2014-10-21 11:03:17   R-msgScdPosB    lvlAddStrong
     2014-10-21 11:03:17   R-msgScdPosC    noMsg
     2014-10-21 11:03:17   R-msgScdPosD    noMsg
     2014-11-01 21:54:12   R-sign          off
     2014-11-01 21:54:12   R-transmitTryMax 3
     2014-11-01 21:54:12   R-triggerMode   sensor
     2014-11-01 21:54:12   RegL_01:          04:10 08:00 20:60 23:05 30:03 92:21 00:00
     2014-11-01 21:56:36   battery         ok
     2014-11-01 21:56:36   contact         unknown:C8 (to vccu)
     2014-11-01 21:56:36   state           unknown:C8
     2014-11-01 21:56:36   trigDst_vccu    noConfig
     2014-11-01 19:35:02   trigger         Short_15
   Helper:
     peerIDsRaw ,00000000
     Role:
       chn        1
     Shadowreg:
Attributes:
   model      HM-MOD-Em-8
   peerIDs    00000000,
   room       Spielwiese

Ich gehe jetzt aber wirklich offline vom FHEM - danke bisher für alles Mühen - mit mir am nächsten Wochenende, oder aber ein anderer stellt sich zur Verfügung.

default der states ist eingestellt
Ein log dazu wäre schön

Zitat von: martinp876 am 02 November 2014, 09:23:53
default der states ist eingestellt
Ein log dazu wäre schön

Ich würde es gerne auch testen, nur weiß ich nicht wie ich zu den aktuellen Änderungen komme, oder reicht dazu ein normales update?

Gruß Ralf

heute den Update aus SVN manuell nachladen.
Morgen ab etwa 7:00 reicht ein Update

Ich habe die Änderung manuell geupdated und dann ein wenig getestet.

Der Kanal 1 ist gepeert mit dem HM-MOD-Re-8.
Der Kanal 2 ist gepeert mit einem virtuellen "define virt_Btn CUL_HM ABC123"
Den Kanal 3 habe ich kurz mit einem virtuellen CUL_HM gepeert, damit ich zum triggerMode sensor wechseln konnte, danach habe ich das Peering wieder gelöst.

Für mich passt der sensor Mode jetzt.

Hier ist das Log vom Kanal 1:

2014.11.02 18:35:46.495 0: HMLAN_Parse: hmusb R:E3131EA   stat:0000 t:56D9FE0B d:FF r:FFCF     m:2E B441 3131EA 2C0622 010A00
2014.11.02 18:35:46.623 0: HMLAN_Parse: hmusb R:E2C0622   stat:0000 t:56D9FE8B d:FF r:FFCD     m:2E 8002 2C0622 3131EA 0102C80000
2014.11.02 18:35:52.094 0: HMLAN_Parse: hmusb R:E3131EA   stat:0000 t:56DA13E5 d:FF r:FFCE     m:2F B441 3131EA 2C0622 010BC8
2014.11.02 18:35:52.222 0: HMLAN_Parse: hmusb R:E2C0622   stat:0000 t:56DA1465 d:FF r:FFCE     m:2F 8002 2C0622 3131EA 0102000000


Hier ist das Log vom Kanal 3:

2014.11.02 18:38:44.446 0: HMLAN_Parse: hmusb R:E3131EA   stat:0000 t:56DCB525 d:FF r:FFCC     m:30 A241 3131EA 424242 030800
2014.11.02 18:38:50.877 0: HMLAN_Parse: hmusb R:E3131EA   stat:0000 t:56DCCE48 d:FF r:FFCD     m:31 A241 3131EA 424242 0309C8


Und hier ist das List:

Internals:
   DEF        3131EA01
   NAME       GarageAlt_01
   NR         46
   STATE      open
   TYPE       CUL_HM
   chanNo     01
   device     GarageAlt_Em8
   peerList   GarageAlt_Re8_Sw_02,
   Readings:
     2014-11-01 18:26:11   R-GarageAlt_Re8_Sw_02-expectAES off
     2014-11-01 18:26:11   R-GarageAlt_Re8_Sw_02-peerNeedsBurst on
     2014-10-12 01:35:07   R-eventFilterTime 5 s
     2014-10-12 01:35:07   R-longPress     0.4 s
     2014-11-01 18:26:02   R-msgScPosA     closed
     2014-10-19 10:59:02   R-msgScdPosA    lvlNormal
     2014-10-19 10:59:02   R-msgScdPosB    lvlAddStrong
     2014-10-19 10:59:02   R-msgScdPosC    noMsg
     2014-10-19 10:59:02   R-msgScdPosD    noMsg
     2014-11-01 18:26:02   R-sign          off
     2014-11-01 18:26:02   R-transmitTryMax 3
     2014-11-01 18:26:02   R-triggerMode   sensor s
     2014-11-02 19:09:53   battery         ok
     2014-11-02 19:09:53   contact         open (to GarageAlt_Re8)
     2014-11-02 18:41:38   peerList        GarageAlt_Re8_Sw_02,
     2014-11-02 19:09:53   state           open
     2014-10-12 22:34:21   trigDst_424242  noConfig
     2014-11-01 22:27:53   trigger         Short_5
     Regl_01::
       VAL
   Helper:
     getCfgList all
     getCfgListNo ,4
     Role:
       chn        1
Attributes:
   model      HM-MOD-Em-8
   peerIDs    00000000,2C062202,
   room       CUL_HM



   Internals:
   DEF        3131EA03
   NAME       GarageAlt_03
   NR         48
   STATE      open
   TYPE       CUL_HM
   chanNo     03
   device     GarageAlt_Em8
   Readings:
     2014-11-02 16:04:30   R-eventFilterTime 5 s
     2014-11-02 16:04:30   R-longPress     0.4 s
     2014-11-02 16:04:30   R-msgScPosA     closed
     2014-11-02 16:04:30   R-sign          off
     2014-11-02 16:04:30   R-transmitTryMax 3
     2014-11-02 16:06:14   R-triggerMode   sensor
     2014-11-02 16:04:31   R-virt_Btn_2-expectAES off
     2014-11-02 16:04:31   R-virt_Btn_2-peerNeedsBurst off
     2014-11-02 19:09:56   battery         ok
     2014-11-02 19:09:56   contact         open (to hmusb)
     2014-11-02 19:09:56   state           open
     2014-11-02 19:09:56   trigDst_424242  noConfig
     2014-11-02 16:02:28   trigger         Long_7
   Helper:
     getCfgList all
     getCfgListNo ,4
     Role:
       chn        1
Attributes:
   model      HM-MOD-Em-8
   peerIDs    00000000,
   room       CUL_HM


mir ist aufgefallen, daß es beim sensor-mode mit dem Log noch nicht passt.

Beim button- und switch-mode werden die Zustandsänderungen ins log geschrieben:

2014-11-02_19:01:36 GarageAlt_Em8 GarageAlt_02 Short (to virt_Btn)
2014-11-02_19:01:36 GarageAlt_Em8 CMDs_done
2014-11-02_19:01:37 GarageAlt_Em8 battery: ok


Beim sensor-mode erscheint bei Zustandsänderungen im log nur "CMDs_done"

kannst du ein log schicken, wenn er als sensor definiert ist?

Zitat von: martinp876 am 06 November 2014, 20:23:11
kannst du ein log schicken, wenn er als sensor definiert ist?

Hier sind einige logs:

GarageAlt_Em8-2014.log
als switch

2014-11-06_20:44:40 GarageAlt_Em8 battery: ok
2014-11-06_20:44:40 GarageAlt_Em8 GarageAlt_03_TorU_Ka Short (to hmusb)
2014-11-06_20:44:40 GarageAlt_Em8 CMDs_done

als sensor

2014-11-06_20:44:28 GarageAlt_Em8 CMDs_done
2014-11-06_20:44:28 GarageAlt_Em8 CMDs_done


Ich habe auch mal die state Änderungen per notify einem dummy zugewiesen:

define Em8_not notify GarageAlt_0.* set Em8_Dummy $EVENT

Em8_Dummy-2014-11.log
als switch

2014-11-06_20:44:40 Em8_Dummy trigDst_424242: noConfig
2014-11-06_20:44:40 Em8_Dummy Short (to hmusb)
2014-11-06_20:44:40 Em8_Dummy trigger: Short_9

als sensor

2014-11-06_20:44:28 Em8_Dummy trigDst_424242: noConfig
2014-11-06_20:44:28 Em8_Dummy battery: ok
2014-11-06_20:44:28 Em8_Dummy closed
2014-11-06_20:44:28 Em8_Dummy contact: closed (to hmusb)
2014-11-06_20:44:28 Em8_Dummy trigDst_424242: noConfig
2014-11-06_20:44:28 Em8_Dummy battery: ok
2014-11-06_20:44:28 Em8_Dummy open
2014-11-06_20:44:28 Em8_Dummy contact: open (to hmusb)


ich brauche die rohmessages. mit denen, die ich gesehen habe funktioniert die Anzeige des State. Ich kann es probieren, aber nur, wenn ich die messages habe.

Hm ... bin gerade zurück und habe aber jetzt keine Zeit, um sofort mitzuhelfen.
Martin: state etc. scheint zu funktionieren. Ralf9 zeigt ja, dass alle Messages vom EM-8, wenn sie über das Notify an den Dummy gesendet werden, von diesem auch abgebildet werden. Nur direkt im Filelog passiert außer CMDs_done wohl nichts.
Erklären kann ich mir das mit meinem bescheidenen Hintergrundwissen jedenfalls erst mal auch nicht.
Ralf, Du hast aber nicht zufällig an den Regex für das Filelog herumgespielt?

Zitat von: Pfriemler am 08 November 2014, 17:09:27
Ralf, Du hast aber nicht zufällig an den Regex für das Filelog herumgespielt?

Nein, an den Regex für das Filelog habe ich nichts geändert.

Zitat von: martinp876 am 08 November 2014, 15:23:18
ich brauche die rohmessages. mit denen, die ich gesehen habe funktioniert die Anzeige des State. Ich kann es probieren, aber nur, wenn ich die messages habe.

Die rohmessages vom sensor mode habe ich bereits bei der Antwort #53 gepostet.
Mit dem notify an den dummy passt für mich das log erstmal so.

define Em8_not notify GarageAlt_0.* set Em8_Dummy $NAME $EVENT


wenn ich die message simuliere wird der Button state auf open oder closed gesetzt
Sollte auch bei euch so sein

Zitat von: martinp876 am 12 November 2014, 19:54:11
wenn ich die message simuliere wird der Button state auf open oder closed gesetzt
Sollte auch bei euch so sein

Martin, das stellt ja auch keiner in Abrede.
Bei mir sind Kanal 1 und 5 gepeert, 1-6 sind remotes, 7 ist ein switch und 8 ein sensor.


8BattSensor1_Btn_01   Short (to LEDDimmer1)
8BattSensor1_Btn_02   Short (to vccu)
8BattSensor1_Btn_03   Short (to vccu)
8BattSensor1_Btn_04   Short (to vccu)
8BattSensor1_Btn_05   Short (to 4BattAkt)
8BattSensor1_Btn_06   Short (to vccu)
8BattSensor1_Btn_07   Short (to vccu)
8BattSensor1_Btn_08   open

Da steht der Status wie es sich gehört.

Aber wenn ich von 1-8 alle einmal kurz durchtaste, bekomme ich von 1-6 genau eine Meldung (ein Button "short"), von 7 zwei (richtig, er muss ja beim Schließen und Öffnen des Tasters einen short senden) - aber die 8 taucht im FileLog zum Device nicht auf. Und um nichts anderes geht's in den letzten vier Posts ...  ???

2014-11-12_22:26:20 8BattSensor1 8BattSensor1_Btn_01 Short (to LEDDimmer1)
2014-11-12_22:26:24 8BattSensor1 battery: ok
2014-11-12_22:26:24 8BattSensor1 8BattSensor1_Btn_02 Short (to vccu)
2014-11-12_22:26:24 8BattSensor1 CMDs_done
2014-11-12_22:26:25 8BattSensor1 battery: ok
2014-11-12_22:26:25 8BattSensor1 8BattSensor1_Btn_03 Short (to vccu)
2014-11-12_22:26:25 8BattSensor1 CMDs_done
2014-11-12_22:26:27 8BattSensor1 battery: ok
2014-11-12_22:26:27 8BattSensor1 8BattSensor1_Btn_04 Short (to vccu)
2014-11-12_22:26:27 8BattSensor1 CMDs_done
2014-11-12_22:26:29 8BattSensor1 battery: ok
2014-11-12_22:26:29 8BattSensor1 8BattSensor1_Btn_05 Short (to 4BattAkt)
2014-11-12_22:26:31 8BattSensor1 battery: ok
2014-11-12_22:26:31 8BattSensor1 8BattSensor1_Btn_06 Short (to vccu)
2014-11-12_22:26:31 8BattSensor1 CMDs_done
2014-11-12_22:26:33 8BattSensor1 battery: ok
2014-11-12_22:26:33 8BattSensor1 8BattSensor1_Btn_07 Short (to vccu)
2014-11-12_22:26:33 8BattSensor1 CMDs_done
2014-11-12_22:26:33 8BattSensor1 battery: ok
2014-11-12_22:26:33 8BattSensor1 8BattSensor1_Btn_07 Short (to vccu)
2014-11-12_22:26:33 8BattSensor1 CMDs_done

Hier sind die raw messages zu einem weiteren Versuch, diesmal habe ich 7 und 8 etwas länger "an gelassen".
Natürlich kommen die Telegramme - sonst würde ja auch die Statusanzeige nicht funktionieren. Nur im FileLog kommt nichts an.

2014.11.12 22:31:46.138 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:C1E1A31C d:FF r:FFC3     m:54 A440 312F44 29765C 0103 #ch1
2014.11.12 22:31:46.500 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:C1E1A39C d:FF r:FFC8     m:54 8002 29765C 312F44 010114103500
2014.11.12 22:31:48.000 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:C1E1AA62 d:FF r:FFC3     m:55 A240 312F44 1411AB 0203 #ch2
2014.11.12 22:31:49.405 0: HMLAN_Parse: HMLAN1 R:E29765C   stat:0000 t:C1E1AFDF d:FF r:FFC7     m:55 A410 29765C 1411AB 0601C80080C8 # ???
2014.11.12 22:31:49.894 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:C1E1B088 d:FF r:FFC3     m:56 A240 312F44 1411AB 0303 #ch3
2014.11.12 22:31:51.032 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:C1E1B63A d:FF r:FFC4     m:57 A240 312F44 1411AB 0403 #ch4
2014.11.12 22:31:52.900 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:C1E1BD86 d:FF r:FFC4     m:58 B440 312F44 529E82 0506 #ch5
2014.11.12 22:31:53.079 0: HMLAN_Parse: HMLAN1 R:E529E82   stat:0000 t:C1E1BE05 d:FF r:FFD9     m:58 8002 529E82 312F44 0103000000
2014.11.12 22:31:54.566 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:C1E1C408 d:FF r:FFC3     m:59 A240 312F44 1411AB 0604 #ch6
2014.11.12 22:31:56.725 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:C1E1CC78 d:FF r:FFC2     m:5A A240 312F44 1411AB 0707 #ch7 (zu)
2014.11.12 22:31:58.672 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:C1E1D413 d:FF r:FFC4     m:5B A240 312F44 1411AB 0708 #ch7 (auf)
2014.11.12 22:32:01.627 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:C1E1DF9E d:FF r:FFC3     m:5C A241 312F44 1411AB 080E00 #ch8 close
2014.11.12 22:32:04.224 0: HMLAN_Parse: HMLAN1 R:E312F44   stat:0000 t:C1E1E9C4 d:FF r:FFC6     m:5D A241 312F44 1411AB 080FC8 #ch8 open


Ah
Zumindest die eine msg scheint inkorrekt. Der kanal ist 7, sollte aber 8 sein. Ein fw bug ?

Zitat von: martinp876 am 13 November 2014, 20:42:37
Ah
Zumindest die eine msg scheint inkorrekt. Der kanal ist 7, sollte aber 8 sein. Ein fw bug ?

Nein, ein Schreibfehler im Kommentar von mir... korrigiert.

Ich habe hierzu mal eine Laienfrage. Ist es also möglich an die Analogen Eingänge einen Öffnerkontakt zu hängen und das Modul sendet nur, wenn der öffnerkontakt geöffnet bzw geschlossen wird?

nicht an die analogen Eingänge,  sondern an die zusätzlich vorhandenen Kontakteingange, speziell für potentialfreie Kontakte.  Sonst: ja.

Vom 7Zöller via Tapatalk

habe ich wohl noch nicht verstanden.
7 ist ein taster, 8 ein Sensor.
Ein taster sendet ein Event -eigentlich wohl das schliessen. das öffnen nicht. Sicher ist, dass es nicht unterschieden wird (ausser evtl  long/short)

8 ist ien Sensor - er meldet  auf oder zu - was er auch in meiner Simulation tut. Der Zustand wird in "contact" festgehalten. bei Ch 7 gibt es den garnicht... kann ja nicht.

So habe ich es verstanden und so kommen auch die trigger.

So, ich schon wieder. Es geht immer noch um die Frage, warum die Statusmeldungen eines auf Kontaktsensor eingestellten Eingangs keine Status-Spuren im FileLog hinterlassen.

Hier ist mein EventMonitor-Auszug dazu, mit # erklärt, was ich gemacht habe und darunter was passiert.
# kurzer Trigger Kanal 6 (remote)
a 2014-11-16 17:00:36 CUL_HM 8BattSensor1 battery: ok
b 2014-11-16 17:00:36 CUL_HM 8BattSensor1 8BattSensor1_Btn_06 Short (to vccu)
c 2014-11-16 17:00:36 CUL_HM 8BattSensor1 CMDs_done
d 2014-11-16 17:00:36 CUL_HM 8BattSensor1_Btn_06 trigDst_vccu: noConfig
e 2014-11-16 17:00:36 CUL_HM 8BattSensor1_Btn_06 Short (to vccu)
f 2014-11-16 17:00:36 CUL_HM 8BattSensor1_Btn_06 trigger: Short_7
# Kontakt geschlossen Kanal 7 (switch) - sendet kurzen Trigger wie bei remote
a 2014-11-16 17:00:38 CUL_HM 8BattSensor1 battery: ok
b 2014-11-16 17:00:38 CUL_HM 8BattSensor1 8BattSensor1_Btn_07 Short (to vccu)
c 2014-11-16 17:00:38 CUL_HM 8BattSensor1 CMDs_done
d 2014-11-16 17:00:38 CUL_HM 8BattSensor1_Btn_07 trigDst_vccu: noConfig
e 2014-11-16 17:00:38 CUL_HM 8BattSensor1_Btn_07 Short (to vccu)
f 2014-11-16 17:00:38 CUL_HM 8BattSensor1_Btn_07 trigger: Short_11
# Kontakt offen Kanal 7 (switch) - sendet kurzen Trigger wie bei remote
a 2014-11-16 17:00:40 CUL_HM 8BattSensor1 battery: ok
b 2014-11-16 17:00:40 CUL_HM 8BattSensor1 8BattSensor1_Btn_07 Short (to vccu)
c 2014-11-16 17:00:40 CUL_HM 8BattSensor1 CMDs_done
d 2014-11-16 17:00:40 CUL_HM 8BattSensor1_Btn_07 trigDst_vccu: noConfig
e 2014-11-16 17:00:40 CUL_HM 8BattSensor1_Btn_07 Short (to vccu)
f 2014-11-16 17:00:40 CUL_HM 8BattSensor1_Btn_07 trigger: Short_12
# Kontakt geschlossen Kanal 8 (sensor) - sendet Trigger mit Wert
c 2014-11-16 17:00:43 CUL_HM 8BattSensor1 CMDs_done
d 2014-11-16 17:00:43 CUL_HM 8BattSensor1_Btn_08 trigDst_vccu: noConfig
a 2014-11-16 17:00:43 CUL_HM 8BattSensor1_Btn_08 battery: ok
? 2014-11-16 17:00:43 CUL_HM 8BattSensor1_Btn_08 closed
? 2014-11-16 17:00:43 CUL_HM 8BattSensor1_Btn_08 contact: closed (to vccu)
# Kontakt offen Kanal 8 (sensor) - sendet Trigger mit Wert
c 2014-11-16 17:00:46 CUL_HM 8BattSensor1 CMDs_done
d 2014-11-16 17:00:46 CUL_HM 8BattSensor1_Btn_08 trigDst_vccu: noConfig
a 2014-11-16 17:00:46 CUL_HM 8BattSensor1_Btn_08 battery: ok
? 2014-11-16 17:00:46 CUL_HM 8BattSensor1_Btn_08 open
? 2014-11-16 17:00:46 CUL_HM 8BattSensor1_Btn_08 contact: open (to vccu)

Wie man sieht, erzeugen remote(6)- und switch(7)-Kanal jeweils 6 Zeilen pro Event, davon drei mit dem Namen des Devices (hier 8BattSensor1) und drei mit dem Namen des Devices, gefolgt von _Btn_0x. a=Batteriemeldung, b=Ereignismeldung Device c=CMDs_done, d=trigDst... e=Ereignis Kanal f=Triggerergeignis. Die Bezeichnungen sind nicht ganz sauber, aber ...

Vom Sensor-Kanal kann ich die Meldungen jedoch nicht so zuordnen.
1. die dritte Zeile (a) müsste die Batteriemeldung ohne den Kanal senden.
2. Die vorletzte Zeile wäre am ehesten ein e, aber dort vermisse ich den pair-Partner (to vccu)
3. Der wieder ist an der contact-Meldung hinten zuviel (also dort, wo die anderen Kanäle ein trigger: short haben)

Ein den Sensor-Kanälen äquivalentes Event-Set müsste nach meiner Meinung so aussehen

# Kontakt geschlossen Kanal 8 (sensor) - sendet Trigger mit Wert
a 2014-11-16 17:00:40 CUL_HM 8BattSensor1 battery: ok
b 2014-11-16 17:00:40 CUL_HM 8BattSensor1 8BattSensor1_Btn_08 closed (to vccu)
c 2014-11-16 17:00:40 CUL_HM 8BattSensor1 CMDs_done
d 2014-11-16 17:00:40 CUL_HM 8BattSensor1_Btn_08 trigDst_vccu: noConfig
e 2014-11-16 17:00:40 CUL_HM 8BattSensor1_Btn_07 closed (to vccu)
f 2014-11-16 17:00:40 CUL_HM 8BattSensor1_Btn_07 contact: closed

bzw.
# Kontakt offen Kanal 8 (sensor) - sendet Trigger mit Wert
a 2014-11-16 17:00:40 CUL_HM 8BattSensor1 battery: ok
b 2014-11-16 17:00:40 CUL_HM 8BattSensor1 8BattSensor1_Btn_08 open to vccu)
c 2014-11-16 17:00:40 CUL_HM 8BattSensor1 CMDs_done
d 2014-11-16 17:00:40 CUL_HM 8BattSensor1_Btn_08 trigDst_vccu: noConfig
e 2014-11-16 17:00:40 CUL_HM 8BattSensor1_Btn_07 open (to vccu)
f 2014-11-16 17:00:40 CUL_HM 8BattSensor1_Btn_07 contact: open

Der default-Regex für das Filelog (der reine Device-Name) findet m.E. nur die ersten drei Zeilen eines Event-Sets und nicht die Zeilen, wo _Btn... drangehangen ist. Deswegen finden derzeit nur die CMDs_done-Meldungen eines Sensor-Kanals den Weg ins FileLog.

ABER!
Ein Schalter-Interface wie das SCI3 sendet nur 4 Zeilen pro Event:

2014-11-16 17:29:50 CUL_HM SchalterSensorSCI3_2 CMDs_done
2014-11-16 17:29:50 CUL_HM SchalterSensorSCI3_2_ch03 battery: ok
2014-11-16 17:29:50 CUL_HM SchalterSensorSCI3_2_ch03 closed
2014-11-16 17:29:50 CUL_HM SchalterSensorSCI3_2_ch03 contact: closed (to vccu)
...
2014-11-16 17:29:53 CUL_HM SchalterSensorSCI3_2 CMDs_done
2014-11-16 17:29:53 CUL_HM SchalterSensorSCI3_2_ch03 battery: ok
2014-11-16 17:29:53 CUL_HM SchalterSensorSCI3_2_ch03 open
2014-11-16 17:29:53 CUL_HM SchalterSensorSCI3_2_ch03 contact: open (to vccu)


und das ist genau das, was ein Kanal eines EM-8 im Sensor-Modus auch tut! Die trigDst-Zeilen sind ja nur Folge einer (bei mir) unvollständigen Konfiguration. Auch beim SCI3 erscheinen (zumindest bei mir) keine Statusänderungen im FileLog.

Nun können wir mal trefflich darüber streiten, ob und welche Änderungen bei welchem HM-Gerät jetzt erforderlich sind. Sollte man die Sensor-Kanäle eines EM-8 den Switch-/Remote-Kanälen meldungsmäßig anpassen oder wie beim SCI3 belassen oder auch das SCI3 dahingehend ändern, dass es Sets wie die remote-Kanäle des EM-8 senden...?

Übrigens: Wer die Kontaktzustandsänderungen eines Kanals im FileLog haben will, braucht ja nur einen passenden REGEX-Part hinzuzufügen (Kanalname also (inkl. Device)) ...

Hi,

der EM sollte im SCi mode auch nichts andere senden.
Falsch ist, dass batterie im Kanal kommt - das wird ins device verschoben. Ist bei tristate sensoren bislang nicht aufgefallen, da sie (meist) nur ein-kanaler sind.

dann sollte es passen - 4 trigger

Gruß Martin

Zitat von: martinp876 am 16 November 2014, 19:03:17
der EM sollte im SCi mode auch nichts andere senden.

Eine Einheitlichkeit wäre wie immer begrüßenswert, nur welche? siehe unten.

ZitatFalsch ist, dass batterie im Kanal kommt - das wird ins device verschoben. Ist bei tristate sensoren bislang nicht aufgefallen, da sie (meist) nur ein-kanaler sind.

Na klar doch. Das mit dem Batterie-Status beträfe dann aber auch den SCI3, siehe meinen Event-Log, neben dem EM-8. Bei der Gelegenheit auch die Geschwister  HM-PBI4-FM und HM-SWI-3-FM checken, ich habe beide nicht im Haus. edit: Anpassung im Activity-Monitor auch nötig?

Blöd ist jetzt noch, dass die Einkanaler wegen der fehlenden Unterscheidung zwischen Device und Kanal mit dem gleichen Regex ihren Status ins Log schreiben ...
2014-11-16_22:16:36 EGHaustuer contact: closed (to vccu) (von einem SCo)
während für einen Mehrkanaler wie dem SCI-3 noch ein zusätzlicher Regex-Filter auf den Kanalnamen nötig ist.

Denn inkonsequent ist eigentlich auch, dass der EM-8 im remote- und switch-Modus seine Trigger quasi doppelt sendet (Zeilen b und e):

# kurzer Trigger Kanal 6 (remote)
...
b 2014-11-16 17:00:36 CUL_HM 8BattSensor1 8BattSensor1_Btn_06 Short (to vccu)
...
e 2014-11-16 17:00:36 CUL_HM 8BattSensor1_Btn_06 Short (to vccu)
f 2014-11-16 17:00:36 CUL_HM 8BattSensor1_Btn_06 trigger: Short_7
entweder wäre Zeile b überflüssig ...
oder SCI-3 & Co senden dann auch "doppelt" und ihr Status landet so ebenfalls mit dem einfachen Device-Regex im Logfile.

Ich glaub, hier besteht noch mehr Optimierungsbedarf.

- batterie wird immer im device gemeldet, nie im Channel. Ist noch einer vergessen?
- der Activity Monitor sollte das können - automatisch. Geht es etwa nicht?

ZitatBlöd ist jetzt noch, dass die Einkanaler wegen der fehlenden Unterscheidung

jeder, der hier unterscheiden will kann den Kanal eines einkanalers defineren. einfach ein Define mit <HMId>01 . Ist sauberer. Hätte ich fast eingeführt... aber so kann man es selbst steuern.

ZitatDenn inkonsequent ist eigentlich auch, dass der EM-8 im remote- und switch-Modus seine Trigger quasi doppelt sendet (Zeilen b und e):

das machen alle mehr-tasten remotes so. Der Trigger kommt im Channel, im Device wird angezeigt, welcher Kanal als letzter einen trigger gesendet hat und welchen.
Falls ich es ändere würde b entfallen. könnte aber zu Problemen bei existierenden Auswertungen der User führen. Daher bleibt es.

Bis auf den letzten Punkt kannst du es selbst optimieren

Zitat- batterie wird immer im device gemeldet, nie im Channel. Ist noch einer vergessen?
- der Activity Monitor sollte das können - automatisch. Geht es etwa nicht?

Bis vor wenigen Tagen war es nicht so.
Der ActionDetector hatte bis dato jedenfalls das EM-8 auch nicht erfasst. Klappt vermutlich ebenfalls wenn die Batterys auf Device-Ebene kommen.
Update läuft ... Yup, Batteriemeldung im Device, nach einem händisch nachgetragenen "actCycle" im Sendemodul und ein paar Triggern vom Modul einwandfrei im ActionMonitor.

Zitatjeder, der hier unterscheiden will kann den Kanal eines einkanalers defineren. einfach ein Define mit <HMId>01 . Ist sauberer. Hätte ich fast eingeführt... aber so kann man es selbst steuern.

Gute Idee, war mir neu, würde die Inkonsistenzen erst mal beseitigen. Aber siehe auch die PM dazu. Denn:

Zitat

ZitatDenn inkonsequent ist eigentlich auch, dass der EM-8 im remote- und switch-Modus seine Trigger quasi doppelt sendet (Zeilen b und e):

...
das machen alle mehr-tasten remotes so. Der Trigger kommt im Channel, im Device wird angezeigt, welcher Kanal als letzter einen trigger gesendet hat und welchen.

Gut. Was spricht dagegen, Sensorwerte genauso doppelt zu schicken? Dann könnte das Device nicht nur den letzten Trigger, sondern auch die letzte Statusänderung zeigen. Beim SCI-3 sieht man ja auch maximal "CMDs done", während jede Remote den letzten Tastendruck anzeigt (zumindest sofern ein peering-Partner bekannt ist).

ZitatFalls ich es ändere würde b entfallen. könnte aber zu Problemen bei existierenden Auswertungen der User führen. Daher bleibt es.

Keine Einwände.  :)

BTW: Mein EM-8 ist seit heute im "produktiven Einsatz". Ein Arduino samt Eigenbau-Sketch überwacht und übersetzt die (teilweise blinkenden) Status-LEDs meiner bestehenden Alarmanlage und meldet ein 5-Bit-Muster per Sensorkanäle, Kanal 6 sendet zusätzlich als Remote einen Trigger, wenn es Änderungen gab - eigentlich überflüssig, da ein DOIF und zwei Notifys die Zustandsänderungen auch so problemlos mitbekommen... Anscheinend hat das Modul keine Probleme, mehrere sich gleichzeitig ändernde Eingangskanäle sauber zu melden. Wäre ja auch schlimm wenn nicht.

ZitatDer ActionDetector hatte bis dato jedenfalls das EM-8 auch nicht erfasst.

wird auch nicht passieren. der em8 schickt keine regelmäßigen messages, der Actiondetector kann es nicht überwachen - wie bei anderen Sendern auch.
Der User kann den ActionDetector selbst starten - muss dann mit dem "dead" nach eigenem gusto umgehen.

Hallöchen,

dumme Frage eines Anfängers zwischendurch... könnte ich an den EM-8 ein IR-Modul (bspw. das IR8 (http://www.elv.de/ir-empfaenger-8-kanaele-ire88-komplettbausatz.html)  von ELV anschließen? Hat das schon jemand probiert?

Gruß
Diddle.

Ich wüsste nichts, was dagegen spräche. Sowohl Open-Collector als auch Spannungseingänge sollten funktionieren. Wenn der IRE die Tastenbetätigung 1:1 durchgibt, stehen in HM alle Short/Long-Möglichkeiten zur Verfügung, wenn die Kanäle des EM-8 im "remote"-Modus betrieben werden.

Hallo,

ich möchte das Modul gerne an einen Bewegungsmelder hängen. Der BM hat einen potentialfreien 12V öffner. Ich bin nun etwas unschlüssig wie ich den HM-MOD-EM-8 am besten verwende.
Hänge ich den BM am besten an den analogen Spannungseingang oder den digitalen? Welcher Modi wäre hierfür am besten?

Vielen Dank!
olfi

Was genau meinst Du mit 12-V-Öffner? Liefert der Ausgang 12 Volt bei erkannter Bewegung?

Ein potentialfreier Öffner kann direkt einen Tastereingang bedienen, ohne Zusatzschaltung. Das ist der geringste Aufwand bei räumlicher Nähe. Als Schließer (NO = normally open) kann er bei kurzer Betätigung den Eingang direkt bedienen, das Modul liefert dann wie eine Fernbedienung entsprechend lange Tastendrücke. Bei einem Öffner (NC = normally closed), wie Du meinst, oder auch bei längeren Schließzeiten ist eine Konfiguration des betreffenden Eingangs auf den Modus "sensor" zwingend erforderlich. Ich würde das aber so oder so empfehlen.

Die nötige Umkehrung der Logik bei einem Öffner erledigt man dann in FHEM.

Der Tastereingang wird intern recht hochohmig abgefragt, deswegen dürfte der Verbrauch außer bei reiner Batteriespeisung gar nicht ins Gewicht fallen). Bei längeren Zuleitungen (ab 1 Meter aufwärts) würde ich wegen der Störsicherheit einen Spannungseingang verwenden. Digital sind beide - nominell ab 2 Volt (praktisch deutlich darunter) erkennt der Eingang auf "bedient". Eine Spannungsauswertung findet nicht statt.

Welches die beste Lösung ist, richtet sich u.a. nach der Entfernung und der Frage, ob Bewegungsmelder und Modul zusammen gespeist werden können.

Hallo,

ich habe das Modul "HM-MOD-EM-8" hier im Einsatz um den High-Pegel von 5 anliegenden Spannungen zu erkennen und zu übermitteln. Dazu habe ich alle 8 Eingänge per "set EM-8-channel regSet triggerMode sensor " in den Sensor-Mode versetzt.

Das Teil lief viell einen Tag gut. Dann erhielt ich keine Logs mehr: STATE = CMDs_pending

Zuerst dachte ich, dass es am Empfang läge. Dies kann aber ausgeschlossen werden, da mehrmals an unterschiedlichen orten getestet. Nun habe ich dazu das Modul blank, ohne angeschlossene 12V Spannungen getestet. Das gleiche. Eine Beschädigung durch die 12V kann ausgeschlossen werden.

Starte ich das Modul neu per "Neubestromen", kriege ich STATE = CMDs_done.

Aber funktionieren tut da etwas nicht richtig...

Ich habe alles ausprobiert, komme aber nicht weiter. D-firmware ist 1.1.

Hat jmd. eine Idee? Danke!

(Betriebsspannung ist 12V, richtig angeschlossen).

Firmware 1.1? Warum weiß ich das nicht?  ;D

Meine beiden EM-8 laufen auch mit Spannungserkennung völlig störungsfrei. Klingt so, als würde sich Dein Modul wegen irgendwas aufhängen. AES aktiv?
Die Spannungen an den Spannungs-Eingängen (keinesfalls aber den Taster-Eingängen) dürfen auch höher als die Versorgungsspannung sein, das ist schaltungstechnisch kein Problem.

Sind denn die Channels wirklich sauber umgestellt oder sendet sich das Modul per Long-Triggerkanonade noch tot?

Hallo,

AES ist aktiv. Alle Pegel werden als Open/Closed übertragen.

Starte ich das Modul neu werden die Pegel richtig erkannt und übertragen. Bei Getconfig kommt dann nur noch das pending...

Ich lasse das blanke Modul mal über Nacht laufen und gucke dann mal.

Ein Aufhängen oder festhängen würde ich auch sagen. Reset über den Taster (4Sek usw.) habe ich scvon gemacht...

Hallo,

habe es eben nochmal probiert. Wie vorher auch schon..

Ob es vielleicht doch die Reichweite bzw. Empfangssituation ist?


avg:-66.2 min:-92 max:-56 cnt:153 lst:-57

Ich kann jetzt sonst nur noch den Support kontaktieren...

Danke und
Gruß

Hi Spel,

ne ganz quere Idee: Was hast Du für einen IO? Hast Du andere Geräte mit vielen Kanälen?
getConfig produziert beim EM-8 ne  Menge Funkverkehr ....

Gruß Otto

Hallo,

ich habe einen HMLAN-Adapter als Gateway.

Damit verknüpft sind:

1x Bewegungsmelder (HM-SEC-MDIR)
1x Sensor 3 Schalteingänge (HM-SCI-3-FM)
1x Handsender, eigentlich ungenutzt (HM-RC-4)
1x Fensterkontakt (HM-SEC-SCo)
1x 8fach Empfangsmodul um Relais zu schalten (HM-MOD-Re-8)
1x das besagte 8fach Sendemodul (HM-MOD-Em-8)

Dabei ist das 8fach Sende- und Emfpangsmodul an einer Stromquelle und wird gleichzeitig eingeschaltet. Habe es aber auch schon so probiert, dass ich das besagte Sendemodul später aufstecke... erzeugt die gleiche Problematik. Die Module sind in etwa 50 cm übereinander angeordnet.

Das Empfangsmodul arbeitet so wie es soll. Ich weiß gerade nicht weiter. Grds. habe ich von Elektronik etwas Ahnung und habe bereits viele Möglichkeiten durchprobiert...

Ich gebe die Hoffnung noch nicht auf...

Danke!

Ok, dann war meine Idee nix.

Reichweite: Du hast zwar einmal rssi von 90 aber die Werte von um die 60 sind eigentlich gut.

Vielleicht doch einfach kaputt ...
Gruß Otto

ZitatDas Teil lief viell einen Tag gut. Dann erhielt ich keine Logs mehr: STATE = CMDs_pending

wieso eigentlich cmds_pending? was will fhem denn?
schon mal hminfo configCheck gemacht? oder den burschen gesnifft?
passiert es auch ohne aes?

Hallo,

da ich keine Rückmeldung, wie zB das standardmässige "battery: OK" erhielt (das ist ja eigentlich nen Handsender das Modul). hatte ich getConfig gedrückt und dann kam nur noch CMD_pending...

HMinfo ergab das:

trigger sent to undefined device
triggerUndefined:
Und dann ein paar Eingänge des Moduls. Dort liegen jedoch einfach nur 12 Volt an...

Hier das Log seit Neustart:

2016-11-07_17:16:17 DG.db.SE.PIRMelder_HM battery: ok
2016-11-07_17:16:17 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:16:33 DG.db.SE.PIRMelder_HM alive: yes
2016-11-07_17:16:33 DG.db.SE.PIRMelder_HM powerOn: 2016-11-07 17:16:32
2016-11-07_17:16:33 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:16:33 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:16:33 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:16:33 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:16:33 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:16:33 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:16:34 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:16:34 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:16:34 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:16:44 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:16:45 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:16:53 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:16:54 DG.db.SE.PIRMelder_HM CMDs_done
2016-11-07_17:21:35 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending
2016-11-07_17:21:36 DG.db.SE.PIRMelder_HM CMDs_pending

Die Stati der Eingänge (open/closed) wurden nicht mehr übertragen seit Neustart des Moduls.

poste mal ein list vom device und von einem channel, und dann sniffe mal das device wie im wiki homematic sniffen.

Hallo,

okay das möchte ich gerne machen. "list" bedeutet regList oder welches list?

Danke!

Zitat von: spel am 07 November 2016, 20:34:59
Hallo,

okay das möchte ich gerne machen. "list" bedeutet regList oder welches list?

Danke!

list <devicename> in der kommandozeile
Wenn Du dem Handsender aber getConfig schickst musst Du auch was drücken, sonst sendet er nicht. Beim EM-8 übrigens genauso.

Gruß Otto

Das Modul selbst:

DEF        3D679C
   IODev      HMLAN1
   NAME       DG.db.SE.PIRMelder_HM
   NOTIFYDEV  global
   NR         184
   NTFY_ORDER 50-DG.db.SE.PIRMelder_HM
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 DG.db.SE.PIRMelder_HM_Btn_01
   channel_02 DG.db.SE.PIRMelder_HM_Btn_02
   channel_03 DG.db.SE.PIRMelder_HM_Btn_03
   channel_04 DG.db.SE.PIRMelder_HM_Btn_04
   channel_05 DG.db.SE.PIRMelder_HM_Btn_05_Wintergarten
   channel_06 DG.db.SE.PIRMelder_HM_Btn_06_Weg
   channel_07 DG.db.SE.PIRMelder_HM_Btn_07_Garagentuer
   channel_08 DG.db.SE.PIRMelder_HM_Btn_08_Terrasse
   Readings:
     2016-11-06 21:37:19   CommandAccepted yes
     2016-11-06 21:22:11   D-firmware      1.1
     2016-11-06 21:22:11   D-serialNr      MEQ0781499
     2016-11-07 20:26:14   PairedTo        0x8883C2
     2016-11-06 21:14:03   R-pairCentral   0x8883C2
     2016-11-07 20:26:14   RegL_00.        02:01 05:40 0A:88 0B:83 0C:C2 12:00 14:03 18:00  00:00
     2016-11-06 21:37:20   aesCommToDev    ok
     2016-11-06 21:37:20   aesKeyNbr       00
     2016-11-07 20:27:08   alive           yes
     2016-11-07 20:27:09   battery         ok
     2016-11-07 20:27:08   powerOn         2016-11-07 20:27:08
     2016-11-07 20:27:08   recentStateType info
     2016-11-07 20:27:09   state           CMDs_done
   Helper:
     HM_CMDNR   1
     mId        00D9
     rxType     16
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +3D679C,00,01,00
       prefIO
       rxt        2
       vccu
       p:
         3D679C
         00
         01
         00
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Tmpl:
Attributes:
   IODev      HMLAN1
   autoReadReg 4_reqStatus
   event-min-interval battery:300
   expert     2_raw
   firmware   1.1
   group      Steuerung Beleuchtung
   icon       audio_fade
   model      HM-MOD-Em-8
   room       Perimeter,_HOMEMATIC
   serialNr   MEQ0781499
   subType    remote
   webCmd     getConfig:clear msgEvents


Channel "08":

Internals:
   DEF        3D679C08
   NAME       DG.db.SE.PIRMelder_HM_Btn_08_Terrasse
   NOTIFYDEV  global
   NR         192
   NTFY_ORDER 50-DG.db.SE.PIRMelder_HM_Btn_08_Terrasse
   STATE      closed
   TYPE       CUL_HM
   chanNo     08
   device     DG.db.SE.PIRMelder_HM
   Readings:
     2016-11-06 21:22:11   R-sign          off
     2016-11-07 20:26:22   RegL_01.        04:10 08:00 20:60 23:05 30:03 92:21 00:00
     2016-11-07 20:27:09   contact         closed (to HMLAN1)
     2016-11-07 20:27:09   state           closed
     2016-11-07 20:27:09   trigDst_8883C2  noConfig
     2016-11-07 20:27:09   trigger_cnt     1
   Helper:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
     Tmpl:
Attributes:
   group      Steuerung Beleuchtung
   model      HM-MOD-Em-8
   peerIDs    00000000,
   room       Perimeter,_HOMEMATIC

Ich hoffe ich habe den richtigen Zeitraum gewählt (dazwischen funken kann wenn nur der Bewegungsmelder (HM-SEC-MDIR)):

2016.11.07 20:55:09.715 0: HMLAN_Send:  HMLAN1 I:K
2016.11.07 20:55:09.725 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0986188 d:322392 O:8883C2 t:0594DA15 IDcnt:0006 L:24 %
2016.11.07 20:55:34.721 0: HMLAN_Send:  HMLAN1 I:K
2016.11.07 20:55:34.730 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0986188 d:322392 O:8883C2 t:05953BC7 IDcnt:0006 L:24 %
2016.11.07 20:55:39.538 0: HMLAN_Parse: HMLAN1 R:E161D0E   stat:0000 t:05954E88 d:FF r:FFCD     m:39 8441 161D0E 000000 01BB2240
2016.11.07 20:55:59.725 0: HMLAN_Send:  HMLAN1 I:K
2016.11.07 20:55:59.733 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0986188 d:322392 O:8883C2 t:05959D76 IDcnt:0006 L:24 %

Seit dem Neustart habe ich am Modul oder in Fhem nicht gedrückt etc. Es müsste sich wenn nur der Channel 08 auf "open" umstellen... ;-(

Hallo,

also ich glaube es ist wichtig, dass nach einem regSet der Kanal auch wirklich dann einmal getriggert wird. Ich glaube das das ursächlich war.

Aber ich muss das noch weiter testen.

in deinem log ist nur eine message von 161D0E zu sehen.

wenn du das attr logids nur mit dem namen des em-08 setzt, werden auch nur diese messages gelogt.
bei jedem spannungsereignis sollte dann eine message kommen.
mit attr expert kannst du mehr register sichtbar machen.
event-min-interval würde ich vorerst löschen. mit dem attr kannst du nur events reduzieren, nicht zusätzlich generieren. mir ist unklar, ob es in dieser form nicht sogar andere events unterdrückt.

Zitat von: spel am 08 November 2016, 10:56:42
Hallo,

also ich glaube es ist wichtig, dass nach einem regSet der Kanal auch wirklich dann einmal getriggert wird. Ich glaube das das ursächlich war.

Aber ich muss das noch weiter testen.

Auf alle Fälle! Der EM-8 ist von der Sache her eine Fernbedienung, bei denen muss man generell knöppchen drücken wenn man was will. Wobei meist ein "Tastendruck" (also nicht unbedingt Konfigknopf) ausreicht, ich lasse bei meiner Garagentorerkennung immer das Garagentor kurz fahren wenn ich was ändere  ;)

Gruß Otto

Das gilt für lazyconfig devices. Wenn ein Knopf mit der zentrale gepeert ist, oder garnicht, dann werden pending Kommandos uebertragen.
Das peering ist essentiell

Zitat von: martinp876 am 08 November 2016, 21:43:02
Das gilt für lazyconfig devices. Wenn ein Knopf mit der zentrale gepeert ist, oder garnicht, dann werden pending Kommandos uebertragen.
Das peering ist essentiell

Tut mir leid Martin, dass verstehe ich nicht.

Gruß Otto

Hallo,

es scheint jetzt zu funktionieren. Ich hatte wie gesagt nicht nur die Register gesetzt, sondern auch dann physikalisch getriggert. Allen voran ein Hardware-Reset über Fhem..

Danke auf jeden Fall für die Hilfe hier.

Zitat von: Otto123 am 08 November 2016, 21:49:39
Tut mir leid Martin, dass verstehe ich nicht.

Also wie ich das verstanden habe: So wie Du schon richtig sagst kann man den EM-8 als "lazyConfig"-fähig auch programmieren infolge einer Gerätekommunikation, etwa bei Statusänderung. Sendet das Gerät eine Statusänderung, so kann quasi mit dem ACK der Hinweis kommen: "ich habe da noch ein paar Konfigurationen für dich". Daraufhin meldet sich das Gerät dann empfangsbereit und die Daten werden ausgetauscht.
Mit FHEM klappt das aber nur, wenn es auch als peer eingetragen ist, d.h. ein ACK an den Statussender liefert. Ein Senden an "broadcast" wie bei frisch angelernten EM-8 müsste demnach nicht für ein lazyConfig ausreichen. Könnte ich mal checken - ich habe ein paar ungepeerte Channels an einem EM-8.

Nachtrag: laut Martin auch bei "broadcast" (also ungepeert). Halt nicht bei ausschließlichem Peering mit anderem HM-Gerät, weil sich FHEM da nicht in den ACK reinhängen kann. Dann wäre aber peering nicht essentiell. Hm...  :-\

Zitat von: Pfriemler am 08 November 2016, 23:50:25
Also wie ich das verstanden habe: So wie Du schon richtig sagst kann man den EM-8 als "lazyConfig"-fähig auch programmieren infolge einer Gerätekommunikation, etwa bei Statusänderung. Sendet das Gerät eine Statusänderung, so kann quasi mit dem ACK der Hinweis kommen: "ich habe da noch ein paar Konfigurationen für dich". Daraufhin meldet sich das Gerät dann empfangsbereit und die Daten werden ausgetauscht.
Mit FHEM klappt das aber nur, wenn es auch als peer eingetragen ist, d.h. ein ACK an den Statussender liefert. Ein Senden an "broadcast" wie bei frisch angelernten EM-8 müsste demnach nicht für ein lazyConfig ausreichen. Könnte ich mal checken - ich habe ein paar ungepeerte Channels an einem EM-8.

Nachtrag: laut Martin auch bei "broadcast" (also ungepeert). Halt nicht bei ausschließlichem Peering mit anderem HM-Gerät, weil sich FHEM da nicht in den ACK reinhängen kann. Dann wäre aber peering nicht essentiell. Hm...  :-\

Ich glaube ich fange an zu verstehen - mann mann mann ganz schön kompliziert...

Ist ein device gepairt der Kanal aber nicht gepeert sendet das devicean die zentrale. Das ist kein broadcast.
Ergo ist im Bezug auf lazyconfig ein peeren mit der zentrale gleich dem ungepeerten Zustand.

Broadcast wird gesendet wenn weder gepeert noch gepairt ist.

Es ist nicht möglich an ein device weitere messages nach einem trigger zu uebertragen wenn dies kein ACK von der zentrale anfordert.

Ich gehe davon aus, dass alle devices gepairt sind. Bei lazyconfig devices will ich bei egal welchen button gepresst wird das config ausloesen. Ich habe also einen virtual channel der vccu definiert welchen ich mit alles Kanälen jedes lazyconfig devices peere. Nur zu diesem Zweck.