HM-PB-2-FM peeren mit 11 HM-LC-Bl1PBU-FM möglich bzw. wie?

[Ralli]

Hallo,

ich möchte mir demnächst einen HM-PB-2-FM als "Zentralschalter" installieren, mit dem ich unabhängig von einer Zentrale bei Bedarf 11 Rollladen-Aktoren HM-LC-Bl1PBU-FM ansteuern möchte (alles hoch/alles runter).

Zwei Fragen zu den Basics:

Kann ich überhaupt den HM-PB-2-FM mit 11 Geräten peeren (laut Wiki bis zu 50 "Kanäle")?

Peere ich das erste dann mit peerChan 0, das zweite mit peerChan 1 usw. oder peere ich alle mit peerChan 0?

[Otto123]

Hallo Ralli,

hier stehen die Basics.
analog dem kannst Du das peering machen.

Der Syntax hängt davon ab, ob du einzelne Knöpfe oder Kombinationen peeren willst.
Ob das mit 11 Aktoren geht, weiß ich nicht. Theoretisch sind das ja 22 Kanäle?

Gruß Otto

[Ralli]

Hallo Otto,

das kenne ich alles, habe auch schon einige Peerings gemacht. Aber eben nicht von einem Schalter mit 11 Geräten. Es wird wohl jeder Aktor mit peerChan 0 gepeered.

Aber meine eigentliche Frage ist nicht beantwortet. Ich hatte gehofft, dass bereits jemand eine ähnliche Konfiguration hat.

[Otto123]

Hallo Ralli,

Aber meine eigentliche Frage ist nicht beantwortet

Ja sorry - aber Versuch macht kluch

Viel Erfolg

Gruß Otto

[martinp876]

die "0" sollte ich evtl entfernen...
vor meiner Zeit gab es das Device und keine Channels. Eine Remote hätte man peeren können mit
set <pbDevice> peerChan <button_No> ...

ButtonNo ist dann von 1 bis Ende/2 - da die Bottons auch  noch in 1On und 1Off separiert wurden. Ein häßliches S
Stück Code.

Wenn du mit Channels arbeitest ist das unnötig, also

set <pbChannel> peerChan <egal> ...

Wenn also vorne ein Channel steht ist der 4. Eintrag egal.

[Otto123]

Hallo Martin,

ich habe mich da auch immer gewundert ->("0")
Im Wiki ist das Peering nur rudimentär erklärt. Da steht z.B. auch das es noch einer Erklärung für IODev bedarf, ich hätte da ja was ganz anderes drunter verstanden (HMLAN z.B.)
Der letzte Parameter "both..." fehlt da völlig.
In der commandref steht es ziemlich umfangreich - aber unter set sicher richtig -aber ->

Ich finde peering ist immer wieder mit vielen Fragen und Unklarheiten behaftet. Es ist schwierig für den Anfänger, dabei ist es doch ne wichtige Sache!

Soll ich das mal mit Deiner Hilfe im Wiki etwas aufarbeiten?

Gruß Otto

[martinp876]

Gerne.
Ich hatte es zu erst im einsteigerdoc erklaert. Da gehoert es m.e. auch in erster linie hin. Peering allein macht keinen sinn, man versteht es nur im zusammenhang. Ich zumindest. Aber es geht sicher auch anders.
Peeren ist ein eintrag im device. Durch peeren werden weitere registergruppen erzeugt...
Neben den kommandos ist erst einmal wichtig zu verstehen, warum man ueberhaupt peeren will.
In wiki wuerde ich mir wuenschen die beschreibung zu splitten. Unterschiede bei unterschiedlichen devices, config oder burst oder virtual sollten nicht doppelt erklaert werden. Das unterscheidet wiki vom einsteigerdoc.

Peerchan ist das einzige kommando, welches an 2 devices geht. Das ist aber mutwillig so gemacht, eigentlich sind es 2 getrennte kommandos. Man muss also beide kontrollieren. Welche fragen sind offen ? Eigentlich haette ich erwartet das die syntax einfach, wenn man den zweck erkannt hat sind die parameter doch selbsterklaerend...ausser die 0

[Otto123]

Eigentlich haette ich erwartet das die syntax einfach, wenn man den zweck erkannt hat sind die parameter doch selbsterklaerend...ausser die 0

Finde ich jetzt auch, nachdem ich es halbwegs verstanden habe. Aber dahin muss man erst mal kommen.
Dieser Tage stand hier irgendwo, das peeren in der Klick Oberfläche der Homematic CCU einfacher ist - finde ich überhaupt nicht.

Ich finde in der Einsteiger Doc sollte das Verständnis gebracht werden, warum, wozu, was passiert.
Das wie es geht mit Beispielen sucht man dann doch im Wiki oder der commandref, dass läuft an vielen Stellen ein bisschen in Konkurrenz.

Ich schaue mir alles nochmal an und überlege mir was. Ich frage dich wenn was unklar ist, vielleicht mache ich dann einen separaten Thread?

Gruß Otto

[krikan]

Ich finde in der Einsteiger Doc sollte das Verständnis gebracht werden, warum, wozu, was passiert.
Das wie es geht mit Beispielen sucht man dann doch im Wiki oder der commandref, dass läuft an vielen Stellen ein bisschen in Konkurrenz.

"Leicht Off-Topic:" Genau, da sind wir doch bei der Frage, die Rudi auch vor kurzem stellte (finde es aber gerade nicht) , ob wir die Doku nicht konsolidieren können? Bspw. Einsteiger-Doc ins Wiki mit Schreibberechtigung nur für Ausgewählte, oder....
Gruß, Christian

[martinp876]

Man kann viel. Und vieles ist richtig.
Das Einsteigerdoc hatte ich als erstes geschrieben (und schon lange nicht mehr rein geschaut). Es erklärt das Verhalten der HM Devices und ich glaube dass es immernoch alles Wichtige adressiert um HM verstehen zu können.
Die Frage ist, wer ein Einsteiger ist. Ich ging von einem Grundverständniss des Lesers bei technischen Abläufen aus. Basierend darauf meine ich sollte er in der Lage sein HM zu verstehen.
Man kann einen Einsteiger auch anders sehen - klar. Jemand der keinerlei Ahnung hat und sich ein paar Devices kauft und schalten will. Der kann leicht überfordert sein mit den Interna der Devices. Solchen Leuten erklärt man sicher einfacher ein Kochrezept für dies und das. Sie werden basierend hierauf nicht unbedingt das Konzept verstehen und somit hie und da Probleme haben, Sonderlocken zu implementieren.

Wiki erklärt wenig Zusammenhänge. kann man ändern - ist m.E. einiges an Aufwand. Rudi war schon immer gegen das Einsteigerdoc und ist gnadenlos für WIKI.

Will man die Doku komplett und für alle User machen braucht man
- simple getting startet
- Konzepte und Funktionen von HM (was ist peeren, wie spielt es zusammen mit Registern, wie arbeiten HM Statemachines)
- besprechen einzelner Aktionen (peeren, Register, Alarme, ....)
- Kochrezepte - wie implementiere ich einfach einen Treppenhausschalter (HMInfo könnte hier mächtig ausgebaut werden!)

In Wiki sehe ich immer noch nicht die wirkliche Option ein "buch" zu hinterlegen, das man einfach durchliest mit einer Reihenfolge und danach einen Überblick hat. Wiki ist sehr gut, einzelne Details zu klären. Man sollte gut aufpassen, alles nur EINMAL zu (er)klären und alles andere zu verlinken. Es stand sehr viel doppelt drin, immer wieder leicht anders und oft falsch. Man sollte also erst einmal ein Konzept für die Struktur in Wiki haben. Das erste Konzept: Beschreibung NUR von Devices macht m.E. keinen Sinn. Das ist nicht wartbar und meist falsch, zumindest irreführend.

zu beachten ist in jedem Fall für wen man was schreibt - also die Erfahrung des vermeintlichen Lesers.

So - meine Meinung. Die Dokumente sollten sich ergänzen.

Aber Doku mache ich wenig - wer möchte hat freie Hand.