Bugfix an den Statusvariablen wurde behoben. Der Download im ersten Beitrag dieses Themas wurde angepasst.
Betroffene Dateien sind einfach nur auszutauschen:[ul]
[li]class.eFHT.php
[/li][li]recv.eFHZ.php beide aus dem eFHT - Brick
[/li][/ul] WLAN-FHZ:
lt. paresy (Posting zuvor) müsste es mit dem ServerSocket ähnlich wie mit dem FTDI Modul funktionieren. Einfach ein RegisterVariable Modul beidseitig verbinden. @Franz: wenn du es einmal ausprobieren möchtest, ich wäre interessiert was passiert. Ich weiß nur noch nicht wie ich es testen soll.
Das Skript eFHZ_calc wird im SkriptEditor jedesmal als Brick (grün) angelegt. Lösche ich es in erstelle ich es neu ist es bis zum schliessen als Skript sichtbar (immer noch grün siehe Grafik 4), öffne ich es anschließend ist es wieder ein Brick.
Wenn ein nicht gewollter grüner Eintrag (IPS-Brick) vorhanden ist, ist im Script Ordner im IP-SYMCON Verzeichnis eine gleichnahmige *.ips.brx Datei vorhanden.
Das kennzeichnet ein IPS Brick.
z.B:
[ul]
[li]eFHZ_calc.ips.php
[/li][li]eFHZ_calc.ips.brx
[/li][/ul]
Einfach nur die *.brx Datei löschen, wenn der Code selbst in Ordnung ist.
Mit der Methode: [b]sFHT_GetTargetWPTemp/b; kannst du schon mal aus der Tabelle auslesen. Wenn du aber die ganze Tabelle in Klarschrift (encoded) verarbeiten willst, kann ich mir auch etwas dazu überlegen.
Eher tageweise oder die ganze Woche oder kombinierbar?
du hast klasse Arbeit geleistet, alle Achtung. Nur glaub ich mittlerweile zu blöd zu sein um das noch installiert zu bekommen, geschweige denn ans laufen zu kriegen. Ich bin schon froh mir ein Basiswissen in PHP angeeignet zu haben. Aber Wörter wie ‚Klasse‘ oder ‚XML-Parser‘ sind für mich Fremdwörter.
Das Problem mit dem Auslesen einer Wochentabelle als auch mit dem Übertragen einer Wochentabelle ist, du kriegst sie nicht komplett auf einen Schlag. Ich kann mit erinnern, als ich noch die C* Software hatte, die Tabelle eines FHT war ja noch ok zu übermitteln, aber dann gleich 11 in meinem Fall ist quasi eine Sache von 24h mindestens, bis alles gesendet wurde, sogar verteilt auf 3 FHZ’s.
Wenn also ein Feiertag im Anmarsch ist, und du die Wochentabellen eintragen musst, kann das fast eine Sache der Unmöglichkeit sein.
Wenn man die tabelle nun in einem Schlag bekommen hätte, dann wäre das Beste gewesen, sie in einem Array zu speichern und dann an String-Variable weitergeben.
Wochenweise in ein Array wäre schon eine gute Sache, da könnte man sich den entsprechenden Tag auslesen.
Wie guyabano oben beschreibt kann das eine Menge an Daten sein die evtl. die Vorschriften des Funkprotokolls sprengen könnten wenn man zuviele FHTs auf einmal ausliest.
Falls das ein Problem darstellt wäre ich auch mit einem Tag zufrieden.
Nun ja, das habe ich schon so gemacht (Stichwort: serialize/unserialize). Und du hast Recht mit dem Wochenprogramm. Ich habe auch Probleme mit dem Empfang und der Auswertung.
Tipps für User mit der Verwendung des FHT Wochenprogrammes:
Falls das vollständige Wochenprogramm empfangen wird (= Änderung direkt am FHT) kann es vorkommen dass nicht das Ganze ankommt bzw. fehlerhaft ankommt. Derzeit kommen bei mir die Daten für Mo,Di,Mi,Do und manchmal für Fr ohne Fehler. Mit der Methode bFHT_RclWeekProgram kann das Wochenprogramm für einzelne Wochentage angefordert werden. Hiermit könnt’ ihr mittels TimeWizard diese Tage anfordern.
Zum Beispiel am Mo für Di, am Di für Mi, etc. Bedenkt aber dabei auch, nicht an allen FHT’s direkt hintereinander Anforderungen abzuschicken -> gleiches Problem und zusätzlich FHZ Pufferüberlauf.
Der Grund, wie schon erwähnt, ist in den FHT’s und der FHZ zu suchen.
Franz, falls du dich hiermit auch auf den vorigen Beitrag von wgreipl beziehst, hier geht es nur um eine komfortablere Methode für die Verwendung in seinen Skripts. Das kann erledigt werden.
Einarbeitung der Methode sFHT_DecodeWP($Day,$Target) für eine dekodierte Ausgabe der Wochenprogramme. Zurückgegeben wird ein 2-dimensionales Array.
Dies ist eine quasi „Offline“-Funktion. Sie bedient sich nur der schon vorhandenen Statusvariablen, es erfolgt somit keine Kommunikation mit den FHT.
Zu tauschende Datei: class.eFHT.php aus dem eFHT - Brick.
Der Download im ersten Beitrag wurde zusammen mit der Anleitung wieder erneuert.
Mehr eine philosophische Anmerkung zur OOP-Nutzung:
Du definierst alle Functionen/Variablen als statisch. Das kommt sicher vom java-programmieren. Das macht m.M. nach nicht so viel Sinn. In PHP braucht man es eigentlich nicht so, da statische Dinge immer Overhead bedeuten.Ich mache es eigentlich nur, wenn ich ein Singleton-Object brauche (z.B. Eine DB-Connection) und diese dann in allen Instancen verwenden will. Die abgeleiteten Objekte holen sich das Object über eine statische getInstance methode und erzeugen es sich selbst, wenn es noch nicht da ist.
public static function getInstance()
{
if (!isset(self::$instance)) {
self::$instance = new xyz();
}
return self::$instance;
}
Bei der OOP sollte man den public variablen vermeiden, statt dessen get_xxx() und set_xxx()-Methoden verwenden, sonst macht das OO auch wenig Sinn (Stichwort Daten-Kapselung)
Bei kleinen Programmen lohnt sich der Aufwand mit Klassen ohnehin nicht und wirkt für die meisten Anwender eher unverständlich.
Hallo tommi,
ja stimmt du musst esoterisch veranlagt sein !
Mit Overhead meinst du Probleme in der Perfomance? Die TIEFEN von php machen mir noch Schwierigkeiten.
Falls die Verarbeitung auch dadurch etwas ausgebremst wird werde ich mir das mal in meinen Kalender schreiben.
hallo @Spawn, habe folgendes problem. im ipsymcon unter kernel bekomme ich alle 50 sec. eine fehlermeldung. script error eFHZ_calc.php sender variable eFHZ trigger usw. woran könnte das liegen. Danke
