LoxBerry Plugin Entwickler: Was wünscht ihr euch?

[Christian Fenzl]

Hallo liebe Plugin-Entwickler,

Prof.Mobilux und ich sind ja fleißig am Werken für LoxBerry 0.3.x.
Ich habe in den letzten Tagen einige System-Module von Michael auf das neue Template-System umgestellt, und bei meiner "Code-Streichelei", die ich dabei betrieben habe, habe ich gesehen, wieviele Mann-Wochen/Monate Michael investiert hat, um alles so hinzubekommen, wie es ist. So einfach wie das alles am Webinterface ausschaut - da steckt durchdachter Code mit allen Techniken dahinter.

Ich habe in die Issues-Liste einen Haufen Wünsche deponiert, die ich mir bzw. uns für die LoxBerry-Weiterentwicklung vorgenommen habe.

Da alles zusammen für einen LoxBerry v0.3 bzw. v0.4 nicht mehr umsetzbar sein wird, möchte ich euch fragen, was ihr euch denn vom LoxBerry-Core wünscht, oder ihr am Sinnvollsten hält, um bei den Plugins oder der Plugin-Entwicklung flexibler zu sein. Ich habe hier ein paar Vorschläge gemacht - aber gerne könnt ihr auch eigene ergänzen.

Also kurzum - Was wünscht ihr euch?

lg, Christian

(PS: Alle Punkte sind "cool" - wählt die aus, die euch am meisten Nutzen bringen würden)

[svethi]

Services müssen vllt nicht unbedingt systemd sein, da dafür wieder konfigurationen gebaut werden müssen, schön wäre einfach, dass man Services über das Webinterface Neustarten können sollte.
Webservice ist sicher nicht schlecht,da nicht jedes Plugin dann eigene Verbindungen aufbauen müsste. Webservices vs. Kommunikationsinterface. Nur über Webservice kommt man an bestimmte Daten ran und außerdem bekommt man Notifikationen über geänderte Werte. Somit entfällt ein ständiges pollen. Allerding wird die Verwaltung etwas kompliziertert. Steht weit hinten an.
Ich hoffe, dass ich auch mal wieder Zeit finde mitzuhelfen.

Gruß Sven

[Michael M.]

1.) Nur die tatsächlichen dependencies für den Loxberry in der packages.txt - siehe mein Beitrag hierzu:

https://www.loxforum.com/forum/projektforen/loxberry/entwickler/131063-loxberry-als-docker-container-opt-loxberry-packages-txt

2.) "Globale Variablen" für die Pluginstallation (PLUGINFOLDER, etc.), welche durch den Loxberry Plugin-Installer aufgelöst / ersetzt werden, sodass nicht jedes Plugin dies für sich machen muss

3.) Effizientere Installation der benötigten Packages in /opt/loxberry/sbin/installpackages.pl
-> derzeit wird für jedes Paket eine neue apt-get install session gestartet. Besser wäre ein Installationsdurchlauf mit allen paketen: apt-get install Paket1 Paket2, etc. auch sollte der Parameter -no-install-recommends zu apt-get hinzugefügt werden

[Prof.Mobilux]

Hallo Michael,

1.) Nur die tatsächlichen dependencies für den Loxberry in der packages.txt - siehe mein Beitrag hierzu:

Wird leider nicht kommen. Siehe mein Posting im anderen Thread.

2.) "Globale Variablen" für die Pluginstallation (PLUGINFOLDER, etc.), welche durch den Loxberry Plugin-Installer aufgelöst / ersetzt werden, sodass nicht jedes Plugin dies für sich machen muss

Ist bereits auf der Agenda und wird definitiv kommen!

3.) Effizientere Installation der benötigten Packages in /opt/loxberry/sbin/installpackages.pl
-> derzeit wird für jedes Paket eine neue apt-get install session gestartet. Besser wäre ein Installationsdurchlauf mit allen paketen: apt-get install Paket1 Paket2, etc. auch sollte der Parameter -no-install-recommends zu apt-get hinzugefügt werden

Ja, ist unschön. Könnte man sicherlich recht schnell umbauen. Aber ich benutze das Skript genau ein einziges Mal bei jeder LoxBerry-Version: nämlich wenn ich das Image baue. Ansonsten braucht man das nicht. Hat also nicht ganz so hohe Priorität :-) Aber ich mache dazu ein Issue auf GIT auf.

[svethi]

Michael M. ich habe auch schon einmal einen Docker Container gebaut, doch man konnte Im Container keinen Neustart oder shutdown ausführen. Damit ist die Bedienbarkeit dahin.

[hismastersvoice]

Automaten updates sind zwar eine get feine Sache, aber nur in Verbindung mit einer Meldung oder Email das upgedatet wurde. Sonst passiert es das evtl das ein Plugin nicht mehr richtig funktioniert und der User merkt es erst spät. So kann er es wenigstens auf Funktion prüfen nach dem Update.

daemon/systemd
Da bin ich der Ansicht von svethi.
Das Problem mit den Rechten hatten wir ja schon in einem anderen Thread.

Was ich mir noch wünsche ist eine einfache Install/Uninstaller Routine für zB python Pakete usw.
In Augenblick geht es ja nur mit viel Aufwand und tricksen. Ist auch ein Thema der Rechte von loxberry.

Ein wichtiger Punkt für mich ist sind die templates in php. Ich schreibe meine Skripte lieber in php, perl habe ich mir jetzt etwas angeeignet, mag es aber nicht wirklich.
Ich denke das hier auch mehr in php schreiben können als in perl so erweitert man can Entwickler-Kreis.

[Christian Fenzl]

Das Starten von Daemons aus dem Webif werden wir hiermit adressieren: https://github.com/mschlenstedt/Loxberry/issues/247

Python habe ich erfasst: https://github.com/mschlenstedt/Loxberry/issues/279

Die Umfrage ist durchwachsen :-)
Einen eindeutigen Sieger gibt es nicht.

Die Roadmap für 0.3/0.4 sieht aus meiner Sicht so aus:

• Michael hat sich der Plugin-Schnittstelle V2 verschrieben, die alle Issues adressieren soll, die in Plugin-Schnittstelle V1 jetzt zu gröbsten Workarounds geführt hat.
• Ich werde die Einbindung der Templates für PHP machen (loxberry_web)
• Als dritten Punkt sehe ich jetzt Automatische Updates für LoxBerry auf der Agenda. Das ganze auf Basis von Releases bei GitHub, und wahlweise sogar auf Commit-Ebene.

"Automatisch" ist im Sinne von wahlweise automatisch, oder durch User getriggert und automatisiert. Diese Funktion für LoxBerry gibt uns die Möglichkeit, schnell auf Fehler zu reagieren, und fließend neue Funktionen nachkommen zu lassen.
Mit LB 0.2.3 war es ja so, dass Fehler seit einem halben Jahr im Code gefixt sind, aber
keine automatisierte Update-Funktion da ist, um das hinaus zu bringen. Das muss eine Core-Funktion werden, dass wir im Notfall on-the-fly eine Korrektur ins Feld bringen.

Dann können wir uns die serverseitige Infrastruktur für automatische/automatisierte Plugin-Updates ansehen und mit einem LoxBerry-Update so eine Funktion nachliefern.

Verwundert bin ich über das niedrige Interesse an einer Logging-Unterstützung für die Plugins für alle Sprachen. Wenn ich mir die Forumsthreads zu Plugins ansehe, hätte ich das als Hauptthema betrachtet, damit die Fehleranalyse leichter wird. "Bist du auf einem LoxBerry oder ist dein Image selbst gebaut?" - das ist ja wirklich eine unnötige Fragerei.

Das Notification Modul wäre dann auch etwas, was wir über ein LoxBerry Update shippen können. Das geht möglicherweise direkt Hand in Hand mit einem Logging-Modul. Irgendwie müssen die Meldungen vom Plugin eingesammelt werden, da kommt das Logging-Modul doch wieder ins Spiel.

Websockets ist noch ein Thema für sich, weil wir da alle noch sehr grün hinter den Ohren sind. Wörsty hat da schon probiert. Was mir gefallen würde, wäre ein node.js Service, das von einem Plugin lokal über einen Linux Socket angesprochen werden kann. Damit hätten wir das Sprachenproblem weg, weil mit einem Linux Socket kann jede Sprache reden. Auf welcher Sprache der lokale Dienst dann basiert (Perl, PHP, Mode.js, Java) ist letztendlich egal, Hauptsache es geht. Optimal wäre, wenn wir Code der node-red Implementierung stibitzen könnten, wir brauchen das Rad nicht neu erfinden.

Wenn wir, Michael, Wörsty, Sven und ich, diese Tasks sinnvoll aufteilen, denke ich, dass wir wirklich zu Weihnachten eine Beta abliefern können. Bis zum eigentlichen Release muss ja noch nicht alles fertig sein.

[orli]

[*]Als dritten Punkt sehe ich jetzt Automatische Updates für LoxBerry auf der Agenda. Das ganze auf Basis von Releases bei GitHub, und wahlweise sogar auf Commit-Ebene.[/LIST]
"Automatisch" ist im Sinne von wahlweise automatisch, oder durch User getriggert und automatisiert. Diese Funktion für LoxBerry gibt uns die Möglichkeit, schnell auf Fehler zu reagieren, und fließend neue Funktionen nachkommen zu lassen.
Mit LB 0.2.3 war es ja so, dass Fehler seit einem halben Jahr im Code gefixt sind, aber
keine automatisierte Update-Funktion da ist, um das hinaus zu bringen. Das muss eine Core-Funktion werden, dass wir im Notfall on-the-fly eine Korrektur ins Feld bringen.

Hi Christian,

vielleicht baut ihr in dem Zuge auch direkt die Updatefunktion für das OS als Solches ein. Es gibt da Tools wie unattended-upgrades, die diese Funktion automatisiert und mit Mailbenachrichtigung bei Fehlern ausführen und einfach via apt installiert werden können. So könntet ihr diesen Part mit einfachen Mitteln auch jedem User zur Verfügung stellen. Ich nutze das Tool übrigens auf hunderten von Servern seit Jahren und könnte Config technisch was sinnvolles liefern was nicht das System zerschießt.

[Christian Fenzl]

orli Das ist schon drin.

EDIT: https://github.com/mschlenstedt/Loxb...-upgrades.conf

Wir machen erstmal nur Security Updates. Über das Webif aus-/einschaltbar.

[orli]

Sehr gut, hatte ich noch garnicht gesehen!

[svethi]

Ich wollte mich ja mit dem Thema SSDP befassen. Hatte da auch schon angefangen. Damit der minidlna raus kann und das muss auch abschaltbar sein, da son kein weiterer Dienst UPnP anbieten kann.

[Christian Fenzl]

Mach mal dazu ein Issue

[svethi]

Gibts doch schon ;-) minidlna

[Christian Fenzl]

Ah, der!