http://wiki.fhem.de/w/api.php?action=feedcontributions&user=Cbl&feedformat=atomFHEMWiki - Benutzerbeiträge [de]2024-03-28T22:53:13ZBenutzerbeiträgeMediaWiki 1.39.3http://wiki.fhem.de/w/index.php?title=Buderus_Web_Gateway&diff=38655Buderus Web Gateway2023-10-13T13:06:18Z<p>Cbl: Modul ergänzt, das auch notwendig ist.Siehe: https://forum.fhem.de/index.php?topic=135293.0</p>
<hr />
<div>{{Infobox Modul<br />
|Name=km200<br />
|ModPurpose= Anbindung eines Buderus Web-Gateway<br />
|ModType=d<br />
<!-- |ModCategory= (noch?) nicht verwendet --><br />
|ModCmdRef=km200<br />
|ModForumArea=Heizungssteuerung/Raumklima<br />
|ModTechName=73_km200.pm<br />
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=4705 Sailor]<br />
}}<br />
<br />
== Allgemein ==<br />
[[Datei:KM200.png|1024px|thumb|left |Buderus Kommunikationsmodul KM200<BR>Quelle: "Bosch Thermotechnik GmbH, Buderus Deutschland" <BR> &copy; Buderus]]<br />
[[Datei:KM300.png|1024px|thumb|right|Buderus Kommunikationsmodul KM300<BR>Quelle: "Bosch Thermotechnik GmbH, Buderus Deutschland" <BR> &copy; Buderus]]<br />
<br />
Das Modul 73_km200.pm ermöglicht die Anbindung eines Buderus Web-Gateway an einen FHEM Server (Raspberry-Pi, Fritzbox, NAS) zur Steuerung/Regelung der Heizungsanlage in der FHEM Umgebung zur Erweiterung der Hausautomatisierung.<br />
<br />
Übersicht der steuerbaren Funktionen und abrufbaren Werte (Services) können unter folgendem Link http://www.ip-symcon.de/wiki/Buderus_KM200 eingesehen werden. Diese können aber in Abhängigkeit der Kombination KM/RC sowie der aktuell installierten Firmware auf dem KM unterschiedlich ausfallen. Weitere Details werden nach und nach ergänzt.<br />
<div style="clear:both;"></div><br />
<br />
<br />
== Vorbereitungen ==<br />
=== Vorbereitungen der Hardware ===<br />
<br />
==== Installation der Hardware ====<br />
Allein aus Gründen der Garantieansprüche, sollte das KMxxx Gerät heizungsseitig nur von Heizungsfachmann installiert werden.<br />
Netzwerkseitig sollte das KMxxx Gerät mit einem Netzwerkkabel besser Cat5 direkt an den Router angeschlossen werden.<br />
<br />
<br />
==== Update der Firmware ====<br />
Um eine funktionsfähige Kommunikation zwischen dem FHEM-Modul und dem KMxxx Gerät aufbauen zu können, muss die entsprechende Firmware installiert werden.<br />
Die Firmware ändert sich paradoxerweise in Abhängigkeit der angeschlossenen Geräte. Aus diesem Grund muss das KMxxx Gerät vor Betrieb mit FHEM in jedem Fall zunächst ins Internet. Sobald die LED des KMxxx Geräts auf grün wechselt, ist die Internetverbindung erfolgreich hergestellt. Ab jetzt kann es unter extremen Umständen bis über Nacht dauern, ehe sich die korrekte Firmware automatisch installiert hat.<br />
<br />
<br />
==== Persönliches Passwort ====<br />
Das persönliche Passwort muss zunächst noch erstellt werden, da die KMxxx Geräte ohne persönliches Passwort ausgeliefert werden. <br />
<br />
Aus diesem Grunde ist es notwendig sich einmalig die Buderus APP [http://www.buderus.de/Online_Anwendungen/Apps/fuer_den_Endverbraucher/EasyControl-4848514.html EasyControl] auf einem SmartPhone zu installieren und das Passwort zu setzen. Hierzu muss einfach den Anweisungen Folge geleistet werden.<br />
<pre style="color: red">ACHTUNG: Keine deutschen Umlaute Verwenden!</pre><br />
<br />
<br />
==== Sperrung des Internetzugangs ====<br />
Ohne, dass der Umstand in den Unterlagen der KMxxx Geräte aus datenschutzrechtlicher Sicht auch nur erwähnt ist, baut das KMxxx-Gerät nach jedem Polling seitens des FHEM-Moduls von sich aus eine Verbindung zum Server von Buderus bzw. BOSH Thermotechnik auf. Über den Inhalt der Datenübertragung kann nur spekuliert werden.<br />
Um diese Datenübertragung zu unterbinden, muss man in dem jeweiligen Internet-Router das KMxxx Gerät bzw. dessen entsprechende IP-Adresse für den Internetzugang gesperrt werden. <br />
In der Fritz!Box bzw. unter Fritz!OS funktioniert dies am Besten mit der [http://avm.de/nc/service/fritzbox/fritzbox-7390/wissensdatenbank/publication/show/8_Internetnutzung-mit-Kindersicherung-einschraenken Kindersicherung]<br />
Bei andewren Routern muss die entsprechende Bedienungsanleitung konsultiert werden.<br />
<br />
Eine erfolgreiche Sperrung des Internet-Zugangs quittiert das KMxxx Gerät mit dem Wechsel der Betriebs-LED auf die orange Farbe.<br />
<br />
<br />
=== Vorbereitungen in Linux ===<br />
<br />
<br />
Damit das Modul unter FHEM und Linux funktioniert müssen zusätzliche Perl-Module installiert werden.<br />
<br />
Damit die ständige Eingabe des „sudo“ Befehls zur Installation der einzelnen Module „muss mit Root-Rechten erfolgen“ umgangen werden kann, bitte folgenden Befehl eingeben und mit Password freigeben.<br />
<br />
Code: <br />
:<Code>sudo bash</Code><br />
<br />
Um die folgenden Perl-Module installieren zu können benötigen wir CPANMINUS, dazu bitte folgenden Befehl zur Installation in die Kommandozeile eingeben.<br />
<br />
:<Code>curl -L https://cpanmin.us | perl - --sudo App::cpanminus</Code><br />
<br />
Kommt es dabei zu einer Fehlermeldung bitte mit folgenden Befehl beginnen.<br />
<br />
Code:<br />
:<Code>sudo apt-get install cpanminus</Code><br />
<br />
Dann nacheinander die u.g. Module per (Copy/Paste) und Bestätigung per {{Taste|Enter}} installieren.<br />
<br />
Code:<br />
:<Code>cpanm JSON</Code><br />
<br />
:<Code>cpanm List::MoreUtils</Code><br />
<br />
:<Code>cpanm Crypt::Rijndael</Code><br />
<br />
:<Code>cpanm LWP::UserAgent</Code><br />
<br />
:<Code>cpanm MIME::Base64</Code><br />
<br />
:<Code>cpanm Time::HiRes</Code><br />
<br />
:<Code>cpanm Digest::MD5</Code><br />
<br />
:<Code>cpanm base</Code><br />
:<br />
:<Code>cpanm Crypt::Rijndael</Code><br />
<br />
:<Code>apt-get install libltdl*</Code><br />
<br />
<br />
Zur Vermeidung bekannter Fehler aufgrund Versionsunterschiede, sollte man seine bereits installierten Pakete auf den neusten Stand bringen:<br />
<br />
:<Code>apt-get update</Code><br />
<br />
:<Code>apt-get upgrade</Code><br />
<br />
<br />
Zum Abschluss nach erfolgter Installation der Module noch mit Eingabe des Code:<br />
:<Code>exit</Code> <br />
<br />
wieder in den User-Mode wechseln.<br />
<br />
=== Vorbereitung in FHEM ===<br />
<br />
==== Passwörter ====<br />
<br />
Es werden für das FHEM Modul "km200" 2 Passwörter benötigt:<br />
<br />
a) Gateway Passwort<br />
<br />
Das Gateway Passwort ist fix auf das Gateway programmiert und befindet sich auf dem Typenschild des jeweiligen KM-Moduls.<br />
Es hat das Format aaaa-bbbb-cccc-dddd<br />
<br />
<br />
b) Persoenliches Passwort<br />
<br />
Das persönliche Passwort muss zunächst noch erstellt werden, da die KMxxx Module ohne persoenliches Passwort ausgeliefert werden. <br />
Siehe vorheriges Kapitel [[#Persönliches_Passwort|Persönliches Passwort]]<br />
<br />
<br />
==== Aktivierung und Definition in FHEM ====<br />
In der [[Konfiguration|fhem.cfg]] das Modul definieren mit:<br />
<br />
:<Code>define <devicename> km200 <IPAdresse des KM200> <Gateway Passwort> <persönliches Passwort></Code><br />
<br />
Hierbei können die Passwörter wahlweise als direkter Text (bareword) oder als Base64 codierter text eigegeben werden, sofern man keine direkten Passwörter in der fhem.cfg stehen haben möchte.<br />
<br />
==== Einstellungen über Attribute ====<br />
Es können neben den Standard Attributen wie "room" oder "verbose" noch folgende für das km200-Modul individuelle Attribute in der fhem.cfg ergänzt werden.<br />
<br />
<pre style="width:650px;"><br />
attr <devicename> IntervalDynVal <time in sec><br />
attr <devicename> PollingTimeout <time in sec><br />
attr <devicename> ConsoleMessage <1 or 0><br />
attr <devicename> DoNotPoll <Service_1> <Service_2> <Service_3> ... <Service_n><br />
attr <devicename> ReadBackDelay <time in ms><br />
</pre><br />
<br />
<br />
;IntervalDynVal<br />
:Ein gültiges Interval für die Abfrage der Werte welche über die KM-Module eingelesen werden. Der Wert muss >= 20s sein um dem Modul zu erlauben einen kompletten Poll abzuwarten. Der Default Wert ist 90s.<br />
<br />
;PollingTimeout<br />
:Zeitraum in dem das auf eine Antwort seitens des KM200/KM50 Moduls warten soll. Sollte ein sehr langsames Heimnetz vorhanden sein, so muss der Wert entsprechend hochgesetzt werden. Der Default-Wert ist 5s.<br />
<br />
;ConsoleMessage<br />
:Sollte es aus Gründen der Fehlersuche erwünscht sein, dem Modul beim Pollen der einzelnen Werte life zuzusehen, so kann man die Ausgabe im Konsolenfenster (STD-OUT) aktivieren. Hierzu muss der Wert auf "1" gesetzt werden.<br />
:Bitte daran denken, dass dies nicht automatisch in dem Telnet Fenster (e.g. PUTTY) angezeigt wird. Man muss zur Anzeige dort das FHEM-System stoppen und wieder starten.<br />
:Der Default-Wert is "0" = deaktiviert.<br />
<br />
;DoNotPoll<br />
:Eine durch Leerzeichen getrennte Liste von Services die nicht gepollt werden sollen. Dies kann bei wiederholten Abstürzen durch Abfrage bestimmter Services angewendet werden sowie für das gezielte Ausblenden von irrelevanten Werten (Z.B.: Rücklauftemperatur = -32768°C, etc.). <br />
:Der Default Wert ist "" somit werden alle Werte abgefragt.<br />
:Nach dem Setzen des "DoNotPoll"-Attributs kann man die ungewünschten Readings mittels "deletereading" einzeln oder komplett löschen: Beispiel: <pre style="width:650px;">deletereading myKm200 .*</pre><br />
<br />
;ReadBackDelay<br />
:Zeitraum in Millisekunden in dem das Modul mit einem Zurücklesen der Werte nach einem Schreibvorgang warten soll, da es sonst zu keinem erfolgreichen Schreibvorgang kommt. Die Größe des Wertes hängt sehr stark von der Geschwindigkeit des FHEM-Host-Systems sowie der angeschlossenen Netzwerkverbindung ab und kann daher mehr oder minder stark schwanken. Der Default-Wert ist 100ms.<br />
<br />
== Beispiel für Menüführung ==<br />
<br />
=== Anzeige der Liste für Fehlermeldungen ===<br />
<pre style="color: red">Mit freundlicher Einladung an DLindner :-) </pre><br />
<br />
=== Steuerungsmenü eines Heizkreises ===<br />
<pre style="color: red">Mit freundlicher Einladung an DLindner :-) </pre><br />
<br />
=== Steuerungsmenü der Warmwasserbereitstellung ===<br />
<pre style="color: red">Mit freundlicher Einladung an DLindner :-) </pre><br />
<br />
== Beispiel für readingsGroup ==<br />
[[Datei:Buderus_RoomHeizung.png|200px|thumb|right|readingsGroup "Heizung" und "Temperaturen" mit 73_km200 - Werten]]<br />
In diesem Beispiel werden im Raum "Heizung" zwei Gruppen namens "Heizung" und "Temperaturen" angelegt und die Services mit entsprechenden Symbolen versehen. <br />
<br />
fhem.cfg<br />
<br />
<code>define Temperaturen readingsGroup myKm200:<%temp_temperature>,<AussenTemp.>,/system/sensors/temperatures/outdoor_t1 myKm200:<%sani_solar_temp><SonnenkollektorTemp.>,/solarCircuits/sc1/collectorTemperature myKm200:<%sani_buffer_temp_all>,<HeißwasserTemp.>,/system/sensors/temperatures/hotWater_t2</code><BR><br />
<code>attr Temperaturen room Heizung</code><BR><br />
<code>attr Temperaturen valueStyle style="text-align:right"</code><br />
<br />
<code>define Heizung readingsGroup myKm200:<%sani_domestic_waterworks>,<Heizungsdruck>,/system/appliance/systemPressure myKm200:<%sani_supply_temp>,<Vorlauftemp>,/system/sensors/temperatures/supply_t1 myKm200:<%sani_return_temp>,<Rücklauftemp>,/heatSources/returnTemperature<BR><br />
attr Heizung room Heizung<BR><br />
attr Heizung valueStyle style="text-align:right"</code><br />
<br />
== Beispiel für Plot ==<br />
<br />
=== Mit dBLog ===<br />
<br />
[[Datei:DbLog-plot.png|1024px|thumb|none|plot mit Werten aus 73_km200]]<br />
<br />
Um einen obigen Plot anzuzeigen geht man wie folgt vor:<br />
<br />
==== [[Konfiguration|fhem.cfg]] ====<br />
<br />
Folgende Einträge müssen in der [[Konfiguration|fhem.cfg]] vorgenommen werden:<br />
<br />
define SVG_CH_Values SVG myDbLog:CentralHeating_CH:HISTORY<br />
attr SVG_CH_Values plotsize 1600,400<br />
attr SVG_CH_Values room Plots<br />
attr SVG_CH_Values title "Central Heating"<br />
<br />
==== gplot ====<br />
<br />
Die entsprechende plot-Datei namens "<code>CentralHeating_CH.gplot</code>" sieht dann wie folgt aus:<br />
<br />
# Created by FHEM/98_SVG.pm, 2015-01-12 22:57:42<br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel " "<br />
set title '<TL>'<br />
set ytics <br />
set y2tics <br />
set grid y2tics<br />
set ylabel "Temperature in °C / Modulation in %"<br />
set y2label "Power in kW"<br />
set yrange [0:105]<br />
set y2range [0:21]<br />
#DbLog myKm200:/heatSources/actualPower<br />
#DbLog myKm200:/system/sensors/temperatures/supply_t1<br />
#DbLog myKm200:/heatingCircuits/hc1/pumpModulation<br />
#DbLog myKm200:/system/sensors/temperatures/hotWater_t2<br />
plot "<IN>" using 1:2 axes x1y2 title 'Power' ls l3 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Vorlauftemperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Ladepumpe' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Warmwasser' ls l2 lw 1 with lines<br />
<br />
Diese Plotdatei kann auch mit Hilfe des [[Plots_erzeugen#.gplot-Editor|Ploteditors]] generiert werden. Die Vorgehensweise entspricht -bis auf die Plot-Source dBLog- dem im Folgenden beschriebenen Ablauf mit FileLog.<br />
<br />
=== Mit FileLog ===<br />
[[Datei:Buderus_Temperaturen_MitFileLog.png|1024px|thumb|none|typischer Temperatur plot]]<br />
<br />
Obiger Plot wurde mit Hilfe des Ploteditors erstellt.<br />
<br />
==== [[Konfiguration|fhem.cfg]] ====<br />
<br />
Die Ploterstellung erfolgt anhand der nachfolgenden Beispiel-Konfiguration:<br />
<br />
# Buderus Gateway aktivieren und Parameter setzen<br />
# ===============================================<br />
define heizung km200 <IP ADR> <SYS PW> <User PW><br />
attr heizung IntervalDynVal 90<br />
attr heizung IntervalStatVal 3600 <br />
attr heizung PollingTimeout 200 <br />
attr heizung ConsoleMessage 0 <br />
attr heizung room Heizung <br />
<br />
# Loggen aller Daten aktivieren, Pfad/Dateiname ./log/Heizung-<Jahr>-<Monat>.log; Bsp.: "Heizung-2015-01.log"<br />
# ===========================================================================================================<br />
define FileLog_heizung FileLog ./log/Heizung-%Y-%m.log heizung<br />
attr FileLog_heizung logtype text<br />
attr FileLog_heizung room LogFiles<br />
attr FileLog_heizung group Heizung<br />
<br />
{{Anker|SelektivLoggen}} <br />
# Loggen einer Auswahl von Daten aktivieren, Pfad/Dateiname ./log/Heizung-<Jahr>-<Monat>.log; Bsp.: "Heizung-2015-01.log"<br />
# =======================================================================================================================<br />
define FileLog_heizung FileLog ./log/Heizung-%Y-%m.log heizung:(/system/sensors/temperatures/hotWater_t2|/system/sensors/temperatures/outdoor_t1).*<br />
attr FileLog_heizung logtype text<br />
attr FileLog_heizung room LogFiles<br />
attr FileLog_heizung group Heizung<br />
<br />
==== Plot Anlegen ==== <br />
[[Datei:Logfiles_FileLog_heizung.png|512px|thumb|right|Logfiles_FileLog_heizung.png]]<br />
Nach Fertigstellung und Abspeichern der ''"[[Konfiguration|fhem.cfg]]"'' Datei ist als erster Schritt der Plot anzulegen. Dazu:<br />
* im Raum ''"LogFiles"'' auf den Link ''"FileLog_heizung"'' klicken.<br />
* Im neuen Fenster auf den Link ''"Create SVG Plot"'' klicken<br />
jetzt kann die eigentliche Konfiguration der darzustellenden Daten beginnen.<br />
<div style="clear:both;"></div><br />
==== Plot Inhalte via Plot Editor konfigurieren ====<br />
[[Datei:Buderus_Heiztemperaturen_Ploteditor.png|1024px|thumb|right|Buderus_Heiztemperaturen_Ploteditor.png]]<br />
Nun ist der Plot noch mit Leben zu füllen. <br />
Dazu müssen dem Plot noch mit Hilfe des [[Plots_erzeugen#.gplot-Editor|Ploteditors]] die eigentlichen Messwerte des Buderus Gateways zugeordnet werden:<br />
<br />
* Link ''"Heiztemperaturen"'' unten links anklicken (siehe oben, Temperatur Plot)<br />''Es erscheint der Ploteditor (Buderus_Heiztemperaturen_Ploteditor.png)''<BR />''Der Plot selbst (oben) erscheint beim ersten Mal noch nicht, da bisher keine Meßgrößen selektiert wurden''<br><br />
*Die Beschriftung von ''Titel, Achsen'' etc. sollte selbst erklärend sein (1)<br />
*In den Zeilen unter ''"Diagram Label, Source..."'' legt man die eigentlichen Meßwerte für den Plot fest<br />
*''"Diagram Label"'' (2) = beliebige Bezeichnung des Meßwertes<br />
*''"Source"'' (3) = in diesem Auswahlfenster legt man die Logdatei fest, aus der die Daten extrahiert werden sollen, hier "FileLog_heizung"<br />
*''"Input:Column"'' (4) = Spalte innerhalb der Logdatei in der die Meßwerte stehen, bei uns immer ''"4"'' (Spalte 1 = Zeitstempel)<br />
*''"Regexp"'' (5) = hier legt wählt man die eigentliche Meßgröße aus<br />
*''"DefaultValue"'' (6) = Defaultwert, wird angezeigt wenn es keine echten Meßdaten gibt (Man sieht dann den Default Wert, ist eher schlecht deshalb bei mir leer)<BR><br />
*''"Function"'' (7) = hier kann eine Umrechnungsformel angegeben werden<br />
*''"Y-Axis"'' (8) = hier kann die Referenzachse (Rechte oder Linke) ausgewählt werden<br />
*''"Plot-Type"'' (9) = hier wird festgelegt ob die Darstellung als "Linie" oder "Punkte" etc. erfolgt<br />
*''"Style"'' (10) = Farbe/Struktur der Linie....<br />
*''"Width"'' (11) = Stärke der Linie....<br />
<br />
Sind alle diese Parameter für einen Meßwert definiert ist noch der Button ''"Write .gplot file"'' (12) zu drücken, danach wird die erste Kurve dargestellt.<br />
'''Aber aufpassen:''' angezeigt werden in obiger Konfiguration immer nur die Meßwerte '''eines Tages'''. Erstellt man diese Konfiguration z.B. um 0:01 Uhr Nachts<br />
sieht man '''nichts''', weil es u.U. noch keine Meßwerte für diesen Tag gibt.<br />
Für weitere Messwerte wird obiger Vorgang wiederholt.<BR><br />
<br />
Danach kann bei Bedarf noch via ''"attr FileLog_heizung Room"'' ein gewünschter "Raum" festgelegt werden. Am Ende noch auf ''"Save config"'' klicken damit das Werk auch abgespeichert wird. <br />
<br />
<br />
<big>'''Hinweis:'''</big><BR><br />
<br />
Das Laden der Plots dauert eventuell sehr lang. Das liegt daran, dass alle Daten der Logdatei geladen werden m&uuml;ssen und unter Umst&auml;nden sehr viele Daten durch ein sehr kurzes Poll-Intervall gespeichert werden. Ein schwaches Rechensystem z.B. Raspberry PI kann diesen Umstand noch verst&auml;rken.<br />
Als Abhilfe kann z.B. nur ein Teil der Daten geloggt werden, s.o. unter: [[Buderus Web Gateway#SelektivLoggen|Loggen einer Auswahl von Daten aktivieren,....]]. Geloggt werden im obigen Beispiel die Daten in der runden Klammer (.hotWater_t2 und ..outdoor_t1).<br />
<br />
== Bekannte Probleme ==<br />
<br />
=== Fehlermeldung: "Use of uninitialized value in concatenation (.) or string at ./FHEM/73_km200.pm" ===<br />
<br />
<u>'''Beschreibung / Ursache:'''</u><br />
<br />
Diese Fehlermeldung tritt meistens in Verbindung mit einem sehr langsamen Netzwerk auf. <br />
Hierbei antwortet das KM300/KM200/KM50 nicht rechtzeitig bevor das 73_km200.pm - Modul aufgibt und die unten genannte Fehlermeldung ausgibt.<br />
<br />
<br />
<br />
<u>'''Lösung:'''</u><br />
<br />
Um das Modul "geduldiger" zu machen, muß man nur das Attribut "PollingTimeout" entsprechend höher setzen. Ein guter Erfahrungswert wäre zum Beispiel 20, was den 4-fachen des Default-Werts entspricht.<br />
Besser wäre es jedoch einen qualitativ höherwertigen Netzwerk-Switch statt beispielsweise Netzwerk-Hub oder gar billigen Router einzusetzen.<br />
<BR><br />
<BR><br />
<BR><br />
<br />
=== Sporadischer Absturz von FHEM ===<br />
<br />
<u>'''Beschreibung / Ursache:'''</u><br />
<br />
Aus noch ungeklärter Ursache kann es bei einzelnen Buderus KMxxx Geräten in Verbindung mit verschiedenen Buderus RCs bei Abfrage bestimmter Services zum Komplett-Absturz des FHEM - Systems kommen.<br />
Es ist dem Developer des Moduls bisher nicht gelungen diese Abstürze nachzustellen um den Fehler entsprechend abzufangen.<br />
Bisher treten diese Abstuerze insbesondere bei Abfrage der folgenden Services auf:<br />
<br />
:<Code>/heatSources/flameCurrent</Code><br />
:<Code>/heatSources/flameStatus</Code><br />
:<Code>/system/appliance/flameCurrent</Code><br />
:<Code>/system/appliance/flameStatus</Code><br />
Aber auch andere Services könnten dieses Problem auslösen. Sind dem Developer aber zur Zeit nicht bekannt.<br />
<br />
<br />
<br />
<u>'''Lösung:'''</u><br />
<br />
Zu diesem Zweck muss man zunächst das Attribut ConsoleMessage aktivieren (Siehe Attribute) und sehen, ab welcher Ausgabe sich das FHEM-System aufhängt.<br />
<br />
Der Wert der Probleme bereitet ist der nächste Wert, der eben gerade nicht angezeigt wird.<br />
<br />
Die bekannten Problem-Services hinter das Attribut DoNotPoll hängen. Sie werden anschließend nicht mehr abgefragt und können somit keinen Absturz mehr verursachen.<br />
<BR><br />
<BR><br />
<BR><br />
=== Keine Services lesbar / Keine Readings im FHEM ===<br />
<br />
<u>'''Beschreibung / Ursache:'''</u><br />
<br />
Es kann sein das das FHEM System nach eine Weile abstürzt ohne vorher Readings in das device geschrieben zu haben.<br />
Wenn man zum debuggen dann das Attribut "ConsoleMessage" aktiviert hat (Siehe Attribute) dann taucht folgende Liste in der Konsole auf:<br />
<br />
<br />
:<Code>Sounding and importing of services started</Code><br />
:<Code>The following Service CANNOT be read &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: /</Code><br />
:<Code>The following Service CANNOT be parsed by JSON : /gateway</Code><br />
:<Code>The following Service CANNOT be parsed by JSON : /gateway/DateTime</Code><br />
:<Code>The following Service CANNOT be parsed by JSON : /gateway/instAccess</Code><br />
:<Code>The following Service CANNOT be parsed by JSON : /gateway/instWriteAccess</Code><br />
:<Code>The following Service CANNOT be parsed by JSON : /gateway/uuid</Code><br />
:<Code>The following Service CANNOT be parsed by JSON : /gateway/versionFirmware</Code><br />
:<Code>The following Service CANNOT be parsed by JSON : /gateway/versionHardware</Code><br />
:<Code>The following Service CANNOT be parsed by JSON : /heatingCircuits</Code><br />
:<Code>The following Service CANNOT be parsed by JSON : /heatingCircuits/hc1</Code><br />
:<Code>The following Service CANNOT be parsed by JSON : /heatingCircuits/hc1/activeSwitchProgram</Code><br />
:<Code>The following Service CANNOT be read&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: /heatingCircuits/hc1/actualSupplyTemperature</Code><br />
:<Code>The following Service CANNOT be read&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: /heatingCircuits/hc1/controlType</Code><br />
:<Code>The following Service CANNOT be read&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: /heatingCircuits/hc1/currentOpModeInfo</Code><br />
:<Code>The following Service CANNOT be read&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: /heatingCircuits/hc1/currentRoomSetpoint</Code><br />
:<Code>The following Service CANNOT be read&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: /heatingCircuits/hc1/designTemp</Code><br />
(Gekürzt)<br />
<br />
<br />
<br />
<u>'''Lösung:'''</u><br />
Bisher tauchen diese Symptome nur in Verbindung mit einem falschen Passwort auf.<br />
Zu diesem Zwecke beide Passwörter überprüfen und ggf. das private Passwort mit der App erneut setzen.<br />
<pre style="color: red">ACHTUNG: Keine deutschen Umlaute Verwenden!</pre><br />
<BR><br />
=== Fehlermeldung: "encrypt: datasize not multiple of blocksize (16 bytes) at ./FHEM/73_km200.pm line xxx" ===<br />
<br />
<u>'''Beschreibung / Ursache:'''</u><br />
<br />
Während der Initialisierung des Geräts taucht die Fehlermeldung <br />
<br />
<Code>encrypt: datasize not multiple of blocksize (16 bytes) at ./FHEM/73_km200.pm line xxx</Code> <br />
<br />
in der Konsole auf und stürzt ab. Offensichtlich kann es aus noch ungeklärter Ursache dazu kommen, dass das KM Gerät 2 Byte zuviel sendet.<br />
<br />
<br />
<br />
<u>'''Lösung:'''</u><br />
<br />
Die Ursache konnte noch nicht gefunden werden. Bei dem einzigen bekannten Fall hat der User nur mit einem kompletten Hardware-RESET des KM - Gerätes die Funktion, bzw. den Kontakt zum KM-Gerät wiederherstellen können.<br />
<BR><br />
<BR><br />
=== FlameStatus "OFF" wird erkannt, FlameStatus "ON" wird aufgrund falscher Codierung verworfen ===<br />
<br />
<u>'''Beschreibung / Ursache:'''</u><br />
<br />
Die Readings <br />
:<code>/heatSources/flameStatus</code><br />
:<code>/system/appliance/flameStatus</code> <br />
<br />
werden zwar eingelesen, jedoch verweilt der Status in "OFF". Da das Gerät einen undefinierten aber nicht reproduzierbaren JSON-Wert für "ON" zurückgibt, wird dieser vom 73_km200 Modul verworfen.<br />
<BR><br />
<BR><br />
<u>'''Lösung:'''</u><br />
<br />
Die Ursache kann vom 73_km200 Modul nicht behoben, bzw. abgefangen werden, da sich die fehlerhaften Stringmeldungen von Gerät zu Gerät in Abhängigkeit von Hardware, Linux-Version, Applikations-Version unterscheiden können.<br />
<br />
Der Fehler liegt nach bisheriger Einschätzung im Gerät bzw. dessen Firmware.<br />
<BR><br />
<BR><br />
Aus diesem Grunde wird empfohlen eine Abfrage auf<br />
:<Code>/heatSources/flameCurrent > 0uA </Code><br />
oder<br />
:<Code>/system/appliance/flameCurrent > 0uA</Code><br />
zu programmieren. Sobald der Ionisierungsstrom >0 ist, läuft der Brenner ganz sicher. <br />
<br />
Die interne Logik der Zentralheizung macht im Grunde nichts Anderes.<br />
<br />
=== Trotz des Ausschluss ausgesuchter Services durch das "DoNotPoll" - Attribut, listet FHEM diese noch auf ===<br />
<br />
<u>'''Beschreibung / Ursache:'''</u><br />
<br />
Nachdem man die nicht mehr erwünschten Services durch das "DoNotPoll" - Attribut geblockt hat, werden diese immer noch aufgelistet<BR><br />
<BR><br />
<u>'''Lösung:'''</u><br />
<br />
FHEM speichert alle Readings in der fhem.save Datei. Um diese zu löschen kann mittels des FHEM - Befehls "deletereading" das entsprchende Reading gelöscht werden.<br />
Es dürfen aber auch alle Readings gelöscht werden, da diese beim nächsten geplanten Polling wieder neu geschrieben werden:<BR><br />
<BR><br />
:<Code>deletereading myKm200 .*</Code><br />
<BR><br />
Update: Seit Version 0052 sollte dieser Fehler behoben sein. Bei Veränderung der "DoNotPoll"-Parameter werden zunächst alle Readings gelöscht und neu eingelesen.<br />
<BR><br />
<BR><br />
=== km200 - Device bleibt auf State "Sounding..." hängen ===<br />
<br />
<u>'''Beschreibung / Ursache:'''</u><br />
<br />
Die genaue Ursache dieses Fehlers ist noch unbekannt und kann nicht zuverlässig reproduziert werden, was die Fehlersuche erschwert.<BR><br />
Es ist zu vermuten, dass die Kommunikation bzw. die Antwortzeiten eine Rolle spielen.<BR><br />
<br />
<u>'''Lösung:'''</u><br />
<br />
Zur Zeit gibt es nur die Möglichkeit nach einem FHEM Neustart einmalig zu kontrollieren, ob die Werte eingelesen werden (Farbwechsel der LastUpdate-Zeiten) bzw. ob der State nach einer gewissen Zeit auf "Standby" geht.<BR><br />
Sollte dies nicht der Fall sein, hat sich die Kommunikation aufgehängt und ein FHEM-Neustart mit "shutdown restart" sollte durchgeführt werden.<BR><br />
Bisher tauchen nach einem erfolgreichen Sounding keine Probleme im normalen Dienst auf.<BR><br />
<BR><br />
Update: Seit Version 0054 ist dieses Problem behoben.<BR><br />
Das Modul wartet nach erfolglosem Erstkontakt zunächst 10s und gibt eine ERROR - Fehlermeldung im STATE aus.<br />
Dann startet es nach Ablauf der 10s einen neuen Versuch.<br />
Sollte der Versuch erfolgreich sein, wechselt der STATE in "Sounding"´ansonsten wartet es wieder 10s.<BR><br />
<BR><br />
<BR><br />
=== km200 - Device bleibt scheinbar auf State "Sounding...", "ERROR -" oder "Polling" hängen ===<br />
<br />
<u>'''Beschreibung / Ursache:'''</u><br />
<br />
Obwohl das Modul scheinbar seine Arbeit aufgenommen hat und funktioniert, ändert sich das STATE Reading in der FHEMWeb - Oberfläche nicht.<br />
<br />
<u>'''Lösung:'''</u><br />
<br />
Dies ist kein km200 oder FHEM Problem Dieses Problem liegt hierbei im Browser.<BR><br />
Die Lösung ist, einen Seiten-Refresh mittels Taste "F5" zu machen.<BR><br />
<BR><br />
<BR><br />
<br />
== Anhang A - Liste bekannter Root Services ==<br />
<br />
Die folgenden Werte sind dem Developer bekannt und können durch das Modul abgefragt werden, sofern eine Antwort seitens des KMxxx kommt oder sich nicht hinter dem DoNotPoll Attribut befinden.<br />
Alle untergeordneten Services werden seit Version 0045 automatisch geladen und können von User zu User variieren.<br />
<br />
<span style="font-family:Courier New"><br />
/<BR><br />
/dhwCircuits<BR><br />
/gateway<BR><br />
/heatingCircuits<BR><br />
/heatSources<BR><br />
/notifications<BR><br />
/recordings<BR><br />
/solarCircuits<BR><br />
/system<BR><br />
<BR><br />
</span><br />
<br />
== Links ==<br />
* {{Link2Forum|Topic=25540}} zur Entwicklung und Support des Moduls<br />
* {{Link2Forum|Topic=25540|Message=230504}}, der auf einem Raspbery Pi schrittweise -ausgehend von der Betriebssysteminstallation über die FHEM-Installation- die Modulnutzung beschreibt<br />
* [http://www.buderus.de Buderus Internetseite]<br />
* [http://de.documents.buderus.com/download/pdf/file/6720807675.pdf Logamatic web KM50 &nbsp; - Installations- und Bedienungsanleitung]<br />
* [http://documents.buderus.com/download/pdf/file/6720647836.pdf Logamatic web KM200 - Installationsanleitung für den Fachmann]<br />
* [http://heizungsfachshop.de/media/pdf/technische-unterlagen-buderus-logamatic-web-km300.pdf Logamatic web KM300 - Installationsanleitung für den Fachmann]<br />
<br />
[[Kategorie:Heizungssteuerung]]<br />
[[Kategorie:Other Components]]</div>Cblhttp://wiki.fhem.de/w/index.php?title=HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi&diff=37492HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi2022-07-08T11:44:54Z<p>Cbl: Hinweis auf NOBREAK ergänzt</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HM-MOD-RPI-PCB.jpg<br />
|Bildbeschreibung=HomeMatic Funkmodul für Raspberry Pi <br />
|HWProtocol=HomeMatic<br />
|HWType=Gateway<br />
|HWCategory=HomeMatic<br />
|HWComm=868,3/869,525 MHz<br />
|HWChannels=n/a<br />
|HWVoltage=1,8–3,6 V&nbsp;DC<br />
|HWPowerConsumption=50 mA max.<br />
|HWPoweredBy=RasPi<br />
|HWSize=19x41x14mm<br />
|HWDeviceFHEM=[[HMUARTLGW]]<br />
|HWManufacturer=ELV / eQ-3 <br />
}}<br />
Das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi]] ist eine Platine, die auf die GPIO-Schnittstelle des [[Raspberry Pi]] aufgesteckt werden und damit als [[Interface]] zu [[HomeMatic]] Geräten dienen kann. <br />
<br />
== Aufbau, Einsatz und grundsätzliche Funktionsweise ==<br />
Das Modul besteht aus zwei Teilplatinen, die von eQ-3 über den Internetshop von ELV (als Bausatz ab etwa 20€, fertig montiert ab etwa 30€) verkauft werden. <br />
<br />
Das eigentliche Funkmodul wird mit HM-MOD-RPI-UART bezeichnet (und trägt den Aufdruck UART, im obigen Bild hinten teilweise verdeckt und mit der umrandeten 7 versehen), sie hat fünf einpolige Buchsen mit dem Rastermaß 2mm. Die Zusatzplatine zum Anschluss an die GPIO wird mit TRX1 bezeichnet (im obigen Bild vorn sichtbar mit dem Aufdruck HM-MOD-RPI-PCB), sie hat zwei sechspolige Buchsen mit dem Rastermaß 2,54mm. Die Zusatzplatine enthält im Wesentlichen Stützkondensatoren und erlaubt einen direkten Anschluss an die GPIO eines Raspberry Pi.<br />
* Der vorgesehene Einsatz als Aufsteckmodul auf den GPIO Port des Raspberry erfordert eine Modell abhängige Konfiguration. Diese wird im Setupbereich des Wiki Artikel zum [[Raspberry_Pi]] beschrieben.<br />
<br />
{{Randnotiz|RNText=Neben der hier beschriebenen Option das HM-MOD-RPI-PCB zu verwenden, besteht auch die Möglichkeit, damit auf demselben Raspberry eine virtuelle CCU zu betreiben, welche dann mit [[HMCCU]] eingebunden werden kann. Hierfür stehen mehrere Virtualisierungsvarianten zur Verfügung; eine kurze Darstellung, wie das mittels YAHM funktioniert, ist in diesem {{Link2Forum|Topic=79670|Message=718289|Forenbeitrag}} zu finden.}}Mit dieser Platine in Verbindung mit dem FHEM-Modul [[HMUARTLGW]] ist nur der Betrieb von BidCoS-Geräten möglich. Zur Einbindung von Geräten, die HM-IP verwenden, ist derzeit (Stand Juni 2018) noch zwingend eine (ggf. virtualisierte) CCU2 oder neuer erforderlich.<br />
<br />
Das Funkmodul stellt auf dem 868MHz-Frequenzband eine Verbindung zu Homematic-Geräten her. Das Modul wird über die serielle Schnittstelle an ein Gerät gekoppelt, dass diese serielle Schnittstelle auswerten und die Information dann weiterverarbeiten kann. Hier kommen beispielsweise in Frage: Raspberry Pi, WeMos mini, ESP8266-Module, USB-serielle Adapter. Bereits das UART-Funkmodul erlaubt eine serielle Anbindung (die entsprechenden Schnittstellen Tx und Rx sind vorhanden, sie basieren auf 3,3V), es kann aber auch die zusätzliche TRX1-Platine seriell verbunden werden. Des weiteren gibt es im Forum ein {{Link2Forum|Topic=56606}}, in dem PeMue eine eigene Platinenversion (Schaltplan, Stückliste und vieles mehr) vorstellt.<br />
<br />
=== Platine 1 -PCB-Modul ===<br />
[[Datei:Hm-uart trx1.png|thumb|right|200px|Verkabelung beim HM-MOD-PCB]]<br />
Am einfachsten ist es sicherlich, das kombinierte PCB-Modul (also beide Platinen UART und TRX1 durch eine Pfostenleiste miteinander verlötet) direkt auf die GPIO des Raspberry Pi aufzustecken. Das Bild rechts zeigt die entsprechende Verkabelung. Dabei ist zu beachten, dass sich nicht zwei Module die GPIO teilen können. Steckt schon ein Modul im Raspberry Pi, muss der Anschluss per USB, in einem zweiten Raspberry Pi oder per WLAN gewählt werden.<br />
<br clear="all"><br />
<br />
=== Platine 2 -UART-Modul ===<br />
[[Datei:Verkabelung-HM-MOD-uart.png|thumb|right|200px|Verkabelung beim HM-MOD-UART]]<br />
Will man das TRX1-Modul nicht verwenden, so kann man auch das UART-Modul direkt mit Rx/Tx des Raspberry Pi verbinden. Das Bild rechts zeigt die entsprechende Verkabelung. Hier sollten allerdings Stützkondensatoren an die Stromversorgung des UART angebracht werden, da Spannungsschwankungen sonst zu schwer interpretierbaren Fehlern führen können. Die Anschlüsse sind dem nachstehenden Bild zu entnehmen, allerdings ist hier nicht die UART-Platine, sondern das TRX1-Gegenstück zu sehen!<br />
<br />
Sowohl serielle Schnittstelle des Raspberry Pi als auch das UART-Modul arbeiten mit 3,3V arbeitet, so dass man keine Spannungsteiler benötigt. Mehr Informationen zu den GPIOs findet man unter diesem [http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_GPIO.html Link].<br />
<br />
=== Zusammenbau und Verwendung ===<br />
Man sollte die Antenne aus dem Gehäuse schauen lassen oder gar eine externe Antenne anbringen. Idealerweise sollte das Ende der Drahtantenne mit einem Klecks Heißkleber oder ähnlichem isoliert werden; eine Berührung vor allem mit dem Innenleben des Raspberry Pi muss vermieden werden!<br />
<br />
Beide Platinen können zusammengebaut oder auch nur das UART Modul getrennt verwendet werden. <br />
[[Datei:HM-MOD-UART-Unten.jpg|thumb|left|200px|Montage des Moduls HM-MOD-UART unten]]<br />
[[Datei:HM-MOD-UART-Oben.jpg|thumb|right|200px|Montage des Moduls HM-MOD-UART oben]]<br />
Die originale Montage in der Anleitung von eq3 sieht den Zusammenbau PCB Modul unten und UART Modul oben vor (Bild rechts). Damit schließen die kleineren Pi-Gehäuse nicht richtig: das Gesamtmodul klemmt am Deckel.<br />
<br />
Man kann ohne weiteres das UART-Modul unter dem PCB-Modul montieren (Bild links), damit wird die Gesamthöhe geringer und es passt problemlos in jedes Gehäuse. Bitte vorher die genaue Situation prüfen: Es kann sein, dass damit Kühlkörper oder ähnliches seitens der Pi-Platine stören.<br />
<br />
Man kann auch das PCB Modul kürzen und das UART Modul mit kurzen Drähten in einer Ebene verbinden (kein Bild).<br />
<br />
Bitte auf die richtige Lage (Bilder) beim Zusammenbau und auf Lötzinnbrücken achten. Da die Anschlüsse durchkontaktiert sind, bewirkt eine falsche Positionierung des UART-Moduls im schlimmsten Fall einen Kurzschluss. Man erkennt auf beiden Bildern, dass beim UART-Modul die Pinleiste einmal auf der einen und ein andermal auf der anderen Seite des Moduls angelötet werden muss! <br />
<br />
<br clear="all"><br />
== Verwendung ==<br />
Das Modul muss, um verwendet zu werden, mit einer Hardware verbunden werden. Hier kommen mehrere Möglichkeiten in Betracht, die jeweils vor und Nachteile aufweisen. Sie werden jetzt nacheinander präsentiert. <br />
<br />
=== Anbindung an die GPIO im Raspberry ===<br />
==== Installation ====<br />
Man kann das HM-MOD-RPI-PCB Modul direkt in die GPIOs eines Raspberry stecken. Das hat den Vorteil, dass das Gerät (mehr oder weniger) sofort betriebsbereit ist, aber den Nachteil, dass am RPi vorher mehrere Installationen zu erfolgen haben. <br />
<br />
Die '''<big>notwendige Konfiguration der Schnittstelle</big>''' ist hier beschrieben: [[Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule|Verwendung UART für Zusatzmodule]].<br />
* Der Einsatz in FHEM für CUL_HM erfolgt mit dem Modul [[HMUARTLGW]]<br />
* Die automatische Erkennung der USB Geräte muss deaktiviert werden: <br />
::<code>attr initialUsbCheck disable 1</code><br />
: Nach dem Setzen des Attributes muss die Änderung gespeichert werden (siehe [[save]])!<br />
<br />
=== Anbindung über das Netzwerk===<br />
Wenn das HM-MOD-RPI-PCB Modul an einen RPi angeschlossen ist, kann man dieses Modul danach auch im Netzwerk verfügbar machen. Dieser Pi kann beliebige Aufgaben erledigen, nur das HM-MOD-RPI-PCB Modul selbst darf nicht lokal verwendet werden. Somit kann man bei einem Umzug des FHEM Servers das HM-MOD-RPI-PCB Modul einfach weiterhin nutzen oder einen vorhandene RaspberryPi zum "HMLAN" umbauen. Sollte man aber ausschließlich Zugriff auf das HM-MOD-RPI-PCB Modul im Netzwerk benötigen, empfiehlt sich auch aus Kostengründen (Stromverbrauch) eine andere Lösung.<br />
<br />
Achtung! Auch über das Netzwerk darf immer '''nur eine Instanz auf das freigegebene Modul zugreifen'''!<br />
<br />
Die Konfiguration der Schnittstelle ist in jedem Fall gleich: [[Raspberry Pi#Verwendung UART für Zusatzmodule|Verwendung UART für Zusatzmodule]]. <br />
<br />
Die [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi#Definition in FHEM 2|Definition in FHEM]] erfolgt dann mit dem Parameter <code>uart:// .</code><br />
<br />
===== Variante mit ser2net =====<br />
[https://forum.fhem.de/index.php/topic,124384.0.html '''Achtung!''' Mit der Version 4 hat sich die Konfiguration geändert!]<br />
<br />
Diese Installation auf dem Pi mit dem HM-MOD-RPI-PCB Modul bitte im Kontext <code>sudo su</code> ausführen. <br />
<br />
Bis zur ser2net '''Version 3'''<br />
<br />
<pre>apt-get install ser2net<br />
echo "4000:raw:0:/dev/ttyAMA0:115200 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE" >> /etc/ser2net.conf<br />
# Den Dienst neu starten<br />
systemctl restart ser2net</pre>Ab der ser2net '''Version 4''' erfolgt die Konfiguration im anderen Format /etc/ser2net.yaml. [https://man.archlinux.org/man/community/ser2net/ser2net.yaml.5.en manpage]<syntaxhighlight lang="bash"><br />
cp /etc/ser2net.yaml /etc/ser2net.yaml.sav<br />
cat <<EOI > /etc/ser2net.yaml<br />
%YAML 1.1<br />
---<br />
# HM_MOD-RPI-PCB<br />
connection: &con01<br />
accepter: tcp,4000<br />
connector: serialdev,<br />
/dev/ttyAMA0,<br />
115200n81,local<br />
EOI<br />
</syntaxhighlight>Zur Kommunikation zwischen FHEM und ser2net auf einem anderen Gerät im Netzwerk kann (mindestens ab Debian Bullseye) zusätzlich die Option "NOBREAK" im Connector (siehe [https://www.mankier.com/8/ser2net manpage]) erforderlich sein.<br />
<br />
In der Service unit müssen Abhängigkeiten eingefügt werden, sonst startet der Dienst nach einem System reboot nicht:<br />
<br />
<code>systemctl edit --full ser2net</code> siehe auch [[Fhem.service (systemd unit file)|Wiki (systemd unit file)]]<syntaxhighlight lang="bash"><br />
[Unit]<br />
Description=Serial port to network proxy<br />
Documentation=man:ser2net(8)<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
EnvironmentFile=-/etc/default/ser2net<br />
ExecStart=/usr/sbin/ser2net -n -c $CONFFILE -P /run/ser2net.pid<br />
Type=exec<br />
Restart=on-failure<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</syntaxhighlight><br />
<br />
===== Variante mit socat =====<br />
Installation auf dem Pi wo das Modul steckt bitte so installieren. <br />
:<code>sudo apt-get install socat</code><br />
Zum Test kann man socat in der Kommandozeile starten<br />
:<code>sudo socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200 </code><br />
<br />
Für den dauerhaften Betrieb muss der Start von socat automatisch erfolgen. <br />
Auf einem Debian Jessie mit systemd legt man z.B. einen Dienst durch folgende Datei an:<br />
/etc/systemd/system/hmlangw.service<br />
<syntaxhighlight lang="Text"><br />
[Install]<br />
WantedBy=multi-user.target<br />
Type=forking<br />
<br />
[Service]<br />
ExecStart=/usr/bin/socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200<br />
User=root<br />
Restart=always<br />
RestartSec=10<br />
</syntaxhighlight><br />
Dann kann mit <br />
:<code>sudo systemctl enable hmlangw </code><br />
der Service zum Autostart konfiguriert werden.<br />
<br />
=== Anbindung mit USB-Adapter ===<br />
{{Randnotiz|RNTyp=r|RNText=Bitte beachten: Es sind immer wieder Exemplare mit [[CP2102]] im Umlauf, die mehr als 3.3V Spannung liefern! Vor dem Verbinden mit dem HM-Modul sollte daher geprüft werden, ob der interne Spannungswandler ordnungsgemäß funktioniert und wirklich nur 3.3V liefert. Bei den blauen Micro-Modulen kann man den Fehler nach dieser Anleitung beheben: [https://www.silabs.com/community/interface/forum.topic.html/cp2102_3_3v_outputi-EaVr Beitrag von PBudmark vom 08.07.2017].}}<br />
[[Datei:PL2102 Modul.png|200px|thumb|right|Mod zur Herstellung der korrekten Spannung]]<br />
Das UART-Modul kann ebenfalls mit einem USB-Adapter an ein USB-fähiges Gerät angeschlossen werden. Allerdings ist hier wieder auf den Spannnungspegel zu achten, unbedingt einen USB-Adapter mit 3,3 Volt Pegel nehmen! Der Vorteil ist hier, dass hohe Geschwindigkeiten möglich sind und nicht wie bei WLAN Latenzen auftreten, aber es muss eben ein USB-Anschluss verfügbar sein.<br />
<br />
Grundsätzlich bewährt haben sich z.B. Modelle mit einem [[CP2102]], der auch ausreichend Stromreserven zum Betrieb des Moduls bietet. Dabei ist die serielle Schnittstelle wie üblich zu kreuzen, also<br />
<br />
'''Verschaltung'''<br />
3.3V <-> 3.3V<br />
GND <-> GND<br />
Rx <-> Tx<br />
Tx <-> Rx<br />
<br />
=== Anbindung mit ESP8266 ===<br />
Hier ist der Vorteil, dass vor Ort nur WLAN verfügbar sein muss. Nachteilig kann sich auswirken, dass WLAN hohe Latenzen aufweisen kann und daher manchmal der Eindruck entsteht, das Modul sei gerade abwesend. <br />
<br />
Zum Anschluss kann ein beliebiger ESP8266 verwendet werden. Mit einigen Versionen (Beispiele im Forum: {{Link2Forum|Topic=102141|Message=956606|LinkText=ESP07}} sowie {{Link2Forum|Topic=102141|LinkText=Wemos mini pro}}) ist eine Anbindung anscheinend nicht oder nur schwer möglich - wobei dies auch an nicht funktionsfähigen Clonen liegen kann oder beim Wemos daran, dass dort die USB-Schnittstelle mit Tx/Rx nicht kalkulierbare Störungen auslöst. Beim ESP8266 gibt es zwei verschiedene Firmware-Möglichkeiten: ESPLink oder ESPEasy. <br />
<br />
[https://github.com/jeelabs/esp-link ESPLink] ist eine sehr stabile und nicht mehr aktiv weiterentwickelte Firmware, die die serielle Schnittstelle direkt mit WLAN verbindet und ohne größere Schwierigkeiten eingerichtet werden kann und funktioniert. Sie nutzt die serielle Schnittstelle des ESP. Allerdings erlaubt ESPLink nicht die Nutzung anderer GPIOs, so können beispielsweise keine anderen Sensoren mit angeschlossen bzw. ausgelesen werden. Verwendet man ESP-Link, so muss neben der WLAN Konfiguration nur das Pin Assignment konfiguriert werden. Alle Pins auf disabled stellen.<br />
<br />
[https://www.letscontrolit.com/wiki/index.php/ESPEasy ESPEasy] (neue Version: ESPMega) wird beständig weiterentwickelt und gestattet es, weitere Sensoren anzuschließen und deren Werte auszulesen. Insbesondere kann man mit ESPEasy auch zwei weitere Pins nutzen, um eine serielle Schnittstelle zu simulieren (so genannter ''serieller Server''). Man spricht auch von einer ''swapped'' Schnittstelle. Die {{Link2Forum|Topic=62651|LinkText=Platine von amunra}} nutzt eine solche Schnittstelle. <br />
Allerdings gibt es mit einigen ESP8266-Geräten Schwierigkeiten, diese serielle Schnittstelle zu nutzen. So ist etwa ein serieller Server mit neueren ESP-Versionen anscheinend nicht lauffähig (siehe dazu {{Link2Forum|Topic=75422|LinkText=diesen Thread}}). Es gibt eine ältere Firmware-Version von PeMue, die unmittelbar funktionsfähig scheint, siehe dazu {{Link2Forum|Topic=86592|LinkText=diesen Forenthread}}. <br />
<br />
[[Datei:Esp-pin Konfiguration HMUART.png|200px|mini|esp-link Pin-Konfiguration beim swapped Server]]<br />
Bei der seriellen Schnittstelle (da die ESP auf 3,3V laufen, sind keine Spannungsteiler erforderlich) findet man die Verschaltung unten. Bei der ''swapped'' Schnittstelle wird auf die digitalen Pins D7/D8 zurückgegriffen (siehe auch unten). Die letztere Verschaltung erfordert eine entsprechende Implementierung der Schnittstelle in der Firmware selbst, die beispielsweise bei ESPEasy unter Umständen nicht gegeben ist oder selbst kompiliert werden muss. <br />
<br />
'''Verschaltung bei einem WeMos D1 mini'''<br />
(UART) <-> (Wemos swapped) <-> (Wemos seriell)<br />
3.3V <-> 3.3V <-> 3.3V<br />
GND <-> GND <-> GND<br />
Rx <-> D8 <-> Tx (D10 oder Tx)<br />
Tx <-> D7 <-> Rx (D9 oder Rx)<br />
<br />
Es gibt eine ausführliche Erläuterung für die Software unter [https://forum.fhem.de/index.php?action=dlattach;topic=56606.0;attach=68630], siehe auch [https://www.esp8266.com/viewtopic.php?f=32&t=18669 diese Grafik der Pins des Wemos]<br />
<br />
Im Forum gibt es mehr Informationen zu diesen Adaptern, zum Beispiel {{Link2Forum|Topic=62651|LinkText="(amunra)-Platine für HM-MOD-UART-RPI..."}} oder {{Link2Forum|Topic=79559|LinkText="3. Sammelbestellung - Homematic WLAN Gateway"}}.<br />
<br />
[[Datei:HM-CFG-WLAN-k.jpeg|thumb|left|200px|Anschluß an Wemos]]<br />
Auf dem linken Foto ist der Anschluss des gesamten Moduls (Rastermaß 2,54mm statt 2mm!) an den Wemos zur Wifi-Einbindung abgebildet.<br />
<br />
=== Betrieb mit einem LAN-TTL-Wandler ===<br />
[[Datei:Hm-uart und usr-tcp232-T2.png|thumb|right|400px|Anschluß an die gängige Variante USR-TCP232-T2]]Auf gängigen Marktplätzen sind für etwas weniger als 10 Euro Module erhältlich, die einen seriellen Anschluss im LAN bereitstellen können. Nähere Hinweise sind in den Artikeln [[Serial TTL to Ethernet Module]] sowie [[1W-IF-ETH]] zu finden.<br />
<br />
Die Module melden sich per DHCP<ref>jedenfalls neuere firmware-Versionen</ref> im Netzwerk an, die Konfiguration erfolgt je nach Variante über ein Web-Interface, ein Windows-Tool oder eine Management-Software.<br />
<br />
=== Betrieb mit MapleCUx ===<br />
Auch die seriellen Schnittstellen, die ein MapleCUL oder [[MapleCUN]] bereitstellen, können zum Anschluß des Moduls verwendet werden. Der MapleCUN stellt beide seriellen Schnittstellen je unter einem eigenen Port ins Netz.<br />
<br />
== Definition in FHEM ==<br />
Die Funktion in FHEM hängt ab von der verwendeten Hardware. Die eigentliche Funktion wird mit dem Modul [[HMUARTLGW]] hergestellt. Alle dortigen Hinweise zur Konfiguration sind zu beachten! Man sollte sich auch mit den Grundlagen der [[HomeMatic]] Kommunikation vertraut machen.<br />
<br />
Je nach physischem Anschluss erfolgt eine Anbindung in FHEM in unterschiedlicher Weise. Folgende Beispiele sind '''abweichend''' von der '''<big>[[HMUARTLGW#Define|Standardkonfiguration]]!</big>'''<br />
<br />
Wurde ein USB-Adapter auf dem FHEM-Gerät selbst verwendet, definiert man das Gerät in FHEM wie folgt.<br />
define USB_HmUART HMUARTLGW /dev/ttyUSBx<br />
Wurde dagegen das Gerät über WLAN oder LAN durch das UART-Modul angebunden, erfolgt die Einbindung in FHEM durch<br />
define WLAN_HmUART HMUARTLGW uart://<IP-Adresse>:<Portnummer><br />
Portnummern:<br />
*ser2net 4000 (bzw. entsprechend gewählter Einstellung)<br />
*socat 2000 (bzw. entsprechend gewählter Einstellung)<br />
*esp-link 23 <br />
*MapleCUN 2324 bzw. 2325 <br />
*USR-TCP232-T2 entspr. Konfiguration.<br />
<br />
=== Logbeispiel ===<br />
Typischerweise meldet sich das Modul beim Start so:<br />
2016.10.06 17:11:16 3: Opening myHmUART device /dev/ttyAMA0<br />
2016.10.06 17:11:16 3: Setting myHmUART serial parameters to 115200,8,N,1<br />
2016.10.06 17:11:16 3: myHmUART device opened<br />
2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_BL<br />
2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_App<br />
<br />
=== Verwendung AES in FHEM===<br />
Das Modul beherrscht AES.<br />
Für weitere Informationen gibt es einen separaten Wiki Eintrag [[AES Encryption]]<br />
<br />
=== Firmware Update des UART-Moduls mit FHEM ===<br />
Die Module werden mit einer Firmware 1.2.1 ausgeliefert. Dies Firmware ist nicht für einen stabilen Betrieb geeignet, die Firmware 1.4.1 ist die minimal lauffähige Version.<br />
<br />
Bitte den Befehl zum download inklusive der Anführungszeichen in die FHEM Kommandozeile eingeben!<br />
<br />
'''Firmware herunterladen'''<br />
* Version 1.4.1<br />
<syntaxhighlight lang="text">"wget -qO ./FHEM/firmware/coprocessor_update.eq3 https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/HM-MOD-UART/coprocessor_update.eq3"</syntaxhighlight><br />
* Alternativ die aktuellste (für den Betrieb mit dem Modul HMUARTLGW '''NICHT''' empfohlen)<br />
<syntaxhighlight lang="text">"wget -qO ./FHEM/firmware/coprocessor_update.eq3 https://raw.githubusercontent.com/eq-3/occu/HEAD/firmware/HM-MOD-UART/coprocessor_update.eq3"</syntaxhighlight><br />
(Firmware neuer als 1.4.1 dient nur bei CCU-Klonen mit Mischbetrieb BidCOs, klassisch HomeMatic und HomeMatic IP, siehe {{Link2Forum|Topic=70752|LinkText=diesen Forenthread}}).<br />
<br />
'''Flashen der neuen Firmware''' <br />
<br />
Erstmal überzeugen das die Firmware da ist: Z.B. mit dem Befehl in der FHEM Kommandozeile, die Ausgabe erfolgt in der Weboberfläche!<br />
<syntaxhighlight lang="text">{qx(ls -lha ./FHEM/firmware)}</syntaxhighlight><br />
Wenn alles ok - Befehl zum flashen ausführen:<br />
<syntaxhighlight lang="text">set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3</syntaxhighlight><br />
<br />
=== Firmware Update des UART-Moduls ohne FHEM ===<br />
Sollte das Update über FHEM nicht funktionieren oder FHEM nicht verfügbar sein, kann die Firmware auch wie folgt eingespielt werden (Quelle: [http://heinz-otto.blogspot.com/2016/07/raspberry-pi-homematic-modul.html Ottos Technik Blog])<br />
<br />
sudo su<br />
apt-get update && apt-get -y install libusb-1.0-0-dev build-essential git<br />
systemctl stop fhem<br />
git clone git://git.zerfleddert.de/hmcfgusb<br />
cd hmcfgusb/<br />
make<br />
# Firmware runterladen<br />
wget https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3<br />
# eigentliches flashen:<br />
./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3<br />
<br />
=== Bekannte Probleme ===<br />
* Sollten beim Flashen der Firmware hartnäckige Probleme auftreten (kein Erfolg aber auch gar keine Fehlermeldungen) ist das Modul vom Strom zu trennen, ein Neustart des Pi reicht nicht!<br />
* Ein {{Link2Forum|Topic=41203|Message=340320|LinkText=Beitrag}} aus dem genannten Forenthread: ''Das Ding ist anscheinend wirklich einfach das Funkmodul aus der CCU2 (wird zumindest in der eQ-3 SW als CCU2 angesprochen) und spricht ein für FHEM vollkommen neues Protokoll.''<br />
* Beim Raspberry 4 gibt es eine Einstellung zur Temperaturkontrolle, die muss deaktiviert werden. Siehe diesen {{Link2Forum|Topic=123223|Message=1178032|LinkText=Beitrag im Forum}}.<br />
* Bei Verwendung mit einem USR TCP232-T2 Wandler kann es in der Default-Einstellung des Wandlers dazu kommen, dass obsolete Kommunikation gepuffert und nach einem Wiederverbinden unnötig an FHEM gesendet wird (siehe {{Link2Forum|Topic=123948|LinkText=dieses Foren-Thema}}). Im FHEM-Log gibt es in diesem Fall die Meldung "HMUART failed to enter App!" Abhilfe schafft das Aktivieren der Option "Buffer Data before connected" unter "Expand Function" im WebUI des TCP-232.<br />
<br />
== Links ==<br />
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM<br />
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}<br />
* [http://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html Produktseite] bei ELV<br />
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}<br />
* {{Link2Forum|Topic=56606|LinkText=Forenthread}} Hardware Thread mit vielen Varianten der Anbindung. In Post #26 gibt es die Detailbeschreibung in der angehängten PDF.<br />
:<hr /><br />
<references /><br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Raspberry Pi]]<br />
[[Kategorie:868MHz]]</div>Cblhttp://wiki.fhem.de/w/index.php?title=CUL_ueber_Netz&diff=37491CUL ueber Netz2022-07-08T11:42:15Z<p>Cbl: /* ser2net */ Ergänzung für Version 4 mit ser2net.yaml</p>
<hr />
<div>Da bei mir [[RFR CUL]] sehr instabil lief, WLAN aber zufriedenstellend, habe ich einen Buffalo WZR-HP-G300NH mit OpenWRT Backfire (10.03.1-rc4) ausgestattet, als WLAN-Client konfiguriert und den CUL am USB-Port betrieben.<br />
<br />
Um den CUL als Quasi-CUN über FHEM anzusprechen, läuft folgendes Script auf dem Router: <br />
#!/bin/sh<br />
<br />
DEV=/dev/ttyACM0<br />
<br />
while (true)<br />
do<br />
/usr/bin/socat -ly -lh GOPEN:$DEV,raw,echo=0 TCP-LISTEN:2323<br />
sleep 2<br />
done<br />
<br />
Zu beachten ist, dass socat in der mitgelieferten Version (1.6.0.1-2) für o.g. Zweck nicht funktioniert. Man kann aber eine neuere Version (1.7.1.3-2) von http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/ herunterladen und installieren.<br />
<br />
Die Konfiguration in fhem ist einfach:<br />
<br />
define cul868 CUL <name-des-geräts>:2323 <fhtid><br />
attr cul868 model CUL<br />
<br />
Anstelle von socat kann man im Notfall auch netcat benutzen. Dazu im Script die Zeile mit socat durch<br />
<br />
netcat -l -p 2323 < $DEV >$DEV<br />
<br />
ersetzen. Allerdings gab es dann häufig Probleme mit der Echo-Einstellung, so dass mehrere Anläufe erforderlich waren, bis es nach einen Reboot stabil läuft. <br />
<br />
==ser2net==<br />
Statt socat kann man auch ser2net verwenden. Hierzu das standard ser2net Paket installieren und in /etc/ser2net.conf so konfigurieren:<br />
2000:raw:0:/dev/ttyACM0:38400 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE<br />
<br />
Danach den CUL in fhem anlegen:<br />
define cul CUL<ip>:2000 0000<br />
<br />
Natürlich lassen sich auch mehrere CUL, panStick, JeeLink oder miniCul einrichten. Hierzu ist dann jeweils ein eigener Port zu verwenden und die Geschwindigkeit passend zu setzen:<br />
<pre><br />
#cul<br />
2000:raw:0:/dev/ttyACM0:38400 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE<br />
2001:raw:0:/dev/ttyACM1:38400 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE<br />
<br />
#panStick<br />
2002:raw:0:/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900LDNL-if00-port0:38400 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE<br />
<br />
#JeeLink<br />
2003:raw:0:/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AE01DTXW-if00-port0:57600 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE<br />
<br />
#miniCul<br />
2004:raw:0:/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IDI4-if00-port0:38400 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE<br />
</pre>Ab der ser2net '''Version 4''', die z.B. ab Debian Bullseye enthalten ist, erfolgt die Konfiguration in einem anderen Format: /etc/ser2net.yaml. Siehe [https://man.archlinux.org/man/community/ser2net/ser2net.yaml.5.en manpage] Im Wiki gibt es ein Beispiel bei [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi#Variante mit ser2net|HM-MOD-RPI-PCB]].<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:CUL]]<br />
[[Kategorie:Glossary]]</div>Cbl