Meeting für ioBroker Core/Dev/Admin 21.02.24 20:30
-
@simatec nächstes mal ist schlecht, aber ich kann es für übernächstes Mal was vorbereiten;-)
-
@ldittmar Das wäre Klasse
-
Noch ein (hoffentlich) kurzes Thema:
Der Adapterchecker wurde (noch als PR) erweitert um zu prüfen
- common.licenseInformation
- common.tier
- common.automaticUpgrade
Wo sind diese neuen Attribute dokumentiert?
Wie ist geplant diese Info an die Entwickler zu bringen?Wenn diese Prüfungen scharf geschaltet werden, gibts bei www.iobroker.dev bei jedem Update einen Fehler da 99% der existierenden Adapter diese nicht gesetzt haben. Und bei jedem Repo Update Check werden diese Prüfungen auch als Fehler aufpoppen und Rückfragen auslösen...
Generell frage ich mich ob hier nicht warnings voll ausreichend wären - das System muss ja jedenfalls mit dem IST STand umgehen können.
-
@mcm57 Ja warnungen sollten reichen und ja es geht backward kompatibel. AM Ende sehen es die Devs damit beim nächsten Repo update und auch das io-package schema ist angepasst für die die es in der IDE sehen. Und ja wir sollten imMeeting kurz was dazu sagen
-
@mcm57 sagte in Meeting für ioBroker Core/Dev/Admin 21.02.24 20:30:
Wo sind diese neuen Attribute dokumentiert?
licenseInformation hab ich in der Doku untergebracht. PR gibt es schon.
https://github.com/Jey-Cee/ioBroker.docs/blob/7d623d350a33ac614aa385838b30aa1629efec59/docs/en/dev/adapterref.md#licenseinformation -
Information
Da ich Rafa bisher nicht erreicht habe und daher nicht weiss ob das Teams-Meeting heute Abend offen ist (sollte Theoretisch ... sehen wir mal).
Falls das nicht geht kann es sein das wir spontan den Teams Link ändern !! -
@apollon77 Ich könnte zur Not auch noch ein Meeting in Teams aufmachen.
-
@apollon77
Vorwarnung:
Ich versuche mich heute abend mal einzuklinken. Bin noch etwas skeptisch, ob die Technik mitspielt und Teams hatte ich noch nie in Nutzung. Video Calls zu Kinder/Enkeln gehen immer via ThreemaSollte also irgendwas schief laufen, bitte nicht schimpfen und zur Not verschwinde ich auch wieder, damit ich nicht störe. Also schaun wir mal. Bis denne.
-
@pi-ter So schlimm wars gar nicht gg
-
So, weil es sonst den ersten Post sprengt habe ich hier noch das Statement aus Projektsicht zu einigen der Themen hier in einer gekürzen Textfassung.
Zielgruppe: Grundsätzlich natürlich alle Smart Home User, die technisch affin genug sind sich einen Raspi, Nuc, Docker oder anderes passendes System aufzusetzen in dem Sie ioBroker betreiben können. Ausser wenn die ioBroker GmbH mal wieder "ioBroker vorinstallierte Server verkauft". Also: Nein iobroker ist keine Appliance die man ansteckt und fertig. Das wäre eine Abgrenzung. Was aber auch wichtig ist, ist der Fakt das ioBroker nicht nur auf Smart Home beschränkt ist, auch wenn das gerade keine echte Priorität bei der Feature- und Adapterplanung hat. ioBroker kann, und wird bereits, in der Industrie und Wissenschaft und weiteren Umfeldern eingesetzt, wie wir in Solingen gelernt haben. ioBroker überwacht Umweltdaten in der Pferdezucht bei Weihenstefan, unterstützt die Bergwacht mit Daten von Bergen und wird genutzt um Helikites oder Drohnen um Funktionen zu erweitern die über das Fliegen hinausgehen. Also: die Zielgruppe startet bei dem erstgenannten, aber darüber hinaus gibt nes keine Grenzen, so lange Node.js verfügbar ist.
Das beantwortet auch ein bissl die Frage nach "Was ist ioBroker und was nicht": Als Grundsystem ist ioBroker ein Input-Output System welches über Plugins Daten erfassen, verarbeiten und wieder ausgeben kann - sei es in anderen Datenformaten, oder als Steuerbefehle oder als Visualisierung. Das ist aber nicht die Antwort auf die echte Frage
Wenn wir also die Frage "Was ist ioBroker für uns im Smart-Home-Bereich?" stellen, dann macht das die Beantwortung aber auch nicht wirklich leichter. Natürlich wollen wir gern ein einfach zu bedienendes System für die vorher genannte Zielgruppe aller Smart-Home-Nutzer schaffen. Ich denke auch das unsere Abgrenzung von anderen Systemen genau die Flexibilität ist - das bei uns einiges "grob vorgegeben" ist aber auch dadurch nicht starr definiert ist. Das macht natürlich hier und da einiges einfacher ... bei uns geht aber mehr. Also das was wir von Projektseite gern wollen ist ein einfaches System was bei Bedarf aber Flexibel ist.Im Zuge der ganzen Diskussion die letzten Wochen haben wir uns auch andere Systeme mal genauer angeschaut und verglichen. Es ist richtig das wir beim Onboarding der User aktuell Schwächen haben. Der User wird nach dem Einrichtungs-Assistenten erst mal vom Funktionsumfang erschlagen und muss sich dann selbst zurechtfinden. Für Discovery haben wir schon in Solingen letztes Jahr Ideen diskutiert was wir anpassen wollen. Wir müssen den User vor allem bei den ersten Schritten besser unterstützen und unsere Flexibilität, die wir gegenüber anderen haben, besser verpacken (nicht verstecken). Ziel ist definitiv nicht „nur Profis/fortgeschrittene“ anzusprechen. Wie gut das geht hängt damit vor allem von Frontend Entwicklern ab und da sind wir sehr knapp. Das versucht Denis teilweise durch Outsourcing schon zu kompensieren wie es die finanziellen Mittel zulassen. Das st jetzt kein Mimi, aber einfach die Realität.
Was die Frage nach Vereinfachungen zur Wartung des Systems angeht kann ich nur darauf hinweisen das wir daran bereits arbeiten - Der js-controller kann seit Version 5 über Admin aktualisiert werden ohne auf die Shell zu müssen - mal mindestens für Linux als Haupt-System. Windows sind wir gerade in Überlegungen wie es am besten ginge. Schon vor längerem haben wir das Thema "Node.js update per Admin" und vllt sogar "Betriebssystemupdates per Admin" für Linux für den js-controller 5.1 als Thema gesetzt und die Entwicklung begonnen.
Von daher sind wir natürlich daran interessiert die Pflege des Systems so einfach wie möglich zu machen. Auch Fortgeschrittene freuen sich darüber wenn Ihnen jemand da Arbeit abnimmt.Werden wir es schaffen einen Appliance-/OS-Ansatz wie Home Assistant oder OpenHabian zu haben? Wenn ihn jemand baut und beisteuert und wir das dann langfristig pflegen können vielleicht. Wobei ich daran nicht glaube, wenn ich mir überlege welcher Aufwand das ist. Also können wir nur überlegen was das ist, womit dennoch die meisten User sinnvoll klarkommen. Und das ist auch ok so!
Ansonsten sind wir gerade dabei aus dem vergleich der Systeme einige Arbeitspakete abzuleiten. Auf die groben Themenbereiche würde ich im Anschluss gern dann nochmal kurz eingehen, aber das würde dieses Thema sprengen. Da brauchen wir aber auch die Unterstützung von Euch Devs.
Last but not lesast zu der "10 Jahre" Frage ... schwierig aber na klar: wir sind (weiterhin) das zwei größte Open Source Smart-Home System und können unsere stärken in Sachen Flexibilität weiterhin ausspielen bzw. behalten. Weiterhin haben wir (natürlich) auch in 10 Jahren alle relevanten Smart-Home-Protokolle und Technologien, die dann aktuell sind, integriert.
Weil auch das Thema der kommerziellen Adapter in der Diskussion direkt oder indirekt mitgeschwungen ist: Es ist natürlich das klare Ziel das es ioBroker ein freies System bleibt. Adapter die sehr wartungsintensiv sind oder spezielle Protokolle implementieren die eher im „nicht privaten Smart Home Bereich“, also eher im industriellen Umfeld zu nutzen sind (weil wir so flexibel sind) können kommerziell sein. Das sollte allerdings weiterhin die deutliche Minderheit sein.
In der Diskussion kamen durchaus noch Themen auf, wo wir auch besser werden können, was vor allem in Richtung "Projekt-Marketing", Blog und Webseite (besser Herausstellen was ioBroker ist und was uns abgrenzt) geht.
Weiterhin haben wir uns einige Themen vorgenommen wo wir in nächster Zeit Verbesserungen anbringen wollen, das sind unter anderem:
Das Ziel ist definitv nicht alles so zu machen wie andere Systeme oder es zu kopieren! Unser System ist Flexibler und das bedeutet das einige Ansätze anders sein müssen und das ist auch ok so. Aber dennoch können wir uns verbessern.
Die Themen die wir zuerst angehen wollen sind:
- Wir wollen den Einrichtungsassistenten erweitern und vor allem Standard-Adapter besser vorschlagen und auch die Vorteile besser darstellen. Dazu wollen wir Vorschläge aus den Bereichen Logik (JavaScript, Node-Red, Scenes ...), Cloud, Historisierung, Notification (Pushover, Telegram ...), Visualisierung, vllt auch Wetter.
- Wir wollen Discovery erweitern um generisches Scanning per MDNS, UPnP und diese Standardprotokolle zusammen mit einem Konfigurations-Ansatz in der io-package. Das bedeutet das, sobald wir das Format definiert haben wir von den Devs Unterstützung brauchen wie Ihre Adapter ggf generisch zu erkennen sind! Diese Idee kam übrigens schon aus Solingen letztes Jahr. Sobald wir das haben gibts weitere Ideen wie wir Discovery verbessern, aber eins nach dem anderen
- Überarbeitung der Adapterliste wenn man eine Komplettliste bekommt. Voraussichtlich eine Mischung aus Vorschlägen aus kategorien und "filterbare Listen", also eher Vorschlagen oder suchen. Auch hier brauchen wir Unterstützung der Devs um alle Ihre tags in den package/io-package zu prüfen das wir sinnvoll finden können
- Instanzkonfiguration vereinfachen: Weiteres Thema und Aufruf an alle Devs: Bitte prüft Eure Admin UIs. Idealerweise strukturieren wir in Zukunft so das die erste Seite/Tab nur das minimale enthält was man braucht oder einstellen muss, alle anderen Optionen lieber auf weitere Tabs verteilen. Ziel: Den User nicht direkt mit Optionen überfrachten. Im Zuge der späteren Discovery Optimierungen haben wir noch andere Ideen aber erstmal ist das schonmal ein guter Schritt.
- Jeder der die ioBroker Visu App verwendet und nen pro Account hat wird künftig entscheiden können weitere Daten zum Handy ggf inklusive der Position ans system zu übertragen.
- Admin erhält weitere Notifications, zb für ausstehende Adapterupdates und einen neuen Tab "Notifications" der diese anzeigt. Dort können künftig zb auch Discovery Ergebnisse reinkommen o.ä.
- Und der Device-Manager ist ein grosser Baustein in der User-Flow Optimierung und wird auch wie geplant fertiggestellt
Danach kommt der nächste Schwung an Themen die dann alle ggf etwas grösser sind und wir schauen müssen wann wir Sie wie umgesetzt bekommen. Aber diese Themen sollten schon einmal erste Verbesserungen für den Einstiegs-Flow mit sich bringen. Auf der Basis einer besseren Discovery und dem Devie-manager kommen dann weitere Optimierungen dran.
Kann ich dazu einen Termin nenen bis wann das fertig sein soll? Nein, leider nicht. Wir haben uns aber zumindestens im Core-Team verständigt das wir diese Themen und die Folgethemen angehen müssen und werden.
-
@apollon77 sagte in Meeting für ioBroker Core/Dev/Admin 21.02.24 20:30:
@pi-ter So schlimm wars gar nicht gg
Moin Ingo,
ja das stimmt. Ich hatte allerdings großen Respekt vor diesem Teams-Gedöhns.
Dass meine Maus eine zeitlang im Bild war, war - natürlich! - kein Versehen aus Unkenntnis, sondern sollte den Stubentiger vom Kollegen anlocken. Hat leider nicht geklappt.Auf alle Fälle danke für die Einladung. Das Meeting hat für mich einen merkwürdigen Nachgeschmack - so, als wenn man "Blut geleckt" hätte.
Ich fand es schon interessant; auch der lockere und nicht immer bierernste Umgang im Meetung - cool.Nun, Spaß beiseite:
Ich habe mir einige Notizen gemacht, werden mir Deine Zusammenfassung ansehen und könnte auf Wunsch den einen oder anderen Gedanken beisteuern. Es gab bei den Themen einige Schnittmengen mit meiner früheren Tätigkeit.Dazu die Frage:
- Soll das hier ins Forum gepostet werden (der Text könnte länger werden) oder gibt es andere Kommunikationskanäle zur "Stammtruppe"? Mit @rene55 habe ich z.B. Mail-Kontakt, das erleichtert oft einiges und nervt andere nicht.
- Als Teams-Newbee: Gibt es eine Möglichkeit, Teams irgendwie zu testen, zu "trainieren"?
Mit dem Tablet war das gestern nicht so optimal, das Mikro der Webcam wurde auf dem Desktop nicht erkannt, etc.
Wobei: Die meisten Mikros waren eh stumm geschaltet, also wäre das dann eventuell nicht das Problem.
Bis denne also.
-
@pi-ter sagte in Meeting für ioBroker Core/Dev/Admin 21.02.24 20:30:
Soll das hier ins Forum gepostet werden (der Text könnte länger werden) oder gibt es andere Kommunikationskanäle zur "Stammtruppe"? Mit @rene55 habe ich z.B. Mail-Kontakt, das erleichtert oft einiges und nervt andere nicht.
Schön das es Dir - und hoffe auch den anderen 20+ - gefallen und Spass gemacht hat.
Wenn es eher 1:1 Themen sind dann gern per E-Mail oder - für mich gerade persönlich besser zu managen - Telegram oder Discord (mit Preferenz zu Discord, da kann ich Nachrichten wieder als ungelesen markieren das ich sie nicht vergesse, das hat Telegram nicht
... aber Telegram geht auch). -
@apollon77 sagte in Meeting für ioBroker Core/Dev/Admin 21.02.24 20:30:
Wenn es eher 1:1 Themen sind dann gern per E-Mail oder - für mich gerade persönlich besser zu managen - Telegram oder Discord (mit Preferenz zu Discord, da kann ich Nachrichten wieder als ungelesen markieren das ich sie nicht vergesse, das hat Telegram nicht
... aber Telegram geht auch).Dann bleibt nur Mail, wäre mir auch am liebsten.
Die Mailadressen können wir doch bestimmt über den Chat austauschen. Ich versuche es einfach. -
@apollon77 sagte in Meeting für ioBroker Core/Dev/Admin 21.02.24 20:30:
ioBroker kann, und wird bereits, in der Industrie und Wissenschaft und weiteren Umfeldern eingesetzt, wie........
Das kann ich bestätigen.
Ich bin der Junior in einer (kleineren) Offsetdruckerei.Hier läuft der ioborker schon für verschiedene Dinge.
Zb Maschinenüberwachung mit Benachrichtigungen, Papierbestellungen oder oder zum auswerten von Exceldateien zur Versandoptimierung. -
In dem Zuge kann ich jeden mit solchen Usecases wo ioBroker im Einsatz ist gern bitten mi da mal ein paar Eckpunkte o.ä. als E-Mail an iobroker@fischer-ka.de zu senden weil ichgerade sammle für einen c't Artikel
-
@pi-ter sagte in Meeting für ioBroker Core/Dev/Admin 21.02.24 20:30:
Dass meine Maus eine zeitlang im Bild war, war - natürlich! - kein Versehen aus Unkenntnis, sondern sollte den Stubentiger vom Kollegen anlocken. Hat leider nicht geklappt.
Mein Kätzchen ist gut erzogen
