FHT 8v direkt ansprechen!?

[habichthugo]

Dazu gibt es ja einen Beitrag im Wiki (http://www.fhemwiki.de/wiki/FHT_8v_direkt_ansprechen).
Wie aber verhält sich FHEM, wenn es neu gestartet wird, mit bereits gepairten FHT 8v? Wird dann automatisch ein Sync. ausgeführt (wie z.B. nach einem Batteriewechsel der FHT80b)? Und wie/wann sendet FHEM den FHT 8v die Ventilöffnungsgrade? Auch immer wieder ca. alle 2 Min., oder nur bei Änderung?

[rudolfkoenig]

Culfw sendet die Daten selbststaendig, FHEM sagt nur, was. Ein FHEM-Neustart sollte nichts bewirken, nach einem culfw-reboot (z.bsp wg. strom-weg) muss aber ein sync durchgefuehrt werden. Achtung: ich habe das nur programmiert, aber selber nicht im Betrieb, deswegen sind meine Aussagen mit Vorsicht zu geniessen.

[habichthugo]

... nach einem culfw-reboot (z.bsp wg. strom-weg) muss aber ein sync durchgefuehrt werden...

Also muss man ggf. den Sync manuell durchführen? Dann ist mir das für den Alltagsbetrieb zu unsicher.

[betateilchen]

Nein, muss man nicht generell.

Es hängt davon ab, wie lange die Verbindung zwischen fhem und dem fht8v unterbrochen war, eine Unterbrechung bis zu 30 Minuten wirkt sich überhaupt nicht aus.

Wie oft die Daten an den Stellantrieb gesendet werden, musst Du in fhem festlegen.
Entweder Du hast den fht8v in einen PID eingebunden, dann wird das automatisch erledigt.
Oder (so habe ich das bei mir gelöst) Du legst das in einer at-Definition fest, die das z.B. alle 10 Minuten macht.

Bei mir werden zwei FHT8V alle 10 Minuten mit set valve 0 befeuert, weil ich diese beiden Heizkörper generell nicht nutze und nur einmal pro Woche die Entkalkungsfahrt des Ventils durchführe.

[habichthugo]

Nein, muss man nicht generell.

Es hängt davon ab, wie lange die Verbindung zwischen fhem und dem fht8v unterbrochen war, eine Unterbrechung bis zu 30 Minuten wirkt sich überhaupt nicht aus.
...

Also, dann verstehe ich die Kommunikation mit den FHT8v generell nicht richtig.
Soweit ich das verstanden habe, sind die FHT8v nur ca. alle 2 Min. empfangsbereit. Sobald die also mit FHEM (wie hier <http://fhem.de/commandref.html#FHT8V> beschrieben) gepairt sind, kann FHEM (bzw. der CUL) so einem FHT8v alle ca. alle 2 Min. Daten schicken. Wenn ich jetzt aber FHEM/CUL ausser Tritt bringe, also z.B. durch einen Stromausfall, dann kann FHEM/CUL doch gar nicht mehr wissen, wann ein FHT8v empfangsbereit ist (und würde ggf. die Stellbefehle ins Nirvana senden).
Daneben: Wenn ich in FHEM ein 'set <name> valve <value;>' absetze, kann FHEM das nur zum nächsten ca. 2 Min. Synchronzeitpunkt abschicken. Was passiert also, wenn ich mehr als alle ca. 2 Min. so ein set absetze? Geht dann nur das letzte zum nächsten Synchronzeitpunkt raus? Oder wie kriege ich meine Stellbefehlwünsche synchron mit den Sendezeitpunkten?
Dazu habe ich von rudolfkoenig noch folgende Info. per Mail erhalten:
"Das Problem kann man auch erstmal mit notify (global:INITIALIZED|CUL:CONNECTED) in FHEM loesen"
+
"Man sendet dem culfw das SYNC Befehl via RAW (set CUL raw T1234002C78), siehe <http://culfw.de/commandref.html#FHT_8v>"
Es gibt also wohl die Möglichkeit, einen Sync. aus FHEM anzuwerfen, wenn auch bislang nur low level. Und der CUL ist dann für einen 'regulären' Sync. (a la FHT80b) für ca. 2 Min. pro FHT8v sendeblockiert!?
Muss mal gucken, wann ich die Zeit finde, dass mal praktisch zu erproben...

[betateilchen]

Also, dann verstehe ich die Kommunikation mit den FHT8v generell nicht richtig.

Das scheint mir auch so. Irgendwie denkst Du einfach viel zu kompliziert.

Achja - und fhem hat nicht den blassesten Schimmer davon, wann ein FHT8V empfangsbereit ist oder nicht. Und ja, die Befehle laufen immer ins Nirvana, in der Hoffnung, irgendwo gehört und interpretiert zu werden. Das ist so ähnlich wie mit Raumsonden auf der Suche von Lebewesen im Universum. Man schickt sie halt einfach mal los, in der Hoffnung, vielleicht doch mal was zu finden. Nur die Erfolgschancen, einen vorhandenen FHT8V zu erreichen sind ungleich höher.

[rudolfkoenig]

Ein FHT8v wacht alle 118+x*0.5 Sekunden fuer eine Sekunde auf. In dieser Sekunde muss ein Telegramm  vom CUL ankommen. FHEM sagt dem CUL im FHT8v-direkt-Modus, was gesendet werden soll. Wann, egal, culfw merkt das, und sendet dies zur rechten Zeit alle 118+x*0.5 Sekunden, bis FHEM was anderes sagt.

Falls das CUL (nicht FHEM!) rebootet wird, dann muss man culfw wieder sagen, was gesendet werden soll, und ein Sync mit den FHT8v's durchfuehren. Dazu gibt es ein Sync Befehl (2C), der 120 Telegramme sendet, eins pro Sekunde, und damit jeden FHT8v "erwischt".
Falls man vor dem reboot die Sendezeit abspeichert (siehe auch http://culfw.de/commandref.html#cmd_T T11) , dann kann man auch weniger als 120 angeben, um Sendezeit zu sparen.

Wenn das Senden fuer ca eine halbe Stunde (hier bin ich nicht sicher) nicht erfolgt, dann geht ein FHT8v in die Notposition (30% Oeffnung). Ich weiss auch nicht, ob ein FHT8v in dieser Stellung noch empfaengt, ich vermute nicht.

[betateilchen]

Ich weiss auch nicht, ob ein FHT8v in dieser Stellung noch empfaengt, ich vermute nicht.

Nein, tut er nicht.

Falls das CUL (nicht FHEM!) rebootet wird, dann muss man culfw wieder sagen, was gesendet werden soll, und ein Sync mit den FHT8v's durchfuehren.

Hast Du das wirklich getestet? Ich habe das jedenfalls noch nie gemacht, wenn ich nach einer Spannungsunterbrechung meinen CUL wieder in Betrieb gesetzt habe, und trotzdem funktionieren meine FHT8V völlig problemlos.

[habichthugo]

Das scheint mir auch so. Irgendwie denkst Du einfach viel zu kompliziert.

Achja - und fhem hat nicht den blassesten Schimmer davon, wann ein FHT8V empfangsbereit ist oder nicht.
...

Ne, offenbar nicht (siehe vorherigen Beitrag von rudolfkoenig)

Ein FHT8v wacht alle 118+x*0.5 Sekunden fuer eine Sekunde auf. In dieser Sekunde muss ein Telegramm  vom CUL ankommen. FHEM sagt dem CUL im FHT8v-direkt-Modus, was gesendet werden soll. Wann, egal, culfw merkt das, und sendet dies zur rechten Zeit alle 118+x*0.5 Sekunden, bis FHEM was anderes sagt.

Ok, dann weiß der CUL ab 'set <name> pair' das 118+x*0.5 Sekunden-Zeitfenster und setzt das letzte 'set <name> valve <value;>' jeweils zum nächst möglichen Zeitpunkt ab.

Falls das CUL (nicht FHEM!) rebootet wird, dann muss man culfw wieder sagen, was gesendet werden soll, und ein Sync mit den FHT8v's durchfuehren. Dazu gibt es ein Sync Befehl (2C), der 120 Telegramme sendet, eins pro Sekunde, und damit jeden FHT8v "erwischt".
Falls man vor dem reboot die Sendezeit abspeichert (siehe auch http://culfw.de/commandref.html#cmd_T T11) , dann kann man auch weniger als 120 angeben, um Sendezeit zu sparen.

Würde es reichen, nur den CUL via USV (Batterie am USB-Hub) am Leben zu halten, während mein Ubuntu-Server (nach einem Stromausfall) rebootet? Oder gibt FHEM dem CUL beim Hochlaufen einen Reset?

Wenn das Senden fuer ca eine halbe Stunde (hier bin ich nicht sicher) nicht erfolgt, dann geht ein FHT8v in die Notposition (30% Oeffnung). Ich weiss auch nicht, ob ein FHT8v in dieser Stellung noch empfaengt, ich vermute nicht.

Das werde ich mal austesten. Wenn die Teile im Notmodus automatisch auch Scannen (wie nach Batteriewechsel), dann würden sie sich ja automatisch nach max. 1/2 h wieder mit FHEM syncen!?

[rudolfkoenig]

@betateilchen:
Nein, ergibt sich aber aus dem normalen Sende-Verfahren, die ich lange getestet habe. Ich hatte am Anfang das 115+0.5*x falsch berechnet (x war mir nicht bekannt), und damit konnte ich genau einmal nach dem Pairing Daten uebertragen. Deswegen gehe ich davon aus, dass es keinen weiteren auto-sync Mechanismus gibt. Lerne gerne hinzu, aber bitte nur bewiesene Theorien

P.S. sorry fuer das 118 weiter unten, korrekt ist laut culfw/clib/fht.c 115:

Code Auswählen Erweitern

    fht8v_timeout = (125*(230+(fht_hc1&0x7)))>>1;


@habichthugo: FHEM rebootet culfw nicht, siehe auch "get CUL uptime"

[betateilchen]

(offtopic)

und damit konnte ich genau einmal nach dem Pairing Daten uebertragen.

Genau dieses Problem hatte ich, als ich FHT noch mit einem COC verwendet habe. Seit ich auf CUL umgestiegen bin, gibt es dieses Verhalten nicht mehr.
(/offtopic)

Und meine beiden erwähnten FHT8v sind keine Theorie, sondern sie existieren und funktionieren tatsächlich in meiner Wohnung

[habichthugo]

So, habe das jetzt mal mit zwei nativen FHT80b3 und drei FHT8v getestet. An einer der FHT80b3 'hängen' zwei FHT8v (mit Kieback&Peter-Label, der Rest ELV). Aus dieser FHT80b3 habe ich zuerst die Batterieen herausgenommen. Danach dauerte es knapp zwei Stunden, bis die beiden korrespondierenden FHT8v auf 30% gingen (nebst kurzem Piepsen und ausstellen des Antennensymbols). Parallel dazu habe ich ca. 3/4 Stunde versetzt aus der zweiten FHT80b3 die Batterien entfernt. Auch hier ging die korrespondierende FHT8v nach ca. zwei Stunden auf 30%. Dann habe ich die erste FHT80b3 wieder angeworfen, und zwar zunächst in der Microwelle, um den Sync. abzuschirmen.  Die FHT8v blieben danach zunächst auf 30%, aber nach ein bis 1 1/2 Stunden (da habe ich leider nicht so genau aufgepasst) waren sie dann doch wieder mit ihrer FHT80b3 verbunden. Die zweite FHT80b3 habe ich dann normal anlaufen lassen, d.h. mit Sync. Die korrespondierende FHT8v reagierte auch hier nicht unmittelbar, weshalb ich sie dann manuell wiederverknüpft habe.
Ich mache das Experiment morgen noch mal mit zwei anderen Paaren, vor allem um genauer herauszufinden, ob die wirklich zuverlässig wieder aufsetzen und wie lange das genau dauert.

[habichthugo]

Habe heute nochmals zwei Tests mit jeweils zwei FHT80b/FHT8v-Paaren gemacht:
1. Beide FHT80b Batterieen raus und wieder rein. Den automatischen Sync. haben sie in Alufolie geschirmt abwarten müssen. Nach fünf Minuten habe ich sie wieder ausgepackt. Die FHT8v blieben dann auf ihrem Stellwert stehen, während die FHT80b munter Stellbefehle ins Nirvana sandten. Nach ziemlich genau zwei Stunden piepten beide FHT8v ein Mal und waren ab da wieder synchron mit ihrer jeweiligen FHT80b.
2. Das Ganze noch mal, allerdings die FHT80b geschirmt gelassen, bis ca. 5 Min. nachdem ihre FHT8v (nach zwei Stunden) auf 30% Notbetrieb umgestellt hatten. Dann beide FHT80b wieder 'frei gelassen'. Die FHT8v blieben ca. eine Stunde weiter auf 30% Notbetrieb (Stellbefehle der FHT80b ins Nirvana), dann rasteten sie mit einem Piep wieder ein.

Summa summarum:
Die FHT8v hören im Normalbetrieb ca. alle zwei Min. ((125*(230+(fht_hc1&0x7)))>>1) auf Stellbefehle. Bleiben diese aus (oder kommen ausserhalb dieser Tacktung) machen sie nach ca. zwei Stunden einen Scan (ca. 2 Min. oder vielleicht auch 2*2Min?), um sich wieder mit ihrer FHT80b zu syncen. Klappt das nicht gehen sie für ca. eine Stunde in den Notbetrieb (30%) und machen erst dann wieder einen Scan. Das Ganze dürfte sich dann alle Stunde wiederholen...

[rudolfkoenig]

Verstehe ich richtig, dass deswegen ein von FHEM/culfw ausgeloestes sync nur fuer Ungeduldige wichtig ist?

[habichthugo]

Verstehe ich richtig, dass deswegen ein von FHEM/culfw ausgeloestes sync nur fuer Ungeduldige wichtig ist?

Wenn du den 2 Min. Countdown meinst, offenbar ja.