Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30

[ldittmar]

Themenliste für Mai:

• Jeder kann kurz sagen woran er gerade arbeitet (alle Anwesenden) - immer nur kurz, die Zeit rennt
  • Maintenance Script für Docker Container - Ideen und Feedback? (andre)
  • JS 3.4 soll erkennen ob ioBroker im Docker läuft
  • JS-Controller 3.3.10 kommt demnächst
  • Warnungen von Adaptern sollen gefixt werden
  • Tears für die Adapter werden gesetzt - Tear 1 - Logik Schicht wird als erstes gestartet, Tear 2 - Daten Lieferung und wird als zweites geliefert, Tear 3 - Visualisierung Schicht wird zum Schluss gestartet - wenn nichts gesetzt wird, dann ist man automatisch in 3 drin https://github.com/ioBroker/ioBroker.js-controller/issues/1298
  • Weblate wird gut angenommen
• ioBroker Community Initiatives - aktueller Stand (Apollon77)
• Neuste Version des Adapter Creator (AlCalzone)
  • https://github.com/ioBroker/create-adapter/blob/master/CHANGELOG.md
• Statistik/Analytik-Plattform (AlCalzone)
  • MongoDB Charts
  • ist im Z-Wave Adapter eingebaut
  • siehe https://forum.iobroker.net/topic/44524/meeting-für-iobroker-core-dev-admin-19-05-21-20-30/16
• Liste von Adaptern die nicht mehr weiterentwickelt oder gepflegt werden - Übernahme durch Community? (Sigi234)
  • Adaptern die nicht mehr funktionieren aus dem Stable entfernen
  • ggf. nicht mehr funktionierende Adaptern aus der Liste entfernen
  • ioBroker Issue als Tracking Issue erstellen
• Adapter Documentation Template Repository (Dutchman) Verschoben auf nächsten Monat
• jsdeliver CDN für datenintensiven Resourcen verwenden (UncleSam)
  • https://forum.iobroker.net/topic/36211/bessere-kontrolle-von-sources-dist-stable-dank-jsdelivr
  • Brainstorming
• Projekt CHIP - Jetzt Matter (UncleSam)
  • https://www.macerkopf.de/2021/04/18/projekt-chip-ende2021-zertifizierung-smart/
• Tests und Release (JeyCee) Verschoben auf nächsten Monat
  • Ideensammlung? Kleine Diskussion... Verbesserungsvorschläge
• Admin 5 ist bald fertig
• ioBroker.devices wird verbessert - Issues anlegen - Danach wird
• Shedule Adapter

Das Meeting findet über Microsoft-Teams statt. Weitere Details hier: https://forum.iobroker.net/topic/43355/meeting-für-iobroker-core-dev-admin-21-04-21-20-30/12

Der Link zum Treffen wird am Tag hier gepostet werden.

Wer Themen zum Meeting hat, einfach hier drunter schreiben und wir tragen es ein. Die Meetings werden auf 2 Stunden begrenzt. Themen die nicht behandelt werden können, verschieben wir auf nächsten Monat. Aber es kann durchaus passieren, dass Diskussionen auch nach dem Ende weiter geführt werden.

Alles was im Meeting besprochen wurde, wird hier unterhalb der Themen, stichpunktweise dokumentiert.

Das übernächste Meeting wird turnusgemäß am 16.06.21 stattfinden.

Apollon77 created this issue in ioBroker/ioBroker.js-controller

closed Define Tiers for some default adapters #1298

[UncleSam]

@ldittmar Kannst du bitte noch den Adapter Creator rüber nehmen, ich konnte zwar meinen Teil letzte Woche erzählen, aber @AlCalzone hat auch noch ein paar Sachen zu erzählen

[AlCalzone]

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

Themenliste für April

Mai?

[ldittmar]

@alcalzone sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

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

Themenliste für April

Mai?

Das war so geplant... wollte nur sehen wer genau aufpasst.

[UncleSam]

Langsam sollten wir uns wohl mal über das Projekt CHIP unterhalten. Es wäre schön, wenn wir von den ersten wären, die CHIP direkt unterstützen, wenn die erste Hardware gegen Ende des Jahres herauskommt. Es bringt auch nichts, wenn drei Entwickler parallel daran arbeiten.

[Jey Cee]

Thema Testing und release:
Wir liefern Standardmässig Tests mit dem Adapter Creator aus. Soweit ich das bisher verstehe wird das vorallem dazu genutzt um die Tests Automatisiert mit GH Actions (oder noch travis) aus zu führen.
Aber man kann diese Tests auch Lokal Ausführen, wobei ich mir sicher bin das macht bisher kaum jemand.

Dazu hatte ich heute folgende Gedanken:

1. Die Tests sollten bereits Lokal durchgeführt werden bevor auf Github gepusht wird.
2. In der iobroker Test suite können sowohl nodejs als auch js-contoller version die getestet werden fest gelegt werden. Damit wäre es möglich die Adapter Automatisiert auf Lauffähigkeit zu überprüfen und diese Information zum Beispiel in der (io)package.json ein zu tragen (falls der Entwickler hier noch nichts definiert hat).
   Dazu muss der Test dann wohl lokal ausgeführt werden.
   Desweiteren muss die Vorgabe der Höchsten und niedrigsten version der jeweiligen Komponente immer durch das Kern Team vorgegeben werden und entsprechend in der Test suite hinterlegt sein.
3. Das release skript zur vorgegebenen Veröffentlichungsmethode machen. (Wie geprüft wird ob es verwendet wurde muss dann geklärt werden)
   Das release skript kann vor dem eigentlichen release, also lokal, die Tests ausführen und den vorgang abbrechen wenn noch Fehler im Adapter sind.
   Außerdem müssen dann die GH Actions nicht mehr bemüht werden um ein npm release zu machen das kann dann auch lokal erfolgen.
4. Tests die sich nur auf den Adapter code beziehen können in der Test suite ausgeführt werden und der Adapter checker muss das nicht mehr übernehmen.

Der Vorteil neben der Vereinfachten Handhabung den ich hier sehe ist die Tatsache das jeder Adapter die Information mit liefert mit welcher nodejs und js-controller version er Kompatibel ist.

Soweit meine Gedanken dazu. Das ganze muss nicht unbedingt beim kommenden Meeting besprochen werden, aber ich wollte es mal auf die Agende für die nahe zukunft setzen.

[AlCalzone]

@jey-cee sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Außerdem müssen dann die GH Actions nicht mehr bemüht werden um ein npm release zu machen das kann dann auch lokal erfolgen.

Da würde ich widersprechen. Es kommt öfter mal vor, dass ein Adapter nur auf einem OS oder unter einer bestimmten Node-Version nicht funktioniert. Das kannst du offline effektiv fast nicht testen.
Zumal GitHub Actions den Vorteil haben, dass die Tests auf einem frischen System ausgeführt werden, ohne dass zufällig eine dependency noch in den node_modules rumlungert, die aus package.json eigentlich schon entfernt wurde, etc.

[UncleSam]

@jey-cee sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Thema Testing und release:

Ich weiss nicht, ob dieser Thread hier der richtige Ort ist, um das zu besprechen, aber ich möchte gerne meine Meinung zu deinen Aussagen geben.

Wir liefern Standardmässig Tests mit dem Adapter Creator aus. Soweit ich das bisher verstehe wird das vorallem dazu genutzt um die Tests Automatisiert mit GH Actions (oder noch travis) aus zu führen.
Aber man kann diese Tests auch Lokal Ausführen, wobei ich mir sicher bin das macht bisher kaum jemand.

Ja, kann man. Wobei es mir eigentlich oft reicht, wenn ich von GitHub ein "OK" bekomme (klar, wenn ich Tests schreibe, dann teste ich die auch lokal).

Dazu hatte ich heute folgende Gedanken:

1. Die Tests sollten bereits Lokal durchgeführt werden bevor auf Github gepusht wird.

Siehe oben.

2. In der iobroker Test suite können sowohl nodejs als auch js-contoller version die getestet werden fest gelegt werden. Damit wäre es möglich die Adapter Automatisiert auf Lauffähigkeit zu überprüfen und diese Information zum Beispiel in der (io)package.json ein zu tragen (falls der Entwickler hier noch nichts definiert hat).

Das würde ja bedeuten, dass du alle Node Versionen und alle Betriebssysteme bei dir installiert haben müsstest. Ich lasse das lieber GH Actions erledigen, dann habe ich das Resultat für 9 OS/Node Kombinationen innert ein paar Minuten ohne einen Finger zu krümmen.

Dazu muss der Test dann wohl lokal ausgeführt werden.
Desweiteren muss die Vorgabe der Höchsten und niedrigsten version der jeweiligen Komponente immer durch das Kern Team vorgegeben werden und entsprechend in der Test suite hinterlegt sein.

Weshalb? Wenn ein Adapter zB nur ab Node 14 läuft, ist das der Entscheid des Entwicklers. Klar, das muss richtig in der (io-)package.json stehen, aber das war's schon.

3. Das release skript zur vorgegebenen Veröffentlichungsmethode machen. (Wie geprüft wird ob es verwendet wurde muss dann geklärt werden)

Das finde ich eine super Idee. Im Moment kann das der Adapter Creator noch nicht, aber es gibt ein Issue dazu.

Das release skript kann vor dem eigentlichen release, also lokal, die Tests ausführen und den vorgang abbrechen wenn noch Fehler im Adapter sind.

Weshalb lokal? Das geht doch viel besser auf GitHub Actions.

Außerdem müssen dann die GH Actions nicht mehr bemüht werden um ein npm release zu machen das kann dann auch lokal erfolgen.

Was heisst "bemühen"? Genau für solche Sachen sind doch CI (Continuous Integration) Lösungen. Ich würde so viel wie möglich auf die CI auslagern, sogar den Release; zumindest wenn noch etwas kompiliert werden muss (TypeScript und/oder React), ist so garantiert, dass immer der neuste, sauber kompilierte Code released wird. So arbeitet jede moderne Software Entwicklung!

4. Tests die sich nur auf den Adapter code beziehen können in der Test suite ausgeführt werden und der Adapter checker muss das nicht mehr übernehmen.

Der Adapter Checker überprüft doch nur den Inhalt von GitHub, der führt keine Tests aus.

Der Vorteil neben der Vereinfachten Handhabung den ich hier sehe ist die Tatsache das jeder Adapter die Information mit liefert mit welcher nodejs und js-controller version er Kompatibel ist.

Das scheint mir ein etwas verkehrter Schluss: wenn ich die Standard Tests mit allen Umgebungen (OS und Node Matrix) auf GitHub ausführe, weiss ich ja ganz genau, dass mein Adapter überall dort läuft. Und wenn nicht, kann ich das ja entsprechend in der (io-)package.json eintragen.

Soweit meine Gedanken dazu. Das ganze muss nicht unbedingt beim kommenden Meeting besprochen werden, aber ich wollte es mal auf die Agende für die nahe zukunft setzen.

Ich finde die Diskussion wichtig und gut, könnte aber in einem dev Meeting etwas ausufern. Vielleicht ein separates Meeting mit allen, die interessiert sind. Wenn dann eine Entscheidung getroffen wurde, kann man die im dev Meeting kommunizieren.

[UncleSam]

@unclesam sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Langsam sollten wir uns wohl mal über das Projekt CHIP unterhalten.

Neu heisst die Plattform nun Matter.

[Jey Cee]

@unclesam sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Weshalb? Wenn ein Adapter zB nur ab Node 14 läuft, ist das der Entscheid des Entwicklers. Klar, das muss richtig in der (io-)package.json stehen, aber das war's schon.

Weil dann vor jedem release gegen die Aktuellen vorgaben getestet wird. Und es ist eine unnötige Arbeit vor jedem release zu prüfen was gerade Aktuell ist und was im Testing hinterlegt ist.
Mit dem "das wars schon" machst du es dir doch etwas zu einfach, Nehmen wir alle "das wars schon" Zusammen, haben wir plötzlich für einen release 30(?) Minuten Zusätzliche Arbeit wenn man immer alles durchgeht.

@unclesam sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Der Adapter Checker überprüft doch nur den Inhalt von GitHub, der führt keine Tests aus.

Das mag richtig sein, er prüft aber auch unnötiger weise ob die package files Korrekt sind. Es wäre Sinnvoller diese Tests schon vorher zu machen. Wenn ich einen Adapter ins Beta/Stable bekommen will wird das erst dort geprüft, was Zusätzliche Arbeit für den review Prozess bedeutet.
Davon abgesehen könnten eigentlich alle Überprüfungen die der Checker macht direkt mit GH Actions ausgeführt werden. Das sparrt einen weiteren Schritt.

@unclesam sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Das scheint mir ein etwas verkehrter Schluss: wenn ich die Standard Tests mit allen Umgebungen (OS und Node Matrix) auf GitHub ausführe, weiss ich ja ganz genau, dass mein Adapter überall dort läuft. Und wenn nicht, kann ich das ja entsprechend in der (io-)package.json eintragen.

Wieder ein Zusätzlicher Schritt den ich extra machen muss. Ich versteh nicht wieso ich das selber machen muss wenn das Testing doch das Ergebnis liefert und auch gleich Eintragen kann.
Deine Annahme impliziert auch das jeder Entwickler das immer macht, das glaube ich aber nicht.
Aber die Eigentliche Idee dahinter ist das Explizit erkennbar ist mit welchen Versionen es auf jeden Fall funktioniert. Jetzt ist es so das man es nie wirklich weis weil das nirgendwo angezeigt wird, bestenfalls steht es in der Readme.
Ist die Information hinterlegt kann man sie abrufen und im Admin anzeigen.

So wie es zum Beispiel die Foren Software macht:

@unclesam sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Ja, kann man. Wobei es mir eigentlich oft reicht, wenn ich von GitHub ein "OK" bekomme (klar, wenn ich Tests schreibe, dann teste ich die auch lokal).

Ganz ehrlich da schau ich nicht immer drauf. Das Ergebnis ist für mich nur von belang wenn es einen Fehler gibt und es sich um ein release handelt, genau dann will ich benachrichtigt werden.

@alcalzone sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Es kommt öfter mal vor, dass ein Adapter nur auf einem OS oder unter einer bestimmten Node-Version nicht funktioniert. Das kannst du offline effektiv fast nicht testen.

Da muss ich dir recht geben.

[AlCalzone]

@jey-cee sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Ich versteh nicht wieso ich das selber machen muss wenn das Testing doch das Ergebnis liefert und auch gleich Eintragen kann.

Aber das Ergebnis reicht eben nicht, weil du es interpretieren musst. @foxriver76 hatte vorhin erst einen Fall, wo in den package Skripten node_modules/.bin/mocha statt nur mocha stand und der Test unter Node 16 fehlgeschlagen ist. Nicht etwa weil es nicht lief, sondern weil das mitgelieferte npm 7 die Binaries woanders ablegt.

Und es ist eine unnötige Arbeit vor jedem release zu prüfen was gerade Aktuell ist und was im Testing hinterlegt ist.

Dann mach's halt nicht vor jedem Release, sondern dann wenn es im Dev-Chat mal wieder heißt: "hey, Node XYZ ist bald LTS" - so ca. jedes 1/2 Jahr.

Davon abgesehen könnten eigentlich alle Überprüfungen die der Checker macht direkt mit GH Actions ausgeführt werden. Das sparrt einen weiteren Schritt.

Stimme ich dir zu - geht grundsätzlich auch. PR welcome: https://github.com/ioBroker/testing/blob/master/src/tests/packageFiles/index.ts

[Garfonso]

@jey-cee said in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Aber die Eigentliche Idee dahinter ist das Explizit erkennbar ist mit welchen Versionen es auf jeden Fall funktioniert.

Wenn jeder Adapter nur mit einer Node Version sicher Funktioniert hat man aber schnell die Situation, dass man bei 3-4 "akzeptablen" Node Versionen vor dem Problem steht, dass man sich entscheiden muss...?? Das macht es doch nicht besser...
Aktuell sehe ich das so, wenn man das Testing per Github Actions mit der Matrix aus Node-Version und OS ok pflegt (wie @AlCalzone sagt, reicht es da zweimal im Jahr reinzugucken, öfter mache ich das auch nicht), dann kann man davon ausgehen, dass alle Adapter auf allen Node-Versionen laufen außer es steht in einer der Config-Dateien ein requirement von einer anderen Version.
Und das musst du dann ja da als Entwickler auch nur eintragen, wenn deine Tests auf Github nicht mehr durchlaufen und da immer nur eine Version schief geht...

Ich muss sagen, dass ich das, insbesondere mit dem relase-script zusammen und automatischen npm build sehr komfortabel finde. Ich mache npm run release -> das kümmert sich um alles und ich bin fertig. Später bekomme ich eine E-mail von NPM, dass ein neues Paket veröffentlicht wurde oder eine E-Mail von Github, dass es Fehler beim Test gab und ich kann ggf. reagieren (PR für stable oder fixen und neu versuchen).

[UncleSam]

@garfonso sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Ich muss sagen, dass ich das, insbesondere mit dem relase-script zusammen und automatischen npm build sehr komfortabel finde. Ich mache npm run release -> das kümmert sich um alles und ich bin fertig. Später bekomme ich eine E-mail von NPM, dass ein neues Paket veröffentlicht wurde oder eine E-Mail von Github, dass es Fehler beim Test gab und ich kann ggf. reagieren (PR für stable oder fixen und neu versuchen).

My words! Geht mir auch so.

Und wartet auf die (über)nächste Version von iobroker.dev... da habe ich noch ein paar Tools in Planung, die einen Release mit dem Release Skript noch einfacher machen - stay tuned!

[andre]

Moin,
da ich nun auch weiß, dass ich heute Abend wohl dabei sein kann, hätte ich nochmal ein Thema zu Docker. Passt vielleicht in das "woran er gerade arbeitet".
Ich habe vor einiger Zeit aus lauter Faulheit und weil der Docker Container immer "unhealthy" wird wenn ich den js-controller update ein (bisher unglaublich simples) maintenance script eingebaut. Würde euch dazu gerne mal die bisherige Funktion zeigen und mir Feedback abholen ob das eine sinnvolle Automatisierung für die Allgemeinheit ist, oder ob es doch besser undocumented bleiben sollte.
Also vielleicht als Unterpunkt zum ersten Punkt...

• Maintenance Script für Docker Container - Ideen und Feedback? (andre)

MfG,
André

[Dutchman]

Link zum Teams Meeting : https://teams.microsoft.com/l/meetup-join/19%3Ameeting_ZjYyY2JiMzktZThhZi00MDlhLTk1ZmItNjg4MDcwZjEyMTU5%40thread.v2/0?context={"Tid"%3A"acd9fe6e-0a90-4965-877c-b73cabe80b83"%2C"Oid"%3A"89f19cbc-f979-40b1-82a8-98df88138249"}

[AlCalzone]

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

Statistik/Analytik-Plattform

Original-Projekt mit Installationsanleitung:
https://github.com/robertsLando/statistics-server

Mein Fork mit ergänzten Collections:
https://github.com/zwave-js/statistics-server

Screenshots der Oberfläche:

Code zum Reporten von Statistiken:
https://github.com/zwave-js/node-zwave-js/blob/master/packages/zwave-js/src/lib/telemetry/statistics.ts

[David G.]

Hallo,

ich melde mich mal hier im Thread, weil ich absolut nicht weiß, wem ich eine PN schreiben soll zu meinem Anliegen.

Vom Titel des Threads vermute ich, dass hier irgendjemand der richtige Ansprechpartner ist.

Gerne würde ich das "Projekt" ioBroker unterstützen.
Meiner Meinung nach ist es immer gut, wenn man Gabenorienorientiert bzw nach seinen Möglichkeiten helfen kann.

Ich bin der "Junior" in der elterlichen Druckerei mit angeschlossenen Werbeagentur.
Ich bin der Betriebsleiter im Bereich Druck und Produktion.

Deshalb würde ich, wenn Bedarf besteht, gerne mit Druckprodukten jeglicher Art Hilfe anbieten.

Im Moment hab ich keine Ahnung, wo ihr sowas brauchen könntet.
Hoffentlich habt ihr direkt eine gute Idee.

Sollte hier keiner Mitlesen, für den es relevant ist, kann es ja ggf. jmd weiterleiten.

[UncleSam]

@david-g Besten Dank für dein Angebot! Selbstverständlich sind wir immer froh um Unterstützung. Ich denke, in diesem Fall wären @Bluefox und @apollon77 die richtigen Ansprechpartner.