Der Weg zum nächsten (0.8.0) Release

[JuMi2006]

Zurück zum Paket. Was hat es mit minify auf sich. Braucht man das?

[henfri]

Hallo,

es verlangt ja keiner eine Anleitung, wie man einen Webserver installiert.
DAS Problem ist es den eibread-cgi/eibwrite-cgi zu kompilieren.
Das MUSS ohne die eibd-sourcen und all dessen Abhängigkeiten gehen.

Gruß,
Hendrik

[MGK]

Das MUSS ohne die eibd-sourcen und all dessen Abhängigkeiten gehen.

braucht man alle sourcen und Abhängigkeiten dafür?????

warum das denn???

ich bleibe glaube ich bei 0.6...

Gruss,
Michael (der das 0.6er Raspi-Image nutzt)

[swiss]

Aber jetzt verstehe ich etwas nicht ganz...

Man neme die bcusdk aus dem Openautomations Repo

http://sourceforge.net/p/openautomation/code/HEAD/tree/tools/bcusdk/

Da ist für Debian alles schon vorkompiliert.

Im Unterverzeichniss eibd/examples in der ReadMe steht:

Additional eibd-clients for CV-Backend (eibread/write-cgi)

Mini-Howto: Option 1)
* Install gcc and libeibclient-dev (or Distribution-specific package containing libeibclient.a)
* Checkout
* Compile using:
gcc -leibclient -c bcusdk-include/common.c
gcc common.o -I./bcusdk-include -leibclient -o eibwrite-cgi eibwrite-cgi.c
gcc common.o -I./bcusdk-include -leibclient -o eibread-cgi eibread-cgi.c
* move eibread-cgi and eibwrite-cgi to cgi-dir to be used by web server serving CometVisu

Option 2)
* Checkout into bcusdk/eibd/examples
* Adjust Makefile.am:
-xpropread xpropwrite groupcachelastupdates
+xpropread xpropwrite groupcachelastupdates eibread-cgi eibwrite-cgi
-xpropread.c xpropwrite.c groupcachelastupdates.c
+xpropread.c xpropwrite.c groupcachelastupdates.c eibread-cgi.c eibwrite-cgi.c

Es ist also doch schon alles zentral vorhanden was für eine Kompilation benötigt wird. Oder verstehe ich das Problem falsch?

[henfri]

Nee, ich denke, das ist das, was wir brauchen?!
Das meinte ich auch mit

Und: Vielleicht hat sich beim Backend ja auch mitterweile noch was getan.

Wenn das mal jemand testen würde, würde das in die Anleitung gehören und ich könnte aufhören (konstruktiv) zu meckern.

Gruß,
Hendrik

[swiss]

Ach soo

Naja mal sehen ob ich dass als absoluter Linux noob hin bekomme. (Ich würde mir ja immer noch eine CV VM wünschen). Da kann ich gleich mal üben

Das ist effektiv etwas das unterdokumentiert ist und auch absolut in die CV Doku gehört

[Chris M.]

Zurück zum Paket. Was hat es mit minify auf sich. Braucht man das?

Geht an sich auch ohne. Ist aber für die Performance sinnvoll. Und sollte eigentlich für jeden egal sein, außer demjenigen (= wohl ich) der das CV Release Paket baut.

Dieses Release Paket kann man dann bei sich auf dem Server "installieren", was ein ziemlich roher Vorgang ist (Dateien im Zielverzeichnis auspacken). Oder ein anderer Maintainer baut daraus ein distributions spezifisches Paket (z.B. Makki für das WireGate) das per simplen Paket-Manager-Befehl installiert wird.

Das MUSS ohne die eibd-sourcen und all dessen Abhängigkeiten gehen.

Den eibd brauchts als Abhängigkeit (so wie eine libc...), aber nicht den Rest vom bcusdk. Damit sind Abhängigkeiten natürlich da - aber überschaubare.

ich bleibe glaube ich bei 0.6...

Gruss,
Michael (der das 0.6er Raspi-Image nutzt)

Das Backend ist für 0.6 und 0.8 identisch. Du kannst problemlos auf 0.8 upgraden, einfach die Dateien für den webserver drauf und fertig

(Ich würde mir ja immer noch eine CV VM wünschen).

Wahrscheinlich ist die so trivial, dass die deswegen noch keiner bereitgestellt hat.

Nimm einfach x86 Ubuntu Server (oder auch Debian) als Mini-ISO, die auf eine leere Maschine, eibd-Paket vom WireGate-Repository.
Fertig.

Das das mit dem lokalen Netzwerk mag ist der größte Aufwand - und der muss bei jedem individuell eingestellt werden, man will ja von außen drauf zugreifen..

[JuMi2006]

Welche Performance meinst Du? Die Performance im Betrieb oder beim installieren?

Die Paketierung an sich ist mir schon klar ... mich interessiert eigentlich was minify mit den *.js macht.

Den eibd aus dem WireGate-Repo brauchts doch nur für l,r und w oder gibts da weitere Anpassungen? Hier funktionierts jedenfalls auch mit dem Standard eibd un selbst kompilierten l,r,w. Nebenbei eben auch meine Version des rrdfetch die kein gepatchtes rrdtool braucht.

[Chris M.]

Welche Performance meinst Du? Die Performance im Betrieb oder beim installieren?

Die Paketierung an sich ist mir schon klar ... mich interessiert eigentlich was minify mit den *.js macht.

Beim Betrieb.
Klassisch reduziert das die Zeit die JavaScript Dateien zu übertragen (nicht nur an Gigabit Ethernet denken, manchmal ist man schon froh am Smartphone EDGE zu haben...).
Durch die Nutzung des Offline-Cache ist das hier allerdings nicht mehr ganz so wichtig. Dafür spart das nun Platz im Cache. Und beim Parsen sollte es auch ein paar Zyklen sparen.

Den eibd aus dem WireGate-Repo brauchts doch nur für l,r und w oder gibts da weitere Anpassungen? Hier funktionierts jedenfalls auch mit dem Standard eibd un selbst kompilierten l,r,w. Nebenbei eben auch meine Version des rrdfetch die kein gepatchtes rrdtool braucht.

Nein, man eibd oder gar bcusdk gibts keine Anpassungen. Aber die Lib braucht's zum kompilieren.
Wie Du selber gesehen hast, ist das aber eigentlich nicht schwer. Von daher verstehe ich auch nicht wo hier das Problem liegen soll.

rrdtool ist natürlich auch noch ein wichtiges Thema. Aber im Sinne der CometVisu "nur" optional, r und w dagegen zwingend notwendig.

[Knaller]

Ich hab bei meiner VM dIe Netzwerkkarte der V M auf NAT Modus und schon kannst Du mit einer eigenen IP hantieren. Linux erkennt dein Netzwerk automatisch. Gruß Herbert

[JuMi2006]

rrdtool ist natürlich auch noch ein wichtiges Thema. Aber im Sinne der CometVisu "nur" optional, r und w dagegen zwingend notwendig.

Das kann ich so nicht teilen ... die Graphen gehören schon zu den Kernfeatures, ob man das so will oder nicht.

Wir reden also lediglich darüber nach einem installierten eibd noch die scripte zu kompilieren oder sie für die wichtigsten Distros auszuliefern/vorzuhalten.

Ich würde nen cometvisu-0.8_all.deb bauen und vom Backend trennen. Als Abhängigkeit kommt da der lighttpd mit rein und fertig.
Die backend Pakete kann man das Distibutionsabhängig machen.

[Chris M.]

Ich hab bei meiner VM dIe Netzwerkkarte der V M auf NAT Modus und schon kannst Du mit einer eigenen IP hantieren. Linux erkennt dein Netzwerk automatisch. Gruß Herbert

NAT ist eben schwierig - schließlich soll in der VM ein Server laufen, auf den Du von außerhalb (also dem normalen Intranet) zugreifen möchtest.

Das kann ich so nicht teilen ... die Graphen gehören schon zu den Kernfeatures, ob man das so will oder nicht.

Ah, Kommunikation. Geht gerne mal schief, da man so viel Kontext impliziert und nie dazu sagt...

Meine Aussage war über die CV an sich. Da gibt es ein paar Kern-Features ohne die die CV keinen Sinn macht. Und erweiterte, die das Leben dann auch noch schön machen - aber höhere Anforderungen haben. Wie PHP - oder eben RRD.
Hintergrund ist, dass die minimalen Systemanforderungen auch eine Fritz!Box bereit stellen können soll...

Wenn Du nun davon ausgehst ein Paket für ein Debian-System (an sich schon mal deutlich fetter als ein handoptimiertes Linux wie auf einem Router) baust, dann gehört da natürlich RRD mit rein.

Ich würde nen cometvisu-0.8_all.deb bauen und vom Backend trennen. Als Abhängigkeit kommt da der lighttpd mit rein und fertig.

Und ein PHP zumindest als empfohlen. Würde es bei dem Paket aber eher als richtige Abhängigkeit mit reinpacken. (Wer Debian nutzt und hier auf Byte-Anzahl optimiert kann auch das rohe Paket verwenden. Und bei den reinen Anfängern hat man durch die harte Abhängigkeit evtl. noch etwas geholfen)

[JuMi2006]

Meine Aussage war über die CV an sich. Da gibt es ein paar Kern-Features ohne die die CV keinen Sinn macht. Und erweiterte, die das Leben dann auch noch schön machen - aber höhere Anforderungen haben. Wie PHP - oder eben RRD.
Hintergrund ist, dass die minimalen Systemanforderungen auch eine Fritz!Box bereit stellen können soll...

Naja und hier scheiden sich die Geister. MEINE Sicht der Dinge ist folgende:

- die CV sollte sich auf einem Standard-System (Raspberry, Debian, Ubuntu -> x86+arm) einfach installieren lassen ohne dutzende unerfüllbare* Abhängigkeiten
- wer das Teil unbedingt auf die Fritzbox quetschen will kann sich dann etwas mehr Mühe geben, der braucht i.d.R. aber weder howto noch fertige Pakete

*natürlich nur eine Frage des Aufwands

Ich hab das Gefühl, und das bitte nicht als persönliche Kritik verstehen, dass hier am Ziel vorbeigeschossen wird. Der hohe technische Anspruch ist zwar schön aber man sieht doch auch wie sehr sich das Entwicklerteam ausdünnt bzw. wie wenig Leute neu dazu stoßen. Das liegt nicht zuletzt an den harten Abhängigkeiten die derzeit bestehen. Sowas bremst das ganze Projekt was ich für sehr Schade halte.

Wenn Du nun davon ausgehst ein Paket für ein Debian-System (an sich schon mal deutlich fetter als ein handoptimiertes Linux wie auf einem Router) baust, dann gehört da natürlich RRD mit rein.

Und ein PHP zumindest als empfohlen. Würde es bei dem Paket aber eher als richtige Abhängigkeit mit reinpacken. (Wer Debian nutzt und hier auf Byte-Anzahl optimiert kann auch das rohe Paket verwenden. Und bei den reinen Anfängern hat man durch die harte Abhängigkeit evtl. noch etwas geholfen)

Full ACK! Siehe oben, wir könnten ja mal eine Umfrage starten wer die CV WO laufen lassen wird. Ich tippe auf 90-95% die mit x86 und Raspberry antworten.
Daher wäre die Trennung von Backend und Webservice als Pakete m.M.n. sehr sinnvoll. Da gibts ein Paket für den Webservice und eben die Sourcen und beliebig viele Binarys/Pakete für das Backend.

[Ziegelstein]

.. Dann klemme ich mich mal wieder hinter die Doku. (Macht jetzt mit Freeze auch Sinn)

Wünsche zu: "Was gehört unbedingt dokumentiert" bitte mal z.B. hier zusammen tragen. Damit mir da nichts durchrutscht...


Also hier mal der Anfang der Wunschliste:

- Installation des Releas 0.8 auf WG (am besten noch zusäzlich mit screencast)

Als Anfänger habe ich Probleme mit allen Eigenschaftseingaben, die über Freitext kommen, wenn es kein drop-down menü gibt.
Mein Wunsch: klare Aussage (Tabelle oder so) mit den Möglichkeiten der eingaben.
("center" bei align oder vorgaben/Beschreibungen zu Einheiten wie °C oder KWh)

Ansonsten wäre es Toll, wenn die Demo-Version Vollständiger wäre. Z.B. Rollosteuerungen mit eingebunden Bildern als Vorlage - wo man nur rauskopieren / abschreiben braucht.
Detail-Erklärung über die Verwendung von Bildern - welche sind bereits hinterlegt? wie werden sie Eingebunden?
Viele Praxisbeispiele, wozu man welchen Button / Eigenschaft nutzen könnte..

soweit auf die schnelle..

Gibts eigentlich sowas wie ein Timer? benutze sowas auf meinen Arcus Touch- falls die jemand in Verwendung hat - Zeiten einfach über die Visu anpassen..falls ja --> in der Doku darauf eingehen.

ansonsten Daumen hoch für das Projekt!!

[swiss]

Ich werde mal sehen was ich in der kurzen Zeit umsezen kann. Sind viele gute Inputs gekommen auch wenn es wohl nicht für alles reichen wir bis zum Releas. Aber Feintuning ist ja auch nach dem Releas noch möglich. Also sollte das Augenmerk erst mal auf den Grundlagen liegen.

Also:
- Installationsanleitung
- Beschreibung aller Widgets und Paramete
- Tutorial fertig stellen (damit sollte man schon weit kommen)

In einem zweiten Schritt dann noch:

- Beispiel Parameter und Auswirkung auf Widgets

Für Ideen was man mit geschikter Konfiguration erreichen kann / für was man die Widgets einsetzen könnte gibt es ja noch die Beispiel-Configs wo man spicken kann. Ich denke das sollte als Dokumentation ausreichen!?