HM-MOD-EM-8 Analoge Spannungseingänge

[Pfriemler]

'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):

Code Auswählen Erweitern

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.

[martinp876]

(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"

[Pfriemler]

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.

mode 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?

Mode 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 ...)

[Pfriemler]

So, noch ein Bug vom EM-8, wie ich vermute ... habe ich in 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 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 ....

Code Auswählen Erweitern


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?

[martinp876]

as ändert aber prinzipiell nichts an den letzten beiden Bits

klar - wie gesagt.

Ist das nach Deiner Lesart Byte 3 oder Byte 2?

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

Logisch 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).

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

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?

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

[Pfriemler]

Schö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.

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).

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 ...

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?

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?

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.

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

[martinp876]

Nein, 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.

[Pfriemler]

Hier der EM-8 (diesmal Kanal 1) im Modus 0x22 mit meinem LED-Zwischendeckendimmer:

Code Auswählen Erweitern

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.

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).

Ü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.

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.

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 ...?

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.

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

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

Das hatte MEitelwein schon in 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

[Pfriemler]

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.

[martinp876]

Der 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?

Das 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.

Der 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.

Ganz 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.

0x20 schaltet den  Kanal quasi ab,

#
ist nachgearbeitet.

Habe 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.

[martinp876]

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

angelegt, nicht gespeichert

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?

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

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).

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)

An 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.

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

es gibt keine defaults für Register imCUL_HM modul

- 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

Damit 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.

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

so - nicht besser

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.

[Pfriemler]

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.

...
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:

Code Auswählen Erweitern

   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

Code Auswählen Erweitern

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 ...

[Pfriemler]

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

[Pfriemler]

...
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.

[martinp876]

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

ist die Einheit, habe ich gelöscht.

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 ...

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

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

hm ja...