(gelöst) Fehler E5 - Danfoss Thermostate - nach Update 23.08.2015

Begonnen von cnkru, 30 August 2015, 12:18:47

Vorheriges Thema - Nächstes Thema

rudolfkoenig

ZitatRudi mag diesen langen Postings nicht, ich hoffe aber das er ihn dennoch liest... ,-)

Ja, weil je laenger, desto mehr Zeit muss man ins Nachdenken investieren.

Was ich mitgenommen habe: ihr seid freudig an Experimentieren, harte Fakten sind aber noch nicht rausgekommen, nur "wenn ich alles aendere, dann ist es etwas weniger komisch".

Ich habe vor diesen Vorschlag zu imlementieren, und dann sehen wir mal weiter.
Wahrscheinlich werde dabei das Setzen von lastMsgTimestamp auch anpassen.

krikan

Zitat von: rudolfkoenig am 05 September 2015, 17:22:32
harte Fakten sind aber noch nicht rausgekommen,
Folgendes Problem in der Verarbeitung des Wakeup-Sendstacks haben Andreas und Carsten mMn festgestellt, das ich auch bestätigen kann:
Sobald vom Node eine Nachricht (nicht nur WU-N) empfangen wird, wird der Timestamp, der der awake-Prüfung zugrunde liegt, aktualisiert. Dadurch werden alle Nachrichten 3 Sek danach an den Node verschickt, obwohl er eventuell gar nicht wach ist, da es keine WU-N sondern irgendeine andere Nachricht war. Es kommt zum Telegrammverlust mit NO_ACK (0013xx01). Habe es gerade noch mal nachgestellt. Bei "unscharfen" regexp im notify oder unglücklichen at-Zeiten ist das unter Umständen fatal.

Oder hattest Du das bereits als harte Fakten auf Deiner Liste!?:
ZitatWahrscheinlich werde dabei das Setzen von lastMsgTimestamp auch anpassen.

rudolfkoenig


cnkru

#48
Hallo Andreas,
Zitat
soweit ich das im Log sehe läuft das halbwegs, aber der Time mit 0.05 sekunden scheint etwas zu optimistisch zu sein...

Kannst Du evtl. noch in Zeile 2481 und Zeile 2491 aus der 0.05 mal eine 0.15 machen?

Habe ich jetzt geändert und nehme notify...wakeup wieder mit rein
Alle Thermostate sind gestorben (E5) außer Thermostat_Jule

Vermutlich ein schrittweises Ableben gegen 16:00 oder 17:00
Anbei der LOG und Auszug vom LOG TH_Test (jede Menge TRANSMIT_NO_ACK ab 16:00)
LOG TH_Kueche sind ganz schlimm aus, ab und zu kam ein setpoint durch   :(

anbei die LOGS

Gruß
Carsten

Nachtrag 20:00 Uhr wieder alle Thermostate mit E5 - außer Thermostat_Jule
Gehe zurück auf die Vormittags-Version um den Abend ruhiger zu begehen

Morgen ist auch noch ein Tag
CUL8R
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

cnkru

#49
Noch eine Idee zum sogenannten mehrfachen notify innerhalb weniger Millisekungen (sogenanntes "Prellen").

habe ein wenig gebastelt - könnte behilflich sein.

Idee ist erstes notify:wakeup durchlassen und dann 1 oder 2 Sekunden nicht mehr, wenn dieses hintereinander erfolgt
Die Prozedur soll also das notify-Signal nur einmal durchlassen und in der gewählten Zeit kein weiteres zulassen (also solange abwarten)
D.h. es wird geprüft, ob der Thermostat in der angegebenen Zeit bereits ein Notify gesendet hat

In myUtils_Initialize($$) die Notify Gruppe einfügen
  our $one_notify_signal_gruppe;
sub
one_notify($$)
{
    my($device, $delay_time) = @_;
# Übergabe-Parameter Device und Zeit (sec.)
    my $cur_time = time();
    my $old_time = $main::one_notify_signal_gruppe->{$device};
   
    if(!defined($old_time)) {
# wenn Geraet nicht vorhanden neues device und timestamp in notify-Geraete-Gruppe anlegen
        $main::one_notify_signal_gruppe->{$device}=$cur_time;
        return 1;
    }   
# Wiederholungsfall überprüfen
    my $delta_t = $old_time-$cur_time+$delay_time;
    if($delta_t gt 0) {
# delay_time noch nicht erreicht
        return 0;
    }
# delay_time abgelaufen, timestamp neu anlegen mit cur_time
    $main::one_notify_signal_gruppe->{$device}=$cur_time;
    return 1;
}



Aufruf mit:
define zAt14 notify  Thermostat_Haustuer:wakeup:.*  {if(one_notify("Thermostat_Haustuer",2))\
{my $WertTT=ReadingsVal("Temperatur_Soll_Haustuer","state",0);; fhem("set Thermostat_Haustuer setpointHeating $WertTT");;}}

Füge ich in TH_Haustuer und TH_Test ein

mal sehen ob es klappt ...

Gruß
Carsten

RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

rudolfkoenig

Carsten: falls du noch Geduld zum Experimentieren hast: ich habe gerade eine neue Version von 10_ZWave.pm und 00_ZWDongle.pm eingecheckt, siehe mein Kommentar.

cnkru

Hallo Rudolf,

kein Problem lade ich morgen früh runter...
wo zu finden, auf Thema msg329852nicht fündig -  auf sourceforge.net oder klassisches Update?

Gruß Carsten
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

rudolfkoenig

Auf sourceforge bzw. SVN jetzt, und ab morgen 08:00 per update.

cnkru

Zitat von: rudolfkoenig am 05 September 2015, 22:56:20
Auf sourceforge bzw. SVN jetzt, und ab morgen 08:00 per update.
Eingespielt ...
Melde mich morgen früh

Nachtigall
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

A.Harrenberg

Hallo cnkru,

habe mir die neuen Logs noch nicht angesehen, aber das die Testversion nicht richtig lief konnte ich an dem ersten Log bereits sehen. Da waren noch ein paar Fehler drin, ich habe den WakeUp-Stack einen Befehl zu früh freigegeben, dadruch kam es wieder zu Kollisionen, durch NO_ACK wurde mein Ablauf mit dem Status zur Steuerung des WakeUp-Stacks völlig außer Kraft gesetzt, da es eine Abfrage auf den NO_ACK gibt die ich nicht beachtet hatte, deswegen ist bei mindestens einem Thermostat der WakeUp-Stack vollkommen deaktiviert worden.

Ich hatte da auch schon was dran geändert, da Rudi aber eine neue Version gemacht hat, sollten die Tests erst mal damit weiterlaufen. Die Notify (für die WakeUp-Geräte auf jedenfall auf die Wakup-Notification umstellen, das verringert auf jeden Fall die Funklast.

Ich muss mir jetzt erst mal ansehen was Rudi da alles geändert hat.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

cnkru

#55
Guten Morgen Jungs :D,

Diese Version lief erst einmal durch - alle Thermostate leben und tun was sie sollen
Die LOGS haben ihre bekannten Errors, jedoch nach einer kurzen Serie zwischendurch eine Stunde Pause

@ Andreas: Gern stehe ich zur Verfügung und teste fleißig mit  :),

anbei - wie gewohnt die LOGS und wenn gewünscht noch von einem anderen Geräte

P.S. "wakeup:.* " wurde bei allen Geräten eingerichtet, TH: WZ Test Haustuer und Flur
       haben noch die Routine  "onenotify(device,time)" nach dem wakeup bekommen.
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

A.Harrenberg

Guten Morgen,

muss mich erst mal durch den Code der neuen Version arbeiten. Die Logs kann ich mir erst anschauen wenn ich Rudis Änderungen verstanden habe damit ich begreife was da im Hintergrund passiert / passieren sollte ,-)

Wenn Dein System soweit erst mal lebt ist es da ja auc h erst mal nicht mehr so dringend.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

Was mir auffaellt:
- im Durchschnitt alle 35 Sekunden ein burst von 5 Nachrichten. 5 Nachrichten erfordern mind. 12 Funktelegramme (5*2 wg. Ack + wakeup:noMoreInformation+Ack) -> relativ viel los
- die Geraete senden alle 5 Minuten battery,setpointTemp,ccs*,wakeup:notification
- manche der Nachrichten (wakeup:notification/battery) werden wiederholt, keine Ahnung, wieso.
- das zum Schluss erfolgte WU_NMI wird manchmal doppelt gesendet, in einer Sekunde Abstand. Ich vermute da noch einen Fehler im Programm, habe aber nach Code-Studium keine Idee, wo. Es scheint keine Auswirkungen zu haben.
- CANs gibts relativ wenige (5 Faelle bei ca 1300 versendeten Nachrichten) meist gehaeuft: 3,7,2,1,6. Wenn ich es richtig sehe, passiert es immer mitten im Funkverkehr, vmtl. ist das aktuelle Verhalten (bei CAN 0.1s schlafen, dann nochmal versuchen) falsch, da der Dongle mit dem Empfang/ACK der Nachrichten beschaeftigt ist. Vorschlag (eingecheckt): bei CAN wird nicht sofort gesendet, sondern so getan, als ob kein ACK gekommen waere, und erst nach eine Sekunde wieder gesendet. Ich hoffe, dass in dieser Zeit die Luft wieder rein ist. Koennte mit WU_NMI kollidieren, das muessen wir evtl. anpassen.

Falls ich was wesentliches uebersehen habe, bitte melden.

cnkru

Hallo Rudolf,

ich lasse seit 9:55 alle wakeup:notify's der Thermosate nur einmal durch (Entprellung, one_notify(...)),
die Errors halten sich in Grenzen (9:56,10:39,10:53,11:03,11:19,12:09 Uhr)
betrifft ggw. 4 Thermostate (0x0b, 0x19,0x20, 0x18)
LOG anbei ...

Ggf. kann ich die "Entprellung" rausnehmen - um das Verhalten ohne zu testen

Gruß
Carsten
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

cnkru

So Jungs ...

habe das "Entprellen" (one_notify) komplett rausgenommen ...
... und keine bedeutende Veränderung erreicht.
13:08 bis 14:07 6 Errors an 3 Thermostaten

nehme jetzt alle notify's komplett raus und überlasse das setzen des Befehles (set Thermostat setpointHeating xx) der Routine heizkurve(),
in dem sie dieses nach dem Aufruf (alle 15 Minuten) in den Stack schreibt (war die Ursprungs-Version der letzten Wochen).

So funkt kein notify mehr dazwischen, wenn die Geraete aufwachen und der Dongle seinen Stack abarbeitet.

Melde mich in einer Stunde wieder

CU
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC