-
Notifications
You must be signed in to change notification settings - Fork 4
Home
Welcome to the optolink-splitter wiki!
ich fang einfach erstmal zu schreiben an, strukturiert wird später...
Der Optolink-Switch wird erstmal zwischen Optolink-Gerät und das Vitoconnect geschaltet. Ein Vitoconnect ist nicht notwendig, wenn nicht mit dem Viessmann Cloud Server kommuniziert werden soll, dann wird einfach nur der Optolink-Kopf mit dem OL-Switch verbunden.
Dazu kann der originale Viessmann Optolink Kopf mit USB Stecker (7856059) benutzt werden, aber auch jeder selbstgebaute Adapter (ich probier demnächst mal, ob die Volkszählerköpfe für 8€ auch gehen).
Damit das mit dem Vitoconnect funktioniert, muss der USB Adapter einen CP2102 Chip haben! Mit dem kann das Vitoconnect umgehen. FTDI oder andre Chips funktionieren wahrscheinlich nicht.
Das Ganze wird physisch am besten mit einem Raspi realisiert. Der hat sogar 2 UARTs, d.h. man kann beide Seiten mit TTL (3.3V) machen, wenn man z.B. einen Optolinkkopf ohne USB hat. Der Link zu Vitoconnect endet wahrscheinlich eh auf TTL, z.B. hiermit. Weil das gleich 3 sind, kann man natürlich auch einen zweiten nehmen, um da wieder USB draus zu machen ;-) Der Raspi hat dann auch gleich WLAN und LAN, was für die weiteren Verbindungen 'praktisch' ist.
Aktuell sind MQTT und Ascii- oder Hex-Strings über TCP/IP in der Pipeline. Eingebaut ist auch eine Polling Liste, mit der die gelisteten Datenpunkte zyklisch ausgelesen und auch gleich an den MQTT Broker gepostet werden. Nebenbei können diese gepollten Werte auch in eine csv Datei für Viessdata geschrieben werden, dann muss Viessdata nicht die ganze Zeit laufen, und man hat trotzdem die gewohnte Grafik da drin. Sowas kann man sich natürlich auch aus den den MQTT geposteten Daten basteln.
Die Lese- oder Schreib-Anfragen werden im einfachsten Fall sozusagen in Klartext formuliert:
- read;<Datenpunktadresse>;<Anzahl Bytes>[;<Skalierung>[;<vorzeichenbehaftet>]]
- write;<Datenpunktadresse>;<Anzahl Bytes>;<Wert>[;<Skalierung>;[<vorzeichenbehaftet>]]
Vornehmich für 'Maschinenkommunikation', z.B. zur Kompatibilität mit Programmen, die früher das Optolinkprotokoll über die serielle Schnittstelle realisiert haben, gibt es die raw Variante
- raw;<Optolink-Telegram-Daten-Hex-String>
und für 'spezielle Aufgaben' gibt es noch die 'full-raw' Variante
- <Optolink-Telegram-Daten-Hex-String>
Die full-raw Variante hat den Nachteil, dass das Ende des Antwort-Telegrams mittels einer 'Ruhe-seit-letztem-Empfang-Zeit' oder eines Timeouts bei garkeiner Antwort identifiziert wird. Die Kommunikaion ist also langsamer als mit einer Identifikation des Telegramm-Endes anhand formaler Kriterien und verzögert entsprechend den gesamten Ablauf. Dafür müsste damit auch das ältere KW Protokoll und das ganz alte GWG Protokoll gehen (nicht getestet)
Die Antwort {beschreibe ich dann morgen...}