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

[Dutchman]

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

@dutchman
Keine Themen von dir?

Wurde nicht beschlossen das nächste Meeting im Dezember ausfallen zu lassen?

da kommt bestimmt noch was

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

@dutchman
Ich würde ja gerne das Thema OAuth behandeln wollen, bin aber leider nicht dabei.
Vielleicht kann man das Thema schon mal für eines der weiteren Meetings vormerken.

würde vorschlagen das dan fuel Januar vor zu vermerken, habe auch dazu schonmal nen thread erstellt zum sammeln: https://forum.iobroker.net/topic/69718/meeting-für-iobroker-core-dev-admin-17-01-24-20-30

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

en) gestrichen.

ich darf halt nicht krank werden und sollte bei den meetings dabei sein :), sorry

[arteck]

ich würde gerne über das Thema : Readme
quatschen.. also Docu wieder mal

[Jey Cee]

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

also Docu wieder mal

Neee Bitte nicht.

[Codierknecht]

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.

[Jey Cee]

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

Da Frage ich doch gleich mal nach wo du Konkret einen fall siehst bei dem das so ist.

[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