FHEM - Hausautomations-Systeme > SlowRF

FHZ1300 / FHT80b set time funktioniert (nicht immer)

(1/3) > >>

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: ---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

--- Ende Code ---

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:

--- Zitat ---… 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).
--- Ende Zitat ---
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.

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln