da ich mich ja weitgehend mit FHT’s beschäftige, ist mir folgender Gedanke gekommen:
Wenn ein FHT_SetTemperature zu einem FHT gesendet wird, d.h. eine neue Target Value, würde es nicht vieles vereinfachen um festzustellen, dass der Befehl ankam am FHT, die TargetValue erst upgedated wird auf den neuen Wert, falls die FHZ ein OK gibt, dass der Wert auch wirklich durch ist? Solange wäre die neue Target Value pending. Naja, hier weiss ich noch nicht so richtig wie man das anzeigen könnte??
jo, stimme dir da prinzipiell zu. dann kann man sich die skripte sparen, die umständlich den temperaturverlauf 15-30 minuten nach sendebefehl auswerten.
Nicht nur das. Mit 11 FHT’s stosse ich an die Grenzen. Mit dem FHZ Buffer stimmt weiterhin was nicht. Ich habe einen Ablauf in mein Projekt eingebaut, das bei Tastendruck nach und nach (mit 2 Minuten Intervallen, habe jedoch auch schon mit 5 Minuten versucht) alle FHT’s zuerst auf manuell schaltet, dann eine festgelegte Absenktemperatur nachschickt. Das sind bei 11 FHT’s 22 Befehle. Das kann ich ehrlich vergessen. So ungefähr 10 Meldungen gehen durch. Solange ich nicht mehr als 2 Befehle im Buffer haben, geht es noch, aber ab dem dritten und vierten ist dann Sendepause, und nix geht mehr. Dann schaltet meine FHZ auf stur, bis alle Befehle nach 1 Stunde in TimeOuts kläglich verenden. Da gibt es meiner Meinung noch viel zu verbesseren im FHZ Modul.
Oder zumindest wäre es ja mal hilfreich, mit in das Kernel die Fehlermeldungen zu übernehmen, die durch Timeouts in der FHZ verursacht werden. Dann könnte man die abfragen und darauf eben reagieren, eventuel noch mal einen Befehl nachschicken.
Auch frage ich mich, ob man der FHZ nicht einen Reset-Befehl schicken kann, wenn der Buffer leer ist? Die WLAN Variante kann es software mässig. Das habe ich gesehen.