[ethersex-devel] dht pollen nach einer weile nicht mehr

[Berner Matthias]

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.

[Matthias Berner]

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 <***@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" <***@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.

[Matthias Berner]

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 <***@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 <***@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" <***@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.

[e***@users.sourceforge.net]

Hallo,

ich finde es toll, dass Ihr Euch mal selbst Gedanken macht und nicht
immer nur auf die Hilfe der Entwickler hofft. Weiter so!

Date: Sun, 7 Dec 2014 12:05:44 +0100
Subject: Re: [ethersex-devel] dht pollen nach einer weile nicht mehr
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)

Autsch! Der 20ms-Delay wird durch dht_periodic() sichergestellt.
Dein Delay in dht_start() bringt das gesamte Timing der Mainloop
durcheinander! Laut Datenblatt reichen 18ms, ein Timertick ist
mindestens 20ms lang. Sollte das auf Deinem AVR nicht der Fall
sein, solltest Du da mit der Ursachensuche beginnen. Man könnte
in der ISR einen Portpin togglen und die Zeiten messen.

laut kommentar in der dht.c sollte darauf dann 40ms pullup folgen, sind aber nur 30 (auch gemessen)

40us nicht 40ms

in dht_read hab ich dass geändert
*(port-0) |= _BV(pin); /* HIGH LEVEL */
_delay_us(40);
*(port-1) &= ~_BV(pin); /* INPUT */

Welchen Sensortyp hast Du im Einsatz? Laut Datenblatt DHT22 sind 30us
typisch, minimum 20us. Dein Sensor hält sich nicht ans Datenblatt?
Die delay-Anweisungen sind übrigend Busy-Waits, die zur Compilezeit
auf Basis des AVR-Taktes (F_CPU) berechnet werden.

Gruß, eku

[e***@users.sourceforge.net]

Moin,

ein Produktiv-NETIO läuft mit AM2302 von Adafruit (=DHT22) seit
sechst Tagen zuverlässig. Die Debugausgaben landen per Syslog auf
einem Linuxrechner. Außerdem werden vom NETIO noch 1w, zwei
RFM12 für Funksteckdosen und FS20 und YPort bedient.

Es läuft der unmodifizierte DHT-Code aus dem Ethersex Master
mit dem Timercode aus dem Branch new_timer_framework
(https://github.com/ethersex/ethersex/tree/new_timer_framework).

Grüße,

[Matthias Berner]

hallo

werd es mal probieren,danke

bezüglich der timings hab ich x-verschiedene Datasheets mit leicht
verschiedenen werten gefunden. wir bewegen uns aber immer nah dran
bei den chinesen findet man an den Modulen immer einen 100nF
Kondensator, hab dazu auch eine Anleitung gefunden, einer läuft damit
bisher ohne Probleme.
da wo kein C dran ist sind sie schon mehrfach über den jordan gegangen.

Post by e***@users.sourceforge.net
Moin,
ein Produktiv-NETIO läuft mit AM2302 von Adafruit (=DHT22) seit
sechst Tagen zuverlässig. Die Debugausgaben landen per Syslog auf
einem Linuxrechner. Außerdem werden vom NETIO noch 1w, zwei
RFM12 für Funksteckdosen und FS20 und YPort bedient.
Es läuft der unmodifizierte DHT-Code aus dem Ethersex Master
mit dem Timercode aus dem Branch new_timer_framework
(https://github.com/ethersex/ethersex/tree/new_timer_framework).
Grüße,

[Daniel Tombeil]

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

Post by Matthias Berner
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
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
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"
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
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel