Hallo alle zusammen,
ich bin neu hier und habe mich auch schon ein wenig umgeschaut. Fhem scheint eine gute Grundlage für mein vorhaben zu sein aber ich habe da noch eine Frage zum Leistungsumfang von FHEM wozu ich trotz Suche keine Antwort gefunden habe. Vielleicht könnt Ihr mir diese Frage beantworten?
Ich habe in meinen Haus selbst entwickelte Hardware in betrieb die per RS485 (also Comm Schnittstelle an FHEM-Server) kommunizieren und ein eigenes Protokoll verwenden, ist es möglich so was in FHEM mit einzubinden und wenn ja gibt es irgendwo hier ein Beispiel Projekt damit ich mir mal anschauen kann wie so was eingebunden wird und auf was ich so achten muss?
vielen Dank und Gruß
Matthias
Hi,
hilfe dazu findest du im Developper Bereich und im Wiki.
http://www.fhemwiki.de/wiki/DevelopmentIntroduction
http://www.fhemwiki.de/wiki/DevelopmentGuidelines
Das was du willst, nennt sich hier "Modul".
Wenn du mal auf deinen fhem Server schaust, findest du im fhem Verzeichnis ziemlich viele Dateien mit der einer Zahl vorne weg und der Endung pm.
Die kannst du theoretisch alle als Beispiel betrachten.
Ich würde aber zunächst mal in die commandref einen Blick riskieren. Dort schmöker mal rum, was die Module so tun. Und wenn du eines gefunden hast, welches deinem ähnlich ist, dann würde ich dieses mal einer genaueren Prüfung unterziehen :)
Hallo,
kann man mehr von deinem RS485 Protokoll erfahren?
Ich habe sowas auch in Benutzung, allerdings noch nicht mit FHEM
(eine Version mit 9Bits).
Vorteile von RS485:
- Netzwerkfähig
- Störanfälligkeit
- Leistungsverbrauch (<< eth)
Joachim
Ja na klar.
in groben:
Physikalische Schnittstelle
Die Datenübertragung zwischen dem Master (PC / CPU) und der Bordcomputer-ECU
erfolgt über ein serielles Interface, welches über eine USB-Schnittstelle als virtueller
COM-Port bzw. über ein RS485-Interface ansprechbar ist. Die Datenübertragung erfolgt
im Half-Duplex-Betrieb mit folgenden Parametern:
• Bitrate: 38400 bps
• 8 Datenbits
• 1 Stop-Bit
• Keine Parität
Alle Daten werden im Big-Endian Format übertragen.
Buszugriff
Der Buszugriff ist durch ein Single-Master Verfahren geregelt, wobei der PC / CPU als Master und die Bordcomputer als Slave verwendet wird.
Eine Antwort des Slaves erfolgt auf eine Anfrage des Masters nur dann wenn alle der
folgenden Bedingungen zutreffen:
• Das Paket wurde von der Transportschicht richtig und vollständig empfangen
(Überprüfung von Startkennung und Checksumme)
• Die vollständige Empfangs-Adresse stimmt mit der eigenen Modul-Adresse überein und ist keine Broadcast-Adresse
Bei einer Anfrage des Masters mit einer Broadcast - Adresse werden alle Slaves
angesprochen und verarbeiten das empfangene Paket. Es erfolgt keine Antwort!
Paket-Aufbau
Ein Datenpaket besteht aus einem Header, den zu übertragenden Nutzdaten und einem Trailer. Tabelle 1 zeigt den Aufbau eines Pakets.
• Der Header beinhaltet eine Startkennung (0xFF), die Protokollversion
und die Ziel- und die Quelladresse (je 1 Byte)
• Die Nutzdaten beinhalten die Länge der Kommandoparameter (2 Byte), das Kommando (1 Byte) und die Kommandoparameter (Länge der
Kommandoparameter hängt vom Kommando ab).
• Der Trailer beinhaltet die Checksumme. Die Checksumme entspricht der Summe aller Nutzdaten inklusive Quell- und Zieladresse. Ergibt die Checksumme 0xFF, so ist 0x00 zu verwenden.
1B | 1B | 1B | 1B | 2B | 1B | n-B | 1B
0xFF | Ver. | DEST_ADDR | SRC_ADDR | PARAM_LEN | CMD | PARAM | CS
Header------------------------------------------ Data------------------------------- Trailer
Tabelle 1: Paketaufbau
Startkennung (0xFF) und Version (V)
Beinhalten zwei aufeinander folgende Bytes die Werte 0xFF und 0x20 (aktuelle Version des Protokolls), so werden diese als Startkennung eines Pakets interpretiert.
Zieladresse ((DEST_ADDR), Quelladresse (SRC_ADDR)
Für die Empfangs- und Sendeadresse ist je 1 Byte vorgesehen.
Adresse Bedeutung
1 Bordcomputer-ECU
254 Master (PC / CPU)
Kommando (CMD)
Eine Liste aller Kommandos mit einem Verweis auf die entsprechenden
Kommandoparameter für Anfrage bzw. Antwort findet sich in Punkt 2.
CMD Bedeutung
66 Bordcomputer-Abfrage
Länge der Kommando-Parameter (PARAM_LEN) und Kommando-Parameter
(PARAM)
Bei Verwendung der meisten Kommandos müssen zusätzlich zum eigentlichen
Kommando (1Byte) Kommandoparameter übertragen werden. Die Länge der Kommando-Parameter hängt vom Kommando ab.
Checksumme (CS)
Das auf die Nutzdaten folgende Byte enthält die Checksumme der Nutzdaten. Die
Checksumme entspricht der Summe aller Nutzdaten inklusive Quell- und Zieladresse. Ergibt die Checksumme 0xFF, so ist 0x00 zu verwenden.
(modulo 256)
Beispiel-Abfrage
eine abfrage des Bordcomputers sieht z.B. so aus (in HEX):
FF 20 01 FE 00 02 66 42 10 B9
FF = Startkennung
20 = Version des Protokolls
01 = Zieladresse Bordcomputer-ECU
FE = Quelladresse PC
00 02 = Länge der Parameter (2 Stück)
66 = Kommando
42 10 = Parameter
B9 = Checksumme (01 FE 00 02 66 42 10 = 1B9 mod 256 = B9)
Fehler Meldung:
Array z.B. Werte
Start 0hFF 0Byte 255
Version 0h20 1Byte 32
Ziel 0h01 2Byte 1
Quelle 0hFD 3Byte 254
Länge anzahl der Para. 4Byte 0
5Byte 2
CMD Kommando 6Byte ?
Param.0 Fehler 7Byte 252
Param.1 Grund 8Byte ?
Checks. modulo 256 9Byte ?
Fehler Grund:
0h00 0 Kein besonderer Fehler
0h01 1 Unbekanntes Kommando
0h02 2 Ungültige Parameter
0h04 4 Fehler beim Zugriff auf EEPROM
0h05 5 Kommando nicht erlaubt
0h0A 10 Applikation fehlerhaft
0h0C 12 Bootloader fehlerhaft
gruß
@Rince
Danke werde ich mir mal anschauen.