An dieser Stelle möchte ich ein paar zusätzliche Informationen zur Verwendung eines TWC mit cFos veröffentlichen. Zusammengetragen von mir und einem weiterem User, danke an D.A. dafür!

• wie in hier beschrieben funktionieren nur TWC Gen2, es funktionieren aber bis zu 3 Stück (theoretisch zumindest (ich habe bei mir 2 TWC an einem PowerBrain am laufen, mehr nicht getestet)
• alle TWC – Kodierdrehschalter müssen auf Position „F“ (=Slave) stehen, weil die PB/CM/Booster ja der Master ist
• an einem Seriellen Anschluss können neben einem (oder mehreren) TWC *keine* anderen Geräte (wie zum Beispiel Modusbuszähler) angeschlossen werden 
• Das PB bzw. CM oder Booster, an dem die TWC angeschlossen sind muss im Lastmanagement der Master sein (diese Aussage ist nicht ganz sicher, es ist schon lange her, als ich das eingerichtet und probiert hatte)
• Funktion „finde TWC“ funktioniert nur wenn je EIN TWC angeschlossen ist (wenn keine ID gefunden: Adern A/B bzw. D+/D- gegeneinander tauschen)
• Bei der Konfiguration der Wallbox in der Oberfläche im Feld Adresse „Com1,XXXX“ (XXXX ist die ID des TWC) eintragen
• Abschlusswiderstände 120Ohm verwenden
• Ladepunktlizenz muss vorhanden sein (im Lieferumfang sind 2 oder 3 Lizenzen dabei) 
• es treten etliche Kommunikationsfehler auf – diese sind leider „normal“, prinzipiell funktioniert es aber auch mit den angezeigten Fehlern (allerdings keine 100% zuverlässigkeit) , dabei ist egal, ob man einen Raspi mit dem CM oder ein Powerbrain verwendet.
  Beispiel Kommunikationsfehler:
• Man beachte die bisher geladene Energiemenge von mehr als 10 Gigawattstunden. Ich fürchte, ich muss einen Kredit aufnehmen 😉 –> Eigenen Zähler verwenden und verknüpfen! 
• Die VIN bei Tesla-BEVs wird mitunter nur in Teilen empfangen. Wenn man diese wie vorgesehen als PIN für die Autorisierung nutzt, dann ggfs. mehrere unterschiedliche PINs (also die verschiedenen Varianten der abgeschnittenen VIN) für den jeweiligen User eintragen. So erhöht man die Wahrscheinlichkeit, dass eine Variante dann greift und das Laden autorisiert.

Folgendes nur bei Verwendung eines Raspis:

• ggfs. eine udev-Regel anlegen, damit der USB-RS485 immer den gleichen Device-Alias bekommt. Dazu mit lsusb die Hersteller- und Produkt-ID ermitteln und in z.B. /etc/udev/rules.d/10-cfos-cm.rules einfügen. Nach dem nächsten Anstecken oder auch nach einem reboot bekommt der RS485 Adapter dadurch zuverlässig immer den gleichen Namen (im Beispiel hier „/dev/twc-modbus“)
  • root@cfos-ChargingManager:/# lsusb
  • Bus 001 Device 004: ID 2458:0001 Bluegiga Technologies BLED112 Bluetooth 4.0 Single Mode Dongle
  • Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
  • Bus 001 Device 006: ID 0424:7800 Microchip Technology, Inc. (formerly SMSC)
  • Bus 001 Device 003: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
  • Bus 001 Device 002: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
  • Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  • root@cfos-ChargingManager:/# more /etc/udev/rules.d/10-cfos-cm.rules
  • ACTION==“add“,ATTRS{idVendor}==“0403„, ATTRS{idProduct}==“6001„, SYMLINK+=“twc-modbus„, GROUP=“dialout“, MODE=“0666″
  • root@cfos-ChargingManager:/# ls -la /dev/twc-modbus
  • lrwxrwxrwx 1 root root 7 Jun 26 12:55 /dev/twc-modbus -> ttyUSB0
  • root@cfos-ChargingManager:/
• In der com-Port-Zuordnung im Konfigurationsmenü des CM dann bei COM1 den gewählten Namen eintragen (Das gibt es übrigens im CM-Kit bzw. Booster sowie m.E. auf der Wallbox nicht, da dort der _integrierte_ RS485 immer COM1 ist):