FHZ1300 / FHT80b set time funktioniert (nicht immer)

[Hinata]

Ich kann über set time die Uhrzeit bei meinen FHT nicht setzen. Anscheinen werden die Minuten nicht übernommen. In meinem Setup mit einer FHZ1300 ist der Softbuffer aktiv.

Code: [Auswählen]

Accept-Language: de-DE,de;q=0.9
2022.02.12 13:20:01 4: WEB_192.168.178.36_57320 POST /fhem&detail=bb_Heizung&dev.setbb_Heizung=bb_Heizung&fwcsrf=csrf_309667990418783&cmd.setbb_Heizung=set&arg.setbb_Heizung=time&val.setbb_Heizung=; BUFLEN:0
2022.02.12 13:20:01 5: Cmd: >set bb_Heizung time<
2022.02.12 13:20:01 2: FHZ get   fhtbuf
2022.02.12 13:20:01 5: Sending 8105044fc90185
2022.02.12 13:20:01 4: FHZ/RAW: 810c04ea0909a0013d540000a6
2022.02.12 13:20:01 4: FHZ/RAW: 00
2022.02.12 13:20:01 5: GET Got: 810c04ea0909a0013d540000a600
2022.02.12 13:20:01 5: getFhtBuffer: 0 810c04ea0909a0013d540000a600
2022.02.12 13:20:01 2: FHZ get   fhtbuf
2022.02.12 13:20:01 5: Sending 8105044fc90185
2022.02.12 13:20:01 4: FHZ/RAW: 8107c9d3010285014a
2022.02.12 13:20:01 5: GET Got: 8107c9d3010285014a
2022.02.12 13:20:01 5: getFhtBuffer: 1   fhtbuf => 4a
2022.02.12 13:20:01 5: Sending 810b04220201836153630d6414
2022.02.12 13:20:01 2: FHT set bb_Heizung hour 13 minute 20
2022.02.12 13:20:01 5: Starting notify loop for bb_Heizung, 1 event(s), first is time
2022.02.12 13:20:01 5: rg_battery_status: not on any display, ignoring notify
2022.02.12 13:20:01 5: rg_window_status: not on any display, ignoring notify
2022.02.12 13:20:01 5: End notify loop for bb_Heizung
2022.02.12 13:20:01 5: GET /fhem?detail=bb_Heizung&fw_id= HTTP/1.1
Host: fhem:8083
…
Referer: https://fhem:8083/fhem?detail=bb_Heizung&fw_id=
Accept-Encoding: gzip, deflate, br
2022.02.12 13:20:01 4: WEB_192.168.178.36_57320 GET /fhem?XHR=1&inform=type=status;filter=bb_Heizung;since=1644668400;fmt=JSON&fw_id=23689×tamp=1644668401870; BUFLEN:0
2022.02.12 13:20:10 4: FHZ/RAW: 810b04 (Unparsed: )
2022.02.12 13:20:10 4: FHZ/RAW: 77830983016153630d43 (Unparsed: 810b04)
2022.02.12 13:20:10 5: FHZ_0: dispatch 810b0477830983016153630d43
2022.02.12 13:20:10 4: FHT bb_Heizung confirmation: 63
2022.02.12 13:20:10 4: FHT bb_Heizung hour: 13
2022.02.12 13:20:10 4: FHT softbuffer check: bb_Heizung / hour 13 minute 20
2022.02.12 13:20:10 4: FHT softbuffer found
2022.02.12 13:20:16 4: Connection closed for WEB_192.168.178.36_57320: EOF
2022.02.12 13:20:16 5: GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2022-02-12.log HTTP/1.1
Host: fhem:8083
Connection: keep-alive


[rudolfkoenig]

Das FHT Protokoll ist mAn suboptimal (und das ist ein Euphemismus), leichte Funkprobleme koennen zu permanenten Uebertragungsschwierigkeiten fuehren. Ich sage das als Entwickler der entsprechenden Routinen in culfw, wie das in der FHZ1x00 geloest ist, weiss ich nicht.
Typisches Problem ist das Vorhandensein von mehreren FHT80bs, die ihre zugeordneten Ventile/FHT8vs leicht versetzt benachrichtigen, und wiederkehrend eine Weile die Uebertragung der Anderen stoeren. Dieses Problem loest sich aber immer wieder von selber.

Man koennte mit einem CUL+culfw die einzelnen Funknachrichten protokollieren, und den "Schuldigen" feststellen.
Ob das den Aufwand wert ist, muss jeder fuer sich entscheiden.

[Hinata]

Wenn ich set time ausführe wird nur hour gesetzt, minute nicht (Readings). Nach set minute sehe ich auch das Readings minute wieder, allerdings stark verzögert mit Zeitstempel ca +120s. Irgendwas ist das komisch?

Ich habe softbuffer ein/aus geschalten und auch FHEM shutdown restart probiert.
Die Kommunikation mit den FHT funktioniert sonst.

Irgendwie scheint das ein Problem mit set time zu sein? Allerdings frage ich mich ob set time oder minute überhaupt funktionieren kann, da eine Verzögerung von Sendebefehlen normal zu sein scheint?

[rudolfkoenig]

set time generiert set hour,minute, also zwei Funkbefehle.
Das FHT ist nur alle 15 Minuten bereit zum Empfang von Befehlen, d.h. die Firmware muss die Zeit entsprechend weiterzaehlen.
culfw macht das, keine Ahnung, was die FHZ1x00 Firmware macht.

Meine Probleme mit dem FHT-Protokoll sind:
- die Uebertragung kann nur alle 15 Minuten erfolgen (nach der Temperatur-Meldung)
- dass man was senden will, muss man mit einem Handshake, was aus mehreren bestaetigten Funknachrichten besteht, ankuendigen.
- man muss alle Befehle einzeln senden, und bestaetigen lassen
- man uebertraegt pro Funknachricht nur zwei Nutzbytes (Befehl und Parameter).
- wenn irgendetwas(!) schiefgeht, dann kann man erst in 15 Minuten weitermachen.
- mehrere FHT Befehle zu senden kostet eine nicht unerhebliche Menge der verfuegbaren 1% Sendebudget, und blockiert relativ lange den Funkraum.

Mit diesem Protokoll viele Befehle erfolgreich zu senden ist ein Geduldsspiel und eher Gluecksache.

softbuffer greift dann, wenn das FHT Hardware-Puffer mit anderen Befehlen voll ist.
Das ist bei dem FHZ1000 relevant, der FHZ1300 hat einen deutlich groesseren Puffer.

[Hinata]

Ich habe das weiter untersucht, das Wiki sagt zu FHT80b:

… Der FHT80b akzeptiert Befehle von einer Zentrale nur alle 115+x Sekunden (x = 0.5*letztes Byte des FHT-Hauscodes (auch FHT-ID genannt), Beispiel: FHT-ID 1234, Sendeintervall = 115+0,5*4 = 117 Sekunden) Praktisch ergeben sich so ca. zwei Minuten. … Der FHT80b übermittelt ungefähr alle 15 Minuten aktuelle Temperaturdaten an die Zentrale. (https://wiki.fhem.de/wiki/FHT80b).

Das deckt sich auch mit meinen Beobachtungen.

Mit meiner FHZ1300 wird:

• Der Minutenwert des Befehls set minute unverändert übernommen. Es wird ein Event für minute erzeugt und Readings aktualisiert.
• set time funktioniert auch. Sowohl hour wie minute wird an FHT80b übertragen. Die FHZ1300 (oder FHT80b) scheint hier generell den Minutenwert um 1 Minute zu erhöhen. Für hour wird ein Event erzeugt und das Reading aktualisiert. Für minute wird kein Event erzeugt und auch Reading nicht aktualisiert. Da scheint irgendwo ein Fehler zu sein.

Genauigkeit von set time mit FHZ1300:

• Ich verstehe das so: Sendebefehl wird 0 bis 120s verzögert an FHT80b gesendet. FHZ1300 (oder FHT80b) addiert 60s, damit ist Wert auf etwa 1 Minute (genau genommen: kann bis zu 1 Minute vor oder nachgehen) genau.
• Ich hatte auch schon softbuffer und retrycount aktiviert. Die FHZ1300 kennt diesen Mechanismus nicht und führt bei einem retry keine weitere Zeitkorrektur durch. Bei jedem retry verschiebt sich die Zeit damit um weitere 240s.

[rudolfkoenig]

Der FHT80b akzeptiert Befehle von einer Zentrale nur alle 115+x Sekunden...

Das ist falsch, es sollte heissen "ein FHT80b sendet Stellbefehle an die FHT8vs nur alle 115+x Sekunden".
Befehle vom FHZ werden nur nach der Temperaturmeldung (alle 15 Minuten) akzeptiert.

Im vorliegenden Fall schafft der FHZ vermutlich nur ein Befehl pro Gelegenheit zu uebertagen.
Weiss nicht mehr genau, was mit den anderen, im Pufferr befindlichen Befehlen passiert.

Nachtrag: Readings werden dann aktualisiert, wenn der FHT den Empfang bestaetigt hat.

[Hinata]

Je mehr ich lese und probiere umso verwirrter bin ich   .

Um das auszuprobieren habe ich mit set minute einen falschen Wert gesetzt und dann anschließend set time geschickt. Ich habe mich neben das FHT80b gestellt und beobachtet wann der Wert übernommen wird. Der Wert wird definitiv nach max 120s übernommen und nicht erst nach 15 Minuten. In der fraglichen Zeit sendet das FHT80b auch keine aktualisierten Werte (measured-temp, actuator, …), das habe ich geprüft. Innerhalb von 15 Minuten konnte ich den Wert auch mehrfach ändern…

Deshalb stimmt nach meiner Beobachtung das Wiki…

Nachtrag: Readings werden dann aktualisiert, wenn der FHT den Empfang bestaetigt hat.

Warum kommt dann die Bestätigung für hour sofort? Der Befehl set time wird in set hour hh und set minute mm aufgeteilt und gesendet. Anscheinend aber nur set hour bestätigt?

[rudolfkoenig]

Es ist denkbar, dass eine andere / neuere(?) Version der FHT80b Firmware sich anders verhaelt.

Ich gebe meine Erfahrungen von vor ca 12 Jahren zurueck, als ich die Kommunikation zwischen FHZ, FHT80B und FHT8v ueber Mitschneiden der  Funktelegramme kennengelernt habe. Eine Dokumentation vom Hersteller ist mir nicht bekannt.
Danach habe ich die culfw FHT80b und FHT8v Kommunikation implementiert, was ich seitdem verwende.

Warum kommt dann die Bestätigung für hour sofort?

Meine Vermutung ist im vorherigen Beitrag zu lesen.

[Hinata]

Code: [Auswählen]

Es ist denkbar, dass eine andere / neuere(?) Version der FHT80b Firmware sich anders verhaelt.
Der Vollständigkeit halber: Laut Typenschild ein FHT80b-2

[Hinata]

Mein ursprüngliches Problem das ich lösen wollte, war die Uhrzeit der FHT80b zyklisch zu synchronisieren um ein Drift der Uhrzeit zu verhindern. Dazu hatte ich im Wiki diesen Beitrag gefunden: https://wiki.fhem.de/wiki/FHT:_Datum_und_Zeit_von_FHEM_setzen_lassen.

Code: [Auswählen]

define fht_timeupdate at *04:00:01 {if ($wday == 5)  { fhem("set TYPE=FHT time") } }
Zumindest mit der FHZ1300 ist bei mehreren FHT80b (in meinem Fall 6) davon abzuraten. Die Befehle werden alle in den Sendepuffer geschrieben und sequentiell ausgeführt. Dies kann beim letzten FHT80b zu einem Zeitversatz von bis zu 6 x 2 Minuten führen.

Ich habe das deshalb wie folgt versucht zu lösen. Hier wird pro Tag nur ein FHT80b synchronisiert:

Code: [Auswählen]

defmod at_fht_update_time at *01:00:01 {
   my @fhts=devspec2array("TYPE=FHT");
   for my $i (0 .. $#fhts) {
      if ($i == $wday) {
         my $fht=$fhts[$i];
         Log 3, "FHT Zeit synchronisieren: $fht";
         fhem("set $fht time");
      }
   }
}
Dies funktioniert meist gut, aber leider nur meist. Folgende Vorbedingungen müssen erfüllt sein:

• Kein weiterer Befehl im FHZ-Puffer, schon gar nicht an die jeweilige FHT80b.
• Softbuffer und Retrycount sollten nicht aktiv sein.

Wenn diese Bedingungen nicht erfüllt sind, führt dies zu einem Versatz von mehreren Minuten.

Generell Frage ich mich ob eine Zeitkorrektur überhaupt Sinn macht. Die maximale Genauigkeit die über einen Funkbefehl erreicht werden kann ist +/- 1 Minute. Die Genauigkeit und der daraus resultierende Drift des in dem FHT80b verbauten Timers dürfte um ein vielfaches kleiner sein.

Ich könnte mir folgenden Pseudocode vorstellen, kenne mich aber zuwenig aus um das umzusetzen:

• Softbuffer abschalten
• Warten bis Sendepuffer leer ist
• set time senden
• Auf Bestätigung von FHT warten
• Softbuffer wieder einschalten

[rudolfkoenig]

Generell Frage ich mich ob eine Zeitkorrektur überhaupt Sinn macht.

Fuer mich als CUL Benutzer schon, da culfw in der Lage ist, die Zeit beim Senden zu korrigieren. Auch wenn der interne Timer die Genauigkeit des minute Befehls um Groessenordnungen uebertifft, ist langfristig(!) das "minute Verfahren" ueber ein NTP synchronisiertes FHEM genauer. Beim time/hour kommt die Korrektur der Zeitumstellung hinzu.

Wenn jemand das anders sieht, der muss ja den Befehl nicht absetzen.

[Hinata]

Bei der Durchsicht des FHT-Codes ist mir aufgefallen, das es bei aktiviertem Softbuffer eine Priorität der Befehle gibt. Würde es hier nicht Sinn machen set minute die höchste Priorität zu geben?

https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/11_FHT.pm#L142

[rudolfkoenig]

Würde es hier nicht Sinn machen set minute die höchste Priorität zu geben?

Ich meine zwar nicht, der Aufwand eines Nachweises ist mir aber zu hoch, und da es nicht schadet, und ich die Diskussion minimieren will, habe ich es eingebaut.

Ich kann mich dunkel an solche Probleme mit meinem FHZ erinnern, vermutlich habe ich softbuffer auch deswegen implementiert.
Solche Probleme hatte ich nach dem Wechsel auf CUL nicht, womoeglich waere das in diesem Fall eine Alternative

[Hinata]

Danke für die Änderung. Ich teste das und melde mich wieder. Da das Problem nur sporadisch auftritt muss ich das einige Tage beobachten.

[Hinata]

Nach meinen Tests bringt die Erhöhung der Priorität für minute keine Vorteile. Ich schlage vor die Änderung wieder rückgängig zu machen.

Ich teste derzeit eine andere Lösung, die sich auf diesen Link bezieht:
https://community.symcon.de/t/fht-uhrzeit-setzen/14926

Erste Tests waren erfolgreich und setzen die Uhrzeit jeweils auf lokale Zeit + 30s.

Code: [Auswählen]

sub
FhtSyncTime($)
{
 my ($fht) = @_;
 # 0.5*letztes Byte des FHT-Hauscodes
 my $interval = 115 + 0.5*9;
 my $timestamp = ReadingsTimestamp($fht, "actuator", "");
 my $offset = ($interval - 5) - (gettimeofday() - time_str2num($timestamp));
 if ($offset < 15) {
    # zu knapp, besser nächstes Interval nutzen
    $offset += $interval;
 }
 $offset += gettimeofday();
 my $synctime = POSIX::strftime("%H:%M:%S",localtime($offset));
 Log 3, "FHT Zeit $fht synchronisieren um: $synctime";
 InternalTimer($offset, "doFhtSyncTime", $fht);
}

sub
doFhtSyncTime($)
{
 my ($fht) = @_;
 Log 3, "FHT Zeit $fht synchronisieren";
 my $buflen = fhem("get FHZ_0 fhtbuf");
 if ($buflen =~ m/4a$/) {
    my @t = localtime;
    if ($t[0] > 30 ) {
       $t[1] += 1;
    }
    fhem("set $fht hour $t[2] minute $t[1]");
 }
}