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 (http://www.mikrocontroller.net/articles/ESP8266) als WiFi-UART-Bridge. D.h. die Anbindung erfolgt per WLAN. Die Optolink-Hardware werde ich gemäß der Anleitungen im openv-Wiki (https://openv.wikispaces.com/Bauanleitung+RaspberryPi) 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é
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 (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.
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 (https://forum.fhem.de/index.php?action=profile;u=448)
tadaaa ;)
Danke, den Adam hatte ich inzwischen auch schon gefunden und kontaktiert :)
Gruß,
René
@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é
wenn du am 300 Protokoll , dich beschäftigst, gehe ich auch in den Keller zum testen ;)
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!
Großartig!
Gibt es was neues?
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
Hmm, ein Kabel braucht man ja trotzdem für die Versorgungsspannung.
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é
Zum Thema "Refactoring" des Moduls 89_VCONTROL.pm selbst: Ich arbeite mich gerade durch den gesamten Diskussions-Thread (https://forum.fhem.de/index.php/topic,20280.0.html), 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é
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
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é
Hallo René,
habe den Schaltplan aktualisiert:
https://forum.fhem.de/index.php?action=dlattach;topic=51583.0;attach=49796
3(,5) Betriebsmodi:
- USB Verbindung (ohne ESP, mit FTDI)
- Raspberry Pi (ohne ESP, ohne FTDI)
- WLAN Betrieb (ohne Debug, bzw. mit Debug = mit FTDI)
Passt das soweit?
Zitat von: renemt am 01 April 2016, 09:56:37
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.
Das wäre natürlich ganz schön cool. Aber dann würde ich die Diskussion auch hierhin https://forum.fhem.de/index.php/topic,51583.0.html verlegen.
Gruß Peter
Das Thema dann dort rüber zu verlegen macht Sinn :)
Zum Plan:
- Den Reset-Taster am ESP kannst eigentlich einsparen. Wenn man einen Reset braucht kann man auch einfach die Spannungsversorgung unterbrechen. Das reicht auch zum Flashen: GPIO15 GPIO0 auf GND legen und VCC herstellen = bereit zum Flashen. Ohne zusätzlichen Reset.
- Für die "universelle Konfiguration" könnte dafür noch ein Schalter/Taster an einem anderen GPIO-Port dazu kommen, um in den Konfigurationsmodus zu wechseln. In dem Fall würde aber ein ESP-01 nicht mehr ausreichen, sondern man sollte gleich einen ESP-12 einsetzen. Der kostet ja in etwa das gleiche, führt aber ausreichend IO-Ports nach draußen.
Ansonsten sieht der Plan gut aus.
Von mir aus können wir dir Diskussion bezüglich der Platine/ESP jetzt auch in "deinem" Thread weiter führen, dann bleibt der Thread für die Änderungen am VCONTROL-Modul frei.
Gruß,
René
Hallo Peter,
noch etwas wichtiges - ist mir gerade erst aufgefallen: Ich habe GPIO15 mit GPIO0 verwechselt! :-\
D.h. GPIO0 muss zum Flashen der Firmware auf GND gelegt werden.
Ich habe das in meinen vorherigen Antworten gleich mal korrigiert.
Gruß,
René
Hallo,
ist es möglich mit dem ESP8266 noch den Gaszähler und evtl. die Wasseruhr zu erfassen und in FHEM zu darzustellen?
Zitat von: max333 am 27 April 2016, 11:11:17
Hallo,
ist es möglich mit dem ESP8266 noch den Gaszähler und evtl. die Wasseruhr zu erfassen und in FHEM zu darzustellen?
Hallo Max,
wir sollten die Diskussion hier https://forum.fhem.de/index.php/topic,51583.msg432508.html#msg432508 weiterführen.
Gruß PeMue
Hallo an alle VControl Begeisterten!
Der Thread ist zwar schon älter aber ich schreib trotzdem mal hier rein, vor allem weil er auf die Fhemwiki-Seite verlinkt ist.
ich habe mich daran gemacht und das VControl-Modul etwas verbessert, und zwar geschwindigkeitstechnisch. Mich hat immer genervt, dass das Abrufen der Werte so elendslang dauert. Habe mich auf die Suche nach dem Grund begeben und wurde auch gleich fündig. Bis jetzt wurde immer nur ein Command gesendet, wenn die Vitotronic den Status 0x05, also bereit zum Empfang eines Commands, gemeldet hat. Das macht sie allerdings nur alle 2 Sekunden. Laut KW Protokoll kann man aber sobald man einmal 0x05 von der Steuerung erhalten, ein Command mit 01 als Prefix (Standard) abgesetzt und man auf diese Anfrage eine Antwort erhalten hat, sofort wieder ein Command senden, diesmal aber ohne 01 als prefix.
Und siehe da, nun fragt er meine grob geschätzt 40 Werte innerhalb von 2.5 Sekunden ab. Anstatt vorher innerhalb fast 60 Sekunden.
Ich hab das erweiterte Modul mal unten angehängt falls es jemand brauchen kann.
Liebe Grüße,
Stephan
@srxp
Wie sieht es dann mit den "alten" Anlagen aus die das GWG-Protokoll nutzen?
Funktionieren die dann noch mit der Änderung?
Das Protokoll liese sich ja zur Unterscheidung aus der .cfg auslesen.
Hi buec65,
das ist ein guter Input...das müsste man noch einbauen. Vielleicht komme ich heute Abend dazu. :-)
lg
stephan
Sodalle...hier nun das aktualisierte Modul.
Als 4ten Parameter kann man nun beim define das Protokol angeben. Wird keines angegeben wird standardmäßig GWG genommen.
Mögliche Werte sind GWG und KW.
Möchte man das protokol angeben muss man gezwungenermaßen ein interval angeben. Aber das stellt ja kein problem dar.
define <name> VCONTROL <port> <command_config> [<interval>] [<protocol>]
lg
Soll das jetzt ein NEUES Modul werden?
Beim original wird das Protokoll und die zu pollenden Werte in einer vcontrol.cfg Datei festgelegt.
Protokoll, gwg
Poll ....
seit wann? bis jetzt gab es keine möglichkeit das protokol festzulegen. es ging immer über gwg. die zu pollenden werte sind im cfg file ja.
sei mir nicht böse aber wer die änderung nicht mag muss das geänderte modul nicht verwenden!
Hallo,
hab heute gesehen das Adam dazu schon mal was gemacht hatte...das ist völlig an mir vorbei gegangen.
Hab das Modul jetzt so geändert das KW standardmäßig genommen wird wenn nix angegeben wird.
Hab auch das Modul mal in den Thread https://forum.fhem.de/index.php/topic,20280.0.html (https://forum.fhem.de/index.php/topic,20280.0.html) reingestellt, mal schauen was Adam dazu sagt.
achja bis jetzt wurde natürlich immer das protokoll kw, allerdings im langsamen modus verwendet...nicht gwg wie ich zuvor geschrieben hatte sorry.
lg
stephan
Irgendwas klappt bei mir nicht. Ich hab einen Optolink Adapter aus dem anderen Thread... Dazu hab ich nun einen Raspi 1 den ich noch rumliegen habe im Heizraum angeschlossen und wollte dann irgendwann FHEM2FHEM Kommunikation machen...
Jetzt aber Back2Topic!!
Ich hab also an den Raspi den Optolinkadapter per USB angeschlossen, hab das ganze in der fhem.cfg definiert, aber ich bekomme keine Werte ausgelesen. Ich habe eine Vitotronic 200KW6B und ich dachte das müsste vielleicht mit dem V200W01B.cfg funktionieren.
Das Logfile sagt folgendes:
2017.02.09 21:38:02 1: Including fhem.cfg
2017.02.09 21:38:02 3: telnetPort: port 7072 opened
2017.02.09 21:38:03 3: WEB: port 8083 opened
2017.02.09 21:38:03 2: eventTypes: loaded 1 events from ./log/eventTypes.txt
2017.02.09 21:38:04 3: VCONTROL: Define open DATEI 'V200WO1B.cfg'
2017.02.09 21:38:04 3: VCONTROL: open DATEI 'V200WO1B.cfg'
2017.02.09 21:38:04 3: VCONTROL: DATEI 'V200WO1B.cfg' refreshed
2017.02.09 21:38:04 3: VCONTROL opening VCONTROL device /dev/ttyUSB0
2017.02.09 21:38:04 3: VCONTROL opened VCONTROL device /dev/ttyUSB0
2017.02.09 21:38:04 3: VCONTROL: Initialization
2017.02.09 21:38:04 1: Including ./log/fhem.save
2017.02.09 21:38:04 1: usb create starting
2017.02.09 21:38:06 3: Probing CUL device /dev/ttyAMA0
2017.02.09 21:38:06 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2017.02.09 21:38:06 1: usb create end
2017.02.09 21:38:06 2: 1
2017.02.09 21:38:06 0: Featurelevel: 5.7
2017.02.09 21:38:06 0: Server started with 8 defined entities (fhem.pl:13334/2017-02-05 perl:5.020002 os:linux user:fhem pid:1114)
list Heizung (so heißt das Device):
Internals:
DEF /dev/ttyUSB0 V200WO1B.cfg 180
DeviceName /dev/ttyUSB0
FD 9
INTERVAL 180
NAME Heizung
NR 23
PARTIAL
STATE Initialized
TYPE VCONTROL
Attributes:
room Heizung
Derzeit zweifle ich noch, ob da überhaupt was gesendet wird. Kann man das irgendwie testen? Ich hab versucht mit der Handykamera mal die LEDs zu filmen, aber da tut sich nichts. Keine Ahnung ob das aber so überhaupt funktioniert.
Hallo Persching,
da du eine KW Steuerung hast wird das wo1b file womöglich nicht funktioniert...bzw ziemlich sicher nicht. du brauchst eine config file für kw vitotronics.
dein optolink adapter ist sicher in ttyusb0 eingebunden?
stell mal auf verbose 5 und poste nochmal ein log...irgendwas sollt er schon tun. die leds am optolink adapter blinken nur wenn er was abfragt oder was schreibt.
bzw was ich grad sehe...du sollte beim cfg file den absoluten pfad angeben...also so habs ich jeden falls also z.B. /opt/fhem/V200WO1B.cfg
lg
stephan
Hallo,
Zitat von: persching am 09 Februar 2017, 22:02:35
Irgendwas klappt bei mir nicht. Ich hab einen Optolink Adapter aus dem anderen Thread ...
mit VitoTest bzw. VitoIDent müssten so oder so ähnliche Bilder kommen (siehe Anhang).
Teste mal, ob der Adapter wirklich plan aufliegt oder ob (durch die seitliche Klappe?) ein Spalt zwischen Adapter und Regelung ist.
Gruß PeMue
Eine seitliche Klappe habe ich nicht, ich hab das rote Teil was man komplett hochklappt. Ich hab den Adapter mit leichtem druck angedrückt, aber das ändert nichts. Es ist auch nicht wirklich ein Spalt dazwischen. Ich konzentriere mich jetzt mal auf die Versuche das Ganze mit Windows und Vitotest zum laufen zu bekommen, denn wenns da nicht funktioniert wird es mit dem Raspi erst recht nicht funktionieren.
EDIT:
Screenshot voIdent hinzugefügt!!
EDIT2:
Langsam aber sicher klappt etwas. Der Trick dabei ist, dass der Adapter mit einem Abstand von rund 6-8 mm (so hält er kaum im V) aufgesteckt werden muss. Dann habe ich wenigstens ein klein wenig Kommunizieren können. Aber auch nur mit voIdent, die anderen Programme bringen mich nicht weiter.
GESCHAFFT!!!! 8)
Internals:
CFGFN
DEF /dev/ttyUSB0 V200KW1.cfg 180
DURATION 86.09
DeviceName /dev/ttyUSB0
FD 14
INTERVAL 180
NAME Heizung
NR 84
PARTIAL
STATE NORM
TYPE VCONTROL
Readings:
2017-02-10 21:10:00 Brenner off
2017-02-10 21:10:03 BrennerStarts 3980
2017-02-10 21:10:03 BrennerStartsDayStart 3976.00
2017-02-10 21:10:03 BrennerStartsToday 4.00
2017-02-10 21:10:23 BrennerStunden 2540.01
2017-02-10 21:10:26 BrennerStunden2 0.00
2017-02-10 21:10:23 BrennerStundenDayStart 2539.86
2017-02-10 21:10:23 BrennerStundenToday 0.15
2017-02-10 21:07:54 Neigung 2
2017-02-10 21:07:57 Niveau -2
2017-02-10 21:10:08 Oelverbrauch 0.00
2017-02-10 21:10:32 Oelverbrauch-Codierung 6502.4
2017-02-10 21:10:08 OelverbrauchDayStart 0.00
2017-02-10 21:10:08 OelverbrauchToday 0.00
2017-02-10 21:10:35 SystemZeit Fr,10.02.2017 21:10:14
2017-02-10 20:57:53 TIMER_0_SA 06:50-22:40/-----/-----/31:60---/
2017-02-10 20:57:56 TIMER_1_SO 06:00-04:00/-----/---31:60/-----/
2017-02-10 20:57:38 TIMER_2_MO 05:00-22:00/-----/-----/31:60---/
2017-02-10 20:57:41 TIMER_3_DI 05:00-22:00/---31:60/31:60---/31:60-31:60/
2017-02-10 20:57:44 TIMER_4_MI 05:00-22:00/-----/-----/31:60---/
2017-02-10 20:57:47 TIMER_5_DO 05:00-20:00/31:60-31:60/31:60-31:60/31:60-31:60/
2017-02-10 20:57:50 TIMER_6_FR 05:00-22:00/-----/---31:60/---31:60/
2017-02-10 20:58:21 TIMER_WW_0_SA 06:30-21:00/-----/-----/31:60-31:60/
2017-02-10 20:58:27 TIMER_WW_1_SO 04:20-16:00/-----/---31:60/31:60---/
2017-02-10 20:57:59 TIMER_WW_2_MO 04:20-21:00/-----/-----/31:60-31:60/
2017-02-10 20:58:05 TIMER_WW_3_DI 04:30-21:00/31:60---/---31:60/-----/
2017-02-10 20:58:10 TIMER_WW_4_MI 04:30-21:00/31:60-31:60/-----/---31:60/
2017-02-10 20:58:13 TIMER_WW_5_DO 04:30-21:00/---31:60/31:60---/-----/
2017-02-10 20:58:18 TIMER_WW_6_FR 04:20-21:00/-----/-----/-----/
2017-02-10 21:09:40 Temp-Aussen 1.2
2017-02-10 21:09:54 Temp-Kessel-Ist 62.5
2017-02-10 21:09:57 Temp-Kessel-Soll -25.7
2017-02-10 21:10:29 Temp-Raum-Soll 23
2017-02-10 21:09:43 Temp-WarmWasser-Ist 60
2017-02-10 21:09:51 Temp-WarmWasser-Soll 55
2017-02-10 21:07:57 UpdateTime 2017-02-10_21:07:57
2017-02-10 21:07:42 Urlaub-Beginn So,01.01.1970 00:00:00
2017-02-10 21:07:49 Urlaub-Betrieb on
2017-02-10 21:07:46 Urlaub-Ende So,00.00.1970 00:00:00
2017-02-10 21:10:11 Zirkulationspumpe off
2017-02-10 21:10:14 state NORM
2017-02-10 21:10:17 state_party off
2017-02-10 21:10:20 state_spar off
Attributes:
room Heizung
Die Werte sind soweit ok... Teils steht hier noch Quark drin... So hab ich z.B. eine Gasheizung und darum ist der Ölverbrauch natürlich nicht korrekt. Aber ich denke das kann ich über die cfg Datei anpassen, oder??
Woran lag es jetzt?
Gruß PeMue
Am Abstand Optolink Adapter zur Heizung, wenn er plan aufliegt dann funktioniert es nicht. Hab jetzt einen Abstand von rund einem halben cm und dann funktioniert es relativ gut. Ich denke ich muss das aber noch irgendwie fixieren.
Moin!
Da bei uns eine neue Steuerung ins Haus steht: Gibt es irgendwo eine Übersicht welche Steuerungen das optolink interface haben?
// bb
Ich glaube so viel verschiedene Steuerungen von Viessmann gibt es gar nicht. Die sehen alle irgendwie gleich aus bloß unterscheiden sie sich im Funktionsumfang. Aber dieses v an das der Optolink andockt ist immer da.
Kommuniziert eigentlich die "Viessmann Cloud" (keine Ahnung wie das korrekt bezeichnet wird) ebenfalls über diese Schnittstelle? Oder werden da die Daten irgendwie intern über einen Bus abgegriffen?
Gibt es eigentlich über das Modul eine Möglichkeit die Steuerung zu identifizieren? Also die Gerätekennung auszulesen? Damit wäre es dann einfach, auf http://openv.wikispaces.com/Adressen (http://openv.wikispaces.com/Adressen) die richtigen Werte für das Config-File zu bekommen.
Ich habe deine Methode probiert, da ich auch dachte, SystemIdent wäre bedeutend... Ergibt bei mir 32. Jetzt fehlt die Konvertierungstabelle ;)
https://forum.fhem.de/index.php/topic,20280.msg600974.html#msg600974
Gruß
Jetzt hab ich es.
POLL, 01F700F802, 2ByteU, 1 , System-Ident , -
Die gelieferte Wert is dezimal. Nach Konvertierung in Hex (bei mir 37920 -> 94 20) finde ich die "2094" die in dieser Tabelle für mein Gerät steht
http://openv.wikispaces.com/Ger%C3%A4te
(V200KW1)
Gruß