Eigene Hardware mit einbinden

Begonnen von LaserBrenner, 24 Februar 2014, 11:33:27

Vorheriges Thema - Nächstes Thema

LaserBrenner

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

Rince

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 :)
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

jjf

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

LaserBrenner

#3
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ß

LaserBrenner

@Rince

Danke werde ich mir mal anschauen.