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

[HCS]

dann den pull-up analog zu dieser Anleitung realisieren: http://tansi.info/rp/interfacing5v.html

Das wird nicht gehen, weil wir sinngemäß den ganz unten beschriebenen I2C-Fall haben.

[weini]

Ok, danke für die Info. Hatte dazu recherchiert aber nichts konkretes gefunden.

[HCS]

Ok, danke für die Info. Hatte dazu recherchiert aber nichts konkretes gefunden.

Wenn, dann etwas in der Art:
http://www.exp-tech.de/sparkfun-pegelwandler-bidirektional
Nur als Beispiel, bekommt man in eBay, China, Deutschland, und tausend anderen Shops.

Aber ich komme ins Zweifeln, ob das Ganze wirklich ein Hardware-Thema ist oder doch ein Software-Thema in der Art, dass der DHT22 durch ein grenzwertiges Timing zum Aussteigen gebracht wird.
Ich muss mal eine pure DHT22 Test-Firmware machen, damit lässt sich einfacher testen.

[Omega-5]

Habt ihr was gegen den PCA9306? 
Wir haben den in Industrieanwendungen eingesetzt und hatten nie Probleme.
http://www.nxp.com/documents/data_sheet/PCA9306.pdf

Gruß Friedrich

[HCS]

Habt ihr was gegen den PCA9306? 

Nein.

Um nur mal auszuprobieren, ob der DHT22 mit 5V Pegel an Data besser läuft, ist es aber herzlich egal, was man nimmt.
PCA9306, N-Kanal FET und zwei Rs, oder, oder
Hauptsache, es setzt den Pegel bidirektional um.

Irgendwo muss ich noch so einen FET shifter rumliegen haben. Wenn ich ihn finde, dann probiere ich mal mit 5V auf Data

[juergs]

Hallo Zusammen,
habe Euren interessanten Thread hier ebenfalls verfolgt und plage mich auch mit "so" einem Verhalten des des DHT22 in Verbindung
mit meinen Funksensor (allerdings Ub=3V6) herum:

Komischerweise fast immer zu bestimmten Zeiten ....

Werde mal Eure gesammelten Erfahrungen durchstudieren ....

Da die Aussetzer immer länger werden, könnte es in meinem Fall doch "nur" die Betriebsspannung,
im Zusammenspiel mit Umgebungstemperatur  sein ...

http://iot-playground.com/forum/hardware-general/537-dht-22-humidity-value-stability-over-time
http://www.kandrsmith.org/RJS/Misc/Hygrometers/dht22_first_failure.html

Overall I am impressed with the DHT22, but if they do have reliability problems (I have one failure out of six devices) you may never feel inclined to trust them.

http://forum.arduino.cc/index.php?topic=355137.0

Nach weiteren versuchen mit neuer CR2032 Batterie mit 3V6 und 240ma kommt das Verhalten wesentlich in kürzeren Abständen.
Die 5Volt Versorung des DHT22 scheint angeraten zu sein, mit einem LiPo-Accu mit 3V7 dürfte es auch nicht wesentlich besser werden.
Es sei denn, die Temperatur steigt über 20 Grad... 

Batterie-Lebensdauer-Rechner: http://oregonembedded.com/batterycalc.htm

[PeMue]

... habe Euren interessanten Thread hier ebenfalls verfolgt und plage mich auch mit "so" einem Verhalten des des DHT22 in Verbindung mit meinen Funksensor (allerdings Ub=3V6) herum.

Hm, vielleicht braucht der DHT22 einen Kondensator in der Nähe zur Stabilisierung?

Gruß PeMue

[juergs]

ich habe 100yF zur 3V6 Batterie hin, schon wegen des Funkmoduls. Probiere aber auch mal 100nF zum DHT hin ..
Erklärt aber nicht das "selektive" Erscheinungsbild ...

- power the DHT22 with 5V instead of 3v3 -> no changes
- adding a 100nF capacitor near device -> no changes

I can conclude that it is typical for DHT sensors. At the same time, BMP180 that I use in the same setup and couple of DS18B20 show correct temperature and are reliable (they do not measure humidity, though). I also have an I2C humidity sensor SHT21, but I have not tried it yet.

Höhrensagen ... werde mal am WoE meine eigenen Messungen starten.

[PeMue]

Hallo HCS,

könntest Du bitte bei Gelegenheit die v1.20 https://forum.fhem.de/index.php/topic,43672.msg471910.html#msg471910 noch auf der ersten Seite verlinken (ich weiß mittleriweile, dass die auf S. 46 steht  ).

Danke + Gruß

Peter

[locutus]

@HCS
Dir ist bekannt, dass der DHT22 ca. 2 Sekunden für die Verarbeitung der Messdaten benötigt?

[HCS]

Hallo HCS,

könntest Du bitte bei Gelegenheit die v1.20 https://forum.fhem.de/index.php/topic,43672.msg471910.html#msg471910 noch auf der ersten Seite verlinken (ich weiß mittleriweile, dass die auf S. 46 steht  ).

Die ist doch im Repo eingecheckt und wird schon seit dem 13.07. mit dem FHEM Update ausgeliefert.
https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/firmware/

.. und plage mich auch mit "so" einem Verhalten des des DHT22 in Verbindung mit meinen Funksensor (allerdings Ub=3V6) herum

Aber einem etwas anderen Verhalten. Wenn er bei mir nicht mehr will, dann ist rum und nichts außer von Ub trennen hilf ihm wieder auf die Sprünge. Wobei er jetzt gerade mal wieder seit zwei Tagen konstant läuft 

Das Ding ist vom ersten Tag bis heute ein "pain in the a..", ich habe nachts schon Alpträume in denen mich Monster-DHTs verfolgen 

ich habe 100yF zur 3V6 Batterie hin, schon wegen des Funkmoduls. Probiere aber auch mal 100nF zum DHT hin ..

Ich habe 100 nF direkt am DHT22 auf Ub drauf, das hat auch nicht geholfen.

Was seltsam ist, ist, dass er mal ein paar Stunden und mal ein paar Tage läuft, bis er aussteigt.
Und siehe die Analyzer-Shots weiter oben, er antwortet dann einfach nicht mehr.

Ach ja, bei dem anderen LGW, bei dem ich dachte, dass er stabil läuft, ist er die Tage auch nach drei Wochen ausgestiegen 

Der Wünschelrutengänger hat unterhalb vom DHT auch nichts verdächtiges entdeckt.

Habe ich irgendwo "Temperatur" gelesen? Die letzten Tage ist es etwas kühler, als zu der Zeit, wo er immer nur einige Stunden geschafft hat. Das lässt sich aber testen, ich stelle ihn in den Backofen und wenn er keine Daten mehr liefert, dann aktiviere ich die pyrolytische Selbstreinigung 

@HCS
Dir ist bekannt, dass der DHT22 ca. 2 Sekunden für die Verarbeitung der Messdaten benötigt?

Ja. Das LGW lässt die internen Sensoren alle 10 Sekunden messen.

Ich werde mal noch das Timing ändern. Lt. Datenblatt darf das Startsignal zwischen 0.8ms und 20ms liegen mit einem typischen Wert von 1ms. Und ich ziehe es genau 1ms runter. Eventuell probiere ich es mal mit etwas mehr, ob er dann besser hört.

[HCS]

könntest Du bitte bei Gelegenheit die v1.20 https://forum.fhem.de/index.php/topic,43672.msg471910.html#msg471910 noch auf der ersten Seite verlinken (ich weiß mittleriweile, dass die auf S. 46 steht  ).

Jetzt habe ich gerade kapiert, was Du gemeint hast 
Yes, I can 
das schaffe ich 

[juergs]

Neu Erkenntnisse:
da ich die letzten Tage nicht @home war, kann ich jetzt für mich entwarnen:

Batteriespannung des Sende-Moduls Außenbereich: 2.90 Volt.
Mein zweites Modul hat 2.95 Volt (InnenBereich) und sendet noch ohne Probleme.
Da habe ich einen Vergleich, wenn die Spannung weiter nachlässt.
(Entladekurve scheint eher eine e-Funktion, wie linear zu sein)

Da das natürlich weit unter den Spezifikationen von 3.3 .. 6Volt liegt,
muss ich das Energiesparen des Sketches noch weiter optimieren, sofern das
mit einer CR2032-Batterie und dem Stromverbrauch des Sensors überhaupt möglich sein sollte.

Werde mal den Verbrauch und die ON-Zeiten für die Sensor-Messung ermitteln.
Die gleiche Funktionalität für den DS18B20 läuft jetzt schon 3 mal so lang ohne Probleme
und benötigt unter 10 yA im Sleep-Modus.

Also scheinen die "Aussetzer" eher ein Indiz für fehlende Power zu sein.

Grüße,
Jürgen

[HCS]

Auch komplett an 5V (FET level shifter) ist er gleich mal nach vier Stunden ausgestiegen. Ich glaube inzwichen eher nicht mehr so sehr daran, dass das ein Spannnugsversorgungsthema ist, zumindest wenn man nicht deutlich unter 3.3V liegt, was ja im Prinzip auch von juergs bestätigt ist, mit seinen 2.9V

Und möglicherweise gibt es zwei separate Probleme:
1. wird beim Start des LGW (manchmal, meistens, immer, ...) nicht erkannt.
Das könnte das zwei Sekunden-Thema sein. Wenn das LGW sehr schnell die wifi-Verbindung stehen hat, könnte es vorkommen, dass zu dem Zeitpunkt, an dem die Initialisierung und Erkennung des DHT22 stattfindet, noch keine zwei Sekunden rum sind, und dann antwortet er nicht und das LGW geht davon aus, dass keiner angeschlossen ist. Ich werde mal was einbauen, das die Initialisierung des DHT22 notfalls verzögert, wenn nach dem Start noch keine zwei Sekunden rum sind.

2. Läuft einige Stunden oder Tage und antwortet dann nicht mehr.
Möglicherweise gibt die DHT22 routine nach dem wake up den bus zu spät frei und der DHT reagiert manchmal beleidigt, weil der bus noch auf vdd genagelt ist. In einer Woche wissen wir es ...

Wenn man bei jeder Änderung eine Woche warten muss, ob es jetzt durchläuft, ist schon hart. 

[Hagenuck1]

Wollte mich heute dran machen und den NanoMCU fertig machen und habe folgendes Problem:
Den 1. hatte ich bereits direkt nachdem er angekommen ist geflasht (nicht zuhause aber SSID & Passwort schon eingetragen und gespeichert)
Heute dann auf dem BreadBoard alles soweit verkabelt, Strom dran und das einzige, was der noch macht ist, dass beim Einstecken des Netzteils die blaue LED 1x blinkt und dann ca. alle 8 Sek. wieder blinkt. Nach ca. 1 Minute blinkt die rote LED dann ein paar mal. Verbinden mit dem WLAN tut es sich aber augenscheinlich nicht, da hier in der Fritz!Box kein Verbindungsversuch aufgelistet ist und auch in der Liste der WLAN Geräte nichts auftaucht. Das "LaCrosseGateway-..." WLAN wird allerdings auch nicht eröffnet.

Dann versucht neu zu flashen. 1x nur dem dem "esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 921600 -ca 0x00000 -cd nodemcu -cf JeeLink_LaCrosseGateway.bin" Befehl -> Er flasht, aber es ändert sich nichts und dann 1x mit vorangehendem löschen des Flashs "./esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 115200 -ca 0x00000 -cd nodemcu -ce" von Seite 36. Keine Änderung.

Dann den 2. NanuMCU ausgepackt. Erst war das LaCrosseGateway-... WLAN da, SSID & Pass hinterlegt. Dann gleiches Problem wie beim 1.

Feste IP oder ähnliches sind bei beiden malen nicht hinterlegt worden.

Ich bin gerade etwas überfragt, hat da jemand ähnliches Phänomen schon gehabt?