HM-MOD-EM-8Bit anlernen

[rabehd]

@Pfriemler

Sorry, ich habe Deine Bitte gelesen und den Wiki-Eintrag auch schon mal überflogen. Sah gut aus. Äußern wollte ich mich erst nach gründlichem Lesen.

(Mein Kunde will in einem Monat mit neuem Systen live gehen und ist eigentlich noch nicht zum Test bereit...)

[Pfriemler]

Ah, danke, es tut sich doch noch was. Das Teil haben ja noch mindestens zwei außer mir ...

Ich denke mal, dass das normal ist. Bei Mikrocontrollern gibt es normalerweise Pullup-Widerstände, aber keine Pulldowns. Das ist sinnvoll, da man leichter einen Eingang auf Masse zieht als auf einen anderen definierten Pegel.

Schon. Die sog. Tastereingänge haben sogar noch extra Pullups von 1M (wenn ich mich spontan recht erinnere) extern beschaltet. Die Mikrocontrollereingänge werden dann wahlweise von einem Taster oder - im Falle des Spannungseingangs - von einem Transistor auf GND gezogen. Aus Prozessorsicht ist das ein Wechsel von H nach L, aus Außensicht sind beides aktive Eingriffe - Logik ist normalerweise L-ruhig und wird H-aktiviert. Vor allem im Fall dass man extern Spannungen anlegt, arbeiten die Datenleitungen default invertierend - H-Pegel = Spannung am Eingang ergibt L-Wert. Das ist sinnfrei.
Es wäre nicht das erste Mal, dass ELV/eQ3 solche Designpannen in der CCU2 hintergründig "korrigiert". Deswegen ja meine Frage wie die Kollegen das dort angezeigt bekommen, und wenn anders, dann die Frage, ob wir es hier ebenso machen. Das zu ändern macht nur Sinn, wenn das Teil noch nicht im großen Stil im Umlauf ist, sonst müssten alle ihre Routinen wieder umschreiben. Das gilt auch auch für das "unknown".

Möglicherweise vermutet auch kaum jemand, dass es in einem Thread mit dem Titel um ein anderes Device und auch gar nicht mehr ums Anlernen geht.

Üblicherweise haben wir im FHEM-Forum (so erkenne ich das) aber EINEN Startthread für ein neues Gerät und das ist genau dieser, in dem am besten ALLES relevante zum Device landet. Und im übrigen geht es mir die ganze Zeit um genau das EM-8bit aus dem Threadtitel. Das EM-8 ist seit langem "fertig".

@rabehd: Danke für Meldung, ich habe Geduld ...

[Thorsten Pferdekaemper]

Üblicherweise haben wir im FHEM-Forum (so erkenne ich das) aber EINEN Startthread für ein neues Gerät

Aha... Dann sollte man aber den Thread-Titel ändern in "Alles über..."

im übrigen geht es mir die ganze Zeit um genau das EM-8bit aus dem Threadtitel. Das EM-8 ist seit langem "fertig".

Sorry, da hatte ich irgendwie Tomaten auf den Augen. ...oder Kürbisse.

Gruß,
   Thorsten

[Pfriemler]

Aha... Dann sollte man aber den Thread-Titel ändern in "Alles über..."

Hast Du völlig recht. Würde ich ja gern, aber das kann nur Martin oder der TE. Der hat es auf mein Drängen im #32 ja immerhin schon geschafft, den Fred von "Anfänger" nach "Homematic" zu schieben. Im übrigen hattest Du im Laufe dieses Threads durchaus den Durchblick ...

[Thorsten Pferdekaemper]

Im übrigen hattest Du im Laufe dieses Threads durchaus den Durchblick ...

Ah jetzt ja... eine Insel... 
Meine Anmerkungen von gestern waren auch nicht als Gemotze gemeint, sondern zum Herausfinden warum die Resonanz vielleicht so klein ist. Aber jetzt geht's ja weiter.
Gruß,
   Thorsten

[martinp876]

Kann ich die rohen Register des device sehen ?

Die Register sollten wie folgt erscheinen (und da ist paircentral im device
defined0106: HM-MOD-EM-8Bit list: register | range | peer | description
0: pairCentral | 0 to 16777215 | | pairing to central
################## y_Tr### list: register | range | peer | description
1: dInProp0 | literal | | Data Input Propertie options:on,off 1: dInProp1 | literal | | Data Input Propertie options:on,off
1: dInProp2 | literal | | Data Input Propertie options:on,off 1: dInProp3 | literal | | Data Input Propertie options:on,off
1: dInProp4 | literal | | Data Input Propertie options:on,off 1: dInProp5 | literal | | Data Input Propertie options:on,off
1: dInProp6 | literal | | Data Input Propertie options:on,off 1: dInProp7 | literal | | Data Input Propertie options:on,off
1: dataTransCond | literal | | dataTransmitCondition options:sndImmediateDisable,sndImmediateEnable,lvlChng_H_L,stbl4TimeDisable,stbl4TimeEnable,lvlChng_any,lvlChng_L_H
1: dblPress | 0 to 1.5s | | time to detect double press
1: longPress | 0.3 to 1.8s | | time to detect key long press
1: sign | literal | | signature (AES) options:on,off
1: stabFltTime | 10 to 111600s | | stability filter time
4: expectAES | literal | required | expect AES options:on,off
4: peerNeedsBurst | literal | required | peer expects burst options:on,off
################# y_Btn_01### list: register | range | peer | description
1: dblPress | 0 to 1.5s | | time to detect double press
1: longPress | 0.3 to 1.8s | | time to detect key long press
1: sign | literal | | signature (AES) options:on,off
4: expectAES | literal | required | expect AES options:on,off
4: peerNeedsBurst | literal | required | peer expects burst options:on,off
################## y_Btn_02### list: register | range | peer | description
1: dblPress | 0 to 1.5s | | time to detect double press
1: longPress | 0.3 to 1.8s | | time to detect key long press
1: sign | literal | | signature (AES) options:on,off
4: expectAES | literal | required | expect AES options:on,off
4: peerNeedsBurst | literal | required | peer expects burst options:on,off

[Pfriemler]

Kann ich die rohen Register des device sehen ?

Was meinst Du damit?
Martin, die Register erscheinen aktuell natürlich (fast) so wie von Dir heute gepostet. Aber sie stimmen nicht mit den Möglichkeiten des Moduls überein:

Siehe auch meinen Post #56 in diesem Thread. Da habe ich alles schon erwähnt (es zu wiederholen empfinde ich als Platzverschwendung  )...

Z.B. im Registerset des Device:
a) Geräteregister EM-8bit:

Code Auswählen Erweitern

list:         register | range              | peer     | description
   0: pairCentral      |   0 to 16777215    |          | pairing to central
Zum Vergleich: die des EM-8 (ohne bit):

Code Auswählen Erweitern

0: ledMode          |     literal        |          | LED mode options:off,on
   0: localResDis      |     literal        |          | local reset disable options:off,on
   0: lowBatLimitBA2   |   0 to 15V         |          | low batterie limit, step .1V
   0: pairCentral      |   0 to 16777215    |          | pairing to central
   0: transmDevTryMax  |   1 to 10          |          | max message re-transmit
Zumindest von ledMode, transmDevTryMax und einer Batterieschwelle (wobei die ja mal mit BA, mal mit BA2 und mal mit BA3 endet, je nach Device) ist gesichert, dass diese adäquaten Einstellungen in der CCU2 verfügbar sind, der Artikel von ELV referenziert auch darauf. Das hätte ich gern auch im EM-8bit.

An den Button-Kanälen 1 und 2 habe ich nichts auszusetzen. 

Im Kanal 3 kranken die dInProp(X) reell an einer wechselnden Sortierung "on,off" und "off,on", das sieht in Deinem Post geordnet aus. Auch hier mein List siehe #56.

Wunschzettel 1c) in Post #56 beziehen sich auf den Post davor, #55:

Der Versuch, auf Devicebene ein "set ... regSet ledMode on" zu setzen, endet in

Code Auswählen Erweitern

ledMode failed: supported register are dblPress expectAES longPress pairCentral peerNeedsBurst sign
...

Aktuell dürfte aber nur der derzeit gelistete pairCentral dort erwähnt werden. Alle übrigen Register sind nur in den Kanälen erlaubt.

Und dann wäre da noch die Frage nach dem "unknown" im Status. Dimmer liefern als Status ja auch einfach eine Zahl (ebenso in level, pct), die sich einfacher auswerten ließe. Das "unknown" ist in gewisser Hinsicht sogar eine gute (Zwischen-)Lösung, weil die Level niemals irgendwelchen üblicherweise in FHEM bekannten festen Leveln wie on, off, closed, open etc entsprechen, und ein geübter Programmer liest aus den beiden Hexa-Werten mühelos das Bitmuster der Eingänge heraus. Vielleicht ist es doch gar keine schlechte Idee, selbst eine Umwandlung in eine Zahl zu machen (den Tipp mit dem userReading würde ich ins Wiki schreiben). Nur falls jemand doch noch eine bessere Idee hat, bitte her damit.

Wenn ich noch mit was dienen kann, bitte sagt es!

[martinp876]

Ok, schaue ich durch.
Dennoch, die readings mit den hexwerten sind interessant. Das was bei archConfig gesichert wird. Oder die readings direkt mit Hex.

[Pfriemler]

Ach ... ich hoffe ich habe das jetzt richtig gemacht, das Modul liegt sein einer Woche brach, daher die Daten von einer Woche.

Device:

Code Auswählen Erweitern

     2017-05-14 19:15:50   RegL_00.          02:01 05:00 0A:14 0B:11 0C:AB 12:00 14:03 18:00  00:00
Kanal 1:

Code Auswählen Erweitern

    2017-05-14 19:15:51   RegL_01.          04:10 08:00 30:03 00:00
Kanal 2:

Code Auswählen Erweitern

    2017-05-14 19:15:52   RegL_01.          04:10 08:00 30:03 00:00
Kanal 3 (Daten - das fällt etwas umfangreicher aus, vielleicht von Interesse):

Code Auswählen Erweitern

   .userReadings:
     HASH(0x4ff9298)
   Readings:
     2017-05-14 19:43:36   .R-dInProp0     on
     2017-05-14 19:43:36   .R-dInProp1     on
     2017-05-14 19:43:36   .R-dInProp2     on
     2017-05-14 19:43:36   .R-dInProp3     on
     2017-05-14 19:43:36   .R-dInProp4     on
     2017-05-14 19:43:36   .R-dInProp5     on
     2017-05-14 19:43:36   .R-dInProp6     on
     2017-05-14 19:43:36   .R-dInProp7     on
     2017-05-07 23:01:52   .R-stabFltTime  1 s
     2017-05-14 19:43:39   .peerListRDate  2017-05-14 19:43:39
     2017-05-14 18:18:14   R-dataTransCond sndImmediateEnable
     2017-05-07 23:01:52   R-sign          off
     2017-05-14 19:43:36   RegL_01.          08:00 30:03 B0:04 B1:21 B2:FF 00:00
     2017-05-15 21:04:36   contact         unknown:81 (to vccu)
     2017-05-15 21:04:36   state           unknown:81
     2017-05-15 21:04:36   trigger_cnt     159
     2017-05-15 21:04:36   value           129
   Helper:
     cfgChkResult No regs found for:

AAZS type:pushButton -
list:peer register         :value
   1:      dInProp0         :on
   1:      dInProp1         :on
   1:      dInProp2         :on
   1:      dInProp3         :on
   1:      dInProp4         :on
   1:      dInProp5         :on
   1:      dInProp6         :on
   1:      dInProp7         :on
   1:      dataTransCond    :sndImmediateEnable
   1:      sign             :off
   1:      stabFltTime      :1 s


Die dInProps habe ich alle händisch gesetzt, ist für die Anschaltung/Auswertung bei mir praktischer. Default waren natürlich alle off.

[martinp876]

alles klar - genau das habe ich gesucht.
Sollte jetzt passen - HMConfig ist in SVN.
teste einmal

[Pfriemler]

Ich krieg jetzt echt die Krise. Was zum Donnergrummel kackt hier denn ständig dazwischen?
In Kurzform: Es hat sich nichts geändert.

Ich habe folgendes gemacht:
- FHEM-Update, restart.
Keine Änderung.
- 8-bit-Sensor gelöscht und resettet, save (Config)
- zwei Neustarts von FHEM (um auch die letzten Reste aus dem Statefile zu kratzen
- Gerät neu angelernt

Es hat sich nichts geändert.
- Gerät hat immer noch nur "pairCentral"

Code Auswählen Erweitern

list:         register | range              | peer     | description
   0: pairCentral      |   0 to 16777215    |          | pairing to central


edit: Ich habe den Fehler gefunden, siehe weiter unten.

- die Reihenfolge der dInPropX-Literale springt genauso zwischen "on,off" und "off,on".

Code Auswählen Erweitern

list:         register | range              | peer     | description
   1: dInProp0         |     literal        |          | Data Input Propertie options:on,off
   1: dInProp1         |     literal        |          | Data Input Propertie options:off,on
   1: dInProp2         |     literal        |          | Data Input Propertie options:on,off
   1: dInProp3         |     literal        |          | Data Input Propertie options:off,on
   1: dInProp4         |     literal        |          | Data Input Propertie options:on,off
   1: dInProp5         |     literal        |          | Data Input Propertie options:on,off
   1: dInProp6         |     literal        |          | Data Input Propertie options:off,on
   1: dInProp7         |     literal        |          | Data Input Propertie options:off,on
   1: dataTransCond    |     literal        |          | dataTransmitCondition options:lvlChng_any,stbl4TimeEnable,lvlChng_L_H,lvlChng_H_L,sndImmediateDisable,sndImmediateEnable,stbl4TimeDisable
   1: dblPress         |   0 to 1.5s        |          | time to detect double press
   1: longPress        | 0.3 to 1.8s        |          | time to detect key long press
   1: sign             |     literal        |          | signature (AES) options:off,on
   1: stabFltTime      |  10 to 111600s     |          | stability filter time
   4: expectAES        |     literal        | required | expect AES options:off,on
   4: peerNeedsBurst   |     literal        | required | peer expects burst options:on,off

BTW: stabFltTime darf auch deutlich kürzer als 10 Sekunden sein, default sind 1s. Da stimmt auch noch was nicht.


So.
a) Warum erscheinen die von Martin definierten Register nicht?
b) Wieso ist mal "on,off" und mal "off,on" gelistet? - An welcher Stelle wird die eindeutig definierte Reihenfolge vertauscht?

Ich habe zwei Browser benutzt und auch den Cache gelöscht.

Dabei finde ich ganz klar alle Infos richtig vor:
"version" liefert

Code Auswählen Erweitern

Latest Revision: 14342

File                   Rev   Last Change
...
00_CUL.pm              14119 2017-04-27 11:41:18Z rudolfkoenig
...
10_CUL_HM.pm           14272 2017-05-13 15:52:29Z martinp876
...
00_HMLAN.pm            14073 2017-04-22 13:45:25Z martinp876
...
00_HMUARTLGW.pm        14240 2017-05-10 09:27:09Z mgernoth
...
HMConfig.pm            14341 2017-05-21 19:01:49Z martinp876


In letzterer:

Code Auswählen Erweitern


...
,"0106" => {name=>"HM-MOD-EM-8Bit"          ,st=>'pushButton'        ,cyc=>''      ,rxt=>'c:w:l'  ,lst=>'1,4'          ,chn=>"Btn:1:2,Tr:3:3",}

dann den neuen Block

Code Auswählen Erweitern

,"HM-MOD-EM-8bit"    =>{ lowBatLimitBA2  =>1,transmDevTryMax =>1,localResDis     =>1 
                         ,ledMode         =>1
                         ,transmitTryMax  =>1,eventFilterTime =>1
                         }

und hier ist der Fehler, Martin: es muss "8Bit" heißen (großes B), gerade testweise geändert, tattaaa!
ledMode habe ich gerade gesetzt, funktioniert! (hüpf)


und weiter unten, wie schon von Martin zuvor gepostet,

Code Auswählen Erweitern

  dInProp0        =>{a=>178.0,s=>0.1,l=>1,min=>0    ,max=>1      ,c=>'lit'      ,f=>''      ,u=>''     ,d=>0,t=>"Data Input Propertie"         ,lit=>{off=>0,on=>1}},
  dInProp1        =>{a=>178.1,s=>0.1,l=>1,min=>0    ,max=>1      ,c=>'lit'      ,f=>''      ,u=>''     ,d=>0,t=>"Data Input Propertie"         ,lit=>{off=>0,on=>1}},
  dInProp2        =>{a=>178.2,s=>0.1,l=>1,min=>0    ,max=>1      ,c=>'lit'      ,f=>''      ,u=>''     ,d=>0,t=>"Data Input Propertie"         ,lit=>{off=>0,on=>1}},
  dInProp3        =>{a=>178.3,s=>0.1,l=>1,min=>0    ,max=>1      ,c=>'lit'      ,f=>''      ,u=>''     ,d=>0,t=>"Data Input Propertie"         ,lit=>{off=>0,on=>1}},
  dInProp4        =>{a=>178.4,s=>0.1,l=>1,min=>0    ,max=>1      ,c=>'lit'      ,f=>''      ,u=>''     ,d=>0,t=>"Data Input Propertie"         ,lit=>{off=>0,on=>1}},
  dInProp5        =>{a=>178.5,s=>0.1,l=>1,min=>0    ,max=>1      ,c=>'lit'      ,f=>''      ,u=>''     ,d=>0,t=>"Data Input Propertie"         ,lit=>{off=>0,on=>1}},
  dInProp6        =>{a=>178.6,s=>0.1,l=>1,min=>0    ,max=>1      ,c=>'lit'      ,f=>''      ,u=>''     ,d=>0,t=>"Data Input Propertie"         ,lit=>{off=>0,on=>1}},
  dInProp7        =>{a=>178.7,s=>0.1,l=>1,min=>0    ,max=>1      ,c=>'lit'      ,f=>''      ,u=>''     ,d=>0,t=>"Data Input Propertie"         ,lit=>{off=>0,on=>1}},

und deren Verwendung im Kanal 3 des 8bit-Sensors

Code Auswählen Erweitern


,"HM-MOD-EM-8Bit03"  =>{ dataTransCond   =>1,stabFltTime     =>1
                         ,dInProp0        =>1,dInProp1        =>1,dInProp2        =>1,dInProp3        =>1
                         ,dInProp4        =>1,dInProp5        =>1,dInProp6        =>1,dInProp7        =>1
                        }



Das ist dann einer der Momente, wo ich mich echt frage, ob ich nicht zu openHAB wechseln sollte ... 

P.S.: nein, natürlich nicht...