Modul zur Anbindung Viessmann Heizung (Vitotronic 200 KW1)

[olli84]

Hab jetzt wieder einige Probleme.

Habe einen "Server"-Umzug hinter mir, Raspi raus, richtiges Ubuntu 14.04 Server rein. Das ganze läuft auf nem älteren Centrino Notebook mit 2 USB2.0 Buchsen.

Ich habe die define Zeile händisch in FHEM eingetragen - wenn ichs oben eintippe schmiert mir FHEM komplett ab.

Per Konsole sehe ich solche hübschen Sachen:

Code Auswählen Erweitern


[  282.376285] usb 2-2: USB disconnect, device number 5
[  282.376460] ftdi_sio ttyUSB1: error from flowcontrol urb
[  282.376768] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[  282.376794] ftdi_sio 2-2:1.0: device disconnected
[  282.620105] usb 2-2: new full-speed USB device number 6 using uhci_hcd
[  282.813584] usb 2-2: New USB device found, idVendor=0403, idProduct=6001
[  282.813594] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  282.813602] usb 2-2: Product: FT232R USB UART
[  282.813609] usb 2-2: Manufacturer: FTDI
[  282.813616] usb 2-2: SerialNumber: A70377TQ
[  282.820649] ftdi_sio 2-2:1.0: FTDI USB Serial Device converter detected
[  282.820726] usb 2-2: Detected FT232RL
[  282.820734] usb 2-2: Number of endpoints 2
[  282.820741] usb 2-2: Endpoint 1 MaxPacketSize 64
[  282.820747] usb 2-2: Endpoint 2 MaxPacketSize 64
[  282.820754] usb 2-2: Setting MaxPacketSize 64
[  282.822687] usb 2-2: FTDI USB Serial Device converter now attached to ttyUSB1
olli@ubuntu:~$ sudo /etc/init.d/fhem stop
Stopping fhem...
olli@ubuntu:~$ sudo /etc/init.d/fhem start
Starting fhem...
olli@ubuntu:~$ Can't call method "close" on an undefined value at ./FHEM/89_VCONTROL.pm line 371.


Jemand ne Idee? Nach der letzten Meldung muss ich FHEM wieder stoppen und starten, usw. - endlose Schleife. Ausser natürlich ich entferne die define Zeile aus der FHEM.cfg

[olli84]

Nur kurz zur Info, wenn jemand die gleichen Probleme wie ich hat:

Nachdem ich die LAN-USB-Verlängerung gegen ein aktives USB Kabel in 10 Meter Länge ausgetauscht habe - läuft alles. 

[zap]

@kvo1: Man macht auch kein Datenlogging auf eine SD-Karte mit Betriebssystem ! Temporär auf eine RAMDisk, permanente Logs via Netzwerk irgendwo anders hin (z.B. USB-Stick an einer Fritzbox).

LG

pah

Kann ich jetzt nicht nachvollziehen. Man bzw. ich mache Datenlogging auf meinen Raspis schon seit Jahren auf die interne SD. Vielleicht hat FHEM ja damit Probleme, andere Anwendungen jedenfalls nicht (z.B. Meteohub mit echt exzessivem Wetterdaten-Logging auf die interne SD). Oder es liegt an der 2,50 € SD von Aldi 

[krakel]

Hallo allerseits,
ich habe mir einen Optokoppler nach der Bauanleitung von ReinerZ, die er bei openv veröffentlicht hatte, nachgebaut. Der LANTRONIX-Baustein ist über WEB-Interface ansprechbar und entsprechend konfiguriert. Allerdings zeigt mir FHEM nach dem "define Vito200 VCONTROL IP:10001 99_VCONTRO.cfg 180"  folgendes:

2015.02.04 17:18:01 3: VCONTROL: Define open DATEI '99_VCONTRO.cfg'
2015.02.04 17:18:01 3: VCONTROL: open DATEI '99_VCONTRO.cfg'
2015.02.04 17:18:01 3: VCONTROL: DATEI '99_VCONTRO.cfg' refreshed
2015.02.04 17:18:01 3: VCONTROL opening VCONTROL device IP:10001
2015.02.04 17:18:01 3: Opening Vito200 device IP:10001
2015.02.04 17:18:01 3: Can't connect to IP:10001: Das Argument ist ungültig

Ich bin mir jetzt nicht sicher, welcher Port anzusprechen ist und ob überhaupt noch das Modul 99_VCONTRO.cfg richtig ist. Gab es da nicht eine Namensänderung?
Hat denn einer eine funktionierende Konfiguration mit diesem LAN/RS232-Adapter? Wie sieht da die Konfiguration aus?
FHEM ist auf folgendem Stand: # $Id: fhem.pl 7358 2014-12-29 16:03:31Z rudolfkoenig. Ich kann leider nicht weiter updaten, da ich sonst keine Verbindung mehr zum HM485-Lan-Gateway bekomme - der Dämon HM485d startet mit aktuellen Versionen nicht mehr.

Vielen Dank für die Hilfe!
Rainhard

[krakel]

Hallo nochmal,
ich war wohl leider etwas ungeduldig, habe den Fehler gefunden: Man sollte natürlich die IP-Adresse des LANTRONIX mit angeben, also "define Vito200 VCONTROL 192.168.178.229:10001 99_VCONTRO.cfg 180" hat das Gerät geöffnet und initialisiert. Nun muss ich erst einmal schauen, welche Konfiguration ich für mein Gerät benötige. Danke nochmals. Ich melde mich wieder.

Rainhard

[funclass]

Hallo,

hier mal eine Status von mir.

olli84 und Reiner haben wohl beide ein ähnliches Problem. Einer mit USB und einer mit einer LAN Version des optolink Adapters.
Beide auf einem RPI unterwegs.

Wenn das Device disconnected ist kommt es zu keinem sauberen reconnect. FHEM hängt sich auch auf. 

Ich habe das eben mal im Keller bei mir mit USB und Windows getestet. Da funktioniert es. 

Tja habe jetzt mal versucht eine Version zu bauen, die aussieht wie andere Module auch,
mit reinen DevIO Aufrufen. (Die scheint bei Reiner auch zu funktionieren (ätere Version))

Damit habe ich auf Windows aber das Problem, dass sich mein FHEM aufhängt 

Tja da scheinen die DevIO-Routinen nicht plattformunabhängig genug zu sein.

Ich werde es heute definitiv nicht schaffen da eine vernünftige Version zu bauen.
Werde mich aber in den nächsten Tagen damit weiter beschäftigen!
Sobald ich eine Version habe mit der ich glücklich bin, werde ich sie hier zum Test posten!

Gruß
Adam

Ich habe genau die gleichen Probleme. Eine Weile lang lief mein FHEM mehrere Tage am Stück durch. In letzter Zeit jedoch stürzt es regelmäßig (ca. 1-2 mal täglich) ab da VCONTROL die Verbindung zu /dev/ttyUSB0 verliert. Betreibe FHEM auch auf einem Rpi B. Gibt es schon neue Erkenntnisse oder Lösungsansätze?

Seit ca. einem Monat logge ich mit einem weiteren Optoadapter (Volkszähler) meinen Stromverbrauch, dort habe ich keinerlei Probleme.

Noch eine Frage zum Modul: das Disable-Attribut schein keine Auswirkung auf das Verhalten zu haben. Gibt es eine Einfache Möglichkeit das Device "stillzulegen" ohne es komplett löschen zu müssen? Das würde mir helfen die Abstürze temporär zu vermeiden.

VG Christian

[salvadore]

Hi funclass,
ich hatte genau wie viele anders auch das Problem. Zuletzt habe ich den RPi dann ausgetauscht gegen ein APU-Board, welches mit allen angeschlossenen USB Geraeten einwandfrei funktioniert. (ging aber auch schon mit BeagleBoneBlack 100%ig).
Irgendwo meine ich etwas über einen neuen FTDI-Treiber gelesen zu haben, vielleicht geht es ja dann.

Salvadore

[olli84]

habe mich das letzte mal auch zu früh gefreut - nachdem es 1-2 Tage wunderbar läuft empfängt es dann irgendwann keine Daten mehr. es gibt aber keinerlei usb aufhänge o.ä. - es kommt einfach nichts mehr an!

Sobald ich in die def gehe, das Modul reloade o.ä. funktioniert alles wieder - für 1-2 tage.

Ich hab mir nun überlegt einen watchdog zu basteln, der merkt wenn die letzte reading Änderung zu lange her ist. sobald die länger wie 5 Minuten (hab 180 Sekunden zum aktualisieren drin) ausbleibt soll der watchdog das Modul reloaden - jemand eine Idee hierfür? ich kenn mich damit zu wenig aus...

grüßle,
Olli

[Adam]

Hallo zusammen,

also das aktuelle Modul öffnet, schliesst und reconnected identisch zu den anderen FHEM Modulen.
Es werden reine FHEM DevIO Routinen genutzt.
Habe jetzt verstanden, dass bei Reiner LAN auf Linux und bei mir USB auf Windows und auch bei anderen USB auf Linux keine Abbrüche passieren,
bzw. reconnects möglich sind.

Wenn keine Daten mehr geliefert werden, kann das Modul natürlich nicht mehr reagieren.
Weiss nicht so genau wie ich das einschränken soll, wenn es auch noch Treiber Probleme sind.
Habe jetzt von einigen gelesen und so war es bei mir auch, dass eine USB -> LAN -> USB Umsetzung unzuverlässig ist.
Reine USB Verbindung dagegen sehr stabil läuft.

Wie gesagt, ich weiss nicht genau wo ich ansetzten soll.

Noch eine Frage zum Modul: das Disable-Attribut schein keine Auswirkung auf das Verhalten zu haben. Gibt es eine Einfache Möglichkeit das Device "stillzulegen" ohne es komplett löschen zu müssen? Das würde mir helfen die Abstürze temporär zu vermeiden.

Ja disable, war noch nicht richtig implementiert, bin gerade beim Test, werde es gleich einchecken!

Sobald ich in die def gehe, das Modul reloade o.ä. funktioniert alles wieder - für 1-2 tage.

Ich überlege, ob ich über ein Attribut, so ein reload nicht intern einmal pro Tag machen könnte!? Muss ich mir mal anschauen.
Wird beim reload das Device komplett gelöscht und wieder angelegt?
Was ist da in fhem im Log zu sehen?

Adam

[Adam]

Ich überlege, ob ich über ein Attribut, so ein reload nicht intern einmal pro Tag machen könnte!? Muss ich mir mal anschauen.

Also ich glaube, der Knackpunkt ist, dass die Initialisierung nochmals durchlaufen wird und der Heizung dann noch mal ein 0x04 Byte zum Start gesendet wird.
Bei einigen Heizungen oder aber Verbindungen scheint das wohl nur ein einziges mal notwendig zu sein, bei anderen halt öfter oder jedesmal.

Ich hänge hier mal eine Test Version ran, die folgendes beinhaltet:

Attribut: init_every_poll:0,1

Wenn Ihr das Attribut init_every_poll auf 1 setzt, so wird jedesmal vor einem Poll Zyklus das 0x04 Byte gesendet.

Bitte einmal ausprobieren, ob das genügt, oder ob man tatsächlich auch noch vor jedem Wert so ein Init machen muss.

In der Hoffnung Euch weiterhelfen zu können,
Adam

[olli84]

Hallo Adam,

ich habe ja mittlerweile auch eine reine USB Lösung (zwar mit 10m aktivem Kabel, aber okay) - usb disconnects habe ich ja auch nicht mehr.

Habe grade nur das problem, das sogar nur noch einmal abgerufen wird - danach nicht mehr. Zeit ist auf 180 Sekunden eingestellt.

Mit deine Update siehts so aus:

Code Auswählen Erweitern

2015.02.08 19:34:15 5: SW: 04
2015.02.08 19:34:15 3: VCONTROL: Initialization
2015.02.08 19:34:15 4: VCONTROL: Start of Poll !
2015.02.08 19:34:15 5: VCONTROL: set InternalTimer to 1423420635.44583
2015.02.08 19:37:15 5: SW: 04
2015.02.08 19:37:15 3: VCONTROL: Initialization
2015.02.08 19:37:15 4: VCONTROL: Start of Poll !
2015.02.08 19:37:15 5: VCONTROL: set InternalTimer to 1423420815.44981

Sobald ich die DEF anklicke (die wie folgt aussieht) und auf "modify Vito200" drücke ruft das Modul wieder die Daten ab.

Code Auswählen Erweitern

/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A70377TQ-if00-port0 V200KW1.cfg 180


Edit: Nach dem erneuten DEF steht mit Verbote 5 folgendes in der log:

Code Auswählen Erweitern

2015.02.08 19:39:03 3: VCONTROL: Define open DATEI 'V200KW1.cfg'
2015.02.08 19:39:03 3: VCONTROL: open DATEI 'V200KW1.cfg'
2015.02.08 19:39:03 3: VCONTROL: DATEI 'V200KW1.cfg' refreshed
2015.02.08 19:39:03 3: VCONTROL opening VCONTROL device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A70377TQ-if00-port0
2015.02.08 19:39:03 3: VCONTROL opened VCONTROL device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A70377TQ-if00-port0
2015.02.08 19:39:03 5: SW: 04
2015.02.08 19:39:03 3: VCONTROL: Initialization
2015.02.08 19:39:03 5: VCONTROL set InternalTimer +1 to 1423420744.78992


Danke für alles,
gruß,
olli

[Adam]

Das Attribut disable wird nun in dieser Version auch ausgewertet.
Kann das sein, dass es bei Dir nicht auf 0 steht!?

[olli84]

war bei mir gar nicht definiert. Habs nun mal mit 0 nachgeholt.

Ausserdem hab ich die def nochmal auf dev/ttyUSB1 umgeschrieben, vielleicht hilft das auch. 

[Adam]

noch eine andere Version wo nur das 0x04 gesendet wird und nicht die ganze Init Routine durchlaufen wird!

[olli84]

hab auch die probiert. Gleiches Problem. Danke für deine Geduld, ich würde wahrscheinlich ausflippen.

Nur wenn ich im def bin, auf save config drücke o.ä. läuft die Abfrage durch. Kann es sein das es am

Code Auswählen Erweitern

2015.02.08 20:09:33 3: VCONTROL: DATEI 'V200KW1.cfg' refreshed
2015.02.08 20:09:33 3: VCONTROL opening VCONTROL device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A70377TQ-if00-port0
2015.02.08 20:09:33 3: VCONTROL opened VCONTROL device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A70377TQ-if00-port0

1. refresh der config datei oder
2. am erneuten port opening liegt? Schliesst mein System vielleicht einfach die Verbindung nach einer Abfrage und das VCONTROL merkt es irgendwie nicht?