NEWS
Meeting für ioBroker Core/Dev/Admin 29.11.23 20:30
-
@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.
zigbee hab ich, zwave auch, nuc's genauso und HA auch
-
Bei govee gibt es glaube ich auch 3 Ansätze.
-
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.
-
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
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer Danke sagen will, kann nen Kaffee spendieren: https://paypal.me/mcm1957atiobroker
-
@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.
-
@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:
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."Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring")
Proxmox 9.1.1 LXC|8 GB|Core i7-6700
HmIP|ZigBee|Tasmota|Unifi
Zabbix Certified Specialist
Konnte ich Dir helfen? Dann benutze bitte das Voting unten rechts im Beitrag -
@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. -
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.@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.Persönlicher Support
Spenden -> paypal.me/J3YC33 -
@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.Geile Idee, sowohl technisch als auch politisch!!
👍 -
@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.@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 ...
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
Ich habe noch https://github.com/ioBroker/ioBroker.discovery/issues/299 als Fallout von Solingen hinzugefügt
-
@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 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 folgedie basis frage war aber überhaupt, sollte backt-up nicht ioBroker relevante Ressourcen (z.b. unifi) unterstützen, und wen ja wie
-
@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 folgedie basis frage war aber überhaupt, sollte backt-up nicht ioBroker relevante Ressourcen (z.b. unifi) unterstützen, und wen ja wie
@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.
Persönlicher Support
Spenden -> paypal.me/J3YC33 -
@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.
Vol bei dir, wird n interessantes Thema beim Meeting :-)
-
@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.
@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.
-
@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“ NetzwerkIst 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 sindDavon 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 -
@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.
@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..
Support us
391
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge