FHT 8v direkt ansprechen!?

Begonnen von habichthugo, 24 Januar 2014, 15:33:00

Vorheriges Thema - Nächstes Thema

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?
CUL (CC1101-USB-Lite module-V3) + 5*fht80b + 6*Mumbi-Funksteckdosen (=Elro AB440); HM-LAN + 11*HM-LC-Bl1PBU-FM Rollladenaktor + 1*HM-LC-Sw1PBU-FM Funklichtschalter + 2*HM-RC-12-W; Raspbian (Raspberry Pi Model B Rev 1 ECN0001 256MB)

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

Zitat von: rudolfkoenig am 24 Januar 2014, 16:19:40
... 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.
CUL (CC1101-USB-Lite module-V3) + 5*fht80b + 6*Mumbi-Funksteckdosen (=Elro AB440); HM-LAN + 11*HM-LC-Bl1PBU-FM Rollladenaktor + 1*HM-LC-Sw1PBU-FM Funklichtschalter + 2*HM-RC-12-W; Raspbian (Raspberry Pi Model B Rev 1 ECN0001 256MB)

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.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

habichthugo

#4
Zitat von: betateilchen am 29 Januar 2014, 11:44:50
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...
CUL (CC1101-USB-Lite module-V3) + 5*fht80b + 6*Mumbi-Funksteckdosen (=Elro AB440); HM-LAN + 11*HM-LC-Bl1PBU-FM Rollladenaktor + 1*HM-LC-Sw1PBU-FM Funklichtschalter + 2*HM-RC-12-W; Raspbian (Raspberry Pi Model B Rev 1 ECN0001 256MB)

betateilchen

Zitat von: habichthugo am 29 Januar 2014, 12:36:53Also, 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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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

Zitat von: rudolfkoenig am 29 Januar 2014, 14:17:03Ich weiss auch nicht, ob ein FHT8v in dieser Stellung noch empfaengt, ich vermute nicht.

Nein, tut er nicht.

Zitat von: rudolfkoenig am 29 Januar 2014, 14:17:03Falls 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.


-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

habichthugo

Zitat von: betateilchen am 29 Januar 2014, 13:49:57
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)

Zitat von: rudolfkoenig am 29 Januar 2014, 14:17:03
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.

Zitat von: rudolfkoenig am 29 Januar 2014, 14:17:03
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?

Zitat von: rudolfkoenig am 29 Januar 2014, 14:17:03
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!?
CUL (CC1101-USB-Lite module-V3) + 5*fht80b + 6*Mumbi-Funksteckdosen (=Elro AB440); HM-LAN + 11*HM-LC-Bl1PBU-FM Rollladenaktor + 1*HM-LC-Sw1PBU-FM Funklichtschalter + 2*HM-RC-12-W; Raspbian (Raspberry Pi Model B Rev 1 ECN0001 256MB)

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:
    fht8v_timeout = (125*(230+(fht_hc1&0x7)))>>1;


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

betateilchen

(offtopic)
Zitat von: rudolfkoenig am 29 Januar 2014, 14:53:30und 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 ;)

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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.
CUL (CC1101-USB-Lite module-V3) + 5*fht80b + 6*Mumbi-Funksteckdosen (=Elro AB440); HM-LAN + 11*HM-LC-Bl1PBU-FM Rollladenaktor + 1*HM-LC-Sw1PBU-FM Funklichtschalter + 2*HM-RC-12-W; Raspbian (Raspberry Pi Model B Rev 1 ECN0001 256MB)

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...
CUL (CC1101-USB-Lite module-V3) + 5*fht80b + 6*Mumbi-Funksteckdosen (=Elro AB440); HM-LAN + 11*HM-LC-Bl1PBU-FM Rollladenaktor + 1*HM-LC-Sw1PBU-FM Funklichtschalter + 2*HM-RC-12-W; Raspbian (Raspberry Pi Model B Rev 1 ECN0001 256MB)

rudolfkoenig

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

habichthugo

Zitat von: rudolfkoenig am 30 Januar 2014, 18:09:48
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.
CUL (CC1101-USB-Lite module-V3) + 5*fht80b + 6*Mumbi-Funksteckdosen (=Elro AB440); HM-LAN + 11*HM-LC-Bl1PBU-FM Rollladenaktor + 1*HM-LC-Sw1PBU-FM Funklichtschalter + 2*HM-RC-12-W; Raspbian (Raspberry Pi Model B Rev 1 ECN0001 256MB)

betateilchen

aber mir wollte ja niemand glauben...  >:(
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

habichthugo

Zitat von: betateilchen am 30 Januar 2014, 18:46:38
aber mir wollte ja niemand glauben...  >:(
Schon, aber u.a.
Zitat von: betateilchen am 29 Januar 2014, 14:33:38
Nein, tut er nicht.
tut er doch!

Ist doch Wurst. Jetzt ist das Verhalten jedenfalls klar (so es die Dinger nicht noch mit anderen Firmwaren gibt).
CUL (CC1101-USB-Lite module-V3) + 5*fht80b + 6*Mumbi-Funksteckdosen (=Elro AB440); HM-LAN + 11*HM-LC-Bl1PBU-FM Rollladenaktor + 1*HM-LC-Sw1PBU-FM Funklichtschalter + 2*HM-RC-12-W; Raspbian (Raspberry Pi Model B Rev 1 ECN0001 256MB)

betateilchen

Zitat von: habichthugo am 30 Januar 2014, 19:16:01tut er doch!

ja weiß ich. Aber das tut er erst nach so langer Zeit, dass manche Leute mit Sicherheit nie die Geduld aufgebracht hätten, darauf zu warten. Ich wußte zwar nicht, nach welcher Zeit es passiert, aber ich wusste aus meiner Anwendungspraxis, dass die Antriebe sich auf jeden Fall ohne Benutzerzutun wieder fangen.

Und genau wie Du sagst: DAS ist die Hauptsache :) Danke für Deine expliziten Experimente.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Puschel74

Hallo,

mich mal zwischenmischen muss  8)

ZitatDanke für Deine expliziten Experimente.
Ich muss schon sagen das ich es genial finde das sich Menschen diese Zeit nehmen und solche Sachen experimentell herausfinden/überprüfen.

@habichthugo
Hut ab - genial.
Ich wäre niemals auf die Idee gekommen meine FHT80b in die Mikrowelle zu packen oder in Alufolie einzuwickeln.
Und das ist jetzt nicht ironisch gemeint.

Grüße
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

betateilchen

Zitat von: Puschel74 am 30 Januar 2014, 21:26:09Und das ist jetzt nicht ironisch gemeint.

meine Antwort übrigens auch nicht :)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Puschel74

Habe ich mir gedacht.
Ich habe dich nur zitiert damit ich den Text nicht nochmal schreiben muss  :D
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

habichthugo

Was passiert, wenn ich dem CUL einen RAW-Stellbefehl für einen nicht gepairten FHT8v gebe? Also z.B.
set CUL_0 raw T1234012600
Geht der sofort, ohne Verzögerung raus?

Hintergrund ist, dass ich den FHT80b gerne die Kontrolle über die FHT8v abluchsen bzw. übersteuern möchte (100% für Raum mit grösster Ventilöffnung, andere Räume ggf. drosseln, um Überschwingen zu vermeiden). Die autarke Regelung soll aber als Rückfallebene erhalten bleiben. Also möchte ich mal probieren, was passiert, wenn ich direkt nach dem Stellbefehl einer FTH80b noch einen modifizierten via FHEM bzw. CUL nachschiebe.
CUL (CC1101-USB-Lite module-V3) + 5*fht80b + 6*Mumbi-Funksteckdosen (=Elro AB440); HM-LAN + 11*HM-LC-Bl1PBU-FM Rollladenaktor + 1*HM-LC-Sw1PBU-FM Funklichtschalter + 2*HM-RC-12-W; Raspbian (Raspberry Pi Model B Rev 1 ECN0001 256MB)

habichthugo

#22
Also, irgend was stimmt da an der Beschreibung im Wiki (http://www.fhemwiki.de/wiki/FHT_8v_direkt_ansprechen#Kommando_Struktur_und_bekannte_Befehle) nicht!
'set CUL_0 raw THHHHDDCCVV' bzw. 'set CUL_0 raw T1234012685 -> Stellantrieb 52 %'
müsste auf mich angewandt z.B.
'set MyCUL raw T4D06012685 -> Stellantrieb 52 %'
ergeben. Aber keiner der zwei Stellantriebe reagiert darauf, sie rasten (nach Batterieentnahme -> A3) immer wieder auf die FHT80b ein.
Im Log sehen Parses auch ganz anders aus, z.B.:
2014.01.05 23:52:23 4: CUL_Parse: MyCUL T4D060026571D -59.5
2014.01.05 23:52:23 4: FHT FHT_Wohnzimmer actuator: 34%
2014.01.17 11:56:29 4: CUL_Parse: MyCUL T4D0600A60017 -62.5
2014.01.17 11:56:29 4: FHT FHT_Wohnzimmer actuator: 0%
2014.01.31 18:00:01 4: CUL_Parse: MyCUL T4D0600B65610 -66
2014.01.31 18:00:01 4: FHT FHT_Wohnzimmer actuator: 34%
2014.01.31 18:30:55 4: CUL_Parse: MyCUL T4C1900A6181F -58.5
2014.01.31 18:30:55 4: FHT FHT_Bad actuator: 9%
Ich nehme mal an, das letzte Byte ist die Prüfsumme (die ich beim set ... raw nicht mit angeben muss)? Auch bei nur einem Stelltrieb (Bad) passt das rote nicht ins obige Schema. Abwandlungen nach diesen Parses helfen auch nicht...
CUL (CC1101-USB-Lite module-V3) + 5*fht80b + 6*Mumbi-Funksteckdosen (=Elro AB440); HM-LAN + 11*HM-LC-Bl1PBU-FM Rollladenaktor + 1*HM-LC-Sw1PBU-FM Funklichtschalter + 2*HM-RC-12-W; Raspbian (Raspberry Pi Model B Rev 1 ECN0001 256MB)

rudolfkoenig

1. Ventilstellbefehle gehen nur im "Takt" raus, andere (pair, etc) sofort.
2. CUL + FHT80b parallel fuer das gleiche FHT8v geht nicht.
3. Es gibt ein FHT8v Modul, damit ist die Bedienung etwas einfacher.

habichthugo

Zitat von: rudolfkoenig am 31 Januar 2014, 19:56:25
1. Ventilstellbefehle gehen nur im "Takt" raus, andere (pair, etc) sofort.
2. CUL + FHT80b parallel fuer das gleiche FHT8v geht nicht.
3. Es gibt ein FHT8v Modul, damit ist die Bedienung etwas einfacher.
zu 1. Da geht wirklich kein 'richtiges' raw, also sofort raus damit?
zu 2. Im Prinzip klar. Schade, dass ich meine Idee so nicht ausprobieren kann.
zu 3. Ja...

Ich habe noch ein bischen experimentiert. Der Hauscode der FHT8V muss einer strengen Nomenklatur folgen, sonst schluckt das CUL die entsprechenden set ... raw einfach, ohne sichtbares Feedback. Gemerkt habe ich das erst als ich ein 'define <Name> FHT8V 1234 MyCUL' versucht habe, da kam eine entsprechende Fehlermeldung (Wrong housecode: must be one of 5axx 5bxx 5cxx 5dxx 5exx 5fxx 60xx 61xx). Im Wiki (http://www.fhemwiki.de/wiki/FHT_8v_direkt_ansprechen) steht davon leider nix, nur in der Reference (http://fhem.de/commandref.html#FHT8V).
Nach einem 'set <name> pair' funktionierten dann sowohl 'set <name> valve <value;>' als auch die entsprechenden 'set <name> raw ...'.
Zum Stellen war in 'set <Name> raw THHHHDDCCVV' für DD bzw. CC bei mir neben 01 bzw. 26 dann auch 00 oder 02 bzw. A6 oder B6 möglich. Mehr Kombinationen habe ich dann nicht mehr ausprobiert. Jedenfalls scheint dem FHT8v u.a. die Stellantriebnummer (DD) völlig schnurz zu sein.
Das CUL setz nach einem pair stur alle ca. 2 Min. einen Stellbefehl ab, und zwar jenen, der zuletzt via 'set <name> valve ...' oder auch raw gesetzt wurde. Mehrere solcher set vor dem nächsten Sendetermin überschreiben sich also. Das Senden der Stellbefehle geht selbst nach einem 'delete <Name>' munter weiter. Erst nach einem 'set myCUL raw B00' (reset CUL) war bei mir Ruhe.
Am Rande noch: Bei den FHT8v kommen für 0..100% bzw. 00..FFh 0..99% an (Display nur zweistellig).
CUL (CC1101-USB-Lite module-V3) + 5*fht80b + 6*Mumbi-Funksteckdosen (=Elro AB440); HM-LAN + 11*HM-LC-Bl1PBU-FM Rollladenaktor + 1*HM-LC-Sw1PBU-FM Funklichtschalter + 2*HM-RC-12-W; Raspbian (Raspberry Pi Model B Rev 1 ECN0001 256MB)