Seit eing-igen Tage (und nach installation der laetzte updates) bekomme ich die % position von die FHT’s nicht mehr.
frage an paresy : wie soll das (debug) Protokoll aussehen fuer die Stelantriebs position? Möchte gerne selber nachsehen op die FHT’s die position uberhaupt durchgeben, bevor ich mich an euch richtte.
Hatte schon mal das problem … FHT’s raus aus dem IPS und neu anmelden. Dann hat’s geklappt. Habe jetzt keine Lust das nochmal zu tun ohne anderes versucht zu haben.
Problem bei mir ist das ich 3 umwalzpumpen (?syntax error?) und 1 kessel habe die 3 circuits mit warmes wasser vorsehen.
Per FHT’s mussen die umwalzpumpen und kessel angesteurt werden. Benutze also die stellantriebe % um dies zu bestimmen. Laufen die pumpen und sind die stelantriebe geschlossen bekomme ich einem wasserkurzschluss (jah echt!) und fangen die pumpen an unterdruck zu machen. Kurzer zeit sollen die dies uberstehen aber keine lange zeit.
(Da hat mir mein installateur etwas tolles gemacht huh ?? besser wäre ein uberdruck ventile rein ins circuit zu stecken so dass bei geschlossene ventile dass wasser uber derren bypass zuruck and die pumpen geliefert ware.) [ow waia mein deutsch] Geht besser nach 4 biere - herr damit !
meine Stellposition geht auch noch nicht wieder. Ich mache heute abend mal einen Reset vom FHZ1000PC (also vom USB Bus abstecken, mal sehen, ob das hilft.
Habe doch die bitte das FHT protokol zu erklären … ist mir einfach zu wichtig. Heizung lauft d’rauf/
Oder kann ich es irgendwo finden ? Ich möchte gans gerne das protokol durchblikken.
Bin eigentlich ein IT-er die low level Netzwerke aus hobby anlegt. also wirklich auf TCP protokoll stresst. Deshalbe bin ich faziniert von das FS20 protokoll.
oh prima, da warte ich, bis Du fertig bist, bevor ich das bei mir mache. Da kann ich in der Zwischenzeit meine Strom-Mess-Station aufbauen, wollte ja noch den Strom beim 0% Dimmung messen.
also bei mir hat das USB abstoepseln, ausschalten des Rechners und vom Netz trennen alles nichts geholfen. Einzig und allein das Entfernen der Batterien im FHT hat geholfen, jetzt geht wieder alles.
Hmm…wenn ich mir diese Dinge alle so über die Zeit betrachte sollte man mal mit einer kelinen Datenbank anfagen in der die typischen Fehler und die möglichen Lösungswege aufgezeigt werden.
Beispiel:
Problem:
PIRI - sendet immer wieder „true“ obwohl keine Bewegung im Umfeld stattfindet.
möglicher Fehler:
Accus, bzw. Batterien mit ungenügend hoher Spannung
Lösung:
Batterien durch „hochwertige“ Alkali-Batterien ersetzen (z.B. Typ XXXX)
halt irgendwie so in der Art - dann muss man nicht immer die Forumsbeiträge durchforsten,
HFT lauft jetzt noch immer nach dem neustart diesem morgen 0u…
Gebe es eine möglichkeit das (between) FHZ & IPS ein buffer sitzt die „uberlauft“?
USB ab und anschalten; IPS neustart; hat mir diesmal geholfen; aber sitze hier noch mit Fragezeichen.
Ich mache mir mal ein debug-programm die - jedesmal dass HFT sendet diesem wert gemerkt wird und parrallel daran einem variablen geset wird.
Nach 6 min wird die parrallele gereset. Indem die parrallelle (oei) nach zb. 1 std kein update bekommen hat mache ich mir ein alarm.
Wie konnte man das hin bekommen … das stresse ich heute abend mal auf.
Am liebsten 1 script die alles in sich hat. Mal gucken! Komme hierauf zuruck :rolleyes:
Bleibe probleme haben …
Kann ich dir noch iregendwie info’s geben zur lösung des problems?
Heute verplichtet FHT instanz zu löschen und neu an zu legen.
Möchte das debug programm schreiben (thema: wenn keine % in zb 30 minuten dann alarm) aber sehe keine %-triggers erscheinen, also kann ich meine last_sent wert nicht setzen… und darum immer alarm -> macht sinn;¨
hätte es gerne anders gesehen.
Wie war die artikelnummer von das ELV FS20 protokoll analyser?
Die FHZ sendet keine % satzen wenn keine stellantriebe geöffnet sind
Sweeet !
Lasst mich mal das ganze protokolieren.
Komme hier morgen auf zuruck.
— 20h50 : edit
Hat jemanden die beschreibung van das FHT protokol ?
Ich guck jetzt schon eine stunde auf das FHT debug fenster aber komme nicht raus
— ende edit
