Pluggit Lüftungsanlage anbinden

[Frank2]

So, habe mir jetzt ein kleines Programm geschrieben, um die Pakete zu dekodieren.

Super Arbeit. Net, dass es eine Kalibrierungsanzeige gibt. Hast du das aus dem nicht kalibiriert Log? Dort gibt es noch einen Countdown von 7200 runter. Das hatte ich in den alten Logs schon kommentiert. Die Fehlernummer stand da auch.

Ich werde es bei Gelegenheit so erweitern, dass er aus einem File in dem zeilenweise immer abwechselnd Requests und Respons drin stehen eine dekodierte Ausgabe erzeugt.

Das brauchst du nicht mehr. Ich habe alle Logs mit einem Programm umformatiert und bereits an der bekannten Stelle abgelegt.

Da kommt gleich noch etwas mehr an Logs. Es dauert nur eine Weile sich durch alle Funktionen durchzuarbeiten.

[Pontius Pilatus]

So, habe mir jetzt ein kleines Programm geschrieben, um die Pakete zu dekodieren.
Das Ergebnis sieht dann nach derzeitigem Stand z.B. so aus:
RequestRegisters: start=0x0400, numberOfRegisters=12
Response: numberOfRegisters=12
Register 0x0400 = 0x030E --> Stufe=3
Register 0x0401 = 0x0813 --> Zeit(Stunde)19
Register 0x0402 = 0x2729 --> Zeit(Minute)39
Register 0x0403 = 0x8F01 --> kalibriert=true
Register 0x0404 = 0x0000
Register 0x0405 = 0x0000
Register 0x0406 = 0x0004 --> Wochentag=Donnerstag
Register 0x0407 = 0x1710
Register 0x0408 = 0xFF12 --> T1=-1°C, T2=18°C
Register 0x0409 = 0x1603 --> T3=22°C, T4=3°C
Register 0x040A = 0x5B56 --> S1=182m³/h, T4=172m³/h
Register 0x040B = 0x0200

Ich werde es bei Gelegenheit so erweitern, dass er aus einem File in dem zeilenweise immer abwechselnd Requests und Respons drin stehen eine dekodierte Ausgabe erzeugt.

@Frank: könntest du ein solches Inputfile mit allen Aufzeichnungen bereitstellen?

Ciao, PP

[Frank2]

das Datum werden wir dann wahrscheinlich nur finden, wenn wir mehr Dumps von verschiedenen Tagen bekommen --> Frank? Die angezeigten Daten brauchen wir zu den Dumps natürlich auch möglichst vollständig.

Meine Dumps sind von drei verschiedenen Tagen.

In den Registern 8-13 vermute ich übrigens alle möglichen Flags. Da bekommen wir die Zuordnung aber nur, wenn Frank die Zustände herstellen kann. Also Evtl. mal einen Lüfter abklemmen oder so.

Das Abklemmen eines Lüfters überlasse ich dir ;-)

Register 14 könnte vielleicht der Wochentag sein? 04 = Donnerstag

0=Sonntag 1=Montag 2=Dienstag 3=Mittwoch 4=Donnerstag => Klingt plausibel

[Pontius Pilatus]

Hi Simon,
das Datum werden wir dann wahrscheinlich nur finden, wenn wir mehr Dumps von verschiedenen Tagen bekommen --> Frank? Die angezeigten Daten brauchen wir zu den Dumps natürlich auch möglichst vollständig.

Wenn das Datum nicht vor der Zeit steht, dann vielleicht direkt dahinter. Die Frage ist nur, wie es kodiert ist.

Wenn ich schon sehe, dass die die Volumenströme div 2 übertragen, schwant mir nichts Gutes.

In den Registern 8-13 vermute ich übrigens alle möglichen Flags. Da bekommen wir die Zuordnung aber nur, wenn Frank die Zustände herstellen kann. Also Evtl. mal einen Lüfter abklemmen oder so.

Register 14 könnte vielleicht der Wochentag sein? 04 = Donnerstag


Ciao, PP

[Frank2]

Hi Frank könntest du vielleicht bei deiner Fernbedienung das Datum und die Uhrzeit einstellen das ganze loggen und hochladen wenn du ein bisschen zeit hast.

Ich erstelle heute Abend mal ein Log mit verschiedenen Einstellungen. Das Datum ist ja nicht das einizigste unklare Feld. Wir hätten da ja noch die Timer, den Bypass und andere Einstellungen.

Dann können wir vielleicht rausbekommen in welches Register das Datum geschrieben wird.

Kannst du dir bitte mal meine Logs zur Einstellung der Lüfterstufe vornehmen und nachsehen ob die Lüfzterstufe in das gleiche Register geschrieben wird oder ob es für das Lesen ein anderes Register gibt? Hier könnten ja ist und sollwerte existieren. Eventeull werden auch zum Programmieren gänzlich andere Register als zum Lesen genutzt.

Ich habe ja noch Logs wo die Anlage eine Kalibrierung einfordert. Dafür hat man etwa 7000 Sekunden Zeit. Diese Zeit habe ich in den Werten auch schon identifiziert ohne die Speicherstelle auszurechenen. Der Fehlercode 02 wird da auch stehen.

Hast Du eine Software um die Registernummern zu errechnen oder was das manuelles ausrechnen?

[SimonK]

Hi Frank könntest du vielleicht bei deiner Fernbedienung das Datum und die Uhrzeit einstellen das ganze loggen und hochladen wenn du ein bisschen zeit hast.
Dann können wir vielleicht rausbekommen in welches Register das Datum geschrieben wird.
Gruß Simon

[SimonK]

S1 und S2 sind auch gefunden :-)
01 03 18 00 10 14 04 5B 56....
00>>T1=0C
10>>T2=16C
14>> T3=20C
04>>T4=4C

5B >>91*2>>S1=182
56>>86*2>>S2=172

Gruß Simon

[SimonK]

Ich hab mich grade mal ans Datum gesetzt.
Da muss ich euch leider enttäuschen ich habe die logs mal durchsucht und ich glaube das war nur Zufall :-(
Denn auf die Anfrage 01 03 04 00 00 0C 44 FF
Findet man auch die Antworten
01 03 18 01 0E 01 16 12 29 8F 01... und 01 03 18 02 0E 01 16 12 29 8F 01...

Gruß Simon

[Frank2]

Hallo Leute, sagt mal könnte es sein, dass die Temperaturwerte als Bytes übertragen werden? Die Daten aus "4_werte.txt" zeigen ja zwei immer wiederkehrende Request + Response. Im ersten Response ab Offset 0x13 steht: "FF 12 16 03". Deine Anzeigewerte waren: T1=-01°C T2=18°C T3=22°C T4=03°C

Zu diesen Erkenntnissen bin ich auch gekommen. In dem was ich dir zukommen lassen habe sind Daten von unterschiedlichen Tagen und anderen Temperaturen.

In beiden Responses aus dem File konnte ich leider keine Standardkodierung eines Datums/Uhrzeit finden. Deshalb habe ich ganz plump nach 0x13:0x27 (19:39) gesucht. Das steht ab Offset 0x06. Noch verrückter wird's beim Datum, das könnte ab Offset 0x03 stehen: 03 0E 08. (Monat Tag Jahr). Wobei das Jahr seit 2005 zu rechnen wäre. Komische proprietäre Kodierung, aber damit stünde als Erstes im Paket Datum und Zeit: 03 0E 08 13 27 '
Auch hier wäre zu prüfen, ob's bei einer neuen Aufzeichnung dann auch hinhaut.

Das ist auch meine Erkenntnise bis jetzt. Ich habe das aber noch nicht mit anderen Datumsangaben gegengeprüft.

Ich wollte die Felder alle mal in eine Tabelle übernehmen und dann versuchen zuzuordnen. Dazu habe ich die Logs umformatiert damit man es besser lesen kann. Die Files habe ich noch einmal aktualisiert.

Vielleicht hat jemand Lust die Felder mal in eine Tabelle zu übertragen. Ich werde erst einmal an der Hard- und Software weiter arbeiten.

Basis für die Hardware wird nun ein Teensy 3.0 werden. Das System hat 3 freie UARTS, einen USB-Port der mit voller USB 1 Geschwindigkeit bedient werden kann und Hardware CRC Unterstützung. Das macht die Analyse einfacher. Dazu kommt noch ein Gas-Sensor (Figaro TGS 2600-B00) sowie ein Temperatur und Feuchtesensor (DHT 11)

Mit etwas Glück lässt sich alles auf einer Lochrasterplatine aufbauen. Die Sensoren können leicht im Luftstrom platziert werden um die Raum-Zuluft zu messen. Gerne würde ich noch einen DHT 11 in der Raum-Abluft platzieren. Das könnte aber Auswirkungen auf die Dichtheit haben.

Viele Grüße

Frank

[Pontius Pilatus]

Hi Simon,
Warum nicht. Es hat schon einen Grund, warum Pluggit die Schnittstelle nicht offenlegt ;-)
Das gleiche Muster wird es bestimmt bei den Volumenstromangaben S1 und S2 geben. Dafür brauchen wir aber nochmal neue Records mit den Angaben vom Display.

Viel merkwürdiger finde ich die 5 Bytes für das Datum. Der Wochentag war da auch nicht direkt bei.

Schwierig dürfte es auch sein, die Flags zu identifizieren. Wobei ich nicht auf Bitfelder tippen würde, sondern eher davon ausgehe, dass die Jungs jeweil ein Byte (bool) pro Flag schreiben. Damit wären die zusammenhängenden Nullen in dem von mir untersuchten Record verdächtig für Filter voll, etc.

Ciao, PP

[SimonK]

Hi Pontius Pilatus

Mit den Temperaturwerten hast du recht ich habe in den Logs auch andere Temperatur werte gefunden die im gleichen Register stehen.
Aber das würde heißen das in einem Register 2 Werte drin stehen oder sehe ich das jetzt falsch.
Im Register 41033 stehen die Temperaturwerte von T1 und T2
Und im Register 41034 stehen die Temperaturwerte von T3 und T4


Gruß Simon

[Pontius Pilatus]

Hallo Leute, sagt mal könnte es sein, dass die Temperaturwerte als Bytes übertragen werden? Die Daten aus "4_werte.txt" zeigen ja zwei immer wiederkehrende Request + Response. Im ersten Response ab Offset 0x13 steht: "FF 12 16 03". Deine Anzeigewerte waren: T1=-01°C T2=18°C T3=22°C T4=03°C

Kann Zufall sein, oder auch nicht. Frank könntest du noch so einen Record erzeugen? Vermutlich sind die Temperaturen jetzt andere...

In beiden Responses aus dem File konnte ich leider keine Standardkodierung eines Datums/Uhrzeit finden. Deshalb habe ich ganz plump nach 0x13:0x27 (19:39) gesucht. Das steht ab Offset 0x06. Noch verrückter wird's beim Datum, das könnte ab Offset 0x03 stehen: 03 0E 08. (Monat Tag Jahr). Wobei das Jahr seit 2005 zu rechnen wäre. Komische proprietäre Kodierung, aber damit stünde als Erstes im Paket Datum und Zeit: 03 0E 08 13 27 '
Auch hier wäre zu prüfen, ob's bei einer neuen Aufzeichnung dann auch hinhaut.

Was meint ihr dazu?

Ciao, PP

[SimonK]

Hallo Frank
Die 44 und die 84 gehören mit zum CRC :-)
"01 03 04 00 00 0C" = "44 FF" CRC
"01 03 04 0C 00 0C" = "84 FC" CRC
Also ich Persönlich tendiere zur zweiten Variante.
Freu mich schon auf deine Tabelle.
Gruß Simon

[Frank2]

Ich habe mich da bei der Antwort vertan. Die stimmt mit einer 8-Bit CRC überein und hat die richtige Länge. Trotzdem kann ich mir ein Byte der Anfrage nicht erklären.

Hier mal einige Anfragen. Die Antworten poste ich wegen einer eventuellen Seriennummer nicht. Etliche Felder habe ich schon identifiziert. Da erstelle ich dann mal eine Tabelle.

Lese-Anfragen:
01 03 04 00 00 0C 44 FF -> Start 0 Anzahl 0c
01 03 04 0C 00 0C 84 FC -> Start 0c Anzahl 0c

Wofür könnten 44 und 84 stehen?

Noch ein paar Werte 2_=FB->P300, 3_=P300->FB

Schreibaktion: Start Kalibrieren
2_01 2_10 2_00 2_07 2_00 2_01 2_02 2_00 2_01 2_66 2_27
3_01 3_10 3_00 3_07 3_00 3_01 3_B0 3_08

Schreibaktion: Stufe 1 blinkt
2_01 2_10 2_00 2_00 2_00 2_01 2_02 2_00 2_09 2_66 2_56
3_01 3_10 3_00 3_00 3_00 3_01 3_01 3_C9

Schreibaktion: Aus
2_01 2_10 2_00 2_00 2_00 2_01 2_02 2_00 2_00 2_A6 2_50
3_01 3_10 3_00 3_00 3_00 3_01 3_01 3_C9
2_01 2_10 2_00 2_2A 2_00 2_01 2_02 2_00 2_02 2_20 2_5B
3_01 3_10 3_00 3_2A 3_00 3_01 3_20 3_01

Bezüglich einer Hardwarelösung kann ich mir zwei Szenarien vorstellen. Das einfachste wäre ein FTDI 3.3V Kabel was auf das Board gesteckt wird. Die Fernbedienung währe dann ohne Funktion und die gesamte Steuerung muss über das Kabel durch einen PC o.ä. vorgenommen werden. Die Software sollte auch unter Linux laufen damit man mit einem einfachen System wie einem Rasperry PI auskommt. Das setzt allerdings eine weitgehende Entschlüsselung der Felder voraus damit man auch Fehlersituationen erkennen kann.

Die Variante zwei wäre für die, die mit der Fernbedienung weiter arbeiten möchten und/oder zusätzliche Sensoren im Gerät möchten. Da ist dann eine Schaltung notwendig. Ich möchte einen Feuchtigkeitssensor und Gas-Sensoren im Luftstom haben um die Anlage danach steuern zu können. Richtung PC würde das gleiche Protokoll gesprochen werden wie mit dem FTDI-Kabel, nur dass die zusätzlichen Sensoren über eine andere Slave-ID angesprochen werden.

Was haltet Ihr davon?

Hat jemand die Technik da sich mal mit der 433MHz Übertragung zu beschäftigen? Dann könnte man die Anlage ohne Eingriff kontrollieren.

Viele Grüße

Frank

[SimonK]

Hi
Ich hab mal einen String Umgelegt auf Modbus müsste eigentlich passen.
Gruß Simon


Anfrage

01 03 0408 000C C53D

01: The Slave Address (1 dez = 01 hex)
03: The Function Code (read Analog Output Holding Registers)
0408: The Data Address of the first register requested. (42053-40001 = 2052 = 0408 hex)
000C: The total number of registers requested. (read 12 registers 42053 to 42064)(12 dez = 000C hex)
C53D: CRC

Antwort

01 03 18 0010 1404 312E 0200 0003 0208 0802 7F01 0004 9104 A500 0000 881B

01: The Slave Address (1 dez = 01 hex)
03: The Function Code (read Analog Output Holding Registers)
18: The number of data bytes to follow (12 registers x 2 bytes each = 24 bytes)(24 dez = 18 hex)
0010: The contents of register 42053
1404: The contents of register 42054
312E: The contents of register 42055
0200: The contents of register 42056
0003: The contents of register 42057
0208: The contents of register 42058
0802: The contents of register 42059
7F01: The contents of register 42060
0004: The contents of register 42061
9104: The contents of register 42062
A500: The contents of register 42063
0000: The contents of register 42064
881B: CRC



http://www.simplymodbus.ca/FC03.htm