Die Bricks sind total neu überarbeitet und ein wenig optimiert worden.
Neuheiten:
[ul]
[li]auf manuelle Installation hin optimiert
[/li][li]zusätzliche Methoden
[/li][li]Sonderfunktionen im eFHT Brick (Autoinitialisierung der FHT, Erkennung ob entkalkt, synchronisiert oder getestet wird)
[/li][li]„sFHZ“ Methoden auch ohne eFHT Brick nutzbar
[/li][/ul]
Genauere Dokumentationen sind wie immer in den Anleitungen vorhanden.
Eventuell sind Anpassungen in euren Skript dadurch nötig geworden.
Stimmt das im Pfad mit bricks\eFHT noch. In deinen neuen Dateien befindet sich im Brick keinen recv.eFHZ.php mehr, die ist nur noch im Brick-Verzeichnis eFHZ.
Wieder mal ein Update: siehe Thread FHT80 - Schaltjahr - falscher Tag Geänderte Dateien:[ul]
[li]class.eFHZ.php
[/li][li]class.eFHT.php ---------------> beide sind einfach nur auszutauschen.
[/li][/ul] Betroffene Methoden:[ul]
[li]sFHZ_SetDateAndTime
[/li][li]sFHT_SetDateAndTime
[/li][li]bFHT_SetMode ---------------> bei allen drei wurde ein neuer Parameter (LEAP=false -> Voreinstellung) eingefügt.
[/li][/ul]
Bei LEAP=true (nur bei FHTs mit Schaltjahrproblemen anzuwenden) wird das Jahr zwischen dem 1.März und 31.Dezember auf 6 Jahre vorverlegt. (z.B: 2008 wird 2014). Bei allen anderen Methoden mit UNIX Timestamp Übergaben kann die aktuelle PC Zeit verwendet werden. Dies betrifft z.B. das Wochenprogramm wo nur der Wochentag berechnet wird. Also keine Unterschiede zwischen den alten und neuen FHTs.
Die allgemeine Gültigkeit des UNIX Timestamp -
Hinweis: Der gültige Bereich eines Timestamp liegt typischerweise zwischen Fri, 13 Dec 1901 20:45:54 GMT und Tue, 19 Jan 2038 03:14:07 GMT. (Das entspricht den minimalen und maximalen Werten für einen vorzeichenbehafteten 32-Bit Integer). Unter Windows-Betriebssytemen ist dieser Bereich auf 01-01-1970 bis 19-01-2038 beschränkt.
bleibt davon unberührt. Näheres ist in den Anleitungen zu finden.
Das Emulieren eines FHT 80 TF (z.B. für Verwendung mit HOPPE Griffen) ist mit einer FHZ1x00PC leider nicht möglich.
Ich kann das Protokoll nicht einmal empfangen und deswegen auch nicht emulieren.
[li]für Bastelfreunde (z.B: funkbasierend) : mittels einem (mehrere) FHT 80 TF und diese dann hardwaremäßig (z.B: mit einem FS20 Schalter der an der Schraubklemme KL1 angeschlossen werden)
[/li] Gedachtes Szenario: HOPPE – (Funk) --> FHZ --(Funk)–> FS20 Schalter --(Kabel)–> FHT 80 TF --(Funk)–> FHT80b
@alle und spez. alle Kabelenthusiasten (z.B: 1-wire):
Verzeiht mir diese Ausführungen, das ist sicherlich keine besonders gute Lösung.
Ich würde sie auch keinem empfehlen, sollte nur eine kleine Anregung sein, falls jemand HOPPE & FHT (beide Funk) verwendet möchte.
Das eFS20-Brick ist eine Erweiterung zum eFHZ-Brick. Falls das Brick jemand einsetzen möchte muss beide Brick installieren.
Das eFHZ-Brick wurde nicht verändert und kann deswegen (wenn schon im Gebrauch) einfach weiter verwendet werden.
Die Methoden beeinflussen die FS20 Aktoren direkt, d.h. es werden keine PHP-Tricks angewendet. Einzige Ausnahme: Die Sonderfunktion „TimeVarReset“ (wenn true) setzt die IPS Statusvariablen auf den Ausgangswert zurück, wenn irgendeine Timerlaufzeit bei den Methoden angegeben wurde.
Mögliche Anwendungen:
[ul]
[li]togglen von Aktoren
[/li][li]Setzen der internen Timer (von Aktoren)
[/li][li]relative Dimmung (= ausgehend vom aktuellen vorhandenen Helligkeitswert im Aktor)
[/li][/ul] Anmerkung:
Auch bei Benutzung der „TimeVarReset“ gilt, die eFS20 bieten „keine“ bidirektionalen Funktionen, die IPS Statusvariablen müssen mit den aktuellen Statuswerten der Aktoren nicht im Zusammenhang stehen.
Das eFS20 Brick wurde im ersten Beitrag hinzugefügt.
Viel Erfolg!
hallo Spawn, habe kleines (großes) problem. habe die neuen bricks installiert
und in meinem ipsymcon um einen raum (fht) erwitert. eFHT_Wohnz( das alte)
funktioniert wie immer, das neue eFHT_Bad geht nicht. es kommt immer die fehlermeldung zb. beim senden Wochenprogramm
<b>Notice</b>: Undefined index: LOCATION in <b>C:\Program Files\IP-SYMCON\bricks\eFHT\class.eFHT.php</b> on line <b>256 hoffe das du mir helfen kannst.
muss mich korrigieren, wenn ich an eFHT_wohnz sende, habe ich zwar bkeine fehlermeldung. aber an der fht ändert sich auch nichts mehr.
Zu Fehler 1: (dein eFHT_Bad)
Ja das ist leider ein kleiner „Bug“.
Er kommt immer dann vor, wenn in IPS kein Name für das FHT angegeben wurde.
unter Instances -> Treeview -> Device Name
EDIT:
Kann gar nicht vorkommen: Da IPS die Instanznummer als Device-Nummer vergibt.
Deine Settings würden mir vielleicht helfen, bitte, danke.EDIT-ENDE
( -> wird korrigiert, dauert aber noch ein bißchen, habe nämlich noch Arbeit an meiner Wärmepumpe)
Zu Fehler 2: (dein eFHT_Wohnz)
Es könnte hier auch derselbe Fehler w.o zutreffen.
Kommen die Status- / Temperaturmeldungen des FHT im eFHT-Brick an? (= am einfachsten zu kontrollieren wenn du die Komfort-/Absenk- und Fenstertemperatur an dem FHT änderst)
Grundlegend kann ich sagen wenn die IPS eigenen FHT Befehle funktionieren gilt das auch für die eFHT Methoden.
Wenn nicht: ist es ein „Bug“ oder die Settings.xml ist der Auslöser.
Wenn du möchtest, kannst du mir deine Settings.xml per PN oder Mail schicken.
Deine Settings sind in Ordnung, was ich so gesehen habe.
Wenn die gesendete Temperatur übernommen wird, funktioniert das Senden.
Zum Wochenprogramm:
Hier werden nur die Zeitdaten und keine Temperaturen gesendet.
Kontrolliere das Wochenprogramm am FHT obs funktioniert hat.
eine Eigenart Wochenprogramm am FHT:
Wenn das Wochenprogramm an FHT’s übertragen wird, ist das für die FHT’s leider kein Grund die betreffende Temperatur (Komfort,Absenk- oder Fenstertemperatur) zu übernehmen.
Auch wenn der eigentliche Zeitpunkt schon eingetroffen oder übschritten wurde. Das geschieht nur wenn der Zeitpunkt im FHT eingetroffen ist.
(= vielleicht mit einer Flankensteuerung zu vergleichen)
Test: Verlege die VON-/BIS ZEIT der Komfortemperatur mit Sicherheitsabstand in die „Zukunft“ damit das FHT Zeit hat das Wochenprogramm zu übernehmen und warte bis die „Flanke“ im FHT getriggert wurde.
Danke, also wie gesagt als ich dem kind unter instance einen namen gab, war die unten genannte fehlermeldung nicht mehr vorhanden.
nach nochmaliges senden des wochenprogramms, funktionierte auch das.
SUPER Arbeit @Spawn. einen kleinen wunsch hätte ich noch(wer hat die nicht)wenn beim erstellen der bricks, sich die vars selber erstellen würden.(habe noch 5 FHT`s)
ps. den wagen habe ich nicht mehr, nach 3mal reichts. habe jetzt einen 335i
@all:
Ich habe dazu noch kein „plausibles“ Konzept.
[ul]
[li]Überprüfung schon vorhandener Variablennamen
[/li][li]Namen mit Zufallsgenerator erstellen
[/li][li]Präfixangaben zu Variablennamen[/ul]
[/li]Wer Vorschläge dazu hat, sollte es hier posten.
Hier ist eine einfache Routine die nicht nur alle eFHT-Brickvariablen anlegt sondern gleich das ganze Brickskript.
Die zuvor erstellten IPS-Variablen werden hier auch automatisch im Brickskript eingetragen.
Sollte eine der beiden Skriptdateien schon existieren wird die Ausführung abgebrochen.
Beispiel für Variablennamen:
Präfix: WOHNZ
eFHT PartyTime IPS Statusvar: WOHNZ_eFHT_IPS_PtyT
Bugfix:
Bei bFHT_SetMode hat sich ein Bug eingeschlichen.
Betroffen waren unter Umständen die FHT’s mit der alten Firmware und dem Schaltjahrproblem.
Neu:
Weitere vFHT_ Variablenmethoden zur Abfrage von aktuellen Werten:
[ul]
[li]Position
[/li][li]Temperatur
[/li][/ul]und Sollwerten am FHT.
[ul]
[li]Temperatur
[/li][li]Modus
[/li][li]Komforttemperatureinstellung
[/li][li]Absenktemperatur
[/li][li]Fenstertemperatur[/ul]
[/li]Grund: Bei Verwendung eines Skriptes für mehrere FHT’s kann mit diesen Methoden die Statusvariablen ohne Anpassungen einfach ausgelesen werden.
Man will es ja auch ein bißchen bequem haben!
Durchführung:
Die Datei class.eFHT.php ist einfach nur auszutauschen.
Die beiliegende Anleitung wurde ebenfalls angepasst.
: