Hallo,
ich habe ein vergleichbares Problem gehabt. Bei mir war es leider so,
dass der Sensor selber "abgekachelt" war. Ich habe am Anfang auch auf
der Ethersex-Seite gesucht. Dann aber festgestellt, dass ein
Powercycle des Sensors das Problem für eine Weile löst, bis es dann
wieder auftritt. Ein Austausch des Sensors hat mein Problem dauerhaft
behoben. Leider war es ein nicht so ganz günstiger DHT22. Ich hoffe,
dass es hier nicht der Fall ist. Wollte das aber schnell beisteuern.
Gruß
Daniel
Quoting Matthias Berner <matthiasber...@familie-berner.de>:
hab mir mal die zeiten im Analyzer angeschaut
die Init zeit von 18ms war ziemlich am schwanken, je nachdem was auf
dem AVR noch so zu tun war
hab mal eine pause hier in dht_start eingefügt
*(port-1) |= _BV(pin); /* OUTPUT */
*(port-0) &= ~_BV(pin); /* LOW LEVEL */
_delay_ms(18);
damit hab ich immer über 20ms reale pulldowntime (die ging ohne mal
auf 8ms runter, möglich dass der DHT dann irgendwann nicht mehr
antwortet)
laut kommentar in der dht.c sollte darauf dann 40ms pullup folgen,
sind aber nur 30 (auch gemessen)
in dht_read hab ich dass geändert
*(port-0) |= _BV(pin); /* HIGH LEVEL */
_delay_us(40);
*(port-1) &= ~_BV(pin); /* INPUT */
mal jetzt schauen was passiert
port und pin numer wurden bisher zumindest nicht vergessen, laut log
und im analyzer ist ja auch was zu sehen.
vielleicht war es dass schon
Am 07.12.2014 um 10:32 schrieb Matthias Berner
<matthiasber...@familie-berner.de>:
also die routine läuft anscheinend
D: DHT start avrnetio05_DHT0
D: DHT read avrnetio05_DHT0
D: DHT read timeout, edge=0
bin mal mit einem Logic analyzer an den Pin gegangen, da tut sich
gar nichts, dh der sensor wird gar nicht fürs reading initialisiert
nach einem reset vom Board, sind sofort die abfragen zu sehen
D: DHT start avrnetio05_DHT0
D: DHT read avrnetio05_DHT0
D: DHT avrnetio05_DHT0 t=219, h=419%
und auch alle 30 sec im Logic analyser
also irgdendwo hier verschluckt sich was
*(port-0) |= _BV(pin); /* HIGH LEVEL */
_delay_us(30);
*(port-1) &= ~_BV(pin); /* INPUT */
gleich mal nen debug einbauen und schauen ob vielleicht vergessen
wird, welcher port es sein soll
Am 06.12.2014 um 14:25 schrieb Ricardo Drescher <drescher.rica...@gmail.com>:
Hallo Matthias,
Ich habe auch das Problem, jedoch noch mit alten Softwareständen
ohne Multi DHT, mit Kabeln zwischen 3m und 10cm sowie nur über sehr
lange Zeiträume (Monate). Habe es eku schon mitgeteilt, jedoch ist
sowas aus meiner Sicht schwer lokalisierbar. Ich nutze e6 mit FHEM
und frage per ECMD alle 4min ab.
Viele Grüße, Ricardo
Am 06.12.2014 08:30 schrieb "Berner Matthias"
<matthiasber...@familie-berner.de>:
hallo
nur mal kurz gefragt, hat noch jemand anders dass problem dass beim
aktuellen Stand die DHTs nach einer Weile (1- 2 Tage) statische
Werte liefern?
habe alles aktiviert was unter dht config zu aktivieren ist, hab
auch die verkabelung zum prozessor kürzer gemacht, weil ich die
kabellänge und die Pullup wiederstände im verdacht hatte.
Wo fängt man jetzt an zu suchen?
mit nem debug_print im dht_periodic() mal schauen ob der irgendwann versagt?
oder dht_periodic() aus control6 heraus alle stunde anschubsen? dann
sieht man ja ob mal ne pause war und es dann wieder läuft.
_______________________________________________
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel
_______________________________________________
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel
