Hallo,
ich habe mir das Sendemodul HM-MOD-EM-8Bit zugelegt.
Jetzt beim Anlernen komme ich nicht ganz zurecht .
Wenn ich es anlerne dann habe ich nur drei Kanäle !?
eigentlich müsste ich doch 8 haben , oder ?
channel_01 HM_518F0A_Btn_01
channel_02 HM_518F0A_Btn_02
channel_03 HM_518F0A_Tr
was mache ich falsch ?
Hi,
schick mal ein list von dem Device mit den drei Kanälen.
Gruß,
Thorsten
siehe hier
3 Übertragungskanäle: 2x Taster, 1x Daten, 8 Bit
MfG
Hallo Wendeling,
Das Ding ist noch nicht angelernt:
2017-02-18 13:06:59 R-pairCentral set_0xF11234
Bitte fertig anlernen, getConfig machen.
hmInfo definieren getConfigCheck machen, Fehler abarbeiten.
list bitte in Codetags (#Taste über dem :-X) posten und nicht als Anhang ::)
Den Thread eventuell nach Homematic verschieben.
Gruß Otto
lastMsg No:1D - t:40 s:518F0A d:F11234 4105
das Teil ist schon angelernt, ohne dass ich jetzt Otto123 ärgern will
das Teil ist noch recht neu, ob da bereits alles geht ?
und wenn noch set_.. in den readings steht ist ein getConfig immer angebracht
Zitat von: wendeling am 18 Februar 2017, 13:14:25was mache ich falsch ?
Nichts.
HM-MOD-EM-8 != HM-MOD-EM-8Bit
ok, aber was soll ich dann anders machen . Das model habe ich umbenannt .
keine Reaktion !
wie bekomme ich nun die 8 Schalter ?
Hi,
das Model umbenennen bringt nichts. Wenn Du daheim ein Pferd hast, aber einen Hund willst, dann nützt es auch nichts, wenn Du zu dem Pferd dauernd "Hund" sagst.
Wie schon gesagt: Mach von den Ding mal ein list und stell das hier rein.
Gruß,
Thorsten
Internals:
CFGFN
CUL868_MSGCNT 15
CUL868_RAWMSG A0B12A240518F0AF112344204::-63.5:CUL868
CUL868_RSSI -63.5
CUL868_TIME 2017-02-19 13:06:45
DEF 518F0A
IODev CUL868
LASTInputDev CUL868
MSGCNT 15
NAME HM_518F0A
NOTIFYDEV global
NR 1316
STATE CMDs_pending
TYPE CUL_HM
channel_01 HM_518F0A_Btn_01
channel_02 HM_518F0A_Btn_02
channel_03 HM_518F0A_Tr
lastMsg No:12 - t:40 s:518F0A d:F11234 4204
protCmdPend 16 CMDs_pending
protLastRcv 2017-02-19 13:06:45
protSnd 9 last_at:2017-02-19 13:06:45
protState CMDs_pending
rssi_at_CUL868 lst:-63.5 cnt:15 avg:-61.86 min:-70 max:-56.5
Readings:
2017-02-19 12:59:58 CommandAccepted yes
2017-02-19 13:06:26 D-firmware 1.0
2017-02-19 13:06:26 D-serialNr NEQ1547303
2017-02-19 12:59:58 R-pairCentral set_0xF11234
2017-02-19 13:06:49 RegL_00.
2017-02-19 13:06:45 battery ok
2017-02-19 13:09:33 state CMDs_pending
cmdStack:
++A001F11234518F0A00040000000000
++A001F11234518F0A01040000000001
++A001F11234518F0A0103
++A001F11234518F0A02040000000001
++A001F11234518F0A0203
++A001F11234518F0A03040000000001
++A001F11234518F0A0303
++A001F11234518F0A00040000000000
++A001F11234518F0A01040000000001
++A001F11234518F0A0103
++A001F11234518F0A02040000000001
++A001F11234518F0A0203
++A001F11234518F0A03040000000001
++A001F11234518F0A0303
++A001F11234518F0A01040000000001
++A001F11234518F0A0103
Helper:
HM_CMDNR 18
cSnd 01F11234518F0A0006,01F11234518F0A00040000000000
mId 0106
rxType 28
supp_Pair_Rep 0
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +518F0A,02,00,00
nextSend 1487506005.63045
prefIO
rxt 2
vccu
p:
518F0A
00
00
00
Mrssi:
mNo 12
Io:
CUL868 -61.5
Prt:
bErr 0
sProc 2
Q:
qReqConf
qReqStat
Role:
dev 1
Rpt:
IO CUL868
flg A
ts 1487506005.53367
ack:
HASH(0x2b36078)
128002F11234518F0A00
Rssi:
At_cul868:
avg -61.8666666666667
cnt 15
lst -63.5
max -56.5
min -70
Shadowreg:
RegL_00. 02:01 0A:F1 0B:12 0C:34
Attributes:
IODev CUL868
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-MOD-EM-8Bit
room KG Geräte
serialNr NEQ1547303
subType pushButton
webCmd getConfig:clear msgEvents
Hi,
ZitatprotCmdPend 16 CMDs_pending
protLastRcv 2017-02-19 13:06:45
protSnd 9 last_at:2017-02-19 13:06:45
protState CMDs_pending
AnlernTaste /ConfigTaste drücken. Datenübertragung abarbeiten da muss CMDs done stehen.
Und bitte Hinweise befolgen, also nochmal:
hmInfo definieren getConfigCheck machen, Fehler abarbeiten.
Gruß Otto
Hallo,
ich kann machen was ich mag. Es ist immer das gleiche Ergebnis: 3 Kanäle !!
Wer kann mir noch helfen Step by step
Zitat von: wendeling am 19 Februar 2017, 16:38:53
Hallo,
ich kann machen was ich mag. Es ist immer das gleiche Ergebnis: 3 Kanäle !!
ist doch auch richtig lt. den lists
wenn du 8 Kanäle haben willst mußt du auch das richtige Modul bei ELV bestellen!!
überliest du hier die Beiträge zu deinem Problem?
Zitat von: wendeling am 19 Februar 2017, 16:38:53ich kann machen was ich mag. Es ist immer das gleiche Ergebnis: 3 Kanäle !!
Ja, genau. Es hat drei Kanäle. Wie schon gesagt. Da wirst Du auch nichts daran ändern können.
Weiß jemand, wie das Teil gedacht ist? Es scheint 8 Eingänge zu haben, aber einen weiteren Eingang zur "Datenübernahme". Ich habe dazu auch nirgends eine Anleitung gefunden.
Gruß,
Thorsten
Hallo ,
Es ist ein neues modul !
Das Bit macht es aus . Die alten sind nicht mehr erhältlich !
Hatte erst jetzt den unterschied realisiert !
Vielecht gibt es doch eine Lösung !?
Zitat von: Thorsten Pferdekaemper am 19 Februar 2017, 17:51:53
... Weiß jemand, wie das Teil gedacht ist? Es scheint 8 Eingänge zu haben, aber einen weiteren Eingang zur "Datenübernahme". Ich habe dazu auch nirgends eine Anleitung gefunden. ...
Die Schalt- und Dateneingänge schalten auf Masse oder durch ein Schaltsignal bis 24 V DC , z. B. Mikrocontroller-Port oder Transistor. An den Eingängen IN00, IN10, IN20, DUI30 und an den Dateneingängen INH0 bis INH7 können Steuerspannungen (2–24 V DC ) angeschlossen werden.
MfG
Zitat von: wendeling am 19 Februar 2017, 18:23:13
...
Das Bit macht es aus . Die alten sind nicht mehr erhältlich !
Hatte erst jetzt den unterschied realisiert !
...
Die alten sind aktuell im Shop noch gelistet und können bestellt werden.
MfG
? Also ich sehe im elv Shop nur die 8Bit Version
https://www.elv.de/homematic-8-kanal-sendemodul.html (https://www.elv.de/homematic-8-kanal-sendemodul.html)
Danke !
8Wochen Lieferzeit !!
Zitat von: Ralf W. am 19 Februar 2017, 18:41:59
Die Schalt- und Dateneingänge schalten auf Masse oder durch ein Schaltsignal bis 24 V DC , z. B. Mikrocontroller-Port oder Transistor. An den Eingängen IN00, IN10, IN20, DUI30 und an den Dateneingängen INH0 bis INH7 können Steuerspannungen (2–24 V DC ) angeschlossen werden.
Ok, soweit so gut. ...aber für was ist das dann gedacht? D.h. was macht das Ding mit den ganzen Anschlüssen?
Bei den meisten Geräten ist mir das klar, aber bei dem Ding? Gibt's dazu irgendwo eine Beschreibung?
Gruß,
Thorsten
Hi Thorsten,
hier -> https://www.elv.de/controller.aspx?cid=726&detail=58815
Wenn ich es richtig verstehe, dient das Teil zum Übertragen eines 8 Bit Logik Wertes welcher durch Taster oder Spannungseingänge abgegriffen werden kann.
Damit hat man dann eine Zahl anstatt 8 einzelnen Kanälen.
Gruß Otto
Hi,
tja, eine richtige Beschreibung gibt's wie immer nicht. Dafür muss man bezahlen.
Zitat
Anzahl Kanäle: 2x Taster (Kanal 1 und 2) / 1x Daten (Kanal 3)
Anzahl der Tastereingänge: 2x Taster (negative Logik / low active) 2x Spannungseingang (2–24 V) (positive Logik / high active)
Anzahl der Dateneingänge: 8x Taster (negative Logik / low active) 8x Spannungseingang (2–24 V) (positive Logik / high active) 1x Taster (negative Logik / low active) 1x Spannungseingang (2–24 V) (positive Logik / high active) für die Datenübernahme
Das Ding hat also eine ganze Menge verschiedener Eingänge, aber nur zwei 1-Bit und einen 8-Bit Kanal. D.h. man muss da irgendwas einstellen können. Wie das aber geht, kann man nur sehen, wenn man das XML zu dem Ding hat. Außerdem ist nicht klar, ob da schon alles in FHEM eingebaut ist.
Möglicherweise kann man das Teil so einstellen, dass an den 8 "Kanälen" der Zustand der Eingänge sofort anliegt und man keine "Datenübernahme"-Taste braucht. Dann könnte man aus dem 8-Bit-Wert die einzelnen Bits auseinanderdröseln (per notify oder userReadings) und dem Device als einzelne Readings geben.
...allerdings muss erst einmal klar sein, wie man das Ding konfiguriert und ob es in FHEM überhaupt schon komplett unterstützt ist. Also am besten nach Homematic verschieben.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 20 Februar 2017, 07:53:48
Wie das aber geht, kann man nur sehen, wenn man das XML zu dem Ding hat.
https://github.com/eq-3/occu/blob/master/firmware/rftypes/rf_em_8_bit.xml (https://github.com/eq-3/occu/blob/master/firmware/rftypes/rf_em_8_bit.xml)
Hi,
also das sieht so aus, als ob die zwei Key-Kanäle ganz normale Tastereingänge sind.
Zu dem 8Bit-Kanal nehme ich an, dass der "Spannungseingang (2–24 V) (positive Logik / high active) für die Datenübernahme" als so eine Art Clock-Eingang gedacht ist.
Der 8Bit-Kanal hat einen Parameter "DATA_TRAMSMISSION_CONDITION", der folgende Werte annehmen kann:
"LEVEL_CHANGE_DATA[HIGH_to_LOW]"
"LEVEL_CHANGE_DATA[LOW_to_HIGH]"
"LEVEL_CHANGE_DATA[LOW_to_HIGH_and_HIGH_to_LOW]"
"NEW_DATA_STABLE_FOR_TIME_DEFAULT_ENABLE"
"NEW_DATA_SEND_IMMEDIATELY_DEFAULT_ENABLE"
"NEW_DATA_STABLE_FOR_TIME_DEFAULT_DISABLE"
"NEW_DATA_SEND_IMMEDIATELY_DEFAULT_DISABLE"
Wenn das Ding schon in FHEM verfügbar ist, dann müsste sich das in irgendwelchen "Registern" widerspiegeln.
Außerdem gibt es DATA_INPUT_PROPERTIE_IN0 bis DATA_INPUT_PROPERTIE_IN7 als true/false-Wert. Ich nehme an, dass man damit entweder von low- auf high-Aktiv umschalten kann oder das entsprechende Bit deaktiviert.
So, jetzt für wendeling: Kannst Du mal geeignete Taster anschließen und ausprobieren, was in FHEM mit Kanal 3 passiert, wenn man darauf rumdrückt? Dann vielleicht auch mal mit den oben genannten Einstellungen rumspielen.
Gruß,
Thorsten
Ich habe mal auf meinem rumgedrückt. :)
Die beiden ersten Kanäle sind Taster. Es wird also ein Short oder Long gesendet (soweit ich mich erinnere).
Der dritte Kanal sendet abhängig vom Modus. Der Modus bei Lieferung bedeutet, dass erst gesendet wird, wenn Taster 3 gedrückt wird.
Dann wird eine Binärzahl aus den Schaltern an den 8 Eingängen gebildet und übertragen. Ist kein Schalter dran, dann ist das FF.
Ich suche jetzt nach einer Möglichkeit, den Modus zu ändern. Ziel ist es das die Binärzahl gesendet wird, sobald sich an den Eingängen was ändert.
Zitat von: rabehd am 20 Februar 2017, 12:40:29
Ich suche jetzt nach einer Möglichkeit, den Modus zu ändern. Ziel ist es das die Binärzahl gesendet wird, sobald sich an den Eingängen was ändert.
Ich weiß nicht so genau, wie Martin das umsetzt, aber das müsste irgendwie mit "set ... regSet ..." gehen.
Allerdings müsste man auch ein mit "R-" beginnendes Reading sehen, wenn das unterstützt ist.
Hat mal jemand ein list von einem vollständig gepairten Teil mit voll aufgedrehtem expert Attribut?
Gruß,
Thorsten
Ich schalte es heute oder morgen abend mal wieder ein.
ich habe das Teil mal rausgeworfen und neu angelernt.
Richtig gepairt ist es wohl nicht. (R-pairCentral set_0x150815) Es war aber vorher auch schon so.
List HM_519034 bringt das:
Internals:
CFGFN
DEF 519034
IODev SCC
LASTInputDev SCC
MSGCNT 5
NAME HM_519034
NOTIFYDEV global
NR 2076
SCC_MSGCNT 5
SCC_RAWMSG A0C02A2415190341503130301FF::-63:SCC
SCC_RSSI -63
SCC_TIME 2017-02-20 17:58:29
STATE CMDs_pending
TYPE CUL_HM
channel_01 HM_519034_Btn_01
channel_02 HM_519034_Btn_02
channel_03 HM_519034_Tr
lastMsg No:02 - t:41 s:519034 d:150313 0301FF
protCmdPend 9 CMDs pending
protLastRcv 2017-02-20 17:58:29
protSnd 4 last_at:2017-02-20 17:58:29
protState CMDs_pending
rssi_at_SCC lst:-63 max:-58.5 avg:-60 min:-63 cnt:5
Readings:
2017-02-20 17:56:09 CommandAccepted yes
2017-02-20 17:56:09 D-firmware 1.0
2017-02-20 17:56:09 D-serialNr NEQ1546982
2017-02-20 17:56:09 R-pairCentral set_0x150313
2017-02-20 17:58:29 battery ok
2017-02-20 17:57:15 state CMDs_pending
cmdStack:
++A00115031351903400040000000000
++A00115031351903401040000000001
++A0011503135190340103
++A00115031351903402040000000001
++A0011503135190340203
++A00115031351903403040000000001
++A0011503135190340303
++A00115031351903403040000000001
++A0011503135190340303 Helper:
HM_CMDNR 2
cSnd 01150313519034000802010A150B030C13,011503135190340006
mId 0106
rxType 28
supp_Pair_Rep 0
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +519034,02,00,00
nextSend 1487609909.34417
prefIO
rxt 2
vccu
p:
519034
00
00
00
Mrssi:
mNo 02
Io:
SCC -61
Prt:
bErr 0
sProc 2
try 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rpt:
IO SCC
flg A
ts 1487609909.24922
ack:
HASH(0x53a3720)
02800215031351903400
Rssi:
At_scc:
avg -60
cnt 5
lst -63
max -58.5
min -63
Shadowreg:
RegL_00. 02:01 0A:15 0B:03 0C:13
Tmpl:
Attributes:
IODev SCC
IOgrp VCCU:SCC
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-MOD-EM-8Bit
room CUL_HM
serialNr NEQ1546982
subType pushButton
webCmd getConfig:clear msgEvents
ein list HM_519034_Tr bringt das:
Internals:
CFGFN
DEF 51903403
NAME HM_519034_Tr
NOTIFYDEV global
NR 2080
STATE unknown:FF
TYPE CUL_HM
chanNo 03
device HM_519034
Readings:
2017-02-20 17:58:29 contact unknown:FF (to VCCU)
2017-02-20 17:58:29 state unknown:FF
2017-02-20 17:58:29 trigger_cnt 1
Helper:
getCfgList all
getCfgListNo ,4
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Tmpl:
Attributes:
model HM-MOD-EM-8Bit
Ist das irgendwie hilfreich?
Was habe ich bisher falsch gemacht?
Hi,
da ist noch "CMDs_pending". Entweder das dauert einfach noch ein bisschen oder Du müsstest nochmal die Anlerntaste drücken.
Wenn das Ding richtig gepairt ist, dann expert mal auf 251_anything setzen.
Gruß,
Thorsten
Anlerntaste hat geholfen. Danke
Jetzt sieht es etwas anders aus.
Das CMDs_pending bleibt aber.
list list HM_519034
Internals:
CFGFN
DEF 519034
IODev SCC
LASTInputDev SCC
MSGCNT 19
NAME HM_519034
NOTIFYDEV global
NR 2076
SCC_MSGCNT 19
SCC_RAWMSG A0C07A2415190341503130305FF::-61.5:SCC
SCC_RSSI -61.5
SCC_TIME 2017-02-20 18:51:21
STATE CMDs_pending
TYPE CUL_HM
channel_01 HM_519034_Btn_01
channel_02 HM_519034_Btn_02
channel_03 HM_519034_Tr
lastMsg No:07 - t:41 s:519034 d:150313 0305FF
protCmdPend 10 CMDs pending
protLastRcv 2017-02-20 18:51:21
protSnd 26 last_at:2017-02-20 18:51:21
protState CMDs_pending
rssi_at_SCC min:-65.5 cnt:19 avg:-60.57 lst:-61.5 max:-56.5
Readings:
2017-02-20 17:56:09 CommandAccepted yes
2017-02-20 18:48:53 D-firmware 1.0
2017-02-20 18:48:53 D-serialNr NEQ1546982
2017-02-20 18:48:54 PairedTo 0x150313
2017-02-20 18:48:54 R-pairCentral 0x150313
2017-02-20 18:48:54 RegL_00. 02:01 05:00 0A:15 0B:03 0C:13 12:00 14:03 18:00 00:00
2017-02-20 18:51:21 battery ok
2017-02-20 18:49:34 state CMDs_pending
cmdStack:
++A0011503135190340303
++A00115031351903403040000000001
++A0011503135190340303
++A00115031351903400040000000000
++A00115031351903401040000000001
++A0011503135190340103
++A00115031351903402040000000001
++A0011503135190340203
++A00115031351903403040000000001
++A0011503135190340303
Helper:
HM_CMDNR 7
cSnd 0115031351903403040000000001,011503135190340303
mId 0106
rxType 28
supp_Pair_Rep 0
Expert:
def 1
det 1
raw 1
tpl 1
Io:
newChn +519034,02,00,00
nextSend 1487613081.66357
prefIO
rxt 2
vccu
p:
519034
00
00
00
Mrssi:
mNo 07
Io:
SCC -59.5
Prt:
bErr 0
sProc 2
Q:
qReqConf
qReqStat
Role:
dev 1
Rpt:
IO SCC
flg A
ts 1487613081.56839
ack:
HASH(0x53a3720)
07800215031351903400
Rssi:
At_scc:
avg -60.5789473684211
cnt 19
lst -61.5
max -56.5
min -65.5
Shadowreg:
Tmpl:
Attributes:
IODev SCC
IOgrp VCCU:SCC
autoReadReg 4_reqStatus
expert 251_anything
firmware 1.0
model HM-MOD-EM-8Bit
room CUL_HM
serialNr NEQ1546982
subType pushButton
webCmd getConfig:clear msgEvents
list HM_519034_Tr
Internals:
CFGFN
DEF 51903403
NAME HM_519034_Tr
NOTIFYDEV global
NR 2080
STATE unknown:FF
TYPE CUL_HM
chanNo 03
device HM_519034
Readings:
2017-02-20 18:48:55 R-dInProp0 off
2017-02-20 18:48:55 R-dInProp1 off
2017-02-20 18:48:55 R-dInProp2 off
2017-02-20 18:48:55 R-dInProp3 off
2017-02-20 18:48:55 R-dInProp4 off
2017-02-20 18:48:55 R-dInProp5 off
2017-02-20 18:48:55 R-dInProp6 off
2017-02-20 18:48:55 R-dInProp7 off
2017-02-20 18:48:55 R-dataTransCond lvlChng_H_L
2017-02-20 18:48:55 R-sign off
2017-02-20 18:48:55 R-stabFltTime 1 s
2017-02-20 18:51:21 contact unknown:FF (to VCCU)
2017-02-20 18:51:21 state unknown:FF
2017-02-20 18:51:21 trigger_cnt 5
Helper:
getCfgList all
getCfgListNo ,4
Expert:
def 1
det 1
raw 1
tpl 1
Role:
chn 1
Shadowreg:
Tmpl:
Attributes:
expert 251_anything
model HM-MOD-EM-8Bit
peerIDs
Hi,
das sieht doch schonmal gar nicht schlecht aus.
Ich denke mal, dass diese Parameter interessant sind:
R-dInProp0 off
R-dataTransCond lvlChng_H_L
Könntest Du damit mal rumspielen? Also sowas wie "set HM_519034_Tr regSet blabla", damit man mal erfährt, was da geht? Dann auf etwas umstellen, was vielleicht NEW_DATA_SEND_IMMEDIATELY_DEFAULT_ENABLE entsprechen könnte.
...und einen Taster anschließen (wahrscheinlich gegen GND), damit rumspielen und dabei den Event Monitor beobachten. Ich glaube, man muss die Taste mindestens 1 Sekunde drücken.
Gruß,
Thorsten
Sagt mal ... da das doch der erste Thread zu dem Teil ist, der wieder nach Kennenlernen und Ausprobieren aussieht, gehört das doch eigentlich direkt nach Homematic verschoben, oder?
Schließe mich da Ottos erstem Post an!
Admins? Wendeling? (Der Threadersteller kann das machen).
Den ELV-Artikel zu dem Ding habe ich gelesen, ihr seid auf der richtigen Fährte. (Die Besitzer des Bausatzes müssten den Artikel ja als Papier vorliegen haben).
Im Artikel wird von ingesamt 7 Übertragungsmodi gesprochen:
Modus 1-3: Sendung bei Änderung des Pegels an DU30 (Taster-Eingang, ist low-aktiv) bzw. Spannungseingang DUI30 (high-aktiv):
Modus 1: Senden bei Änderung H->L (könnte dem zitierten "lvlChng_H_L" entsprechen)
Modus 2: dito bei L->H
Modus 3: Senden bei H->L und L->H
Modus 4 und 6: Senden bei bestimmten Zuständen am Dateneingang (bei Änderung der Bits sozusagen), wenn diese länger als die "Datenstabilitätsfilterzeit" anliegen (bei kurzen Änderungen erfolgt keine Sendung) - ähnlich wie eventFilterTime bei Sensoren: Sendung erst x Sekunden nachdem es eine Änderung gab)
Modus 4: Sendung erfolgt wenn Datenübertragungseingang HIGH (bei low erfolgt keine Sendung)
Modus 6: Dito, aber bei Datenübertragungseingang LOW
Modus 5 und 7: Senden sofort bei Änderung, danach Wartezeit (ähnlich minInterval bei Bewegungsmeldern - Wartezeit nach Meldung einer Bewegung)
Modus 5: Sendung erfolgt wenn Datenübertragungseingang HIGH (bei low erfolgt keine Sendung)
Modus 7: Dito, aber bei Datenübertragungseingang LOW
Jetzt müsste man herausbekommen wie die Register und Modi nach martins Definition heißen.
dInPropX? Sind das die einzelnen Bits oder soll das eine Maske sein für die Triggerung? Davon ist aber nirgends die Rede.
Was liefert regList des Kanal 3? Da stehen doch sonst die möglichen Werte drin.
"stabFltTime" müsste diese "Datenstabilitätsfilterzeit" sein, die dann je nach Modus eine Wartezeit bis zu -oder- nach einer Sendung darstellt.
Jm2c.
mach ich, aber nicht mehr heute abend. morgen hat die bessere Hälfte Spätschicht...
Wenn man einen Taster an den Kanal 3 anschliesst und betätigt (zweifel mal das mindestens an), dann wird anhand der geschlossenen Dateneingänge/Pegel eine Binärzahl gesendet. Soweit der Werkszustand.
Der Modus wird wahrscheinlich im R-dataTransCond stehen? Die Frage ist dann, wie werden die Modi verschlüsselt? Das müsste eigentlich bei HM-MOD-EM-8 genauso sein. Kann da jemand nachschauen?
Der HM-Mod-EM-8 sendet (wie wohl auch das 8bit in den beiden ersten Kanälen) je nach eingestelltem Modus bei kurz/lang-Betätiung (remote) oder Zustandswechsel (im Modus switch ein unbewertetes short, im Modus sensor einen Zustand 200 oder 0 (closed, open - oder umgekehrt). Das wird je nach Kanal im Register "triggerMode" festgelegt.
ZitatDer Modus wird wahrscheinlich im R-dataTransCond stehen?
Sehe ich auch so. Deswegen ja meine Frage nach dem regList, vielleicht stehen dort schon die erlaubten Werte. Bei den condition- und jumptables der Aktoren ist es ja so, und beim EM-8 für den Triggermode steht dort auch "1: triggerMode | literal | | define type of event report options:sensor,switch,button,off ".
reglist Kanal 3:
list: register | range | peer | description
1: dInProp0 | literal | | Data Input Propertie options:off,on
1: dInProp1 | literal | | Data Input Propertie options:on,off
1: dInProp2 | literal | | Data Input Propertie options:off,on
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:off,on
1: dInProp6 | literal | | Data Input Propertie options:off,on
1: dInProp7 | literal | | Data Input Propertie options:on,off
1: dataTransCond | literal | | dataTransmitCondition options:sndImmediateEnable,stbl4TimeEnable,lvlChng_L_H,sndImmediateDisable,lvlChng_any,stbl4TimeDisable,lvlChng_H_L
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:off,on
Ich vermute Modus 1 ist eingestellt. Sendung erfolgt, wenn DU30 geschlossen wird. Ich vermute DUI30 analog. Das Öffnen führt nicht zu einer Sendung.
Ich werde morgen abend mal alles für dataTransCond durchprobieren.
Cool. Die Modi sind doch fast selbstsprechend.
Edit: hab mich verwechselt, korrigiert:
sndImmediateEnable = Modus 5 (oder 7 je nach Pegel - das ist doch unklar und je nach Sichtweise (Taster- bzw. Spannungseingang) unterschiedlich)
sndImmediateDisable wäre das Pendant dazu
"sende sofort" entspricht den Modi 5 und 7, der Datenübertragungseingang gilt dann als ENABLE, entweder H oder L-Aktiv
stbl4TimeEnable = Modus 4 (oder 6, s.o.)
stbl4TimeDisable wäre das Pendant
"sende wenn Zustand stabil für ... (Sekunden)" entspricht den Modi 4 und 6, der Datenübertragungseingang gilt dann als ENABLE, entweder H oder L-Aktiv
lvlChng_L_H = Modus 2 (oder 1)
lvlChng_H_L = Modus 1 (oder 2)
lvlChng_any = Modus 3
Wenn DU30 geschlossen wird und Modus 1 ab Werk aktiv ist (und er dann also sendet), wären die Pegel wohl aus Sicht des Tastereingangs zu verstehen, d.h. H ist offen und L ist geschlossen.
Für diese Theorie spricht auch der übermittelte Wert von 255 (&HFF) - offene Taster = H.
Nachtrag:
im Foto von den CCU-Einstellungen ist vom Modus 0 die Rede. Vielleicht sind die da alle eins nach unten verschoben.
Da gibt es übrigens noch den Wert "Sender für 8-Bit-Entscheidungswert" mit der Erläuterung "Dateineingang invertieren", je Bit anhakbar.
Da kann man wohl je Bit festlegen, ob es L- oder H-aktiv ist - das könnte das fragliche "dInProp..." sein - stehen ab Werk alle auf off, also keine Invertierung.
Hallo, habe gerade mal mal etwas gespielt , und den Kanal3 beobachtet
wenn ich zB. INL0 auf gnd lege dann kommt "FE"
INL1 "FD"
aber bei INL1+INL3 = auch FD
Internals:
CFGFN
DEF 518F0A03
IODev
NAME HM_518F0A_Tr
NOTIFYDEV global
NR 1206
STATE unknown:FD
TYPE CUL_HM
chanNo 03
device HM_518F0A
protState Info_Cleared
Readings:
2017-02-20 22:05:25 contact unknown:FD (to CUL868)
2017-02-20 22:05:25 state unknown:FD
2017-02-20 22:05:25 trigDst_F11234 noConfig
2017-02-20 22:05:25 trigger_cnt 27
Helper:
getCfgList all
getCfgListNo ,4
Expert:
def 1
det 0
raw 1
tpl 0
Prt:
bErr 0
sProc 0
Role:
chn 1
Shadowreg:
Attributes:
model HM-MOD-EM-8Bit
Zitataber bei INL1+INL3 = auch FD
War bestimmt ein Wackler.
Lieber wendeling, verschiebst Du den Thread bitte nach "FHEM Forum » FHEM - Hausautomations-Systeme » Homematic"? Da gehört er m.E. hin.
Das müsste beim Edit des Erstbeitrages möglich sein.
würde ich gerne mache, bekomm es aber nicht gebacken
ok hat funktioniert
Zitat von: wendeling am 20 Februar 2017, 22:14:26
Hallo, habe gerade mal mal etwas gespielt , und den Kanal3 beobachtet
wenn ich zB. INL0 auf gnd lege dann kommt "FE"
INL1 "FD"
aber bei INL1+INL3 = auch FD
Kannst Du dazu mal zeigen, was im Event Monitor ankommt?
Gruß,
Thorsten
hier das Ergebnis aus dem Eventmonitor
kein Eingang geschlossen, DU3 per Taster gegen GND
2017-02-21 19:38:17 CUL_HM HM_519034 battery: ok
2017-02-21 19:38:17 CUL_HM HM_519034_Tr contact: unknown:FF (to VCCU)
2017-02-21 19:38:17 CUL_HM HM_519034_Tr unknown:FF
2017-02-21 19:38:17 CUL_HM HM_519034_Tr trigger_cnt: 19
Eingang INL4 bis INL7 gegen GND geschlossen, DU3 per Taster gegen GND
2017-02-21 19:39:04 CUL_HM HM_519034 battery: ok
2017-02-21 19:39:04 CUL_HM HM_519034_Tr contact: unknown:0F (to VCCU)
2017-02-21 19:39:04 CUL_HM HM_519034_Tr unknown:0F
2017-02-21 19:39:04 CUL_HM HM_519034_Tr trigger_cnt: 22
Der Rest ist sicher analog.
Ich habe jetzt mit "set HM_519034_Tr regset dataTransCond sndImmediateEnable" das Register für den Modus verändert.
Ergebnis: Jede Änderung an einem Eingang INL wird sofort gesendet und erzeugt ein Event.
Genau das was ich wollte.
Danke an die Unterstüzung von Pfriemler und Thorsten Pferdekaemper.
Was sollte man jetzt noch tun? Einen Gerätetyp anlegen für die Nächsten? Wie kann ich unterstützen?
Zitat von: rabehd am 21 Februar 2017, 20:11:27Was sollte man jetzt noch tun? Einen Gerätetyp anlegen für die Nächsten? Wie kann ich unterstützen?
Wieso neuer Gerätetyp? Das Ding funktioniert doch wunderbar, oder?
Was man jetzt machen sollte:
1. Wiki-Eintrag zu dem Ding anlegen mit den Erkenntnissen aus diesem Thread.
2. Eine kleine Routine schreiben, die das state oder contact Reading in einzelne on/off oder so Readings übersetzt.
Viel Spaß.
Gruß,
Thorsten
Das Wiki hatte ich schon aufm Zettel, basierend auf dem EM-8. Kann aber gern jemand anderes machen. Ein Foto wäre schön.
Edit: Artikel ist online.
via Tapatalk
Foto kann ich dir liefern. Vermutlich darf man bei ELV nicht kopieren.
Ja bitte! Guck mal dem HM-Mod-EM-8-Foto, so in der Art wäre nett. Ich habe das Mod aber auch auf der Einkaufsliste, wird nur ein bisschen dauern.
Zitat von: rabehd am 26 Februar 2017, 21:57:34
Vermutlich darf man bei ELV nicht kopieren.
Die Regeln für Fotos im Wiki bevorzugen ausdrücklich eigene Fotos mit klarem Copyright. Das Kopieren bei ELV verbietet sich absolut!
Hallo Zusammen,
ich habe dieses Modul zusammen mit Schwimmerschaltern als Spielumgebung aufgesetzt und festgestellt, dass das Modul nicht jedes mal, wenn es Kontakt an einem Spannungseingang feststellt, eine Meldung sendet. Er zählt den Kontakt aber, denn wenn das Modul wieder einen neuen Status verkündet geht der Counter direkt um die Anzahl hoch, die er nicht mitgesendet hat.
Diese Aussetzer sind sporadisch und für mich nicht nachvollziehbar und ich erkenne kein wirkliches Muster.
Hat jemand eine Idee, woran das liegen kann?
Lists vom Modul sowie Channel 3 nachstehend.
Grüße
Nils
DEF 51900A
HMLAN_MSGCNT 105
HMLAN_RAWMSG E51900A,0000,0CD6C87F,FF,FFDA,4EA24151900A2CDA0B0321FF
HMLAN_RSSI -38
HMLAN_TIME 2017-04-13 15:56:54
IODev HMLAN
LASTInputDev SCC
MSGCNT 191
NAME funk_sender1
NOTIFYDEV global
NR 297
NTFY_ORDER 50-funk_sender1
SCC_MSGCNT 86
SCC_RAWMSG A0C4EA24151900A2CDA0B0321FF::-51:SCC
SCC_RSSI -51
SCC_TIME 2017-04-13 15:56:54
STATE CMDs_done
TYPE CUL_HM
channel_01 funk_sender1_Btn_01
channel_02 funk_sender1_Btn_02
channel_03 funk_sender1_Tr
lastMsg No:4E - t:41 s:51900A d:2CDA0B 0321FF
protLastRcv 2017-04-13 15:56:54
protSnd 26 last_at:2017-04-13 15:56:54
protState CMDs_done
rssi_at_HMLAN min:-98 cnt:105 lst:-38 max:-38 avg:-68.17
rssi_at_SCC min:-94.5 cnt:86 max:-51 lst:-51 avg:-75.92
Readings:
2017-04-03 22:48:25 CommandAccepted yes
2017-04-04 14:57:05 D-firmware 1.0
2017-04-04 14:57:05 D-serialNr NEQ1547024
2017-04-13 15:56:10 PairedTo 0x2CDA0B
2017-04-03 21:38:40 R-pairCentral 0x2CDA0B
2017-04-13 15:56:10 RegL_00. 02:01 05:00 0A:2C 0B:DA 0C:0B 12:00 14:03 18:00 00:00
2017-04-13 15:52:56 alive yes
2017-04-13 15:56:54 battery ok
2017-04-13 15:52:56 powerOn 2017-04-13 15:52:56
2017-04-13 15:52:56 recentStateType info
2017-04-13 15:56:54 state CMDs_done
Helper:
HM_CMDNR 78
PONtest 0
cSnd 012CDA0B51900A03040000000001,012CDA0B51900A0303
mId 0106
rxType 28
supp_Pair_Rep 0
Ack:
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newCh 1
newChn +51900A,00,00,00
nextSend 1492091815.02529
rxt 2
vccu VCCU
p:
51900A
00
00
00
prefIO:
HMLAN
Mrssi:
mNo 4E
Io:
HMLAN -36
SCC -51
Prt:
bErr 0
sProc 0
sleeping 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rpt:
IO HMLAN
flg A
ts 1492091814.81556
ack:
HASH(0x49b5338)
4E80022CDA0B51900A00
Rssi:
At_hmlan:
avg -68.1714285714286
cnt 105
lst -38
max -38
min -98
At_scc:
avg -75.9244186046512
cnt 86
lst -51
max -51
min -94.5
Shadowreg:
Attributes:
IODev HMLAN
IOgrp VCCU:HMLAN
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-MOD-EM-8Bit
room Balkon
serialNr NEQ1547024
subType pushButton
webCmd getConfig:clear msgEvents
Internals:
DEF 51900A03
NAME funk_sender1_Tr
NOTIFYDEV global
NR 301
NTFY_ORDER 50-funk_sender1_Tr
STATE unknown:FF
TYPE CUL_HM
chanNo 03
device funk_sender1
Readings:
2017-04-03 22:51:11 R-dataTransCond sndImmediateEnable
2017-04-03 21:38:42 R-sign off
2017-04-13 15:56:13 RegL_01. 08:00 30:03 B0:04 B1:21 B2:00 00:00
2017-04-13 15:56:54 contact unknown:FF (to VCCU)
2017-04-13 15:56:54 state unknown:FF
2017-04-13 15:56:54 trigger_cnt 33
Helper:
peerIDsRaw ,00000000
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Shadowreg:
Attributes:
model HM-MOD-EM-8Bit
peerIDs 00000000,
room Balkon
in welchem Triggermode läuft das Modul?
Ich denke Du brauchst "sensor" -> http://www.fhemwiki.de/wiki/HM-MOD-EM-8_8-Kanal-Sendemodul#Betrieb_mit_FHEM
Gruß Otto
Ich habe, wie von rabehd beschrieben, "regset dataTransCond sndImmediateEnable"
Sollte ja eigentlich dann bei jedem Kontakt einen Status senden.
Das war nicht meine Frage. Ich meinte
Zustandserkennung
Der HM-MOD-EM-8 wird mit dem triggerMode "button" ausgeliefert. Was wir brauchen ist der Triggermode "sensor" damit offene und geschlossen Kontakte angezeigt werden und kein Dauer(funk)feuer bei geschlossenem Kontakt entsteht. Im FHEM Wiki ist das gut erklärt.
Folgender Befehl schaltet alle Kanäle in den "sensor" Modus.
set RC81_.* regSet triggerMode sensor
Gruß Otto
Das ist aber der HM-MOD-EM-8Bit. Da gibts das doch nicht in der Form. Deswegen ja das umstellen mittelns "regset dataTransCond sndImmediateEnable" was ein sofortiges senden aller Änderungen bewirken soll.
Ach sorry, war ich wieder im falschen Film :o
Warum sind die rssi Werte manchmal so schlecht?
Er redet mit dem scc aber der HMLAN ist preffered eingetragen.
Liegt es am Empfang? Kannst Du mal mit loggen? Da müsste man ja missing Ack sehen oder?
Gruß Otto
Sorry, hatte ich komplett überlesen.
Zitat von: fischit am 13 April 2017, 16:21:35
Ich habe, wie von rabehd beschrieben, "regset dataTransCond sndImmediateEnable"
Sollte dann aber nur senden, wenn der Datenübergabeeingang
enabled ist (DU30 auf GND gezogen oder DUI30 mit Spannung versorgt) unbeschaltet ist (DU30 offen und DUI30 offen bzw auf GND gezogen (gerade gemerkt, das Ding funktioniert genau logisch falsch).
Scheint aber zu passen, denn sonst würde das Ding intern keine Counter hochzählen. Ich denke, einzelne Sendungen gehen wegen schlechtem RSSI einfach unter.
Habe mein Modul heute in Betrieb genommen und versuche in den nächsten Tagen endlich den Wiki-Artikel zu erstellen...
Anders als beim EM-8 arbeiten beim EM-8bit die ersten beiden Kanäle offenbar fest im button-Mode, das war mir bisher neu.
Was mir eben noch auffällt:
Die beim HM-MOD-EM-8 verfügbare Aktivierung der LED (ledMode) und die Batterieüberwachungsschwelle (lowBatLimitBA2 o.ä.) sind laut ELV-Journal 01/2017 vorhanden, in FHEM fehlen aber die passenden Register, zumindest laut "get ... regList". Da gibt es nur pairCentral.
Der Versuch, auf Devicebene ein "set ... regSet ledMode on" zu setzen, endet in
ledMode failed: supported register are dblPress expectAES longPress pairCentral peerNeedsBurst sign
Davon wiederum sind die meisten eigentlich nur auf Kanalebene nutzbar.
Martin? ;)
So, Wiki ist online.
Mein Wunschzettel für das Modul (und da möchte ich Martin nochmal herzlich bitten, ich habs selber nicht gepackt) erweitert sich:
1a) - ledMode im Gerät nachrüsten (man kann natürlich auch eine LED an den Pins anlöten, aber onboard ist praktischer)
1b) - lowBat, dito
Wie schon gesagt: beides geht laut ELV mit der CCU2 einzustellen.
1c) "supported register" bei den Kanälen korrigieren: "pairCentral" gehört nur ins Gerät, "dblPress expectAES longPress peerNeedsBurst sign" sind buttontypisch für Kanal 1 und 2, im Kanal 3 dürften dblPress und longPress obsolet sein, weil nur Stati ausgewertet werden.
2) Und dann stört mich da noch der Präfix "unknown:XX" im Kanal 3 vor den Werten. Wie soll man das vernünftig auswerten?
Könnte man den Wert nicht bitte einfach als Dezimalwert liefern? (0-255).
Oder anderer Vorschlag? Wird Hexadezimal (wie derzeit) als praktischer empfunden?
edit: Nutze dazu aktuell userReadings mit der Definition "value {hex(substr(ReadingsVal("<EM-8bit_data_channel>","state","unknown:FF"),8))}" - funzt.
3) Fast nur noch ein Schönheitsfehler:
list: register | range | peer | description
1: dInProp0 | literal | | Data Input Propertie options:off,on
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:off,on
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:on,off
- alles auf "off (default), on" oder wenigstens gleich ...
Wie sehen das die anderen Modulnutzer?
@fischit, @rabehd: Könntet Ihr bitte den Wiki-Artikel querlesen und ggf. bemeckern?
Ich stelle mir außerdem die Frage, ob es wirklich von ELV gewollt ist, offene Eingänge als logisch HIGH zu interpretieren. Ich muss mal die Homematic-Kollegen dazu befragen...
Sagt mal, mache ich irgendwas falsch? Habe ich mich im Ton vergriffen?
Ich bekomme weder hier, noch per PM, noch bei Homematic Antwort auf meine Fragen zum Modul. Verlange ich zuviel?
Bin ratlos ... :-[
Zitat von: Pfriemler am 15 Mai 2017, 16:05:33
Ich stelle mir außerdem die Frage, ob es wirklich von ELV gewollt ist, offene Eingänge als logisch HIGH zu interpretieren. Ich muss mal die Homematic-Kollegen dazu befragen...
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.
Zitat von: Pfriemler am 19 Mai 2017, 21:04:14
Sagt mal, mache ich irgendwas falsch? Habe ich mich im Ton vergriffen?
Ich bekomme weder hier, noch per PM, noch bei Homematic Antwort auf meine Fragen zum Modul. Verlange ich zuviel?
Also hier kann es sein, dass einfach sonst niemand das Teil hat...
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.
Gruß,
Thorsten
Sorry, wenn ich es übersehen habe.
Welche Register fhem sucht siehst du mit regList. Welche gefunden wurden mit regList.
Lowbat ist vorhanden.
Paircentral ist im device nicht dem Kanal.
Auch ledmode ist vorhanden. im device.
Was also ist die Frage?
Reden wir von Em8?
@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...)
Ah, danke, es tut sich doch noch was. Das Teil haben ja noch mindestens zwei außer mir ...
Zitat von: Thorsten Pferdekaemper am 19 Mai 2017, 21:20:54
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".
ZitatMö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 ...
Zitat von: Pfriemler am 19 Mai 2017, 22:27:49Ü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..."
Zitat
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
Zitat von: Thorsten Pferdekaemper am 19 Mai 2017, 22:42:39
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 ...
Zitat von: Pfriemler am 19 Mai 2017, 22:48:08Im ü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
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
ZitatKann 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 :D)...
Z.B. im Registerset des Device:
a) Geräteregister EM-8bit:
list: register | range | peer | description
0: pairCentral | 0 to 16777215 | | pairing to central Zum Vergleich: die des EM-8 (ohne bit):
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:
ZitatDer Versuch, auf Devicebene ein "set ... regSet ledMode on" zu setzen, endet in
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!
Ok, schaue ich durch.
Dennoch, die readings mit den hexwerten sind interessant. Das was bei archConfig gesichert wird. Oder die readings direkt mit Hex.
Ach ... ich hoffe ich habe das jetzt richtig gemacht, das Modul liegt sein einer Woche brach, daher die Daten von einer Woche.
Device:
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:
2017-05-14 19:15:51 RegL_01. 04:10 08:00 30:03 00:00
Kanal 2:
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):
.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.
alles klar - genau das habe ich gesucht.
Sollte jetzt passen - HMConfig ist in SVN.
teste einmal
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"
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".
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
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:
...
,"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
,"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,
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
,"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 ... ;D
P.S.: nein, natürlich nicht...