Überarbeitetes Modul 89_VCONTROL.pm / ESP8266 WiFi-Interface

Begonnen von renemt, 21 März 2016, 17:56:33

Vorheriges Thema - Nächstes Thema

renemt

Hallo zusammen,

Ich bin René - und das ist mein erster Beitrag im FHEM-Forum :) Beruflich bin ich im IT-Bereich unterwegs und habe einen Hintergrund als Entwickler.

Privat bastle ich gerade an der Ansteuerung meiner Heizung (Vitodens 300 mit Vitotronic 200) per FHEM/VCONTROL über einen ESP8266 als WiFi-UART-Bridge. D.h. die Anbindung erfolgt per WLAN. Die Optolink-Hardware werde ich gemäß der Anleitungen im openv-Wiki bauen.

Der ESP8266 läuft derzeit als Vitotronic-Mock. D.h. er tut so, als wäre er eine Vitotronic und reagiert auf Kommandos gemäß dem Protokoll. So kann ich in FHEM bereits Pseudo-Temperaturwerte etc. pollen. Die Verbindung von FHEM mit VCONTROL zum ESP per WLAN läuft also schon mal.

Bei der Arbeit fiel mir allerdings ein Problem mit dem Modul 89_VCONTROL.pm auf: Wenn der "Sender" (d.h. der ESP8266) zwischendurch offline geht, weil z.B. die WLAN-Verbindung abreißt, dann kann VCONTROL nie wieder Daten pollen. Auch ein setzen des Attributs "init_every_poll" brachte keine Abhilfe.

Daraufhin habe ich mir den Code angesehen und festgestellt, dass in mehreren Funktionen anscheinend beim Einpflegen der LAN-Anbindung Dinge vergessen wurden oder durcheinander gekommen sind. Daraufhin habe ich


  • den Code neu formatiert, so dass zusammen gehörende Klammern bei "if"-Statements etc. leichter zu erkennen sind,
  • das Flag $LAN_HW in $TCP_CONNECTION umbenannt - denn der Zugriff kann ja transparent über jedes Medium erfolgen, solange eine TCP-Verbindung zu <SERVER>:<PORT> hergestellt werden kann
  • alle Stellen, an denen eine Unterscheidung zwischen USB- und TCP-Verbindung durch Prüfung auf einen Doppelpunkt im Device-Name erfolgte, auf Nutzung des $TCP_CONNECTION-Flags umgebaut
  • in der FunktionVCONTROL_Read einen Zweig für das Schließen der TCP-Verbindung eingebaut, wenn das Attribut "closedev" gesetzt ist (vorher wurde dort nur USB berücksichtigt)
  • VCONTROL_ReInit ebenfalls um die Logik für TCP-Connections ergänzt

Praktisches Ergebnis: Wenn "init_every_poll" gesetzt wird und die TCP-Verbindung zwischenzeitlich verloren geht verbindet sich VCONTROL jetzt erneut, wenn die Verbindung wieder da ist - und pollt dann auch wieder Daten.

Frage: Ich könnte mir vorstellen, noch weitere Anpassungen/Refactorings an dem Modul vorzunehmen. Besteht für die Möglichkeit, einer der Maintainer des Moduls zu werden? Und wäre für mich eine Mitgliedschaft in der FHEM-Developers - Gruppe angebracht?

Der angepasste Code von 89_VCONTROL.pm befindet sich im Anhang.


Gruß,
René

HoTi

Das ist ja super das da jemand weiter macht!

Per WLAN ist ja interessant. Ich habe da ein zweiten RPI dran, der allerdings noch mehr im Keller macht, ist also nicht so schlimm.

Hier findest du den maintrainer des Moduls: http://fhem.de/MAINTAINER.txt

In deinem Fall:
Zitat
Files with a maintainer. If you wish to change a file, please contact the
maintainer of the file to do the change.

The third column specifies, where/how the maintainer should be contacted. If
there is no reaction from the mainainer within 3 weeks, then rudolfkoenig
(forum.fhem.de/FHEM Forum) should be contacted, in order to assign a new
maintainer.

When adding a new file, add yourself as the maintainer.

File                                              Maintainer          Contact
=========================================================================
FHEM/89_VCONTROL.pm          adamwit              http://forum.fhem.de Heizungssteuerung/Raumklima

Leider finde ich den adamwit nicht im Forum, sonnst hätte ich dir einen direkten Link zu seinem Profil gepostet.

Wenn du Tester brauchst, den mache ich gerne, bin aber per USB angebunden. Ich weiß ja nicht was du noch am Modul machen willst.
Viele Grüße aus  Oberbayern
Tim (RettungsTim)

HoTi

Wer lesen kann ich klar im Vorteil. Ich kann anscheinend nicht.

Kurze Suche im Forum ergab. Dein Ansprechpartner ist:

https://forum.fhem.de/index.php?action=profile;u=448

tadaaa  ;)
Viele Grüße aus  Oberbayern
Tim (RettungsTim)

renemt

Danke, den Adam hatte ich inzwischen auch schon gefunden und kontaktiert :)


Gruß,
René

renemt

@RettungsTim: Wenn du allerdings etwas testen möchtest, dann prüfe doch bitte mal, ob die USB-Anbindung mit der angepassten Version noch so funktioniert, wie sie soll. Nicht, dass ich da jetzt etwas kaputt gemacht habe.

René

LuckyDay

wenn du am 300 Protokoll , dich beschäftigst, gehe ich auch in den Keller zum testen ;)

HoTi

Zitat von: renemt am 22 März 2016, 13:16:56
@RettungsTim: Wenn du allerdings etwas testen möchtest, dann prüfe doch bitte mal, ob die USB-Anbindung mit der angepassten Version noch so funktioniert, wie sie soll. Nicht, dass ich da jetzt etwas kaputt gemacht habe.

René

LÄUFT!
Viele Grüße aus  Oberbayern
Tim (RettungsTim)


HoTi

Viele Grüße aus  Oberbayern
Tim (RettungsTim)

PeMue

#9
Hallo renemt,

sehr cool. Ich werde auf meine Optolink Platine (siehe hier: https://forum.fhem.de/index.php/topic,51431.0.html, bitte ggf. abstimmen) noch einen ESP8266 mit draufmachen, vermutlich einen ESP-03. Dann kann der Adapter USB, RaspberryPi und WLAN  ;D
Welchen ESP verwendest Du?

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

HoTi

Hmm, ein Kabel braucht man ja trotzdem für die Versorgungsspannung.


Viele Grüße aus  Oberbayern
Tim (RettungsTim)

renemt

#11
Hi,

die Konstruktion läuft bei mir jetzt seit ca. 5 Tagen stabil. Den Optokoppler habe ich wie oben beschrieben gemäß der Raspberry-Anleitung aus dem openv-Wiki gebastelt und auch in ein Teko-10006 - Gehäuse verbaut. Wobei das Lötgefummel auf 5x2cm nichts für dicke Finger ist :)

Anschließend habe ich den Optokoppler mit einem USB-Serial-Konverter am USB-Port erfolgreich getestet. Den Konverter verwende ich auch zum Flashen der ESPs. Danach habe ich die ESP-Software auf einem ESP-12 fertig gemacht. Im Prinzip den Telnet-to-Serial - Sketch aus den ESP8266-Arduino-AddOns. Nachdem das auch funktionierte verwende ich final jetzt einen ESP8266-01. Der liefert alle Ausgänge, die ich brauche: TX und RX zur Ansteuerung des Optokopplers, sowie einen freien GPIO-Port, der als "Serial1" aus dem Sketch heraus Debug-Informationen ausgibt. So kann man sich zur Not auch mal parallel per USB 'dranhängen und gucken, was gerade los ist.

Wie gesagt - seit 5 Tagen bekomme ich stabile Messwerte in FHEM geliefert. Ich warte jetzt noch auf ein paar MicroUSB-Breakout-Boards aus China. Dann verfrachte ich den Mikrocontroller samt Spannungswandler in ein 2. Teko-10006-Gehäuse und die Spannungsversorgung erfolgt per Handy-Netzteil. Der benötigte Strom liegt maximal bei ca. 200mA.

In ein paar weitere Projekte werde ich den ESP für batteriebetriebene Sensoren nutzen. Aber das macht nur Sinn, wenn die Daten "sporadisch" übertragen werden. Also alle paar Minuten WLAN an, Daten senden, WLAN aus. Im Heizungsfall möchte ich aber kontinuierlich Messwerte haben, mein Poll-Intervall liegt bei einer Minute. Da würden Batterien nicht lange halten :)

@PeMue: Coole Sache mit der Platine! Wird auf jeden Fall deutlich schöner als das Gelöte auf einer Euro-Platine :) Ich habe auch abgestimmt (nach unten).


Gruß,
René

renemt

Zum Thema "Refactoring" des Moduls 89_VCONTROL.pm selbst: Ich arbeite mich gerade durch den gesamten Diskussions-Thread, um zu verstehen, was wie warum gemacht wurde, sowie durch die FHEM-Entwickler-Doku. Nebenbei habe ich das Refactoring des Moduls begonnen. Ist aber noch kein Stand, den ich zum Testen freigeben würde.

René

PeMue

Zitat von: renemt am 31 März 2016, 18:51:02
Anschließend habe ich den Optokoppler mit einem USB-Serial-Konverter am USB-Port erfolgreich getestet. Den Konverter verwende ich auch zum Flashen der ESPs. Danach habe ich die ESP-Software auf einem ESP-12 fertig gemacht. Im Prinzip den Telnet-to-Serial - Sketch aus den ESP8266-Arduino-AddOns. Nachdem das auch funktionierte verwende ich final jetzt einen ESP8266-01. Der liefert alle Ausgänge, die ich brauche: TX und RX zur Ansteuerung des Optokopplers, sowie einen freien GPIO-Port, der als "Serial1" aus dem Sketch heraus Debug-Informationen ausgibt. So kann man sich zur Not auch mal parallel per USB 'dranhängen und gucken, was gerade los ist.
Hallo René,

schaust Du mal bitte über den Schaltplan https://forum.fhem.de/index.php?action=dlattach;topic=51583.0;attach=49691, ob das mit dem ESP so passt? Ich hätte auf den ESP die transparent bridge draufgemacht. Postest Du bitte mal den Link für Deine Firmware?

Danke + Gruß

Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

renemt

#14
Hallo Peter,

Ich habe mir den Schaltplan angesehen.

Für die Verbindung des ESP mit dem Optokoppler gilt folgendes:

- GPIO15 GPIO0 des ESP8266 darf nur zum Flashen auf GND gelegt werden. Das passiert entweder vor dem Einbau. Oder, wenn man das Teil "upgrade-fähig" machen will, per Taster. Dann kann man theoretisch auch nach dem Zusammenbau über TX/RX des ESP8266 eine neue Firmware aufspielen.
- TX des ESP muss auch an TX des Optokopplers (LED), RX an RX (Fototransistor). Auf dem Schaltplan ist das gerade vertauscht.

Wenn du den FTD und den ESP in "Parallelbetrieb" auf der Platine anbieten möchtest wäre zu beachten, dass sich TX/RX von beiden im Optokoppler nicht in die Quere kommen. Es geht halt entweder nur USB oder nur TCP/WiFi-Zugriff. Eventuell wäre da ein Umschalter sinnvoll. Dann könnte man als nettes Feature nämlich im WiFi-Betrieb auch noch GPIO2 des ESP8266 auf RX des FTD legen und so Debug-Informationen abgreifen. Die Debug-Verbindung würde in dem Fall mit 115.200bps, 8N1, laufen.

Den Sourcecode findest du hier: https://github.com/rene-mt/vitotronic-interface-8266

Wenn du eine "Universal-Platine" bauen willst, dann könnte ich den Sketch noch so anpassen, dass man WiFi-Verbindung und Port von außen festlegen kann, ohne die Firmware jedes mal neu zu compilieren und flashen zu müssen.


Gruß,
René