[erledigt] Artikelstruktur fronthem/smartVISU

[joshi04]

Hallo Zusammen,

ich probiere mich gerade ein wenig in Fronthem/smartVISU einzuarbeiten und würde in diesem Zusammenhang auch eine leichte Überarbeitung der zugehörigen Artikel vornehmen wollen. Derzeit ist es inhaltlich mM noch etwas unstrukturiert auf die Artikel verteilt. So bin ich der Meinung, könnte es einen Artikel geben für fronthem, dessen Inhalt vom Artikel für smartVISU aber relativ strikt getrennt wäre. Die Artikel wären jeweils die Einstiegsartikel mit entsprechenden Querverweisen.
Darüber hinaus
Variante 1 gibt es jeweils einen zusätzlichen Artikel für die Installation oder
Variante 2 wird die Installation jeweils in die Artikel integriert.

Im Folgenden die Struktur für Variante 1:
Fronthem (Einstiegsseite von Fronthem aus)
   Bausteine
   Integration in FHEM (Basic Syntax)
   Converter
   Device Connector

Installation Fronthem
   Allgemein
   Installation Fronthem
   Integration in FHEM
   
Installation smartVISU (neuer Artikel)
   Allgemein
   Installation smartVISU (von Artikel "Installation Fronthem")
   Eigenes smartVISU Projekt anlegen (von Artikel "Installation Fronthem")
   Konfiguration des Treibers (Clientseite)

Smartvisu (Einstiegsseite von smartVISU aus)
   Codebeispiele
      Universelle ZeitschaltUhr UZSU (von Artikel "Fronthem"), ggf. eigener Artikel smartVISU/Universelle ZeitschaltUhr UZSU
   Widgets

Ggf. könnte man auch darüber nachdenken, den Fronthem- und smartVISU-Artikel ganz zusammenzufassen. Aber auch wenn ich derzeit von keinem anderen Frontend weiß, dass fronthem verwendet, war es mM das ursprüngliche Ziel von Jörg, mit fronthem eine Schnittstelle allgemein für Frontends zu schaffen. Dass es derzeit vielleicht nur smartVISU ist, sollte kein Grund sein, dieses zukünftig zu erschweren oder gar auszuschließen nur durch die Zusammenfassung der Wikiartikel.

Neue Erkenntnisse würde ich natürlich ebenfalls nach und nach einfließen lassen.

Was haltet Ihr davon? Welche Variante gefällt Euch besser? Oder vielleicht sollte alles so bleiben, wie es ist?

Mein persönlicher Favorit wäre allerdings Variante 2, da man weniger durch die Artikelstruktur verwirrt wird und die Anzahl an Artikeln, die man lesen muss, um die Zusammenhänge zu verstehen, geringer ist.

Schöne Grüße,
John

[ph1959de]

Hallo John,

Mal für mich als weitere Verständnishilfe, derzeitiger "Seitenbestand":

• Fronthem - Modulseite, inoffizielles Modul
• Fronthem
• SmartVisu - Kurzinfo über SmartVisu
• ical
• fritz!box via TR-064
• ical
• weitere widgets(?):IconHighlights in Menus, lichtSzene, ...?

- fehlt da noch was?

Eine Überarbeitung des Themenbereichs kann sicherlich vieles verständlicher machen. Habe leider nicht ganz verstanden, wie Variante 2 bei Dir im Detail aussehen würde. Was ich aber auf jeden Fall begrüßen würde, wäre ein Diagramm auf der Fronthem Seite, aus dem die Zusammenhänge deutlich werden. Außerdem (sofern es sowas gibt) ein Vergleich zwischen der Darstellung (eines Objekts) mit Standard (FHEMWEB) und fronthem? Gibt es Vorteile aus Endbenutzersicht oder ist das "nur für Entwickler"?

Die Installationsseite sollte meiner Meinung nach auf jeden Fall eine eigene Seite bleiben (allein schon vom Umfang her).

Für weitere Empfehlungen fehlt mir (bisher) selbst der Überblick über diesen Themenkomplex.

Peter

[joshi04]

Hallo Peter,

sorry, ich probieren ein wenig Licht zu schaffen:
mM besteht das Ganze grundsätzlich aus 2 Teilen:

• Das derzeit inoffizielle Modul fronthem und seine Zusätze (converter, etc.) stellen eine allgemeine Schnittstelle für alternative Frontends zur Verfügung. Dieses ist derzeit größtenteils im fronthem-Artikel beschrieben. Dieses findet alles innerhalb der Konfiguration von FHEM statt.
• smartVISU ist das alternative Frontend, kommt eigentlich aus dem KNX-Bereich und koppelt sich über fronthem an FHEM an. Die Konfiguration hier bezieht sich auf die html-Seiten, die man später aufruft.

Für beide Teile sind mehr oder minder umfangreiche Installationen notwendig, die derzeit aber zusammen im Artikel "fronthem Installation" beschrieben sind. Hier stimmt mM der Titel des Artikels nicht mit dem Inhalt überein, was auch mich Anfangs ziemlich verwirrt hat.

Hat man beide Teile erst einmal installiert und die grundsätzliche Konfiguration hinbekommen (Kommunikation untereinander), folgt die individuelle Konfiguration, die derzeit leider noch sehr spärlich im smartVISU Artikel beschrieben ist. Von dort würde ich, wie schon mit den wenigen Seite geschehen, jeweils die gesamte Konfiguration für ein widget beschreiben, d.h. in smartVISU und in FHEM, da das ja zusammengehört.

In Variante 2 würde ich die Installation der beiden Teile jeweils in die Hauptartikel für fronthem und smartVISU mit aufnehmen. Es gäbe dann keine Artikel für die Installation. Wie ich Deinem Kommentar aber entnehmen kann, sollten wir die Installationsanteile eher in separaten Artikeln belassen bzw. auslagern.

Für ein Diagramm bin ich wissenstechnisch glaube ich noch nicht so weit. Ich behalte es aber im Hinterkopf, was auch für Screenshots und einen Vergleich gilt.

Was die Vorteile angeht, so ist das Ganze wohl am ehesten etwas um den WAF zu erhöhen, auch wenn man zum Einrichten eher Entwickler sein sollte, zumindest derzeit. Aber das versuche ich ja gerade ein wenig zu ändern.

Schöne Grüße,
John

[joshi04]

Eine Übersicht (Diagramm) zur Diskussion habe ich hier mal eingestellt:
https://forum.fhem.de/index.php/topic,53881.msg460993.html#msg460993

[joshi04]

Der überarbeitet Artikel für fronthem ist jetzt online. Bitte gerne kommentieren oder direkt korrigieren. Als nächstes nehme ich mir den Artikel "fronthem Installation" einmal vor.

Haltet Ihr es ggf. für sinnvoll eine eigene Kategorie für die Artikelserie in Zusammenhang mit fronthem und/oder smartVISU anzulegen? Oder ist das ausreichend über "FHEM Frontends" definiert?

Außerdem habe ich festgestellt, dass die Schreibweise von "smartVISU" in den bisherigen Artikeln uneinheitlich ist bzw. SmartVisu. Hier bräuchte ich vermutlich nochmal administrative Unterstützung oder einen Vorschlag, wie ich vorgehen soll. In den neuen/überarbeiteten Artikeln würde ich die Schreibweise "smartVISU" verwenden. Den Seitentitel kann ich natürlich nicht ändern.

Schöne Grüße,
John

[krikan]

Haltet Ihr es ggf. für sinnvoll eine eigene Kategorie für die Artikelserie in Zusammenhang mit fronthem und/oder smartVISU anzulegen? Oder ist das ausreichend über "FHEM Frontends" definiert?

Hallo John!

Die Unterkategorie hatten wir hier http://www.fhemwiki.de/wiki/Kategorie_Diskussion:FHEM_Frontends eigentlich "beschlossen". Ich habe es nur noch nicht umgesetzt. Das kannst Du sehr gerne machen.

Die Schreibweise von SmartVisu würde ich auf jeden Fall vereinheitlichen. Ich bin mir aber nicht sicher welche richtig ist. Nehme aber das Unterforun hier als Indiz.

Gruß, Christian

[joshi04]

Hallo Christian,

Kategorien: Mist, das habe ich übersehen. Sorry.

Für die Schreibweise habe ich mich an der Quelle (www.smartVISU.de) orientiert. Das heißt natürlich, dass das Unterforum hier dem derzeit auch nicht entspricht. Bezüglich Einheitlichkeit bin ich definitiv ganz bei Dir.
Bei einer Entscheidung bin ich zwar offen, befürchte allerdings, da die Quelle es so handhabt, wird uns das immer wieder einholen. Bei den panStamps haben wir das ähnlich gehandhabt. Daher wäre mein Vorschlag eher es auf "smartVISU" anzupassen.

Eine Kategorie würde ich dann einrichten, wenn sich eine Meinung herausgebildet hat.

Ich füge oben mal eine Umfrage ein, mit der Bitte um Meinungsabgabe...

Schöne Grüße,
John

[krikan]

Hallo John!
Wenn smartVISU der offizielle Name ist, sollten wir ihn nutzen. Würde mich dann um Forumsanpassung bemühen.
Wer die Arbeit macht, darf aber grds. entscheiden. Demokratie ist da mMn nicht notwendig  .
Gruß, Christian

[joshi04]

Hallo Christian,
*GGG*, ok, dann ist die Schreibweise "smartVISU" ja schon beschlossen. 

Ich kümmere mich gerne um die Änderung auf den Seiten (nach und nach).
Kategorien schauen ich mir auch an, sieht aber einfach aus und kümmere mich ebenfalls drum. Es wird danngibt eine neue für "fronthem/smartVISU".

Allerdings bräuchte ich bei den Artikel-Titeln wie erwähnt leider Hilfe.
Betroffen davon wären die folgenden Seiten:
SmartVisu -> smartVISU
SmartVisu/lichtSzene  -> smartVISU/lichtSzene
SmartVisu/IconHighlights in Menus -> smartVISU/IconHighlights in Menus
SmartVisu/fritz!box via TR-064 -> smartVISU/fritz!box via TR-064
SmartVisu/ical -> smartVISU/ical

Leider doch nochmal Arbeit für jmd mit ausreichend Rechten.
Schöne Grüße,
John

Edith: Habe herausgefunden, dass ich doch Artikel verschieben darf (oder habe ich das Recht kürzlich hinzubekommen??). Ich werde entsprechend alles soweit vorbereiten. Leider darf ich das Erzeugen der Weiterleitung nicht unterbinden, so dass ich die Weiterleitungsseite als Löschkandidaten markieren werde. Das bezieht sich dann natürlich nur auf die Weiterleitung und nicht als den verschobenen Artikel, nur zur Sicherheit.

Auch habe ich den Artikel "Installation fronthem" zu "fronthem Installation" verschoben, da er sich dann deutlich besser in die Kategorie-Seite einfügt.

[joshi04]

Hallo Zusammen,

die überarbeiteten Artikel sind online, neue Kategorie ist eingerichtet, Artikel sind umbenannt.

Ob die Umleitungen erhalten bleiben sollen oder gelöscht werden, dazu gibt es hier eine Diskussion: http://www.fhemwiki.de/wiki/Diskussion:Installation_Fronthem
Vor dem Ausführen einer Löschung, sollte man auf alle Fälle dort hineinschauen. Ich werde die Diskussion dort weiterführen.

OT:
Mir ist jetzt auch klar, warum bei der panStamp-Geschichte Peter versehentlich die Artikel direkt gelöscht hat. Obwohl ich nur den Umleitungs-Artikel als Löschkandidaten markiert habe, landet man, wenn man in der Kategorie "Löschkandidaten" den Links folgt auf den Umleitungszielen.
Besteht hier ggf. die Möglichkeit die Vorlage für die Löschkandidaten anzupassen (noredirect)? Das ist für meine Fähigkeiten allerdings definitiv zu hoch.

Schöne Grüße,
John

Edith: Anpassung zwecks Vermeidung von Missverständnissen.

[dev0]

die überarbeiteten Artikel sind online

In dem Artikel wird für zusätzliche Widgets auf https://github.com/herrmannj/smartvisu-widgets verwiesen. Neben diesem Archiv gibt es noch https://github.com/ddtlabs/smartvisu-widgets. Die Repositories sind (noch) nicht zusammengelegt, da diese Widgets größtenteils schon auf SV v2.8+ umgestellt sind und nicht ohne weiteres mit v2.7 funktionieren. Wie man das smartvisu-cleaninstall auf v2.8 aktualisiert, habe ich hier beschrieben: https://github.com/ddtlabs/build-smartvisu-cleaninstall

Wäre nett, wenn Du das in dem Artikel ergänzen könntest.

/Uli

[joshi04]

Hallo Uli,

vielen Dank für den Hinweis. Für die Installation von 2.8 hatte ich tatsächlich bereits hier auf Deinen Github verlinkt:
http://www.fhemwiki.de/wiki/SmartVISU_Installation#nicht_offiziell_ver.C3.B6ffentlichte_Version_2.8
Das beantwortet allerdings noch nicht Deine Frage.

Nachdem ich zwar für die Installation schon einen guten Überblick gewonnen habe, fehlt mir dieser derzeit noch ziemlich komplett bei smartVISU selbst.
Was ich derzeit noch nicht weiß, bist Du der Meinung, im Wiki sollte man generell die Version 2.8 empfehlen und beschreiben? Laufen die Widget zwar nicht alle mit 2.7, dafür aber mit 2.8? Ich war da zunächst erst einmal vorsichtig, da ich die Kompatibilität nicht kenne.
Ich habe leider noch keine gute Beschreibung gefunden, was sich tatsächlich geändert hat, hätte das gerne beschrieben.

Der Link auf herrmannj's Github ist historisch und stammt noch aus dem Vorartikel. Weitere Quellen gibt es noch von bgewehr und HCS (glaube ich). Soweit bin ich allerdings noch nicht. Eigentlich sehe ich das Wiki als zentrale Quelle von Wissen und würde den Bereich, wie welches Widget in smartVISU eingebunden wird gerne noch deutlich ausbauen.

Auf Deinem Github habe ich gesehen, dass die Widgets bereits perfekt beschrieben sind und daher wäre mir vor allen Dingen Deine Meinung wichtig. Ich sehe für die Beschreibung im Wiki mehrere Möglichkeiten:

• Nur ein Titel mit Kurzbeschreibung des Widgets und Link direkt ins entsprechende Github; Dieses würde dazu führen, dass man bzgl. der Beschreibung immer an unterschiedlichen Orten landet.
• Beschreibung im Wiki und Link ins Github als Quelle für den Code und Quellenangabe; Dieses hat den Nachteil, dass die Beschreibung doppelt im GitHub und im Wiki steht. Da jedoch dann alles zusammen als gemeinsame Dokumentation im Wiki stünde und man nur zum Download einmalig im GitHub landet, wäre dieses derzeit mein Favorit.
• Beschreibung und Code im Wiki + Link als Quellenangabe; Dieses macht mM eigentlich nur dann Sinn, wenn die Quelle z.B. nur in ein Beitrag im Forum veröffentlicht wurde. Für die Widgets in einem GitHub würde ich die Dateien dort belassen, wo sie sind. Etwas entsprechendes habe ich hier eigentlich vor für das Temp-Sensor-Widget https://forum.fhem.de/index.php/topic,55228.msg468935.html#msg468935. Ich habe die Bestätigung der Autoren allerdings noch nicht eingeholt.

Wie denkst Du darüber?

Ich passe das Wiki gerne entsprechend an. Das lebt ja eh.

Schöne Grüße,
John

[dev0]

bist Du der Meinung, im Wiki sollte man generell die Version 2.8 empfehlen und beschreiben?

kurz: ja.
lang: SV 2.8 läuft genauso stabil wie 2.7. Der wesentliche Unterschied zur 2.7 ist, dass svg statt png Icons verwendet werden. Wenn man jetzt noch die 2.7er einrichtet, dann muss man beim Update alle Icons, die man eingebunden hat, anpassen oder die Icon Library zusätzlich installieren https://github.com/Martin-Gleiss/smartvisu.lib. Habe ich aber nie getestet, da svgs die bessere Wahl sind. SV 2.8 verwendet folgende Syntax für Icons:

Code Auswählen Erweitern


normal:
<img class="icon" src="{{ icon0 }}light_light.png" />
<img class="icon" src="{{ icon0 }}light_light.svg" />
highlighted:
<img class="icon" src="{{ icon1 }}light_light.png" />
<img class="icon icon1" src="{{ icon0 }}light_light.svg" />

Siehe auch: https://knx-user-forum.de/forum/supportforen/smartvisu/31400-umstellung-der-icons-auf-svgs

Weitere Unterschiede zur 2.8 sind zusätzliche Widgets: https://github.com/Martin-Gleiss/smartvisu/blob/master/history.txt und ich glaube der eine oder andere Bugfix.
Da Cybers SV Fork und auch herrmannj's [Edit: geplantes next release von] cleaninstall auf SV 2.8 basieren, würde ich, bei einer Neuinstallation direkt die 2.8 installieren.

Da wir nicht wissen, wann entweder herrmannj oder Cybers mit 2.8er Versionen um die Ecke kommen, könnte man solange auch meinen 2.8er Fork nutzen, darin sind die cleaninstall Erweiterungen/Treiber und die aktuelle Highcharts Version enthalten.
Das könnte aber auch mehr Chaos verursachen als helfen, wenn dann irgendwann einer der beiden eine 2.8er Version verfügbar macht. Daher habe ich das bisher vermieden diese Version anzubieten, zumal ich sie noch nicht getestet sondern nur erstellt habe. Wenn Du meinen Fork erwähnen möchtest, dann bitte in jedem Fall vorher testen.

Ich sehe für die Beschreibung im Wiki mehrere Möglichkeiten:

Ich würde im Wiki nur auf die einzelnen Widgets verlinken und kurz schreiben was sie machen, mehr nicht. Zusätzlich könnte man erklären wie man Widgets installiert, die (noch) keine Beschreibung haben: Einbinden der Dateien und wie man sie Aufrufen muss. Der Aufruf geht aus der Macrozeile und dem Kommentar darüber hervor. Das könnte man anhand von 1-2 Beispielen versuchen dem Anwender näher zu bringen. SV ist wie FHEM ein Framework, dass seine Stärken erst entwickelt, wenn man weiß, wie man damit umzugehen hat und nicht Codebeispiele 1:1 übernimmt und nicht versteht.
Wenn Du Installationsbeschreibungen hinzufügen möchtest dann auf Github und nicht im Wiki: einfach das Widget forken, ergänzen und einen pull request stellen.
Das Schlimmste wäre Code von bestehenden Widgets im Wiki. Bitte nicht! Github ist keine Dateiablage sondern eine Versionsverwaltung, so wie das FHEM svn. Überspitzt gesagt könnte man sonst auch alle FHEM Module ins Wiki stellen und svn abschalten

Just my 2 cents.

[joshi04]

Hallo Uli,

jeder Cent ist wichtig, daher hatte ich ja gerade gefragt.

lang: ...

Klasse, genau das hatte ich bislang nicht gefunden. Ich überlege mal, dazu etwas im Wiki mit aufzunehmen.

Da Cybers SV Fork und auch herrmannj's cleaninstall auf SV 2.8 basieren, würde ich, bei einer Neuinstallation direkt die 2.8 installieren.

Mist, ich dachte bislang, herrmanj's cleaninstall wäre 2.7, aber Du hast Recht, hab gerade nochmal nachgeschaut, zumindest in der ini steht 2.8.

Da wir nicht wissen, wann entweder herrmannj oder Cybers mit 2.8er Versionen um die Ecke kommen, könnte man solange auch meinen 2.8er Fork nutzen, darin sind die cleaninstall Erweiterungen/Treiber und die aktuelle Highcharts Version enthalten.

Ich muss gestehen, hier bin ich nicht ganz mitgekommen. Nur zum Verständnis, heißt das, es sind die "highcharts", die bei herrmanj's cleaninstall noch nicht drin sind?

Das könnte aber auch mehr Chaos verursachen als helfen, wenn dann irgendwann einer der beiden eine 2.8er Version verfügbar macht.

Dann werde ich im Weiterenticklungs-Thread die Frage besser noch einmal stellen, welche Version zurzeit am ehesten im Wiki zur Installation empfohlen werden sollte. Dazu mache ich mir nochmal Gedanken. Gebe Dir recht, das könnte Chaos geben.

Daher habe ich das bisher vermieden diese Version anzubieten, zumal ich sie noch nicht getestet sondern nur erstellt habe. Wenn Du meinen Fork erwähnen möchtest, dann bitte in jedem Fall vorher testen.

So hatte ich das bislang ebenfalls interpretiert. Daher ist im Wiki die Installation noch Deinem Fork derzeit nur inoffiziell und auf eigene Gefahr. Im Übrigen läuft es bei mir derzeit genau so. Allerdings bin ich noch nicht sehr weit, was daher noch bei weitem keine nachhaltige Schlussfolgerung zulässt.

Ich würde im Wiki nur auf die einzelnen Widgets verlinken und kurz schreiben was sie machen, mehr nicht.
Zusätzlich könnte man erklären wie man Widgets installiert, die (noch) keine Beschreibung haben: Einbinden der Dateien und wie man sie Aufrufen muss. Der Aufruf geht aus der Macrozeile und dem Kommentar darüber hervor. Das könnte man anhand von 1-2 Beispielen versuchen dem Anwender näher zu bringen. SV ist wie FHEM ein Framework, dass seine Stärken erst entwickelt, wenn man weiß, wie man damit umzugehen hat und nicht Codebeispiele 1:1 übernimmt und nicht versteht.

Bzgl. Dokumentation mache ich mir für Deine Widgets definitiv keine Sorgen. Bei der Doku, sollte das jeder hinbekommen.
Ich entnehme aber daraus, dass ich das PDU und das Sonos Widget von Dir verlinken darf?

In anderen Fällen gibt es machmal nur das Widget, hier würde ich die Verwendung auf einer Seite (ich glaube, das ist das, was Du mit "installieren" beschreibst) detaillierter beschreiben wollen.
Für die Frage, wie Widgets eingebunden werden können (import), habe ich im Forum mehrere Möglichkeiten gefunden und mir vorgenommen, das allgemeingültig zu beschreiben, sobald ich das durchdrungen habe.

Beim Verstehen bin ich ganz bei Dir und denke, wir sind garnicht so weit auseinander. Ein konkretes Beispiel finde ich immer dann wichtig und hilfreich, wenn das Wissen des Anwenders noch nicht ausreicht, anhand der Beschreibung eine funktionstüchtige Lösung direkt hinzubekommen. Das Beispiel ist aber immer nur zusätzlich, allerdings auch dazu da, dem Anwender ein gewisses Erfolgserlebnis zu verschaffen, überhaupt etwas zum Laufen zu bekommen. Läuft es dann erstmal, kann er sich daran entlanghangeln und sich daran für seine Anwendung orientieren. Von blindem Copy/Paste, ohne Sinn und Verstand halte ich ebenfalls nichts. Aber ich denke nicht, dass man mit solch einer Haltung für die Einrichtung von SV überhaupt sehr weit kommt.

Wenn Du Installationsbeschreibungen hinzufügen möchtest dann auf Github und nicht im Wiki: einfach das Widget forken, ergänzen und einen pull request stellen.

Ich glaub, da muss ich mich mit dem Wording und mit Github mal auseinandersetzen  ...

Das Schlimmste wäre Code von bestehenden Widgets im Wiki. Bitte nicht! Github ist keine Dateiablage sondern eine Versionsverwaltung, so wie das FHEM svn. Überspitzt gesagt könnte man sonst auch alle FHEM Module ins Wiki stellen und svn abschalten

Danke für das plastische Beispiel.  Vielleicht habe ich den Anwendungsfall nicht deutlich genug beschrieben. Siehst Du das ebenso bei Code, der derzeit nur in einem Forums-Beitrag zu finden ist? Sollte der Code aus dem Forum irgendwann einmal in einem Github landen, bin ich ganz bei Dir, sollte er nicht mehr im Wiki stehen.

Danke für Deine Meinung und schöne Grüße,
John

[dev0]

Das aktuelle cleaninstall basiert auf 2.7. Das next Release soll auf 2.8 basieren. Das ist mir vorhin auch aufgefallen und hatte es korrigiert während du deinen Beitrag geschrieben hast. Die 2.8 in der ini Datei ist schlicht gelogen
Morgen schreib ich zum Rest weiter...