den Raumregler FHT kann man ja auch direkt am Gerät programmieren. Z.B. Absenktemperatur, Komforttemperatur, Absenkzeiten, Wochenprogramm, Urlaub, etc…
Diese Angaben senden die Raumregler FHTs auch an die FHZ. Die Codes des FHZ-Kommunikation sind hier beschrieben: FHZ 1000 for Linux : FHZ1000 Protocol
In der Doku der FHZ1000PC.DLL (Version vom 14.07.05, S. 14ff.) ist ebenfalls beschrieben, welche Daten der FHT and die FHZ übermittelt werden.
Könnte man diese Infos nicht auch in IPSYMCON zur Verfügung stellen?
So in der Art FHT_GetComfortTemp(FHT_ID), FHT_GetMode(FHT_ID), etc.
Erstens einmal, warum sollte es diese Funktion überhaupt geben? IPS kann das 10x besser und effektiver.
Zweitens geht das sehr schlecht bis gar nicht ! Ich hatte auch am anfang die CONTR**CS Software und mit der hat es schon nicht geklappt.
Probier mal bei 11 FHT’s (wie bei mir) jedem ein Wochenprogramm zu senden, und du wirst sehen, wieviel davon im Buffer Timeout landet. (1% Directive)
Auch mit der C Software musste ich manchmal Stunden (!) warten, bis mal 1 komplettes Wochenprogram durch war.
Wohlgemerkt: Ein Datenpaket ist nicht gleich ein ganzes Wochenprogramm, sondern das wird in mehreren Paketen geschickt.
Sowieso hat IPS die ganzen Protokolle zum Datenverkehr FHZ <> FHT.
Das einige Problem, was noch gelöst werden sollte ist das synchronisieren der Zeiten in den FHT’s mit der Zeit in der FHZ. Das hat IPS noch nicht im Griff ! Doch da tut sich im Moment leider nichts. :mad:
Diese Angaben senden die Raumregler FHTs auch an die FHZ.
Das ist falsch. Die FHZ sendet das an den FHT und nicht umgekehrt. Vom FHT aus wird nur Ventilposition, Batteriestatus (vom FHT), Fensterstatus, Istwert-Temp und Targetemp (und auch nur, wenn am Rad gedreht wurde, und das nur einmal) wurde.
das ist ein Missverständnis. Ich will nicht Wochenprogramme oder sonst was an die FHTs senden. Sondern einfach Informationen nutzen, die eh schon von den FHTs zur Verfügung gestellt werden. Die FHTs senden diese Infos bereits an die FHZ. Was spricht dagegen diese Infos zu nutzen?
Ich hatte das mal ausprobiert und mitgehört was bei der FHZ reinkommt.
Z.B. per USBSniffer oder per USB->ComDriver und dann per serieller Kommunikation. Das sieht dann z.B. so aus:
01:24:41,004 INFO FHZProtocolDescriptor:105 - protocol data: 81 0c 04 bf 09 09 a0 01 43 23 1c 00 69 21
Decodiert bedeutet das, dass an dem FHT die Starttemperatur (Wed from 1) auf 16.5 Grad steht (eingegeben wurde).
Solche Werte kommen alle schon an der FHZ an, man muss sie nur decodieren und könnte sie dann in IPS nutzen. Beim Decodieren kann ich helfen, ich habe das mal mit einem Java-Programm gemacht. O.K. die Werte kommen in unregelmässigen Zeitabständen, aber sie kommen.
Warum braucht man das? Ich gehöre leider nicht zu denjenigen bei denen die Kombination Windows->IPSYMCON->Queue->FHZ1000->FHT stabil läuft. Nachdem diese Kombi sich wiedereinmal verabschiedet hat und das Haus 4 Tage in Abwesenheit durchgeheizt wurde, laufen die FHTs jetzt wieder im Automatik-Modus und IPS greift regelnd ein. Deshalb wäre es schön, wenn man in IPS erfahren könnte, auf was die FHTs programmiert wurden. Diese Info geht ja bereits über das Funknetz, sie zur Verfügung zu stellen wäre also nur ein „Abfallprodukt“. Was spricht dagegen?
Das ist auch O.K., wenn die Regelung absolut verlässlich ist. Bei der Gesamtkette HW, Windows, IPS, Queue, FHT ist das zumindest bei mir nicht der Fall. Befehle in die Queue abzusetzen ist eine Zitterpartie (z.B. Zeitsynchronisation). Auch bleibt immer mal wieder das System stehen. Andere im Forum scheinen diese Effekte auch zu kennen. Da ich viel unterwegs bin, muss ich mich auf das was zu Hause autonom passiert verlassen können. Deshalb stehen die FHTs auf Automatik-Mode. Das ist quasi mein Notfall-Programm. Die FHTs sind führend. Um dann per IPS regelnd eingreifen zu können, wäre es hilfreich deren intern programmierte Werte zu erfahren. Gut, der Ansatz ist ein bischen anderst, aber zumindest fail-safe.
Tut mir leid wenn ich dann was misinterpretiert habe. Nur, es gab mal einen Befehl, der irgendwie FHT_Request (o.ä) lautete, doch der baute ziemlich Mist, sodass bei verschiedenen sich sogar FHT’s aufhängten !
Nur, wie schon erwähnt, brauch man diese diese Infos wirklich?
Du hast recht, ich weis wie es ist, wenn du jeden Morgen aufwachst, und IPS sich mal wieder aufgehängt hat.
Gott sei dank läuft IPS bei mir nun stabil und seit 3 Monaten keinen einzelnen Eingriff nötig, ausser mal WLAN aussetzer !
am Stellrad der FHT wird manuell eine andere Temp eingegeben
ein Skript wird getriggert und der Mode für 2 Stunden auf manuell gesetzt, damit die Automatik den eingestellten Wert nicht überschreibt (Idee ist von Retiarius)
nach Ablauf der zwei Stunden wird der Mode per Skripttimer wieder auf Automatik gesetzt
jetzt müsste auch noch die aktuelle Automatik-Temperatur (Comfort / Nacht) wieder an die FHT mitgegeben werden, sonst bullert die Heizung bis zum nächsten Automatikschaltvorgang mit dem vorher manuell eingestellten Wert weiter.
Bei mir sind die FHTs führend, weil die verlässlich arbeiten. Hätte ich jetzt in IPS die Infos über das in der FHT programmierte Wochenprogramm und dessen Comfort- und Nachtemperatur, könnte ich an der Stelle jetzt einfach den zu der Automatiksequenz gehörenden Temperaturbefehl mitgeben und voila …
Davon bin ich leider noch ein ganzes Stück entfernt. Und wenn es läuft, dann sag ich auch „Gott sei dank“ …
Dadurch dass ich im Automatik-Modus der FHTs arbeite hat es keine fatalen Auswirkungen, wenn sich der Rechner aufhängt.
Das musste ich sofort ausprobieren. Es macht ja Sinn, wenn ich per JAVA-COM über FTDI an die Werte herankam, müssten Sie auch in IPS als einkommender Datenstream zu bekommen sein. Ich habe dir mal ein Screenshot angehängt. Wie Du siehst kommen da irgendein Binärstream rein. Vielleicht hast Du noch eine Idee, wie ich die einkommenden Daten interpretieren/decodieren könnte.
Du musst ein Script auf die Variable Triggern, dort die ganze Sache in die einzelnen Pakete teilen (Ich glaube das Trennzeichen war 0x129) und dann noch ein wenig die Bytes nach Protokoll auslesen.
Du kannst natürlich auch das ips_debug Tool nehmen… Das zeigt die Messages auch in HEX an, wenn man Sie per Doppelklick auswählt.
herzlichen Dank für die schnelle Hilfe. Der vorgeschlagene Weg hilft mir weiter. Ich habe mir das Ganze jetzt mal im Debugger angeschaut und „alte Bekannte“ wiedergefunden. Ich denke, dass ich von hier aus weiterkomme.
