IPS verliert Kontakt zu FHT

Nee, und alle FHT’s sind empfangsmässig mit 3 FHZ’s verbunden. Alle Ventilpositionen kommen regelmässig rein, nur die Temperaturen nicht. Das kann dann nicht an Funkstörungen liegen. Ich hatte das Skript mal probiert, und hat nichts gebracht. Manchaml senden FHT’s keine Werte für 12 Stunden, und dann auf einmal senden sie wieder.
Weiss der Geier, warum das so ist !

mfG Franz

Nun pedocom scheints auch „erstmal“ etwas zubringen, nur bei euch dachte ich mir schon, dass das eventuell nicht zum „Workaround“ führen wird, nachdem ich mir die anderen Diskussionen durchgelesen habe.

Seltsam ist das jedenfalls!

In welchem Mode betreibt Ihr Eure FHTs?

Meine laufen im manuellen Mode. Und die Temperaturen kommen alle paar Minuten, außer es gab keine Änderung.

Immer im AUTO Mode.

AUTO heisst bei mir: Steuerung durch IPS
MANU eben per Stellrad

mfG Franz

Und was steht auf das display am FHT? Da hat eben auto und manu etwas andere bedeutung. Auto am FHT nimmt die interne programmierung (max. 2 schaltschwelle (niedrig / hoch) am tag.) NUR in manu-betrieb am FHT kann man FHT_SetTemp(xxx,soll-wert) setzen, ansonnsten keinem einfluss.

Ich weiss, ich habe im AUTO betrieb auch gar keine Tabellen eingegeben, deshalb ist es für den FHT egal. Lediglich den Status AUTO/MANU interessiert mich für IPS.

mfG Franz

Und was steht auf das display am FHT

Und was steht nun im Display? :confused:

AUTO :confused:

mfG Franz

Das halte ich aber für ein dickes Gerücht. Genau so wie du im Auto-Modus am Rad drehen kannst, kannst du per IPS die Temperatur ändern. Beim nächsten programmierten Schaltzeitpunkt schaltet natürlich wieder auf niedrig bzw. hoch.

Seit wann ist das so ? Ich mach das seit Beginn. Alle meine FHT’s stehen auf AUTO und ich steuere wunderbar meine FHTs’ per IPS. Wenn ich das nicht will, schalte ich einen Regler einfach auf Manuell

mfG Franz

Was ist wenn IPS einem neuem befehl gibt im FHT MANU-betrieb? Bitte sehr? Wenn ich euch glauben möchte gehen die befehle nicht durch ? komm !

Ja, im Prinzip ist es dem FHT egal, ob er einen Befehl erhält, ob er in Manuell ist, oder Automatik.
Nur habe ich alle meine Skripte so aufgebaut, dass wenn der FHT per IPS oder per HAND auf MANU gesetzt wird, keine Set_Temp’s von IPS aus mehr gesendet werden.

mfG Franz

Nur habe ich alle meine Skripte so aufgebaut, dass wenn der FHT per IPS oder per HAND auf MANU gesetzt wird, keine Set_Temp’s von IPS aus mehr gesendet werden.

AHA. Jetz ich verstehen Deine Vorgehensweise…
Deine Programmtabelle im FHT ist also leer.

Als Backup besitzen meine FHTs normale Wochentabellen. Zum Betrieb mit IPS setze ich sie in manual-mode.

Für den „echten“ manuellen Mode habe ich das Script von Fredje etwas modifiziert:
Ich sende nur dann Daten an einen FHT, wenn die eingestellte state-Temp (nicht state-request) von der Vorgabe abweicht. Damit übersteuere ich aber manuelle Änderungen. Daher habe ich eine Lock-Tabelle angelegt. Ändert man die Temp am FHT manuell, wird ein Lock-Bit gesetzt. Erst nach einer gewissen Zeit (bei mir 90min) wird der FHT wieder von IPS gesteuert. Oder die von Hand eingestellte Temperatur entspricht genau der Vorgabe, auch dann wird das Lock zurückgesetzt.
Bsp. Ich stelle die Temp vor der eigentlichen Schaltzeit auf 21°C. Innerhalb der Locktime wird die Vorgabetemp. ebenfalls auf 21°C gesetzt. IPS läuft jetz wieder „synchron“. Daher wird der Lockzustand zurückgesetzt. :smiley:

Das hat aus meiner Sicht zwei Vorteile:

  1. Eine von Hand eingestellte Temp wird nicht gleich bei der nächsten Vorgabeänderung zurückgestellt.
  2. Dreht man in den Heizpausen oder spät abends nochmal am Rad :rolleyes: , wird die eventuell vergessene Einstellung nicht die ganze Zeit (oder Nacht) beibehalten, sodass nicht unbeabsichtigt durchgeheizt wird. Zwischen 23 und 07 Uhr wird die Locktime außerdem halbiert.

Fabian

aus dem Grund mochte ich Fredje’s Skripte nicht. Ich ging einen einfachen Weg:

Voraussetzung:
Die Wochentabelle des FHT muss natürlich leer sein

Jeder FHT hat bei mir ein eigenes Skript. Richtig ist zwar, dass es nur ein Skript ist, ein Modul, das jeweils nur mit den Raum-spezifischen Variablen durchlaufen wird. Ist jedoch der FHT auf Manuell oder ein Fenster offen, wird das Skript mit diesen Raum-Variablen nicht durchlaufen, somit bleibt die letzte eingestellte Temperatur stehen. Danach kann man am Stellrad soviel drehen wie man will. Der FHT wird erst wieder von IPS berücksichtigt, wenn ich den FHT wieder auf AUTO setze.
Das war meiner Meinung nach die bessere Variante. Ausserdem habe ich den Skripts Überwachungen, falls mal ein neuer TargetWert nicht nach x Minuten am FHT angekommen ist, wird eine Meldung generiert und der Wert wird neu gesendet.

mfG Franz

Mann habe ich mich etwas aufgeregt … aber jetzt ist klarheit total :slight_smile:

@Fabian : Gute lösung fur dein fall : meine aussonderungen sind meistens so das ich daheim bin wenn normal niemanden daheim ist. Also den ganzen nachmittag durchheizen ist schon ok. Abends um 23h nochmals drehen wird ‚gereset‘ durch mein schlafen-gehen script.

Jeden macht es wie er möchte -> nur sind wir ein wenig off-topic geraten glaube ich.

Back to topic:
gibt es noch den bug ?

gibt es noch den bug ?
Es scheint noch einen zu geben. Nur wo?

Erst heute bin ich wieder einem Fehler der letzten Tage auf die Spur gekommen:
Einer der FHTs macht seit ein paar Tagen Probleme. Erstmal dauern state-requests sehr lange (auch wenn die pos stetig reinkommt). Dann fallen die pos-Meldungen einfach mal für ein paar Stunden weg.

Nunja, Batterien raus und rein, neu anmelden… Ihr kennt das ja.
Dennoch bleiben die Probleme bestehen. :frowning:

Also habe ich mein FHT-Logging wieder angeworfen.
Erste Auffälligkeit:
Es kommen in der gleichen Zeit (habe mehrere Referenzlogs geprüft) nur rund die Hälfte der Daten rein. Von einigen nur pos-Meldungen. Außerden ist mir aufgefallen, dass bei fast allen die requests langsamer durchgehen als sonst.

Zweite Auffälligkeit:
Wenn die pos-Meldungen bei meinem „Problemkind“ nicht kommen, sind auch keine im Log. => Pluspunkt für IPS!
ABER: mein fehlender FHT sendet laut Log Daten. :eek: Und zwar mehrfach eine Sequenz mit der Funktionskennung 7d. :eek: Die gibt es aber gar nicht - und auch nicht in allen anderen Logs.

Neustart IPS - nix
Neustart IPS mit aus- einstecken der FHZ- nix
Neustart OS - nix
Herunterfahren des Rechners mit Power off und Neustart - Problem behoben!

Scheint so als hätte die USB-Schnittstelle ein Problem gehabt???

Ohne Log hätte ich nie erkannt, dass es ein echter Fehler ist. Da immer nur ein FHT auffällig war…

Als 0X7D ? in hex ? -> dec. 125 ??
Doch gibt es : anfang ‚block‘

Mal einfach nur so zum Denkanstoss:

Wie wäre es mal zur Abwechslung, wenn wir Bugs auf seiten von den FHT’s suchen würden. Villeicht hat ELV auch einfach nur Mist gebaut !

Ich hatte letzte Nacht wieder ein FHT, bei dem keine Temperaturen reinkamen, und ein anderer, der verweigert hat, VPos zu schicken, obwohl 3(!) FHZ’s lauschen.

mfG Franz

Hallo Fredje,

Interessant!
Kannst Du mir weitere Quellen nennen, wo ich sowas nachsehen kann. (PM?) Ich kenne bis jetzt nur die Linux-Seite fhz4li…

Leider konnte ich in meinen anderen Logs bisher nichts vergleichbares finden. Daher dachte ich an einen Fehler… :o

Tja, und wie erklärst du dann, dass ich manchmal den gleichen Fehler habe, ich meine FHZ’s aber per Client Socket anspreche, also nix USB !?

mfG Franz