Hallo,
ich hab gestern 2 HM-LC-Bl1PBU-FM in Betrieb genommen und wollte den Wikieintrag mal etwas Einsteigerfreundlicher "erweitern": http://www.fhemwiki.de/wiki/HM-LC-Bl1PBU-FM_Unterputz-Jalousieaktor. Nun steht im Wikieintrag:
ZitatOptionale Attribute - empfohlen
- autoReadReg 5_readMissing
- event-on-change-reading .*
- expert 0_off
Leider steht nicht dabei warum es empfohlen wird. Ich würde gerne Gründe dazu schreiben oder es rausnehmen. Ich würde noch ein Codebeispiel für das drive up und drive down hinzufügen und dazuschreiben, das man die Zeit die der Rollladen für Aufwärts und abwärts braucht stoppen muss. Ich hab meine Werte einfach aufgerundet. Ich denke etwas zu lang ist besser als knapp zu kurz?!
das sind allgemeine Empfehlungen. Die sollten nicht in ein device sondern generell in Homematic oder in ein "homematic empfehlungen".
Im Device sollte man nur dorthin referenzieren.
Ansonsten musst du dies in quasi allen WIKI eintragen nachziehen.
Zur erklärung bietet sich das Commandref an- auch das könnte man verlinken. Das gilt zumindest für
expert: Empfohlene einstellung ist "schlankes Frontend"
autoReagReg: automatisches lesen der Register bei Änderungen - daten aktuell halten
Erklären könnte man event-on-change-reading. Das Kommandref erklärt nur die Funktion. Man könnte darauf hinweisen, dass ".*" performance spart, da ereignisse nur bei Änderung trigger erzeugen.
Ich empfehle nicht, dass kommandref hier einfach zu wiederholen. User von Wiki sollten das kommandref bei Fragen zuerst lesen. Wiki gibt empfehlungen für kombinationen.
Es kann auch zu viel text geben - wenn etwas ständig wiederholt wird. Das wird mit sicherheit inkonsistent - und das ist das schlechteste überhaupt.
Wenn du also etwas tun willst, wäre es meiner Meinung nach das Beste, wiki zu strukturieren
- Devices einrichten: allgemeine Attribute, register, settings, commands
- channels dito
- remotes: register beschreiben, peering, register (burst/aes/sign)
- switch-actor dito
- blind dito
...
dann die Modelle. Diese MÜSSEN auf die allgemeinen Erklärungen referenzieren, nicht kopieren!
was hältst du davon?
Danke für deine Ausfüührliche Antwort. Ja das klingt sinnvoll, einfach zu verlinken, so nach dem Motto wie bei allen HM geräten sind folgende Einstellungen zu empfehlen und dann hierhin zu verlinken: http://www.fhemwiki.de/wiki/HomeMatic#Attribute
Ich werde mich da mal durch wurschteln und dann hier schreiben, vielleicht magst du dann abschließend einmal drüber schauen.
genau da hatte ich einmal angefangen... das mit den Attributen. Es muss noch viel aufgeräumt werden.
Das Vorgehen (glaube ich zumindest) sollte von allgemein nach speziell gehen. Also erst die Allgemeinen webseiten anlegen (attribute, pairen, peeren...) dann Subtypes (rollo, schalter, remote) und dann kann man die modele aufräumen.
Im Modell kann man dann Zusätze und Abweichungen der jeweils allgemeineren Anleitung hinterlegen.
Was ich überlege
- Aufbau der allgemeinen Erklärungen (das meiste ist jetzt in homematic) - sollte das aufgespalten werden? Sollte man ggf jetzt machen, damit die Links dann passen.
- subtype festlegen: Man kann einen "type Blind" erstellen (usw) oder ein modell als referenz heranziehen. Das mit "type..." gefällt mir besser, weil es sauberer ist.
Leider ist mein Wiki-User schon wieder gesperrt... da klappt immer etwas nicht - noch nicht einmal das Rücksetzen
Ich sehe du bist zur Zeit im großen Aufräumen :-).
Also wenn ich dich richtig verstehe sollte das dann so aussehen
- Homematic -> Allgemeine Infos zu Homematickomponenten und FHEM
- Attribute
- pairen
- peeren
- burst
- aes
- ...
- Subtypes
- Blindactuator -> Grundästzliche Infos zu Blindaktoren mit Verweisen auf die allgemeineren Homematic Informationen
- Unterputz Jalousieaktor -> spezielle Informationen zum HM-LC-Bl1PBU-FM mit Verweisen auf die allgemeineren Subtype-Informationen
- Aufputzjalousieaktor
- ...
- Schaltaktor
- Dimmer
- ...
Nun habe ich das Problem, das mir ein wenig die Übersicht fehlt, welche Subtypes gibt es. Aber wenn du willst können wir uns das hier erarbeiten?
zu einigen habe ich schon etwas geschrieben
aes
pairen
peeren
zu den subtypes:
man muss nicht alle subtypes habe, bevor man mit dem modellen anfängt. Du musst also nicht alle kennen.
So mal in 5 min sehe ich
blind, switch, dimmer, remote, sensor
Evtl noch heating. Bei einem TC-IT kann man dann beim Weather Kanal auf den Sensor verweisen. Ein Sensor ist ein Device, das einen oder mehrere Werte liefert.
SDs sind eine klasse für sich...
Wenn du also mit blind anfangen willst könntest du das Programmieren der Fahrzeiten beschreiben - das haben alle. Ach das Verhalten - also dass es über eine Zeitsteuerung funktioniert, dass nach reboot immer 50% angenommen wird, wie up/down/on/off/pct funktionieren.
danach kannst du die einzelnen modelle der Dimmer bearbeiten.
Beim Dimmer kann man u.a. die Virtuellen Channels erklären, die zwar nicht bei allen dimmern vorhanden sind, aber bei einigen.
Schön fände ich dann auch eine einheitliche Gliederung... das meiste wiederholt sich schematisch.
Gruss Martin
Ich schau mal was meine Zeit zuläst. Also brauchen wir vorallem erstmal subtype Seiten: Powermeter gibts auch noch.
Macht es auch Sinn, die Geräte in der Homematic Übersicht vielleicht danach zu sortieren?
Wie würdest du denn den Seitentitel nennen?
HomeMatic Type Blind
Wäre vielleicht auch noch Sinnvoll irgendwo die Typen zu erklären?! Vielleicht kann man das auch irgendwie bei der Erklärung für die Typenbezeichnung mit anhängen.
die Seite ist Homematic. kann man schreiben, muss man nicht.
Sie aktuellen Bezeichnungen gefallen mir nicht alle.
HomeMatic Devices pairen
Homematic Peering Beispiele
Homematic Nachrichten sniffen
unschön, schlecht zu suchen. Man könnte wichtige Aktionen gruppieren (vielleicht werden es noch mehr, die man "auslagern" sollte)
Aktion Pairen
Aktion Peering
Aktion Sniffen (oder debuggen)
....
das mit type finde ich gut
Type Blind
Type Switch
Type Remote
Type Dimmer
Type Sensor
...
dann könnte man noch eine Gruppe Grundlagen machen
Basic AES encryption
Basic Gerät Einrichten
dazu müsste man die alten Dokus umziehen....
aber das sind nur meine Vorstellungen.... man kann erst einmal langsam beginnen - und den wildwuchs ausmisten.
wenn du also erst einmal mit Type Blind anfängst, wäre gut. Und bei allem was noch allgemeiner, musst du es auch so beschreiben- Pairen ist nicht blind spezifisch.
Den User/Anfänger wird es masslos verwirren, wenn das gleiche leicht unterschiedlich 2 mal beschrieben wird.
Aber wenn du das konzept verstanden hast und damit einverstanden bist, fange einmal an.
Klingt gut, ich fang einfach mal an. Ich fang erstmal an und gleiche die Wikieinträge der 3 Rolladenaktoren an und baue es daran prototypisch und dann schreib ich mal wieder hier. Von den Grundsätzlichen Themen lass ich erstmal die Finger. Da sind auch meine Wissenlücken viel zu groß. Und dann mal Stück für Stück.
Als Bezeichnung würde ich dann Homematic Type Blind nehmen.
prima.
Wenn es generelle Themen gibt, die dir Fehlern oder die dir nicht komplett/hinreichend erscheinen, lass es mich wissen. Du solltest diese nicht in den spezifischeren Blöcken beschreiben - sonst kriegen wir das nicht gebacken. m.M. kann man das nur von Unten nach oben aufräumen.
So bei machen fällt mir dann auf: Das ist ein radikaler Umbau, aber da fällt auch vieles doppelte und dreifach geschriebene weg. Es steht ja auch beim Aufputz Jalousieaktor, wird konfiguriert wie der andere. Das kann man dann wirklich besser für alle 3 auf den Subtype auslagern. Zum Glück kann man im Wiki alles Rückgängig machen, ist schon komisch so starke Veränderungen da durchzuführen.
eigentlich sind es mehr.
mit
get hm models -f blind
bekommst du die Liste der vorhandenen. Ob jeder einen eigenen Eintrag wert ist... die Schueco sind rechst selten - habe noch keinen in FHEM gesehen... ROTO erst einen. Die Unterschiede kenne ich auch nicht alle. Das "-2" ist evtl eine neuere HW version. Könnte man erwähnen
subType name ID supportedMode Info List channels
blindActuator HM-LC-BL1-FM 0005 normal 1,3
blindActuator HM-LC-BL1-PB-FM 0053 normal 1,3
blindActuator HM-LC-BL1-SM 0006 normal 1,3
blindActuator HM-LC-Bl1-FM-2 00D2 normal 1,3
blindActuator HM-LC-Bl1-SM-2 00D1 normal 1,3
blindActuator HM-LC-Bl1PBU-FM 006A normal 1,3
blindActuator ROTO_ZEL-STG-RM-FEP-230V 007B normal 1,3
blindActuator Schueco_263-146 0086 normal 1,3
blindActuator Schueco_263-147 0087 normal 1,3
blindActuatorSol WDF-solar 0096 burst 1,3 1 win, 2-3 blind,
Danke für den Hinweis. Das ist gut so ein Übersicht zu bekommen.
Ich hab die Geräte mal hinzugefügt und die verlinkt für die es einen Wikieintrag gibt. Letztendlich sind von den genannten nur die 3 von mir eingesetzten im Wiki, auch über HM-LC-BL1-PB-FM finde ich per Google keine Infos. Sind das die alten Geha Schalter?
Schwierig finde ich auch mit den -2 Geräten umzugehen, es gibt welche die Fensterkontakte SEC-SC wo die Unterschiede schon groß sind und es gibt andere, da sind die Unterschiede mir nicht bekannt. Aber ich glaube das würde ich dann innerhalb des Wikieintrages erwähnen, das es 2 Versionen gibt und ob Unterschiede bekannt sind.
Schwierig wird es für mich zu entscheiden was ist jetzt typisch für ein Blindaktor und was ist Gerätespezifisch. Muss ich bei allen z.B. die Fahrzeit für das Rollo einstellen? Bei denen für die es einen Wikieintrag gibt weiß ich das, da ich es nachschauen kann. Ich möchte ja so wenig doppelte Information wie nötig.
Kannst ja noch mal drauf schauen: http://www.fhemwiki.de/wiki/HomeMatic_Type_Blind
Noch eine Nachfrage bevor ich das einfach ändere beim HM-LC-BL1-FM steht folgendes:
set <name> <Zweistellige Zahl> -> Schaltet den Aktor ein und öffnet die Jalousie um <Zweistellige Zahl>%. 100% entspricht dabei einem "on"
müsste aber doch auch so sein oder? Nur mit up down wir um xy % verändert?!
set <name> <Prozentangabe[0 bis 100]> -> Öffnet die Jalousie auf absolut prozentuale Öffnungsposition, berechnet aus definierter Laufzeit.
Hab da noch eine Frage da steht auch noch
Wichtig: Danach unbedingt am Aktor auf Anlernen drücken, damit er die regSets abarbeiten kann. Ob alles geklappt hat, kann man überprüfen mit :
set <name> getConfig
get <name> reg all
Ich musste bei mir den Anlernknopf nicht noch mal drücken, ist das evtl. unterschiedlich je Aktor? Ich kenne das eigtl. nur von den ThreeState Sensoren und da ist es beim neuen SEC-SC-2 auch nicht mehr nötig.
up und down haben einen default von 10%. man kann auch andere Werte eingeben. zweistelling muss es nicht sein -blödsinn. Schritte von 0.5% sind erlaubt.
ZitatIch musste bei mir den Anlernknopf nicht noch mal drücken, ist das evtl. unterschiedlich je Aktor? Ich kenne das eigtl. nur von den ThreeState Sensoren und da ist es beim neuen SEC-SC-2 auch nicht mehr nötig.
da hast du vollkommen recht. Anlernen ist notwending, zum pairen und wenn das Device nicht dauer-wach ist. i.a. batteriebetriebene Devices. So eine Beschreibung ist recht raumgreifend und sollte in ein allgemeines Kapitel. Ist nicht Rollo-spezifisch.
Hier ein paar Anmerkungen... kannst du evtl einbauen... oder ignorieren.
Was erklärt werden sollte ist in einer Beschreibung die Prozent Berechung, das Verhalten nach power-up des Aktors (50%-regel...). Danach sollten die Angaben in den Kommandos usw. klar sein.
Wissenswert ist somit, dass lange Rollos nicht so präzise zu steuern sind wie kurze. Das ist insbesondere von Bedeutung beim kippen von Jalousien.
danke
HomeMatic Geräte vom Typ Blind
=> Verweis: die aktuelle liste kann mit HMInfo "infos" abgefragt werden
Kommando get hm models -f blind
### da die Liste einer kontinuierlichen Änderung unterliegt solltest du es "flexibel" machen
### Generell sollte man links nach Unten einbauen (model->blind->HMallgemein) Die andere Richtung ist auch schön, aber arbeitsintensiv.
Konfiguration
Die Konfiguration des Devices betrifft <u>[[HomeMatic#Register]]</u> und Peerings. Dies sind Werte, die über FHEM '''im Flash des Device''' gesetzt werden.
Das Device muss zuerst mit FHEM <u>[[HomeMatic Devices pairen#Devices Pairen|gepairt]]</u> werden.
Danach werden Kanäle nach bedarf gepeert.
Beachte auch [[Homematic_HMInfo#Templates]] zur einfachen Modifikation von Register. Aktuell verfügbar sind templates zum stoppen des Rollos mit beliebigen Tastendruck, falls der Rollo fährt
BlStopDnLg Info:Blind: stop drive on any key - for long drive down
BlStopDnSh Info:Blind: stop drive on any key - for short drive down
BlStopUpLg Info:Blind: stop drive on any key - for long drive up
BlStopUpSh Info:Blind: stop drive on
Mögliche Schaltoperationen
Beachte "param levelInverse" zur Bedeutung der Prozentwerte.
Die Steuerung der Rollostellung erfolgt prozentual und wird über die Fahrzeiten ermittelt. Der Aktor kennt nicht die wirkliche Stellung des Rollos sondern errechnet diese aus den gefahrenen Zeiten. Die eingestellt Fahrzeit ist sind dabei der 100% Referenzwert.
Nach einem Neustart des Aktors (spannungsausfall,...) wird eine aktuelle Stellung von 50% angenommen. Durch fahren des Rollos in beide Endstellungen kann der Aktor die korrekte Einstellung wieder errechnen. Es kann aber sein, dass man entsprechend oft in eine Richtung fahren muss um dies zu erreichen. Steht der Rollo auf effektiv 0% und es kommt zum neustart nimmt der Aktor 50% an. Fährt man nun nach 100% wird der Aktor +50% fahren, also in die Mitte. Dann hat er real 50%, errechnet aber 100% und bleib stehen. Man kann durch mehrfache Eingaben von 100% ein "überfahren" der 100% Marke erreichen und der Rollo wird langsam 100% real erreichen.
set <name> on # fahren des Rollos auf 100%
set <name> off # fahren des Rollos auf 0%
set <name> toggle # umschalten von 0% auf 100% oder umgekehrt
set <name> <level> # Öffnet den Rollo auf absolut Position "level" in Prozent 0-100.
set <name> up/down <change> # Öffnet oder schließt den Rollo um "change" Prozent. default ist +- 10%
set <name> stop # stoppt die Fahrt
ich hab gerade einen neuen HM-LC-Bl1PBU-FM in betrieb genommen und bin mir ziemlich sicher das zum sichtbar schalten der internen taster und zum zum konfigurieren mit regBulk die anlerntaste gedrückt werden muss. sonst bleiben die kommandos pending.
gruss
andre
ps: wenn man bei regBulk eine register liste angibt die es nicht gibt (z.b. wenn man sich vertippt oder mal wieder vergessen hat das es RegL_03 und nicht List03 heissen muss :) ) dann schmiert der aktor so komplett ab das nur ein rücksitzen aus werkseinstellungen, ein löschen aus fhem und neu pairen hilft. vielleicht könnte man den namen der register liste prüfen?
Hi Andre,
zum sichtbar machen der internen Tasten braucht es keine Config taste.
ausser bei Anlernen:
- falls man die Config-taste benötigt, dass immer zum übetragen - oder nie.
- bei wakeup devices wartet man bis sie aufwachen - oder man drückt anlernen, das bescheunigt.
Zitatwenn man bei regBulk eine register liste angibt die es nicht gibt (z.b. wenn man sich vertippt oder mal wieder vergessen hat das es RegL_03 und nicht List03 heissen muss :) ) dann schmiert der aktor so komplett ab das nur ein rücksitzen aus werkseinstellungen, ein löschen aus fhem und neu pairen hilft. vielleicht könnte man den namen der register liste prüfen?
- eine minimalprüfung kann es geben, ist auch schon drin. Aber wer regBulk nutzt sollte wissen, was er tut. Das ist ein zugriff auf die rohdaten - da soll man eben mehr können. Eine Prüfung der Daten bekommst du mit regSet.
- normal reicht aber ein power-zyklus. Also einmal sicherung. Rücksetzen musste ich noch nie.
- löschen aus fhem halte ich für unwahrscheinlich - sollte nicht notwendig sein
- pairen musst du nur, wenn du werkseinstellungen gesetzt hast.
=> falls du regList 0 zerschossen hast ist es schon notwendig - da steht ja das pairing drin.... geht zwar auch ohne reset - aber da musst du etwas basteln. FHEM löschen glaube ich auch hier nicht.