FHEM Forum
FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: Markus Hermann am 09 April 2013, 09:57:52
-
Hallo Forum,
Homematic ist für mich recht neu.
FHEM hat durch autocreate alle meine Devices korrekt erkannt und ich kann sie per notify auswerten.
Meine HM-RC-Sec3 leuchtet aber nicht grün, wenn ich ein Tastendruck tätige. Muss ich sie noch extra mit meinem HM-LAN-CFG pairen.
Gilt das auch für die HM-SEC-SC's ?
Gruß
Markus
-
Hallo,
für beide gilt: Du musst nicht, aber du solltest.
Solange die Geräte nicht angelernt sind, bekommt FHEM zwar mit, was die Geräte senden senden, was bei Sensoren und FBs ja schon ausreichend sein kann, aber FHEM kann nichts zurückschicken. Darum leuchtet auch die LED nicht grün. Es kommt kein Bestätigung an die FB zurück. Das ist bei den beiden Geräten kein gravierendes Problem, da FHEM ja trotzdem alles mitkriegt, aber spätestens wenn du den Fensterkontakt konfigurieren möchtest, wird das schiefgehen.
-
Hi,
Carsten, du musst peeren und pairen unterscheiden.
pairen (device mit Zentrale) sollte man immer alle!
peeren (channels, also sensoren mit Aktoren) kann man Sensoren sollte man eigentlich auch.
Das Problem, dass nach einer Aktion am Sensor nicht gruen kommt ist, dass dieser keine Antwort bekommt.
1) channel nicht gepeert: Sensor erwartet keine Antwort und leuchtet gelb (orange?)
2) channel ist gepeert: Sensor erwartet eine Antwort. Wenn die nicht kommt-> rot, sonst gruen.
Fall 2 ist zu bevorzugen da der Sensor ggf. die Nachricht wiederholt wenn eine Antwort fehlt. Ist ein Vorteil in Sachen Ausfallsicherheit.
Ich wuerde sensoren (Taster, buttons, fensterkontakte) immer peeren. Entweder (vorrangig) mit einem HM aktor. Wenn der nicht da ist mit eine virtuellen FHEM aktor. Der antwortet dann auch und macht den Sensor gruen ;-)
Gruss
Martin
-
Hallo,
danke für die Aufklärung. Dass der Sensor nur eine Antwort bekommt, wenn er mit einem "echten" Gerät gepeert ist, wusste ich nicht. Ich dachte FHEM als Gegenstelle reicht.
Sorry für die Fehlinformation.
Gruß
Carsten
-
Danke Euch für die Infos.
D. h. wenn der Sensor korrekt gepairt ist (mit Fhem), dann probiert er auch mehrmals das Signal abzusetzen, bis eine Bestätigung von Fhem kommt?
Und wie erstellt man virtuelle FHEMaktoren?
Gruß
Markus
-
Hi Carsten,
sorry, war wohl missverstaendlich. Pair und Peer auseinander halten!!!
Das Device schicht an die gepairte Zentrale Infos. Wenn keine gepairt ist gibt es (glaube ich) einen broarcast ohne wiederholung. Der Fall ist fuer mich nicht relevant, bei mir ist pairen Pflicht.
Der sensor-channel will vom peer ein ein ack. Normal wird 3-mal wiederholt falls es nicht kommt. Ohne peer auch kein ACK. Es ist dem Sensor egal, wer der Peer ist, HM oder FHEM oder virtual.
Wenn FHEM der Sensor ist verlangt FHEM nach einem ACK und wiederholt auch. HMLAN wiederholt sowieso,wenn ein ACK gefordert ist, FHEM setzt noch einen drauf - somit wird auch bei einer CUL wiederholt.
Klar soweit, alle Modi?
Markus,
siehen oben:
pairen = device<-> Zentrale. Hier laufen Info messages due ggf. wiederholt werden.
peeren = sensor-channel<-> actorChannel. Hier laufen trigger die "ge-ackt" werden muessen. Ohne peer kein ACK, keine Wiederholung.
um eine virtuellen Aktor (oder Sensor, egal ) zu erstellen braucht man erst einmal eine HM-entity, also
define <virtName> CUL_HM 111111 # die HMID ist frei waehlbar, 3Byte in hex und darf nicht mit der eines anderen Device uebereinstimmen.
set <virtName> virtual 10 # habe jetzt 10 virtuellen Channels definiert. Diese koennen sensoren und aktoren sein. Sogar beides gleichzeitig. Virtuellen Sensoren sollte nicht mit virtuellen Aktoren zusammenarbeiten!!!
Die Channels heissen btn, ist aber nur ein Namen.
set <sensorChan> peerChan 0 virt_Btn01 single set
fertig
Gruss
Martin
-
Hallo
Ich habe auch das Problem meine beiden HM-SEC-RHS zu "Peeren". Das Pairing war soweit kein Problem. Die Kontakte (offen, geschlossen oder gekippt) werden sauber angezeigt.
Aktuell finde ich folgende Einträge
virtFenster set_? press short press long
virtFenster_Btn1 set_? press short press long
Ich gehe mal davon aus, dass ich diese Einträge nun miteinander verbinden muss.
Den Befehl
set <sensorChan> peerChan 0 virt_Btn01 single set (von martinp876) verstehe ich nun gar nicht mehr.
Wie muss ich nun die "virtFenster" mit der "virtFenster_Btn1" zusammen bringen?
Gruss
Chris
-
Hallo Chris,
du hast vor einen RHS mit FHEM zu peeren um ein ACK zu erhalten?
Wenn der RHS keinen peer wird fuer den Trigger kein Ack geschickt.
Wen er mit der Zentrale gepairt ist (pair, nicht peer) dann sendet er status-Info an die Zentrale.
Muessen muss man nichts, man kann...
Einen RHS habe ich nicht, aber der hat wohl, wie viele remotes, eine LED in verschiedenen Farben? Zeit an, ob die Kommunikation ok war? Musst du bestaetigen.
Man bekommt rot (fehler) gelb(egal) gruen(ok) wenn man eine Aktion macht?
Jedenfalls, wenn du willst, dass der Trigger des RHS einen Empfaenger hat und keinen Broadcast sendet, musst du ihn peeren, sonst nicht. Der Empfaenger muss dann ein ACK schicken auf den Trigger.
Wenn du es nun in der Zentrale verarbeiten willst kannst du hier eine virtuelle Entity erstellen. Da die bereitgestellten virtEntities recht dumm sind und absichtlich klein gehalten wurden sind es Mischlinge. Sie simulieren Aktoren und Remotes.
Als Remote koennen sie das senden eines Triggers simulieren, als Aktor deren Empfang, nicht mehr.
Natuerlich kann man den Status sehen.
Der User sollte eine Entity nur fuer einen Zweck nutzen, aktor oder Sensor, kann es aber mischen, wenn er meint.
In deinem Fall kannst du den RHS mit einem virt-Aktor peeren.
Also erst einen virtuellen Channel definieren, dann peeren.
Um einen virtuellen Channel zu erhalten brauchst du erst ein Device, ist IMMER so,ohne device keinen Channel.
virtFenster ist das Device, die Mutter aller channels virtFenster_Btnxx (koennen mindestens 20 sein, wenn du willst).
Dich interessiert nunmehr nur noch der channel, wie bei den anderen Entities auch.
Also:
Verbinden musst du den RHS mit dem virtFenster_Btn1. Der RHS muss 'vorne'stehen
Gruss
Martin
-
Hallo Martin
Danke für die ausführliche Antwort. Habe aber vergessen zu erwähnen, dass ich in Sachen Perl ein absolutes Greenhorn bin :-).
Ein paar Sachen von deinen Ausführungen denke ich zu verstehen.
Aber bei
"Verbinden musst du den RHS mit dem virtFenster_Btn1. Der RHS muss 'vorne' stehen"
verstehe ich nur "Bahnhof" :-)
Chris
-
Hi Chris,
fuer die Ausfuehrungen, die ich gemacht habe brauchst du kein Perl.
Hast du ein Problem mit der LED und willst du den RHS sensor peeren? Nein-> fertig
ja:
peerst du ihn an eine HM HW? Ja->nutze peerChan wie im Commandref
nein-> du brauchst einen virtual Channel
define virtDev CUL_HM 112233
set virtDev virtual 1 #1 channel reicht
set <rhs> peerChan 0 virt_Btn1 single
fertig <rhs> steht vorne im Kommando, RHS ist mit virt?Btn1 verbunden
Gruss
Martin
-
Martin
Danke für deine Geduld. Aber wie es scheint, bin ich zu blöd, deine Ausführungen umzusetzen.
Also. Am Fenster habe ich den RHS-Sensor "WZ_Fenster". Dieser ist mit gepairt. Die Signale werden sauber empfangen und entsprechen angezeigt (geschlossen, offen, gekippt). Soweit also alles klar. Damit ich aber nur die Rückmeldung erhalte (statt rotes Aufleuchten, das grüne) muss ich den RHS noch peeren.
Damit dies gelingt, erstelle ich einen virtuellen Channel:
define virtFenster CUL_HM 112233
set virtFenster virtual 1
Nach dem Speichern erhalte ich im cfg folgende Eintrag:
define virtFenster CUL_HM 112233
attr virtFenster expert 2_full
attr virtFenster model virtual_1
attr virtFenster peerIDs
attr virtFenster subType virtual
define virtFenster_Btn1 CUL_HM 11223301
attr virtFenster_Btn1 model virtual_1
attr virtFenster_Btn1 peerIDs
attr virtFenster_Btn1 room CUL_HM
attr virtFenster_Btn1 webCmd press short:press long
define FileLog_virtFenster_Btn1 FileLog ./log/virtFenster_Btn1-%Y.log virtFenster_Btn1
attr FileLog_virtFenster_Btn1 logtype text
attr FileLog_virtFenster_Btn1 room CUL_HM
Jetzt setze ich den letzten Befehl:
set WZ_Fenster peerChan 0 virtFenster_Btn1 single
Darauf erhalte ich bei der virtFenster_Btn1 in der
peerList: WZ_Fenster_chn:01,
peerIDs: 1E8E1901,
Der State: set_?
Bei "virtFenster" bleibt die peerIDs leer und der State ebenfalls auf set_?
Chris
-
Hi,
Der State: set_?
kann sein, dass dies beim virtual aktor falsch ist. Der meldet ja nichts zurueck.
mein Fehler, aber kein Problem, einfach ignorieren
Das "device" kann man NIE peeren. Du hast sicher kein einziges device, das gepeert ist, nur gepairt.
virtFenster ist die transmit instanz fuer alle seine Channels. Du hast nur einen.
virtFenster kannst du demnach vergessen.
Beachten solltest du, dass dein RHS den virtFenster_Btn1 als peer hat, das ist wichtig!
Also ein
set WZ_Fenster_chn getConfig
und dann nachsehen.
Beachte dass dein RHS nur config und wakeup kann. Wenn du dem ein Kommando sendest must du
a) warten bis der RHS aufwacht. Macht er so alle 24h
b) Anlernen druecken.
Ich empfehle b)
Sicher hast du gelesen, dass peerChan auf beide Seiten wirkt, den Sensor UND den Aktor.
Schau einmal nach, dass der RHS alle kommandos auch abgearbeitet hat. Im Web Interface stehen die Eintraege "prot..." Die sollte man pruefen, die sind wichtig
Gruss, Martin
-
Martin
Dir ist schon klar, dass ich nur (das heisst maximal) die Hälfte verstehe. Im Moment dreht sich alles in meinem Kopf :-).
Das
set WZ_Fenster_chn getConfig
ergibt
Please define WZ_Fenster_chn first
Und Einträge "prot..." finde ich nirgends. Vielleicht bin ich ja schon blind vor lauter pearing und peering :-)
Chris
-
Hi,
der Befehl bei dir müsste lauten:
set WZ_Fenster getConfig
und die prodcmd Sachen findest du entweder auf der Detailseite dieses devices oder mit
list WZ_Fenster
hoffe das hilft,
Martin
-
Martin.
Jetzt wird es aber verrückt, ausser ich bin b'soffen :-)
Ich verfüge ja über 2 solcher RHS. Den WZ_Fenster und den WZ_Tuere. Die habe ich beide auf Werkeinstellung zurückgesetzt und dann von Grund auf neu eingelesen bzw. gepairt.
Kaum habe ich den WZ_Tuere gepairt, hat dieser immer mit der grünen Farbe geantwortet. Der WZ_Fenster bleibt bei der roten Antwort.
Also habe ich gemäss deiner Anleitung das Peering für den WZ_Fenster vorgenommen:
define virtFenster CUL_HM 112233
set virtFenster virtual 1
set WZ_Fenster peerChan 0 virtFenster_Btn1 single
Immerhin habe ich auf
set WZ_Fenster getConfig
beim State (zum ersten Mal) ein "Missing Ackt" erhalten
Schau dir aber mal die Details des WZ_Tuere an!!!! Hier habe ich noch gar kein Peering vorgenommen....
Also. Jetzt verstehe ich wieder gleich viel (oder sogar noch weniger) als am Anfang :-)
Jetzt habe ich den WZ_Fenster erneut auf Werkeinstellungen zurückgestellt (das Peering vorher gelöscht) und erneut gepairt.
Jetzt erhalte ich zwar nach dem "set WZ_Fenster getConfig" denselben Auszug wie bei WZ_Tuere. Nur das grüne Licht fehlt. Kommt aber auch kein rotes Lichtlein :-)
Also erneut gepeert. Hat aber (bei den Lichtlein) nichts gebracht. Blinkt kurz orange und dann nichts mehr. Die beiden Logs sehen so aus:
WZ_Fenster:
2013-04-11_16:54:59 WZ_Fenster RAWMSG: A0D3086101E8E1900000006010000F9
2013-04-11_16:54:59 WZ_Fenster RSSI: -77.5
2013-04-11_16:54:59 WZ_Fenster contact: geschlossen (to broadcast)
2013-04-11_16:54:59 WZ_Fenster geschlossen
2013-04-11_16:54:59 WZ_Fenster cover: geschlossen
2013-04-11_16:54:59 WZ_Fenster battery: ok
2013-04-11_16:54:59 WZ_Fenster alive: yes
WZ_Tuere:
2013-04-11_16:43:34 WZ_Tuere RAWMSG: A0CCEA4411E90ADF1113401B4C8EB
2013-04-11_16:43:34 WZ_Tuere RSSI: -84.5
2013-04-11_16:43:34 WZ_Tuere contact: offen (to CUL_1)
2013-04-11_16:43:34 WZ_Tuere offen
Der Log virtFenster_Btn1 ist leer
Die Readings (WZ_Fenster):
R-virtFenster_Btn1-expectAES set_off
R-virtFenster_Btn1-peerNeedsBurst set_off
sind beim WZ_Tuere nicht zu finden....
Und umgekehrt sind die RegL_00 und RegL_01 bei der WZ_Fenster nicht zu finden...
Chris
-
Hi Chris,
ich habe noch nicht gesehen, dass dein WZ_Fenster irgend ein Kommando verarbeitet hat.
Solange die Werte auf "set_" stehen haben wir keine Bestaetigung.
Schau dir erst einmal den RHS an und lese ihn aus.
Wichtig: der rhs kann nicht einfach beschriegen werden!!!! Auch nicht gelesen!!!!
du musst das Kommando abschicken, es wird in FHEM gespeichert!
Dann anlernen druecken (oder 24h warten!)
Danach sollte protState auf CMDs_done stehen.
Du kannst mehrere Kommandos in FHEM anschicken - aber am Ende immer anlernen oder Warten. (falls FHEM rebootet nuetzt das warten nichts!! dann ist alles verloren)
Schicke das ergebnis aus
list WZ_Fenster wenn alles gelesen wurde.
Ich will darin kein set_ mehr sehen ;-)
und kein pending irgendwas.
Gruss
Maritn
-
Martin
Ein Wunsch ist mir doch Befehl. Finde keine andere Möglichkeit, das Ergebnis hier anderers anzuzeigen...
Internals:
CFGFN ./FHEM/Wohnzimmer.cfg
CUL_1_MSGCNT 18
CUL_1_RAWMSG A16E8A0101E8E19F11134020800206C2100226430060000FF
CUL_1_RSSI -74.5
CUL_1_TIME 2013-04-13 06:06:37
DEF 1E8E19
EVENTS 18
IODev CUL_1
LASTInputDev CUL_1
MSGCNT 18
NAME WZ_Fenster
NR 439
NTFY_TRIGGERTIME 2013-04-13 06:06:37
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:E8 - t:10 s:1E8E19 d:F11134 020800206C2100226430060000
protCmdDel 5
protLastRcv 2013-04-13 06:06:37
protResnd 2 last_at:2013-04-13 05:35:07
protResndFail 3 last_at:2013-04-13 06:00:52
protSnd 10 last_at:2013-04-13 06:06:36
protState CMDs_done
rssi_at_CUL_1 avg:-72.72 min:-75.5 max:-67 lst:-74.5 cnt:18
Readings:
2013-04-13 06:06:35 Activity: alive
2013-04-13 06:06:36 PairedTo 0x0
2013-04-13 05:58:19 R-cyclicInfoMsg off
2013-04-11 16:37:26 R-eventDlyTime 0 s
2013-04-13 05:58:19 R-intKeyVisib invisib
2013-04-11 16:37:26 R-ledOnTime 0.5 s
2013-04-13 05:58:21 R-msgRhsPosA closed
2013-04-13 05:58:21 R-msgRhsPosB open
2013-04-13 05:58:21 R-msgRhsPosC tilted
2013-04-13 05:58:19 R-pairCentral 0x0
2013-04-13 05:58:19 R-transmDevTryMax 6
2013-04-13 05:58:21 R-transmitTryMax 6
2013-04-11 16:52:35 R-virtFenster_Btn1-expectAES set_off
2013-04-11 16:52:35 R-virtFenster_Btn1-peerNeedsBurst set_off
2013-04-13 06:06:36 RegL_00: 02:00 09:00 0A:00 0B:00 0C:00 10:01 14:06 00:00
2013-04-13 06:06:37 RegL_01: 08:00 20:6C 21:00 22:64 30:06 00:00
2013-04-13 05:35:00 alive yes
2013-04-13 05:35:00 battery ok
2013-04-13 05:39:00 contact closed (to broadcast)
2013-04-13 05:35:00 cover open
2013-04-13 06:00:52 state RESPONSE TIMEOUT:RegisterRead
Helper:
mId 0030
peerIDsRaw ,00000000
rxType 12
Role:
chn 1
dev 1
Rpt:
IO CUL_1
msg A16E8A0101E8E19F11134020800206C2100226430060000::-74.5:CUL_1
ts 1365825997.33249
ack:
HASH(0xd42328)
E88002F111341E8E1900
Rssi:
At_cul_1:
avg -72.7222222222222
cnt 18
lst -74.5
max -67
min -75.5
Shadowreg:
Attributes:
actCycle 028:00
actStatus alive
devStateIcon open:offen closed:geschlossen tilted:gekippt
eventMap open:offen closed:geschlossen tilted:gekippt
expert 2_full
firmware 2.0
fp_Wohnbereich 641,385,0,
model HM-SEC-RHS
peerIDs 00000000,
room Wohnzimmer
serialNr JEQ0711547
subType threeStateSensor
-
Martin
Inzwischen habe ich den RHS WZ_Fenster erneut auf die Werkeinstellungen zurück gesetzt und dann neu gepairt. Es ist das gleiche passiert, wie beim WZ_Tuere. Die Rückmeldung funktioniert, ohne dass ich das Peering vorgenommen habe...
Chris
-
Hi,
folgendes sieht nicht gut aus:
STATE RESPONSE TIMEOUT:RegisterRead
==> evtl ist die register liste 4 leer, da es keinen Peer gibt
peerIDs 00000000,
==> die peer liste ist leer, ein reading peerList gibt es nicht
2013-04-11 16:52:35 R-virtFenster_Btn1-expectAES set_off
2013-04-11 16:52:35 R-virtFenster_Btn1-peerNeedsBurst set_off
==> diese Readings sind 2 Tage alt. Readings werden nicht gelöscht (mal sehen, ob mir hier etwas einfällt, evtl baue ich dies um...)
==> mache ein set WZ_Fenster clear readings,dann sind alle readings weg und dun kannst sie neu lesen.
Also erst einmal solltest du das peering einstellen und in peerList auch sehen
Gruss
Martin
-
Martin
Wie bereits erwähnt, habe ich beide RHS nicht gepeert. Trotzdem erhalte ich auf einmal bei beiden (nach der Rücksetzung auf Werkeinstellung)eine Rückmeldung. Hier der Eintrag der WZ_Tuere:
Internals:
CFGFN ./FHEM/Wohnzimmer.cfg
CUL_1_MSGCNT 14
CUL_1_RAWMSG A0D1FA6101E90ADF111340601C800E0
CUL_1_RSSI -90
CUL_1_TIME 2013-04-17 16:26:29
DEF 1E90AD
EVENTS 10
IODev CUL_1
LASTInputDev CUL_1
MSGCNT 14
NAME WZ_Tuere
NR 503
NTFY_TRIGGERTIME 2013-04-17 16:26:29
STATE offen
TYPE CUL_HM
lastMsg No:1F - t:10 s:1E90AD d:F11134 0601C800
protCmdDel 2
protLastRcv 2013-04-17 16:26:29
protResndFail 1 last_at:2013-04-17 16:24:07
protSnd 4 last_at:2013-04-17 16:26:14
protState CMDs_done
rssi_at_CUL_1 avg:-90.5 min:-99.5 max:-82.5 lst:-90 cnt:14
Readings:
2013-04-17 16:26:13 Activity: alive
2013-04-17 16:26:14 PairedTo 0xF11134
2013-04-17 16:26:14 R-cyclicInfoMsg off
2013-04-17 16:26:15 R-eventDlyTime 0 s
2013-04-17 16:26:14 R-intKeyVisib invisib
2013-04-17 16:26:15 R-ledOnTime 0.5 s
2013-04-17 16:26:15 R-msgRhsPosA closed
2013-04-17 16:26:15 R-msgRhsPosB open
2013-04-17 16:26:15 R-msgRhsPosC tilted
2013-04-17 16:26:14 R-pairCentral 0xF11134
2013-04-17 16:26:14 R-transmDevTryMax 6
2013-04-17 16:26:15 R-transmitTryMax 6
2013-04-17 16:26:14 RegL_00: 02:01 09:00 0A:F1 0B:11 0C:34 10:01 14:06 00:00
2013-04-17 16:26:15 RegL_01: 08:00 20:6C 21:00 22:64 30:06 00:00
2013-04-17 16:26:18 alive yes
2013-04-17 16:26:18 battery ok
2013-04-17 16:26:18 contact open (to CUL_1)
2013-04-17 16:26:18 cover closed
2013-04-17 16:26:18 state open
Helper:
mId 0030
peerIDsRaw ,00000000
rxType 12
Respwait:
Role:
chn 1
dev 1
Rpt:
IO CUL_1
msg A0D1FA6101E90ADF111340601C800::-96:CUL_1
ts 1366208778.194
ack:
HASH(0x100e2c8)
1F8002F111341E90AD00
Rssi:
At_cul_1:
avg -90.5
cnt 14
lst -90
max -82.5
min -99.5
Shadowreg:
Attributes:
actCycle 028:00
actStatus alive
devStateIcon open:offen closed:geschlossen tilted:gekippt
eventMap open:offen closed:geschlossen tilted:gekippt
expert 2_full
firmware 2.0
fm_name T%C3%BCre
fm_order 2
fm_type none
fp_Wohnbereich 377,1004,0,Türe
model HM-SEC-RHS
peerIDs 00000000,
room Wohnzimmer
serialNr JEQ0711455
subType threeStateSensor
Gruss
Chris
-
Hi Chris,
der ist gepairt mit
RegL_00: 02:01 09:00 0A:F1 0B:11 0C:34 10:01 14:06 00:00
reset loescht offensichtlich nicht alles
Falls Hary dies liest: auch hier eine Statusmeldung an die Zentrale, kein Broadcast
msg A0D1F A6 10 1E90AD F11134 06 01C800::-96:CUL_1
Gruss
Martin