Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[apollon77]

Ich habe noch https://github.com/ioBroker/ioBroker.discovery/issues/299 als Fallout von Solingen hinzugefügt

[Dutchman]

@apollon77 sagte in Meeting für ioBroker Core/Dev/Admin 29.11.23 20:30:

@jey-cee Man müsste sich nur was überlegen wie man damit umgeht wenn der adapter gerade nicht läuft ... bzw ist ja auch die Frage ob Adapter zb nicht laufen dürfen (siehe zigbee/influxdb) wenn Sie "Ihr" backup machen ... damit ggf eher ein "main.js -- backup" oder sowas als extra handler ...

@simatec @Jey-Cee daher ist es denk ich mal praktisch dieses Thema im meeting zu besprechen, die fragen im issue waren z.b.

• ist es überhaupt valide das in BackitUp zu machen
• sollte backup eventuell nur fuer ioBroker relevante Dienste, oder auch Exoten unterstützen
• sollte man das eventuell separat auslagern in einen anderen adapter

Da ich den Eindruck habe das man sich nicht mit der Thematik beschäftigt hat bevor reagiert wurde, in dem fall "so als Vorschlag: Bau ein Interface über das ein Adapter sich im Backitup registrieren kann und über das die Backups als zip geliefert werden müssen."
(das war nicht die frage/beispiel im issue :))

Vorschlag ist definitiv interessant, wuerde z.b. beim ESPHome eventuell auch eine Lösung sein um @simatec in der maintenance zu entlasten.
Das bedeute aber auch in de basis das die adapter das selber implementieren müssen, viele:

• unifi
• influxDB
• SQL

etc... haben das momentan nicht so gelöst, also ein strategisches Thema fürs meeting: worauf einigen wir uns wir wir damit weitermachen :)
eventueel mit nem change auf bestehende Lösungen als folge

die basis frage war aber überhaupt, sollte backt-up nicht ioBroker relevante Ressourcen (z.b. unifi) unterstützen, und wen ja wie

[Jey Cee]

@apollon77 sagte in Meeting für ioBroker Core/Dev/Admin 29.11.23 20:30:

@jey-cee Man müsste sich nur was überlegen wie man damit umgeht wenn der adapter gerade nicht läuft ... bzw ist ja auch die Frage ob Adapter zb nicht laufen dürfen (siehe zigbee/influxdb) wenn Sie "Ihr" backup machen ... damit ggf eher ein "main.js -- backup" oder sowas als extra handler ...

Guter Punkt, muss man Natürlich berücksichtigen. Unter diesem Aspekt wäre ein Flag "Backup" in der io-package.json und in der package.json unter scripte ein Eintrag ala ioBackup ne Überlegung. Das script kann dann unabhängig vom Status des Adapters ausgeführt werden und sich dann entsprechend um alles Kümmern.

@dutchman sagte in Meeting für ioBroker Core/Dev/Admin 29.11.23 20:30:

ist es überhaupt valide das in BackitUp zu machen

Ja und Nein: Die Antwort hängt davon ab wer gefragt wird.
Benutzer die ein externes System verwenden zum sichern sagen sicher eher Nein. Während die diejenigen die ioBroker als das Zentrale System Benutzen sicher eher sagen Ja.
Wenn wir jetzt beschließen Nein das ist es nicht, muss man Konsequent sein und alles was nicht ioBroker ist aus dem Adapter wieder entfernen, sonst wird es immer wieder diese Diskussion geben.
Das heist auch die DB's mit Ausnahme von History müssten entfernt werden.

@dutchman sagte in Meeting für ioBroker Core/Dev/Admin 29.11.23 20:30:

sollte man das eventuell separat auslagern in einen anderen adapter

Diese Frage hat meiner Meinung nach gar keine Berechtigung, den der Backitup Adapter ist schon eine Auslagerung des ioBroker eigenen Backups.

@dutchman sagte in Meeting für ioBroker Core/Dev/Admin 29.11.23 20:30:

(das war nicht die frage/beispiel im issue :))

Stimmt, die Frage von @simatec war "Wie weit sollte hier die Unterstützung von Backitup gehen?"
Und genau darauf habe ich mit einem Lösungsvorschlag geantwortet. Die Lösung ist halt nur nicht eine Grenze zu definieren (siehe oben warum das eine blöde idee wäre), sondern eine Möglichkeit flexibel zu bleiben ohne nur einen Entwickler damit zu belasten.

Davon ab gab es diese Fragen schon in der Vergangenheit und wurden Offensichtlich nie geklärt.

[Dutchman]

@jey-cee

Vol bei dir, wird n interessantes Thema beim Meeting :-)

[A Former User]

@dutchman @Jey-Cee

Freut mich, dass es hier in die richtige Richtung geht, vielen Dank!

[simatec]

@jey-cee Grundsätzlich bin ich absolut bei dir.
Die Frage ist nur, wie definieren wir Grenzen?
Und darum geht es mir im Speziellen.

Ein Influx Backup sehe ich schon im iobroker Verbund, da es aktiv mit iobroker genutzt wird und dort Daten geschrieben werden.

In dem von mir aufgezeigten Beispiel die Config eine Unifi Gerätes zu sichern, bin ich eher anderer Meinung.

Ein Unifi Gerät steht in keinerlei Zusammenhang mit iobroker.
Davon abgesehen, ist das wirklich nur ein reines Beispiel, da die Umsetzung über einen Adapter eher nicht möglich ist… aber das ändert an dem grundsätzlichen Thema erstmal nix 😊

Aber das ist nur meine persönliche Meinung und ich freue mich auf die Diskussion im Meeting.

[Dutchman]

@simatec sagte in Meeting für ioBroker Core/Dev/Admin 29.11.23 20:30:

Ein Unifi Gerät steht in keinerlei Zusammenhang mit iobroker.

Mia das ist ja genau der Knackpunkt und diesem Beispiel, eventueel für doch nicht in Kombi ioBroker…
Aber wen ich so die Community repräsentieren darf (telegram/discord/facebook) dan sieht man das hunderte, traue mich sogar zu sagen tausende User ihr heimnetzwerk für iOT auf Unifi aufgebaut haben und ioBroker ist aus der Sicht wieder die centrale Einheit für das „locale iOT“ Netzwerk

Ist alles Ansichtssache Sache, darum wollte ich auch zurück zur Basis Diskussion „scope“ Da es individuelle Meinungen ist.
So wie hier influxDB als Bestandteil der ioBroker infra genannt wird, so kann es unifi auch sein.
Zigbee2mqtt auch und esphome was auch eigentlich andere externe Module sind

Davon abgesehen, ist das wirklich nur ein reines Beispiel, da die Umsetzung über einen Adapter eher nicht möglich ist… aber das ändert an dem grundsätzlichen Thema erstmal nix 😊

Das stimmt nicht ganz den API bzw file Sync (beim Controller) oder Mount wie auch mit zigbee2mqtt währen technisch möglich
(Gibt hier einen Unterschied zwischen Dream machine und einen richtigen Controller)

Ich möchte damit keine erneute Prinzip Diskussion starten, nur betonen das wir bei der scoping Diskussion bleiben sollte das wie kan danach bestimmen.
Und was für den einen kein bestand Teil ist, ist für den anderen sehr wichtig jedes Home Netzwerk ist anders aufgebaut

[arteck]

können wir das im MEETING besprechen und nicht hier..

[A Former User]

@simatec sagte in Meeting für ioBroker Core/Dev/Admin 29.11.23 20:30:

@jey-cee Grundsätzlich bin ich absolut bei dir.
Die Frage ist nur, wie definieren wir Grenzen?

Grenzen engen ein, Interfaces oeffnen Zugaenge...

Jungs, ihr macht alle ne super Arbeit!!
Hier haben wir das "AVM Eierlegendewollmilchsau-Problem" aus der ISDN-Karte aus den 90ern ist auch etwas mehr geworden..
Da ich das Issue angeleiert habe, werde ich gerne mal beim Meeting dabei sein.. aber macht ihr erstmal die wichtigen Dinge..
Das kann hinten anstehen und ich verstehe ja auch, dass irgendwo "fertig" sein muss..

[mcm1957]

KÖNNEN WIR UNS HIER BITTE AUF DIE TOPICS BESCHRÄNKEN.

DANKE

Inhaltliche Diskussionen bitte beim Meeting besprechen oder ggF eigenenThread eröffnen

[Dutchman]

@ilovegym sagte in Meeting für ioBroker Core/Dev/Admin 29.11.23 20:30:

Da ich das Issue angeleiert habe, werde ich gerne mal beim Meeting dabei sein.. aber macht ihr erstmal die wichtigen Dinge..

du bist herzlich willkommen am 29ten um 20.30, die Einladung (siehe ersten post) ist offen fuer jedermann.
Es wahre eventueel sogar sehr hilfreich um, sollte die frage kommen, vom end-user Perspektive zu erfahren/verstehen wo und warum der wünsch entstanden ist das kan positiv bijtragen zum Thema und uns in der Gruppe helfen es im ganzen zu sehen

[andre]

@mcm57 Da kommst du mit deiner Ansage leider ein paar Posts zu spät. :) Nichts desto trotz kann ich die (Vorab-)Beteiligung hier nur loben! (Auch wenn das vielleicht nicht der passende Thread dazu ist) Fakt ist, dass sich offenbar viele kluge Köpfe Gedanken dazu machen. Hoffe das setzt sich im Meeting fort!
Achja übrigens, deine Shift Taste klemmt. :joy:

Aber um mal zurück auf die Themen vom Meeting zu kommen. Es gibt Bewegung beim RPI Imager (https://github.com/raspberrypi/rpi-imager/issues/375#issuecomment-1816744612).

Allerdings ist der Autobuild Prozess des ioBroker RPI Images derzeit kaputt (vermutlich durch die "unfertige" Migration auf Debian 12 und 64-bit). Jetzt ist die Frage wie wir hier weiter machen und ob ich da nochmal Zeit investiere.
Daher bitte den folgenden Punkt hinzufügen:

• Zukunft des ioBroker Raspberry Pi Images. Ist das Kunst oder kann das weg?

MfG,
André

[Dutchman]

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

Zukunft des ioBroker Raspberry Pi Images. Ist das Kunst oder kann das weg?

danke dir !

@ldittmar und ich habe uns bemüht, zwischen der aktiven Diskussion ;), alle angetragenen Themen zusammen zufassen.
Diesen Punkt habe ich soeben aufgenommen

[Dutchman]

@apollon77 ich bin da gerade noch auf dieses Thema gestossen, waehre eventueel Planung NodeJS Versionen 18/20 auch etwas fürs meeting.
Wir haben noch nicht offiziell abstand genommen von 16, die ist inzwischen EOL und auch 18 ist bereits in maintenance

[apollon77]

@dutchman Naja Empfohlene version ist bereits Node.js 18 as I know ... mit Nodejs 20 würde ich warten bis die die version releasen bei der npm 10.2.3+ mitkommt um probleme wegen node-gyp und Python 3.12 vorzubeugen ... aber dann könnte man auch Node.js 20 als Empfehlung hoch. Am Ende schadet aber auch Node.js 18 nicht ... ist noch LTS bis April 25 (ja 2025)

[simatec]

@apollon77 Ist ein gutes Thema, da node20 aktuell noch einen Bug in Kombi mit CIFS hat

[apollon77]

@simatec na dann ein grund mehr zu warten

[Thomas Braun]

Man könnte aber 'die Herde' zusammentreiben und auf nodejs@18 führen, indem zentrale Adapter diese Version zur Mindestvoraussetzung machen.

[Dutchman]

@thomas-braun sagte in Meeting für ioBroker Core/Dev/Admin 29.11.23 20:30:

Man könnte aber 'die Herde' zusammentreiben und auf nodejs@18 führen, indem zentrale Adapter diese Version zur Mindestvoraussetzung machen.

das haben wir glaube ich bereits den sehr viele Adapter benutzen module die NodeJS-18 benötigen.
In den vorigen meetings wurde bisher entschieden das Node16 support noch bleibt im jetzigen JS-controller und ein dropping where auch ein Major change (also eher fuer den 6.x.x als ner minor release vom 5er)

Die frage waehre also ob wir node16 support jetzt killen und in moment x auf 18 gehen, NodeJS 20 hatte ich mehr gemeint als roadmap Sachen damit es nicht in Vergessenheit gerät z.b. fuer controller 6 Nestes Jahr. Nach release Planung sollte zu der zeit 16 definitiv rausfallen (wen die Abhängigkeiten es zulassen), 18 ist ja noch in maintenance bis April '25

[apollon77]

@dutchman Warum killen wenn nicht nötig? Es hat bisher immer soweit "natürlich" funktioniert. Adapter heben deps an wenn Sie es wegen Ihrer deps brauchen ... der js-controller ebenso ... so ziehen wir schon seid Jahren die Community langsam hochwärts