[Featurewunsch] items-kategorien / feedback

[ozett]

mache jetzt die ersten schritte mit smarthome/smartvisu. zuvor habe ich einige projekte mit ets und homeserver3/4 gemacht.

die smartvisu sieht sehr gut aus und ich denke, die entwicklung lebt auch vom feedback und know-how transfer (best breed ;-)), so dass ich auch mal eine kleine anmerkung zusteuern möchte. wenn ich wüsste, wo das systematisch für das entwicklertem eingespeist werden soll, dann würde ich das dort machen. vielleicht ist ja hier auch der richtige ort. also:

nachdem ich mich etwas mit der syntax der items.conf angefreundet habe:

-die trennung und pfade für die items(x).conf(en) ist etwas inkonsistent.

ich kann bislang auch nicht sofort erkennen, wo die datei hin müsste, wenn man nur die smartVISU _ohne_ smarthome.py betreiben würde. auch ist man zunächst unter linux eher an /etc/smart../x.conf gewöhnt. würde ich sagen.

- also: warum nicht z,bsp. etwa wie bei linux/asterisk in /etc/smart/items/xxx.conf ?

und die zweite kleinigkeit, die mir als irritation bei den mir sonst gewohnten handlings aufgefallen ist, ist auch irgendwie die doppelte verwendung von attributen. in den items.conf kommt (in den beispielen zumindest) ein name= .. vor, in den widgets ebenfalls erneut. reicht das nicht an einer stelle, bzw der name ergibt sich doch dann? sicherlich ist das optional, aber irgendwie auf den ersten blick nicht so stringent, was minimal obligatorisch ist, und was anderen zwecken, wie z.bps. der orientierung dient

[NACHTRAG: die attribute visu=yes/true und sv_xx kamen mir spanisch vor, in der items.conf. jetzt habe ich gesehen, dass diese erst mit aktivierung einer visu option in der plugin.conf gültige optionen in der items.conf werden. bzw. der autogeneration dienen. auch irgendwie inkonsistent/verschachtelt. darauf kommt man in einer erstkonfiguration wohl nur ganz schwer...]

- schön wären vermutlich auch kommentarzeilen in der items.conf. geht das?

Widgets:
die händische verwaltung von unique-ids scheint mir langfrist fehlerträchtig, das das nachhalten und tippfehler/copy-and-paste-fehler auch schon in ets/homeserver-projekten oft ärgerlich und zeitintensiv sind.

die unterscheidung in der doku, zwischen basic und device ist auch irgendwie nicht gleich schlüssig. das da keine oppositionspaare sind erschliesst sich der erwartete inhalt eher überraschend als logisch. bei licht sind schalter/aktoren klare basics, aber auch dimmer. hier sind das "devices" . etwas geöhnungsbedürftig. sicher hat man sich dabei was gedacht, aber unter devices hätte ich zumindest was ganz anderes gesucht..

also, bitte alles nur als _konstruktive_ anmerkung verstehen, oder ignorieren. alles nur in bester absicht hier, keinerlei kritik (um solchen reaktion schon mal vorzubeugen).

wie so oft: sehr gute arbeit, ich bin immer noch begeistert.

mit dank und gruss,ozett

[2ndsky]

items-kategorien / feedback

Was du immer bedenken musst, dass die smartVISU auch mit anderen Backends als sh.py funktioniert. Beides sind an und für sich erstmal eigenständige Systeme. Dadurch ist so mancher "Kritikpunkt" von dir einfach nicht anders umsetzbar, außer man verwendet den Autogenerator von sh.py (doppelte Namen, ID pflege der Widgets usw.).

[ozett]

ok. danke für die reaktion.

ich dachte mir das schon. leider ist es in meinem beispiel ja auch so, dass ich versucht habe die smartVISU alleine zu betreiben. bzw. dann mit dem eibd-backend. das ging schon nicht so einfach, führte aber auch dazu, dass dafür die KNX-GAs und DPTs direkt in die pages zu schreiben wären, und nicht wie in den anderen backend-Fällen in eine für smartVISU und/oder (?) smarthome standardisierte items.conf.

Und selbst dann wäre es dort eben nach meinen Versuchen wohl nicht so einfach stringent. allein der pfad scheint beim einsatz nur von smartVISU ein anderer als in der kombination mit smarthome. und liegt nicht gleich in diesem gewohnten linux/etc.
alles nicht so schlimm, aber eben wieder hier und da und dort ein wenig anders...

und bleibe ich noch eben bei dem beispiel items.conf, so gibts da auch optionen, die aus plugins stammen. oder bei meinem knx-beispielen scheint sich die angabe zur knx-dpt und type etwas zu doppeln.

ich hab' schon ne ahnung, dass die programmierkomplexität steigt, aber ich dachte eben, man sucht ja meist einen weg zu robusten, einfachen und verstehbaren systemen - und da würde dann so ein feedback vielleicht helfen. oder ggfs beim nächsten problem villeicht über den hinterkopf hilfreich sein.

in diesem sinne, dachte ich,
grüsse,ozett

ps: versuche mich dann jetzt mal mit den 'shuttern', sehe aber auch da für die knx übernahme ein paar kleinigkeiten ...

[callidomus]

wo das systematisch für das entwicklertem eingespeist werden soll, dann würde ich das dort machen. vielleicht ist ja hier auch der richtige ort. also:

Wir sind da flexibel, passt schon.

-die trennung und pfade für die items(x).conf(en) ist etwas inkonsistent.

ich kann bislang auch nicht sofort erkennen, wo die datei hin müsste, wenn man nur die smartVISU _ohne_ smarthome.py betreiben würde. auch ist man zunächst unter linux eher an /etc/smart../x.conf gewöhnt. würde ich sagen.

Was meinst Du mitt Trennung und Pfade inkonsistent? Du trennst die Items in Dateien auf.
Wenn Du die smartVISU ohne SmartHome.py betreiben möchtest hast Du überhaupt keine Item Dateien.

- also: warum nicht z,bsp. etwa wie bei linux/asterisk in /etc/smart/items/xxx.conf ?

Weil dort sich in der Regel nur root tummelt. Ich sehe es eher als User-Programm an. Auserdem wollte ich nicht die Dateien im Filesystem verteilen.
Bei dem Pi-Image ist alles unter /usr/smarthome was SH.py angeht.

und die zweite kleinigkeit, die mir als irritation bei den mir sonst gewohnten handlings aufgefallen ist, ist auch irgendwie die doppelte verwendung von attributen. in den items.conf kommt (in den beispielen zumindest) ein name= .. vor, in den widgets ebenfalls erneut. reicht das nicht an einer stelle, bzw der name ergibt sich doch dann? sicherlich ist das optional, aber irgendwie auf den ersten blick nicht so stringent, was minimal obligatorisch ist, und was anderen zwecken, wie z.bps. der orientierung dient

Deswegen kannst Du ja im Widget item.name verwenden und nicht noch einmal den Name ausschreiben.

[NACHTRAG: die attribute visu=yes/true und sv_xx kamen mir spanisch vor, in der items.conf. jetzt habe ich gesehen, dass diese erst mit aktivierung einer visu option in der plugin.conf gültige optionen in der items.conf werden. bzw. der autogeneration dienen. auch irgendwie inkonsistent/verschachtelt. darauf kommt man in einer erstkonfiguration wohl nur ganz schwer...]

Hast Du die Docu gelesen? SmartHome.py - Visu Plugin

- schön wären vermutlich auch kommentarzeilen in der items.conf. geht das?

Du kannst in den conf files und den logiken Kommentar mit # markieren. Siehe auch in den diversen Beispielen.

Widgets:
die händische verwaltung von unique-ids scheint mir langfrist fehlerträchtig, das das nachhalten und tippfehler/copy-and-paste-fehler auch schon in ets/homeserver-projekten oft ärgerlich und zeitintensiv sind.

Da stimme ich Dir zu. @Martin wieso muss das ein User angeben? Kannst Du das nicht automatisch zuweisen?

ich dachte mir das schon. leider ist es in meinem beispiel ja auch so, dass ich versucht habe die smartVISU alleine zu betreiben. bzw. dann mit dem eibd-backend. das ging schon nicht so einfach, führte aber auch dazu, dass dafür die KNX-GAs und DPTs direkt in die pages zu schreiben wären, und nicht wie in den anderen backend-Fällen in eine für smartVISU und/oder (?) smarthome standardisierte items.conf.

Die smartVISU kommunziert nur über eine definierte Schnittstelle mit dem Backend. Die items.conf wird nur von SH.py verwendet.

Und selbst dann wäre es dort eben nach meinen Versuchen wohl nicht so einfach stringent. allein der pfad scheint beim einsatz nur von smartVISU ein anderer als in der kombination mit smarthome. und liegt nicht gleich in diesem gewohnten linux/etc.
alles nicht so schlimm, aber eben wieder hier und da und dort ein wenig anders...

Das verstehe ich nicht.

und bleibe ich noch eben bei dem beispiel items.conf, so gibts da auch optionen, die aus plugins stammen. oder bei meinem knx-beispielen scheint sich die angabe zur knx-dpt und type etwas zu doppeln.

Ich kann zwar keine Beispiel oben entdecken, aber es gibt auch Items die nicht mit KNX verknüpft werden.

ich hab' schon ne ahnung, dass die programmierkomplexität steigt, aber ich dachte eben, man sucht ja meist einen weg zu robusten, einfachen und verstehbaren systemen - und da würde dann so ein feedback vielleicht helfen. oder ggfs beim nächsten problem villeicht über den hinterkopf hilfreich sein.

Das versuchen wir auch, aber momentan ist es nichts die sich nicht mit Linux anfreunden können.

Wo ist eigentlich der Featurewunsch Items-Kategorien? Den konnte ich nirgends entdecken.

Bis bald

Marcus

[Apollo]

Widgets:
die händische verwaltung von unique-ids scheint mir langfrist fehlerträchtig, das das nachhalten und tippfehler/copy-and-paste-fehler auch schon in ets/homeserver-projekten oft ärgerlich und zeitintensiv sind.

Das stimmt vielleicht. Für optische Änderungen (im css) ist es mir jedoch lieber, wenn ich das Widget "genau" kenne. Vielleicht kann man die uis zukünftig optional machen... Mal gucken...

die unterscheidung in der doku, zwischen basic und device ist auch irgendwie nicht gleich schlüssig. das da keine oppositionspaare sind erschliesst sich der erwartete inhalt eher überraschend als logisch.

Sollen ja keine "Oppositionspaare" sein, vielmehr sind es Kategorien, in den die Widgets eingeteilt sind.
Basic: Einfache Widgets, mit genau einer Funktion.
Device: Widgets, die an Funktionalitäten (Herstellerunabhängig) angelehnt sind. (z. B. rtr)

Die Idee dahinter war ggv. vielleicht mal eine "Hersteller" Kategorie zu machen (die auf den allgemeinen device. aufsetzt)
abb.rtr
mkt.rtr

Gruss