OBI Funk-Steckdosenumbau ESP8266 (Generation1 Rund)
-
Nachdem Tom ganz zu Beginn den Sinn eines Temperatursensors in der Dose IMHO zu Recht in Frage gestellt hatte, hätte ich als arduino/esp noob eine Frage.
Kann man stattdessen vielleicht einen Luftgütesensor, analog zum wiffi einbauen?
Das wäre für meine Zwecke wesentlich sinnvollet.
Gruß Rainer
-
Ich will hier Sissi nicht vorgreifen, aber das sollte eigentlich bei der Version 1.1.1b oder 1.1.1c gefixt sein. Hast du die "Vanilla" 1.1.1 genommen, oder eine der späteren mit Bugfix? Probier es doch am besten nochmal mit der 1.1.1c und dem Passwort ohne 32 Leerzeichen. Wenn das Problem da immer noch auftritt, sag Bescheid `
Wir hatten die 1.1.1b einmal bei dem ersten Updateversuch geflasht gehabt. Allerdings hatten wir wahrscheinlich den Fehler gemacht direkt von der Startversion zur 1.1.1b zu flashen. Anschließend war die Steckdose im WLAN nicht auffindbar und machte auch keinen AP mehr auf. Wir hatten gedacht das die Version vielleicht fehlerhaft ist und hatten daher noch mal von vorne angefangen und dann Stück für Stück die neueren Versionen geflasht und so ging es und hatten als letztes die 1.1.1 genommen, weil wir eben dachten die b Version wäre fehlerhaft. Ich denke der Fehler lag aber eher bei uns, daher werde ich die 1.1.1c dann gleich mal drüber installieren und hoffe damit geht dann weiterhin noch alles
Ich danke dir zu den Infos mit dem Temperatursensor. Das klingt für mich zunächst erstmal doch recht kompliziert, Arduino ist für mich wie schon gesagt komplettes neuland. Hab zwar ein paar Grundkentnisse was sowas angeht aber ich denke dafür müsste ich mich noch mal genauer rein lesen in die Materie. Ich hatte gehofft das geht einfacher und man müsste den Sensor wirklich nur anlöten und der liefert die Daten über diese Firmware die hier angeboten wird. Aber wenn da weitere anpassungen nötig sind, dann muss ich mich da noch ein wenig rein lesen.
Noch mal eine andere Frage - kennt jemand eine Möglichkeit die Steckdosen auch von außerhalb des lokalen Netzwerkes erreichbar zu machen, was sich dann über Android steuern lässt? Quasi ein ersatz für die original Software, die bei der Steckdose auf dem Smartphone installiert wird? Ich meine natürlich ohne ein Zwischengerät wie einen Raspberry. Ich habe bei mir einen Raspberry laufen und steuere die Steckdosen via Openhab2. Funktioniert alles hervorragend. Aber mein Bruder hat auch einige von den Steckdosen, jedoch kein Raspberry und möchte auch keinen extra dafür anschaffen. Vielleicht kennt da ja jemand eine App, um sowas zu realisieren?
Ich habe schon einen Lösungsansatz dafür, der schon ganz gut und einigermaßen einfach funktioniert. Ich habe auf meiner Fritz.Box einfach ein VPN freigegeben und wähle mich über das Smartphone in dieses per DynDNS ein. Wenn man da nun verbunden ist, kann man die IP aus dem lokalen Netzwerk auch von "außen" aufrufen und die Steckdosen schalten. Die Lösung funktioniert eigentlich schon sehr gut, allerdings muss man sich jedes mal im Handy durch die Einstellungen wursteln bis zur VPN Verbindung und man muss dann ein Lesezeichen zum Beispiel aufrufen, um die Steckdose zu steuern. Kein Beinbruch aber geht das noch einfacher und "Idiotensicherer"?
Sonst wäre das sicher mal eine nette Idee für jemanden der gut ist im programmieren für Android
Vielleicht eine App, die im Hintergrund beim starten der App eine VPN Verbindung aufbaut (setzt natürlich ein Router vorraus, der dies unterstützt) und dann mit einer Liste aus eingetragenen IPs für die Steckdosen eine kleine Steuerungsoberfläche zur Verfügung stellt und damit sozusagen die original Software ersetzt. Halt ohne irgendwelche China Server dazwischen, das würde die Steckdose für seinen preis noch besser machen als sie sowieso schon ist -
Nachdem Tom ganz zu Beginn den Sinn eines Temperatursensors in der Dose IMHO zu Recht in Frage gestellt hatte, hätte ich als arduino/esp noob eine Frage. `
Also den Temperatursensor würde ich auch nicht in das Gehäuse einbauen, da wirds doch recht kuschelig warm. Aber wenn man da 50-100 cm Kabel dazwischenlegt, hat das für meine Zwecke einen sinnvollen Nutzen: Thermostat-Regelung einer elektrischen Heizeinrichtung. Ja, die Heizung selbst hat wirklich keinen eingebaut
Kann man stattdessen vielleicht einen Luftgütesensor, analog zum wiffi einbauen?
Das wäre für meine Zwecke wesentlich sinnvollet. `
Man könnte sicherlich vieles anschließen, was nicht mehr als die 3 prinzipiell herausgeführten Pins (GPIO0, RX, TX) zur Kommunikation braucht, und wofür es Arduino- bzw. ESP8266-Bibliotheken gibt. 1-Wire Sensoren kommen mit einer Datenleitung aus, ebenso der DHT22. Allerdings können die nicht auf der selben Leitung laufen, fürchte ich. Mann kann aber (fast) beliebig viele 1-Wire Sensoren an dieselbe Leitung hängen.
Programmieren muss man das ganze natürlich trotzdem noch… einfach nur die Pins verbinden reicht leider nicht, um die Werte auszulesen und dann dem ioBroker zur Verfügung zu stellen.
Grüße,
Alex
-
Hi,
schön das hier was los ist. Der Fehler mit dem Passwort sollte eigentlich behoben sein.
Muss das nochmal prüfen. Mein BHT22 ist aufm weg und kommt zwischen gestern und in 4 Wochen an.
Dann kann man da sicherlich was machen. Die Dose entwickelt allerdings eine gewisse Eigenwärme.
Ich weiss nicht ob es deshalb sinnvoll ist den Sensor da rein zu bauen.
Hatte eigentlich vor so etwas mit einen esp12e zu realisieren und dann mit mehreren Sensoren und möglichst per Batterie …
Aber erstmal die neue Version:
Was ist neu: Laststate, d.h. wenn Stromausfall, dann geht sie wieder in den letzten Status zurück.
Das ist jetzt realisiert über SPIFFS, d.h. nicht EEPROM-Simulation sondern Filesystem.
Das gibt dann auch neue Möglichkeiten, z.B. die Messwerte von Temperatursensoren zu speichern.
Die blaue LED ist jetzt entkoppelt. In der Initialisierungphase blinkt sie schnell, schneller beim suchen des WLANs und noch schneller wenn der AP aufgespannt wird.
Ansonsten blinkt sie nach Abschluss der Initalisierung 10x
Im Betrieb ist sie nur kurz an wenn der Schalter auf PowerON geht.
Ansonsnten wenn auf einen Schaltvorgang gewartet wird, blinkt sie alle 3 Sekunden.
Unter der Haube werden alle 5 Sekunden alle relevanten Verbindungen gecheckt.
Ist das Gateway länger als 120 Sekunden nicht erreichbar wird ein Wifi-Reconnect versucht.
Sind CCU oder ioBroker nicht erreichbar, dann wird das protokolliert.
Code wurde optimiert. Man sieht es am Speicherverbrauch.
Es wird die tatsächliche Speichergröße und der Flashmodus angezeigt.
Ansonsten sicherlich noch etliche kleinere Verbesserungen.
-
Lange rede, kurzer Sinn: das erneute eingeben von WLAN Zugangsdaten hat bei der 1.1.1 bei mir nicht geklappt. Der WLAN Schlüssel scheint irgendwie nicht gespeichert zu werden oder er wird als falsch gespeichert. Vielleicht kann sich das hier ja jemand einmal anschauen, ob es da irgendwo einen Fehler gibt? Oder habe ich einfach etwas übersehen oder vergessen? `
Ich will hier Sissi nicht vorgreifen, aber das sollte eigentlich bei der Version 1.1.1b oder 1.1.1c gefixt sein. Hast du die "Vanilla" 1.1.1 genommen, oder eine der späteren mit Bugfix? Probier es doch am besten nochmal mit der 1.1.1c und dem Passwort ohne 32 Leerzeichen. Wenn das Problem da immer noch auftritt, sag Bescheid!
Ich habe in einem ct Magazin Bericht gelesen, dass man die Steckdose auch um Temperatursensoren erweitern kann, wie den DHT22. Man kann diesen wohl einfach an VCC, GND und RX anschließen und dann soll dieser die Temperaturdaten über WLAN senden. Die Frage ist, kann man das empfangen dieser Daten mit dieser Firmware hier irgendwie realisieren? Hat sich daran schon mal jemand versucht? Bin noch recht neu in diesem Gebiet, daher diese Frage. `
Ich habe den Source-Code für einen DS18B20 Temperatursensor angepasst, der an VCC, GND und inwischen RX (vorher GPIO0) hängt. Einen DHT22 habe ich nicht, aber die nötigen Änderungen scheinen recht übersichtlich zu sein, wenn man schon mal mit der Arduino-Umgebung für ESP8266 gearbeitet hat und sich daran versuchen will. Ich denke, man kann sich da ein Stück weit z.B. am Abschnitt "Setup" und "Code" in https://www.losant.com/blog/getting-started-with-the-esp8266-and-dht22-sensor orientieren. Wenn man RX dafür nutzen will, sollte man jedenfalls die serielle Schnittstelle folgendermaßen umkonfigurieren:
Serial.begin(115200,SERIAL_8N1,SERIAL_TX_ONLY); // statt Serial.begin (115200);Die TX-Leitung kann man dann immer noch für die Ausgabe mit Serial.println nutzen - Stichwort Debugging
Der RX liegt auf GPIO-Pin 3, den muss man dann für die Abfrage des Sensors nutzen.
Grüße,
Alex `
Serial.begin(115200,SERIAL_8N1,SERIAL_TX_ONLY); // statt Serial.begin (115200);Hab ich vorgemerkt. Version > 1.1.3 hat das dann
-
Richtig genialer Support hier!
Mit dem Temperatursensor bin ich auch der Meinung das man da einfach längere Kabel anlöten kann, dann kann man ihn auch ausserhalb des Gehäuses führen. Meine mal gelesen zu haben dass da längen bis 10m nicht mal ein Problem wären, man müsste nur den Pullup Widerstand entsprechend anpassen. Es gibt übrigens auch den DHT22 in Form einer schon fertigen Platine, wo der aufgelötet ist und der Widerstand per SMD Bauteile gelöst ist. Man hat somit dann schon die fertigen 3 Pins zum verbinden (GND, Daten und VCC 3,3v). Betreibe derzeit zwei davon an meinem Raspberry Pi an den GPIO Pins und die funktionieren hervorragend, loggen Außen und Innentemperatur mit langen Kabeln und schreiben sie per Python Script in eine MySQL Datenbank, die dann per Grafana ausgewertet wird. Wenn man das für ein paar kleine Euros an den Steckdosen via WLAN erweitern kann, dann wäre das natürlich richtig geil.
Was aber natürlich richtig cool wäre, wenn man in der Steckdosenübersicht dann zusätzlich noch die Werte für den angeschlossenen Temperatursensor stehen hätte und der sich auch in Echtzeit aktualisiert
Ich habe die Version 1.1.1c vorhin drüber gejagt und bestätige, dass das WLAN Schlüssel Problem behoben ist! Habe extra noch mal die Dose zurückgesetzt, AP neu eingerichtet, WLAN Schlüssel wurde ohne umschweife sofort übernommen und war im WLAN
-
Richtig genialer Support hier!
Mit dem Temperatursensor bin ich auch der Meinung das man da einfach längere Kabel anlöten kann, dann kann man ihn auch ausserhalb des Gehäuses führen. Meine mal gelesen zu haben dass da längen bis 10m nicht mal ein Problem wären, man müsste nur den Pullup Widerstand entsprechend anpassen. Es gibt übrigens auch den DHT22 in Form einer schon fertigen Platine, wo der aufgelötet ist und der Widerstand per SMD Bauteile gelöst ist. Man hat somit dann schon die fertigen 3 Pins zum verbinden (GND, Daten und VCC 3,3v). Betreibe derzeit zwei davon an meinem Raspberry Pi an den GPIO Pins und die funktionieren hervorragend, loggen Außen und Innentemperatur mit langen Kabeln und schreiben sie per Python Script in eine MySQL Datenbank, die dann per Grafana ausgewertet wird. Wenn man das für ein paar kleine Euros an den Steckdosen via WLAN erweitern kann, dann wäre das natürlich richtig geil.
Was aber natürlich richtig cool wäre, wenn man in der Steckdosenübersicht dann zusätzlich noch die Werte für den angeschlossenen Temperatursensor stehen hätte und der sich auch in Echtzeit aktualisiert
Ich habe die Version 1.1.1c vorhin drüber gejagt und bestätige, dass das WLAN Schlüssel Problem behoben ist! Habe extra noch mal die Dose zurückgesetzt, AP neu eingerichtet, WLAN Schlüssel wurde ohne umschweife sofort übernommen und war im WLAN
`Super das mit der 1.1.1c.
Meine DHT22 sind aufm Weg. mal sehen wann sie kommen. 3 für 8 Euro.
Langsam wird die Website zu klein. Überlege ob ich die Hilfe zumindest auf eine zweite Seite setze.
-
Ganz genau diese DHT22 meine ich! Die sind wirklich top. Wäre echt klasse wenn man die integriert bekommt.
ich habe nun mal die aktuelle Version 1.1.3 installiert. Funktioniert soweit alles einwandfrei bis auf eine kleine Sache, in dem Log der Dose wiederholt sich ständig die Meldung
00:00:00 18.08.2018 Gateway not reach
00:00:05 18.08.2018 Gateway not reach
00:00:10 18.08.2018 Gateway not reach
00:00:16 18.08.2018 Gateway not reach
00:00:16 18.08.2018 Wifi.Reconnect bad Ping Gateway done
Hat das irgendwas zu bedeuten und kriegt man das irgendwie aus? Oder einfach ignorieren? Die Dose funktioniert ja trotzdem. Auch wegen dem CuxD hat er in Schleife immer wieder einen Fehler ausgegeben allerdings war der weg, wenn man CuxD auf OFF stellt.
Nachtrag zur Version 1.1.3
Also seitdem ich diese Version installiert habe, machen die Steckdosen plötzlich richtig Probleme. Neben diesen Gateway Meldungen sind die Steckdosen ganz plötzlich nicht mehr erreichbar. War man eben noch in der Weboberfläche, reagieren sie plötzlich nicht mehr, will man die Seite aufrufen kommt irgendwann die Meldung das er sie nicht gefunden hat. Manchmal ist die Web Oberfläche dann erreichbar, sie baut sich aber nur halb auf. Es fehlen die Steuerelemente zum Beispiel und die Tabelle wird auch nicht komplett angezeigt…
Sieht dann so aus:
Nachtrag #2
ich habe jetzt noch mal ein wenig rum getestet und kann nun eingrenzen woran diese Neustarts liegen und das Problem ist wirklich merkwürdig in meinen Augen. Ich hatte ja gestern schon mal geschrieben, dass ich die Fernsteuerungsmethode mit dem VPN über die Fritz.Box am testen war. Das hatte ich noch einmal wiederholt. Und dadurch müssen diese Fehler zustande gekommen sein. Denn hier das Problem, wenn ich mit dem Handy im WLAN, sprich lokal mit der Steckdose verbinde und die Weboberfläche aufrufe ist alles normal. Öffne den Chrome Browser, rufe die IP auf und es funktioniert alles. Gehe ich in die VPN Verbindung und rufe dann ganz genau auf die gleiche Art die Oberfläche auf, dann stürzt die Steckdose sofort ab und startet sich neu. Bei allen Dosen das gleiche Fehlerbild, sobald ich die IP aufrufe im Browser, startet die Steckdose sofort neu. Ich habe mit dem Terminal Programm versucht den Fehler einzusehen, ob es irgendwelche Fehler gibt. Leider nicht, da wird nichts mitgeloggt in dem Moment. Erst ab da an, wenn die Dose wieder online ist. Jetzt hab ich noch mal das volle Programm abgespielt, alles von vorne geflasht. Habe gedacht das es an der Version 1.1.3 lag. Habe dann wieder die 1.1.1c installiert, gleiches Problem. Nun aber der große Witz an der Sache, gestern mittag hat es problemlos noch funktioniert. Konnte auf die Steckdose über VPN verbinden und sie ohne Probleme steuern. Und noch komischer ist, mit dem Chrome stürzt die Dose ab. Habe dann mal eine App runtergeladen aufs Handy, die heißt HTTP Request Shortcut. Damit kann man HTTP Befehle senden via einer Homescreen Verknüpfung. Dort kann man wählen das die App den Befehl schickt und nicht der Browser. Damit funktioniert es ebenfalls, Dose stürzt nicht ab. Und sobald ich dann wieder in den Chrome gehe und die Dose aufrufe > Absturz. Woran könnte das denn zum Teufel liegen?
-
Ganz genau diese DHT22 meine ich! Die sind wirklich top. Wäre echt klasse wenn man die integriert bekommt.
ich habe nun mal die aktuelle Version 1.1.3 installiert. Funktioniert soweit alles einwandfrei bis auf eine kleine Sache, in dem Log der Dose wiederholt sich ständig die Meldung
00:00:00 18.08.2018 Gateway not reach
00:00:05 18.08.2018 Gateway not reach
00:00:10 18.08.2018 Gateway not reach
00:00:16 18.08.2018 Gateway not reach
00:00:16 18.08.2018 Wifi.Reconnect bad Ping Gateway done
Hat das irgendwas zu bedeuten und kriegt man das irgendwie aus? Oder einfach ignorieren? Die Dose funktioniert ja trotzdem. Auch wegen dem CuxD hat er in Schleife immer wieder einen Fehler ausgegeben allerdings war der weg, wenn man CuxD auf OFF stellt.
Nachtrag zur Version 1.1.3
Also seitdem ich diese Version installiert habe, machen die Steckdosen plötzlich richtig Probleme. Neben diesen Gateway Meldungen sind die Steckdosen ganz plötzlich nicht mehr erreichbar. War man eben noch in der Weboberfläche, reagieren sie plötzlich nicht mehr, will man die Seite aufrufen kommt irgendwann die Meldung das er sie nicht gefunden hat. Manchmal ist die Web Oberfläche dann erreichbar, sie baut sich aber nur halb auf. Es fehlen die Steuerelemente zum Beispiel und die Tabelle wird auch nicht komplett angezeigt…
Sieht dann so aus:
screen.JPG
Nachtrag #2
ich habe jetzt noch mal ein wenig rum getestet und kann nun eingrenzen woran diese Neustarts liegen und das Problem ist wirklich merkwürdig in meinen Augen. Ich hatte ja gestern schon mal geschrieben, dass ich die Fernsteuerungsmethode mit dem VPN über die Fritz.Box am testen war. Das hatte ich noch einmal wiederholt. Und dadurch müssen diese Fehler zustande gekommen sein. Denn hier das Problem, wenn ich mit dem Handy im WLAN, sprich lokal mit der Steckdose verbinde und die Weboberfläche aufrufe ist alles normal. Öffne den Chrome Browser, rufe die IP auf und es funktioniert alles. Gehe ich in die VPN Verbindung und rufe dann ganz genau auf die gleiche Art die Oberfläche auf, dann stürzt die Steckdose sofort ab und startet sich neu. Bei allen Dosen das gleiche Fehlerbild, sobald ich die IP aufrufe im Browser, startet die Steckdose sofort neu. Ich habe mit dem Terminal Programm versucht den Fehler einzusehen, ob es irgendwelche Fehler gibt. Leider nicht, da wird nichts mitgeloggt in dem Moment. Erst ab da an, wenn die Dose wieder online ist. Jetzt hab ich noch mal das volle Programm abgespielt, alles von vorne geflasht. Habe gedacht das es an der Version 1.1.3 lag. Habe dann wieder die 1.1.1c installiert, gleiches Problem. Nun aber der große Witz an der Sache, gestern mittag hat es problemlos noch funktioniert. Konnte auf die Steckdose über VPN verbinden und sie ohne Probleme steuern. Und noch komischer ist, mit dem Chrome stürzt die Dose ab. Habe dann mal eine App runtergeladen aufs Handy, die heißt HTTP Request Shortcut. Damit kann man HTTP Befehle senden via einer Homescreen Verknüpfung. Dort kann man wählen das die App den Befehl schickt und nicht der Browser. Damit funktioniert es ebenfalls, Dose stürzt nicht ab. Und sobald ich dann wieder in den Chrome gehe und die Dose aufrufe > Absturz. Woran könnte das denn zum Teufel liegen?
`Hi,
kannst du mal mit AJAX = 0 testen?
Was sagt die Zeile: Response?
Was ist als Gateway eingestellt? (FIX + Automatisch)
PS: Ich nutze eigentlich nur Chrome…
-
Nachdem Tom ganz zu Beginn den Sinn eines Temperatursensors in der Dose IMHO zu Recht in Frage gestellt hatte, hätte ich als arduino/esp noob eine Frage.
Kann man stattdessen vielleicht einen Luftgütesensor, analog zum wiffi einbauen?
Das wäre für meine Zwecke wesentlich sinnvollet.
Gruß Rainer `
Moin Rainer,
ja kann man
Welcher Sensor sollte es denn werden?
@Alle
Es gibt einen Punkt, warum ich den Einsatz eines Sensors ausserhalb der Dose als kritisch ansehe, das Thema nennt sich elektrische Sicherheit.
Wenn ihr den Sensor mit den normal üblichen Bastelkabel anschließt und nach aussen führt, dann besteht die Gefahr, daß sich eines dieser Kabel lösen kann und an 230V führende Teile kommen könnte. Damit ist dann 230V auf den dünnen Käbelchen.
Dafür sind die weder zugelassen noch wirklich von der Dicke der Isolierung tauglich, um euch vor einem elektrischen Schlag zu schützen. Dieser kann bei 230V tötlich enden.
Wenn ihr Sensoranschlüsse nach aussen verlegt müssen diese zwingend galvanisch getrennt angeschlossen werden!!!!
Bei einem Unfall mit dieser Dose steht ihr nämlich voll in der Haftung, da ihr den Umbau gemacht habt. Und das kann sehr teuer werden.
Bitte überlegt es euch sehr gut, ob das alles den Umbau wert ist, oder ob es nicht besser wäre sich für die Temperatur einen eigenen Sensor zu bauen.
Viele Grundfunktionen der Steckdose lassen sich auch mit jedem anderen ESP benutzen, und mit einem einfachen Steckernetzteil seit ihr dann auch auf der sicheren Seite.
Grüße
Tom
EDIT :
Mit welcher Coreversion und welcher Adrduino Version scheibst du die bin Dateien?
-
Welcher Sensor sollte es denn werden? `
Hallo Tom,Ich habe zwei iaq mit denen ich nicht wirklich glücklich bin.
Mit Eugens wiffi läuft es eigentlich recht gut. Und der schreibt:
> – Luftgütesensor (mit MQ135 oder optional mit MH14)Gruß Rainer
-
Hi,
kannst du mal mit AJAX = 0 testen?
Was sagt die Zeile: Response?
Was ist als Gateway eingestellt? (FIX + Automatisch)
PS: Ich nutze eigentlich nur Chrome… `
AJAX = 0 wurde gesetzt, Zeile Response sagt folgendes: Response : 127ms. Avg : 87ms Blocked : -sec.Allerdings wird diese Zeile nicht mehr angezeigt, wenn ich AJAX = 0 mache.
Gateway habe ich gerade mal fix alles eingestellt und aktiviert. Am PC funktioniert die Dose nach wie vor einwandfrei, am Smartphone noch immer das gleiche Fehlerbild. Sobald ich dort die Steckdosenoberfläche im Chrome öffnen will, während ich mit dem VPN verbunden bin > Absturz der Dose. Allerdings wenn man den VPN ausschaltet, dann funktioniert es plötzlich. Also das scheint diese Kombination VPN + Android Chrome zu sein, die der Steckdose nicht gefallen. Ich frage mich aber halt, warum?
Hier die Gateway Settings in der Oberfläche:
own IP : 192.168.178.116 (Mac:60:01:94:52:30:03)
GATEWAY : FRITZ!Box 7490 2.8
Gateway IP : 192.168.178.1
Gateway Mask : 255.255.255.0
FIX-IP-Status: 1 (0=off/1=on) ON OFF (ON->OFF:reboot)
FIX-IP-Address: 192.168.178.116
FIX-IP-Gateway: 192.168.178.1
FIX-IP-Subnet: 255.255.255.0
Scheint aber auch so alles korrekt zu sein. GateWay IP ist die der Fritzbox und eigene IP Adresse stimmt auch, dass ist die der Dose.
Nachtrag
Kann aber bestätigen, wenn man das CuxD auf 0 setzt und die IP und Gateway FIX setzt, dann scheinen die sich wiederholenden Fehlermeldungen erledigt zu haben. Der VPN Fehler besteht weiterhin auch bei der 1.1.3.
-
Ganz genau diese DHT22 meine ich! Die sind wirklich top. Wäre echt klasse wenn man die integriert bekommt.
ich habe nun mal die aktuelle Version 1.1.3 installiert. Funktioniert soweit alles einwandfrei bis auf eine kleine Sache, in dem Log der Dose wiederholt sich ständig die Meldung
00:00:00 18.08.2018 Gateway not reach
00:00:05 18.08.2018 Gateway not reach
00:00:10 18.08.2018 Gateway not reach
00:00:16 18.08.2018 Gateway not reach
00:00:16 18.08.2018 Wifi.Reconnect bad Ping Gateway done
Hat das irgendwas zu bedeuten und kriegt man das irgendwie aus? Oder einfach ignorieren? Die Dose funktioniert ja trotzdem. Auch wegen dem CuxD hat er in Schleife immer wieder einen Fehler ausgegeben allerdings war der weg, wenn man CuxD auf OFF stellt.
Nachtrag zur Version 1.1.3
Also seitdem ich diese Version installiert habe, machen die Steckdosen plötzlich richtig Probleme. Neben diesen Gateway Meldungen sind die Steckdosen ganz plötzlich nicht mehr erreichbar. War man eben noch in der Weboberfläche, reagieren sie plötzlich nicht mehr, will man die Seite aufrufen kommt irgendwann die Meldung das er sie nicht gefunden hat. Manchmal ist die Web Oberfläche dann erreichbar, sie baut sich aber nur halb auf. Es fehlen die Steuerelemente zum Beispiel und die Tabelle wird auch nicht komplett angezeigt…
Sieht dann so aus:
screen.JPG
Nachtrag #2
ich habe jetzt noch mal ein wenig rum getestet und kann nun eingrenzen woran diese Neustarts liegen und das Problem ist wirklich merkwürdig in meinen Augen. Ich hatte ja gestern schon mal geschrieben, dass ich die Fernsteuerungsmethode mit dem VPN über die Fritz.Box am testen war. Das hatte ich noch einmal wiederholt. Und dadurch müssen diese Fehler zustande gekommen sein. Denn hier das Problem, wenn ich mit dem Handy im WLAN, sprich lokal mit der Steckdose verbinde und die Weboberfläche aufrufe ist alles normal. Öffne den Chrome Browser, rufe die IP auf und es funktioniert alles. Gehe ich in die VPN Verbindung und rufe dann ganz genau auf die gleiche Art die Oberfläche auf, dann stürzt die Steckdose sofort ab und startet sich neu. Bei allen Dosen das gleiche Fehlerbild, sobald ich die IP aufrufe im Browser, startet die Steckdose sofort neu. Ich habe mit dem Terminal Programm versucht den Fehler einzusehen, ob es irgendwelche Fehler gibt. Leider nicht, da wird nichts mitgeloggt in dem Moment. Erst ab da an, wenn die Dose wieder online ist. Jetzt hab ich noch mal das volle Programm abgespielt, alles von vorne geflasht. Habe gedacht das es an der Version 1.1.3 lag. Habe dann wieder die 1.1.1c installiert, gleiches Problem. Nun aber der große Witz an der Sache, gestern mittag hat es problemlos noch funktioniert. Konnte auf die Steckdose über VPN verbinden und sie ohne Probleme steuern. Und noch komischer ist, mit dem Chrome stürzt die Dose ab. Habe dann mal eine App runtergeladen aufs Handy, die heißt HTTP Request Shortcut. Damit kann man HTTP Befehle senden via einer Homescreen Verknüpfung. Dort kann man wählen das die App den Befehl schickt und nicht der Browser. Damit funktioniert es ebenfalls, Dose stürzt nicht ab. Und sobald ich dann wieder in den Chrome gehe und die Dose aufrufe > Absturz. Woran könnte das denn zum Teufel liegen?
`Hi,
konnte das Problem nachstellen. Auch mein VPN hats geschafft die Dose in die Knie zu bringen
Das Problem bei einer langsamen Verbindung war der Speicher. Der ist ihn ausgegangen. Da er schneller ausgeliefert hat als abgeholt wurde.
Das Problem mit dem Gateway ping ist auch gelöst. Hat immer das Gateway genommen, auch wenn feste IP-Adresse.
Ping kann man jetzt ausschalten.
Warum wurde das mit jeder Version schlechter: Die Website wurde immer größer, deshalb gabs Probleme mit dem Speicher.
Jetzt liefert er die Seite Stückchenweise aus.
Funktioniert angelehnt an: https://github.com/letscontrolit/ESPEasy/issues/600
Hier ein Fix. Bitte testen:
-
Hab die 1.1.4 drüber installiert. Leider das gleiche Problem noch immer vorhanden, VPN bringt die Dose noch immer zum neustarten…
-
Hab die 1.1.4 drüber installiert. Leider das gleiche Problem noch immer vorhanden, VPN bringt die Dose noch immer zum neustarten…
`Hi,
Das ist schlecht. Da sie bei mir stabil auch über VPN zu laufen scheint.
Kannst du mal einen Screenshoot deiner Einstallungen machen?
Nutzt du das bin oder Compilierst du selbst?
Was für,eine VPN-Verbindung hast du?
Ich habe WLAN-VPN und 3G-VPN getestet.
-
Hi,
Das ist schlecht. Da sie bei mir stabil auch über VPN zu laufen scheint.
Kannst du mal einen Screenshoot deiner Einstallungen machen?
Nutzt du das bin oder Compilierst du selbst?
Was für,eine VPN-Verbindung hast du?
Ich habe WLAN-VPN und 3G-VPN getestet. `
Hi,
Sicher, Screenshot der Steckdose:
Oder meintest du die VPN Settings? Da kann man aber ehrlich gesagt ja nicht viel sehen, außer den Login Name und das zensierte Passwort. Kann noch sagen IPSec XAuth PSK ist der Verbindungstyp. Verbindung dazu wird vom Smartphone aufgebaut aus dem HDSDA Netz oder Edge. Aus dem WLAN funktioniert es. Sobald aber das ganze aus dem mobilen Datennetz kommt > Absturz
ich nutz die Binary zum Updaten.
Nachtrag:
Okay, ich habe es eben gerade noch mal probiert, bin raus auf den Balkon damit ich eine HSDPA Verbindung bekomme, VPN Verbunden und siehe da, es funktionierte. Konnte die Dose 2 mal an und aus schalten, keine Probleme bis auf das der Browser von der ON Seite der Steckdose nicht wieder von alleine zurück ging auf die Hauptseite.
Echt sehr komisch. Vielleicht hat das Stecker ziehen nach dem Update gestern doch geholfen. Ich werde es mal im Auge behalten und schauen ob sie wieder abstürze bekommt oder ob es nun doch stabil läuft
-
Nachdem es hier seit einiger Zeit wieder richtig rund geht, wollte ich mir den aktuellen Stand ansehen.
Ich habe von Version (???) per OTA die 1.1.4 aufgespielt.
Ging ganz flott - Super dachte ich -> rebooting…......
jetzt blinkt die Blaue LED ganz hektisch.
every Help appreciated
Gruß
Rainer
-
Nachdem es hier seit einiger Zeit wieder richtig rund geht, wollte ich mir den aktuellen Stand ansehen.
Ich habe von Version (???) per OTA die 1.1.4 aufgespielt.
Ging ganz flott - Super dachte ich -> rebooting…......
jetzt blinkt die Blaue LED ganz hektisch.
every Help appreciated
Gruß
Rainer `
1/2 Sekunde = Initalisiere
1/4 Sekunden = AP geöffnet
10x fertig
Wichtig ist die unterste Zeile:
2018 by TomT/sissiwup - - - Version BETA 1.1.4c Aug 19 2018 13:30:02(10104) - - - Info : https://forum.iobroker.netDie Zahl in Klammern gibt die Version des Speichers an.
Die Logik ist, wenn die gespeicherte Version kleiner ist als die neue, dann werden alle Werte zwischen der Version und der
aktuellen mit default geschrieben.
Im rechten Statusfenster sollten dann "update from 10106 1.0.8,1.0.9,1.1.1" stehen.
Wenn in den Klammern eine (0) steht, dann ist was schief gelaufen, da alles initalisiert wurde.
-
Habe mittlerweile mein Netbook gezückt -> AP wird dauerhaft (!)angezeigt, aber mit dem bisherigen Passwort komme ich nicht rein
Gruß
Rainer
-
Hi,
das Passwort ist "esp8266-1". Muss mal eine Dose zurücksetzen und schauen, was da los ist.
