Hallo,
ein NodeMCU mit ESPEasy Mega zickt mächtig. Er ist im 1.OG eingesetzt, will sich partout mit dem Wlan im EG verbinden, obwohl sich im 1.OG in 1-2 Meter ein weiteres UniFi-Wlan-Gerät befindet. Beide Wlan-Geräte haben dieselbe SSID.
Die Verbindung zum Wlan im EG liegt so bei -90 bis -95 dB, beim Ping kommen grottige Zeiten bis zu einigen Sekunden und Verluste von 10-20% raus. Zum Wlan im OG gibt es sehr gelegentlich eine Verbindung, dann beträgt das Signal -60 dB.
Gibt es irgendeine Möglichkeit, dass der NodeMCU sich zwingend mit dem besten Wlan verbindet?
Viele Grüße Gisbert
Zum Wlan im OG gibt es sehr gelegentlich eine Verbindung
Das dürfte Dein Problem sein. Ein Gerät hält seine Verbindung, bis diese nicht mehr "da" ist, d.h. wenn eine verbindung gut, aber manchmal "weg ist", eine andere schlecht, aber dauerhaft "da", wird die 2. genommen.
Laut Deiner Beschreibung ist dieses bei Dir der Fall.
Ist übrigens ein bekanntes Problem bei WLAN.
Hallo Wernieman,
deine Erklärung leuchtet mir schon ein, aber es ist das einzige Gerät auf der ESP-Seite, das solche Sperenzien macht. Alle anderen ESPs wählen sich brav in das jeweils beste Wlan ein, auch in das im OG. Deshalb glaube ich eher nicht das das Wlan-Gerät (ist übrigens ein UniFi UAP-AC-LR) die Ursache ist.
Ich hab schon an die vorhandene Antenne beim ESP eine Verlängerung (nach Anleitung) angelötet, scheint aber nicht wirklich viel zu bringen.
Der UniFi Controller sagt bei der TX Rate bei allen Wlan-Geräten ca. 70 Mbps, bei einem weiteren sehr weit entfernten Gerät 10 Mbps und bei dem besagten NodeMCU 1 Mbps.
Gibt es keine weitere Möglichkeiten (außer Austausch des NodeMCU)?
Viele Grüße Gisbert
Bei Tasmota wurde vor ein paar Wochen das WLAN modifiziert. Dort wird nun ,,ab und zu"(tm) nach besseren Verbindungen derselben SSID geschaut und dorthin verbunden. Zumindest habe ich das im Git gelesen.
Gesendet von iPhone mit Tapatalk
Hallo Waldmensch,
vielen Dank für deinen Hinweis. Ich werde der Sache nachgehen. Vermutlich muss ich den NodeMCU ausbauen, wenn es mir nicht gelingt per OTA eine neue Firmware zu flashen.
Viele Grüße Gisbert
als workaround:
du kannst auch eine zweite ssid konfigurieren die nur auf dem einen ap aktiv ist und diese verwenden.
Hallo justme1968,
das ist eine interessante Idee, da es ESP- und Fhemseitig keinerlei Änderungen bedarf, bis auf die neue SSID für den NodeMCU.
Ich bin aber noch etwas am rätseln, wie ich das mit meiner jetzigen Konfiguration im UniFi-Controller am besten umgesetzt bekomme und keine unerwünschten Nebeneffekte generiere.
Meine UniFi-Konfiguration:
- Network 192.xx.yy.1/24 Name: IoTDevices VLAN 2
- Bisher habe ich eine einzige WLAN Group für die IoTDevices und meine "normalen" Geräte
- Wirless Networks "normale" Geräte (Name ist natürlich anders als hier geschrieben, nur um keine Verwirrung zu stiften)
- Wirless Networks IoTZuhause Use VLAN 2
Meine Fragen:
Muss ich ein neues Network 192.xx.zz.1/24 Name: IoTDevicesOG (Name beispielhaft)
VLAN 3 anlegen?
Dann auch Wirless Networks
IoTZuhauseOG Use VLAN 3?
Oder generiere ich besser eine neue WLAN Group?
Was ist einfacher und übersichtlicher?
Viele Grüße Gisbert
ich meine in der aller einfachsten variante konfigurierst du dir eine zusätzliche ssid auf das schon vorhandene vlan und aktivierst diese dann in den ap einstellungen nur für den einen ap.
Hallo justme1968,
mir war nicht klar, dass ich eine neue SSID mit dem gleichem VLAN einrichten kann. Das macht die Sache dann natürlich sehr einfach. Die neue SSID habe ich dann nur auf dem im OG stehenden AP provisioniert, d.h. mein zickiger NodeMCU kann sich jetzt mit der neuen SSID nur auf den AP im OG verbinden (Verbindung läuft jetzt mit ca -50 dB).
Yeahhh, ich hab den NodeMCU in die Knie gezwungen, hoffentlich rächt er sich nicht.
Auf jede Reaktion erfolgt in irgendeiner Weise eine Gegenreaktion, zumindest in der Physik und zwischen Menschen.
Viele Grüße und vielen Dank
Gisbert
Zitat von: Gisbert am 29 Januar 2019, 10:45:37Yeahhh, ich hab den NodeMCU in die Knie gezwungen, hoffentlich rächt er sich nicht.
Auf jede Reaktion erfolgt in irgendeiner Weise eine Gegenreaktion, zumindest in der Physik und zwischen Menschen.
Zu früh gefreut - er rächt sich.
Hatte ich zuvor das Problem, dass er alle 1-2 Wochen aussteigt, ist es jetzt jeden bis jeden zweiten Tag.
Also ist das keine Lösung.
Ich frage mich nur, warum bei guter Verbindung (-55 dB) der NodeMCU so schlecht die Verbindung hält.
Könnte man per Rules in ESPEasy Mega (muss leider diese Software sein, da an 3 GPIOs Temperatursensoren hängen, was bei Tasmota nicht geht) etwas definieren, dass ihn vor dem Einschlafen bewahrt bzw. ihn wieder lebendig macht?
Viele Grüße Gisbert
PS: ich ändere den Titel wieder auf ungelöst.
siehst du auf unifi seite etwas? im log?
Hallo justme1968,
ich hab den UniFi-Controller auf meinem Win10-PC installiert, der aber nicht dauernd läuft; ein Umzug ist auf einen leistungsfähigeren Server als einen RPi geplant, aber noch nicht umgesetzt.
Lange Rede, kurzer Sinn, es gibt keine logs.
Viele Grüße Gisbert
Hast Du nur einen UniFi Accesspoint? Bei >1 AP muss der Controller IMMER laufen, bei nur einem braucht man gar keinen Controller.
Gesendet von iPhone mit Tapatalk
auch mehr als einem ap muss der kontroller nicht immer laufen. aber es ist praktisch.
das muss er für bestimmte features wie gastportal, fast roaming (sowieso nicht empfohlen) und ein ein paar andere.
Ich dächte gelesen zu haben, dass es sonst Probleme beim rooming gibt. Wenn ein Client auf einen anderen AP wechseln soll. Ich habe 6 Pro AP und den Cloudkey, und mir ist von den gefühlt 50 IoT Devices noch keins ,,abhanden" gekommen. Sie haben allerdings eine eigene SSID, die auf 2,4 only läuft.
Gesendet von iPhone mit Tapatalk
Hallo,
ich hab 2 APs, eure Hinweise motivieren mich den Controller umzuziehen. Die IoT-Devices sind einem separaten IP-Adressbereich, und falls per Wlan angebunden, dann nur mit 2,4 GHz.
Glaubt ihr, dass das Problem auf der UniFi-Seite liegt?
Viele Grüße Gisbert
wie oben geschrieben: nur für das fast roaming ist der kontroller nötig. fast roaming ist aber sowieso nicht empfohlen und deprecated.
für 802.11r und 802.11k ist der kontroller nötig, für 802.11k glaube ich aber sogar nur für den scan, nicht für das handover.
ansonsten ist das roaming eine reine client entscheidung. weder der ap noch der kontroller können einen ap zum roaming zwingen.
@Gisbert: für die zweite ssid solltest du nur 2.4ghz aktivieren und die diversen optimierungen die der kontroller inzwischen kann erst mal deaktivieren.
Zitat von: Gisbert am 02 Februar 2019, 17:10:14
Hallo,
ich hab 2 APs, eure Hinweise motivieren mich den Controller umzuziehen. Die IoT-Devices sind einem separaten IP-Adressbereich, und falls per Wlan angebunden, dann nur mit 2,4 GHz.
Glaubt ihr, dass das Problem auf der UniFi-Seite liegt?
Viele Grüße Gisbert
Just my 2 cts: Soviel Sinn es auch ergibt, dauerhaft einen Controller laufen zu haben (wie justme schon erwähnte: Gastportal, detaillierte Statistiken usw, Zugriff auf die Unifi-Logs,...), sowenig halte ich den Controller bei "normaler" Konfiguration für den Schuldigen in diesem Fall (mit normal meine ich: Kein Fast Roaming, keine Beta-Features usw). Auf dem Win10-PC taugt er Dir jetzt zur Analyse genau so gut, wenn Du ihn einfach mal ein bisschen mitlaufen lässt und einfach mal die Verbindung zur NodeMCU beobachtest.
Was ich überprüfte sind nachbarliche WLANs - damit hatte ich hier auch Probleme, durch entsprechende Channel-Wahl konnte ich dies aber korrigieren. Findest Du im Unifi-Controller unter "insights", wenn ich mich recht entsinne. Interessanten Effekt, den ich hatte: Das WLAN des nachbarlichen Autos fing an, meinen ESP in der Garage zu stören.
Gruß, Tom
meine Waschmaschine werfe ich mit einem beherzten Reconnect auf dem Controller gelegentlich auf den anderen Access Point
sollte also bei ständig laufenden Controller auch mit einem Notify zu erledigen sein ...
oder Methode obskur: Ein wenn Alufolie um den ESP damit der Empfang schlechter wird und er gezwungen wird den richtigen AP zu nehmen ;-)
reconnect funktioniert bei den esp fast nie. die merken sich eigentlich stur den ersten ap den sie nach dem einschalten finden. wenn überhaupt wechseln die nur von sich aus.
das gilt bei mir auch für geräte die einen esp verbaut haben wie die xiamoi lampen.
Hatte ich weiter oben schon geschrieben, Tasmota wechselt automatisch auf einen stärkeren.
Zu ESPEasy, da hatte ich mal einen Mergerequest auf github, mit dem die eindeutige BSSID in der AP Liste angezeigt wurde. Damit konnte man dann gezielt einen AP bei gleicher SSID auswählen. Wurde unbegründet abgelehnt. Bei so viel Ignoranz bin ich dann zu Tasmota gewechselt.
https://github.com/letscontrolit/ESPEasy/pull/101
Gesendet von iPhone mit Tapatalk
Welche Version von ESPEasy fährst Du denn?
Habe gesucht, aber hier im Thread dazu nichts gefunden ...
Noch eine Idee
Knapps den falschen AP aus und verbinde das WLAN im ESP noch einmal neu
Danach kannst Du den bestimmt wieder einschalten
Hallo Werniemann,
ZitatWelche Version von ESPEasy fährst Du denn?
ESP_Easy_mega-20180809_normal_ESP8266_1024.bin
Ich habe einen identischen NodeMCU mit der gleichen Software im EG laufen, der hat zwar wegen räumlicher Situation eine schlechtere Verbindung, läuft aber sehr stabil ohne Reconnects.
Der NodeMCU im OG verbindet sich trotz sehr guter Sendeleistung ständig neu, mal macht er es ein paar Stunden, dann vielleicht nur 10-30 Minuten, etliche Mal, bis er aufgibt.
@Tom,
ich versuche einen anderen Channel, mal sehen, ob ich das hinkriege. Mich wundert jedoch, dass nur dieser und alle anderen kein Problem haben.
Ich versuche den Controller umzuziehen, dann kann ich logs erstellen.
@Ralf,
der böse NodeMCU (OG) verbindet sich ja gelegentlich mit beiden APs. Wenn man ihn lässt, dann verbindet er sich bevorzugt mit dem AP (EG) mit schlechter Sendeleistung und läuft immerhin 1-2 Wochen.
Viele Grüße Gisbert
Hallo Gisbert:
Hintergrund: Ich habe meine 4 APs im Haus so konfiguriert, dass sich die Channels nicht überlappen - will "man" ja nicht. Mein AP, der auch die Garage ausleuchtet, hatte Channel 13. Das war laut meinen Log-Dateien auch der Channel des automobilen Hotspots der nachbarlichen SUV-Inkarnation - und der Erwerb der letzteren hatte zu abnehmender Zuverlässigkeit meiner Testinstallation in der Garage geführt.
Es hat den Anschein, als ob sich mein Wemos d1 mini nach einer Umstellung auf Channel 6 deutlich wohler fühlt. Ist ja im Unifi-Controller nur ein "klick" oder zwei. Und da ich ansonsten nur geringe Störeinflüsse durch andere WLANs habe, konnte ich mir wieder eine überlappungsfreie Config basteln.
Und mal zu prüfen, ob man entsprechende Störeinflüsse hat, ist ja mit dem Unifi-Controller schnell gemacht - oder halt mit dem Handy und einem Wifi-Scanner die Räume ablaufen..
VG Tom
channel 13 sollte man nicht verwenden. die einzigen 2.4ghz kanäle die sichbei ht20 nicht überlappen sind 1, 6 und 11.
Zitat von: justme1968 am 03 Februar 2019, 11:14:53
channel 13 sollte man nicht verwenden. die einzigen 2.4ghz kanäle die sichbei ht20 nicht überlappen sind 1, 6 und 11.
Was meiner aktuellen Config entspricht. Der 13er kam aus dem "initialen" Setup via Controller - und hatte bis zum Auftreten der ESP-Empfangsprobleme in der Garage guten Dienst geleistet.
Hallo,
ich hatte Kanal 6 (OG) und Kanal 11 (EG).
Die Nachbarschaft sendet auf 1, 6 und 11, sind aber alle ziemlich schwach.
Den AP im OG (Distanz zum NodeMCU: ca. 1.5 m) hab ich jetzt auf Kanal 3 eingestellt.
Heute gab es wieder einen Verbindungsabbruch, und der NodeMCU hat sein eigenes Wlan aufgespannt, also es nicht geschafft sich mit dem bekannten Wlan zu verbinden, er hätte sich mit beiden APs verbinden können.
In der ESPEasy Mega-Software gibt es unter dem Reiter Config eine Position "Fallback SSID", hier habe ich jetzt eine 2. SSID eingegeben, die erste für den AP im OG und die 2. für beide APs. Mal sehen, ob das etwas bringt.
Viele Grüße Gisbert
Versuche auch mal eine neuere Version.
Bei mir hat die aktuelle bei einem, der auch häufiger "weg" war, deutliche Verbesserungen gebracht (bis jetzt kein "weg" mehr ...)
Edit:
Rede von Version mega-20190121
Ich würde mal ne andere nodemcu probieren. So teuer sind die Dinger ja nun auch nicht.
Gesendet von iPhone mit Tapatalk
Hallo Wernieman und Waldmensch,
der Gedanke, diesen ESP auszutauschen, am besten gegen einen Wemos D1 mini, der auch ausreichend viele herausgeführte GPIOs hat, ist mir natürlich auch schon gekommen. Vielleicht ist das Teil einfach nur "schlecht". Die Wemos D1 mini, die ich im Einsatz habe, haben bei gleicher Einbausituation nachweislich eine um 10 dB bessere Leistung. Da ich keinen Nachschub mehr habe, werde ich das jetzt machen. Wegen des chinesichen Neujahrsfest dürfte es dann Mitte März werden, bis es bei mir eintrudelt.
Eine neue Softwareversion zu flashen kann ich auch probieren, mal sehen, ob das OTA geht.
Der zuständige AP (OG) läuft jetzt auf einem anderen Kanal, bis jetzt sieht es gar nicht schlecht aus, aber mal abwarten und beobachten.
Viele Grüße Gisbert
Kannst von mir einen haben samt Pfostenleisten.
Geht morgen mit der Post raus.
Ansonsten hätte ich Dir auch einen geben können .... wobei ich mittlerweile "nackte" esp8266 verplane ...
Ist schon eingepackt, adressiert und frankiert... wenn sich der Postbote heute auch noch durch den Schnee kämpft, sollte es ja passen ;-)
Kleine Anmerkung, wo ich das gerade so gelesen habe...
"Ähnliche Effekte" hatte ich auch mit 1 von 4 ESP8266 .
Die liefen alle zuverlässig, aber der eine zickte ständig rum, meldete sich ständig im WLAN ab und nicht immer wieder an etc.
WLAN an sich habe ich ausgeschlossen, und der Effekt trat auch an den identischen Positionen reproduzierbar auf.
Wollte das Ding schon wegschmeissen, bis ich einen letzten Versuch gemacht habe...
Ich habe den ESP einmal komplett gelöscht (also mit so einer Blank-Datei in entsprechender Größe geflasht),
und anschließend noch mal neu geflasht.
Seitdem funktioniert es seit mehreren Monaten völlig problemlos.
Hallo Tom,
vielen lieben Dank, dass du an mich denkst, damit hätte ich nicht gerechnet. Jetzt muss ich wohl mit meinen Vorhaben, Ideen, Wünschen ... vorsichtiger sein ;)
Auch an dich Wernieman, herzlichen Dank für dein Angebot.
@Hollo, guter Gedanke, das werde ich auch versuchen - Flashen einer neueren Softwareversion.
Zwischenstand nach einem Tag nach Ändern des Channels: bisher zwar Reconnects, aber keine fatalen Aussetzer.
Viele Grüße Gisbert
Update nach ca. 3 Tagen:
Wifi-Konfiguration mit 1. SSID ausschließlich zum 1.5 m entfernten AP, 2. SSID zu allen (beiden) APs.
Nachdem ich den Metalldeckel des Heizkreisverteilers geschlossen habe, hat es nicht lange gedauert, bis er wieder beim entfernten AP gelandet war, mit -90 dB - das ist nicht gut.
Ich werde die nächsten Optionen testen:
- neue Firmware
- Austausch gegen einen Wemos D1 Mini
wie kann er be falschen ap landen wenn es die ssid dort garnicht gibt?
oder habe ich jetzt etwas falsch verstanden?
Zitat von: justme1968 am 07 Februar 2019, 08:25:15
wie kann er be falschen ap landen wenn es die ssid dort garnicht gibt?
oder habe ich jetzt etwas falsch verstanden?
Im ESP hat er 2 SSIDs eingetragen. Die Erste ist die, welche nur auf dem "guten" AP provisioniert wurde, die zweite ist die bisherige Standard-SSID - sozusagen als Fallback.
Zumindest interpretiere ich das so.
das sollte man vielleicht in diesem fall genau nicht tun da es den zwang auf einen bestimmten ap ja wieder aufhebt.
sonst versuch doch mal im Unifi Conroller den "falschen" AP unter Properties --> Radios --> Advanced --> min RSSI zu setzen
Update vom 8. Feb. 2019:
Wlan-Konfiguration nur mit dem guten AP (nah) funktioniert nicht dauerhaft
Wlan-Konfiguration mit dem guten AP (nah, -50 dB) und zusätzlich als Fallback den weiter entfernten, schlechten AP (-90 dB) funktioniert auch nicht.
Der nächste Schritt ist jetzt den NodeMCU neu zu flashen, OTA geht leider nicht, also muss ich das Ding rauszerren.
@Tom, vielen, lieben Dank, dein Wemos D1 mini ist heute heil angekommen - das wird dann der übernächste Schritt in diesem Kapitel sein, wenn das neu flashen keinen Erfolg bringt.
2019-02-10: Hoffentlich letztes Update zu diesem Thema:
- OTA flashen des NodeMCU hat nicht funktioniert.
- Flashen des NodeMCU mit der neuesten ESPEasy MEGA-Firmware hat funktioniert, allerdings konnte ich mich nicht auf den AP einloggen - ich hatte die Geduld mit diesem Teil verloren und bin zum nächsten Punkt übergegangen.
- Ich hab den neuen Wemos D1 mini lite (von Tom, nochmals lieben Dank) mit der neuesten ESPEasy MEGA-Firmware (Stand 2.2.2019) geflasht - hat sofort auf Anhieb funktioniert, inkl. Verbindung - kleiner Hinweis: es ist ein ESP8255 verbaut, das muss man bei der Auswahl der Binärdatei berücksichtigen.
- Nachdem ich die notwendigen 4.7K-Widerstände für die Dallas DS18B20 noch an den Wemos angelötet habe, habe ich den Wemos wieder im Heizkreisverteilerkasten verbaut und bekomme ca. -50 dBm, wo ich vorher bei dem vermalledeitem NodeMCU -90dBm hatte - wohlgemerkt bei der identischen Einbausituation.
Der Wemos läuft jetzt seit einer Stunde, und hoffentlich die nächsten Wochen oder mehr ohne Neusstart.
Der NodeMCU wird jetzt zerstört, nicht dass ich nochmals auf die Idee komme, das Teil für irgendetwas einzusetzen.
Viele Grüße Gisbert
Update: 13. Feb. 2019
Der Wemos D1 mini lite läuft jetzt seit 80 Stunden ohne jede Unterbrechung oder Neustart sehr stabil bei -50 dBm, länger als der NodeMCU vermutlich je durchgehalten hat.
Na, so soll's sein. Da geht es dem Wemos bei Dir viel besser als bei mir in der Kramkiste ;-)
Hallo
falls hier noch jemand was liest?
habe auch Probleme mit unifi und ESP....ss
Bei mir ist es so, dass der ESP nicht von überall mit curl / http zu erreichen ist aber verbunden ist.
Fhem und Unifi controller zeigen die ESPs als verbunden an.
Habe hier Unifi auch in Verdacht als Ursache....habe dort im Unifi Forum auch was geschrieben.....
Sachverhalt noch immer unklar....
habt ihr mit unifi und ESPs keine Probleme mehr?
Zitat von: riker1 am 03 Juni 2019, 13:04:14
Hallo
falls hier noch jemand was liest?
habe auch Probleme mit unifi und ESP....ss
Bei mir ist es so, dass der ESP nicht von überall mit curl / http zu erreichen ist aber verbunden ist.
Fhem und Unifi controller zeigen die ESPs als verbunden an.
Habe hier Unifi auch in Verdacht als Ursache....habe dort im Unifi Forum auch was geschrieben.....
Sachverhalt noch immer unklar....
habt ihr mit unifi und ESPs keine Probleme mehr?
Hab seit ca. 2 Wochen auch Unifi APs (2 AC Pro plus 1x Mesh) und hatte noch nie Probleme mit meinem ESP.
ESP12E eigener Sketch allerdings...
Und ein disconnect (wie es im Unifi-Modul heißt) bzw. reconnect (wie es auf der Unifi-Controller-Seite [jetzt?] heißt) funktioniert problemlos bzw. musste ich es nur 1 / 2 mal machen: als der "neue" Mesh hinzu kam und dann noch mal nachdem ich ihn fest montiert hatte (da war er ja mal wieder kurz weg ;) )...
Ansonsten werde ich für "falsch verbundene Clients" ein notify+myUtils-Sub einrichten in Verbindung mit dem Unifi-Modul, die das dann per "disconnect" wieder "gerade biegt"... :)
Gruß, Joachim
Leider lese ich diesen Thread jetzt erst. Nachdem ich von Fritzbox/Repeater auf UniFi-APs umgestellt habe, hatte ich zuerst das gleiche Problem. Bei mir war ein Sonoff (mit ESPeasy) betroffen, der unmittelbar neben einem der UniFi-APs verbaut war, es scheint also wirklich an "zu gutem Empfang" zu liegen. Ich habe mich mit dem Problem leider ebenfalls recht lange herumgeschlagen. Zuerst habe ich an defekte HW geglaubt und den Sonoff gegen einen identischen getauscht, der aber das gleiche Fehlerbild zeigte. Ich habe dann letztlich mehrere, auch teils exotische ESPeasy-Versionen ausprobiert; nichts half.
Letztlich habe ich irgendwann unter "Advanced -> special Settings" die Einstellungen "Force WiFi B/G" und "Force WiFi No Sleep" gefunden und aktiviert. Das war vor mehreren Wochen, seitdem läuft der Sonoff wieder unauffällig. Ich habe allerdings nicht mehr gegengetestet, ob der Fehler wieder kommt, wenn ich das wieder umstelle. Somit weiß ich auch nicht, welche dieser beiden Optionen ggf zum Erfolg geführt hat (evtl beide in Kombination, vielleicht aber auch irgend etwas ganz anderes, was ich nicht auf dem Schirm habe). Das wäre ein Fall für "Jugend forscht", vielleicht fühlt sich ja jemand berufen :-)
Dein armer, zertrümmerter NodeMCU war aber wahrscheinlich unschuldig ...
Habe hier ein komplettes Unifi WLAN und ca 40 ESP. Gemischt Tasmota und Espeasy. Die Espeasy haben ab und zu die Verbindung verloren. Da gibt es aber ein Setting ,,reboot wenn kein wifi" oder so ähnlich. Das habe ich aktiviert, seitdem ist Ruhe. Ich habe für die ESP eine separate SSID eingerichtet die nur 2,4GHZ sendet.
Gesendet von iPhone mit Tapatalk
Hmm, zu guter Empfang?
Zu nahe?
Also mein ESP auf dem Balkon ist ca. 1,5m-2m vom AP (Mesh) weg...
Habe Power auf Auto und wie geschrieben keinerlei Probleme...
...aber auch kein ESPeasy etc.
Zitat von: Waldmensch am 03 Juni 2019, 14:00:39
Die Espeasy haben ab und zu die Verbindung verloren. Da gibt es aber ein Setting ,,reboot wenn kein wifi" oder so ähnlich. Das habe ich aktiviert, seitdem ist Ruhe.
Vielleicht liegt es bei mir auch daran, habe sowas selbst in meinen Sketch eingebaut, da ich vorher (auch ohne Unifi APs) auch ab und an Verbindungsproblemchen hatte...
...aber eher, wenn ich mit 2 Browsern auf den ESP los bin (HTTPMOD aus fhem und vom Handy während des Befüllens meines Wassertanks, damit ich schneller sehe, wenn er voll ist und ich abdrehen muss/sollte)...
Gruß, Joachim
Zitat von: MadMax-FHEM am 03 Juni 2019, 13:14:44
Ansonsten werde ich für "falsch verbundene Clients" ein notify+myUtils-Sub einrichten in Verbindung mit dem Unifi-Modul, die das dann per "disconnect" wieder "gerade biegt"... :)
Gruß, Joachim
Hi Joachim,
könntest du die enstprechenden Devices mal hier reinhängen? Danke
Zitat von: riker1 am 03 Juni 2019, 14:28:58
Hi Joachim,
könntest du die enstprechenden Devices mal hier reinhängen? Danke
Ich hab das ja noch nicht umgesetzt...
Aber hier sind die entsprechenden Infos zu dem (den) Modul(en) die ich dafür nehmen will/werde:
https://wiki.fhem.de/wiki/Unifi
https://forum.fhem.de/index.php/topic,40287.msg325212.html#msg325212
(brauche ich hierfür eigentlich nicht ;) https://forum.fhem.de/index.php/topic,99864.msg932489.html#msg932489)
Im Unifi-Controller-Device stehen alle (Wifi)Clients mit zugehörigem AP.
Mein (aktueller) Plan:
da ein Notify auf _accesspoint (oder wie das Reading genau heißt)
dann eine Sub in myUtils, die anhand einer Liste prüft, ob der Client am "richtigen" AP angemeldet ist und wenn nicht, dann eben ein set UnifiController disconnect ClientName ;)
(in der Hoffnung [und bislang war es immer so], dass er sich dann mit dem gewünschten verbindet / ich werde nat. nicht "ständig" disconnecten, sondern halt noch eine "Strategie" für ganz unwillige etc. überlegen)
Gruß, Joachim
Vielen Dank Joachim,
bei mir ist das Szenario etwas anders.
ESPs sind am unifi AP angemeldet.
Können aber nicht von allen anderen Devices erreicht werden.
1. andere Rechner im Netz können zwar den ESP anpingen, aber nicht mit curl eine response bekommen, bzw das Webgui öffen. Bei dem Rechner auf dem der Controller von Unifi läuft geht es meist.
2. andere WLAN Clients ( Handy) - auf an Unifi AP Connected - können den ESP nicht erreichen (weder Lan Ping noch Webgui (curl)
das ganze ist irgendwie sehr merkwürdig.
Unifi selbst sagte, das es ein Problem mit Mesh APs gab. Davon hatte ich eines. Aber es gab ein Update und auch ohne MESH AP geht es nicht immer.
Kann natürlich auch am ESP liegen, ab der die meist schon länger ohne restart laufen, und webgui auch bei dem einen Rechner mit Unifi Contoller (da Läuft auch FHEM drauf) funktionieren.
Habe bei Fhem auch presensce-checks von Otto: System response mit port, lan-ping - etc.
to be continued....
ZitatAnsonsten werde ich für "falsch verbundene Clients" ein notify+myUtils-Sub einrichten in Verbindung mit dem Unifi-Modul, die das dann per "disconnect" wieder "gerade biegt"... :)
Gruß, Joachim
Daran bin ich auch interessiert, getreu dem Motto "Vertrauen ist gut, Kontrolle ist besser" ... aber nur auf Bezug von Dingen, nicht Menschen!
Nach der vor ein paar Monaten geschilderten Aktion hatte ich bisher keinen einzigen Ausfall. Unifi läuft ohne Probleme; der Betreuungsaufwand ist minimal.
Viele Grüße Gisbert
Es gibt ja einen Thread/Wiki mit Anwendungsfällen für Unifi...
Wenn ich es mal habe (jetzt sind ja demnächst wieder ein paar Feiertage ;) :) ) stelle ich es dann dort ein (sofern ich das wieder finde ;) )...
Gruß, Joachim