Viessmann Vitotronic 200 über USB-Kabel aus Paket Vitoconnect 100 WLAN steuern

[tpm88]

ok trotzdem Danke,
der originale USB Adapter kann aber das gleiche wie die Eigenbauvarianten:
"https://openv.wikispaces.com/Adapter+Eigenbau"

Oder gibt es da Einschränkungen?

Naja - der originale Adapter spricht eben nur USB. Bei den Eigenbauvarianten sind ja auch z.B. LAN-Varianten darunter.

[tpm88]

ich habe nichts in hinsichtlich auf den Gasverbrauch gefunden. Vielleicht lässt sich aus Brennerleistung über die Brennerzeit (Prosa: Brennerleistung pro Zeit = der Gasverbrauch pro Zeit). Dafür müsste man dann aber die Brennerleistung und die Einschaltzeiten des Brenners sehr fein loggen und zuvor für bestimmte Brennerleistungen den Gasverbrauch (über die Gasuhr) messen.

Obwohl die Vitotrol App tatsächlich den Gasverbrauch darstellt habe ich bisher keine Adresse zum Auslesen des Verbrauchs via Optolink gefunden.

Obigen Ansatz von jowo habe ich bei mir seit kurzen umgesetzt. Hier die Eckdaten dazu:

- Auslesen der Heizungswerte via Optolink alle 60 Sekunden
- event-on-change-reading .* für alle Optolink readings
- notify auf das reading Modulation (nicht Brennerleistung)
- bei jeder Änderung des ausgelesenen Modulationsgrades wird via dem notify der Gasverbrauch seit der letzten Änderung berechnet (Funktion in 99_myUtils)
- Berechnung nach folgender Formel (vgl. die Dokumentation zu Vies-sion hier: https://openv.wikispaces.com/Vies-sion)

Code Auswählen Erweitern

Gasverbrauchalt [m³] + Modulationsgrad [%] * Nennleistung [kW] * Zeit [h] / Brennwert [kWh/
m³]
- hierzu habe ich noch einen Dummy definiert, der sich den alten Modulationsgrad für die Berechnung des Delta in einem Reading merkt
- in einem weiteren Reading speichere ich den errechneten Gasverbrauch

Ich denke, die Idee ist rübergekommen. Notfalls kann ich noch Details zur Realisierung beisteuern.

Allerdings muß ich auch erstmal nach ein paar Wochen sehen, wie genau die Berechnung im Vergleich zum Ist-Stand des Gaszählers ist.

[Depechem]

Mit : sudo ls -l /dev/serial/by-id
können die vorhanden USB-Controller auf dem Raspberry Pi angezeigt werden.

Hier:  usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0

Mit dem FHEM Modul VCONTROL und der passenden Config-Datei VScotHO1.cfg (im Forum vorhanden) kann folgendes Define erfolgen:

define Heizung VCONTROL /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 VScotHO1.cfg 600

Das Device Heizung wird angelegt und über die oben ermittelte Schnittstelle werden hier alle 600 Sekunden, anhand der Vorgaben aus VScotHO1.cfg, die entsprechenden Readings gefüllt (BrennerStarts, usw.) -> siehe Foto.

Hallo Jowo,
mein USB-Adapter ist nun da und ich habe ihn laut deiner Anleitung installiert.
Noch zur Info. Ich musste das USB-Kabel mit einem 5m Aktivkabel verlängern(https://www.amazon.de/gp/product/B00AKCS5GE/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1)

Nun folgendes Problem.
Im Log wird nun folgendes angezeigt:

Code Auswählen Erweitern

2017.02.16 11:36:35.231 1: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 disconnected, waiting to reappear (Heizungsanlage)
2017.02.16 11:36:41.482 1: /dev/ttyUSB0 disconnected, waiting to reappear (myJeeLink)

zusätzlich zu dem Opto-USB Kabel ist noch:
- ein "myJeeLink" USB-Stick angeschlossen (PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol) dieser geht seitdem ich das "Opto-USB Kabel" angeschlossen genau so wie das "Opto-USB Kabel" immer wieder im Wechsel in "opend...disconnected..."
- ein "HMUSB" USB-Stick angeschlossen > der funktioniert weiterhin ohne Probleme und ist dauerhaft "opened"

Wenn ich den "myJeeLink USB-Stick" entferne, geht das "Opto-USB Kabel" trotzdem immer im Wechsel in "connected... disconnected... Initialized..."
mit folgender Fehlermeldung im Log:

Code Auswählen Erweitern

2017.02.16 11:42:19.991 1: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 disconnected, waiting to reappear (Heizungsanlage)
2017.02.16 11:42:26.749 1: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 disconnected, waiting to reappear (Heizungsanlage)
2017.02.16 11:42:33.138 1: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 disconnected, waiting to reappear (Heizungsanlage)

An was könnte dies liegen? hattest du oder jenad anders das Problem auch?
meine fhem.cfg sieht so aus:

define Heizungsanlage VCONTROL /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 VScotHO1.cfg 180
attr Heizungsanlage closedev 0
attr Heizungsanlage event-on-change-reading .*
attr Heizungsanlage icon sani_boiler_temp
attr Heizungsanlage room Heizungsanlage

Laut "openv.wikispaces.com" habe ich dieses "VScotHO1_40" Gerät. Zum testen habe die "VScotHO1.cfg" genommen. Readings kommen an, teilweise aber fehlerhaft.
Das hat doch aber grundätzlich nichts mit der Fehlermeldung und dem laufenden "disconnected" zu tun oder?


Ich hoffe ihr könnt mir helfen.
Vielen Dank im voraus
Gruß Thomas

[tilly001]

Schon mal ohne die aktive Verlängerung getestet?

[Depechem]

Schon mal ohne die aktive Verlängerung getestet?

Ja gerade nochmal.
Jetzt nur der direkter USB-Adapter ohne Verlängerung dran. Alle anderen USB-Sticks abgesteckt
"2017.02.16 12:12:48.074 1: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 disconnected, waiting to reappear (Heizungsanlage)"

keine Änderung

[tilly001]

Welchen Raspberry Pi nutzt du?

[Depechem]

Welchen Raspberry Pi nutzt du?

Raspberry Pi 2b

[tilly001]

Probiere mal die USB Geschwindigkeit runter zu setzen auf USB 1.1.

Dazu die Datei /boot/cmdline.txt editieren und den Eintrag

Code Auswählen Erweitern

dwc_otg.speed=1

einfügen oder auf den Wert "1" ändern.

Dann einen Reboot des PI und erneut testen.

[Depechem]

ok kann ich probieren aber dann sind ja alle Ports nur noch 1.1.
Das wäre schlecht.

Sollte ich vieleicht mal das neue Modul "89_VCONTROL300.pm " testen?

[tilly001]

ok kann ich probieren aber dann sind ja alle Ports nur noch 1.1.
Das wäre schlecht.

Das stimmt. Falls aber kein Massenspeicher am Pi hängt, macht das dem Rest: Lacrosse, HM und Co nichts aus ... Die laufen intern alle über eine serielle Verbindung.

Sollte ich vieleicht mal das neue Modul "89_VCONTROL300.pm " testen?

Kannst du natürlich machen. In meiner Konfiguration mit Raspberry Pi Zero läuft das Ursprungsmodul allerdings.
Berichte mal falls du es ausprobierst.

[tpm88]

Bei mir läuft der Viessmann Optolink Adapter an einem RPI (1) Modell B auch ohne Änderung der USB-Ports auf 1.1 ohne disconnects.

Ich setze das VCONTROL300 Modul ein - allerdings remote via ser2net.

ser2net.conf:

Code Auswählen Erweitern

4002:raw:600:/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0:4800 EVEN 2STOPBITS 8DATABITS LOCAL -RTSCTS


Definition in FHEM:

Code Auswählen Erweitern

define Vitodens300 VCONTROL300 <IP>:4002 vcontrol300.cfg 60

Das kannst du natürlich auch lokal einmal auspropieren - dann für die IP einfach localhost 127.0.0.1 einsetzen.

Interessant wäre auch, ob nur das FHEM Modul "disconnected" oder der Optolink-Adapter auch aus Betriebssystemsicht zeitweise verschwindet. Siehst Du denn entsprechende Meldungen in der /var/log/messages ??

[Depechem]

Bei mir läuft der Viessmann Optolink Adapter an einem RPI (1) Modell B auch ohne Änderung der USB-Ports auf 1.1 ohne disconnects.

Ich setze das VCONTROL300 Modul ein - allerdings remote via ser2net.

ser2net.conf:

Code Auswählen Erweitern

4002:raw:600:/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0:4800 EVEN 2STOPBITS 8DATABITS LOCAL -RTSCTS


Definition in FHEM:

Code Auswählen Erweitern

define Vitodens300 VCONTROL300 <IP>:4002 vcontrol300.cfg 60

Das kannst du natürlich auch lokal einmal auspropieren - dann für die IP einfach localhost 127.0.0.1 einsetzen.

Interessant wäre auch, ob nur das FHEM Modul "disconnected" oder der Optolink-Adapter auch aus Betriebssystemsicht zeitweise verschwindet. Siehst Du denn entsprechende Meldungen in der /var/log/messages ??

ok Danke das werde ich gleich mal testen.
hier der Message log!?

[tpm88]

Die gesamte messages Datei hilft nur sehr bedingt - ohne zu wissen, zu welchen Zeiten genau du die disonnects/reconnects beobachtest hast.

idProduct ermitteln:

Code Auswählen Erweitern

lsusb
root@rpi1:/var/log# lsusb
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 004: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. LAN9500 Ethernet 10/100 Adapter / SMSC9512/9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Seit dem letzten reboot kannst Du so ermitteln, wie oft Linux den USB-Adapter erkannt neu erkannt hat:

Code Auswählen Erweitern

root@rpi1:/var/log# dmesg | grep ea60
[    2.228589] usb 1-1.2: New USB device found, idVendor=10c4, idProduct=ea60

=> d.h. bei mir nur 1x

Ich bin mir gerade nicht sicher, ob der 10c4:ea60 oder der 0403:6001 der Optolink Adapter ist.

[Depechem]

Also irgend etwas läuft hier nicht so wie es soll...

ser2net habe ich eingerichtet und mit vcontrol300 verknüpft.
nach 3-4 min hängt sich fhem dann immer auf...
(alle USb-Sticks vorher abgesteckt das nur der Opto-USB dran ist)

normales vcontrol wieder installiert und mit ser2net verknüpft
fhem läuft ohne abzuschmieren
Readings kommen nach einer Weile an.

dafür bleibt nun mein "myJeeLink" USB Stick" dauerhaft im "initialized" < funktioniert somit nicht mehr
2017.02.16 14:24:13.005 1: /dev/ttyUSB0 disconnected, waiting to reappear (myJeeLink)

entweder die beiden vertragen sich nicht untereinander oder ich weis auch nicht.(HM-USB-Stick und myJeeLink funktionieren doch auch beide super!?)

jetzt läuft gerade der Opto sehr gut mit den Readings-aktualisierungen dafür bleibt der myJeeLink komplett im initialized.
Nach einem Neustart kann es wieder genau anders herum sein

Also wie gesagt ich kann bis jetzt noch nicht bestätigen das der originale Opto-USB Stick ordentlich läuft

habt ihr noch ideen?

[tpm88]

Also irgend etwas läuft hier nicht so wie es soll...

ser2net habe ich eingerichtet und mit vcontrol300 verknüpft.
nach 3-4 min hängt sich fhem dann immer auf...
(alle USb-Sticks vorher abgesteckt das nur der Opto-USB dran ist)

Die Glaskugel ist gerade kaputt 
Soll heißen, ohne Log (verbose=5), Fehlermeldung etc. wird es schwierig, da zu helfen.

normales vcontrol wieder installiert und mit ser2net verknüpft
fhem läuft ohne abzuschmieren
Readings kommen nach einer Weile an.

dafür bleibt nun mein "myJeeLink" USB Stick" dauerhaft im "initialized" < funktioniert somit nicht mehr
2017.02.16 14:24:13.005 1: /dev/ttyUSB0 disconnected, waiting to reappear (myJeeLink)

entweder die beiden vertragen sich nicht untereinander oder ich weis auch nicht.(HM-USB-Stick und myJeeLink funktionieren doch auch beide super!?)

Das ser2net war nur eine Idee - ist natürlich bei einer lokalen Installation (Optolink Adapter und FHEM gemeinsam) nicht notwendig.
Welcher der Adapter hat denn aktuell /dev/ttyUSB0 ?? (das ist nicht deterministisch!!)
Ich würde auch den JeeLink über /dev/serial/byid/<richtiger JeeLink Adapter> definieren.

jetzt läuft gerade der Opto sehr gut mit den Readings-aktualisierungen dafür bleibt der myJeeLink komplett im initialized.
Nach einem Neustart kann es wieder genau anders herum sein

Eben! Die /dev/ttyUSB<n> werden beim Booten nicht immer gleich vergeben. Du kannst da ggf. auch mit udev - Rules experimentieren. Aber zumindest Optolink und Jeelink können eineindeutig via /dev/serial/byid/... definiert werden.

Also wie gesagt ich kann bis jetzt noch nicht bestätigen das der originale Opto-USB Stick ordentlich läuft

Hier läuft der Viessman Optolink-Adapter seit 4 Wochen problemlos. Daran liegt es sicher nicht.

Weitere Ideen: Stromversorgung RPI, aktiver USB-Hub (??), falls die USB-Geräte zuviel Strom ziehen..., closedev Parameter, ...

Bitte systematisch bei der Fehlersuche vorgehen. Wildes An- und Abstecken der USB-Sticks und Wechsel der Module führt sicher nicht zum Ziel...