LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino

[amunra]

Ich könnte die Zeit (die 15 Sekunden) konfigurierbar machen, dass man das LGW z.B. 60 Sekunden probieren lassen kann.
Wenn man allerdings neu konfigurieren will, muss man dann halt 60 Sekunden warten, bis das LGW aufgibt und seinen eigenen AP auf macht.

Ich halte das für einen annehmbaren Kompromiss. Den Default-Wert von ,,15 Sekunden" würde ich jedoch lassen. Dies nur als Anmerkung meinerseits.

[HCS]

Ich stelle mal ganz vorsichtig ein Feature-Request:

,,Eine Möglichkeit das LGW in einem reinen Transparent Bridge Mode ohne einen SC16IS750 zu betreiben."

Das werde ich nicht implementieren.
Ohne SC16IS750 muss eine soft serial her, die muss GPIOs verwenden, an denen sonst RFMs hängen, das komplette System muss diesen Modus beherrschen, das Frontend darf nur die passenden Einstellungen anbieten, und, und, und, und man muss es testen, supporten, ...
Das würde mehr oder weniger eine komplett neue Software, da bleibt fast nichts wie es ist.

Aber reine serielle bridges für den ESP8266 gibt es doch:
https://github.com/beckdac/ESP8266-transparent-bridge
https://github.com/jeelabs/esp-link
und bestimmt noch 10 weitere, die ich spontan nicht gefunden habe.

[HCS]

Ich halte das für einen annehmbaren Kompromiss. Den Default-Wert von ,,15 Sekunden" würde ich jedoch lassen.

Ja, die config page bekommt eine Einstellung, und der default ist 15 Sekunden, damit bleib alles wie es war, solange man es nicht ändert.
Das ist kein Kompromiss, das ist die einzige Möglichkeit, dieses Szenario in den Griff zu bekommen.
Man muss dann mal mit der Stoppuhr messen, wie lange der AP braucht, bis er zum Leben erwacht, und dann im LGW etwas mehr als das einstellen.

[amunra]

Das werde ich nicht implementieren.
Ohne SC16IS750 muss eine soft serial her, die muss GPIOs verwenden, an denen sonst RFMs hängen, das komplette System muss diesen Modus beherrschen, das Frontend darf nur die passenden Einstellungen anbieten, und, und, und, und man muss es testen, supporten, ...
Das würde mehr oder weniger eine komplett neue Software, da bleibt fast nichts wie es ist.

Ich habe es befürchtet   und verstehe es auch.

Aber reine serielle bridges für den ESP8266 gibt es doch:
https://github.com/beckdac/ESP8266-transparent-bridge
https://github.com/jeelabs/esp-link
und bestimmt noch 10 weitere, die ich spontan nicht gefunden habe.

Ja, die kenne ich. Ich habe damit vor ca. 1 - 1 1/2 Jahren schon ein wenig experimentiert. Ich bin zu sehr von der Zuverlässigkeit und der einfachen Implementierung des LGWs verwöhnt und ein System wäre mir lieber. Ich wage erneut einen Versuch. Die Option, es mithilfe des SC16IS750 zu realisieren, die ich übrigens auch testen werde, bleibt ja immer noch. 

[Omega]

Ja, die config page bekommt eine Einstellung, und der default ist 15 Sekunden, damit bleib alles wie es war, solange man es nicht ändert.
Das ist kein Kompromiss, das ist die einzige Möglichkeit, dieses Szenario in den Griff zu bekommen.

Super - danke. 
Der Vorteil von Parametern - man kann es fast allen recht machen

[HCS]

Der Vorteil von Parametern - man kann es fast allen recht machen

Ja fast, bis auf die, die dann nörgeln, dass man da so viel einstellen muss.
Ich sehe den Tag kommen, an dem es eine "Simple-Config-Page" und eine "Expert-Config-Page" geben muss ... 

Die Option, es mithilfe des SC16IS750 zu realisieren, die ich übrigens auch testen werde, bleibt ja immer noch. 

Das sollte funktionieren. Man muss keine Radios dran haben, geht auch ohne.
Ein devkit, ein SC16IS750 und irgend was an dessen Serielle sollte gehen.
Und dann hast Du WebFrontend, OTA für LGW und den angeschlossenen Prozessor, eigentlich alles was Du willst.

Eigentlich wollte Wzut hier https://forum.fhem.de/index.php/topic,52895.0.html einen SC16IS750 clone implementieren, dass man nicht so lange warten muss, bis er aus China kommt und mit einem 328p oder gar einem Tiny wäre es auch preiswerter.
Aber da scheint nichts draus zu werden.

[HCS]

Fortsetzung der DHT22 Problematik die hier https://forum.fhem.de/index.php?topic=52921.msg475715#msg475715 begonnen hat:

Nach zwei Tagen mit mit angeklemmten Analyzer hat der DHT22 dann doch noch aufgehört Daten zu liefern.

Er antwortet einfach nicht mehr. Man sieht, wie das LGW den wake up pulse absetzt, aber vom DHT kommt keine Antwort.
Kann sich so ein Ding aufhängen, die Lust verlieren oder was auch immer?

Mal die Fakten:
- ich habe ein weiteres LGW , an dem ein DHT22 dran ist, der wochenlang liefert
- Die DHTs gegeneinander getauscht hat das Problem nicht auf das andere LGW verlagert
- An diesem LGW läuft er mal ein paar Stunden, mal einige Tage
- aktuell nach etwas über zwei Tagen plötzlich keine Daten mehr

Hat jemand sachdienliche Hinweise?

Nach jeder Änderung drei Tage warten, ob er durchläuft, das wird eine lustige Fehlersuche ...

Nachtrag: von der Versorgungsspannung getrennt, neu verbunden und läuft wieder, siehe "GehtWieder.png"

[locutus]

3,3V ist die untere Grenze des Betriebsspannungsbereichs, dazu kommen noch Bauteiltoleranzen. Zuverlässig läuft dieser Sensor nur mit 5V.

[weini]

Hi Damian!

Kann ich denn auf der von dir erworbenen Platine (-> https://forum.fhem.de/index.php/topic,52181.msg458753.html#msg458753) irgenwo die 5V abgreifen? Die müssen doch eigentlich vom Netzteil als VIN reinkommen.

Falls das nicht geht, kann ich mit einem Step-Wandler die notwendige Stabilisierung für den DHT22 erreichen?

Danke im Voraus,
Christian

[HCS]

... irgenwo die 5V abgreifen? Die müssen doch eigentlich vom Netzteil als VIN reinkommen.

Die IOs des ESP8266 sind nicht 5V tolerant. Den Data-Pin des DHT22 darf man nicht auf 5V pullen.
Bestenfalls den DHT mit 5V betreiben und IO mit 3.3V, aber ob das (besser) geht?

Oder den DHT22 an 5V, Data auch auf 5V pullup und dann mit einem bidirektionalen level shifter auf 3.3V adaptiert an den ESP dran.

[HCS]

... irgenwo die 5V abgreifen?

Die sollten am "vin" pin des devkit aufliegen.

[weini]

Nachdem mein DTH22 die letzte Wochen nicht mehr zur Mitarbeit zu bewegen war habe ich jetzt wieder Daten. Das fuktioniert genau seit ich einen 10k Pullup auf 3,3V zusätzlich mit eingelötet habe.

Jetzt heißt es abwarten und beobachten, schließlich lief der DHT22 zu Beginn für mehrere Wochen auch ohne Pullup.

Ich halte euch auf dem Laufenden...

[HCS]

3,3V ist die untere Grenze des Betriebsspannungsbereichs, dazu kommen noch Bauteiltoleranzen. Zuverlässig läuft dieser Sensor nur mit 5V.

Da das Datenblatt sagt, dass der Data-Out des DHT22 ein open collector ist, habe ich den DHT22 dann mal mit 5V versorgt, Data ist weiterhin auf 3.3V gezogen. Lief spontan, aber nach einem halben Tag ist er wieder stehen geblieben.

Jetzt habe ich mal eine neuen Theorie: die HF des ESP8266 wirft ihn aus der Bahn. Ich habe jetzt mal 0,1uF direkt am DHT22 aufgelötet.
Wir werden sehen ...

Nachdem mein DTH22 die letzte Wochen nicht mehr zur Mitarbeit zu bewegen war habe ich jetzt wieder Daten. Das fuktioniert genau seit ich einen 10k Pullup auf 3,3V zusätzlich mit eingelötet habe.

Jetzt heißt es abwarten und beobachten, schließlich lief der DHT22 zu Beginn für mehrere Wochen auch ohne Pullup.

Ja, das devkit hat ja schon einen 10K pullup drauf. Mit jetzt 5K werden höchstens noch die Flanken steiler.

Man darf sich aber nicht täuschen lassen. Als ich das letzte mal den Analyzer mit drauf gehängt habe, lief er zwei Tage, bis er ausgestiegen ist.

Und was auch als recht sicher betrachtet werden kann: wenn er ausgestiegen ist, dann ist rum, bis man die Spannungsversorgung trennt und wieder verbindet.

[HCS]

Jetzt habe ich mal eine neuen Theorie: die HF des ESP8266 wirft ihn aus der Bahn. Ich habe jetzt mal 0,1uF direkt am DHT22 aufgelötet.
Wir werden sehen ...

Lief von gestern Abend 20:00 bis heute Nacht um 01:00, dann ist der DHT22 wieder ausgestiegen.

Aktuelle Variante ist:
- DHT22 über ca. 10cm Flachbandkabel an "PeMue-Platine" angeschlossen
- 5V Versorgung
- Data mit den 10K, die auf dem devkit sind, auf 3.3V hochgezogen
- 0,1uF direkt auf dem DHT22 auf den Spannungsversorgungs-Pins

Ich glaube, dass ich jetzt den DHT22 mal mit 5V und pullup auf 5V über einen ordentlichen Level-shifter (MOSFET) betreibe.

Oder kann ihn die Software tatsächlich mit einem ungünstigen Timing abstürzen lassen?

[weini]

Mein Versuch mit zusätzlichem 10k pull-up hat leider auch nur für genau EINE Log-Meldung "OK WS..." gereicht, danach war wieder Ruhe.

Ich würde bei mir als nächstes folgenden Ansatz versuchen:

• DHT22 VCC über VIN speisen (also +5V)
• dann den pull-up analog zu dieser Anleitung realisieren: http://tansi.info/rp/interfacing5v.html

Kann nur etwas dauern, ich habe derzeit noch die Restarbeiten meiner Wohnungsanierung abzuschließen...