[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...

[joshi04]

  jupp, in ini's kann viel stehen ... Jetzt passt es auch wieder mit dem hier zusammen: https://forum.fhem.de/index.php/topic,52358.msg441062.html#msg441062.
Da hatte ich nämlich Deine Anleitung her. Hätte ich besser verlinken sollen   

Dann ist die derzeitige Beschreibung im Wiki ja doch nicht soo verkehrt, auch wenn er hier und da noch ein bisschen "holpert".

Lass Dir Zeit, wollte hier erstmal Konsens finden, bevor zumindest ich das Wiki diesbezüglich wieder anfasse.

Edith: Hab mal ein unfertiges Beispiel angehängt, wie ich Beschreibung und in dieser Ausnahme Code beschrieben sein könnten. Wohlgemerkt als Diskussionsgrundlage.

[dev0]

heißt das, es sind die "highcharts", die bei herrmanj's cleaninstall noch nicht drin sind?

Drin schon, aber eine ältere Version.

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.

Im ersten Mega Fronthem Thread gab es bereits eine Diskussion, wie man Widgets am Besten einbindet. Konsens war, dass wir includen wollen. Darauf hin wurden die Widgets im herrmannj Repo auch entsprechend umbenannt. So kann man sie einfach downloaden und in den pages Ordner kippen. Man muss sie dann nur einmal includen. Bei einem Update einfach die vorhandenen Dateien überschreiben.

Ich entnehme aber daraus, dass ich das PDU und das Sonos Widget von Dir verlinken darf?

Alle anderen Widget auch. Zum Verlinken und Beschreiben benötigst Du keine Zustimmung. Wenn Du Code (ins Wiki) _kopierst_ sieht es anderes aus, dann ist die Lizenz zu beachten. Sollte aber in den meisten Fällen eine GPL sein, ist nichts angegeben, dann würde ich die GPL zugrunde legen, da SV lebst unter GPL steht.

Siehst Du das ebenso bei Code, der derzeit nur in einem Forums-Beitrag zu finden ist?

In dem Fall wäre es das Eleganteste, wenn der Entwickler den Code in das smartvisu-widgets Repo einchecken würde und ggf. vorher in die passende Forum bringen würde (drei Dateien ala widget_name_.ext). Wenn der Schreiberling keinen Bock drauf hat, dann kann man das auch selbst machen und im Thread bekanntgeben. Wenn ich es richtig verstanden habe, dann steht Code im Forum generell unter einer CC Lizenz, die das auch rechtlich hergibt (Quelle angeben). Ist natürlich auch der aufwendigste Weg...
Du merkst schon, ich habe etwas gegen kopierten Code im Wiki. Das Problem dabei ist, dass Du Änderungen am Code nicht unbedingt mitbekommst und nachtragen kannst. Wen DU dich irgendwann einmal nicht mehr intensiv drum kümmerst, dann ist das Wiki schneller überholt als man gucken kann und verursacht durch die unterschiedlichen Versionen ggf. noch erhöten Supportaufwand.

Hab mal ein unfertiges Beispiel angehängt, wie ich Beschreibung und in dieser Ausnahme Code beschrieben sein könnten.

Code Auswählen Erweitern

{% import  "widgets\\widget_temp_sensor.html" as TempSensor %}
Das \\ ist mir unklar.

Code Auswählen Erweitern

Der folgende Code muss als widget_temp_sensor.html gespeichert werden.

In welchen Ordner?

Code Auswählen Erweitern

Das Widget wird mit folgendem Aufruf innerhalb einer Seite in smartVISU eingebunden:
{{ TempSensor.Data(<id>, <txt>, <gad>, <icon>, <flags>) }}

Ist dem Leser an dieser Stelle schon bekannt, dass diese Aufrufe noch in einen Block o.ä. verpackt werden sollten/müssen?

Code Auswählen Erweitern

gad: GAD-Prefix, das im GAD-Editor verknüpft werden muss

Prefix bitte weglassen.
Was ist überhaupt ein GAD oder Item?

Toll, dass Du Dich um das Thema kümmerst. Respekt!

[joshi04]

Er nahm die aufmunternden Worte und verschwand auf nimmer wiedersehen...
War ein paar Tage beschäftig und nehme nun wieder Anlauf.

Im ersten Mega Fronthem Thread gab es bereits eine Diskussion, wie man Widgets am Besten einbindet. Konsens war, dass wir includen wollen.

Durch den habe ich zwar auch durchgekämpft, aber mit einem anderen Fokus. So ist mir gerade das wohl entgangen. Dem Konsens will ich natürlich unter keinen Umständen widersprechen. Gehe davon aus, dass herrmannj's github derjenige zum includen sein wird, das frage ich gleich aber noch im anderen Fred.

Wenn Du Code (ins Wiki) _kopierst_ sieht es anderes aus, dann ist die Lizenz zu beachten.

Das habe ich bereits mit krikan diskutiert. Genehmigung liegt aber bereits auch vor, obwohl das wohl nicht mehr so (im Wiki) zum Tragen kommt.

Du merkst schon, ich habe etwas gegen kopierten Code im Wiki.

Ich teile mittlerweile Deine Meinung, habe vorher aber keine bessere Möglichkeit gesehen.

Deine Anregungen nehme ich gerne auf:
\\ -> stammt auf dem ursprünglichen Post. Gerade noch einmal getestet, mit nur einem findet er das widget im Unterverzeichnis nicht. Ist der "import" hier eigentlich ein smartVISU-Befehl?

In welchen Ordner? -> Das sollte bereits in einem anderen Artikel/Abschnitt beschrieben worden sein. Vielleicht muss ich mir das zuerst anschauen. Sonst kann man da nicht drauf aufbauen.

Ist dem Leser an dieser Stelle schon bekannt, dass diese Aufrufe noch in einen Block o.ä. verpackt werden sollten/müssen? -> Guter Punkt, sollte ich noch einmal drauf hinweisen. Vielleicht an allgemeiner Stelle, ist ja immer so. Spätestens im Beispiel stolpert man nochmal drüber.

Prefix bitte weglassen. -> Auch aus dem Ursprungspost, nehm ich aber raus. Hast recht.

Was ist überhaupt ein GAD oder Item? -> sollte im Wiki schon beschrieben sein, ich schau nochmal. Das Thema Widgets ist mM derzeit im Wiki noch sehr rudimentär eingeführt. Das muss man noch einmal allgemein beschreiben, was das ist und mit was das einhergeht. Hab ich auf dem Zettel.

In den Zusammenhang werde ich die Struktur vom smartVISU-Artikel noch einmal ein wenig umstellen (Bausteine und Konfiguration fürs Verständnis, der Rest als Nachschlagewerk):
Bausteine
   Statische Seiten
   Treiber
   Widgets
      Funktion: Was ist das? (Was sind items, GAD)
      Einbindung: Wie binde ich Widgets ein (import)? Wie verwende ich Widgets auf meiner Seite?
Konfiguration
verfügbare Widgets und Codebeispiele
Links

Anmerkungen und Anregungen sind wie immer stets willkommen.

[joshi04]

Ich bin nun noch einmal auf V2.7 und V2.8 näher eingegangen.
http://www.fhemwiki.de/wiki/SmartVISU_Installation

Als nächstes kommt die Konfiguration (Widgets, Seitenaufbau, etc.) dran. Das wird aber etwas dauern und reifen müssen.

[joshi04]

Fürs Erste hab ich nun die mir bekannten Repositories mit Quellen zu weiteren Widgets auf der smartVISU-Seite hinzugefügt.

Bis ich hier weitermachen kann, muss ich mich erstmal selbst schlau turnen.

Zwischenzeitlich würde ich mich freuen, wenn Ihr Euch den derzeitigen Stand der folgenden Artikel anschaut:
http://www.fhemwiki.de/wiki/Fronthem
http://www.fhemwiki.de/wiki/Fronthem_Installation
http://www.fhemwiki.de/wiki/SmartVISU
http://www.fhemwiki.de/wiki/SmartVISU_Installation

Schöne Grüße,
John

[dev0]

Gute Arbeit!

[joshi04]

Danke fürs drüber schauen und die Blumen. Das freut mich

[joshi04]

Habe noch das Repo für die Plots (mit DbLog) hinzugefügt. Und ein paar Links für die Schreibweise korrigiert. Die alten Weiterleitungen können nun gefahrlos (ohne tote Links) gelöscht werden. Da diese aber bereits so markiert sind (das findet seinen Weg), würde ich alles Weitere nicht mehr unter dem Thema "Artikelstruktur" sehen und diesen Thread entsprechend als erledigt markieren.
Schöne Grüße,
John

[dev0]

@John: Magst Du das vll noch mit ins Wiki aufnehmen: https://forum.fhem.de/index.php/topic,59338.msg507736.html#msg507736

[joshi04]

Bin gerade nicht ganz auf stand und muss mich erst wieder einlesen. Zwischenzeitlich hat es ja wieder richtig Fahrt aufgenommen und sich einiges verändert (freu).
Was meinst Du denn genau?
Falls der Hinweis auf das mysql-php gemeint ist, wird das ja erst in Zusammenhang mit den Plots notwendig. Diese Doku wollte ich allerdings auf dessen github belassen. So hatte ich damals zumindest die Aufteilung verstanden. Oder meinst Du etwas ganz anderes? Habe's selbst leider noch nicht eingerichtet...

Unabhängig davon, dass Du recht hast, ich könnte mich mal wieder kümmern, freue ich mich natürlich jederzeit auch über weitere Bearbeiter des Wiki und andere Blickwinkel.


Gesendet von iPhone mit Tapatalk

[dev0]

Falls der Hinweis auf das mysql-php gemeint ist, wird das ja erst in Zusammenhang mit den Plots notwendig. Diese Doku wollte ich allerdings auf dessen github belassen.

Yepp, das meinte ich. Du hast aber Recht, dass es eigentlich in die Doku zum Widget gehört.
Habe einen Issue auf Github eröffnet, da der Autor seit ~1 Jahr hier nicht mehr aktiv ist.

[dev0]

Ich habe den den Absatz "Config.ini kopieren" gerade etwas nach oben verschoben, da es sonst mit den Berechtigungen Probleme gibt: siehe hier