Hallo und erstmal einen guten Abend in die ganze IPS-Runde hier.
Ich lese schon seit geraumer Zeit hier im Forum mit und habe zu Weihnachten mit meiner eigenen Version IPS angefangen zu experimentieren.
Leider bin ich auf dem Gebiet php und IPS völliger Neuling, habe aber aus dem Forum schon viele gute Hinweise mitgenommen, so dass die V2 schon einigermassen mit 2x FHT und 3x FS20 Steckdose plus Handsender läuft.
Ein Problem habe ich derzeit unter den Händen, und zwar ist das die Möglichkeit der Einbindung meiner Zisternenerkennung USF 1000.
Ich habe heute mal die Debugmeldungen (FTDI) der 1300PC laufen lassen und bekommen Meldungen von der USF.
Alle 3 Sekunden bekomme ich eine 14-byte Variable nach dem Schema:
81 0C 04 XX 01 01 A0 01A5 CE AA 00 B7 YY
wobei sich die hinteren 2 byte (YY) zwischen 05 und FF bewegen, wenn ich den Abstand zum Sensor verändere. Diese bytes müssten also den Abstand (und damit die Füllhöhe) repräsentieren.
Nun kommt meine eigentliche Frage:
Wie kann ich diese Bytefolge in IPS einlesen und die letzen beiden bytes als eine Variable definieren?
Vielleicht kann mir hier jemand mit einem Script aushelfen oder wenigstens Hinweise geben, damit ich weiter experimentieren kann?
Leider scheint es hier keine Meinungen dazu zu geben. Schade.
Ich würde die Einbindung als sinnvolle Erweiterung von IPS empfinden.
Also dann die Frage mal andersherum.
Ich habe jetzt den String von dem FTDI eingelesen und eine Variable definiert.
Leider sieht der Hex-String in ASCII ziemlich komisch aus, so dass man diesen erstmal wandeln müsste. Wie könnte man das tun?
Danach wäre zu prüfen, ob es auch wirklich die 14byte von der USF sind, und die letzten 2byte zu extrahieren. Und schon hätte man eine Füllhöhe, die man nur noch entsprechend Zisterne anpassen müsste.
Kann mir jemand Unterstützung bei der Umwandlung ASCII-Hex geben und den String dann auseinandernehmen? Ist sowas ohne Probleme in php möglich?
Tut mir leid, das ich hier etwas nerve mit diesem Thema, aber ich möchte das System irgendwie zum Laufen bekommen.
Erstmal ein herzliches Willkommen im Forum der Haussteuerungs-Freaks.
Es wundert mich, dass die USF 1000 von der FHZ 1300 PC erkannt werden kann. Aber schön zu hören, wenn dem so sei steht der Anbindung an IPS ja kaum noch was im Wege.
Nun zu Deinem Hex2Dec-Problem. So sollte die Wandlung des letzten Bytes funktionieren:
Die USF sendet wirklich entweder alle 30min im Stromsparmodus oder alle 3min wenn der interne Jumper entfernt ist einen oder 2 Strings mit folgendem Aufbau:
81 0C 04 XX 01 01 A0 01 A5 CE AA 00 B7 YY, wobei sich die letzten beiden Stellen im Verhältnis zum Abstand ändern (05 - FF).
Ich habe den ankommenden Datenstring mit Register Variable auf eine Variable $Zisterne(string) gelegt, leider scheint da irgendwas mit den Datenformaten der Variablen nicht zu funktionieren. Wenn ich mir im Script die Variable $Zisterne anzeigen lasse, ist der string leer, definiere ich aber die Varible $Zisterne mit dem Hex-string von oben funktioniert das ganze mit der Umwandlung wie von
bladerunner beschrieben.
Noch mal zu meinem Wunsch:
Ich möchte den FTDI-Eingang mitschreiben, erstmal alle reinkommenden strings auf eine Variable schreiben, diese dann untersuchen ob sie 14 byte lang ist und mit 81 0C 04 beginnt und mit 01 01 A0 weitergeht.
Wenn das der Fall ist kommt die Umwandlung von hex nach dezimal (siehe bladerunner) und danach die verknüpfung mit dem Zisternenabhängigen Faktor.
Wenn es eine andere Methode gibt, um das ganze zu realisieren wäre ich an einem Ansatz interessiert.
Wie schon gesagt bin ich absoluter Newbie auf dem Gebiet php aber immer bereit neues zu erlernen und mir helfen zu lassen.
Hast du irgendwo Informationen dazu, dass der USF 1000 wirklich mit dem FS20 Protokoll kompatibel ist? Sicher, dass nicht irgendein Bewegungsmelder Daten versendet? (Ich mag das nämlich nicht so recht glauben)
Und wenn ja, hast du genaue Informationen wie die letzten 2 Bytes zu interpretieren sind? Dann könnte ich vielleicht ein Modul daraus machen.
Da das Gerät (unter der o.g. Annahme) FS20 kompatible Bytes sendet, kannst du das FS20 Modul nehmen und es müsste zumindest ein Hauscode/Adresse erkannt werden. Die Variablen Data/Timer müsste sich dann auch ändern. Würde gerne wissen, welche Werte dort landen.
Ob der USF nun FS20-kompatibel ist oder nicht kann ich nicht sagen, ich weiss nur folgendes:
ich habe bei FTDI das debugfenster offen und bekomme mit 100%er Sicherheit von der USF folgenden String:
81 0C 04 XX 01 01 A0 01 A5 CE AA 00 B7 YY (wenn hex angekreuzt ist)
XX hat mal ne 1D, mal ne 1E …
YY bewegt sich abhängig vom Abstand zum Sensor (fast direkt drauf entspricht 05, Deckenhöhe ca. 2,5m entsprechen A6 bis A7 und wenn es ganzweit weg ist kommt FF)
Leider kann ich von Arbeit aus nicht die USF in den „Sende alle 3 Sekunden“-Mode umjumpern, so dass ich hier nur alle 30s einen String bekomme.
Wenn du mir sagst wie kann dir auch irgendwelche Logfiles zukommen lassen.
Wie schon gesagt wäre ich (und vielleicht auch andere) sehr daran interessiert, die USF in IPS einzubinden.
Mein USF 1000 ist übrigends im Oktober 2006 gekauft bei ELV.
Zitat von Attain:
„Wenn man mal ins Manual schaut http://www.elv-downloads.de/service/...USF1000_km.pdf , steht da: „Messbereich:…0,1 - 2,50 m“. Ich würde also davon ausgehen das 0x05 = 0,1m und 0xff = 2,5m ist.“
Das kann stimmen, zur Zeit liegt der Sensor auf dem Tisch und zeigt Richtung Decke, hat also einen Abstand von ca. 1,6m.
die von Dir genannte Datensequenz hat tatsächlich große Ähnlichkeit mit dem Datenformat wie es zur Kommunikation mit den FHTs verwendet wird:
81: FHT Kommunikation
0C: Telegrammlänge ab dem nächsten Zeichen (12 Zeichen + 81 + 0C = 14 Zeichen)
04: Telegrammtyp
XX: Checksumme; wenn sich die Daten ändern, ändert sich natürlich auch die Checksumme
01 01 A0 01: ??? (beim FHT: 09 09 A0 01)
A5 CE: diese beiden Bytes entsprechen beim FHT dem Hauscode
AA: Befehlscode
00 B7 YY: Nutzdaten
Das bedeutet allerdings nicht, dass die FHZ etwas damit anfangen kann. Aber Du greifst ja die Daten schon am FTDI ab.
Eine Interpretation nach Deinem Vorschlag sollte kein Problem sein. Schwieriger wird es, wenn Du gleichzeitig auch FHTs betreibst, denn dann musst Du diese von Deinem Zisternensensor unterscheiden.
danke für die Nachricht und die Zerlegung des Strings.
Man müsste dann also den String auf Vorhandensein des Codes 01 01 A0 01 testen und dann die Datenbytes auswerten, dann könnte man ihn von den FHTs unterscheiden.
Ich habe zur Zeit noch 2 FHTs hier am IPS, und da sollen in nächster Zeit noch weiter 3 dazukommen, so dass eine Unterscheidung anhand der Adresse der FHTs sinnvoll ist.
Ich weiss zur Zeit noch nicht weiter, ich bekomme den String, allerdings wenn ich ihn anzeige, sind es nur Hyroglyphen (ASCII von Hex-Zahlen) und ich weiss nicht, wie ich ihn weiter behandeln soll. (dank fehlendem php-Wissen)
Bin natürlich für alle Hinweise diesbezüglich offen.
Entschuldigung, aber irgendwie weiss ich damit nichts so richtig anzufangen.
Ich habe doch eine Variable mit dem Typ string erzeugt und die ist auch mit dem aktuell eingelesenen Wert des FTDI beschrieben.
Siehe http://alphacars.de/Bilder/Screenshot.jpg
Wie schon gesagt ist das mein erster Versuch mit IPS und php, ich bitte daher schon im Vorfeld um Entschuldigung.
Gruß
Thilo
@Attain
Beim Ausführen bekomme ich konstant den Wert 0 zurück.
es ist klar, dass Du nur Hieroglyphen angezeigt bekommst, da die Registervariable immer einen String enthält und PHP folglich glaubt es müsse aus den Bytes lesbare ASCII-Zeichen machen. Leider sind diese Bytes in ASCII auch nicht sonderlich gut lesbar. Aber das ist nicht das eigentliche Problem.
Tatsächlich haben wir es hier mit zwei verschiedenen Problemen zu tun:
B. Die Zerlegung des Byte-Strings in verwertbare Zeichen.
A. Zuvor muss aber erst einmal ein vollständiger String vorliegen.
Das Problem A ist bisher noch nicht angesprochen worden. Serielle Schnittstellen, wie COM-Port oder FTDI, liefern die Daten leider nicht immer „in einem Stück“, sondern häufig in kleineren „Häppchen“. Um einen vollständiges Datenpaket zu bekommen kann man so vorgehen:
A)
Registervariable auf „overwrite“ setzen und auf „OnUpdate“ triggern lassen
Registervariable auslesen und hinten an eine globale Variable „Zisterne“ anhängen
die angekommenen Daten nach der Startsequenz „81 0C 04“ durchsuchen
war die Suche erfolglos, Skript beenden und auf den nächsten Trigger warten
war die Suche erfolgreich, den Rest des Strings extrahieren
ist der Rest mindestens 11 Zeichen Lang?
Wenn nein, Skript beenden und auf den nächsten Trigger warten
wenn ja, prüfen ob die Sequenz „01 01 A0 01“ an Position 1 zu finden ist
8a. wenn nein, Daten sind nicht vom Zisternensensor
8b. prüfen, ob der Rest den Beginn der Startsequenz „81“ enthält
8c. wenn ja, „Zistern“ löschen bis ausschließlich „81“
8d. wenn nein, „Zisterne“ löschen
8e. Skript beenden und auf den nächsten Trigger warten
wenn ja, die ersten 11 Zeichen nach „Z_Daten“ abspeichern
die ersten 11 Zeichen von „Zisterne“ löschen
B)
Der String „Z_Daten“ stammt nun mit Sicherheit vom Zisternensensor und Position 10 enthält den Füllstand.
… und schon gibt es eine Lösung. Zwischen die FTDI Instanz und der Register Variable eine „Cutterinstanz“ setzen, konfigurieren wie im Bild, dann hast Du die Daten immer in der richtigen „Form“ vorliegen.
wie alt ist der USF und die FHZ? Ich hatte seinerzeit ähnliches versucht, aber meine FHZ hat sich nicht zur Zusammenarbeit mit dem USF bewegen können. Eventuell hat es da eine FW-Änderung gegeben…
Möglicherweise ist die FHZ beim „Durchreichen“ der empfangenen Daten nicht mehr so restriktiv.
Wenn es bei Dir klappt, super!
Zur Stringzerlegung hatten wir mal beim Leveljet (ich glaube von nancilla) ein paar Scriptschnipsel ausgetauscht, ev. ist da noch was zu finden.