Grundsätzliche Frage - wie fange ich an ;)

Begonnen von TommiH, 14 Februar 2017, 00:28:32

Vorheriges Thema - Nächstes Thema

bugster_de

Hi,

autocreate ist ein Basismechanismus von FHEM; der gilt, falls eingeschaltet, erstmal für alle Geräte. Pairing ist Homematic Special und sitzt quasi unten-drunter. Man muß FHEM mit dem Homemmatic Gerät pairen und wenn das passiert ist, legt autocreate das Gerät automatisch in der Oberfläche an.

Warum Pairing: das sieht man sehr schön, wenn man z.B. Baumarkt Steckdosen von Intertechno hat: wenn der Nachbar die gleichen hat, dann schaltet der immer meine und ich immer seine mit. Irgendwie blöd. Bei Homematic sind die einzelnen Geräte mit einer Zentrale gepaired und des Gerät führt nur Befehle aus, die von der Zentrale kommen, mit der es auch gepaired ist. Sprich der Nachbar kann auch Homematic haben und man beeinflusst sich nicht gegenseitig. Sprich Pairing ist im Prinzip das gegenseitige Kennenlernen von FHEM Zentrale und Homematic Gerät.
Gleiches auch bei Sensoren, denn was interessiert mich die Wohnzimmertemperatur meines Nachbarn? Passiert dir bei Homematic nicht.
deshalb ist Homematic initial aufwendiger und komplexer aber dann im weiteren Verlauf auch einfach besser.

ZitatAlso meiner Meinung nach braucht man keine VCCU.
Dachte ich auch all die Jahre. der Charme einer VCCU kommt aber dann ins Spiel, wenn deine Homematic Zentrale (z.B. HM-LAN) das zeitliche gesegnet hat und du den ganzen Pairing Vorgang wieder mit der neuen HW machen mußt. Da merkst Du dann erst, wieviel HM Geräte du über die Jahre angeschafft hast. Die darfst Du alle neu pairen. Bei Nutzung einer VCCU braucht man das nicht.

ich würde aber jetzt erstmal folgendes machen
- maximal 2-3 HM Geräte über den klassichen Weg in FHEM einbinden
- wenn du das im Griff hast und FHEM soweit verinnerlicht hast, dann stellst du auf VCCU um und erweiterst dann die Installation

Übrigens: das Thema Peering bei Homematic machen wir dann im Fortgeschrittenen Kurs :-)




Thorsten Pferdekaemper

Zitat von: bugster_de am 14 Februar 2017, 12:41:43Sprich der Nachbar kann auch Homematic haben und man beeinflusst sich nicht gegenseitig.
...außer ich will unbedingt. SCNR.  :P

ZitatDachte ich auch all die Jahre. der Charme einer VCCU kommt aber dann ins Spiel, wenn deine Homematic Zentrale (z.B. HM-LAN) das zeitliche gesegnet hat und du den ganzen Pairing Vorgang wieder mit der neuen HW machen mußt.
Warum das den? Gib doch der neuen Hardware einfach dieselbe HmId.
Gruß,
   Thorsten
FUIP

Beta-User

Zitat von: Thorsten Pferdekaemper am 14 Februar 2017, 12:55:10
Warum das den? Gib doch der neuen Hardware einfach dieselbe HmId.
...das reicht unter Umständen leider nicht: Das IO sollte tunlichst auch vor den anzusteuernden Geräten in der cfg stehen (kann man aber ggf. natürlich auch händisch erreichen bzw. durch Änderung der "alten" IO-Definition).
Die VCCU ist (nach angelesenem Wissen) außerdem hilfreich, wenn man weitere HM-Funker in der Nachbarschaft hat (ganz besonders HMIP) und/oder mehrere IO's betreiben will oder muß. Auch hier gilt das vorgesagte: die VCCU als IO sollte in der cfg vor den anzusteuernden Devices stehen.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Thorsten Pferdekaemper

Zitat von: Beta-User am 14 Februar 2017, 13:08:36
...das reicht unter Umständen leider nicht: Das IO sollte tunlichst auch vor den anzusteuernden Geräten in der cfg stehen (kann man aber ggf. natürlich auch händisch erreichen bzw. durch Änderung der "alten" IO-Definition).
Aber hilft da die VCCU? Ich glaube außerdem, dass es zu dem grundsätzlichen Problem der Reihenfolge einen anderen Thread gibt und ich gehe davon aus, dass das demnächst gelöst wird. Das betrifft nämlich nicht nur HM.

Zitat
Die VCCU ist (nach angelesenem Wissen) außerdem hilfreich, wenn man weitere HM-Funker in der Nachbarschaft hat (ganz besonders HMIP) und/oder mehrere IO's betreiben will oder muß.
Ja, dann schon. Hier ging's aber nicht darum.
Ich glaube, Martins Argument ist hauptsächlich, dass man von Anfang an eine VCCU haben sollte, falls man später mal mehrere IOs hat.
Gruß,
   Thorsten
FUIP

Beta-User

Zitat von: Thorsten Pferdekaemper am 14 Februar 2017, 13:29:54
Aber hilft da die VCCU?
Soweit ich das verstanden habe, jedenfalls solange, wie es noch min. ein "vorgelagertes" IO gibt. Ob bzw. wann das generelle Problem gelöst wird, entzieht sich meiner Kenntnis, es gab nur die vergangenen 3 Monate gefühlte 3-4 Beiträge, bei denen die TE jeweils das Problem hatten (auch nicht-HM).

Zitat von: Thorsten Pferdekaemper am 14 Februar 2017, 13:29:54
Ich glaube, Martins Argument ist hauptsächlich, dass man von Anfang an eine VCCU haben sollte, falls man später mal mehrere IOs hat.
Mag sein, dazu spricht noch der Umstand dafür, dass man damit virtuelle Kanäle nutzen kann und so bei Tastern eine grüne Quittung bekommt, das ist aber auch eher eine Nebensächlichkeit.

Fazit: VCCU ist nicht überlebenswichtig, aber auch nicht schädlich und irgendwann eventuell nützlich, auch wenn man das jetzt vielleicht noch nicht wissen kann :).

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Thorsten Pferdekaemper

Zitat von: Beta-User am 14 Februar 2017, 13:38:14
Soweit ich das verstanden habe, jedenfalls solange, wie es noch min. ein "vorgelagertes" IO gibt. Ob bzw. wann das generelle Problem gelöst wird, entzieht sich meiner Kenntnis, es gab nur die vergangenen 3 Monate gefühlte 3-4 Beiträge, bei denen die TE jeweils das Problem hatten (auch nicht-HM).
Ich habe mal kurz im Developer-Teil nachgesehen. Anscheinend arbeitet da niemand wirklich aktiv dran. Es scheint nur so zu sein, dass von den Modulautoren erwartet wird, das "richtig" zu machen. D.h. man darf in einem Client-Modul nicht von Anfang an die Existenz der IO-Devices voraussetzen, sondern erst wenn FHEM fertig initialisiert ist. Das bedeutet, dass Martin das eigentlich mal reparieren sollte.
(...und ich auch, da bei Homematic-Wired dasselbe Problem auftritt  :-[).
Gruß,
   Thorsten
FUIP

TommiH

Zitat von: Thorsten Pferdekaemper am 14 Februar 2017, 08:53:44
Hi
ich bin immer noch gespannt, welche "2-3 Anfängeranleitungen" Tommi gelesen hat. Ich glaube nicht, dass es möglich ist, auf den FHEM-Seiten 3 Anfängeranleitungen zu finden, ohne etwas über das Pairing zu lessen. Außerdem: Kann da jemand nicht so genau bis 3 Zählen?
SCNR...
   Thorsten

https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM#Der_erste_Einstieg
https://fhem.de/Heimautomatisierung-mit-fhem.pdf
(besonders umfangreich, auf Seite 28 kommt dann etwas von pairing - aber anscheinend auch für FS20? - HM folgt dann auf Seite 60 - ist da dann alles zu HM? - naja, auch mal durcharbeiten)
http://www.meintechblog.de/2012/10/fhem-mit-fritzbox-7390-und-cul-stick-professionelle-hausautomation/
http://voizchat.de/fhem-tutorial-serie-teil-02-homematic-in-fhem-einrichten-komponenten-anlernen/
https://raspberry.tips/hausautomatisierung/hausautomatisierung-mit-fhem-teil-2-fhem-installation-und-einrichtung-auf-dem-raspberry-pi/

usw. - wie gesagt, ich suche für gewöhnlich mit google und da findet man leider sehr viel - was davon taugt oder nicht, weiß man ja als Anfänger nicht... (und zu pairing steht da viel, aber klar und deutlich ist eindeutig anders...)

Immerhin habe ich den Eindruck, als ob man hier gescheite Hilfe finden kann :) - so, nun werde ich mich mal noch mit der Fehlermeldung und der VCCU beschäftigen

Tommi

Thorsten Pferdekaemper

#22
Zitat von: TommiH am 14 Februar 2017, 21:11:29
https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM#Der_erste_Einstieg
Ja, das ist gut als erster Einstieg, hilft aber natürlich nichts zum Einbinden von Hardware.

Zitathttps://fhem.de/Heimautomatisierung-mit-fhem.pdf
Das ist wahrscheinlich das wichtigste Dokument für den Anfang. Ein bisschen FS20/HM-lastig, aber für irgendwas muss man sich ja entscheiden.

Zitat
(besonders umfangreich, auf Seite 28 kommt dann etwas von pairing - aber anscheinend auch für FS20? -
Ja, und leider meiner Meinung nach sollte es Peering heißen. Ich werde da mal nachhaken.
(Siehe https://forum.fhem.de/index.php/topic,19621.msg585571.html#msg585571)

ZitatHM folgt dann auf Seite 60 - ist da dann alles zu HM? - naja, auch mal durcharbeiten)
Genau, Du hast HM, da liegt es nahe, den HM-Teil zu lessen. Oder???
Mich wundert, dass Du den Homematic-Teil im Wiki nicht gefunden hast. Ist der erste sinnvolle Treffer bei google für "fhem homematic".

Zitat
http://www.meintechblog.de/2012/10/fhem-mit-fritzbox-7390-und-cul-stick-professionelle-hausautomation/
http://voizchat.de/fhem-tutorial-serie-teil-02-homematic-in-fhem-einrichten-komponenten-anlernen/
https://raspberry.tips/hausautomatisierung/hausautomatisierung-mit-fhem-teil-2-fhem-installation-und-einrichtung-auf-dem-raspberry-pi/
usw. - wie gesagt, ich suche für gewöhnlich mit google und da findet man leider sehr viel - was davon taugt oder nicht, weiß man ja als Anfänger nicht...
Es ist eigentlich ganz einfach: Alles, was auf fhem.de steht, im FHEM-Wiki oder im FHEM-Forum taugt für FHEM. Alles andere im Zweifelsfall nicht. Wer wirklich was zu FHEM beitragen will, der macht das auf den FHEM-Seiten und nicht irgendwo.

Zitat
Immerhin habe ich den Eindruck, als ob man hier gescheite Hilfe finden kann :)
Das ist ja auch das FHEM-Forum. Was hast Du gedacht, wo Du Hilfe zu FHEM findest?

Gruß,
   Thorsten
FUIP

TommiH

Hallo Thorsten,

naja, für mich ist normalerweise ein Forum die 2te Wahl, wenn man sich erstmal mit guten Dokus eine Grundlage geschaffen hat - daher erst das googeln, dann das Forum. Aber fehm ist (da es nicht nur um fhem, sondern natürlich ja auch um Hardware - Aktoren aber auch 'worauf' (Pi/Router/PC/...) geht) ja mehr als nur fhem ansich.

Langsam beginne ich aber mehr und mehr zu verstehen, da macht dann das Forum auch wieder Sinn ;)

Dann werde ich mal noch speziell die HM-Dokus genauer anschauen, das wird schon.

Was mich allerdings aktuell interessieren würde, ich habe zwar ein Backup gemacht, aber da waren schon die ersten Sachen eingerichtet/angelegt. Nun habe ich so viel rumprobiert, dass ich eigentlich wieder auf den Stand 'fhem und CUL sind lauffähig' zurück? Also das nur die Grundkonfiguration wieder da ist, ohne angelernte Sachen usw.

Geht das für einen Anfänger umzusetzen, oder muss ich das fhem komplett neu aufsetzen um das zu erreichen?

Ich habe den Eindruck, wenn ich einen Aktor über die Oberfläche entferne, dass er nicht komplett weg ist (muss man da noch manuell irgendwo etwas löschen?)- und ich habe den Eindruck, als ob die Meldungen, die ich seit kurzem bekomme (Stichwort VCCU) eher durch von mir mal eingerichtete Aktoren kommen.

Ich würde also, wenn möglich, alles was ich neben CUL und hmid eingerichtet habe vergessen wollen...


;) - hoffentlich ist bald Wochenende, da kann ich mich wieder etwas mehr damit beschäftigen.

LG,
Tommi


LG,
Tommi


Thorsten Pferdekaemper

Zitat von: TommiH am 16 Februar 2017, 08:48:19naja, für mich ist normalerweise ein Forum die 2te Wahl, wenn man sich erstmal mit guten Dokus eine Grundlage geschaffen hat - daher erst das googeln, dann das Forum.
Das ist ja grundsätzlich richtig. Ich wollte nur darauf hinaus, dass wenn man etwas zu einem "Produkt" namens "FHEM" wissen will, man sich nicht zu wundern braucht, wenn die besten Informationen auf Webseiten zu finden sind, die "fhem" im Namen haben.

Zitat
Was mich allerdings aktuell interessieren würde, ich habe zwar ein Backup gemacht, aber da waren schon die ersten Sachen eingerichtet/angelegt. Nun habe ich so viel rumprobiert, dass ich eigentlich wieder auf den Stand 'fhem und CUL sind lauffähig' zurück? Also das nur die Grundkonfiguration wieder da ist, ohne angelernte Sachen usw.
Geht das für einen Anfänger umzusetzen, oder muss ich das fhem komplett neu aufsetzen um das zu erreichen?
Lösche einfach über die Oberfläche alles, was Du nicht mehr willst.

ZitatIch habe den Eindruck, wenn ich einen Aktor über die Oberfläche entferne, dass er nicht komplett weg ist (muss man da noch manuell irgendwo etwas löschen?)- und ich habe den Eindruck, als ob die Meldungen, die ich seit kurzem bekomme (Stichwort VCCU) eher durch von mir mal eingerichtete Aktoren kommen.
Naja, physikalisch existieren die Dinger ja noch. Daher kann es sein, dass sie durch autocreate wieder angelegt werden, wenn sie was funken.

Gruß,
   Thorsten
FUIP

TommiH

Hallo Thorsten,

okay - nun habe ich mit dem speziellen HM-Teil angefangen (gut! ;) ) - naja, aller Anfang ist wie gewöhnlich schwer, aber beim 2ten/3ten Anlauf wird es leichter und leichter.

2 Fragen noch, ich habe nun fast alles aus der fhem.cfg rausgeworfen (bis auf 3 Dummyeinträge und meine Steckdose1), ist da noch 'Anfängerschmarrn' drin, den man besser ändern sollte?

attr global userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride
attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd Messages collected while initializing FHEM:\
./log/fhem.save: Please define Dimmer1 first\

attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3

define telnetPort telnet 7072 global
define allowed_telnetPort allowed
attr allowed_telnetPort password cx500c
attr allowed_telnetPort validFor telnetPort

define WEB FHEMWEB 8083 global
attr WEB editConfig 1
define allowed_WEB allowed
attr allowed_WEB basicAuth dG9tbWk6Y3g1MDBj
attr allowed_WEB validFor WEB

define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix smallscreen
define allowed_WEBphone allowed
attr allowed_WEBphone basicAuth dG9tbWk6Y3g1MDBj
attr allowed_WEBphone validFor WEBphone

define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad
define allowed_WEBtablet allowed
attr allowed_WEBtablet basicAuth dG9tbWk6Y3g1MDBj
attr allowed_WEBtablet validFor WEBtablet

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog

define autocreate autocreate

define eventTypes eventTypes ./log/eventTypes.txt

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
attr initialUsbCheck disable 1
#define SVG_FileLog_HM_528A62_1 SVG FileLog_HM_528A62:SVG_FileLog_HM_528A62_1:CURRENT
#attr SVG_FileLog_HM_528A62_1 icon black_Steckdose.off
define CUL1 CUL /dev/ttyUSB0@38400 1234
attr CUL1 hmId xxxxxx
attr CUL1 rfmode HomeMatic
define myschalter1 dummy
attr myschalter1 room Raum1
attr myschalter1 webCmd on:off
define lampe1 dummy
attr lampe1 room Raum1

define Steckdose1 CUL_HM 528A62
attr Steckdose1 IODev CUL1
attr Steckdose1 autoReadReg 4_reqStatus
attr Steckdose1 expert 2_raw
attr Steckdose1 firmware 2.6
attr Steckdose1 model HM-LC-Sw1-Pl-DN-R1
attr Steckdose1 peerIDs 00000000,
attr Steckdose1 room Arbeitszimmer
attr Steckdose1 serialNr NEQ1677030
attr Steckdose1 subType switch
attr Steckdose1 webCmd statusRequest:toggle:on:off
define n_myschalter1_on notify myschalter1 set lampe1 $EVENT
attr n_myschalter1_on room Raum1

Und die zweite Frage noch, wenn ich meine Dose schalte, dann kommt ja

2017-02-17 07:52:58 CUL_HM Steckdose1 deviceMsg: on (to xxxxxx)
2017-02-17 07:52:58 CUL_HM Steckdose1 level: 100
2017-02-17 07:52:58 CUL_HM Steckdose1 pct: 100
2017-02-17 07:52:58 CUL_HM Steckdose1 on
2017-02-17 07:52:58 CUL_HM Steckdose1 timedOn: off

wo die hmID mit angezeigt wird, in der Definition der Steckdose ist sie aber nicht vorhanden, also nur im Gerät gespeichert und wird beim ausführen angezeigt. Aber wenn ich so einen Eintrag im LOG sehe, wie kann man daraus irgendwas über den Verursacher ablesen? Also analysemäßig? bzw

2017.02.17 07:40:09 3: CUL1: Unknown code A0E8E82021915DE18D8F40101BC002D::-66:CUL1, help me!
2017.02.17 07:42:34 3: CUL1: Unknown code A0C8F867018D8F400000080CF20::-79:CUL1, help me!
2017.02.17 07:42:54 3: CUL1: Unknown code A0B8FA25818D8F41915DE00F2::-78.5:CUL1, help me!
2017.02.17 07:42:55 3: CUL1: Unknown code A0E8F82021915DE18D8F40101BC002D::-67:CUL1, help me!
2017.02.17 07:45:06 3: CUL1: Unknown code A0C90867018D8F400000080CE20::-78:CUL1, help me!

bzw. folgendes im EventMonitor

2017-02-17 07:57:18 CUL CUL1 UNKNOWNCODE A0C95867018D8F400000080CE20::-79.5:CUL1
2017-02-17 07:57:38 CUL CUL1 UNKNOWNCODE A0B95A25818D8F41915DE00F2::-80:CUL1
2017-02-17 07:57:38 CUL CUL1 UNKNOWNCODE A0E9582021915DE18D8F40101BC002D::-67.5:CUL1

kann man da irgendwie rauskriegen, was das überhaupt sein könnte? Also was für eine Art Aktor oder Ding das ist?

LG,
Tommi

Thorsten Pferdekaemper

Zitat von: TommiH am 17 Februar 2017, 07:59:012 Fragen noch, ich habe nun fast alles aus der fhem.cfg rausgeworfen
Hoffentlich nicht durch Editieren der fhem.cfg. Die gehört nämlich fhem und nicht Dir. Sachen rauswerfen macht man mit "delete" auf der Web-Oberfläche.

Außerdem: Inhalte von Dateien und andere Programm-artige Sachen bitte in code-Tags posten. Der Inhalt der fhem.cfg interessiert übrigens nur in Ausnahmefällen. Bei Fragen zu einem Device besser ein list von dem Device schicken.

Zitat
Und die zweite Frage noch, wenn ich meine Dose schalte, dann kommt ja
Neue Fragen besser in neuen Threads, aber machen wir mal eine Ausnahme...

Zitat
2017-02-17 07:52:58 CUL_HM Steckdose1 deviceMsg: on (to xxxxxx)
2017-02-17 07:52:58 CUL_HM Steckdose1 level: 100
2017-02-17 07:52:58 CUL_HM Steckdose1 pct: 100
2017-02-17 07:52:58 CUL_HM Steckdose1 on
2017-02-17 07:52:58 CUL_HM Steckdose1 timedOn: off
Auch sowas gehört in code-Tags.

Zitat
wo die hmID mit angezeigt wird, in der Definition der Steckdose ist sie aber nicht vorhanden, also nur im Gerät gespeichert und wird beim ausführen angezeigt. Aber wenn ich so einen Eintrag im LOG sehe, wie kann man daraus irgendwas über den Verursacher ablesen? Also analysemäßig? bzw
Hä? Das Ding heißt offensichtlich "Steckdose1". Wenn Du näheres dazu wissen willst, dann schau Dir "Steckdose1" auf der Weboberfläche an oder mach "list Steckdose1".

Zitat
2017.02.17 07:40:09 3: CUL1: Unknown code A0E8E82021915DE18D8F40101BC002D::-66:CUL1, help me!
2017.02.17 07:42:34 3: CUL1: Unknown code A0C8F867018D8F400000080CF20::-79:CUL1, help me!
2017.02.17 07:42:54 3: CUL1: Unknown code A0B8FA25818D8F41915DE00F2::-78.5:CUL1, help me!
2017.02.17 07:42:55 3: CUL1: Unknown code A0E8F82021915DE18D8F40101BC002D::-67:CUL1, help me!
2017.02.17 07:45:06 3: CUL1: Unknown code A0C90867018D8F400000080CE20::-78:CUL1, help me!
Ich denke, damit musst Du in den Homematic-Bereich. Am besten einen neuen Thread aufmachen. Wenn Du dann eine allgemeine Vorgehensweise findest, dann könntest Du sie auch dokumentieren. Ich glaube die Frage kommt öfter, aber ich habe bisher noch keine allgemeine Lösung gefunden. Das liegt aber vielleicht auch an mir und ich habe nicht ordentlich gesucht.

Gruß,
   Thorsten
FUIP

TommiH

Hm, die Frage was man zuerst machen sollte, verstehe ich aber auch nach mehreren Anleitungen nicht. Auch auf den fhem-Seiten finde ich immer wieder:

> Es wird angestrebt, die Sensoren und Aktoren möglichst direkt zu peeren. Dies hat Vorteile in Ausfallsicherheit und vor allem der Schaltgeschwindigkeit sowie Präzision der Steuerung.

> Ansatz ist somit:
> Komponenten über FHEM zu konfigurieren
> Sensoren (speziell Taster / Remotes) direkt mit Aktoren zu peeren. Man kann diese Funktionen somit ohne Zentrale betreiben. Außerdem wird die Schaltgeschwindigkeit und Präzision erhöht.

Im PDF steht dazu
> Pairen
> Pairen ist das Anlernen des Device an die Zentrale. Dies ist dann für alle Kanäle im Gerät gültig. Pairen ordnet das Gerät der Zentrale unter. Bestimmte Aktionen können nach dem pairen nicht mehr von Device ausgeführt werden (peeren oder 'anlernen' von Kanälen ohne Zentrale). ... Es wird strikt empfohlen alle Devices mit der Zentrale zu pairen. Dies sollte die erste Aktion der Inbetriebnahme sein.

Also geht es NACH dem Pairen nicht mehr, Aktor/Sensor zu peeren (direkt zu verbinden) - oder verstehe ich das nur falsch?

Ich würde daraus ja verstehen - wenn gepairt ist, dann geht peeren nicht mehr, aber eben auch, pairen ist das Erste was man tun sollte. Irgendwie ist das verwirrend...

Tommi






Thorsten Pferdekaemper

Hi,
damit ist nur gemeint, dass das Peering bei bestimmten Devices nicht mehr über die Knöpfchen an den Geräten selbst funktioniert. Stattdessen muss man das über die Zentrale machen. Das Peering über die Knöpchen an den Geräten ist meiner Meinung nach sowieso nicht menschenwürdig, also:
1. Pairing mit der Zentrale (also FHEM)
2. dann Peering der Devices untereinander über die Zentrale.
Das Peering macht man zwar mit Hilfe der Zentrale, aber die ganzen Einstellungen werden dann in die Geräte selbst geschrieben und brauchen danach theoretisch keine Zentrale mehr.
Gruß,
   Thorsten
FUIP