UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[mcm1957]

Neue Konstante für FORBIDDEN_CHARS

Die derzeitige FORBIDDEN_CHARS erlaubt einige Zeichen die bekanntsmassen Probleme bereiten (z.B das Leerzeichen). Wir sollten daher überlegen eine neue Konstante zu definieren die so restriktiv ist dass wirklich nur gewünschte Zeichen in einer ID vorkommen. Diese sollte für NEUE Adapter verwendet werden. Ob nun eine Variable oder gleich od ev. zusätzlich eine Replace Function zentral angeboten werden soll wäre zu besprechen.

Zusätzlich könnte man überlegen im adaptercode basierend auf z.B. einer Info in io-package.json strenger zu prüfen.

[simatec]

Ich würde mir für das nächste Meeting mal wieder ein paar Statistiken wünschen ... Dieses Thema fand ich immer sehr interessant und aufschlussreich.

Vielleicht passt es ja mit rein

[Gaspode]

Mal wieder das Randthema Windows Installer:
Auf Linux Seite tut sich ja derzeit viel in Bezug auf Controller Update (inzwischen verfügbar), Node.js und Linux System Updates (in Arbeit) per GUI. Letzteres ist für Windows wohl eher unnötig und Node.js Update kann der Installer bereits.
Ich bin beim Controller Update jetzt unschlüssig: Sollte das auch in die GUI, oder soll ich es lieber in den Installer einbauen und in die GUI kommt ein Hinweis, man soll den Installer verwenden?

[arteck]

@andre sagte in Meeting für ioBroker Core/Dev/Admin 21.02.24 20:30:

Es wird, insbesondere im Forum, häufig die Meinung vertreten, dass sich das ioBroker-Projekt nur an fortgeschrittene Benutzer richten sollte,

nö.. aber .. es wird vermehrt nach Themen gefragt die schon zig mal schon beantwortet wurden..
das ist das Problem... "ICH hab ein problem und DU musst mir jetzt helfen"

aber ja ich freue mich auf die Diskussion

[Codierknecht]

@arteck sagte in Meeting für ioBroker Core/Dev/Admin 21.02.24 20:30:

nö.. aber .. es wird vermehrt nach Themen gefragt die schon zig mal schon beantwortet wurden..
das ist das Problem... "ICH hab ein problem und DU musst mir jetzt helfen"

Das dürfte eine Auswirkung des beliebten Themas "Dokumentation" sein.

[apollon77]

lasst uns bitte im Dev-Meeting Diskutieren!

[maloross]

Kurze Verständnisfrage: Kann ich als Zuhörerin teilnehmen oder ist das nur für Entwickler?

[Thomas Braun]

@maloross sagte in Meeting für ioBroker Core/Dev/Admin 21.02.24 20:30:

Kurze Verständnisfrage: Kann ich als Zuhörerin teilnehmen oder ist das nur für Entwickler?

Das ist ein offenes Meeting.

[apollon77]

@maloross Jeder Interessierte kann nur zuhören oder sich auch aktiv beteiligen. Themen werden vorab gesammelt damit es dann nicht zu Chaotisch wird.

[maloross]

@thomas-braun @apollon77
danke - ist bestimmt interessant, ein paar Einblicke zu erhalten. Ich bleibe auch schweigsam - versprochen!

[ldittmar]

@simatec nächstes mal ist schlecht, aber ich kann es für übernächstes Mal was vorbereiten;-)

[simatec]

@ldittmar Das wäre Klasse

[mcm1957]

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.

[apollon77]

@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

[Jey Cee]

@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

[apollon77]

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 !!

[simatec]

@apollon77 Ich könnte zur Not auch noch ein Meeting in Teams aufmachen.

[wcag22]

@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 Threema

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

[apollon77]

@pi-ter So schlimm wars gar nicht gg

[apollon77]

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.