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. -
@dutchman Wir hatten im letzten Meeting wegen des Smarthome Forums in Solingen das nächste Meeting nach hinten verschoben und dann das Dezember-Meeting (wegen der Nähe zu Weihnachten) gestrichen.
Leider weiß ich aber den Termin nicht mehr. War es der 29.11.2023?? @apollon77 @ldittmar -
@andre Exakt 29.11., dann wieder Januar. ich hab mal hier umbenannt den Thread.
@Dutchman passt du bitte ggf den teams link an wenn nötig?
-
@apollon77 sagte in Meeting für ioBroker Core/Dev/Admin 29.11.23 20:30:
@andre Exakt 29.11., dann wieder Januar. ich hab mal hier umbenannt den Thread.
@Dutchman passt du bitte ggf den teams link an wenn nötig?
ist ein recurrence meeting, der bleibt bewusst derselbe :), habe den invite verschoben... diejenigen die mir ihre e-mail Adresse gegeben hatten bekommen das neue datum
-
@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
-
ich würde gerne über das Thema : Readme
quatschen.. also Docu wieder mal -
@arteck sagte in Meeting für ioBroker Core/Dev/Admin 29.11.23 20:30:
also Docu wieder mal
Neee Bitte nicht.
-
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.
-
@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.
-
@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
-
@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.
-
-
Bei govee gibt es glaube ich auch 3 Ansätze.
-
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.
-
@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
-
@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.
-
@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. -
@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 -
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
closed Feature request: Unifi Backup #1024
-
@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.
