Muss ich meine HM-Devices an HM-LAN-CFG anlernen

[Markus Hermann]

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

[Carsten]

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.

[martinp876]

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

[Carsten]

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

[Markus Hermann]

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

[martinp876]

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

[outhouse]

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

[martinp876]

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

[outhouse]

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

[martinp876]

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

[outhouse]

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

[martinp876]

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

[outhouse]

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

[Martin Thomas Schrott]

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

[outhouse]

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