868 MHz Protokoll f. Heizung FHT80 und HMS - Infos gesucht

Hallo,

ich suche Informationen zu den Protokollen von FHT80 und HMS die in den ELV Produkten verwendet werden.
Die verfügbaren Informationen aus dem Forum über das FS20 Protokoll kenne ich, beinhalten aber nichts zu FHT80 und HMS Komponenten.

Einiges habe ich schon dekodiert und herausgefunden. Vielleicht kann man sich ja austauschen.

Andreas

Dass die sich im 2 bis 3 Minutentakt unterhalten und über den Anmeldevorgang die Synchronisierung beginnt, d.h. die Synchronisierungzeit gestartet wird, habe ich auch rausgefunden.
Man müßte einen Logicanalyser haben. Die genaue Zeit kann man mit einfachen Mitteln ausmessen.
Hat man das Protokoll, kann man auch zentrale Steuerungsaufgaben machen, träum träum.... O:)

Nun, ich habe eien 868 Mhz Empfänger am Atmega32 und lese die Impulse mit. Ich kann die Syncbits der Übertragungssequenz und die Informationsbits erkennen. Die Informationsbits kann ich auch in Bytes zusammenfassen, Parity prüfen und die CRC checken. Ich kann den Hauscode und die Moduladresse dekodieren. Was mir noch unklar ist sind die Bedeutung der nachfolgenden Befehle oder Codes und die Deutung der übertragenen Werte. Also wie ist z.B. die Temperatur verschlüsselt ? (Highbyte / Lowbyte, Zahlenformat etc.
Die vom ATMega erfassten Daten gebe ich über RS232 an den PC und protokolliere sie mit.
Über die Analyse dieser Daten kommt man sicher auf einige Infos. Ist aber etwas mühsam. Aber vielleicht hat jemand schon ein paar Codes etc. herausgefunden ?

Interessiert das hier sonst keine(n) :) ?

Ich kann die Daten der FHT's ebenfalls protokollieren, darin sind die Adr's, Hauscode, Temperaturen und Stellungsmeldungen zu den Stellmotoren enthalten.

Wie liest du denn mit? Über RS232 ?

ja, rs232.
sieht dann im Moment so aus:

HC:54-19 ADR:0 ARG:166 ARG:0 CRC:251 (Bits:67 Bytes:7 End:3696)
0000000000001-00110110000010011100000000010100110000000000011111 0111
HC:87-70 ADR:0 ARG:166 ARG:0 CRC:79 (Bits:67 Bytes:7 End:4736)
0000000000001-01010111101000110100000000010100110000000000001001 1111
HC:76-0 ADR:159 CRC:0 (Bits:48 Bytes:3 End:3584)
1110100011010000000001-01001100000000000010011111
HC:95-66 ADR:0 ARG:166 ARG:8 CRC:91 (Bits:67 Bytes:7 End:4864)
0000000000001-01011111001000010000000000010100110000001000101011 0111
HC:76-17 ADR:183 CRC:17 (Bits:48 Bytes:3 End:3792)
1100100001000000000001-01001100000010001010110111

SByte1 = 1 ---> Adr
SByte2 = 49--> Adr
SByte3 = 0
DByte1 = 6--> Ventilstellung mit Wert 0 ?
DByte2 = 0
DByte3 = 0

Edit:

SByte1 = 4
SByte2 = 54
SByte3 = 66
DByte1 = 9
DByte2 = 233
DByte3 = 0

Das müste 23,3 Grad sein ?

SByte1 = 4
SByte2 = 54
SByte3 = 0
DByte1 = 6
DByte2 = 11
DByte3 = 0
Dasd müste Ventilstellung: 4,296875 % sein ?


SByte1 = 4
SByte2 = 54
SByte3 = 0
DByte1 = 6
DByte2 = 24
DByte3 = 0
das Ventilstellung : 9,375 % sein ?
Das würde bedeuten: Ventilstellung 255 = 100%

Wenn ich dein AVR-Programm, das seriell die Daten in meinen Rechner gleichzeitig mit meinen Log-Files schreibt, könnte ich den Zusammenhang deutlicher erkennen, weil du andere Adressen hast usw.
So wie ich das sehe, bedeutet der Wert nach den Adressen den Modus der nachfolgenden Daten. Also 6 z. B. für die Ventilstellung, 9 für die Temp: hier 19,6 Grad.
SByte1 = 1
SByte2 = 49
SByte3 = 66
DByte1 = 9
DByte2 = 196
DByte3 = 0

Ev kannst du mir mal einen Plan und das Programm für den AVR per PN mailen.
Es fängt mit dem Synchronisieren an 12x 0, 1x1: dann blicke ich aber nicht durch dein Zahlenwerk durch...
Hauscode, Adresse, Argument, CRC, ist klar, kann ich aber nicht von BCD nach Dez konvertieren :-( passt irgendwie nicht.
Sind das mehrere FHT's ?


HC:54-19 ADR:0 ARG:166 ARG:0 CRC:251 (Bits:67 Bytes:7 End:3696)
0000000000001-00110110000010011100000000010100110000000000011111 0111
HC:87-70 ADR:0 ARG:166 ARG:0 CRC:79 (Bits:67 Bytes:7 End:4736)
0000000000001-01010111101000110100000000010100110000000000001001 1111
HC:76-0 ADR:159 CRC:0 (Bits:48 Bytes:3 End:3584)
1110100011010000000001-01001100000000000010011111
HC:95-66 ADR:0 ARG:166 ARG:8 CRC:91 (Bits:67 Bytes:7 End:4864)
0000000000001-01011111001000010000000000010100110000001000101011 0111
HC:76-17 ADR:183 CRC:17 (Bits:48 Bytes:3 End:3792)
1100100001000000000001-01001100000010001010110111

Es sind mehrere FHT´s, gesamt 12 FHT, 35 Schalter/Dimmer, 14 PIRI´s, 12 4-Kanalsender, 12 HMS Komponenten, Wetter etc.

Zum Aufbau des Codes an einem Beispiel:
die Startbits bestehen aus 12 low+1high, danach die datenbits, immer 8+1prüfbit. Ich mach mal Trennstriche zwischen den Bitblöcken und & vor dem Prüfbit zur Verdeutlichung.
Die ersten 2 Bytes (hier HC genannt) sind bei FHT die Adresse, das 3. Byte (hier ADR) der Code, danach die Daten (ARG, ARG) und die CRC.

HC:54-19 ADR:0 ARG:166 ARG:0 CRC:251 (Bits:67 Bytes:7 End:3696)
0000000000001-00110110&0-00010011&1-00000000&0-10100110&0-00000000&0-11111011&1

Hier nochmal ein kompletter Block von einem FHT-Regler:
HC:32-23 ADR:125 ARG:103 ARG:49 CRC:88 (Bits:67 Bytes:7 End:4512)
0000000000001-00100000100010111001111101001100111100110001101011 0001
HC:32-23 ADR:125 ARG:119 ARG:49 CRC:104 (Bits:67 Bytes:7 End:3312)
1000000000001-00100000100010111001111101001110111000110001101101 0001
HC:32-23 ADR:66 ARG:105 ARG:186 CRC:168 (Bits:67 Bytes:7 End:3584)
0000000000001-00100000100010111001000010001101001010111010110101 0001
HC:32-23 ADR:66 ARG:105 ARG:186 CRC:168 (Bits:69 Bytes:7 End:3872)
100000000000001-00100000100010111001000010001101001010111010110101 0001
HC:32-23 ADR:66 ARG:121 ARG:186 CRC:184 (Bits:66 Bytes:7 End:3328)
100000000001-00100000100010111001000010001111001110111010110111 0000
HC:32-23 ADR:67 ARG:105 ARG:0 CRC:239 (Bits:68 Bytes:7 End:3440)
10000000000001-00100000100010111001000011101101001000000000011101 1111
HC:32-23 ADR:67 ARG:121 ARG:0 CRC:255 (Bits:66 Bytes:7 End:3744)
100000000001-00100000100010111001000011101111001100000000011111 1110
HC:32-23 ADR:75 ARG:103 ARG:0 CRC:245 (Bits:67 Bytes:7 End:2992)
0000000000001-00100000100010111001001011001100111100000000011110 1010
HC:32-23 ADR:75 ARG:119 ARG:0 CRC:5 (Bits:66 Bytes:7 End:3008)
100000000001-00100000100010111001001011001110111000000000000000 1010
HC:32-23 ADR:68 ARG:105 ARG:0 CRC:240 (Bits:68 Bytes:7 End:4432)
10000000000001-00100000100010111001000100001101001000000000011110 0000
HC:32-23 ADR:68 ARG:121 ARG:0 CRC:0 (Bits:66 Bytes:7 End:3840)
000000000001-00100000100010111001000100001111001100000000000000 0000
HC:32-23 ADR:75 ARG:103 ARG:0 CRC:245 (Bits:68 Bytes:7 End:2864)
00000000000001-00100000100010111001001011001100111100000000011110 1010
HC:32-23 ADR:75 ARG:119 ARG:0 CRC:5 (Bits:66 Bytes:7 End:3904)
000000000001-00100000100010111001001011001110111000000000000000 1010
HC:32-23 ADR:126 ARG:103 ARG:0 CRC:40 (Bits:67 Bytes:7 End:3488)
0000000000001-00100000100010111001111110001100111100000000000101 0000

Sorry, ich hatte keine Zeit vorher, und war auch noch verwirrt, habe die Dekodierung jetzt erkannt.
HC:54-19 ADR:0 ARG:166 ARG:0 CRC:251 (Bits:67 Bytes:7 End:3696)
0000000000001 ---------------> enrspricht 12 mal 0, 1 mal 1, wie im FS20
00110110&0-00010011&1------> das soll 54 19 sein
00000000&0-10100110&0------>
00000000&0-11111011&1------>

(alles Dez)
wie geschrieben bekomme ich meine Logfiles und kann daraus die Rückschliüsse ziehen, die ich oben geschildert habe.
Kannst du denn mit deinem AVR auch senden um etwas aus zuprobieren?
Mich würde eine Verbindung zum Stellventil reizen, ohne FHT.....
Ich habe festgestellt, die synchronisieren sich beim Anmelden.
Und zwar machen die ein Zeitfenster ab, in dem sich das Stellventil bereit macht, Daten zu empfangen.
Was es für Daten sind habe ich noch nicht rausbekommen, weil ich nur das Telegram der FHT mitlesen kann. Ev. besteht gar kein Unterschied.
Das müsste Rückmeldung in Automatic oder in Automatic schalten sein :
SByte1 = 1
SByte2 = 49
SByte3 = 126
DByte1 = 7
DByte2 = 42
DByte3 = 0



Das müste in Manuel schalten sein
SByte1 = 1
SByte2 = 49
SByte3 = 126
DByte1 = 7
DByte2 = 1
DByte3 = 0
Das müste in Automatic schalten sein
SByte1 = 1
SByte2 = 49
SByte3 = 126
DByte1 = 7
DByte2 = 0
DByte3 = 0



Das müste Ventilstellung 18,75 sein ---> DByte2= 255 = 100 %
SByte1 = 1
SByte2 = 49
SByte3 = 0
DByte1 = 6
DByte2 = 48
DByte3 = 0

SByte1 = 1
SByte2 = 49
SByte3 = 0
DByte1 = 6
DByte2 = 43 das ist Ventilstellung 16,79688 %
DByte3 = 0

SByte1 = 1
SByte2 = 49
SByte3 = 0
DByte1 = 6
DByte2 = 38 das ist Ventilstellung 14,84375 %
DByte3 = 0

SByte1 = 1
SByte2 = 49
SByte3 = 0
DByte1 = 6
DByte2 = 32 das 12,5 % ventilstellung
DByte3 = 0

das müste 21 grad meldung sein
SByte1 = 1
SByte2 = 49
SByte3 = 66
DByte1 = 9
DByte2 = 210
DByte3 = 0

das 21,2 grad
SByte1 = 1
SByte2 = 49
SByte3 = 66
DByte1 = 9
DByte2 = 212
DByte3 = 0

nein, senden kann ich im Moment nicht.
Woher hast du deine Logfiles und welche Software setzt du ein? Sind da keine CRC dabei ?
Du schreibst DByte2 = 212 wären 21,2 Grad. Was passiert bei Temperaturen größer 25,5 Grad ?
Bzgl. der Ventilstellung und den bisherigen Erfahrungen über den Aufbau der Codes kann ich mir nicht vorstellen, dass für die Übertragung von ganzzahligen Werten zwischen 1und 100 die das vorher in Werte zwischen 1und 255 umrechnen und dann wieder rückwärts. War das eine Vermutung oder hast du das definitiv rausgefunden.
Ich habe jetzt 3 Tage die Daten in einem ASCII Format mitprotokolliert und will das mal mit EXCEL und den Filtern und Sortieren Möglichkeiten etwas unter die Lupe nehmen. Das File ist fast 5 MB groß. Die Daten der Stellantriebe müssen da ja auch mit drin sein.
Mal sehen...

Meine Logfiles erhalte ich von der FHZ1000 PC von ELV .
Mit den Temperaturen über 25,5 Grad muß ich erst mal ausprobieren.
Im Moment habe ich kaum Zeit. Ich kann die gesamten Daten der FHT's mit der jeweiligen Uhrzeit der Meldung mitloggen. Dann kann ich jeweils noch die Temperaturen, Ventilstellungen, Manuel oder Automatikmode, Fensterkontakte-Rückmeldungen usw. einzeln auch mit Uhrzeit mitloggen.
Das bedeutet: ich wei0 welche Meldung die Temp, Ventilstellung oder sonstwas ist, weil ich die Meldung dann zur gleichen Uhrzeit zuordnen kann.

Beispiel Logfile gesamter FHT Uhrzeit:
12:01
SByte1 = 1
SByte2 = 49
SByte3 = 66
DByte1 = 9
DByte2 = 212
DByte3 = 0
es meldet sich um die Temperatur mit Uhrzeit:
12:01
21,2 Grad
genauso finde ich dann raus, wenn ich Stellungen der Ventile bekomme, ich suche nur noch die passende Uhrzeit, dann weiss ich was das für ein Code ist.
Es kann aber sein, und es wird auch so sein, daß deine Darstellungen der Werte anders ist.
Deshalb wollte ich ja deine Schaltung und den AVR -Code haben.
Dann kann ich es genauso mit den seriellen Daten deines Empfängers machen. Mein Logfile der ser. Schnittstelle wird auch mit Uhrzeit geloggt.
Auf die Weise bekomme ich einen Überblick zu welcher Zeit welche Daten kommen.
Ich kann mit meiner FHZ 1000 PC auch senden, dein Gerät hört das mit, so daß ich auch rausbekomme, welche Daten das Gerät bekommt um etwas im FHT zu setzen !!
Das mitloggen geht automatisch, nur das Auswerten muss man selber machen.
Bei den zusendenen Befehlen, da muß man dabei sein, weil das ja dann gesendete FHZ 1000 PC-Befehle sind und keine von der FHT.
Die Logfiles müsste man in Exel einlesen oder von Hand durchsehen.
Wie gesagt, mit deinem Gerät und meiner FHZ-Logfile Geschichte könnte es einfacher sein.
Auszug aus dem FTDI-Log (Daten über USB) und dem FHT-Log:
18.11.05 23:50:35 (11): 81 0c 04 97 09 09 a0 01 01 31 4b
18.11.05 23:50:35 (11): 81 0c 04 ca 09 09 a0 01 01 31 7e
18.11.05 23:52:13 (10): 81 0c 04 8b 09 09 a0 01 01 31
18.11.05 23:54:08 (10): 81 0c 04 8b 09 09 a0 01 01 31
18.11.05 23:57:18 (11): 81 0c 04 77 09 09 a0 01 04 36 42
18.11.05 23:57:18 (11): 81 0c 04 99 09 09 a0 01 04 36 43
18.11.05 23:57:18 (11): 81 0c 04 9f 09 09 a0 01 04 36 4b
18.11.05 23:57:19 ( 2): 81 0c
18.11.05 23:57:19 ( 9): 04 9a 09 09 a0 01 04 36 44
18.11.05 23:57:19 ( 9): 04 9f 09 09 a0 01 04 36 4b
18.11.05 23:59:15 (10): 81 0c 04 93 09 09 a0 01 04 36
19.11.05 00:01:13 (10): 81 0c 04 93 09 09 a0 01 04 36
19.11.05 00:02:33 ( 2): 81 0c
19.11.05 00:02:34 ( 9): 04 5f 09 09 a0 01 01 31 42
19.11.05 00:02:34 ( 9): 04 91 09 09 a0 01 01 31 43
19.11.05 00:02:34 ( 9): 04 97 09 09 a0 01 01 31 4b
19.11.05 00:02:34 ( 9): 04 92 09 09 a0 01 01 31 44
19.11.05 00:02:35 (11): 81 0c 04 97 09 09 a0 01 01 31 4b
FHT:
18.11.05 23:02:34 Bad_oben_Temp_Ist 21.2 Float
18.11.05 23:19:30 Bad_oben_Temp_Ist 21 Float
18.11.05 23:34:54 Bad_oben_Temp_Ist 20.9 Float
18.11.05 23:50:34 Bad_oben_Temp_Ist 20.7 Float
19.11.05 00:02:34 Bad_oben_Temp_Ist 20.7 Float
19.11.05 00:19:11 Bad_oben_Temp_Ist 20.5 Float
19.11.05 00:34:35 Bad_oben_Temp_Ist 20.5 Float
19.11.05 00:50:34 Bad_oben_Temp_Ist 20.4 Float
19.11.05 01:03:27 Bad_oben_Temp_Ist 20.3 Float
19.11.05 01:18:51 Bad_oben_Temp_Ist 20.2 Float

81 0c 04 97 09 09 a0 01 01 31 4b entspricht in Bin, deshalb hatte ich erst oben soviel schwierigkeiten deinen Code zu lesen:
1000 0001 0000 1100 0000 0100 1001 0111 00001001 0000 1001 1010 0000 0000 0001 0000 0001 0011 0001 0100 1011


MfG

Hi Grüss Euch,

da ihr anscheinend dasselbe versucht, würd mich gern bei euch einklinken.

Leider bin ich aber noch nicht ganz so weit wie ihr, ich versuch z.Z. Verbindung zur FHZ1000pc aufzubauen, so dass ich mal was senden/empfangen kann.

Zitat:
Einiges habe ich schon dekodiert und herausgefunden. Vielleicht kann man sich ja austauschen.
und noch ein Zitat:
Interessiert das hier sonst keine(n) ?

Tja, ich denke man könnte das Protokoll gemeinsam raus bekommen, ich mit meinen Log's und mit den Mitschnitten aus AS123. Wenn ich die AVR-Log's seriell gleichzeitig mit meinen FHZ-Logs hätte, geht es leichter und auch AS123 hätte sein Logformat erklärt bekommen, hätten alle was davon. Scheint doch jeder seine eigene Suppe kochen zu wollen.
MfG

hab unter:
http://fhz4linux.info/tiki-index.php...000%20Protocol
http://fhz4linux.info/tiki-index.php?page=FS20+Protocol

was gefunden das womöglich schon hilfreich wäre, oder zu mindest ein Kontakt der uns weiterhilft.

Ich hab jetzt zumindest mal die FHZ1000PC als usbDevice in meinem Projekt. wie ich jetzt aber den SerialPort da rauskrieg damit ich Kommunikation aufbauen kann, weiß ich leider noch nicht.(ich Arbeite unter VB.Net und versuche eine ClassLibrary für FS20, FHZ, FHT... zu schreiben)

Jo, so habe ich mir das auch vorgestellt, mein Datenformat ist wie im ersten Link.
Ich kann mit meinen Log's ähnliche Verknüpfungen erkennen.
Der Link ist klasse.
Um das Datenformat von AS123 zu bekommen muß man "hardware nah" loggen können, sprich die Funksignale über eigene Hardware dekodieren, hier muß man sicherlich die Manchesterdekodierung entsprechen entschlüsseln, die Übertragungsgeschwindigkeit erkennen, das Datenformat per Soft erkennen und dann seriell ausgeben, dazu fehlt mir persöhnlich die Zeit. Doch über die FHZ 1000 PC Hardware komme ich auch auf solche Formate und um die Befehle zu entschlüsseln reicht es ja.
Um das serielle Datenformat des USB-Device FHZ 1000 PC zu bekommen, muß man nur in die Box und RX und TX am PIC-Kontroller abgreifen. http://www.ipsymcon.de/forum/showthread.php?t=64

ich hab mir mittlerweile einen Treiber geholt, der mir an der FHZxxPC einen Virtuellen SerPort Emuliert.
(unter: http://www.ftdichip.com/Drivers/D2XX.htm)

Dazu mußte ich aber wie auf FHZ4LinuxPage beschrieben die FTDI-Chip Settings (ProductID) etwas Anpassen damit sich der Treiber hierzu installieren lässt.

So Mittlerweile hab ich also den COM-Port Kann ihn Öffnen usw.

Aber: Es ist zum verückt werden: ich Krieg Keine Antworten wie auf:

"81 06 c9 82 02 01 1f 60 " was laut FHZ4Linux "Say Hello" bedeuten soll.

Ich denke es könnte mit dem Encoding zusammenhängen z.B. (CRLF zum Abschluss der Zeile) oder irgend eine andere Kleinigkeit die ich übersehen hab.

Biste auf Linux oder Windows? Ich habe keine Ahnung von Linux..

Ich bin (noch) unter Windows unterwegs,

der unterschied zu Linux ist in diesem Fall "Nur" der Driver. Die FHZ ist ja die Selbe, und wenn an einem Seriellen Port "Hallo" Raus schreibt macht es keinen unterschied ob das Hallo nun von Linux oder Windows kommt. Es sei den es wird der Text den man rausschreibt vom Driver (oder vom verw. Programm) irgendwie "Autoverfollständigt" oder "Formatiert", wie z.B ein "LineEnd-Character" angehängt.

Also hab ich eigentlich dassselbe gemacht wie unter
http://fhz4linux.info/tiki-index.php...r+installation
("Solution B")
beschrieben ist, nur das ich halt die Windows Version von dem "FTDI-Driver" verwende.

Hier gibt es wiederum 2 Versionen:
-"Direct"-Driver: Stellt die SerPortFunctionen als Win32API mit einer DLL zur Verfügung. (So wie es der mitgelieferte Driver von ELV macht) Ich bin ohnehin der Meinung, dass der "ELV-Driver" und der FTDI-Driver Ein Und der Selbe ist mit dem einen Kleinen Unterschied dass die Product-ID am FTDI mit der in der INF-Datei übereinsteht.

-"VCP - VirtualComPort": Stellt den FTDI232AM-Chip als SerialPort zur Verfügung, sodaß man ihn Theoretisch im HyperTerminal ansprechen kann. Ich hab genau diese Möglichkeit gewählt da ich im VB.Net zwar auf WIN32API-Functionen zugreifen kann, ich aber .Net-Standard Componenten verwenden möchte.

Ich Glaub ich hab den meinen Fehler auch schon gefunden:
Ich habe ja bis jetzt "81 06 c9 82 02 01 1f 60" als STRING rausgeschickt,
manche Programme erkennen zwar Automatisch dass es sich hier um Bytes in einem ARRAY handelt aber wenn ich direkt mit der RS232-Schnittstelle Spreche wird genau das rausgeschickt was ich schreibe.

Also Werd ichs heut abend mal mit dem ByteArray versuchen.

Teste doch erst einmal ob du die Solltemperatur des FHT's per FHZ setzen kannst, sieht man dann ja (hoffentlich) im FHT Display. O:)
Übrigens, eine kostenpflichtige DLL für Delphie und c kann man hier laden, 21 Tage darf man vorher testen O:) !!
http://www.contronics.de/download.htm
In dem dazu gehörigem PDF steht interessantes drin !

Endlich hab ichs geschafft!!!

Jetzt klappts beim Senden & Empfangen, dasa Problem war:
Wie schon oben Geschrieben:
- Es muss als "Byte-Array" gesendet werden das genau die Große der zu sendenden Bytes behinhaltet.
- Nach dem Senden des ersten Kommandos muß ein wenig (im ms Bereich) gewartet werden, damit die FHZ Zeit hat um die Antwort auf den Port zu geben.

Die nächste Schritte für mich sind ein Kleines TestProgramm:
- 1. Data-Logging in Ein TextFile
- 2. Einbau des FHZ-Protocols, damit zum z.B. Setzen der SollTemp nur noch der Aufruf "SetDemandTemp(DemandTemp as Float)", u.s.w. verwendet werden muß.

Das wird wohl eine Woche brauchen natürlich Stell ichs dann hier zur Verfügung.

Ich denke mal, es muss der oder die Befehle in Hex beim FHZ1000 ankommen, so ist der Text von dir mit dem Byte array gemeint. Den Ausdruck kennt, glaube ich, nur die VB-Gemeinde.
Mein Wunsch wäre es die FHZ1000er über einen µ-Controller zu bedienen. Sprichst du jetzt die FHZ1000 über den USB-Port an, und hast du die DLL von der einfachen Version, oder die prof. Version?

Naja Ich Meinte Närlich ein Array von bytes.
Da ja ein Byte mit dem Wert "C9" (in Hex), in dezimal 201, oder in binär"11001001", ohnehin auf der Schnittstelle dasselbe sein müsste weil es wohl oder übel eh nur in binärer Form übertragen werden kann.
Anders ist es aber Beim String "C9" da ja bei Strings für jedes Zeichen im String der ASCII-Code als Byte rausgeht, was dann - ich Rat mal - "C"=12(Dez) und "9"=9 bedeuten würde.

Standard oder Proffessional-DLL?:
Ich verwende keine von beiden, ich hab ja den Treiber von der www.FTDIChip.com mit dem ich auf die SerielleSchnittstelle rauskann und die DLLs nicht brauche, das Problem ist nur in den DLLs ist das Schnittstellen-Protocol schon implementiert, ich müsste sie mir halt selbst schreiben. Das dürfte "Wenn" das Protocol bekannt ist kein so großes Problem mehr sein.

Microcontroller? vielleicht gibts unter: http://www.cc2net.de
einen Assembler-Treiber der das schon drin hat, FS20 gibts soweit ich weiß schon.
Ich Attach da Mal ein etwas älteres beispiel, die zwar nicht die FHZ1000 verwenden aber im vergleich mit der schaltung mit der du die Serielle schnittstelle angezapft hast dürfte es fast dasselbe wie das Beispiel für den anschluß an den I2C-Bus (bei CControl2).

Jetzt kann ich meine FS20 Empfänger ohne PC Ein- und Aus-schalten.
Gehe als nächstes Projekt mal die FHT's an.
Bisher macht es ein Mega8 über die FHZ1000PC, der wird aber sicherlich für die Zukunft zu klein sein.
Hat jemand ein Bascom oder ASM-Programm für die Empfangs- und Sender- Bausteine der FS20 Serie?
Langfristig möchte ich mit Dallas DS18b20 Temp.-Sensoren und meinem MikroController meine Stellventile ohne FHT's steuern. Koste leider viel Zeit..... ohne die genauen Protokollkenntnisse. Aber es wird schon werden....

Hallo Stromi,

wenn du die FHZ1000pc von einem Microcontroller aus ansteuern willst kannst du mit einem kleinen Hardwareeingriff den FTDI chip umgehen und direkt mit dem PIC sprechen. Hier:
http://www.ipsymcon.de/wiki/index.ph...PC_USB_auf_LAN
hat jemand so ein LAN Interface drangebaut.

viel erfolg,
Amateur

@Amateur
:roll: Habe ich Anfang Dezember auch gepostet, IPsymcon ist überhaupt einen Hinweis wert !

Hallo Stromi,

wenn ich dich richtig verstanden habe möchtest du die Ventilantrieb direkt, ohne FHT80b, mit eigener Hardware ansteuern. Hier:
http://f2.webmart.de/f.cfm?id=277503...&a=1&t=2396388
behauptet jemand das Protokoll zwischen FHT80b und Ventilantrieben geknackt zu haben. Vieleicht könnt ihr euch ja kurzschließen, und das Ergebnis irgendwo posten. Ich wäre brennend interessiert.

Gruß,
Amateur

@alle
Frohes und gesundes neues Jahr wünsche ich.
@Amateur
Ist aber "wunderlich", dass da keine weiteren Post zu sehen ist. Oder soll ich " bezeichnend " sagen?

Hallo ich habe den Artikel hier schon x mal gelesen,aber ich komme noch nicht ganz dahinter,habt Ihr den Pic mit den nötigen Daten über RS232
versorgt oder seit Ihr einen anderen weg gegangen ?
Ich Programiere mit Bascom.Ich moechte ansich nur Funkschalter
mit dem FHZ 100 PC schalten und einen Rauchmelder.
Ich würde mich über eine Antwort freuen.
Gruß raggy