NEWS

Ich würde ein paar Worte zu diesem Thema anbieten:

Kommende Änderungen bei npm (November)

Abkündigung dauerhafter (classic) Token trusted deployment Anpassungen @iobroker/testing-action-deploy und test-and-release.yml workflow

NOTES FOR NEXT MEETING

Vorschlag: Adapter creator sollte die Erstellung neuer (!) Adapter mit materialize UI nicht mehr anbieten da jsonConfig bereits ausreichend Funktionalität anbietet und React für komplexe UIs verfügbar ist. Insbesodere neuen Devs sollte nicht zu vile Optionen angeoten werden da dies nur verwirrt.

https://github.com/ioBroker/create-adapter/issues/1187

Wäre zu besprechen.
In dem Zusammenhang kann man auch das Thema maetrialize Zukunft kurz anreißen.

mcm1957 created this issue in ioBroker/create-adapter open Remove option to select materialize adminUI #1187

@ldittmar

Wie sieht es mit der offiziellen Empfehlung für Node 22 aus ?
https://forum.iobroker.net/topic/80970/meeting-für-iobroker-core-dev-admin-21-05-25-20-30/16
Welche Probleme sind noch bekannt und Grund für weiteres Delay?
Yahka sollte gelöst sein. (https://github.com/jensweigele/ioBroker.yahka?tab=readme-ov-file#115-2025-07-09)

@ldittmar - Ich schaffe es heute aus persönlichen Gründen nicht zum Meeting. Daher hier ein kurzer Status von mir.
Nachdem OAUTH2 in den Spotify Adapter integriert wurde ( Danke an BlueFox ) und er diesen auch gleich in TypeScript umgesetzt hat kämpfe ich noch mit der Implementation.
So wie ich das sehe ist die OAUTH2 Implementation gut und funktioniert. Die aktuell vorhandenen Probleme habe ich wohl selbst vor ein paar Monaten bei der Umstellung von axios verusacht.
Sollte jemand Zeit "übrig" haben ( ich weiss - Guter Witz ) dann nehme ich Hilfe gerne an, ansonsten bin ich da sehr ehrgeizig und denke das ich bis zum nächsten Meeting fertig bin.

Und hier noch die CharGPT Zusammenfassung von Denis:

ioBroker Entwicklermeeting Bericht - 21. Mai 2025 1. Matter-Update: Fast 500 Installationen erreicht; Fokus derzeit auf Stabilität und reduziertem RAM-Verbrauch. Unterstützung für weitere Gerätetypen wie Klimaanlagen geplant. Untersuchung von Problemen mit Aqara Türsensoren läuft aktuell. 2. Rollen- und Typdetektor: Fehler mit Rolle Indicator.Error behoben. Verbesserte Geräteerkennung, um Mehrfacherkennung eines Geräts zu vermeiden (z.B. Homematic Kanäle). Priorisierung und Ausschlussmechanismen für optimale Typenerkennung hinzugefügt (besonders für Zigbee-Adapter). 3. TypeScript Widgets für VIS-2: Widgets können jetzt in TypeScript entwickelt werden. Erste Umstellungen (Material, Jägerdesign) bereits erfolgt. Erfordert neue Version von VIS-2 (2.12.9), bald stabil verfügbar. Entwickler werden zur Migration auf TypeScript ermutigt für einfachere Verwaltung und Konsistenz. 4. OAuth2 Service: Vorschlag eines zentralen OAuth2-Services für Adapter wie Spotify, Dropbox usw. Vereinfacht die Authentifizierung und Benutzerkonfiguration deutlich. Aktuelle Implementierungen existieren bereits für Google Drive und Dropbox, weitere Anbieter sind geplant. 5. Regionale Adapteridentifikation: Verwendung von ISO 3166-2 Codes zur Identifikation regionsspezifischer Adapter vorgeschlagen. Könnte die Relevanz und Benutzerfreundlichkeit je nach geografischem Standort der Nutzer erhöhen. Erste Implementierungen für die Filterung im Admin-Interface in Betracht gezogen. 6. Node.js Updates: Offizielle Empfehlung, Nutzerinstallationen auf Node.js 22 zu aktualisieren. Node.js 18 ist End-of-Life; Node.js 24 Tests sind erwünscht, aber noch nicht offiziell empfohlen. Bekannte Kompatibilitätsprobleme mit bestimmten Adaptern, insbesondere solchen mit nativen Abhängigkeiten. 7. Benachrichtigungen und Verwaltung der Einstellungen: Diskussion über die Angemessenheit und Konfiguration von Benachrichtigungen. Vorschlag einer zentralisierten Kontrolle der Benachrichtigungen über das Admin-Interface. Verstärkter Einsatz von JSON-Konfigurationen für flexible Adaptereinstellungen empfohlen. Fazit:

Im Meeting wurden bedeutende Verbesserungen in Benutzerfreundlichkeit, Flexibilität der Adapterentwicklung und Backend-Infrastruktur behandelt. Wichtige Initiativen umfassen bessere Nutzererfahrung durch regionale Adapterfilterung, verbesserte Typdetektionsmechanismen, zentrale OAuth2-Authentifizierungsdienste und breitere Einführung von TypeScript für die Widget-Entwicklung.

Hab das Meeting leider verpasst.

@ldittmar sagte in Meeting für ioBroker Core/Dev/Admin 16.04.25 20:30:

Integration von externen "Geräte-Libraries" via "Virtuelle Adapter" (UncleSam)

Lange Diskution - wie könnte man sowas abbilden?

Ist den bei der Diskussion was rum gekommen auf dessen Grundlage man die Frage angehen kann?

@feuersturm sagte in Meeting für ioBroker Core/Dev/Admin 19.03.25 20:30:

Die Stichpunkte sind doch im ersten Beitrag enthalten.

ah ok, hatte das anders aufgefasst!
Alles gut 🙂

@ticaki Ah, ok sry. Danke für die Info.

@apollon77

sorry, tut mir leid, dass ich hier wohl wenig Diplomatisch meine persönlichen Empfindungen wieder gegeben habe.. ich wollte niemand auf die Füße treten.
Ich bin da manchmal leider ziemlich ein Trampel 😞

Da gibts noch Luft nach oben..

@mcm1957 said in Meeting für ioBroker Core/Dev/Admin 20.11.24 20:30:

@ldittmar
Nur kurze Info
Migration auf EsLint 9, Info über Migration Guide und @iobroker/eslint-rules.

Foxriver76 und Bluefox haben eine zentrale EsLint Konfiguration erstellt die für alle Core Adapter zum Einsatz kommt und für alle sonstigen Adapter empfohlen wird. Da die derzeit weit verbreitete EsLint 8 Version outdated ist, bietet es sich an beim Umstieg auf EsLint diese zu verwenden. Damit entfällt auch die lokale Installation und das Update von eslint / prettier j Adapter. Einen Migration Guide gibt's hier:

https://github.com/ioBroker/ioBroker.eslint-config/blob/main/MIGRATION.md

@jey-cee danke

@ldittmar Thema für das nächste Meeting
Zukunft Feiertag's Adapter:

Aktuell ohne Maintainer unter den Top 100 Trotz einfacher Konfiguration wäre die Migration nach JSONConfig Aufwändig, auf grund der Verstrickung von Config und Backend halb Internationlisiert (objekte werden in Deutsch und Englisch angelegt, Übersetzungen vorhanden, keine Länder Auswahl)

@mcm1957 Im Prinzip geht es darum, dass die Bedienbarkeit und Lesbarkeit auf allen Devices gegeben sein muss.
Egal ob großer Gamingmonitor oder ein Ipad, oder Smartphone.
Der Trend bei Usern geht ganz klar dahin, dass sie bequem am Abend auf dem Sofa mal eben was in ihrem ioBroker anpassen konfigurieren oder testen wollen. Das ganze halt auch mehr und mehr mit dem Smartphone.

Und genau hier sollte ioBroker zu Mitbewerbern dringend aufholen...
Aus reiner Entwicklersicht sind solche Dinge sicher nicht nachzuvollziehen, den ich sitze nicht am Smartphone und bastle an meinem ioBroker rum, aber bei den Endnutzern ist dies ein ganz entscheidender Aspekt.

Bitte sucht euch einem Termin für ein Frontend Meeting aus: https://forum.iobroker.net/topic/77012/umfrage-meeting-frontend-responsive-design

Thema: Device Manager Demo als JSONConfig Komponente ( @Bluefox React Komponente? )

@mcm1957 sagte in Meeting für ioBroker Core/Dev/Admin 19.06.24 20:30:

meines Wissens nach funktionierenden nuki-extended

ja ist korrekt und dieser funktioniert auch

Scheinbar haben wir bei der Planung des Mai-Meetings die Pfingstferien übersehen. Da viele unserer Entwickler in dieser Zeit im Urlaub sind und somit nicht am Meeting teilnehmen können, haben wir beschlossen, es dieses Mal ausfallen zu lassen. Das nächste Meeting wird wie gewohnt am 19.06. stattfinden.

kurzes Update zur App kann ich auch geben

@ldittmar sagte in Meeting für ioBroker Core/Dev/Admin 20.03.24 20:30:

Moin,

erstmal danke, dass ich wieder teilnehmen durfte.

Wie ihr sicher bemerkt habt, fällt mir die schriftliche Kommunikation mit Euch leichter, als in der noch ungewohnten Teams-Sitzung, noch dazu nach einem besch... Tag

Egal...

Da ich das Thema Quältext in der Doku nun mal angestoßen habe, kann und will ich mich nicht klamm heimlich verdrücken. Heißt: Ich bleibe am Thema dran. Ein valider Output sollte angestrebt werden.
Ob meine Kenntnisse und Erfahrungen, die aus der Webentwicklung mit ganz anderen Präferenzen stammen, dann letztlich reichen werden, muss sich zeigen.

Gleichzeitig stimme ich @mcm57 zu, dass der Inhalt der Doku Priorität hat. Daher bleibe ich auch bei meinem Hilfsangebot, die Doku weiter zu entwickeln. Zusammen mit Ingo gab es bereits erste Änderungen, die aber erst noch aktiviert werden müssen. Danach mache ich dann weiter.

Einige Dinge waren in der Auswertung des Meetings für mich intressant:

showdown.js habe ich mir bereits herunter geladen und auch markdown-it habe ich gefunden.

Die Formulierung ...bzw was neueres finden lässt bei mir die Vermutung aufkommen, dass wir wohl nicht zwingend auf showdown.js festgenagelt sind und auch andere Konverter möglich wären.

Was mir bei diesem Themenkomplex fehlt, ist das Wissen um die Abläufe im Front- und Backend:

Wo werden getätigte Texteingaben (zwischen-)gespeichert, filebasiert oder DB? Wann und an welcher Stelle greift der Konverter MD zu HTML? Wie, wodurch bzw warum wird der HTML-Output erst bei Seitenaufruf generiert? Wie erfolg(te) die Erzeugung der Styles? Vorgaben manuell, dann scriptgesteuert?

Und natürlich die Verknüpfung mit Github...

Nach erstem kurzem Ausflug zu showndown muss der Fehler nicht unbedingt im Konverter zu finden sein.
Möglich, dass die Verwurstelung des HTML-Outputs im Zusammenhang mit weiteren nachgeschalteten Scripten steht oder auch aus der etwas merkwürdigen Gestaltung der Styles herrührt.

Kurz:
Wenn sich Jemand findet, der Lust und vor allen Dingen Zeit hat, mir die vielen Fragen zu beantworten, die ich in dem Zusammenhang habe, würde ich mich freuen.

In diesem Sinne ein schönes WE zunächst.