Wikieintrag zu HM-LC-Bl1PBU-FM

Begonnen von strauch, 14 April 2014, 10:14:36

Vorheriges Thema - Nächstes Thema

strauch

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?!
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

martinp876

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?



strauch

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.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

martinp876

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

strauch

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?
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

martinp876

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


strauch

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.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

martinp876

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.


strauch

#8
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.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

martinp876

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.

strauch

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.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

martinp876

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,

strauch

Danke für den Hinweis. Das ist gut so ein Übersicht zu bekommen.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

strauch

#13
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
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

strauch

#14
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.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.