LoxBerry: Kennt ihr das?

[Sisamiwe]

Hallo,
ich bin beim Stöbern im Internet auf das Projekt "LoxBerry" gestoßen. Dies ist eine Erweiterung des Loxone auf Basis eines RPi.
Das Konzept ist ähnlich dem von shNG, zumindest in sofern, dass die Funktionalität mit Hilfe von Plugins erweitert wird.
Link

Die Plugins sind auch Skripte die teilweise in Python geschrieben sind. Vielleicht ergibt sich ja die Möglichkeit, diese zu "forken" bzw. als Basis oder Ideengeber zu nutzen.
Was meint ihr?

Michael

[psilo]

soweit ich das verstehe ist das ein raspi mit fhem und ein paar systemtools. fhem habe ich schon weitgehend nach ideen abgegrast. bspw das traffic plugin. wo genau siehst du denn bei den unter loxberry gelisteten plugins (sind nur 2 hand voll) potential? die meisten dinge haben wir imho schon.

[Sisamiwe]

fhem ist da auch in Plugin. LoxBerry ist in erste Linie ein Erweiterung des Loxone.

Du hast natürlich Recht, dass es bei shNG schon das meiste gibt.
Das Potential sehe ich bspw. bei dem BLE-Scanner, Door und auf der Wunschliste (bei den Einträgen, an denen gearbeitet wird) klingen einige auch interessant.

[Onkelandy]

Hab auf Hinweis von whe das Image und Webinterface mal gecheckt. Dabei stellt sich mir die Frage, ob es über das aktuelle Backendplugin bzw. eigenes Plugin mit http Modul möglich wäre, auch Systemeinstellungen zu tätigen...?

Also zB Abändern der knxd.ini Konfiguration via Webinterface? (De)Aktivieren von Systemdiensten, etc.

[psilo]

Onkelandy die frage ist: wollen wir das? wir haben den vorteil, dass shng auf vielen verschiedenen geräten und linux distributionen (und sogar ios + irgendwann mal windows) laufen würde..

da würde ich mich ehrlich gesagt nicht an systemnahme dinge auch noch binden wollen. dafür gibt es andere werkzeuge..
ich habe bspw. keine knxd.ini und der knxd ist ja sowieso in einem sep. docker container...

ein eigenes plugin kann gerne mal jemand versuchen, aber ins backend würde ich das nicht "weben" wollen.. der block mit dem knxd gehoert m.e. da derzeit eigentlich auch nicht ins backend rein.

PS: im dev sind mitlerweile alle gui frameworks (bootstrap 4 final, font awesome, jquery) global über "/gstatic" verfügbar, wenn das http modul benutzt wird. diese sollten dann auch für weitere GUI plugins verwendet werden. ich dokumentiere das die nächsten wochen noch und mache einen styleguide.

[Msinn]

Onkelandy Wenn man sowas will, wäre das ein eigenes Plugin mit Webinterface. Das einzig ungewöhnliche an dem Plugin wäre, dass es die Standardmethoden nicht füllt, da es sich nicht um die Bearbeitung von Items kümmert. Die Webinterfaces von Plugins können direkt per url oder aus dem backend aufgerufen werden.

[Onkelandy]

Okay, wenn ich's richtig verstehe, wäre also entweder ein komplett unabhängiges Webinterface oder ein Plugin (zB raspi-config) ein Ansatz, wobei Letzteres insofern nicht optimal passt, da es nur bedingt mit SmarthomeNG und dessen Items zu tun hat...? Aber theoretisch wäre es okay und machbar?

Falls ich mich da wirklich mal an eine Config für das Raspi-Image wagen sollte, möchte ich möglichst auf Bestehendes aufbauen.

[psilo]

Onkelandy ja ich sehe auch ein eigenes plugin, dann bspw. spezifisch für den raspi... auf bestehendes kannst du bzgl gui dann aufbauen. wir versuchen für 1.5 auch so dinge wie ein globales menü zu lösen. und items brauchst du am ende viell. doch, um bestimmte dinge "wegzuspeichern".

wir haben übrigens eine reihe plugins ohne eigene items.. die meist eine api für clouddienste als shng funktion bereitstellen

[Onkelandy]

Danke für den Input. Eigentlich wäre es sogar eine gute Idee, alles als Items festzulegen und dann einfach diese Items über das Webinterface anzupassen. Dann würde auch eine Logik ausreichen, die beim Ändern des Items über Python den entsprechenden Systembefehl ausführt?

[psilo]

Onkelandy wäre ne idee.. ich würde das aber eher in einer pluginfunktion kapseln, die getriggered wird