NEWS
Test Adapter Unifi Network
-
Ich hab am WE deinen Adapter installiert.
Er läuft soweit stabil und zuverlässig parallel zum alten Unifi Adapter.
Super Arbeit!Mir fehlt allerdings eine ganz essentielle Funktion, die der alte Adapter bietet:
Die Möglichkeit die PoE Ports meiner Unifi Switch zu schalten. (+ den aktuellen Stromverbrauch der PoE Geräte anzuzeigen)
Hast du das Feature auf der Roadmap ?
Falls ja, dann könnte ich den alten Unifi Adapter tatsächlich kübeln und komplett auf deinen umsteigen.Falls du Infos dazu brauchst, versuche ich gerne nach meinen Möglichkeiten zu unterstützen.
Beste Grüße
-
@scrounger
Wann nimmst Du aktuellere releases ins stable Repo auf? Ich habe die "offizielle" 1.1.6, in Github haben wir ja jetzt 1.3.1 (in der auch ein interessanter fix für mich ist)? Hast Du da einen Zyklus oder Vorgehensweise? -
Ich habe versucht einen Bug report auf GitHub zu erstellen. Mittlerweile wird man so schikaniert, dass selbst das erstellen eines Bug Reports gefühlt 45 Minuten dauert.
Naja, ich habe zwei Accesspoints in der Wohnung und wenn ich mich durch die Wohnung bewege wechselt er automatisch von einem zum anderen Accesspoint. Beim Wechsel wird das Gerät für ca. 10 Sekunden als offline angezeigt. Dabei ist es auch egal wie viel Entprellzeit ich einstelle. Erst mit einem Timeout im Skript komme ich weiter und verhindere diese kurzen "Abwesenheitsmomente" -
Ich habe versucht einen Bug report auf GitHub zu erstellen. Mittlerweile wird man so schikaniert, dass selbst das erstellen eines Bug Reports gefühlt 45 Minuten dauert.
Naja, ich habe zwei Accesspoints in der Wohnung und wenn ich mich durch die Wohnung bewege wechselt er automatisch von einem zum anderen Accesspoint. Beim Wechsel wird das Gerät für ca. 10 Sekunden als offline angezeigt. Dabei ist es auch egal wie viel Entprellzeit ich einstelle. Erst mit einem Timeout im Skript komme ich weiter und verhindere diese kurzen "Abwesenheitsmomente"@Dragon sagte in Test Adapter Unifi Network:
Ich habe versucht einen Bug report auf GitHub zu erstellen. Mittlerweile wird man so schikaniert, dass selbst das erstellen eines Bug Reports gefühlt 45 Minuten dauert.
Naja, ich habe zwei Accesspoints in der Wohnung und wenn ich mich durch die Wohnung bewege wechselt er automatisch von einem zum anderen Accesspoint. Beim Wechsel wird das Gerät für ca. 10 Sekunden als offline angezeigt. Dabei ist es auch egal wie viel Entprellzeit ich einstelle. Erst mit einem Timeout im Skript komme ich weiter und verhindere diese kurzen "Abwesenheitsmomente"Mal langsam mit den "wilden Pferden"!
Du nutzt einen kostenlosen Adapter, den jemand in seiner Freizeit schreibt und wartet für die comminity! Da wird es doch nciht zu viel verlangt sien, einen ausführlichen Report zu schreiben, der dem Entwickler die Möglichkeit gibt den Fehler nachzuvollziehen und zu verstehen, um der Sache dann freundlicherweise nachzugehen.Ein bißchen mehr "Bitte" und "Danke" wäre angezeigt, statt unmäßiger Erwartungshaltung.
PS: Schon mal überlegt, dass diese Problematik vom Router kommen könnte (nur eine Vermutung - weil das Ding echt träge reagiert)?
-
@scrounger
Wann nimmst Du aktuellere releases ins stable Repo auf? Ich habe die "offizielle" 1.1.6, in Github haben wir ja jetzt 1.3.1 (in der auch ein interessanter fix für mich ist)? Hast Du da einen Zyklus oder Vorgehensweise?@reutli sagte in Test Adapter Unifi Network:
@scrounger
Wann nimmst Du aktuellere releases ins stable Repo auf? Ich habe die "offizielle" 1.1.6, in Github haben wir ja jetzt 1.3.1 (in der auch ein interessanter fix für mich ist)? Hast Du da einen Zyklus oder Vorgehensweise?Ich würde den gerne schneller ins stable bringen, aber da gibt es mittlerweile die Regel das der Adapter mind. 2 Wochen im Beta war und glaub auch eine gewisse Anzahl an Nutzern den schon installiert haben müssen (@mcm1957)
Da ich aber die letzten Wochen immer dran gearbeitet bin ich nie über die zwei Wochen kommen...@Dragon sagte in Test Adapter Unifi Network:
Ich habe versucht einen Bug report auf GitHub zu erstellen. Mittlerweile wird man so schikaniert, dass selbst das erstellen eines Bug Reports gefühlt 45 Minuten dauert.
@reutli hat es schon alles dazu gesagt. Allerdings fehlt wie in 99% der Fälle ein debug log. Ohne ein log kann ich eh nix analysieren...
Also füg ein debug log hinzu oder der issue wird ganz schnell wieder geschlossen...@Dragon sagte in Test Adapter Unifi Network:
Naja, ich habe zwei Accesspoints in der Wohnung und wenn ich mich durch die Wohnung bewege wechselt er automatisch von einem zum anderen Accesspoint. Beim Wechsel wird das Gerät für ca. 10 Sekunden als offline angezeigt. Dabei ist es auch egal wie viel Entprellzeit ich einstelle.
Dann scheint bei dir ein generelles Problem mit dem Roaming zu bestehen. Anstatt zu roamen verbinden sich deine clients neu. Das ist kein Problem des Adapters sondern deiner Konfig.
@Dragon sagte in Test Adapter Unifi Network:
Erst mit einem Timeout im Skript komme ich weiter und verhindere diese kurzen "Abwesenheitsmomente"
Keine Ahnung was du hier für ein Skript verwendest...
-
Ich bekomm die Instanz leider nicht grün. Hab den anderen Adapter abgeschalten, aber ändert leider nix :-(
unifi-network.0 2025-12-05 09:37:00.470 error [login]: Login to the Unifi-Network controller API failed! (host: https://10.10.0.1, site: default) unifi-network.0 2025-12-05 09:37:00.469 error [NetworkApi._retrieve] Unable to connect to the Network controller. This is temporary and may occur during device reboots (url: https://10.10.0.1/api/auth/login)EDIT: wollte gerade den alten nochmal starten. Da steht im Log wohl mein Fehler... Wie lange muss man da warten?
Error site undefined (data): {"code":"AUTHENTICATION_FAILED_LIMIT_REACHED","message":"You've reached the login attempt limit","level":"debug"} -
@reutli sagte in Test Adapter Unifi Network:
@scrounger
Wann nimmst Du aktuellere releases ins stable Repo auf? Ich habe die "offizielle" 1.1.6, in Github haben wir ja jetzt 1.3.1 (in der auch ein interessanter fix für mich ist)? Hast Du da einen Zyklus oder Vorgehensweise?Ich würde den gerne schneller ins stable bringen, aber da gibt es mittlerweile die Regel das der Adapter mind. 2 Wochen im Beta war und glaub auch eine gewisse Anzahl an Nutzern den schon installiert haben müssen (@mcm1957)
Da ich aber die letzten Wochen immer dran gearbeitet bin ich nie über die zwei Wochen kommen...@Dragon sagte in Test Adapter Unifi Network:
Ich habe versucht einen Bug report auf GitHub zu erstellen. Mittlerweile wird man so schikaniert, dass selbst das erstellen eines Bug Reports gefühlt 45 Minuten dauert.
@reutli hat es schon alles dazu gesagt. Allerdings fehlt wie in 99% der Fälle ein debug log. Ohne ein log kann ich eh nix analysieren...
Also füg ein debug log hinzu oder der issue wird ganz schnell wieder geschlossen...@Dragon sagte in Test Adapter Unifi Network:
Naja, ich habe zwei Accesspoints in der Wohnung und wenn ich mich durch die Wohnung bewege wechselt er automatisch von einem zum anderen Accesspoint. Beim Wechsel wird das Gerät für ca. 10 Sekunden als offline angezeigt. Dabei ist es auch egal wie viel Entprellzeit ich einstelle.
Dann scheint bei dir ein generelles Problem mit dem Roaming zu bestehen. Anstatt zu roamen verbinden sich deine clients neu. Das ist kein Problem des Adapters sondern deiner Konfig.
@Dragon sagte in Test Adapter Unifi Network:
Erst mit einem Timeout im Skript komme ich weiter und verhindere diese kurzen "Abwesenheitsmomente"
Keine Ahnung was du hier für ein Skript verwendest...
@Scrounger sagte in Test Adapter Unifi Network:
@reutli sagte in Test Adapter Unifi Network:
@scrounger
Wann nimmst Du aktuellere releases ins stable Repo auf? Ich habe die "offizielle" 1.1.6, in Github haben wir ja jetzt 1.3.1 (in der auch ein interessanter fix für mich ist)? Hast Du da einen Zyklus oder Vorgehensweise?Ich würde den gerne schneller ins stable bringen, aber da gibt es mittlerweile die Regel das der Adapter mind. 2 Wochen im Beta war und glaub auch eine gewisse Anzahl an Nutzern den schon installiert haben müssen (@mcm1957)
Da ich aber die letzten Wochen immer dran gearbeitet bin ich nie über die zwei Wochen kommen...Hi @scrounger,
Da scheint ein gewisses Missverständnis vorzuliegen. Ich will das mal zusammenfassen:
a) Sobald eine Release 14 Tage im Latest ist UND mindestens 5% aller Installation aufweist, wird ein Erinnerungsisusse erstellt, dass den Maintainer daran erinnern soll, dass die Release ev. ins Stable kommen sollte.
b) Spätestens nach 30 Tagen im Latest wird ein Erinnerungsissue erstellt - unabhängig von der Anzahl der Installationen.
c) In jedem Fall muss der Maintainer die Aktualisierung im Stable aktiv anfordern. Einen Automatismus gibt es (als Folge der Beschwerde eines Devs) nicht.
d) Eine Release kann auch schon vor den 14 Tagen ins Stable Repository aufgenommen werden. Der Maintainer muss nicht auf das Erinnerungsissue werten. Hier gilt als allgemeine Richtlinie ca. eine Woche im Latest, kann aber auch schon ein zwei Tage früher sein wenn es User und keine (neuen) gravierenden Issues gibt. Einfach PR einstellen.
e) Bei ganz wenigen Tagen (4 oder weniger) bitte eine kurze Begründung in den PR schreiben warum die Release schon ins Stable soll.
f) Ohne Begründung / zusätzliche Info werden Issues die weniger als ca 4 Tage im Latest waren nur markiert und nach ca 14 Tagen dann gemerged. Natürlich kann da auch schon vorher vom Maintainer ein Kommentar ergänzt werden
g) Natürlich kann eine Release auch quasi sofort ins Stable wenn es sich um einen Emergency Fall handelt (z.B. Api Änderung des Herstellers blockiert ältere Releases o.ä.). Bitte dies unbedingt gleich in den PR schreiben und je nach Prio ggF mich oder Apollon77 auch via Telegramm anpingen.
h) Nicht gern gesehen sind PRs fürs Stable die unmittelbar nach dem Erstellen einer Release zu einem Zeitpunkt wo die neue Release noch nicht mal im Latest ist gemacht werden. Auch geringste Änderungen können negative Auswirkungen haben - deswegen sind ein paar Latest Installation jedenfalls "erwünscht". 0-Day PRs, d.h. PRs wo die neue Release noch nicht mal im Latest ist werden ev. auch mit der Bitte diese nach einer kurzen Testphase neu zu erstellen geschlossen.
Ergo:
Wenn du einen Update im Stable willst, die betreffende Release deiner Ansicht nach OK ist und sie zumindest einige (wenige) Tage im LATEST war, dann erstell doch bitte einen PR. -
@scrounger
Wann nimmst Du aktuellere releases ins stable Repo auf? Ich habe die "offizielle" 1.1.6, in Github haben wir ja jetzt 1.3.1 (in der auch ein interessanter fix für mich ist)? Hast Du da einen Zyklus oder Vorgehensweise?@reutli sagte in Test Adapter Unifi Network:
@scrounger
Wann nimmst Du aktuellere releases ins stable Repo auf? Ich habe die "offizielle" 1.1.6, in Github haben wir ja jetzt 1.3.1 (in der auch ein interessanter fix für mich ist)? Hast Du da einen Zyklus oder Vorgehensweise?Ähmm - was meinst du mit in Github ?
Die Version 1.3.1 ist ganz normal im LATEST Repository verfügbar und du kannst sie jederzeit via LATEST Repository installieren wenn du die aktuellste Testversion haben willst. Von direkten Installation von Github wird abgeraten. Neue Versionen kommen automatisch spätestens nach 24h ins LATEST Repository.

-
@Scrounger sagte in Test Adapter Unifi Network:
@reutli sagte in Test Adapter Unifi Network:
@scrounger
Wann nimmst Du aktuellere releases ins stable Repo auf? Ich habe die "offizielle" 1.1.6, in Github haben wir ja jetzt 1.3.1 (in der auch ein interessanter fix für mich ist)? Hast Du da einen Zyklus oder Vorgehensweise?Ich würde den gerne schneller ins stable bringen, aber da gibt es mittlerweile die Regel das der Adapter mind. 2 Wochen im Beta war und glaub auch eine gewisse Anzahl an Nutzern den schon installiert haben müssen (@mcm1957)
Da ich aber die letzten Wochen immer dran gearbeitet bin ich nie über die zwei Wochen kommen...Hi @scrounger,
Da scheint ein gewisses Missverständnis vorzuliegen. Ich will das mal zusammenfassen:
a) Sobald eine Release 14 Tage im Latest ist UND mindestens 5% aller Installation aufweist, wird ein Erinnerungsisusse erstellt, dass den Maintainer daran erinnern soll, dass die Release ev. ins Stable kommen sollte.
b) Spätestens nach 30 Tagen im Latest wird ein Erinnerungsissue erstellt - unabhängig von der Anzahl der Installationen.
c) In jedem Fall muss der Maintainer die Aktualisierung im Stable aktiv anfordern. Einen Automatismus gibt es (als Folge der Beschwerde eines Devs) nicht.
d) Eine Release kann auch schon vor den 14 Tagen ins Stable Repository aufgenommen werden. Der Maintainer muss nicht auf das Erinnerungsissue werten. Hier gilt als allgemeine Richtlinie ca. eine Woche im Latest, kann aber auch schon ein zwei Tage früher sein wenn es User und keine (neuen) gravierenden Issues gibt. Einfach PR einstellen.
e) Bei ganz wenigen Tagen (4 oder weniger) bitte eine kurze Begründung in den PR schreiben warum die Release schon ins Stable soll.
f) Ohne Begründung / zusätzliche Info werden Issues die weniger als ca 4 Tage im Latest waren nur markiert und nach ca 14 Tagen dann gemerged. Natürlich kann da auch schon vorher vom Maintainer ein Kommentar ergänzt werden
g) Natürlich kann eine Release auch quasi sofort ins Stable wenn es sich um einen Emergency Fall handelt (z.B. Api Änderung des Herstellers blockiert ältere Releases o.ä.). Bitte dies unbedingt gleich in den PR schreiben und je nach Prio ggF mich oder Apollon77 auch via Telegramm anpingen.
h) Nicht gern gesehen sind PRs fürs Stable die unmittelbar nach dem Erstellen einer Release zu einem Zeitpunkt wo die neue Release noch nicht mal im Latest ist gemacht werden. Auch geringste Änderungen können negative Auswirkungen haben - deswegen sind ein paar Latest Installation jedenfalls "erwünscht". 0-Day PRs, d.h. PRs wo die neue Release noch nicht mal im Latest ist werden ev. auch mit der Bitte diese nach einer kurzen Testphase neu zu erstellen geschlossen.
Ergo:
Wenn du einen Update im Stable willst, die betreffende Release deiner Ansicht nach OK ist und sie zumindest einige (wenige) Tage im LATEST war, dann erstell doch bitte einen PR. -
@mcm1957
Das man das aktiv anfordern muss ist schon klar. A-G, also 7x regeln mit wenn / und / aber ist mir ehrlich gesagt zu kompliziert ;-)@Scrounger sagte in Test Adapter Unifi Network:
@mcm1957
Das man das aktiv anfordern muss ist schon klar. A-G, also 7x regeln mit wenn / und / aber ist mir ehrlich gesagt zu kompliziert ;-)Dann lies nur den letzten Satz bitte :-)
Ergo:
Wenn du einen Update im Stable willst, die betreffende Release deiner Ansicht nach OK ist und sie zumindest einige (wenige) Tage im LATEST war, dann erstell doch bitte einen PR. -
@reutli sagte in Test Adapter Unifi Network:
@scrounger
Wann nimmst Du aktuellere releases ins stable Repo auf? Ich habe die "offizielle" 1.1.6, in Github haben wir ja jetzt 1.3.1 (in der auch ein interessanter fix für mich ist)? Hast Du da einen Zyklus oder Vorgehensweise?Ich würde den gerne schneller ins stable bringen, aber da gibt es mittlerweile die Regel das der Adapter mind. 2 Wochen im Beta war und glaub auch eine gewisse Anzahl an Nutzern den schon installiert haben müssen (@mcm1957)
Da ich aber die letzten Wochen immer dran gearbeitet bin ich nie über die zwei Wochen kommen...@Dragon sagte in Test Adapter Unifi Network:
Ich habe versucht einen Bug report auf GitHub zu erstellen. Mittlerweile wird man so schikaniert, dass selbst das erstellen eines Bug Reports gefühlt 45 Minuten dauert.
@reutli hat es schon alles dazu gesagt. Allerdings fehlt wie in 99% der Fälle ein debug log. Ohne ein log kann ich eh nix analysieren...
Also füg ein debug log hinzu oder der issue wird ganz schnell wieder geschlossen...@Dragon sagte in Test Adapter Unifi Network:
Naja, ich habe zwei Accesspoints in der Wohnung und wenn ich mich durch die Wohnung bewege wechselt er automatisch von einem zum anderen Accesspoint. Beim Wechsel wird das Gerät für ca. 10 Sekunden als offline angezeigt. Dabei ist es auch egal wie viel Entprellzeit ich einstelle.
Dann scheint bei dir ein generelles Problem mit dem Roaming zu bestehen. Anstatt zu roamen verbinden sich deine clients neu. Das ist kein Problem des Adapters sondern deiner Konfig.
@Dragon sagte in Test Adapter Unifi Network:
Erst mit einem Timeout im Skript komme ich weiter und verhindere diese kurzen "Abwesenheitsmomente"
Keine Ahnung was du hier für ein Skript verwendest...
@Scrounger sagte in Test Adapter Unifi Network:
@Dragon sagte in Test Adapter Unifi Network:
Naja, ich habe zwei Accesspoints in der Wohnung und wenn ich mich durch die Wohnung bewege wechselt er automatisch von einem zum anderen Accesspoint. Beim Wechsel wird das Gerät für ca. 10 Sekunden als offline angezeigt. Dabei ist es auch egal wie viel Entprellzeit ich einstelle.Dann scheint bei dir ein generelles Problem mit dem Roaming zu bestehen. Anstatt zu roamen verbinden sich deine clients neu. Das ist kein Problem des Adapters sondern deiner Konfig.
Hi,
also ich habe das auch und es laesst sich meiner Meinung nach nicht im unifi controller verhindern.
Faktisch ist es auch so, dass ein Wechsel zwischen 2 AP ein disconnect und ein connect stattfindet.
Wenn ich das richtig sehe, dann konnte man früher mal die darstellung Zeit des Handovers beeinflussen. Geht aber wohl nicht mehr.Ich habe ein Anwesenheitsscript (schätze mal sowas hat @dragon ebenfalls.). Lösung kann es sein im Script eine offline Meldung für ca. 10 sek zu ignorieren und erst bei längerer offline Zeit die Abwesenheit zu registieren.
Ähnliches könnte man sich für den Adapter vorstellen (Entprellzeit oder Pufferzeit - wie auch immer)
Das ist kein Bug sondern m.E. ein Feature Request
vG Looxer
-
@reutli sagte in Test Adapter Unifi Network:
@scrounger
Wann nimmst Du aktuellere releases ins stable Repo auf? Ich habe die "offizielle" 1.1.6, in Github haben wir ja jetzt 1.3.1 (in der auch ein interessanter fix für mich ist)? Hast Du da einen Zyklus oder Vorgehensweise?Ähmm - was meinst du mit in Github ?
Die Version 1.3.1 ist ganz normal im LATEST Repository verfügbar und du kannst sie jederzeit via LATEST Repository installieren wenn du die aktuellste Testversion haben willst. Von direkten Installation von Github wird abgeraten. Neue Versionen kommen automatisch spätestens nach 24h ins LATEST Repository.

@mcm1957 sagte in Test Adapter Unifi Network:
Ähmm - was meinst du mit in Github ?
ich meinte nicht "latest" sondern "stable". In Github ist die 1.3.1 und im stable "nur" die 1.1.6. Damit ist im iob stable eben nur die 1.1.6 (im latest natürlich auch die 1.3.1 - ich installier' aber nach Möglichkeit auf Prod nur aus dem stable).
-
Dein Ansatz ist sehr vernünftig.
Es hat für mich nur so geklungen als würdest du das LATEST Repo nicht kennen / übersehen. Du musst für die Instalaltion einzelner Adapter übrigens nicht zwingend das Repo unstellen - via 'von npm installieren' beko mmst du auch die neueste (Latest / Beta) Release wenn du sie aus irgendeinem Grund haben willst. -
Dein Ansatz ist sehr vernünftig.
Es hat für mich nur so geklungen als würdest du das LATEST Repo nicht kennen / übersehen. Du musst für die Instalaltion einzelner Adapter übrigens nicht zwingend das Repo unstellen - via 'von npm installieren' beko mmst du auch die neueste (Latest / Beta) Release wenn du sie aus irgendeinem Grund haben willst.@mcm1957 sagte in Test Adapter Unifi Network:
Du musst für die Instalaltion einzelner Adapter übrigens nicht zwingend das Repo unstellen - via 'von npm installieren' beko mmst du auch die neueste (Latest / Beta) Release
Gilt allerdings nur für Adapter, die auch ein stable Release haben. Adapter, die noch 'in der Mache' sind findest du da nicht (bzw. nur, wenn das Beta-Repo dann doch aktiviert ist), soweit ich weiß.
-
@mcm1957 sagte in Test Adapter Unifi Network:
Du musst für die Instalaltion einzelner Adapter übrigens nicht zwingend das Repo unstellen - via 'von npm installieren' beko mmst du auch die neueste (Latest / Beta) Release
Gilt allerdings nur für Adapter, die auch ein stable Release haben. Adapter, die noch 'in der Mache' sind findest du da nicht (bzw. nur, wenn das Beta-Repo dann doch aktiviert ist), soweit ich weiß.
@Thomas-Braun sagte in Test Adapter Unifi Network:
Gilt allerdings nur für Adapter, die auch ein stable Release haben. Adapter, die noch 'in der Mache' sind findest du da nicht (bzw. nur, wenn das Beta-Repo dann doch aktiviert ist), soweit ich weiß.
Das ist richtig. Die Liste der angebotenen Adapter wird aus dem selektierten Repo entnommen. Adapter die dort gar nicht drinnen sind, werden nicht angezeigt. Ganz Github hier zu durchsuchen wäre ein wenig overkill :-)
Das Installieren von Adapter VON npm ist aber auch via Katze und 'custom' möglich. Hier kann auch eine npm Referenz (z.B. ioBroker.unify-network@latest' eingegeben werden.
Der eindeutig empfohlene Weg ist aber die Verwendung der Repositories, allen voran des STABLE Repositories.
-
@Scrounger sagte in Test Adapter Unifi Network:
@Dragon sagte in Test Adapter Unifi Network:
Naja, ich habe zwei Accesspoints in der Wohnung und wenn ich mich durch die Wohnung bewege wechselt er automatisch von einem zum anderen Accesspoint. Beim Wechsel wird das Gerät für ca. 10 Sekunden als offline angezeigt. Dabei ist es auch egal wie viel Entprellzeit ich einstelle.Dann scheint bei dir ein generelles Problem mit dem Roaming zu bestehen. Anstatt zu roamen verbinden sich deine clients neu. Das ist kein Problem des Adapters sondern deiner Konfig.
Hi,
also ich habe das auch und es laesst sich meiner Meinung nach nicht im unifi controller verhindern.
Faktisch ist es auch so, dass ein Wechsel zwischen 2 AP ein disconnect und ein connect stattfindet.
Wenn ich das richtig sehe, dann konnte man früher mal die darstellung Zeit des Handovers beeinflussen. Geht aber wohl nicht mehr.Ich habe ein Anwesenheitsscript (schätze mal sowas hat @dragon ebenfalls.). Lösung kann es sein im Script eine offline Meldung für ca. 10 sek zu ignorieren und erst bei längerer offline Zeit die Abwesenheit zu registieren.
Ähnliches könnte man sich für den Adapter vorstellen (Entprellzeit oder Pufferzeit - wie auch immer)
Das ist kein Bug sondern m.E. ein Feature Request
vG Looxer
@looxer01 sagte in Test Adapter Unifi Network:
@Scrounger sagte in Test Adapter Unifi Network:
@Dragon sagte in Test Adapter Unifi Network:
Naja, ich habe zwei Accesspoints in der Wohnung und wenn ich mich durch die Wohnung bewege wechselt er automatisch von einem zum anderen Accesspoint. Beim Wechsel wird das Gerät für ca. 10 Sekunden als offline angezeigt. Dabei ist es auch egal wie viel Entprellzeit ich einstelle.Dann scheint bei dir ein generelles Problem mit dem Roaming zu bestehen. Anstatt zu roamen verbinden sich deine clients neu. Das ist kein Problem des Adapters sondern deiner Konfig.
Hi,
also ich habe das auch und es laesst sich meiner Meinung nach nicht im unifi controller verhindern.
Faktisch ist es auch so, dass ein Wechsel zwischen 2 AP ein disconnect und ein connect stattfindet.
Wenn ich das richtig sehe, dann konnte man früher mal die darstellung Zeit des Handovers beeinflussen. Geht aber wohl nicht mehr.Ich habe ein Anwesenheitsscript (schätze mal sowas hat @dragon ebenfalls.). Lösung kann es sein im Script eine offline Meldung für ca. 10 sek zu ignorieren und erst bei längerer offline Zeit die Abwesenheit zu registieren.
Ähnliches könnte man sich für den Adapter vorstellen (Entprellzeit oder Pufferzeit - wie auch immer)
Das ist kein Bug sondern m.E. ein Feature Request
vG Looxer
In der v1.2.0 hab ich eine entprell moglichkeit genau für diesen Fall eingebaut, global und gezielt für clients.
Trotzdem sollte das bei ausreichender Abdeckung und korrekter Konfiguration eigentlich nicht passieren und die clients sollten roamen statt nen reconnect.
-
@Dragon sagte in Test Adapter Unifi Network:
Ich habe versucht einen Bug report auf GitHub zu erstellen. Mittlerweile wird man so schikaniert, dass selbst das erstellen eines Bug Reports gefühlt 45 Minuten dauert.
Naja, ich habe zwei Accesspoints in der Wohnung und wenn ich mich durch die Wohnung bewege wechselt er automatisch von einem zum anderen Accesspoint. Beim Wechsel wird das Gerät für ca. 10 Sekunden als offline angezeigt. Dabei ist es auch egal wie viel Entprellzeit ich einstelle. Erst mit einem Timeout im Skript komme ich weiter und verhindere diese kurzen "Abwesenheitsmomente"Mal langsam mit den "wilden Pferden"!
Du nutzt einen kostenlosen Adapter, den jemand in seiner Freizeit schreibt und wartet für die comminity! Da wird es doch nciht zu viel verlangt sien, einen ausführlichen Report zu schreiben, der dem Entwickler die Möglichkeit gibt den Fehler nachzuvollziehen und zu verstehen, um der Sache dann freundlicherweise nachzugehen.Ein bißchen mehr "Bitte" und "Danke" wäre angezeigt, statt unmäßiger Erwartungshaltung.
PS: Schon mal überlegt, dass diese Problematik vom Router kommen könnte (nur eine Vermutung - weil das Ding echt träge reagiert)?
-
Entschuldigt, den harschen Post. Ich habe mich über Github etwas geärgert und wie heist es so schön. Erst abkühlen und dann handeln.... Das muss man sich immer wieder bewusst machen. Ich würde tatsächlich nie schlecht über die Entwickler hier sprechen. Habe bisher nur sehr gute Erfahrungen mit Adapterentwicklern gemacht, welche sich sogar Zeit nehmen und Probleme mit einzelnen Services etc. sogar im Vier Augen Gespräch beheben. Also vom Support bin ich sehr begeistert.
Ich hatte mich bei Github darüber aufgeregt, dass man früher die Infos aus dem Broker und alle anderen Sachen einfach in das Fehlerbeschreibungsfeld kopieren konnte. Nun muss man Furz und Feuerstein alles in einzelne Vorgefertigte Felder eintragen. Das dauert ewig, im Gegensatz zu dem wie es früher mal lief.
So, nun aber genug zum Github Ärger.
Ich habe ja die 1.1.6 installiert, dort gibt es auf der ersten Konfigseite auch eine Zeit zum einstellen. Ich hatte gedacht, dass dieses die Entprellzeit ist, aber wenn ich mich da getäuscht habe, dann werde ich mal den Latest versuchen und schauen ob mein Problem damit behoben ist.
Mit seiner Vermutung hatte @looxer01 absolut recht. Ich habe ein Anwesenheitsskript, welches ständig zwischendurch die Lampen auschaltete, da dies ein Teil der Abwesenheitssteuerung war. Seine Idee, wie dies zu beheben ist, habe ich genau so umgesetzt. Mit einem Timeout.
Vielen Dank für eure Arbeit. Werde Besserung geloben und wie gesagt die Schikane bezog sich auf Github nicht auf den Entwickler. -
Entschuldigt, den harschen Post. Ich habe mich über Github etwas geärgert und wie heist es so schön. Erst abkühlen und dann handeln.... Das muss man sich immer wieder bewusst machen. Ich würde tatsächlich nie schlecht über die Entwickler hier sprechen. Habe bisher nur sehr gute Erfahrungen mit Adapterentwicklern gemacht, welche sich sogar Zeit nehmen und Probleme mit einzelnen Services etc. sogar im Vier Augen Gespräch beheben. Also vom Support bin ich sehr begeistert.
Ich hatte mich bei Github darüber aufgeregt, dass man früher die Infos aus dem Broker und alle anderen Sachen einfach in das Fehlerbeschreibungsfeld kopieren konnte. Nun muss man Furz und Feuerstein alles in einzelne Vorgefertigte Felder eintragen. Das dauert ewig, im Gegensatz zu dem wie es früher mal lief.
So, nun aber genug zum Github Ärger.
Ich habe ja die 1.1.6 installiert, dort gibt es auf der ersten Konfigseite auch eine Zeit zum einstellen. Ich hatte gedacht, dass dieses die Entprellzeit ist, aber wenn ich mich da getäuscht habe, dann werde ich mal den Latest versuchen und schauen ob mein Problem damit behoben ist.
Mit seiner Vermutung hatte @looxer01 absolut recht. Ich habe ein Anwesenheitsskript, welches ständig zwischendurch die Lampen auschaltete, da dies ein Teil der Abwesenheitssteuerung war. Seine Idee, wie dies zu beheben ist, habe ich genau so umgesetzt. Mit einem Timeout.
Vielen Dank für eure Arbeit. Werde Besserung geloben und wie gesagt die Schikane bezog sich auf Github nicht auf den Entwickler.@Dragon sagte in Test Adapter Unifi Network:
Ich habe ja die 1.1.6 installiert, dort gibt es auf der ersten Konfigseite auch eine Zeit zum einstellen. Ich hatte gedacht, dass dieses die Entprellzeit ist, aber wenn ich mich da getäuscht habe, dann werde ich mal den Latest versuchen und schauen ob mein Problem damit behoben ist.
Meinst du die Entprellzeit?

Die hat damit überhaupt nix zu tun.
Ist nur wichtig wenn man ein nicht so performantes system hat, da die Echtzeit API im sekundentakt dein System mit status nachrichten fluten kann. Mit dieser Einstellung kannst du das entprellen und last von deinem system nehmen. Echtzeit Events wie z.B. Client connect / disconnect ist davon nicht betroffen.Seit v1.2.0

kann man eine Entprellzeit für connect / disconnect setzen. Einmal global für alle clients oder für einzelne Clients eigene Zeiten. Damit sollte das Skript überflüssig werden.