OBI Funk-Steckdosenumbau ESP8266 (Generation1 Rund)
-
Sorry, wenn ich hier kurz das Problem von haselchen unterbreche, wollte nur etwas zu den LEDs mitteilen, was ich gerade herausgefunden habe:
@TomT:Die LEDs leuchten dann, wenn das Relay AN ist, also die Steckdose eingeschaltet wurde.
Leider sind beide LEDs am selber GPIO Pin, so daß diese nicht getrennt steuerbar sind. `
Ich glaube, das ist nicht ganz richtig: Am GPIO 4 hängt die blaue LED, aber die rote LED ist direkt am Relay, wenn ich das auf der Platine richtig sehe. Jedenfalls habe ich mal den Befehl
digitalWrite(4, 1);in den Funktionen switch_ON() etc. auskommentiert. Beim Einschalten leuchtet dann die rote LED (am Taster) immer noch auf, die blaue LED aber nicht mehr.
Grüße,
Alex
-
@ sissiwup
Hab mal alles ausprobiert und ein Javascript deaktiviert, das mit der Steckdose zu tun hatte.
Und nun bekomme ich nur noch 1 State mitgeteilt.
Nicht steinigen. Ich weiss leider nicht mehr was das Script bewirkt hat. Irgendwas mit der VIS auf jedenfall.
Eventuell sollte man das auf Seite 1 aufnehmen?
-
Sorry, wenn ich hier kurz das Problem von haselchen unterbreche, wollte nur etwas zu den LEDs mitteilen, was ich gerade herausgefunden habe:
@TomT:Die LEDs leuchten dann, wenn das Relay AN ist, also die Steckdose eingeschaltet wurde.
Leider sind beide LEDs am selber GPIO Pin, so daß diese nicht getrennt steuerbar sind. `
Ich glaube, das ist nicht ganz richtig: Am GPIO 4 hängt die blaue LED, aber die rote LED ist direkt am Relay, wenn ich das auf der Platine richtig sehe. Jedenfalls habe ich mal den Befehl
digitalWrite(4, 1);in den Funktionen switch_ON() etc. auskommentiert. Beim Einschalten leuchtet dann die rote LED (am Taster) immer noch auf, die blaue LED aber nicht mehr.
Grüße,
Alex `
Super, ist die blaue LED sonst mal an? Oder soll die verwendet werden um z.B. WIFI-Connect oder Web-Aktivität oder aktiver Timer anzuzeigen?
-
@ sissiwup
Hab mal alles ausprobiert und ein Javascript deaktiviert, das mit der Steckdose zu tun hatte.
Und nun bekomme ich nur noch 1 State mitgeteilt.
Nicht steinigen. Ich weiss leider nicht mehr was das Script bewirkt hat. Irgendwas mit der VIS auf jedenfall.
Eventuell sollte man das auf Seite 1 aufnehmen? `
Kannst du das Script mal posten?
Grüße
Tom
-
Ich glaube, das ist nicht ganz richtig: Am GPIO 4 hängt die blaue LED, aber die rote LED ist direkt am Relay, wenn ich das auf der Platine richtig sehe. Jedenfalls habe ich mal den Befehl
digitalWrite(4, 1);in den Funktionen switch_ON() etc. auskommentiert. Beim Einschalten leuchtet dann die rote LED (am Taster) immer noch auf, die blaue LED aber nicht mehr. `
Ja, kannst Recht haben, so genau hab ich mir die Hardware nicht angeschaut….
Grüße
Tom
-
Ist Dein eigenes Skript :lol: :lol: (ohne meine Daten drin)
on({id: "esp8266.0.OBI-Steckdose.SetState"/*SetState*/, change: "ne"}, function (obj) { var value = obj.state.val; var oldValue = obj.oldState.val; if (getState("esp8266.0.OBI-Steckdose.SetState").val === true) { try { require("request")('http://<ip der/steckdose="">/ON').on("error", function (e) {console.error(e);}); } catch (e) { console.error(e); } console.log("request: " + 'http://<ip der/steckdose="">/ON'); } else { try { require("request")('http://<ip der/steckdose="">/OFF').on("error", function (e) {console.error(e);}); } catch (e) { console.error(e); } console.log("request: " + 'http://<ip der/steckdose="">/OFF'); } });</ip></ip></ip></ip> -
Bei mir leuchtet die blaue LED im normalen Betrieb gar nicht mehr, wenn ich die digitalWrite wie beschrieben auskommentiere.
Ich habe mal die testWiFi() folgendermaßen geändert (basierend auf der 1.0.9, die nutze ich derzeit noch), damit die blaue LED während des Verbindungsaufbaus blinkt, und je nach Ergebnis an oder aus ist:
// test if we are connected boolean testWiFi() { int c = 0; Serial.print(F("Waiting for Wifi to connect")); // c at 60 with delay 500 is for 30 seconds ;) // c at 120 with delay 500 is for 60 seconds ;) pinMode(4, OUTPUT); // <-- sonst blinkt hier nix (pinMode wird in der main erst später gesetzt) while ( c < 120 ) { digitalWrite(4, c%2); // <-- einfaches Blinken gemäß delay() unten. 1-c%2 geht natürlich auch ;-) Serial.print("."); if (WiFi.status() == WL_CONNECTED) { Serial.println(""); Serial.println(printConnectionType(WiFi.status())); digitalWrite(4, 1); // <-- Bei erfolgreichem Verbinden soll die blaue LED dauerhaft leuchten return 1; } delay(500); c++; } digitalWrite(4, 0); // <-- Falls nicht erfolgreich, blaue LED aus Serial.println(""); Serial.println(printConnectionType(WiFi.status())); return 0; }So bleibt die blaue LED natürlich auch an, wenn die Verbindung verloren gehen sollte - oder während eines Reboots oder bei Firmware Update. Da kann man aber bestimmt was machen.
Grüße,
Alex
-
Bei mir leuchtet die blaue LED im normalen Betrieb gar nicht mehr, wenn ich die digitalWrite wie beschrieben auskommentiere.
Ich habe mal die testWiFi() folgendermaßen geändert (basierend auf der 1.0.9, die nutze ich derzeit noch), damit die blaue LED während des Verbindungsaufbaus blinkt, und je nach Ergebnis an oder aus ist:
// test if we are connected boolean testWiFi() { int c = 0; Serial.print(F("Waiting for Wifi to connect")); // c at 60 with delay 500 is for 30 seconds ;) // c at 120 with delay 500 is for 60 seconds ;) pinMode(4, OUTPUT); // <-- sonst blinkt hier nix (pinMode wird in der main erst später gesetzt) while ( c < 120 ) { digitalWrite(4, c%2); // <-- einfaches Blinken gemäß delay() unten. 1-c%2 geht natürlich auch ;-) Serial.print("."); if (WiFi.status() == WL_CONNECTED) { Serial.println(""); Serial.println(printConnectionType(WiFi.status())); digitalWrite(4, 1); // <-- Bei erfolgreichem Verbinden soll die blaue LED dauerhaft leuchten return 1; } delay(500); c++; } digitalWrite(4, 0); // <-- Falls nicht erfolgreich, blaue LED aus Serial.println(""); Serial.println(printConnectionType(WiFi.status())); return 0; }So bleibt die blaue LED natürlich auch an, wenn die Verbindung verloren gehen sollte - oder während eines Reboots oder bei Firmware Update. Da kann man aber bestimmt was machen.
Grüße,
Alex `
Ok, wichtig war mir, das sie sonst aus ist. Dann werde ich mal ein paar Statusmeldungen darüber realisieren.
An: Wenn Verbindung ins WLAN besteht
Aus: Wenn keine Verbindung besteht
Blinken bei Aktivität
Mal sehen was mir sonst noch einfällt.
-
Hallo,
erstmal ein riesen Respekt und Dank für eure Arbeit hier, bin wirklich begeistert davon. Allerdings hätte ich zwei Fragen bzw. Anliegen.
1.
Ich habe gestern meine erste Steckdose erfolgreich geflasht. Nach ein paar Problemen und rum probieren lief dann die 1.1.1 ohne Probleme auf der Steckdose. Das flashen und löten habe ich alles bei meinem Bruder gemacht, natürlich haben wir dann seinen WLAN Gastzugang benutzt, um die Steckdose zu prüfen. Wir fingen also an mit der Startversion diese zu flashen, haben dort die WLAN Daten hinterlegt und dann die OTA Updates gemacht bis auf 1.1.1. Bis hierhin funktionierte auch alles ohne Probleme. Das Problem kam dann erst als ich mir meine Steckdose geschnappt habe und nachhause bin und diese hier natürlich sofort in meinem eigenen WLAN in Betrieb nehmen wollte. Der AP der Steckdose wurde gefunden, connecten auf die IP 192.168.4.1 ging ebenfalls, die Seite zum einrichten öffnete sich. Dort habe ich auch meine WLAN SSID gefunden, diese ausgewählt und das Passwort eingegeben und anschließend neugestartet. Aber die Steckdose fand nicht den Weg ins WLAN. Stattdessen kam immer wieder nach einiger Zeit der AP zurück in der WLAN Übersicht. In der Fritz.Box Ereignisanzeige war kein Verbindungsversuch zur Box zu sehen. Auch nach mehrmaligen neuen eingeben des WLAN Schlüsseln passierte nichts. Also hab ich die Erase eeprom Funktion ausgeführt, wieder die WLAN Daten eingegeben und dann ein kleines Lebenszeichen der Steckdose; in der Fritz.Box Log war ein Verbindungsversuch zu sehen, allerdings WLAN Schlüssel falsch, daher keine Verbindung. Ich habe dann den Gastzugang geöffnet, mehrere male die SSID umbenannt, immer das gleiche Ergebnis. Ich hab dann letztendlich aufgegeben und die Steckdose noch mal mit der Startversion geflasht, WLAN Daten eingegeben und sofort verbunden. Die beiden OTA Updates gemacht, alles in Ordnung, Steckdose läuft einwandfrei.
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?
und zu meinem 2. Punkt.
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.
Vielen Dank schon mal und viele Grüße
Noch ein Nachtrag
Ich habe die dose noch mal ans USB gehängt und ein Terminal mitlaufen lassen, um zu schauen was dort passiert beim Login. Beim setzen der WLAN Daten wird dort das richtige Passwort angezeigt, auch im SSID Name scheint kein Fehler zu sein. Was jedoch auffällig ist beim Verbindungsaufbau:
> SSID: FRITZBoxGastzugang<\r><\n>PASS: <\r><\n>Waiting for Wifi to connect….....................................................................................................................<\r><\n>WL_DISCONNECTED<\r><\n>Could not connect to SSID!<\r><\n>Starting AP at port: 80<\r>Hinter dem PASS: steht wirklich nichts. Ist das normal? Sollte da nicht der WLAN Key stehen?
Nachtrag #2
Okay, es liegt an dem Codefehler, den Beamer auf Seite 17 schon genannt hat, dass der WLAN Key erst 32 Zeichen später geschrieben wird. Konnte es ganz leicht gegen testen, hab die Dose noch mal eingerichtet, habe jedoch dieses mal bei der WLAN Key eingabe einfach 32 Leerzeichen gemacht und erst dann den WLAN Key angefangen einzutippen. Gespeichert, neugestartet und siehe da, WLAN verbunden
-
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
-
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?
