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

[Dutchman]

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

Aus aktuellem Anlass würde ich gerne das Thema „Konkurrenz“ bei der Entwicklung von Adaptern erörtern.

Welchen Sinn macht es, wenn zwei oder mehr Entwickler Adapter für das gleiche Gerät entwickeln?

Falls das zu einem Wettstreit ausartet, wer den „schöneren“ Adapter entwickelt, den „eleganteren“ Code schreibt oder die meisten Adapter am Start hat, bin ich aus der Nummer sofort wieder raus.

Das sollte niemals das Ziel sein, leider gibt es ein Par Beispiel dazu was auch den Effekt hat mehrere Adapter in der repo zu habe für das selbe Ziel der eine besser maintained als der andere

Zu diesem Thema währe eventueel interessant wie wir mit dopplungen und Aufnahme in der repo umgehen wollen.

Anstatt parallelle Sachen würde es mich freuen wen man sich einander findet und ergänzt, ich habe dadurch zb sehr viel gelernt und in Zusammenarbeit umgesetzt, aber verstehe auch das dies nicht immer möglich ist

[apollon77]

@codierknecht in einer idealen Welt gibts das Problem nicht ;-). In der Praxis kann es vorkommen und kam es auch meist wenn ein bestehender Adapter nicht mehr weiterentwickelt wurde und auch der dev nicht erreichbar war. Es sollte aber erlaubt sein nach dem Sinn zu fragen und idealerweise stimmt man solche Themen ab. Manchmal entsteht so etwas, auch, wenn Meinungen zu stark voneinander abweichen, wie ein entsprechender Adapter aussehen sollte. Aber natürlich ist es am Ende blöd, weil es doppelte Entwicklungsressourcen bindet. Wenn du aber ein konkretes Beispiel hast, lass es doch einmal diskutieren und klären.

Du hast aber recht, dass ein Wettrüsten natürlich nicht das Ziel sein kann.

[arteck]

@apollon77 ist zwar alt aber gas schon mal

oder

von tibber gibet glaube ich 3 stück oder so

[Thomas Braun]

@arteck @apollon77

Bei govee gibt es glaube ich auch 3 Ansätze.

[oFbEQnpoLKKl6mbY5e13]

Die beiden Nuki-Adapter kann man kaum vergleichen, weil der Extended viel mehr bietet. Zum Beispiel das alternative Steuern über die Web-API. Aber auch die Anzeige des Batteriestands.

Grundsätzlich trifft das ja auf alle Extended-Adapter von @Zefau zu. Da er die Entwicklung dieser Adapter inzwischen aufgegeben hat, sind das letztlich Altlasten.

[mcm1957]

@ofbeqnpolkkl6mby5e13 said in Meeting für ioBroker Core/Dev/Admin 29.11.23 20:30:

Die beiden Nuki-Adapter kann man kaum vergleichen, weil der Extended viel mehr bietet. Zum Beispiel das alternative Steuern über die Web-API. Aber auch die Anzeige des Batteriestands.

Grundsätzlich trifft das ja auf alle Extended-Adapter von @Zefau zu. Da er die Entwicklung dieser Adapter inzwischen aufgegeben hat, sind das letztlich Altlasten.

Nuki-extended ist bereits seit längerem DEPRECTED, das Problem hat sich erledigt.

Der konkrete Fall von Codierknecht betrifft nicht direkt eine Parallelentwicklung eines bestehenden Adapters sondern den Fall, dass 2 Entwickler einen Adapter der NICHT auf npm war und daher auch nicht in den Repos war aktualisiert haben und natürlich nur einer Adapter mit dem Namen in npm (und damit ein die Repos) kann.

Das ist ein Sonderfall, bei dem noch dazu kommt, dass der später begonnen (lt. firt GH commit) schneller war UND von den Arbeiten des anderen Entwicklers wusste...

Detaiuls möge ggF Codierknecht selbst posten - wobei ich nicht sicher bin, ob das für dieses Topic nicht O.T: wird.

Edit: Nuki Hinweis gestrichen, ich hab das mit hue / hue-extended verwechselt. Danke an ofbeqnpolkkl6mby5e13 für Hinweis. Sorry für allfällige Verwirrung

[oFbEQnpoLKKl6mbY5e13]

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

Nuki-extended ist bereits seit längerem DEPRECTED, das Problem hat sich erledigt.

Das sehe ich nicht so, solange er noch von vielen benutzt wird. Und das wird er, weil er nicht durch den anderen Nuki-Adapter ersetzbar ist. Beim Hue-Adapter ist/war das anders.

[Codierknecht]

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

wobei ich nicht sicher bin, ob das für dieses Topic nicht O.T: wird.

Wird es. Daher mein Wunsch, das Thema beim Meeting zu erörtern.
Alles andere geht an dieser Stelle zu weit.

[Dutchman]

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

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

wobei ich nicht sicher bin, ob das für dieses Topic nicht O.T: wird.

Wird es. Daher mein Wunsch, das Thema beim Meeting zu erörtern.
Alles andere geht an dieser Stelle zu weit.

Sehe ich aus so, lasst uns in diesem Thread bitte Focus legen auf die Agenda der Session.
Den Inhalt können wir dort besprechen oder separieren in ein Diskussions Thema sollte es bedarf geben

[simatec]

Aus aktuellen Anlass habe ich auch noch ein Thema zur allgemeinen Diskussion.
Wie weit sollte hier die Unterstützung von Backitup gehen? Ich sehe alle Backups, die nicht in unmittelbarer verbindung mit iobroker stehen hier eher nicht sinnvoll in einem Backup Adapter für iobroker.

https://github.com/simatec/ioBroker.backitup/issues/1024

[Jey Cee]

@simatec 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.
Wenn dann ein Backup gemacht wird schickt Backitup den Befehl an den Adapter der gibt das Zip (oder den Pfad zum Zip) zurück und Backitup kann damit machen was nötig ist.
So sollte das gehen ohne das im Backitup irgendwas geändert werden muss wenn ein neuer Adapter dazu kommt.
Damit liegt es einfach nur am Adapter ob es Unterstützt wird oder nicht.

[Ein ehemaliger Benutzer]

@jey-cee

Geile Idee, sowohl technisch als auch politisch!!
👍

[apollon77]

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

[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 :-)

[Ein ehemaliger Benutzer]

@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