Behandlung von FHT8v in CUN/CUL
agen
ich habe schon alles durchgeforstet, bin aber nicht fündig geworden:
Wie bzw. wann erfolgt denn die Synchronisation der Ventile mit der
CUN ? Die Logik mit den 116 Sekunden Zeitfenstern und den
Ventileinträgen die in diesen Zeitfenstern verschickt werden habe ich
im Source gefunden, aber wann erfolgt denn die Synchronisation (der 2-
minütige countdown mit dem 0x2c command ) die doch m.E. der Startpunkt
für die Zeitfenster ist ?
Danke schon mal für die "Nachhilfe"
Andreas
Rudolf Koenig
> CUN ?
8v Bedienung mit dem CUL (z.Zt noch nicht dokumentiert, freiwillige vor):
1. Mit T01HHHH Hauscode vergeben (wird von FHEM eigentlich gemacht).
Pruefen des Hauscodes mit T01
2. Ventilbefehl speichern:
THHHH00B640 (25%)
und mit T10 8v Puffer abfragen
3. 8V dem CUL zuordnen:
8v Knopf 3 Sek lang druecken, 8v piept. Im CUL "pair" absetzen:
THHHH002F00
8v piept erneut, Antenne blinkt.
4. Mit T11 naechsten Telegramm-Zeitpunk pruefen, falls dieser Wert 0 erreicht,
dann wird der 8v erneut piepen, und die Antenne blinkt nicht mehr.
5. Ab jetzt wird der Pufferinhalt (T10) regelmaessig dem 8v uebertragen.
Sync (2C) ist noch nicht implementiert, d.h. nach einem CUL reboot ist erneut
ein manueller Eingriff (8v Zuordnung) notwendig. Das Ganze wird auch durch
fhem noch nicht unterstuetzt.
agen
OK - danke für die Antwort
> Sync (2C) ist noch nicht implementiert, d.h. nach einem CUL reboot ist erneut
> ein manueller Eingriff (8v Zuordnung) notwendig. Das Ganze wird auch durch
> fhem noch nicht unterstuetzt.
perl zu tun) finde ich den sync schon wichtig, da ich keine FHT8b´s
besitze.
Meine "Schnellimplementierung des sync" (funktioniert auch) nur so als
Anregung ;-)
im fht8v_timer ergänzt:
--------------------
if (insync == 1) {
hb[2] = 0;
hb[3] = 0x2c;
if (ctsync > 1){
hb[4] = ctsync;
ctsync -=2;
fht8v_timeout = 125;
addParityAndSendData(hb, 5, FHT_CSUM_START, 1);
return;
}
if (ctsync == 1){ // sleep 2 more seconds
ctsync --;
fht8v_timeout = 250;
return;
}
if (ctsync == 0){ // send broadcast
insync = 0;
hb[2] = 0;
hb[3] = 0x26;
hb[4] = 0x00;
fht8v_timeout = (125*(230+(fht_hc1&0x7)))>>1;
addParityAndSendData(hb, 5, FHT_CSUM_START, 2);
return;
}
}
-------------
im fht_send den "FHT8v mode commands" - Teil erweitern
-------------
#ifdef HAS_FHT_8v
if(hb[0]==fht_hc0 &&
hb[1]==fht_hc1) { // FHT8v mode commands
switch(hb[3]) {
case 0x2f: // pair
addParityAndSend(in, FHT_CSUM_START, 2);
break;
case 0x2c: // start syncprocess
insync = 1;
ctsync = 0xf3;
fht8v_timeout=1;
break;
default : // Store the rest
fht8v_idx = (hb[2] < 9 ? hb[2] : 0);
fht8v_buf[fht8v_idx*2 ] = hb[3]; // Command or 0xff for
disable
fht8v_buf[fht8v_idx*2+1] = hb[4]; // value
break;
}
return;
}
#endif
-------------
2 variablen in fht.c ergänzen
---------------
#ifdef HAS_FHT_8v
uint16_t fht8v_timeout;
uint8_t fht8v_buf[18], fht8v_idx;
uint8_t insync, ctsync;
#endif
---------------
und insync in fht_init auf 0 setze
---------------
insync=0;
---------------
Rudolf Koenig
> Meine "Schnellimplementierung des sync" (funktioniert auch) nur so als
> Anregung ;-)
Die Anregung habe ich mehr oder weniger identisch uebernommen, und mit 1.31
eingecheckt. Lustigerweise bekam ich von Alexander ein Tag spaeter eine andere
Implementierung des syncs. Er experimentiert auch mit dem Steuerung der 8v's,
siehe fhem/contrib/99_PID.pm.
Gruss,
Rudi
squawk
> eingecheckt. Lustigerweise bekam ich von Alexander ein Tag spaeter eine andere
> Implementierung des syncs. Er experimentiert auch mit dem Steuerung der 8v's,
> siehe fhem/contrib/99_PID.pm.
das war schon drollig, ich hatte diese Diskussion hier noch gar nicht
verfolgt und letzte Woche einfach drauf los programmiert :-))
dann schreibe ich hier auch mal. Denn ich bin schon wieder ein Stück
weiter, musste dafür aber die CUL-Firmware erneut patschen.
Meine Beobachtung ist nämlich folgende:
Die FHT8vs bekommen hier teilweise mit der Orginalfirmware 1.30 (mit
Synch-Patch) nur alle 10 Minuten neue Werte. Die CUL-Firmware ist
außerdem so aufgebaut, dass der zuletzt gesetzte fht8v zuerst bedient
wird (fht8v_idx Variable, die beim Beschreiben eines "Slot-Kommandos"
auf das jeweils zuletzt geschriebene zeigt). Zunächst habe ich das
einfach raus genommen, dass der Index beim Schreiben so verwaltet
wird. Aber das endet eben bei fünf hier im (Test)Betrieb befindlichen
FHT8vs darin, dass diese eben nur alle 10 Minuten mit neuen Werten
bedient werden.
Ich habe daraufhin etwas anderes probiert:
Ich habe die CUL-Firmware dahingehend abgeändert, dass ich den Haus-
Code anders verwende. Jeder FHT8v bekommt jetzt einen eigenen Haus-
Code. Damit es mit der Zeitsynchronisation auch weiterhin klappt,
dürfen die unteren zwei Bits nicht abweichen, deshalb habe ich das
obere Byte fht_hc0 aufsteigend vergeben (T2020012F00, T2120012F00...).
Die Firmware sendet jetzt jeweils alle zwei Minuten die Kommandos nur
einmal (ohne repeat) an die Stellantriebe.
Bei einer nicht geglückten Übertragung ist die Lücke bis zum nächsten
Wert jetzt trotz gesparter Retransmission viel kürzer, als die Lücke,
die vorher entstand, bis überhaupt ein Wert (dafür sicherer) kam.
Damit lässt sich jetzt eine wirklich flüssige Regelung realisieren!
Dabei ist mir übrigens eine Unschönheit in rf_send.c aufgefallen: Wird
die Routine sendraw mit null repaets aufgerufen, knallt es wegen Über/
Unterlauf. Die Variable repaet ist uint8_t.
Deshalb vielleicht lieber statt:
} while(--repeat > 0);
ein:
} while ( repaet-- > 0 );
Ansonsten habe ich hier jetzt schon mal Lehrbuchmäßig die
Sprungantwort meiner Räume gemessen und optimiere die Regelparameter
für meine PID-Regelung. Ist schon nett soweit!
Würde mich freuen, wenn wir das mal Diskutieren könnten, wie man da zu
einer guten Lösung kommt (vielleicht Verschiedene Module durch
bedingte Compilierung). Ich habe bei mir jetzt z.B. die Steuerung der
FHT80 rausgenommen, da die FHT8v-Steuerung mir
(verständlicherweise ;-) viel wichtiger ist.
Gruß erstmal,
Alexander
Rudolf Koenig
> Die Firmware sendet jetzt jeweils alle zwei Minuten die Kommandos nur
> einmal (ohne repeat) an die Stellantriebe.
Verstehe ich es richtig:
- Du hast 5 Stellantriebe, die vorher mit dem gleichen Hauscode aber
unterschiedlichen Ventilnummer versehen wurden. Da culfw nur ein Stellantrieb
auf einmal stellt, hat es 5x2 = 10 Minuten gedauert, bis jeder einmal an die
Reihe kam. Jedesmal wurde das Signal 2-mal gesendet.
- Jetzt haben alle unterschiedliche Hauscodes, und alle werden auf einmal
gesendet. Mit wievielen 8v's klappt das maximal? Ich hab Angst, dass die 8v's
zu schnell abschalten.
Gruss,
Rudi
squawk
Nö, das ist ja der Witz, die 8v's werden nicht abschalten, da sie
jetzt leicht hintereinander synchronisiert sind (jeder denkt, er habe
eine FHT80, die lustigerweise exakt alle kurz hintereinander senden
und hübsch zueinander passende Hauscodes haben ;-).
Da sie alle unterschiedliche Hauscodes haben, sind die FHT8vs alle
auch nacheinander aktiv. Deswegen (da ja nur ein Zeitintervall bedient
werden kann) darf eben der unterste Teil des Hauscodes (die letzten
zwei Bits) nicht abweichen. Alle fünf Stellantriebe laufen jetzt hier
seit einigen Stunde vollkommen störungsfrei. Ich berichte weiter,
falls ich erfriere ;-) Ob noch mehr gehen, weiß ich nicht, ich vermute
aber mal, dass ich das Spiel mit noch mehr Antrieben ganz locker
vorsetzen kann (bis culfw zulange sendet).
Das andere ist genau richtig von Dir interpretiert, so ist es! Aber:
mit Glück bekomme ich jede 10 Minuten einen neuen Wert bei den
Stellantrieben. Da die S300TH aber das Event triggern, zu dem die
Regelung neu rechnet (und neue Stellgrößen generiert) läuft es auf ein
lockeres Intervall von 3 Minuten hinaus, mit dem der fht8-Buffer mit
neuen Werten gefüllt wird. Und hier kommt fht8v_idx ins Spiel und
setzt die Reihenfolge dann so fest, dass der zuletzt geschriebene Wert
tatsächlich gesendet wird. Manchmal hat ein Stellantrieb so (bei
unglücklicher zeitlichen Verhältnissen) sehr viel länger als 10Minuten
keinen neuen Wert bekommen.
Falls Du es mal ausprobieren willst, ich kann dir den (sehr
experimentellen) Patch ja mal zur Verfügung stellen. Ich glaube so
gelöst läuft das für eine Regelung echt besser...
Gruß,
Alexander
squawk
jetzt läuft die geänderte Firmware seit einer Woche sehr erfolgreich.
Fünf Stellantriebe haben konstanten - schnell reagierenden - Kontakt.
Die Regelung läuft stabil und zuverlässig.
Woll't ich nur mal so erzählen.
Gruß,
Alexander
tiptronic
wenn Du nicht fhem verwendest, was verwendest Du dann, wenn ich fragen
darf?
Ich hab' seit gestern meine erste CUL und wollte am Wochenende mal
damit rumspielen.
Wenn ich Dich richtig verstehe, dann hast Du S300 und FHT8v gemeinsam
im Einsatz. Genau das möchte ich auch machen. Gibt's da irgendwas
besonderes zu beachten, oder hast Du ein paar Tipps, was ich auf
keinen Fall machen soll?
Vielen Dank
andy