Velux KLF200 mit Firmware 2.0.0.71 für io-homecontrol

[buennerbernd]

Ich hatte mich ja beklagt, dass die Verbindungen zur KLF200 Box so instabil sind.
Wie es aussieht, hat das Modul DevIo.pm seinen Anteil dazu beigetragen.
Ich hatte festgestellt, dass die Verbindungsabbrüche immer nur dann auftreten, wenn ich mit dem Handy im Web UI bin. Nachts oder wenn ich FHEM in Ruhe gelassen habe, war die Connection stabil. Also musste es irgendwie an FHEM liegen. Es scheint, als ob die in DevIo.pm verwendete Funktion syswrite für SSL ungeeignet ist.
Seit ich nicht mehr DevIo_SimpleWrite() aufrufe, sondern einfach $hash->{TCPDev}->write($bytes) konnte ich dieses Fehlerbild nicht mehr provozieren.

Die neue stabilere Version ist im Git.

Gruß, Stefan.

[pejonp]

Hallo Stefan,

ich habe mal das mit dem PW in das Modul eingebaut. Jetzt benötigt man keine extra Datei. Man kann es einmal hinterlegen, im KLF200 wird aber nichts geändert. Ich habe auch eine Version eingefügt. Diese muss allerdings von Hand angepasst werden.

Code Auswählen Erweitern


# $Id: 83_KLF200.pm 0009 2018-11-14 10:10:10Z buennerbernd $


Kannst du für FHEM nicht eine Datei bereitstellen damit man von FHEM das Update machen kann.  Ich mache das bei VBUS so (https://github.com/pejonp/vbus).

Code Auswählen Erweitern


update all https://raw.githubusercontent.com/pejonp/vbus/master/controls_vbus.txt


Ich habe bei mir mal die Icons für die Rolläden und die Fensterheber angepasst. Die Lampe hat mir nicht so gefallen. Könnte man diese nicht gleich an Hand des Types (nodeTypeSubType) einstellen. Vielleicht kann man auch noch den Hersteller (Velux, Somfy,..) mit anzeigen. In der API ist es ja vorhanden.
Ich würde es ja einpflegen, weis aber noch nicht wie und an welcher Stelle in der 83_KLF200Node.pm Datei.

Fensterheber

Code Auswählen Erweitern


attr Velux_2 devStateIcon off:fts_window_roof on:fts_window_roof_open_2


Rolladen

Code Auswählen Erweitern


attr Velux_3 devStateIcon on:fts_shutter_10@green off:fts_shutter_100@black 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100


Die Änderungen hänge ich mal hier an.

Tschüß Jörg

[Dr. Boris Neubert]

Hallo,

ich habe mal das mit dem PW in das Modul eingebaut. Jetzt benötigt man keine extra Datei.

das Passwort sollte nicht im aktuellen Verzeichnis gespeichert werden - wer weiß, ob FHEM dort Schreibrechte hat? Man sollte die Passwortdatei angeben können. Die Passwortdatei muss Rechte 600 bekommen.

Viele Grüße
Boris

[pejonp]

Hallo Boris,

Das passwort wir nicht im Klartext gespeichert, sondern kodiert und liegt in einem Verzeichnis von fhem.  Doch etwas sicherer als nur die Textdatei die angegeben wird. Kannst ja mal suchen wo diese liegt. 
Und ich finde es so etwas bedienerfreundlich.

Viele Grüße
Jörg

[CoolTux]

Verstehe ich das richtig das es hier lediglich um das aufbewahren eins Passwortes geht welches innerhalb des Modules Verwendung findet?
Für sowas hat FHEM doch eigene interne Funktionen.
setKeyValue
getKeyValue


Grüße

[pejonp]

Hallo,
Danke für den Hinweis

Pejonp

[buennerbernd]

Na hier war ja viel los. Also nacheinander:

Passworte:
Mir ist noch unklar, wie ihr euch den Ablauf vorstellt.
Am Anfang ist das Modul noch nicht instanziiert. Beim define benötigt man das Passwort. Man möchte nicht unbedingt, dass es gleich in DEF ersichtlich ist. Wo kommt es her, wie und wann kommt es dort hin? Wann soll setKeyValue aufgerufen werden? Wie machen das andere Module?

devStateIcon:
Da habe ich mich an Homematic orientiert und es vollständig dem Nutzer überlassen diese Icons zu setzen. Die Geschmäcker der Nutzer sind hier unterschiedlich. Ich mache das natürlich bei mir auch.
@Pejonp Stimmen bei dir die Icons von 1% bis 9%?
Bei mir sind zwar on und off getauscht, aber ich habe andere Patterns:

Code Auswählen Erweitern

attr <device-name> devStateIcon off:fts_window_2w on:fts_shutter_100 \d:fts_window_2w 1\d:fts_shutter_10 2\d:fts_shutter_20 3\d:fts_shutter_30 4\d:fts_shutter_40 5\d:fts_shutter_50 6\d:fts_shutter_60 7\d:fts_shutter_70 8\d:fts_shutter_80 9\d:fts_shutter_90 100:fts_shutter_100

update all:
Klingt interessant, das schaue ich mir mal in Ruhe an.

Momentan arbeite ich daran, dass das Modul auch mit den Namen der Szenen umgehen kann. Das mit den IDs ist mir zu abstrakt.
Und dann will ich ja auch noch die Queue realisieren.

Gibt es momentan noch richtige Bugs? Wie ist die Stabilität?

Gruß, Stefan.

[Dr. Boris Neubert]

Hallo,

Das passwort wir nicht im Klartext gespeichert, sondern kodiert und liegt in einem Verzeichnis von fhem.  Doch etwas sicherer als nur die Textdatei die angegeben wird. Kannst ja mal suchen wo diese liegt. 

ich habe mich nicht auf die Bedienerfreundlichkeit bezogen, die ist für mich sicher gegeben. Es geht darum, dass die Datei in jeder Anwendersituation an einer Stelle liegt, die FHEM auch beschreiben kann, und dass die Datei nicht für jedermann lesbar ist. Das Passwort wird so weit ich das sehe ja nicht verschlüsselt sondern nur verschleiert.

Ob eine Datei aus FHEM heraus überhaupt der optimale Weg ist, kann ich mit Blick auf DBConfig nicht beurteilen. Die DBConfig-Vertreter müssten sich dazu äußern.

Ich denke, dass CoolTux das Standardvorgehen für die Ablage von Passwörtern aufgezeigt hat, nicht wahr?

Viele Grüße
Boris

[CoolTux]

Ich denke, dass CoolTux das Standardvorgehen für die Ablage von Passwörtern aufgezeigt hat, nicht wahr?

Viele Grüße
Boris

Korrekt.

Na hier war ja viel los. Also nacheinander:

Passworte:
Mir ist noch unklar, wie ihr euch den Ablauf vorstellt.
Am Anfang ist das Modul noch nicht instanziiert. Beim define benötigt man das Passwort. Man möchte nicht unbedingt, dass es gleich in DEF ersichtlich ist. Wo kommt es her, wie und wann kommt es dort hin? Wann soll setKeyValue aufgerufen werden? Wie machen das andere Module?

Gruß, Stefan.

Hallo Stefan,

Du kannst nachträglich die DEF noch ändern, das wäre ein Weg. Aber nicht unbedingt nötig.
Der wie ich finde bessere Weg ist, Schreibe in den state eine Info das ein passwort über den set Befehl gesetzt werden muss. Sobald ein Passwort gesetzt wurde blendest Du den set Befehl in der set Liste aus

Code Auswählen Erweitern


$list .= " gardenaAccountPassword"
          if ( not defined( ReadPassword($hash) ) );

Eine Beispielimplementierung findest Du im Gardena Bridge Modul oder im HEOS Master Modul.

Setzt Voraus das innerhalb des Defines kein weiterer Routinenaufruf statt findet.
Damit Dein Modul dann anfängt seine Arbeit auf zu nehmen, musst Du eine NotifyFn hinzufügen und auf den Event des Passwort Set Befehles reagieren. Bei Fragen gerne Fragen.



Grüße

[Dr. Boris Neubert]

Du kannst nachträglich die DEF noch ändern, das wäre ein Weg. Aber nicht unbedingt nötig.
Der wie ich finde bessere Weg ist, Schreibe in den state eine Info das ein passwort über den set Befehl gesetzt werden muss. Sobald ein Passwort gesetzt wurde blendest Du den set Befehl in der set Liste aus
...
Setzt Voraus das innerhalb des Defines kein weiterer Routinenaufruf statt findet.
Damit Dein Modul dann anfängt seine Arbeit auf zu nehmen, musst Du eine NotifyFn hinzufügen und auf den Event des Passwort Set Befehles reagieren. Bei Fragen gerne Fragen.

Also DEF würde ich keinesfalls ändern. Die Definition kommt ja nicht zwangsläufig in die Konfiguration zurück, schon gar nicht bei save-Totalverweigerern wir mir. Und in die Definition gehören geheime Informationen auch nicht.

Der Fluss wäre wie folgt.

Im Define prüfen, ob ein Passwort vorhanden ist; wenn ja: Routine zum Verbindungsaufruf aufrufen, sonst Funktionalitäten deaktivieren und state auf Warnung setzen (analog zu dem Fall, dass ein Passwort vorhanden aber falsch ist).

Wenn der Anwender ein Passwort gesetzt hat mit set, wird die Routine zum Verbindungsaufruf erneut aufgerufen und weiter wie oben. Ein Notify braucht man da eigentlich nicht.

Ich diskutiere hier mit, weil ich nämlich das Kalendermodul auch noch so umschreiben muss, dass die geheime URL des Kalenders nicht in der Definition auftaucht. Vielleicht können wir hier eine Best-Practice entwickeln.

[pejonp]

Hi
Ich habe mir mal das Modul 73_gardenasmartbrigde.pm im github/leongaultier angesehen. Ich nutze die gleichen Funktionen. Digest::MD5
Wo ist das Problem?

Pejonp

[CoolTux]

Eine NotifyFn ist nicht unbedingt nötig, aber in meinen Augen macht es den Fluss einfacher. Es wird alles Eventbasiert geregelt. So wird zum Beispiel das Modul erst aktiv wenn die Hauptschleife von FHEM fertig initialisiert ist. Darauf kann man dann triggern. Genau so ist es bei set Befehlen oder anderen Events des Modules. Ich finde es einfacher.

Ist aber nur meine persönliche Meinung und Erfahrung 

[CoolTux]

Hi
Ich habe mir mal das Modul 73_gardenasmartbrigde.pm im github/leongaultier angesehen. Ich nutze die gleichen Funktionen. Digest::MD5
Wo ist das Problem?

Pejonp

Ich habe mir das gerade einmal angeschaut. Du verwendest in der Tat den selben Code. Aber wozu dann die Angabe von pwfile?
Die FHEM Routinen die verwendet werden speichern doch das Passwort dann verschlüsselt ins FHEM/FhemUtils/uniqueID File.

[buennerbernd]

Zum Verständnis: Muss ich mich bei
setKeyValue
getKeyValue
überhaubt selbst um Verschlüsselung/Verschleierung kümmern?

[CoolTux]

Ich habe mir das gerade einmal angeschaut. Du verwendest in der Tat den selben Code. Aber wozu dann die Angabe von pwfile?
Die FHEM Routinen die verwendet werden speichern doch das Passwort dann verschlüsselt ins FHEM/FhemUtils/uniqueID File.

Frage beantwortet. Das Passwortfile in der DEF ist mit dem von mir angeschauten Code absolete. Wird ja gar nicht mehr verwendet. So zu sagen toter Code.