erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[HCS]

... und es kann nicht immer alles sein, wie man es sich wünscht, ...

Ja, leider, ich hatte mir sooooo sehr die sortierten GADs in den cfg gewünscht.

[herrmannj]

ja, kommt  noch. Bin etwas zeit-knapp.

Dafür gibt es mit dem update viele Sachen zum Thema Stabilität, das ist ja auch wichtig. Da ist fronthem mit dem neuen update so das kaum noch Punkte drin sind wo was passieren sollte. Umso wichtiger wird jetzt, sollte wirklich was unvorhergesehenes passieren, das genau zu dokumentieren und in ein Szenario zu finden in dem ich das nachstellen kann.

Zum Editor: (@marvin), ich hab das nicht mehr ganz im Kopf wo Du Verbesserungen willst. Sag noch mal bitte oder waren das die GADs nach Dir/page ? Das geht halt einfach nicht.

Was ich noch in der pipeline habe ist eine Sortier- und Filterfunktion bei den GADs. Gedacht so das man die Liste filtern kann (nur GADs die aktuell in sv angezeigt werden sind in der Liste). Und eine Funktion um die GADs nach Zeit (letzter Zugriff) zu sortieren. Das hat aber bei mir keine hohe Prio weil ich der Meinung bin das man da ja "nur" konfiguriert - im Normalfall, im normalen Betrieb wenn alles eingerichtet ist, geht man da ja nicht bei.

Ansonsten nehme ich Vorschläge gern auf. Ehrlicherweise: ich muss halt auch immer abwägen wie der Zeiteinsatz ist um das dann zu machen und da fallen auch Sachen runter. 

vg
jörg

[fhainz]

hab gerade Deinen edith gelesen (wollte das gerade vorschlagen  Du hattest das irgendwie auf einem mac -richtig ? Ich schau da nochmal rein. Das wundert mich eigentlich weil der fork in der mutter gemacht wird, but who knows ...

Hast du dafür schon mal Zeit gefunden?

Grüße

[herrmannj]

@hsc,

driver: sehr cool, bin ihn eben überflogen. Ich hätte noch eine Idee, weiß aber nicht genau was die bringt. Thema ist die Zeit im update.

Normaleiweiße sind "each" und die Selektorsuche (line #171) echte Zeitfresser.
Idee wäre das widget-object selbst zu cachen, (array im driver), dann spart man sich für alle weiteren updates auf dem GAD die #171, ich vermute da >80% Zeit pro update damit gespart werden können (schätze, glaube .. )

vg
jörg

[herrmannj]

Hast du dafür schon mal Zeit gefunden?

Grüße

danke für den reminder - ich weiß nicht mehr genau worum das da ging. Sorry, sag noch mal bitte.

danke und vg
jörg

[fhainz]

Es ging um das Problem das bei mir ein shutdown restart nicht funktioniert bzw in einen

Code Auswählen Erweitern

2015.01.10 12:57:31.268 1: WEB: Can't open server port at 63191: Address already in use. Exiting. endet.

Siehe hier: http://forum.fhem.de/index.php/topic,30909.msg243206.html#msg243206

[herrmannj]

Ja, alles klar. Das soll, soweit es fronthem betrifft, vom Tisch sein, hab da einiges optimiert. Tritt immer noch auf ? Vorsicht, das kann auch völlig fronthem unabhängig sein.

Was ich oben vergessen habe zu erwähnen, in dem update sind auch die Sonderzeichen-fix drin.

vg
jörg

[marvin78]

@herrmannj: Ich bin eben der Meinung, dass der gad Editor eigentlich "übergeordnet" sein müsste und nicht innerhalb der fronthemDevices. Das ist aktuell inkonsequent. Der gad wird automatisiert in allen Devices angelegt und das konfigurieren (Device, converter, set etc) muss man es in EINEM Device. Um dann aber die Rechte für die anderen Devices anzupassen, muss man in jedes Device und in jeden Gad rein klicken, abspeichern etc. Das ist schon sehr unkomfortabel und Benutzer unfreundlich. Meinen Vorschlag hatte ich eigentlich schon mehrfach gepostet: Sinvoll wäre IMHO, den gad-Editor im fronthem und nicht im fronthemDevice zu haben. Dann dort eine breite Tabelle in der man für die Rechte Haken setzen und dann für alle Devices auf einmal abspeichern kann. Ich denke, du kannst dir vorstellen, was ich meine. Auch das wird unter Umständen auf kleinen Bildschirmen nicht gerade übersichtlich aber da könnten gute Filter etc. helfen.

ABER: Das ist wirklich Jammern auf hohem Niveau. In einer perfekten Welt...

[fhainz]

Ja, das tritt immer noch auf.
Sobald das fronthem Device gelöscht oder aus unbekannten gründen plötzlich abgeschmiert (siehe hier) ist, funktioniert der neustart problemlos, deswegen denk ich schon das es mit fronthem zusammenhängt.

Grüße

[HCS]

Was ich noch in der pipeline habe ist eine Sortier- und Filterfunktion bei den GADs.

Also so für die ganz ferne Zukunft wäre in den Spaltenköpfen ein "Excel-like" filter genial, um z.B. GADs zu filtern, die z.B. nicht R, W oder in der Bezeichnung etwas bestimmtes enhalten usw. Dazu noch Mehrfachselektion für das Löschen.
Und ohne es nun ganz gründlich zu überdenken, glaube ich, dass ich mich der "marvin78-Ansicht" anschließen kann.
Auch dafür bräuchte man dann leistungsfähige Filter und multiselect, sonst ist man immer noch am "durchklicken"
Und es klingt nach reichlich Arbeit.
Vielleicht findet sich ja jemand, der den ultimativen Editor schreiben möchte.
Fertigstellungstermin = Starttermin + Personenstunden / Anzahl Personen  (vereinfachte Formel)
Ist aber Prio 3

Zuerst sollten wir dann die Plots in Schwung bringen. Denk bitte dran, ich habe schon was vorbereitet.

Ach ja, ich habe das Interface für einen addon-driver geändert. Ich werde noch ein aktuelles Beispiel ins repository einchecken.
Wer schon einen geschrieben hat, sorry muss nun angepasst werden.

[herrmannj]

@marvin

sollte vielleicht - ja nach workflow auch beides gehen. Also "mutter" macht alle, "device" seins. Hatte ich nicht so dediziert verstanden.

Das Design ist aber auch aus einem Sachzwang heraus genau so. Theoretisch ist es möglich mehrere fornthem Instanzen zu betreiben. Ich hab zwar keine genaue Anwendung dafür aber sich so etwas offen zu halten ist eigentlich immer eine gute Idee (Stichwort: mehr als 16 Adressleitungen brauchen wir nieeeee). Dann würde die Mutter nicht mehr wissen welche device sie in der Liste darstellen soll (es sein denn sie sind gerade aktiv).

Muss ich nochmal nachdenken. Aber ich denke es ist ok das nicht ganz oben auf der Liste zu haben, da seh ich eher Stabilität, Plots, app. OK ?

vg
jörg

[herrmannj]

@HCS

Ach ja, ich habe das Interface für einen addon-driver geändert.

btw, Du wolltest einen Filter in fronthem haben. Der ist rudimentär im fronthemDevice in line #635 angelegt. Der wird erweitert werden, ich brauch den später für die APPs (tts, brightness, play, voice und co) per plugin. Allerdings kommt da noch viel zu, wenn Du was änderst wird das von updates überschrieben werden.

Da sind die "mutter" und das "device" involviert. Die "mutter" soll die app spezifischen Funktionen ja nicht in die cfg übernehmen, das device muss aber seine set-list anpassen. Fürs erste aber hardcoded dort ein Einstiegspunkt.

Im Augenblick filtere ich GADs die mit "internal.".. beginnen - die funktionieren also nicht mehr als reguläres GAD.

vg
jörg

[marvin78]

@HCS: Das hast du gesehen?

@hsc,

driver: sehr cool, bin ihn eben überflogen. Ich hätte noch eine Idee, weiß aber nicht genau was die bringt. Thema ist die Zeit im update.

Normaleiweiße sind "each" und die Selektorsuche (line #171) echte Zeitfresser.
Idee wäre das widget-object selbst zu cachen, (array im driver), dann spart man sich für alle weiteren updates auf dem GAD die #171, ich vermute da >80% Zeit pro update damit gespart werden können (schätze, glaube .. )

vg
jörg

[herrmannj]

Ja, das tritt immer noch auf.
Sobald das fronthem Device gelöscht oder aus unbekannten gründen plötzlich abgeschmiert (siehe hier) ist, funktioniert der neustart problemlos, deswegen denk ich schon das es mit fronthem zusammenhängt.

Grüße

hmmm. Auch mit dem update von gestern ?

[fhainz]

Ja. Hab gestern ein update gemacht.