ich versuche mich gerade an der direkten Steuerung der FHT8v…
Die Skripte von Tommi haben die im ersten Bild sichtbare Struktur geschaffen. Ich vermute, dass es daran liegt, das CUNO den „Funkverkehr“ des FHZ1300PC und des FHT8i „mitgelauscht“ hat…
Ich möchte jetzt die FHT8v direkt steuern.
Muss der Antrieb auf jeden Fall mit dem CUNO „gepaart“ werden, oder reichen die Angaben die im Screenshoot sichtbar sind?
Die Scripte sind bisher nur zum Mitlesen ausgelegt, lediglich für FS20 gibt es (jedenfalls von mir) auch ein extra Script was zum senden. Die Struktur wird anhand der Daten vom CUN aufgebaut, der jeden Empfang sofort weitermeldet.
HC ist der Hauscode, wie er vom IPS FHT-Modul und auf dem FHT80b angezeigt wird. ID ist der Wert wie er vom CUN übergeben wird. Ist einfach nur eine andere Darstellung(Hex). Die Ventile reagieren nur in einem engen Zeitfenster auf Sendeimpulse, müssen deshalb wohl auch neu gepaart werden. Die genaue Bedeutung der einzelnen Bytes hat sich mir allerdings auch noch nicht erschlossen, da müßte man mal in den fhem Sourcecode für das Modul schauen. Ich hatte deshalb auch noch nicht selber versucht, ein FHT steuern
BTW:der Threadtitel suggeriert Details zum EM1000, was hier nicht ganz korrekt ist. @mods:Thread ggfls teilen.
Habe gerade jetzt erst den vorigen Post mit der Fehlermeldung gesehen.
Warning: Instanz #14595 existiert nicht in [Server\Testobjekte\CUNO\CUNO RegVar] on line 39
Modultyp wrong
In der Zeile 39 steht:
$inst=IPS_GetInstance($sid);
Was ist Object #14595?
Die Idee ist hier, das die Registervariable-Instance ein Subobjekt der zugehörigen IO-Instance ist. Ist sie das nicht, gibt Get_Parent natürlich irgendwas aus, nur keine ID einer Instance. Wenn ich dann mit dieser ID ein Instance-Object haben will, geht das natürlich schief. Da könnte man noch eine Prüfung einbauen, ob diese ID wirklich eine Instance ist oder was anderes.
//Parent=ClientSocket or ComPort
$sid=IPS_GetParent($reg);
if ($sid) {
$inst=IPS_GetInstance($sid);
Zeig mir doch bitte im Baum, wo die RegVar-Instance und was darüber ist.
worin liegt eigentlich genau die Herausforderung bei der direkten Steuerung der FHT8v durch CUL/CUNO?
Hier und dort liest man etwas von besonderen Timinganforderungen und Ähnlichem…
Sollte die Firmware nicht dafür Sorge tragen, dass ein gesendeter „Txx…“-Befehl zeitlich bzw. insgesamt korrekt abgesendet wird?
Kann man das Skript von Tommi für die FS20 Schalter tatsächlich als Vorbild verwenden?
Das Script als Vorbild zu nehmen war jetzt nur gemeint, um die formale Kommunikation mit dem CUN/CUL nachbilden zu können. Was zum FHT gesendet werden muss, ist natürlich in dem FS20-Schript nicht enthalten.
Das Problem bei den FHT-Ventilen ist (wenn ich das richtig verstanden habe), das diese aus Stromspar-Gründen auf der Empfangsseite in den Schlaf geschickt werden, wo sie nur zeitgesteuert erwachen. Man muss also den richtigen Zeitpunkt abpassen. Das Dumme ist nur, das der Algorithmus, wie er von den Raumreglern benutzt wird, nicht genau bekannt ist und bei den aktuellen Implementationen im wesentlichen nur aus Beobachtungen ermittelt wurde. Außerdem muss man die 1% Sendebegrenzung einhalten, darf also nicht einfach drauflos senden. Möglicherweise kann das die aktuelle CUL-Firmware auch schon, wenn nicht, muss man das nehmen was es gibt, in der CUL-fans Mailingliste nachfragen … oder selber die Firmware verbessern. Ein weites unbekanntes Land ruft hier nach neuen Erkenntnissen :rolleyes:
ich versuche es mit meinen bescheidenen Kenntnissen mal Step-by-Step.
In der Beschreibung steht folgendes:
Übertragung der FHT-ID auf Stellantriebe:
define your CUL FHT-ID (1234):
T011234 (check it with T01)
Der Anfang müsste dann doch so ausssehen (wenn ich unterstelle, dass die Daten so gesendet werden können und nicht noch irgendetwas „umgestellt“ werden muss):
hier mal meine ersten (wenn auch kleinen) Erfolge:
Vorlage waren die Skripte von Tommi:
Zuerst habe ich einen neuen FHT8v genommen, Batterien eingelegt und montiert. Nachdem nun „A3“ im Display erschien habe ich folgendes abgesendet:
Möglicherweise handelt es sich um ein CUNO-Problem? Zitat: „Es gibt Hinweise darauf, dass im Zusammenhang mit dem Einsatz eines CUNO anstelle eines CUL Timingprobleme eine korrekte Funktion der Firmware CUL_FHT8v verhindern: Pairing der FHT8v ist zwar möglich, jedoch kein Absetzen weiterer Kommandos. Firmware CUL_FHT8v ist ausdrücklich nur auf CUL getestet.“
"Sync consumes a lot of rf-time and it can be easily disturbed, so we try to reduce the „normal“ 2 minute (115+x) interval by remembering the last interval in higher level software, and schedule a sync with a smaller runtime at the correct time. Note: the argument must be odd, and it is measured in 0.5 seconds.
T1234002C21 (Sync for 0x21 == dec 33 == 15 seconds)"
Ich fürchte, Du bist mit dieser Anwendung der Pionier. Deshalb kommt auch so wenig Input. Am Besten auf der CUL-Liste nachfragen. Die Befehle kann man dann 1:1 im PHP-Script implementieren
in diesem Fall würde es mir (vielleicht) schon helfen, wenn mir jemand diesen Satz erklären würde…
"Sync consumes a lot of rf-time and it can be easily disturbed, so we try to reduce the „normal“ 2 minute (115+x) interval by remembering the last interval in higher level software, and schedule a sync with a smaller runtime at the correct time. Note: the argument must be odd, and it is measured in 0.5 seconds.
T1234002C21 (Sync for 0x21 == dec 33 == 15 seconds)"
Ich versuche ihn zu verstehen…
Was ist mit der „higher level software“ gemeint? Wäre das in diesem Fall IPS?
Was würde dieser Befehl „verstellen“?
Ich weiss es auch nicht.
Meine Interpretation: Die eigene Anwendung(in dem Fall IPS)soll sich das Syncinterval merken (nicht der CUL), um nicht einfach loszusende,sondern nur zur erwarteten Zeit. 33x0.5s sind bei mir aber schon 16s statt 15s. Der gezeigte Befehl würde dann nur 15s lang versuchen, zu den Sync-Vorgang abzuschliessen, um die 1%-Regel nicht zu verletzen. Aber wie gesagt, ist nur meine aktuelle Interpretation, kein Wissen… Besser nachfragen!
Mit CUL-Liste ist die CUL Group Mailingliste gemeint: https://groups.google.com/group/cul-fans?hl=de
Dort habe ich schon Fragen zum FHT8v gesehen. Einfach mal suchen und ggfls selber nochmal nachfragen.
ich habe Deinen Tipp in die Tat umgesetzt und mich in dem von Dir genannten Forum angemeldet.
In der Diskussionwurde under anderem darum gebeten, die Protokolle die ich mit dem Befehl „X61“ aktiviert habe im msec-Bereich aufzuzeichnen (nach dem Senden wurde auch für den von CUNO zu verstellenden Antrieb im Verzeichnisbaum eine neue Kategorie angelegt, so wie es auch für die vom FHT8i gesteuerten geschehen ist).
Hast Du oder jemand anderes einen Tipp wie ich das Protokoll mit IPS realisieren kann?
Für die Analysen würde ich den CUNO im IPSymcon erstmal deaktivieren und die Befehle direkt über USB (via COM-Port) oder Netzwerk an den Cuno schicken. Mit einem Terminalprogram wie putty geht das ganz gut. Dann sollst Du die Ausgaben vom CUNO zurückschicken. Also Connect an den CUNO, X61<enter> dann den Befehl wie in IPS (also T…<Enter>) und schauen was passiert.
Dirk hat ja auch schon geschrieben, er hätte Dir eine spezielle Version geschickt, die bei ihm funktioniert, weil in der alten Version wohl der IR-Empfang oder 1Wire das Timing störte.