Modul-Entwicklung: Somfy RTS

Skusi · 14 Juni 2015, 09:57:36

Hallo,

ich bin begeistert von dem Somfy Modul. Als ich mit Fhem anfing, war das das erste Modul das eingebunden wurde, da mein Haus komplett mir Somfy Funk Rollladen bestückt ist. Seit dem optimiere ich die Steuerung ständig und versuche immer mehr intelligente Funktionen zu realisieren.

Da die aktuell eingecheckte Version 1.5 viele Problem mit der Auswertung der Position über state aufwirft und deshalb meine Doif´s immer wieder Mist bauen, war ich voller Erwartung als ich durch Zufall auf GitHub eine Version 1.6 gefunden hatte.

Nun habe ich diese dann zu Testen von Hand Installiert und festgestellt das das mit den Positionen schon seeehr viel besser funktioniert.

Leider stürzt allerdings nach einigen Fahrbefehlen mein auf dem RASPI laufendes Fhem ab. Und ich bekomme beim starten immer folgende Meldungen:

Prototype mismatch: sub main::max ($@) vs (@) at /usr/share/perl/5.14/Exporter.pm line 67, <$fh> line 398.
at ./FHEM/10_SOMFY.pm line 55

Prototype mismatch: sub main::min ($@) vs (@) at /usr/share/perl/5.14/Exporter.pm line 67, <$fh> line 398.
at ./FHEM/10_SOMFY.pm line 55

Irgend was scheint da mit meinem Perl Exporter nicht zu harmonieren. Was kann ich tun um das zum laufen zu bringen ?
Ist da im Somfy Modul noch ein Fehler, oder muß ich an meiner Perl Installation was ändern ?
Ich hoffe das dann auch die Abstürze vorbei sind.

Die Version 1.6 macht seine Sache soviel besser als die 1.5 das ich alles daransetzten werde die zum laufen zu bringen.

An dieser Stelle auch mal riesen Dank an die Mitwirkenden thdankert, Elektolurch und viegener !!!
Großen Respekt! Ich wünschte ich könnte auch so was schreiben. Aber ich bin ja schon zufrieden das ich mit Fhem so gut klarkomme. Ist schon wie ne Sucht geworden. Da ich MSR Techniker von Beruf bin kann ich auch Privat nicht anders.

Ich bitte hier also dringend mal um Hilfe. Ich hoffe mir kann da jemand eine Tipp geben wie ich an der Stelle weiter komme.

---Skusi

thdankert · 14 Juni 2015, 11:02:56

Zitat von: Skusi am 14 Juni 2015, 09:57:36
Leider stürzt allerdings nach einigen Fahrbefehlen mein auf dem RASPI laufendes Fhem ab. Und ich bekomme beim starten immer folgende Meldungen:

Prototype mismatch: sub main::max ($@) vs (@) at /usr/share/perl/5.14/Exporter.pm line 67, <$fh> line 398.
at ./FHEM/10_SOMFY.pm line 55

Prototype mismatch: sub main::min ($@) vs (@) at /usr/share/perl/5.14/Exporter.pm line 67, <$fh> line 398.
at ./FHEM/10_SOMFY.pm line 55

Hallo Skusi,

danke für das Lob! Kannst du das Problem als Issue im Github-Projekt einstellen? Dann vergess ich das nicht (bin ab Morgen im Urlaub), und kann nach einer Lösung suchen.

Grüße,
Thomas

Skusi · 14 Juni 2015, 11:21:54

Hallo Thomas,

danke für die schnelle Reaktion.
Ich habs bei GiHub eingestellt (hoffentlich richtig ?) !
Hab ich Dich ja noch gerade erwischt.

Da Du wohl im Urlaub nicht an Fhem schrauben wirst (-oder ?) werde ich mich wohl ein par Wochen gedulden müssen.

Naja, die Lösung zählt !!!

Ich wünsche eine erholsamen Urlaub !

---Skusi

viegener · 26 Juni 2015, 01:24:52

Hallo Skusi,
Irgendwie war mir dieser Thread bisher entgangen.
Ich habe hier mal eine aktualisierte Version angehängt, in der die Fehlermeldung wohl nicht mehr auftritt.

Erklärung: min und max können normalerweise aus dem Util-Modul importiert werden, dass standardmässig bei Perl enthalten ist. Allerdings wird wohl irgendwo in FHEM eine eigene Definition von min und max gemacht, deshalb kommt es zu der Meldung.
Ich habe den use / import-Teil jetzt mal herausgenommen, das läuft bei mir bisher ohne Probleme.

Lass mich wissen, ob das auch bei Dir funktioniert.

Gruss,
Johannes

viegener · 26 Juni 2015, 01:38:21

Und noch ein Hinweis: Ich habe das Problem mit den Abstürzen nicht reproduzieren können. Ich denke aber es hängt zumindest nicht mit den obigen Fehlermeldungen zusammen. Bei mir läuft FHEM auf einem pi2.

Sind die Abstürze erst mit der Version 1.6 aufgetreten und waren weg nachdem Du die 1.5 wieder eingespielt hast?

Johannes

Skusi · 29 Juni 2015, 19:23:22

Hallo viegener,

nun bin ich mal dazu gekommen dein angepasstes Modul auszuprobieren.

Die Fehlermeldung beim Start ist schonmal weg !

Abstürze habe ich bisher auch noch nicht gehabt. Ich habe das Modul aber auch gerade erst ausgetauscht und vom Update ausgeschlossen. Die ersten Fahrbefehle sahen schon sehr gut aus. Nun haben ich auch wieder den exakten Positions State. Vielen Dank schonmal für diese Aufwertung.

Ich werde die Tage mal beobachten wie stabil die Sache läuft.
Ich betreibe Fhem übrigens auch auf einem Raspi 2.

Warum ist die 1.6 Version denn noch nicht eingecheckt ? Ist noch zu Beta ?
Ich finde die angaben des Pos im state sehr hilfreich. Schön ist dabei auch das während des fahrens nun miene StateIcons fein "mitlaufen"

Vielen dank erstaml für die Unterstützung. Ich berichte wieder wenn mir was auffällt.

---Skusi

viegener · 29 Juni 2015, 22:09:22

Zitat von: Skusi am 29 Juni 2015, 19:23:22
Warum ist die 1.6 Version denn noch nicht eingecheckt ? Ist noch zu Beta ?

Soweit ich gelesen habe ist Thomas noch in Urlaub und ich finde es löblich, dass er vor seinem Urlaub nicht noch schnell einen neue Version freigegeben hat, denn das kenne ich aus eigener Erfahrung: das geht gerne mal schief

Elektrolurch · 30 Juni 2015, 08:49:49

Hallo,

ich hatte ja meine "private" Version wegen der korrekten Anzeige und des Auskommentierens der parseFn.
Nun habe ich gestern die V1.6 vom Beitrag oben mal eingespielt und heute morgen haben wir alle verschlafen. :-D
Ich hatte dem set-Befehl die Optionen "open" und "close" noch hinzugefügt, weil ich das deutlich eingängiger als "on" und "off" für einen Rolladen sehe.
Die fehlen aber in der 1.6.

Elektrolurch

viegener · 30 Juni 2015, 11:36:37

Zitat von: Elektrolurch am 30 Juni 2015, 08:49:49
Nun habe ich gestern die V1.6 vom Beitrag oben mal eingespielt und heute morgen haben wir alle verschlafen. :-D
Ich hatte dem set-Befehl die Optionen "open" und "close" noch hinzugefügt, weil ich das deutlich eingängiger als "on" und "off" für einen Rolladen sehe.
Die fehlen aber in der 1.6.

Elektrolurch

Ausschlafen tut doch auch mal gut

Ich kann das gerne noch hinzufügen, ich hatte bei mir Open und close auch, habe das aber über eine eventmap realisiert:

Code Auswählen


eventMap on:close off:open stop:halt

Vielleicht hilft Dir das sogar schneller weiter?

Gruss,
Johannes

Elektrolurch · 30 Juni 2015, 12:05:25

Hallo Johannes,

klar ginge das mit eventMap, daran hatte ich auch gedacht.... aber nun kommt auch noch Deutsch und Englisch hinzu:

Meine Definition zur Zeit:
eventMap /open:offen/close:geschlossen/pos 100:gesperrt/pos 80:Dämmerung/pos 70:Sonnenschutz/

Und dann muss man noch schauen, wie readingsGroup damit umgeht. 'state' und STATE meine ich.

Wenn man es einbauen könnte, fände ich es schon schöner.
Einmal bei der Ausgabe von set xxx ?
und in der set-Routine überall da, wo auf on/off abgefragt wird es mum open/close ergänzen.
So hatte ich es (so glaube ich) drin.

Elektrolurch

thdankert · 30 Juni 2015, 20:13:09

Hi zusammen,

Zitat von: viegener am 29 Juni 2015, 22:09:22
Soweit ich gelesen habe ist Thomas noch in Urlaub und ich finde es löblich, dass er vor seinem Urlaub nicht noch schnell einen neue Version freigegeben hat, denn das kenne ich aus eigener Erfahrung: das geht gerne mal schief

Und jetzt bin ich wieder erholt zurück und wir können gern die neue Version festzurren und freigeben

Zitat von: Elektrolurch am 30 Juni 2015, 12:05:25
klar ginge das mit eventMap, daran hatte ich auch gedacht.... aber nun kommt auch noch Deutsch und Englisch hinzu:

Genau dafür ist eventMap da - in vielen anderen Modulen heißen die Kommandos ebenfalls on/off/stop, da möchte ich ungern die Ausnahme sein.
Englisch ist beim Programmieren einfach weiter verbreitet.

Zitat
Und dann muss man noch schauen, wie readingsGroup damit umgeht. 'state' und STATE meine ich.

@Elektrolurch: was genau meinst du? Gibt es bei Verwendung einer readingsGroup noch Probleme?

@Johannes: hast du noch weitere Änderungen gemacht, die vielleicht noch von einer größeren Nutzergruppe getestet werden sollten, bevor es eine neue Version gibt?
Wenn nicht, kann ich das gern einchecken, dann ist es morgen/übermorgen per Update verfügbar.

Grüße,
Thomas

viegener · 01 Juli 2015, 00:55:38

Zitat von: thdankert am 30 Juni 2015, 20:13:09
@Johannes: hast du noch weitere Änderungen gemacht, die vielleicht noch von einer größeren Nutzergruppe getestet werden sollten, bevor es eine neue Version gibt?
Wenn nicht, kann ich das gern einchecken, dann ist es morgen/übermorgen per Update verfügbar.

Nein, ich sehe die Änderungen von oben mit dem Util package und der direkten Änderung des Status hast Du selber bereits nachgezogen (das nächste Mal bekommst Du auch einen pull request).

Also aus meiner Sicht wäre es soweit ok,
Johannes

thdankert · 01 Juli 2015, 10:07:43

Danke, ich habe gerade die neueste Version eingecheckt, ab morgen früh ist sie dann per FHEM update verfügbar.

Elektrolurch · 02 Juli 2015, 14:23:00

Hallo Johannes,

habe die Version aus dem fhem gerade ausprobiert.
Da hat sich bezüglich der Position noch ein kleiner Fehler eingeschlichen:

Das set - Kommande akzeptiert "pos", intern (in _UpdateState) aktualisierst Du aber "position" und nicht das reading "pos".
Das hat den Effekt, dass, wenn man das Aufklappmenü pos:0...100 aus dem Modul verwendet, das Menü nach der Positioniererei nicht mehr stimmt.

Wir haben jetzt zwei gleiche readings: pos und position.
Vermutlich würde es reichen, überall wo position verwendet wird, pos zu verwenden. Dann wäre es wieder stimmig.

Alles andere muss ich über eventMap und devStateIcon anpassen.

Gruß

Elektrolurch

viegener · 02 Juli 2015, 21:00:00

Zitat von: Elektrolurch am 02 Juli 2015, 14:23:00
Hallo Johannes,

habe die Version aus dem fhem gerade ausprobiert.
Da hat sich bezüglich der Position noch ein kleiner Fehler eingeschlichen:

Das set - Kommande akzeptiert "pos", intern (in _UpdateState) aktualisierst Du aber "position" und nicht das reading "pos".
Das hat den Effekt, dass, wenn man das Aufklappmenü pos:0...100 aus dem Modul verwendet, das Menü nach der Positioniererei nicht mehr stimmt.

Wir haben jetzt zwei gleiche readings: pos und position.
Vermutlich würde es reichen, überall wo position verwendet wird, pos zu verwenden. Dann wäre es wieder stimmig.

Alles andere muss ich über eventMap und devStateIcon anpassen.

Gruß

Elektrolurch

Hallo Elektrolurch,
vermutlich ist es heute zu warm, aber ich verstehe Deine Beschreibung leider nicht. Auch wenn ich "set pos" verwende, bleibt es bei mir dabei, dass ich nur ein Reading habe: position. Ich habe in den alten Stand geschaut (von Maerz) und auch dort heisst das Reading position. Kann es sein, dass das pos Reading noch woanders herkommt?

Den Unterschied, den ich finden konnte ist, dass heute in state direkt numerische Werte stehen und früher dort Einträge der Art "pos 50" standen. Das hatte ich beim Umbau übersehen. Wenn gewünscht liesse sich das sicher wieder umstellen.

Gruss,
Johannes