FHEMWiki - Benutzerbeiträge [de]

LightScene

2025-02-07T19:05:13Z

F Klee: Define aus commandref eingefügt

{{Infobox Modul
|ModPurpose=Speicherung und Wiederherstellung des Zustands von einer Gruppe von Geräten.
|ModType=h


|ModTechName=31_LightScene.pm
|ModOwner=justme1968
}}

'''LightScene''' ist ein Hilfsmodul, das es erlaubt, Zustände einer Gruppe von Geräten abzuspeichern und wiederherzustellen.

== Anwendung ==
=== Define ===
:<code>define <name> LightScene [<dev1>] [<dev2>] [<dev3>] ... </code>
:Beispiele:<syntaxhighlight>
define light_group LightScene Lampe1 Lampe2 Dimmer1
define kino_group LightScene LampeDecke LampeFernseher Fernseher Verstaerker
define Wohnzimmer LightScene Leinwand Beamer TV Leselampe Deckenlampe
</syntaxhighlight>Die Gerätedetailansicht zeigt eine HTML-Übersicht über den aktuellen Zustand aller eingebundenen Geräte und aller konfigurierten Szenen mit den jeweiligen Gerätezuständen. Die Spaltenüberschrift mit den Gerätenamen ist anklickbar, um zur Detailansicht dieses Geräts zu gelangen. Die erste Zeile, die den aktuellen Gerätezustand anzeigt, ist anklickbar und sollte wie ein Klick auf das Gerätesymbol in einer Raumübersicht reagieren. Damit kann interaktiv eine neue Szene konfiguriert und mit dem Befehlsmenü der Detailansicht gespeichert werden. Die erste Spalte der Tabelle mit den Szenennamen ist anklickbar, um die Szene zu aktivieren.
:Ein Weblink mit einer Szenenübersicht, der in jeden Raum oder Grundriss eingebunden werden kann, lässt sich erstellen mit:<syntaxhighlight>
define wlScene weblink htmlCode {LightScene_2html("LightSceneName")}
</syntaxhighlight>

=== Set ===

=== Get ===

=== Attributes ===

== Funktionen ==

== Anwendungsbeispiele ==
* [[XBMC#Lichtsteuerung_durch_KODI_oder_PLEX|Lichtsteuerung durch KODI oder PLEX]]
* [[Zuhause-Status|Umsetzung Zuhause-Status mit LightScene]]
* [[ReadingsGroup#LightScene_DropDown-Men.C3.BC_f.C3.BCr_smallscreen_Styles_oder_Floorplan|LightScene-DropDown-Menü für Smallscreen-Styles oder Floorplan]]

== Links ==
* weitere Dokumentation
* ...

Stromzähler auslesen

2025-01-12T12:27:07Z

F Klee: Hichi zu den Kombigeräten hinzu gefügt.

"EM" in FHEM steht für "EnergieMessung", der Stromzähler im Haushalt ist also ein naheliegendes Objekt der Erfassung durch FHEM.
In Deutschland waren 2018 noch 78% der Stromzähler klassische elektromechanische Zähler <ref>https://de.statista.com/statistik/daten/studie/298727/umfrage/verteilung-der-zaehlertechnik-in-deutschen-haushalten/</ref>, auch [https://de.wikipedia.org/wiki/Ferraris-Z%C3%A4hler Ferraris-Zähler] genannt. Neben dem Zwischenschritt, der elektronischen Messeinrichtung, dürfen heute aber nur noch [https://www.bundesnetzagentur.de/SharedDocs/A_Z/M/ModerneMesseinrichtung.html moderne Messeinrichtungen] ("mMe") verbaut werden, und sollen bis 2032 komplett ersetzt werden. <ref>https://www.bundesnetzagentur.de/DE/Sachgebiete/ElektrizitaetundGas/Verbraucher/Metering/SmartMeter_node.html</ref>
Die dritte Gruppe sind die [https://www.bundesnetzagentur.de/SharedDocs/Mediathek/Verbraucherhefte/Energie/IntelligentesMessystem_SmartMeter.pdf Intelligenten Messsysteme]. Bei diesen überträgt zusätzlich zu den modernen Messeinrichtungen ein SmartMeterGateway viertelstündlich die Zählerstände zum Messstellenbetreiber. Eine Ablesung durch den Nutzer selber oder den Betreiber entfällt damit. Das SmartMeterGateway soll zusätzlich auch einen Steuerungsrückkanal z.B. für Ladesäulen im Haushalt zur Verfügung stellen - diese Spezifikationen sind allerdings noch teilweise (Stand 2020) in der Entwicklung.

== Anwendungsfälle der Verbrauchserfassung ==
[[Datei:Verbrauchssteuerung mit FHEM.jpeg|mini|Steuerung zweier Hausverbraucher (Heizkreispumpe, Tiefkühltruhe) über FHEM. Nach Abschluss der Heizphase der Waschmaschine wird die Heizkreispumpe eingeschaltet, was wiederum kurz danach einen Start des Brenners auslöst. Mit kurzer Verzögerung wird nach dem Abschalten des Brenners der Tiefkühlschrank eingeschaltet.]]

=== Ohne eigene Stromerzeugung: ===
* Abrechnung von Nutzungszeiträumen, z.B. bei einer überlassenen Ferienwohnung
* Selbstanreiz zum Stromsparen durch zeitnahes Feedback (z.B.: Tagesvergleich, Wochenvergleich)
* Ermitteln der eigenen Tageslastkurve (Stromverbrauch nach Uhrzeit), um qualifiziert das Eigenverbrauchspotential bei einer Solaranlage vorab abschätzen zu können
* Überwachung des 24-h-Mindestverbrauchs: Ist der Mindestwert des Stromverbrauch auf Minutenbasis im Vergleich zum Vortag angestiegen, liegt der Verdacht nahe, dass entweder ein signifikanter Standby-Verbraucher hinzugekommen ist, oder z.B. ein Kellerlicht vergessen wurde.

=== Mit eigener Stromerzeugung (Solar etc.): ===
* Bestimmung des Eigenverbrauchs / der Autarkie-Quote
* Signalisierung der Überschuss-Situation, z.B. durch eine farbige Lampe in der Wohnung ("Licht aus = kein Überschuss, dunkelrot = bis 500 Watt Überschuss, grün = 500-2000 Watt Überschuss, hellblau = > 2000 Watt Überschuss), um Großverbraucher bewusst einzuschalten.
* Automatische Steuerung von Stromverbrauchern je nach Überschuss: Wärmepumpe, Wallbox, Waschmaschine / Trockner / Geschirrspüler, Tiefkühltruhe

== Schnittstellen ==
[[Datei:Stromzaehler ohne.jpeg|mini|D0-Schnittstelle an einer modernen Messeinrichtung oben rechts]]

=== D0-Schnittstelle ===
[[Datei:Stromzaehler mit.jpeg|mini|... und mit angebrachtem IR-Schreib/Lese-Kopf]]
Für den Nutzer spielt der Unterschied zwischen moderner Messeinrichtung und intelligentem Messsystem vor allem preislich eine Rolle: Die Grundgebühr für den Messstellenbetrieb, die bei der modernen Messeinrichtung z.Zt. auf 20€ im Jahr begrenzt ist, ist beim intelligenten Messsystem gestaffelt höher. An der Schnittstelle zum Nutzer ändert sich nichts: In der Regel verfügen moderne Messeinrichtung wie auch intelligentes Messsystem über eine digitale optische Schnittstelle für den Kunden: Die D0-Schnittstelle nach DIN EN 62056-21. Diese Schnittstelle findet sich in der Regel in Form eines durch eine Erhebung auf der Frontseite des Zählers gebildeten Kreises mit je einer IR-Leucht- und einer Foto-Diode am Zähler. Auf der Rückwand ist i.d.R. eine Eisenplatte angebracht, die es erlaubt, einen optischen Lesekopf mit Magneten stabil auf dem Zähler zu platzieren. Auf der D0-Schnittstelle werden - ggf. nach einmaliger oder regelmässiger Aktivierung durch eine PIN - regelmäßig (ggf. sekündlich) sowohl momentane Lastwerte (Watt) als auch Zählerstände ausgegeben.

=== S0-Schnittstelle ===
Ältere Zähler oder frei am Markt verfügbare Zwischenzähler bieten hingegen oft lediglich eine [https://de.wikipedia.org/wiki/S0-Schnittstelle S0-Schnittstelle]. Die S0-Schnittstelle entspricht der alten roten Markierung auf der Drehscheibe des Ferrariszählers: Sie liefert Impulse, deren Auftreten den Verbrauch von z.B. einer Wattstunde (Wh) signalisiert. Damit kann durch ununterbrochenes Mitzählen der Impulse der Verbrauch in relativ grober zeitlicher Auflösung erfasst werden. Neben der gröberen zeitlichen Auflösung lassen sich aber absolute Zählerstände nicht einlesen, und eine Unterbrechung der Erfassung kann nicht automatisch korrigiert werden. Eine Beschreibung, eine S0-Schnittstelle in FHEM verfügbar zu machen und mit dem Modul ElectricityCalculator auszuwerten, befindet sich z.B. [https://haus-automatisierung.com/projekt/2019/04/21/projekt-s0-zaehler-loxone-fhem.html hier].

=== Vorläufer-Lösungen ===
Auch für Ferraris-Zähler wurden optische Auslese-Lösungen entwickelt. Diese werden hier aber nicht beschrieben, weil der Hardware-Aufwand für eine Lösung, die ohnehin absehbar abgeschaltet wird, nicht lohnenswert ist.

=== RS485 Schnittstelle ===
Einige Zähler und Netzbetreiber erlauben das Auslesen über eine serielle RS485 Schnittstelle, welche ansonsten von einem Smartmeter-gateway genutzt werden würde. Ist die Schnittstelle nicht belegt durch eine Einrichtung des Netzbetreibers, dann ist es hiermit ebenfalls möglich, die Daten des Stromzählers analog zur D0 Schnittstelle auszulesen.

== Voraussetzungen für die Erfassung ==
=== Eine Moderne Messeinrichtung erhalten ===
Grundsätzlich obliegt es dem Messstellenbetreiber, über den Zeitpunkt des Einbaus einer modernen Messeinrichtung bis spätestens 2032 zu entscheiden. Die Entscheidung kann durch folgende Schritte des Benutzers forciert werden:
* Gespräch mit dem Messstellenbetreiber
* Verbrauch von mehr als 6000 kWh im Jahr
* Betrieb einer steckerfertigen Solaranlage: Denn die Mehrzahl der Ferrariszähler würden sich beim Betrieb einer steckerfertigen Solaranlage ("Balkon-Kraftwerk", "Guerilla-PV") rückwärts drehen, da sie nicht über eine Rücklaufsperre verfügen. Dieses Rückwärtsdrehen des Zähler entspräche einem Verstoß gegen verschiedene Vorschriften, insbesondere auch ein Steuervergehen im Sinne der Stromsteuer.
* Inbetriebnahme einer "großen" Solar-Dachanlage

=== D0-Schnittstelle aktivieren ===
In Deutschland zeigt eine moderne Messeinrichtung i.d.R. nach dem Einbau lediglich den Zählerstand in kWh ohne Nachkommastelle an. Auch die optische D0-Schnittstelle ist entweder überhaupt nicht aktiviert, oder sendet lediglich diesen ungenauen Zählerstand. In Österreich ist die D0-Schnittstelle hingegen i.d.R. aktiviert, sendet aber verschlüsselt Daten aus. In Deutschland muss der Kunde die genaue Auflösung des Zählers erst per PIN aktivieren. Diese kann vom Messstellenbetreiber i.d.R. problemlos angefordert werden, und muss dann an der D0-Schnittstelle z.B. mit einer Taschenlampe "hineingemorsed" werden. Die Netzbetreiber stellen i.d.R. in Zusammenarbeit mit den Herstellern der Zähler hierfür Anleitungen bereit. Beispielhaft ein Video zur [https://www.youtube.com/watch?v=TonPnmOtBM0 ISKRA-Zählerfreischaltung].

Ist "der Datenschutz" erst einmal "weggemorsed", ergeben sich durch die direkte Anzeige des Live-Verbrauchs in Watt bereits Vorteile: Die Suche nach Standby-Verbrauchern kann unmittelbar am Stromzählerschrank über das Abschalten von Sicherungskreisen eingegrenzt werden.

== Anbindungsoptionen an FHEM ==
Die Lösungen zum Auslesen beginnen bei der Befestigung einer Fotodiode mit Knetmasse oder Klebeband, einem Pullup-Widerstand und der direkten Verknüpfung mit GPIO-Ports eines Raspberry.
<ref>[https://wiki.volkszaehler.org/hardware/controllers/ir-schreib-lesekopf-pi-ausgang Einfachlösung von Volkszaehler.org]</ref>
Da manche Zähler allerdings erst nach Senden einer Anforderung ihrerseits Daten versenden, ist für diese Zähler auch eine sendende IR-LED notwendig. Das erste Unterscheidungsmerkmal ist also "Nur Lesen" versus "Lesen / Schreiben". Die weitere Unterscheidung ist insbesondere die computerseitige Schnittstelle:
* TTL-Ausgang zur Verbindung mit einem GPIO-Port z.B. eines ESP8266 (z.B. Wemos D1) oder einem Raspberry
* USB-Ausgang zur Verbindung mit einem USB-Port (z.B. am Raspberry)
* Kombigeräte mit direkt verbundenem ESP8266
* "poweropti" von Power 42 GmH ("powerfox")
=== USB-IR-Köpfe ===
Generell ist für Nutzer ohne Lötkolbenerfahrung, die ihre FHEM-Hardware in USB-Entfernung zum Schaltschrank betreiben, der USB-Anschluss sicherlich die einfachste Möglichkeit. Neben Selbstbauanleitungen und 3D-Drucker-Files wie sie insbesondere vom Projekt [https://volkszaehler.org Volkszaehler.org] veröffentlicht wurden, gibt es hier auch zahlreiche Anbieter. Das reicht von Bastlern, die eine Überschussproduktion an Platinen fertig aufgebaut für unter 20 Euro anbieten <ref>https://wiki.volkszaehler.org/hardware/controllers/ir-schreib-lesekopf-usb-ausgang</ref>, geht über professionelle ebay-Angebote z.B. der Verkäufer o_electronics_o und anderer Anbieter zwischen 20-25 Euro bis zum oft eingesetzten "Weidmann-Schreib/Lesekopf".

Sofern am FHEM-Computer noch ein USB-Port frei ist und die Stromversorgung ausreicht, genügt hier hardwareseitig das Andocken des Lesekopfes mit dem Kabel nach unten zeigend und das Einstecken in einen freien USB-Port. Unter FHEM wird das Modul 47_OBIS.pm eingebunden.

=== TTL-IR-Köpfe ===
Ist der "FHEM-Hauptcomputer" weiter vom Stromzähler entfernt (z.B. wegen eines angeschlossenen Displays oder mangelnder Reichweite angeschlossener Funklösungen in Zählerschranknähe), sind aber beim Stromzähler eine Steckdose und ausreichende WLAN-Abdeckung gegeben, so bietet sich ein TTL-Lesekopf in Verbindung mit einem ESP8266 als nicht ganz lötfreie, aber sparsame Lösung an. Hierbei kann zwischen folgenden Lösungen unterschieden werden:
* Der ESP8266 überträgt lediglich die Rohdaten der seriellen Schnittstelle per TCP zu FHEM. Eine vollständige Lösung (inkl. 3D-Drucker-Dateien) mit ESPEasy ist [https://mwinkler.jimdo.com/smarthome/aktoren-sensoren/stromz%C3%A4hler-digital/ hier] von Michael Winkler beschrieben. Auf FHEM-Seite dekodiert ebenfalls 47_OBIS.pm den Datenstrom
* Die SML-Dekodierung erfolgt auf dem ESP8266, und dieser liefert per MQTT die Daten an FHEM. Eine Lösung ist die Software [https://github.com/mruettgers/SMLReader SMLReader] von Michael Rüttgers, eine andere das [https://tasmota.github.io/docs/Smart-Meter-Interface/ SmartMeter-Interface von Tasmota].

=== Kombigeräte mit direkt verbundenem ESP8266 oder ESP32 ===
Eine fertige Lösung (IR-Lesekopf mit ESP8266 und Gehäuse) wird z.B. vom ebay-Verkäufer peterling11 vertrieben. Das Gerät kann nach Wunsch entweder direkt MQTT senden, oder es arbeitet über ser2net mit dem FHEM 47_OBIS-Modul zusammen. Der Vorteil in beiden Fällen: Der Stromzähler muss lediglich WLAN-Versorgung haben.

Wer bei eBay oder Amazon nach Hichi sucht, findet weitere (fast) fertige Lösungen auf Tasmota-Basis (nicht nur Hichi). Benötigt wird nur noch ein USB-Netzteil. Je nach Stromzähler-Typ muss noch das passende Script von der [https://tasmota.github.io/docs/Smart-Meter-Interface/ Tasmota-Seite] eingespielt werden. Die Daten werden dann per MQTT an FHEM gesendet. An die V2 mit ESP32 können zusätzlich noch TTL-IR-Köpfe für weitere Zähler angeschlossen werden.

=== poweropti ===
Der "poweropti" der power 42 GmbH ist eine Cloud-Lösung, die diverse Funktionen für den Endanwender in der Cloud bereitstellt. Das Gerät kommt Adaptern, Support und App und ist durchgängig auf Otto-Normal-Anwender ausgerichtet (Erklärvideos, QR-Codes scannen, App, u.s.w.). Der Hersteller stellt eine API bereit, die es u.a. erlaubt, die Parameter "aktuelle Watt-Zahl", bezogene und gelieferte kWh mit einer Auflösung von 10 Sekunden auszulesen. Eine interne Schnittstelle im heimischen LAN ist wohl vorhanden, allerdings nicht dokumentiert. Daher müssen diese Werte per HTTPMOD aus der Cloud nach FHEM zurückgelesen werden. Die Einbindung in FHEM ist hier beschrieben: [[poweropti]].

== Referenzen ==
<references />

Z-Wave-Eurotronic Spirit Thermostat

2024-10-05T18:05:03Z

F Klee: /* Features */ Link zum Handbuch eingefügt

{{Infobox Hardware
|Bild=platzHalter.png
|Bildbeschreibung=todo
|HWProtocol=Z-Wave Plus
|HWType=Aktor, Empfänger und Sender, Sensor
|HWCategory=Z-Wave
|HWComm=Funk 868MHz
|HWChannels=
|HWVoltage=3V
|HWPowerConsumption=
|HWPoweredBy=2xBatterie AA Mignon
|HWSize=
|HWDeviceFHEM=[http://fhem.de/commandref.html#ZWave Z-Wave]
|HWManufacturer=[https://eurotronic.org/ EUROTRONIC Technology GmbH]
}}

[[Z-Wave-Eurotronic Spirit Thermostat]] ist ein Heizungsthermostat mit Z-Wave 500er-Serie-Chip und Z-Wave Plus-Zertifizierung

== Features ==
* [[Z-Wave#FLIRS-Ger.C3.A4te|FLiRS-Gerät]]
* siehe [https://eurotronic.org/wp-content/uploads/2024/06/bedienungsanleitung-spirit-z-wave-plus-de.pdf Handbuch]

== Hinweise zum Betrieb mit FHEM ==
=== Inklusion ===
Der Aktor wird bei der Inklusion und aktiviertem [[Autocreate|autocreate]] vollautomatisch erkannt und definiert.

Eine beispielhafte durch autocreate erzeugte Definition mit Hinweisen zu manuellen Ergänzungen findet sich unter [[#Definition|Definition]].

=== Assoziation ===
Der Controller muss zur korrekten Funktion in die Assoziationsgruppe 1 des Thermostats aufgenommen werden. Dies geschieht während der Inklusion durch FHEM automatisch durch Absetzen des folgenden Befehls:
:<code>set <device> associationAdd 1 <Controller-NodeID></code>

Die erfolgreiche Ausführung des Befehls während der Inklusion durch Abfrage überprüfen:
:<code>get <device> associationAll</code>

=== Konfiguration ===
Konfigurationsanpassungen des Thermostates an eigene Wunschvorstellungen können anschließend vorgenommen werden.

Abschließend ist es sinnvoll die Konfiguration zu Sicherungs- und Kontrollzwecken komplett abzurufen:
:<code>get <device> configAll</code>

=== Befehle zur Steuerung ===
{{Hinweis|Das Thermostat antwortet bei Einstellungen per Funk mit einem set-Befehl mit einem Ack-Telegramm über die vorgenommene Änderung, sendet aber keine explizite Änderung des Werts. Um die entsprechenden Readings aktuell zu halten und die erfolgreiche Übermittlung des set-Befehls zu kontrollieren kann bei ZWDongle als Interface das Attribut ''setReadingOnAck'' gesetzt werden. Dies hat allerdings den Nachteil, dass auch ungültige Befehle als ausgeführt angezeigt werden. Alternativ kann der zugehörige get-Befehl, der im Folgenden jeweils aufgeführt wird, verwendet werden, was aber zusätzlichen Funkverkehr erzeugt. Bei Änderungen über die Bedienung am Gerät wird FHEM hingegen per Telegramm über die vorgenommene Änderung informiert.}}

==== Betriebsmodi ====
Die nachfolgende Tabelle enthält die Aktivierungsbefehle für alle Betriebsmodi des Thermostats. Weitere Modi (tmCooling, tmAuto, tmFan) werden vom Gerät -obwohl von FHEM angeboten- nicht unterstützt.

{| class="wikitable"
|-
!Befehl!!Beschreibung
|-
|<code>set <device> tmOff</code>||Aus-Modus: Aus mit Regelung auf 6°C als Frostschutz
|-
|<code>set <device> tmHeating</code>||Komfortmodus: Regelung entsprechend [[#Komfortmodus|Solltemperatur Komfortmodus]]
|-
|<code>set <device> tmEnergySaveHeating</code>||Absenkmodus: Regelung entsprechend [[#Absenkmodus|Solltemperatur Absenkmodus]]
|-
|<code>set <device> tmFullPower</code>||Boostmodus: schnellstmögliche Raumaufheizung für maximal 5 Minuten
|-
|<code>set <device> tmManual</code>||Stellwertmodus (Manufacturer Specific): Ventilöffnung über Command Class SWITCH_MUTILEVEL einstellen
|}

Abfrage des eingestellten Betriebsmodus mit: <code>get <device> thermostatMode</code>

Steuerungsbefehle der Command Class SWITCH_MUTILEVEL ausschließlich für den Stellwertmodus (tmManual):

{| class="wikitable"
|-
!Befehl im Stellwertmodus!!Beschreibung
|-
|<code>set <device> dim %</code>|| Ventilöffnung von 0% bis 100%, wobei 99 = 100%
|-
|<code>set <device> on</code>||letzten Ventilöffnungsgrad einstellen; sinnvoll beispielsweise nach Aus-Modus (tmOff)
|-
|<code>set <device> off</code>||kleinstmögliche Ventilöffnung; entspricht 0%
|-
|}

Im Stellwertmodus erfolgt keine automatische Temperaturregelung durch das Spirit, sondern diese muss durch separate Logik (beispielsweise mit Hilfe von [[PID20 - Der PID-Regler|PID20]]) überwacht und geregelt werden.

Der Öffnungsstand wird mit <code>get <device> swmStatus</code> abgefragt. Zudem kann mit der Parameternummer 6 der Command Class CONFIGURATION der automatische Versand des Ventilöffnungsgrades bei bestimmten Veränderungen eingeschaltet werden (configValveOpeningPercentageReport).

==== Solltemperaturen ====
Die Solltemperaturen in den Modi Komfortmodus (tmHeating) und Absenkmodus (tmEnergySaveHeating) lassen sich im Temperaturbereich 8°C bis 28 °C anpassen. Die Solltemperatur für den Absenkmodus lässt sich ausschließlich per Funk anpassen. Im Aus-Modus (tmOff) und Boostmodus (tmFullPower) ist keine Anpassung möglich.

Die Einstellung der Solltemperaturen erfolgt mit dem set-Befehl <code>thermostatSetpointSet</code> oder dem funktionsgleichen set-Befehl <code>desired-temp</code>. Der letzte Befehl wurde zur Angleichung an andere Module eingeführt und im folgenden genutzt.

===== Komfortmodus =====
Die Solltemperatur auf NN.N °C wird mit folgendem Kurzbefehl eingestellt:

<code>set <device> desired-temp NN.N</code>

Dies entspricht dem ausführlichen Befehl:

<code>set <device> desired-temp NN.N C 1</code>

Die eingestellte Solltemperatur abrufen:

<code>get <device> setpoint 1</code>

oder mit dem Kurzbefehl

<code>get <device> setpoint</code>

===== Absenkmodus =====
Die Solltemperatur auf NN.N °C wird mit folgendem Befehl eingestellt:

<code>set <device> desired-temp NN.N C 11</code>

Die eingestellte Solltemperatur abrufen:

<code>get <device> setpoint 11</code>

==== Kindersicherung ====
{| class="wikitable"
|-
!Befehl!!Beschreibung
|-
|<code>set <device> protectionOff</code>||Ungeschützt - Bedienung am Gerät uneingeschränkt möglich
|-
|<code>set <device> protectionSeq</code>||Eingeschränkt - Bedienung am Gerät erst nach Entsperrung am Gerät (gleichzeitiges Drücken von {{Taste|+}} und {{Taste|-}} für 3 Sekunden)
|-
|<code>set <device> protectionOn</code>||Deaktiviert - Bedienung am Gerät deaktiviert und Steuerung ausschließlich per Funk
|}

Abfrage der eingestellten Kindersicherung mit: <code>get <device> protection</code>

=== Definition ===
Ein Beispiel für ein Spirit FHEM-Device enthält der nachfolgende exemplarische Auszug aus der [[Konfiguration]]:
define ZWave_THERMOSTAT_53 ZWave e345c452 53
attr ZWave_THERMOSTAT_53 IODev ZWDongle
attr ZWave_THERMOSTAT_53 classes ZWAVEPLUS_INFO ASSOCIATION ASSOCIATION_GRP_INFO VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY PROTECTION SENSOR_MULTILEVEL SWITCH_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT BATTERY
CONFIGURATION ALARM POWERLEVEL SECURITY SECURITY_S2 TRANSPORT_SERVICE SUPERVISION FIRMWARE_UPDATE_MD
attr ZWave_THERMOSTAT_53 extendedAlarmReadings 1
attr ZWave_THERMOSTAT_53 room ZWave
attr ZWave_THERMOSTAT_53 stateFormat temperature
attr ZWave_THERMOSTAT_53 vclasses ALARM:8 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:1 POWERLEVEL:1 PROTECTION:1 SECURITY:1 SECURITY_S2:1
SENSOR_MULTILEVEL:5 SUPERVISION:1 SWITCH_MULTILEVEL:1 THERMOSTAT_MODE:3 THERMOSTAT_SETPOINT:3 TRANSPORT_SERVICE:2 VERSION:2 ZWAVEPLUS_INFO:2
Im vorstehenden Beispiel wurde manuell das Attribut <code>extendedAlarmReadings</code> auf <code>1</code> gesetzt, damit für die diversen Alarmarten einfacher unterscheidbare Events erzeugt und separate Readings angelegt werden. Zudem wurde manuell das Attribut <code>stateFormat</code> angelegt. Sämliche anderen Angaben der Defintion nebst Attributen wurden von FHEM bei der Inklusion automatisch durch autocreate angelegt.

=== Logbeispiel ===
2018-10-19_18:04:14 ZWave_THERMOSTAT_53 setpointTemp: 18.0 C energySaveHeating
2018-10-19_18:04:34 ZWave_THERMOSTAT_53 setpointTemp: 22.0 C heating
2018-10-19_18:04:54 ZWave_THERMOSTAT_53 thermostatMode: heating
2018-10-19_18:05:03 ZWave_THERMOSTAT_53 thermostatSetpointSupported: heating energySaveHeating
2018-10-19_18:05:13 ZWave_THERMOSTAT_53 version: Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.10
2018-10-19_18:05:24 ZWave_THERMOSTAT_53 zwavePlusInfo: version:01 role:SleepingListeningSlave node:Z-Wave+Node installerIcon:1200 userIcon:1200
2018-10-19_18:06:32 ZWave_THERMOSTAT_53 alarm_System: Event cleared: unknown event 0, notificationIsOn
2018-10-19_18:08:02 ZWave_THERMOSTAT_53 battery: 100 %
2018-10-19_18:08:02 ZWave_THERMOSTAT_53 batteryState: ok
2018-10-19_18:08:02 ZWave_THERMOSTAT_53 batteryPercent: 100
2018-10-19_18:10:10 ZWave_THERMOSTAT_53 temperature: 23.27 C
2018-10-19_18:18:10 ZWave_THERMOSTAT_53 temperature: 22.73 C
2018-10-19_18:30:10 ZWave_THERMOSTAT_53 temperature: 22.29 C
2018-10-19_19:00:17 ZWave_THERMOSTAT_53 thermostatMode: energySaveHeating
2018-10-19_19:00:55 ZWave_THERMOSTAT_53 thermostatMode: off
2018-10-19_19:06:10 ZWave_THERMOSTAT_53 temperature: 21.75 C
2018-10-19_23:22:18 ZWave_THERMOSTAT_53 thermostatMode: energySaveHeating
2018-10-19_23:27:31 ZWave_THERMOSTAT_53 set_tmHeating
2018-10-19_23:27:32 ZWave_THERMOSTAT_53 tmHeating

== Links ==
* [https://products.z-wavealliance.org/products/2543 Eintrag in http://products.z-wavealliance.org mit Handbuch und mehr]
* [https://eurotronic.org/wp-content/uploads/2024/06/bedienungsanleitung-spirit-z-wave-plus-de.pdf deutsches Handbuch auf Hersteller-Webseite]
* Nutzung eines direkt assozierten Fenstersensors zur Fenster-Offen-Erkennung: {{Link2Forum|Topic=92206}}
* setList-Attribut: {{Link2Forum|Topic=112955|Message=1092262|LinkText=Temperaturwerte eines Nicht-ZWave-Gerätes an das Spirit zur Regelung übermitteln}} ({{Link2Forum|Topic=77598|Message=701397|LinkText=bisheriger Hack}})
* {{Link2Forum|Topic=77598|Message=854445|LinkText=Nutzung des Modul PID20 zur Temperaturregelung im Stellwertmodus (tmManual)}}

[[Kategorie:Z-Wave Components|Sensor]]
[[Kategorie:Heizungsventile]]

Z-Wave-Eurotronic Spirit Thermostat

2024-10-05T18:02:48Z

F Klee: Link zur Bedienungsanleitung aktualisiert

{{Infobox Hardware
|Bild=platzHalter.png
|Bildbeschreibung=todo
|HWProtocol=Z-Wave Plus
|HWType=Aktor, Empfänger und Sender, Sensor
|HWCategory=Z-Wave
|HWComm=Funk 868MHz
|HWChannels=
|HWVoltage=3V
|HWPowerConsumption=
|HWPoweredBy=2xBatterie AA Mignon
|HWSize=
|HWDeviceFHEM=[http://fhem.de/commandref.html#ZWave Z-Wave]
|HWManufacturer=[https://eurotronic.org/ EUROTRONIC Technology GmbH]
}}

[[Z-Wave-Eurotronic Spirit Thermostat]] ist ein Heizungsthermostat mit Z-Wave 500er-Serie-Chip und Z-Wave Plus-Zertifizierung

== Features ==
* [[Z-Wave#FLIRS-Ger.C3.A4te|FLiRS-Gerät]]
* siehe Handbuch

== Hinweise zum Betrieb mit FHEM ==
=== Inklusion ===
Der Aktor wird bei der Inklusion und aktiviertem [[Autocreate|autocreate]] vollautomatisch erkannt und definiert.

Eine beispielhafte durch autocreate erzeugte Definition mit Hinweisen zu manuellen Ergänzungen findet sich unter [[#Definition|Definition]].

=== Assoziation ===
Der Controller muss zur korrekten Funktion in die Assoziationsgruppe 1 des Thermostats aufgenommen werden. Dies geschieht während der Inklusion durch FHEM automatisch durch Absetzen des folgenden Befehls:
:<code>set <device> associationAdd 1 <Controller-NodeID></code>

Die erfolgreiche Ausführung des Befehls während der Inklusion durch Abfrage überprüfen:
:<code>get <device> associationAll</code>

=== Konfiguration ===
Konfigurationsanpassungen des Thermostates an eigene Wunschvorstellungen können anschließend vorgenommen werden.

Abschließend ist es sinnvoll die Konfiguration zu Sicherungs- und Kontrollzwecken komplett abzurufen:
:<code>get <device> configAll</code>

=== Befehle zur Steuerung ===
{{Hinweis|Das Thermostat antwortet bei Einstellungen per Funk mit einem set-Befehl mit einem Ack-Telegramm über die vorgenommene Änderung, sendet aber keine explizite Änderung des Werts. Um die entsprechenden Readings aktuell zu halten und die erfolgreiche Übermittlung des set-Befehls zu kontrollieren kann bei ZWDongle als Interface das Attribut ''setReadingOnAck'' gesetzt werden. Dies hat allerdings den Nachteil, dass auch ungültige Befehle als ausgeführt angezeigt werden. Alternativ kann der zugehörige get-Befehl, der im Folgenden jeweils aufgeführt wird, verwendet werden, was aber zusätzlichen Funkverkehr erzeugt. Bei Änderungen über die Bedienung am Gerät wird FHEM hingegen per Telegramm über die vorgenommene Änderung informiert.}}

==== Betriebsmodi ====
Die nachfolgende Tabelle enthält die Aktivierungsbefehle für alle Betriebsmodi des Thermostats. Weitere Modi (tmCooling, tmAuto, tmFan) werden vom Gerät -obwohl von FHEM angeboten- nicht unterstützt.

{| class="wikitable"
|-
!Befehl!!Beschreibung
|-
|<code>set <device> tmOff</code>||Aus-Modus: Aus mit Regelung auf 6°C als Frostschutz
|-
|<code>set <device> tmHeating</code>||Komfortmodus: Regelung entsprechend [[#Komfortmodus|Solltemperatur Komfortmodus]]
|-
|<code>set <device> tmEnergySaveHeating</code>||Absenkmodus: Regelung entsprechend [[#Absenkmodus|Solltemperatur Absenkmodus]]
|-
|<code>set <device> tmFullPower</code>||Boostmodus: schnellstmögliche Raumaufheizung für maximal 5 Minuten
|-
|<code>set <device> tmManual</code>||Stellwertmodus (Manufacturer Specific): Ventilöffnung über Command Class SWITCH_MUTILEVEL einstellen
|}

Abfrage des eingestellten Betriebsmodus mit: <code>get <device> thermostatMode</code>

Steuerungsbefehle der Command Class SWITCH_MUTILEVEL ausschließlich für den Stellwertmodus (tmManual):

{| class="wikitable"
|-
!Befehl im Stellwertmodus!!Beschreibung
|-
|<code>set <device> dim %</code>|| Ventilöffnung von 0% bis 100%, wobei 99 = 100%
|-
|<code>set <device> on</code>||letzten Ventilöffnungsgrad einstellen; sinnvoll beispielsweise nach Aus-Modus (tmOff)
|-
|<code>set <device> off</code>||kleinstmögliche Ventilöffnung; entspricht 0%
|-
|}

Im Stellwertmodus erfolgt keine automatische Temperaturregelung durch das Spirit, sondern diese muss durch separate Logik (beispielsweise mit Hilfe von [[PID20 - Der PID-Regler|PID20]]) überwacht und geregelt werden.

Der Öffnungsstand wird mit <code>get <device> swmStatus</code> abgefragt. Zudem kann mit der Parameternummer 6 der Command Class CONFIGURATION der automatische Versand des Ventilöffnungsgrades bei bestimmten Veränderungen eingeschaltet werden (configValveOpeningPercentageReport).

==== Solltemperaturen ====
Die Solltemperaturen in den Modi Komfortmodus (tmHeating) und Absenkmodus (tmEnergySaveHeating) lassen sich im Temperaturbereich 8°C bis 28 °C anpassen. Die Solltemperatur für den Absenkmodus lässt sich ausschließlich per Funk anpassen. Im Aus-Modus (tmOff) und Boostmodus (tmFullPower) ist keine Anpassung möglich.

Die Einstellung der Solltemperaturen erfolgt mit dem set-Befehl <code>thermostatSetpointSet</code> oder dem funktionsgleichen set-Befehl <code>desired-temp</code>. Der letzte Befehl wurde zur Angleichung an andere Module eingeführt und im folgenden genutzt.

===== Komfortmodus =====
Die Solltemperatur auf NN.N °C wird mit folgendem Kurzbefehl eingestellt:

<code>set <device> desired-temp NN.N</code>

Dies entspricht dem ausführlichen Befehl:

<code>set <device> desired-temp NN.N C 1</code>

Die eingestellte Solltemperatur abrufen:

<code>get <device> setpoint 1</code>

oder mit dem Kurzbefehl

<code>get <device> setpoint</code>

===== Absenkmodus =====
Die Solltemperatur auf NN.N °C wird mit folgendem Befehl eingestellt:

<code>set <device> desired-temp NN.N C 11</code>

Die eingestellte Solltemperatur abrufen:

<code>get <device> setpoint 11</code>

==== Kindersicherung ====
{| class="wikitable"
|-
!Befehl!!Beschreibung
|-
|<code>set <device> protectionOff</code>||Ungeschützt - Bedienung am Gerät uneingeschränkt möglich
|-
|<code>set <device> protectionSeq</code>||Eingeschränkt - Bedienung am Gerät erst nach Entsperrung am Gerät (gleichzeitiges Drücken von {{Taste|+}} und {{Taste|-}} für 3 Sekunden)
|-
|<code>set <device> protectionOn</code>||Deaktiviert - Bedienung am Gerät deaktiviert und Steuerung ausschließlich per Funk
|}

Abfrage der eingestellten Kindersicherung mit: <code>get <device> protection</code>

=== Definition ===
Ein Beispiel für ein Spirit FHEM-Device enthält der nachfolgende exemplarische Auszug aus der [[Konfiguration]]:
define ZWave_THERMOSTAT_53 ZWave e345c452 53
attr ZWave_THERMOSTAT_53 IODev ZWDongle
attr ZWave_THERMOSTAT_53 classes ZWAVEPLUS_INFO ASSOCIATION ASSOCIATION_GRP_INFO VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY PROTECTION SENSOR_MULTILEVEL SWITCH_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT BATTERY
CONFIGURATION ALARM POWERLEVEL SECURITY SECURITY_S2 TRANSPORT_SERVICE SUPERVISION FIRMWARE_UPDATE_MD
attr ZWave_THERMOSTAT_53 extendedAlarmReadings 1
attr ZWave_THERMOSTAT_53 room ZWave
attr ZWave_THERMOSTAT_53 stateFormat temperature
attr ZWave_THERMOSTAT_53 vclasses ALARM:8 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:1 POWERLEVEL:1 PROTECTION:1 SECURITY:1 SECURITY_S2:1
SENSOR_MULTILEVEL:5 SUPERVISION:1 SWITCH_MULTILEVEL:1 THERMOSTAT_MODE:3 THERMOSTAT_SETPOINT:3 TRANSPORT_SERVICE:2 VERSION:2 ZWAVEPLUS_INFO:2
Im vorstehenden Beispiel wurde manuell das Attribut <code>extendedAlarmReadings</code> auf <code>1</code> gesetzt, damit für die diversen Alarmarten einfacher unterscheidbare Events erzeugt und separate Readings angelegt werden. Zudem wurde manuell das Attribut <code>stateFormat</code> angelegt. Sämliche anderen Angaben der Defintion nebst Attributen wurden von FHEM bei der Inklusion automatisch durch autocreate angelegt.

=== Logbeispiel ===
2018-10-19_18:04:14 ZWave_THERMOSTAT_53 setpointTemp: 18.0 C energySaveHeating
2018-10-19_18:04:34 ZWave_THERMOSTAT_53 setpointTemp: 22.0 C heating
2018-10-19_18:04:54 ZWave_THERMOSTAT_53 thermostatMode: heating
2018-10-19_18:05:03 ZWave_THERMOSTAT_53 thermostatSetpointSupported: heating energySaveHeating
2018-10-19_18:05:13 ZWave_THERMOSTAT_53 version: Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.10
2018-10-19_18:05:24 ZWave_THERMOSTAT_53 zwavePlusInfo: version:01 role:SleepingListeningSlave node:Z-Wave+Node installerIcon:1200 userIcon:1200
2018-10-19_18:06:32 ZWave_THERMOSTAT_53 alarm_System: Event cleared: unknown event 0, notificationIsOn
2018-10-19_18:08:02 ZWave_THERMOSTAT_53 battery: 100 %
2018-10-19_18:08:02 ZWave_THERMOSTAT_53 batteryState: ok
2018-10-19_18:08:02 ZWave_THERMOSTAT_53 batteryPercent: 100
2018-10-19_18:10:10 ZWave_THERMOSTAT_53 temperature: 23.27 C
2018-10-19_18:18:10 ZWave_THERMOSTAT_53 temperature: 22.73 C
2018-10-19_18:30:10 ZWave_THERMOSTAT_53 temperature: 22.29 C
2018-10-19_19:00:17 ZWave_THERMOSTAT_53 thermostatMode: energySaveHeating
2018-10-19_19:00:55 ZWave_THERMOSTAT_53 thermostatMode: off
2018-10-19_19:06:10 ZWave_THERMOSTAT_53 temperature: 21.75 C
2018-10-19_23:22:18 ZWave_THERMOSTAT_53 thermostatMode: energySaveHeating
2018-10-19_23:27:31 ZWave_THERMOSTAT_53 set_tmHeating
2018-10-19_23:27:32 ZWave_THERMOSTAT_53 tmHeating

== Links ==
* [https://products.z-wavealliance.org/products/2543 Eintrag in http://products.z-wavealliance.org mit Handbuch und mehr]
* [https://eurotronic.org/wp-content/uploads/2024/06/bedienungsanleitung-spirit-z-wave-plus-de.pdf deutsches Handbuch auf Hersteller-Webseite]
* Nutzung eines direkt assozierten Fenstersensors zur Fenster-Offen-Erkennung: {{Link2Forum|Topic=92206}}
* setList-Attribut: {{Link2Forum|Topic=112955|Message=1092262|LinkText=Temperaturwerte eines Nicht-ZWave-Gerätes an das Spirit zur Regelung übermitteln}} ({{Link2Forum|Topic=77598|Message=701397|LinkText=bisheriger Hack}})
* {{Link2Forum|Topic=77598|Message=854445|LinkText=Nutzung des Modul PID20 zur Temperaturregelung im Stellwertmodus (tmManual)}}

[[Kategorie:Z-Wave Components|Sensor]]
[[Kategorie:Heizungsventile]]

Gleitende Mittelwerte berechnen und loggen

2024-08-09T17:03:01Z

F Klee: HTML-Sonderzeichen ersetzt

Für verschiedene Wettersensoren ist es oftmals wünschenswert, gleitende Mittelwerte (fälschlich auch als "relative" Mittelwerte bezeichnet) über ein bestimmtes Zeitfenster auszugeben oder in den Logs zu speichern und zu plotten. Beispiele:
* Die momentanen Winddaten eines KS300 sind oft stark schwankend. Hier wäre ein Mittelwert z.B. der letzten 2-3 Stunden interessant.
* Für die Außentemperatur ist anhand eines Mittelwertes der letzten 24 Stunden evtl. ein gewisser Trend der generellen Entwicklung der Temperatur ableitbar.

Mit Modulen wie ''rain'' oder ''average'' ist konzeptbedingt nur ein Mittelwert von fixen Zeiträumen (aktueller Tag, Monat, etc.) möglich.

Im Nachfolgenden werden deshalb zwei Programme vorgestellt, die solche gleitenden Mittelwerte bereitstellen. Beide Programme werden in die Datei [[99 myUtils anlegen|99_MyUtils.pm]] eingetragen und dann von FHEM aufgerufen. Das erste Programm macht dies für beliebige Readings beliebiger Devices, das zweite Programm greift auf beliebige [[FileLog|File-]] oder [[DbLog|DbLogs]] zurück.

== Gleitender Mittelwert für beliebige Readings ==
=== Subroutine movingAverage in 99_MyUtils anlegen ===
Es werden die Funktionen ''movingAverage'' und ''movingAverageT'' in die 99_MyUtils Datei übernommen werden. Wenn noch nicht vorhanden, sollte die Datei dann so aussehen, der übliche Speicherort ist ''/opt/fhem/FHEM/99_MyUtils.pm''

<syntaxhighlight lang="Perl">package main;
use strict;
use warnings;
sub
MyUtils_Initialize($$)
{
my ($hash) = @_;
}
###############################################################################
#
# Moving average
#
# Aufruf: movingAverage(devicename,readingname,zeitspanne in s)
#
###############################################################################

sub movingAverage($$$){
my ($name,$reading,$avtime) = @_;
my $hash = $defs{$name};
my @new = my ($val,$time) = ($hash->{READINGS}{$reading}{VAL},$hash->{READINGS}{$reading}{TIME});
my ($cyear, $cmonth, $cday, $chour, $cmin, $csec) = $time =~ /(\d+)-(\d+)-(\d+)\s(\d+):(\d+):(\d+)/;
my $ctime = $csec+60*$cmin+3600*$chour;
my $num;
my $arr;
#-- initialize if requested
if( ($avtime eq "-1") ){
$hash->{READINGS}{$reading}{"history"}=undef;
}
#-- test for existence
if( !$hash->{READINGS}{$reading}{"history"}){
#Log 1,"ARRAY CREATED";
push(@{$hash->{READINGS}{$reading}{"history"}},\@new);
$num = 1;
$arr=\@{$hash->{READINGS}{$reading}{"history"}};
} else {
$num = int(@{$hash->{READINGS}{$reading}{"history"}});
$arr=\@{$hash->{READINGS}{$reading}{"history"}};
my $starttime = $arr->[0][1];
my ($syear, $smonth, $sday, $shour, $smin, $ssec) = $starttime =~ /(\d+)-(\d+)-(\d+)\s(\d+):(\d+):(\d+)/;
my $stime = $ssec+60*$smin+3600*$shour;
#-- correct for daybreak
$stime-=86400
if( $stime > $ctime);
if( ($num < 25)&&( ($ctime-$stime)<$avtime) ){
#Log 1,"ARRAY has $num elements, adding another one";
push(@{$hash->{READINGS}{$reading}{"history"}},\@new);
}else{
shift(@{$hash->{READINGS}{$reading}{"history"}});
push(@{$hash->{READINGS}{$reading}{"history"}},\@new);
}
}
#-- output and average
my $average = 0;
for(my $i=0;$i<$num;$i++){
$average+=$arr->[$i][0];
Log 4,"[$name moving average] Value = ".$arr->[$i][0]." Time = ".$arr->[$i][1];
}
$average=sprintf( "%5.3f", $average/$num);
#--average
Log 4,"[$name moving average] calculated over $num values is $average";
return $average;
}

###############################################################################
#
# Moving average of last X seconds, weigh values by time
#
# movingAverageT(Devicename, Readingname, HistoryLength)
#
###############################################################################
sub movingAverageT($$$){
my ($name, $reading, $hSeconds) = @_;
my $hash = $defs{$name};
my @new = my ($val, $time) = ($hash->{READINGS}{$reading}{VAL}, $hash->{READINGS}{$reading}{TIME});

#create new hash "history" if not already existing
if ( !$hash->{READINGS}{$reading}{"history"}) {
@{$hash->{READINGS}{$reading}{"history"}} = \@new;
}

#get reference to hash "history"
my $arr = \@{$hash->{READINGS}{$reading}{"history"}};

#just add values if timestamp differs to last item in history
if( "$time" ne "$arr->[-1][1]" ) {
#append the new entry
push(@{$hash->{READINGS}{$reading}{"history"}}, \@new);

#remove entries that are too old
while( time() - time_str2num((\@{$hash->{READINGS}{$reading}{"history"}})->[0][1]) > $hSeconds ) {
#Log 1,"[$name:$reading] removing reading, it is too old";
shift(@{$hash->{READINGS}{$reading}{"history"}});
}
}

#length of current history
my $aLength = int(@{$hash->{READINGS}{$reading}{"history"}});

#if history currently consists of a single value, just return it
if ($aLength <= 1) {
#Log 1,"[$name:$reading] Average of a single value is the single value: $val";
return sprintf("%5.3f", $val);
}

#sum up all values multiplied with fraction of duration, a value that was valid longer weighs more
my $average = 0;
my $oldest = $arr->[0][1];
my $newest = $arr->[-1][1];
#Log 1,"[$name:$reading] Oldest Timestamp = ".$oldest.", Newest Timestamp: ".$newest;

$oldest = time_str2num($oldest);
$newest = time_str2num($newest);
my $timespan = $newest - $oldest;
#Log 1,"[$name:$reading] Total Timespan: ".$timespan;

#iterate of the array from index 0 to N-1
for(my $i=0; $i<$aLength-1; $i++){
#Log 1,"[$name:$reading] Index: $i, Value = ".$arr->[$i][0]." Time = ".$arr->[$i][1];

my $thisTime = time_str2num($arr->[$i][1]);
my $nextTime = time_str2num($arr->[$i+1][1]);
my $diffTime = $nextTime - $thisTime;
my $fraction = $diffTime / $timespan;

#Log 1,"[$name:$reading] diffTime = $diffTime, Fraction: $fraction";

$average += $arr->[$i][0] * $fraction;
}
#Log 1,"[$name:$reading] Average: $average";

return sprintf("%5.3f", $average);;
}

1;</syntaxhighlight>

=== Funktion movingAverage() aufrufen und nutzen ===
Bei jedem Aufruf schiebt die obige Funktion den gegenwärtigen Wert sowie den Zeitpunkt eines Readings (zweiter Parameter) ans Ende eines Arrays (maximal 25 Einträge) und wirft dafür den ersten Eintrag heraus. Die Anzahl der Einträge im Array wird so gewählt, dass die Zeitpunkte der Readings größer oder gleich der gewünschten Zeitspanne für die Mittelung sind. Über diese Werte wird dann gemittelt und der Wert zurückgegeben.

Zur Anwendung empfiehlt sich, dem gewünschten Device ein userReading zu geben:
:<code>attr devicename userReadings readingname.av {movingAverage("devicename","readingname",zeitspanne)}</code>

Dieses wird dann automatisch bei jedem neuen Wert des Readings mit dem neuen gleitenden Mittelwert über die vergangene Zeitspanne gefüllt.

Beispiel: Das Reading "pressure" des Devices "A.OWB" wird alle 5 Minuten aktualisiert. Das Device bekommt nun ein userReading:
:<code>attr A.OWB userReadings pressure.av {movingAverage("A.OWB","pressure",1800)}</code>

Dieses schreibt bei jeder Aktualisierung von "pressure" einen neuen Eintrag in sein Array - allerdings maximal sechs Werte, dann wird immer der älteste Eintrag gelöscht. Damit ist sichergestellt, dass diese mindestens 1800 Sekunden abdecken - also sechs Einträge.

=== Funktion movingAverageT() aufrufen und nutzen ===
Bei jedem Aufruf schiebt die Funktion ''movingAverageT'' den gegenwärtigen Wert sowie den Zeitpunkt eines Readings (zweiter Parameter) ans Ende eines Arrays und verwirft Einträge die älter als das Zeitlimit aus dem dritten Parameter sind. Die Anzahl der Einträge im Array ist nicht limitiert und es wird nur anhand des Zeitstempels entschieden, ob ein Wert im Array verbleibt. Über die Werte im Array wird dann gemittelt und der Wert zurückgegeben.

Zur Anwendung empfiehlt sich, dem gewünschten Device ein userReading zu geben:
:<code>attr devicename userReadings readingname.av {movingAverageT("devicename", "readingname", Zeitspanne_in_Sekunden)}</code>

Dieses wird dann automatisch bei jedem neuen Wert des Readings mit dem neuen gleitenden Mittelwert über die vergangene Zeitspanne gefüllt.

Beispiel: Das Reading "pressure" des Devices "A.OWB" wird alle 5 Minuten aktualisiert. Das Device bekommt nun ein userReading:
:<code>attr A.OWB userReadings pressure.av {movingAverageT("A.OWB", "pressure", 1800)}</code>

Dieses schreibt bei jeder Aktualisierung von "pressure" einen neuen Eintrag an das ende seines Array und löscht zu alte Werte am Anfang des Array wieder heraus.

== Gleitender Mittelwert aus Log-Dateien ==
=== Subroutine myAverage() in 99_MyUtils anlegen ===
Zuerst muss die Subroutine myAverage in die 99_MyUtils übernommen werden. Wenn noch nicht vorhanden, sollte die Datei dann so aussehen:
<syntaxhighlight lang="perl">
package main;
use strict;
use warnings;
sub
MyUtils_Initialize($$)
{
my ($hash) = @_;
}
##########################################################
# myAverage
# berechnet den Mittelwert aus LogFiles über einen beliebigen Zeitraum
# Args: $offset = Offset in Sekunden
# $logfile = LogFile, z.B. DbLog Device
# $cspec = column-spec, z.B. 4:temp:: (4.Spalte, Zeile enthält temp)
sub myAverage($$$) {
my ($offset,$logfile,$cspec) = @_;
my $period_s = strftime "%Y-%m-%d\x5f%H:%M:%S", localtime(time-$offset);
my $period_e = strftime "%Y-%m-%d\x5f%H:%M:%S", localtime;
my $oll = $attr{global}{verbose};
$attr{global}{verbose} = 0;
my @logdata = split("\n", fhem("get $logfile - - $period_s $period_e $cspec"));
$attr{global}{verbose} = $oll;
my ($cnt, $cum, $avg) = (0)x3;
foreach (@logdata){
my @line = split(" ", $_);
if(defined $line[1] && $line[1] ne ""){
$cnt += 1;
$cum += $line[1];
}
}
if("$cnt" > 0){$avg = sprintf("%0.1f", $cum/$cnt)};
Log 4, ("myAverage: File: $logfile, Field: $cspec, Period: $period_s bis $period_e, Count: $cnt, Cum: $cum, Average: $avg");
return $avg;
}
##########################################################
1;
</syntaxhighlight>

=== Funktion myAverage() aufrufen und nutzen ===
Jetzt kann die Funktion <code>myAverage(<offset>, <logfile>, <column-spec>)</code> ganz normal auf der FHEM-Konsole (telnet localhost 7072) genutzt werden. Hier z.B. die Ausgabe des Mittelwertes des Windsensors, eines KS300, über die letzten drei Stunden (Angabe in 3*3600s) oder der Temperaturmittelwert der letzten 24 Stunden.

Mit FileLog:

<nowiki>fhem> {myAverage("10800", "FileLog_KS300", "8:::")}
6.3
fhem> {myAverage("86400", "FileLog_KS300", "4:::")}
-2.7
fhem></nowiki>

Mit DbLog:

<nowiki>fhem> {myAverage("10800", "myDbLog", "KS300:wind::")}
5.9
fhem> {myAverage("86400", "myDbLog", "KS300:temperature::")}
-2.7
fhem></nowiki>

Ähnlich ist die Verwendung in perl-Code in der [[Konfiguration|fhem.cfg]]:

<nowiki>my $avg = myAverage("10800", "FileLog_KS300", "8:::");;\</nowiki>
Ein [[notify]], welches bei jedem neuen Sensorwert die Mitteltemperatur der letzten 24 Stunden als Event "average-temp xy" ins Logfile schreibt, sieht dann wie folgt aus:

<nowiki>define KS300_T_notify notify KS300:temperature.* {\
fhem('trigger KS300 average-temp: '.myAverage("86400", "FileLog_KS300", "4:::"));;\
}</nowiki>


Analog dazu wäre mit den Winddaten zu verfahren.

== Gleitender Mittelwert und Minimum und Maximum aus Log-Dateien ==

Manchmal interessieren einem auch Minimum und Maximum Werte über einen bestimmten Zeitraum, die Funktion ''myAverage'' kann einfach entsprechend abgeändert werden:

=== Subroutine avgMinMaxAusLog() in 99_MyUtils anlegen ===
<syntaxhighlight lang="Perl">
# Berechnet den Mittelwert, Minimum und Maximum aus LogFiles über einen beliebigen Zeitraum
# Args: $offset = Offset in Sekunden
# $logfile = LogFile, z.B. DbLog Device
# $cspec = column-spec, siehe https://fhem.de/commandref_DE.html#DbLog -> get
sub avgMinMaxAusLog($$$) {
my($offset, $logfile, $cspec) = @_;
my $period_s = strftime "%Y-%m-%d\x5f%H:%M:%S", localtime(time - $offset);
my $period_e = strftime "%Y-%m-%d\x5f%H:%M:%S", localtime;
my $oll = $attr { global } { verbose };
$attr { global } { verbose } = 0;
my @logdata = split("\n", fhem("get $logfile - - $period_s $period_e $cspec"));
$attr { global } { verbose } = $oll;
my ($cnt, $cum, $avg, $min, $max) = (0)x5;
foreach(@logdata) {
my @line = split(" ", $_);
if (defined $line[1] && $line[1] ne "") {
$cnt += 1;
$cum += $line[1];
# Beim ersten Eintrag min/max setzen
if ($cnt == 1) {
$min = $line[1];
$max = $line[1];
# Bei den darauffolgenden Einträgen $min/max ermitteln
} else {
if ($line[1] < $min) { $min = $line[1]; }
if ($line[1] > $max) { $max = $line[1]; }
}
}
}
if ("$cnt" > 0) {
$avg = sprintf("%0.1f", $cum / $cnt)
};
Log 4, ("avgMinMaxAusLog: File: $logfile, Field: $cspec, Period: $period_s bis $period_e, Count: $cnt, Cum: $cum, Average: $avg, Minimum: $min, Maximum: $max");
return ($avg, $min, $max);
}
</syntaxhighlight>
Anwendung wie oben. Statt nur dem Mittelwert wird eine Liste zurückgeliefert mit Mittelwert, Minimum und Maximum. Verwendung z.B. wie folgt:

<nowiki>my ($avg, $min, $max) = myAverage("10800", "FileLog_KS300", "8:::");;\</nowiki>

== Eigenes Filelog und Plot ==
==== Definitionen ====
Ich schreibe ein komplett eigenes Logfile und lasse über eine spezielle gplot-Definition die Temperatur- und Winddaten loggen und plotten.

<syntaxhighlight lang="Perl">
define KS300_W dummy
define KS300_W_notify notify KS300:wind.* {\
my $avg = myAverage("10800", "FileLog_KS300", "8:::");;\
my $event = sprintf("Wc: %0.1f Wd: %0.1f Wm: %0.1f Wlh: %0.1f", ReadingsVal("KS300","wind","0"), ReadingsVal("KS300","W_avg_day","0"), ReadingsVal("KS300","W_avg_month","0"), $avg);;\
Log 2, ("K300_W: Event: $event");;\
fhem("trigger KS300_W data: $event");;\
fhem("trigger KS300 average-wind: $avg");;\
}
define FileLog_KS300_W FileLog ./log/KS300_W-%Y.log KS300_W.*
attr FileLog_KS300_W logtype text
attr FileLog_KS300_W room Logs
define KS300_TH dummy
define KS300_TH_notify notify KS300:temperature.* {\
my $avg = myAverage("86400", "FileLog_KS300", "4:::");;\
my $event = sprintf("Tc: %0.1f Hc: %0.1f Tavg: %0.1f", ReadingsVal("KS300","temperature","0"), ReadingsVal("KS300","humidity","0"), $avg);;\
Log 2, ("K300_TH: Event: $event");;\
fhem("trigger KS300_TH data: $event");;\
fhem('trigger KS300 average-temp: '.$avg);;\
}
define FileLog_KS300_TH FileLog ./log/KS300_TH-%Y.log KS300_TH.*
attr FileLog_KS300_TH logtype text
attr FileLog_KS300_TH room Logs</nowiki>
Die Definitionen für die Plots schauen so aus:

<nowiki>define weblink_KS300_W weblink fileplot FileLog_KS300_W:ks300_wind:CURRENT
attr weblink_KS300_W label "Wind - Min: $data{min1}, Max: $data{max1}, Last: $data{currval1}"
attr weblink_KS300_W room Dachterasse
define weblink_KS300_TH weblink fileplot FileLog_KS300_TH:ks300_temphum:CURRENT
attr weblink_KS300_TH label "Temperatur/Feuchte - Min: $data{min1}, Max: $data{max1}, Last: $data{currval1}"
attr weblink_KS300_TH room Dachterasse
define weblink_KS300_R weblink fileplot FileLog_KS300:ks300_rain10:CURRENT
attr weblink_KS300_R label "Regen - Min: $data{min1}, Max: $data{max1}, Last: $data{currval1}"
attr weblink_KS300_R room Dachterasse
</syntaxhighlight>

==== Angepasste gplot-Dateien ====
Nun noch die speziellen gplot-Dateien.
ks300_wind.gplot

<syntaxhighlight lang="Perl">
############################
# Display the wind values of a KS300.
# Corresponding FileLog definition:
# define <filelogname> FileLog ./log/KS300_W-%Y.log KS300_W.*
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
#set y2tics
set ytics
set title '<L1>'
set grid xtics ytics
set yrange [0:]
set y2range [0:]
set ylabel "Wind (aktuell) [km/h]"
set y2label "Wind (gemittelt) [km/h]"
set format y2 "%0.1f"
#FileLog 5:Wc\x3a:0:
#FileLog 11:Wlh\x3a:0:
plot "<IN>" using 1:5 ls l7fill axes x1y1 title 'Wind (aktuell)' with lines,\
"<IN>" using 1:11 ls l5 axes x1y2 title 'Wind (3h-Mittel)' with steps,\</syntaxhighlight>

ks300_temphum.gplot
<syntaxhighlight lang="Perl">
############################
# Display the Temperature und Humidity values of a KS300.
# Corresponding FileLog definition:
# define <filelogname> FileLog ./log/KS300_TH-%Y.log KS300_TH.*
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperatur [°C]"
set ylabel "Luftfeuchte [%]"
#FileLog 5:Tc\x3a:0:
#FileLog 9:Tavg\x3a:0:
#FileLog 7:Hc\x3a:0:
plot "<IN>" using 1:5 axes x1y2 ls l0 title 'Temperatur' with lines,\
"<IN>" using 1:9 axes x1y2 ls l10 title 'Temperatur (24h-Mittel)' with lines,\
"<IN>" using 1:7 axes x1y1 ls l2fill title 'Luftfeuchte' with lines
</syntaxhighlight>
Den Plot für den Regen habe ich noch um Punkt-Plots für den israining-Status erweitert, so dass Punkte bei "yes" geplottet werden.

ks300_rain10.gplot
<syntaxhighlight lang="Perl">
############################
# Display the Rain values of a KS300.
# Corresponding FileLog definition:
# define <filelogname> FileLog ./log/KS300-%Y.log KS300:T:.*
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
#set y2tics
set ytics
set title '<L1>'
set grid xtics ytics
set y2range [0.5:1.5]
set y2tics ("" 0, "Regen" 1)
set pointsize 7
set ylabel "Regen (l/m²)"
set yrange [0:]
# Computing Rain/h and Rain/d values by accumulating the changes.
#FileLog 10:IR\x3a:0:delta-h
#FileLog 10:IR\x3a:0:delta-d
#FileLog 12:IR:0:$fld[11]=~"yes"?1:0
plot "<grep -v avg_ <IN> | perl -ane '\
@a = split(\"[_:]\", $F[0]);\
if(defined($lh) && $lh ne $a[1])\
{ printf(\"${ld}_$lh:30:00 %f\n\", $hv); $hv = 0; }\
if($lv) { $hv += ($F[9]-$lv); }\
$lh = $a[1]; $ld = $a[0]; $lv = $F[9];\
END { printf(\"${ld}_$lh:30:00 %f\n\", $hv) }'"\
using 1:2 axes x1y1 ls l1fill title 'Regen pro Stunde' with histeps,\
"<grep -v avg_ <IN> | perl -ane '\
@a = split(\"[_]\", $F[0]);\
if(defined($ld) && $ld ne $a[0]) {\
printf(\"${ld}_12:00:00 %f\n\", $dv); $dv = 0; }\
if($lv) { $dv += ($F[9]-$lv); }\
$ld = $a[0]; $lv = $F[9];\
END {printf(\"${ld}_12:00:00 %f\n\", $dv)}'"\
using 1:2 axes x1y1 ls l7 title 'Regen pro Tag' with histeps
"<grep -v avg_ <IN> | awk '{print $1, $12==\"yes\"? 1 : 0; }'"\
using 1:2 axes x1y2 ls l11fill title 'Regen aktuell' with points
</syntaxhighlight>
Eventuell müssen in den gplots noch die Linienstile/Farben den eigenen Bedürfnissen angepasst werden. Ich verwende hier eigene Farben und Füllungen.

[[Kategorie:HOWTOS]]
[[Kategorie:Code Snippets]]
[[Kategorie:Logging]]

Diskussion:FHEM Tablet UI

2024-08-05T09:27:08Z

F Klee: Abschnitt gelöscht. Wiki-Seite wurde verschoben. Es fehlt aber der Hinweis für alle, die über die alte Seite einsteigen.

Sollte man nicht die Widgets alphabetisch sortieren ?

Ich kann das gerne machen... bzw. mache das, wenn ich keinen Widerspruch höre --[[Benutzer:Nobby1805|Nobby1805]] ([[Benutzer Diskussion:Nobby1805|Diskussion]]) 13:05, 6. Mai 2015 (CEST)

Ich habe die Reihenfolge von github übernommen. Aber klar, eine alphabetische Sortierung ist durchaus sinnvoll. Dann aber auch die Beispiele entsprechend sortieren.

:Ich setz mich mal dran .. oder willst du noch aktuell noch etwas ändern ?--[[Benutzer:Nobby1805|Nobby1805]] ([[Benutzer Diskussion:Nobby1805|Diskussion]]) 16:48, 7. Mai 2015 (CEST)

== Sprung von der Widget-Auflistung zu den Beschreibungen ==

... habe ich testweise mal für CIRCLEMENU gemacht ... werde ich in den nächsten Tagen für alle nachzioehgen ... und von dort dann sinnvollerweise auch zu den Beispielen ?! --[[Benutzer:Nobby1805|Nobby1805]] ([[Benutzer Diskussion:Nobby1805|Diskussion]]) 11:54, 14. Mai 2015 (CEST)

== Update Link falsch? ==

Müsste der Update Link zum hinzfügen nicht wie folgt heißen:

<code>update add https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt</code>

ich bekomme mit dem aktuell hinterlegten Link nämlich einen Fehler

--[[Benutzer:Amenophis86|Amenophis86]] ([[Benutzer Diskussion:Amenophis86|Diskussion]]) 14:35, 16. Feb. 2016 (CET)
<HR>
: Hallo!
: Ja, Link auf Wiki-Seite war falsch; controlfile-Angabe fehlt dort.
: Ist korrigiert.
: Danke, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 14:52, 16. Feb. 2016 (CET)

== Deutsch / Englisch ==
Sollten die Texte nicht eingedeutscht werden? Inhalt ist mal deutsch mal englisch --[[Benutzer:Svenson08|Svenson08]] ([[Benutzer Diskussion:Svenson08|Diskussion]]) 06:37, 2. Mär. 2016 (CET)

Ist richtig, hat nur noch keiner gemacht. Kommt daher, dass setstate es auf seiner github Seite in Englisch hat und von dort das Meiste kopiert wurde. --[[Benutzer:Amenophis86|Amenophis86]] ([[Benutzer Diskussion:Amenophis86|Diskussion]]) 00:57, 5. Mär. 2016 (CET)

== Widgets ==
zur besseren Lesbarkeit wäre es besser je Widget ein eigenen "Kapitel"/Überschrift in der Seite anzulegen. Es macht auch wenig Sinn die Beispiele eines Widgets am Ende der Seite einzuhängen. Verständlicher ist es Wenn die Beispiele bei dessen Erläuterung aufgeführt sind. Beispiele ohne Bilder machen wenig Sinn wenn ich ein UI erklären will. --[[Benutzer:Svenson08|Svenson08]] ([[Benutzer Diskussion:Svenson08|Diskussion]]) 19:39, 7. Mär. 2016 (CET)
:Da stimme ich nicht zu ... die jetzige Version mit den zusätzliche "Überschriften' bei Label und Level ist m.E. unübersichtlicher ... aus der alphabetischen Übersicht kommt ja immer durch die Links schnell zu den Beschreibungen und ebenfalls durch die Links zu den Beispielen ... wenn ich zu einem Widget die Argumente nachschlagen will würden m.E. die immer wieder dazwischen liegenden Beispiele eher stören --[[Benutzer:Nobby1805|Nobby1805]] ([[Benutzer Diskussion:Nobby1805|Diskussion]]) 23:33, 7. Mär. 2016 (CET)
Da diese Überschriften keine Kapitel sind ist diese Bearbeitung, Ergänzung mühselig. Das sollten zumindest Kapitel sein um das besser zu bearbeiten und in der Seiten Übersicht sind diese dann ebenfalls mit einem Blick zu sehen und man direkt von dort zum Beispiel springen. Ist eine kleinere Änderung. --[[Benutzer:Svenson08|Svenson08]] ([[Benutzer Diskussion:Svenson08|Diskussion]]) 04:54, 8. Mär. 2016 (CET)
Längere Artikel ohne Kapitel sind nur schwer zu Pflege, das dadurch ein index gebildet wird, besser ein Inhaltsverzeichnis halte ich sehr wohl als übersichtlicher, aber das sieht jeder anders. Aber bearbeite mal eine bestimmte stelle wenn du mehrere tausend Zeilen bis zur gesuchten Zeile scrollen musst. Diese Übersichtlichkeit ist ein Grund warum es die Funktion in jeder wiki Engine gibt.--[[Benutzer:Svenson08|Svenson08]] ([[Benutzer Diskussion:Svenson08|Diskussion]]) 04:58, 8. Mär. 2016 (CET)
:Ein seitlanges Inhaltsverzeichnis finde ich allerdings nicht so prickelnd ;) Ansonsten hast du ja nicht unrecht, ich habe schon mehrfach kleinere Änderungen an den Widgetbeschreibungen durchgeführt, das wäre einfacher wenn die Abschnitte kleiner wären. --[[Benutzer:Nobby1805|Nobby1805]] ([[Benutzer Diskussion:Nobby1805|Diskussion]]) 09:42, 8. Mär. 2016 (CET)
: :-) Toll, ich hab mal recht .... Spaß bei seite. Ich hab auch schon überlegt ob man den einzelnen Widgets nicht einzelne Artikel spendiert. Gibts hier im Wiki auch schon bei ähnlich ausführlicheren Dokus. Auch wenn mal (viel) mehr Beispiele zu einem Widget erfasst werden wäre das vielleicht nicht verkehrt. Hab aber keine Endgültige Meinung dazu.--[[Benutzer:Svenson08|Svenson08]] ([[Benutzer Diskussion:Svenson08|Diskussion]]) 12:25, 8. Mär. 2016 (CET)
:Ich finde die Idee der einzelnen Unterabschnitte, wie sie aktuell zB bei Label gemacht wurde nicht schlecht. Allerdings sollte weiterhin eine Übersichtsliste bleiben, wie sie aktuell unter "Widgets -- Konfiguration" ist. Wenn alle Widgets ein eigener Unterabschnitt ist, dann kann man auch die Beispiele direkt dort einfügen und zB Bilder hinzufügen. Allerdings sollte es dann auch nicht "Widgets LABEL" heißen, sondern "Widget LABEL". Ist ja dann nur noch ein Widget, welches angezeigt wird ;) --[[Benutzer:Amenophis86|Amenophis86]] ([[Benutzer Diskussion:Amenophis86|Diskussion]]) 15:22, 9. Mär. 2016 (CET)

== Betriff Abschnitt Vorraussetungen ==
Vorausgesetzt ist noch ein definierte FHEMWEB Instance, ohne das würden die Fhem Befehle nicht gesendet werden, longpoll, etc. Zwar ist das Default jeder installation, aber man sollte darauf Hinweisen. --[[Benutzer:Svenson08|Svenson08]] ([[Benutzer Diskussion:Svenson08|Diskussion]]) 05:54, 8. Mär. 2016 (CET)

== Anmerkung Link ==

Hallo,

ich hatte Darstellungsprobleme, wenn ich den im Beitrag genannten Link verwendet habe. (Sowohl Chrome als auch Firefox)
Mit diesem Link ging es dann ohne Probleme: http://<fhem-server>:8083/fhem/ftui'''/'''

Gruß
Andy

Diskussion:FHEM Tablet UI

2024-08-05T09:14:00Z

F Klee: Neuer Abschnitt /* Wiki-Seite geleert??? */

AT kleine Helferlein

2024-07-25T18:05:16Z

F Klee: Anker hinzu gefügt

Ein AT kann statt einer Uhrzeit bzw. eines Datums mit einer Uhrzeit auch eine Perl-Funktion nutzen. Beispiel solcher Funktionen sind [[At#at ultimo|at_ultimo]] oder das Modul [[SUNRISE_EL]]. Hier sollen weitere Funktionen vorgestellt werden.

Der Code kann in der [[99 myUtils anlegen|99 myUtils]] untergebracht werden.

== {{Anker|AT am x-ten Wochentag im Monat ausführen}}AT am x-ten Wochentag im Monat ausführen ==

Aufgabe ist es, das at z.B. an jedem 2. Montag im Monat auszuführen. Zusätzlich gibt es auch die Möglichkeit, das at immer am z.B. letzten Montag im Monat auszuführen.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# x.ten Wochentags im Monat
#
# x=1-4 x.ter Wochentag im Monat
# x=9 letzter Wochentag im Monat
# w=1-7 Wochentag, 1=Montag
# h,m,s Uhrzeit Stunde, Minute, Sekunde
#
sub at_xwday($$$$$) {
my ($x,$w,$h,$m,$s) = @_;

my $ziel_tag = 0;

# akt. Datum und Uhrzeit in Variablen aufteilen
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);

# bei Neuberechnung einen Monat addieren
my $add = $data{AT_RECOMPUTE} ? 1 : 0;
$mon = $mon + $add;

my ($nm, $ny) = ($mon == 12) ? (0,$year+1) : ($mon,$year);

# Letztes Vorkommen des Wochentags berechnen?
if ($x == 9) {
# Berechnen des letzten Tags des Monats
# ersten Tag des Folgemonats als timestamp
my ($xm, $xy) = ($mon == 11) ? (0,$year+1) : ($mon+1,$year);
my $nt = mktime(0, 0, 0, 1, $xm, $xy);

# letzter Tag des aktuellen Monats = erster Tag des Folgemonats minus ein Tag
my ($letzter_tag_des_monats, $letzter_wochentag) = (localtime($nt - DAYSECONDS))[3,6];

# Prüfen, ob der letzte Wochentag im Monat mit dem gewünschten Wochentag übereinstimmt
$ziel_tag = $letzter_tag_des_monats;
if ($letzter_wochentag > $w) {
# Falls der letzte Wochentag später im Monat ist, subtrahiere die Differenz
my $differenz = $letzter_wochentag - $w;
$ziel_tag -= $differenz;
} elsif ($letzter_wochentag < $w) {
# Falls der letzte Wochentag früher im Monat ist, subtrahiere 7 plus die Differenz
my $differenz = $w - $letzter_wochentag;
$ziel_tag -= (7 - $differenz);
}
} else {
# Berechne den Tag des ersten Vorkommens des Wochentags im Monat
my $erster_tag = 1;
my $erster_tag_des_monats = (localtime(mktime(0,0,0,$erster_tag,$nm,$ny)))[6];
my $erstes_vorkommen = ($w - $erster_tag_des_monats + 7) % 7 + 1;

# Berechne den Tag des x.ten Vorkommens des Wochentags im Monat
$ziel_tag = $erstes_vorkommen + 7 * ($x - 1);

# Überprüfe, ob das Datum im gültigen Bereich liegt
if ($ziel_tag > 31 || $ziel_tag < 1) {
return "Ungültiges Datum";
}
}
return mktime($s,$m,$h,$ziel_tag,$nm,$ny);
}

</syntaxhighlight>Als Parameter benötigt die Funktion, welches Vorkommen des Wochentags berechnet werden soll (1-4). Soll das letzte Vorkommen berechnet werden, übergibt man 9. Als Wochentag wird 1-7 angegeben, wobei Montag der Wochentag 1 ist. Danach kommen als getrennte Parameter Stunde, Minute und Sekunde. Die Definition sieht dann so aus<syntaxhighlight lang="perl">
defmod at_heat1_Treffen_FG_Radverkehr at *{at_xwday(1,2,17,45,0)} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_FG_Radverkehr at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>Die Heizung wird für das Treffen der Fachgruppe Radverkehr am ersten Dienstag im Monat auf 21 Grad gestellt. Gleichzeitig wird ein AT gestartet, das die Heizung zwei Stunden später wieder auf 15 Grad reduziert. Kleiner Tipp: Man kann im AT auch zwei FHEM-Befehle hintereinander senden. Klappte in diesem Fall aber nur über den kleinen Umweg über Perl.

== {{Anker|AT alle x Tage ausführen}}AT alle x Tage ausführen ==

Soll ein Termin z.B. alle sechs Wochen stattfinden, so kann folgende Funktion genutzt werden.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# nächsten Treffens in x Tagen

sub at_xdays($$) {
my ($tm,$days) = @_;
my $delta = $days * DAYSECONDS; # Nächster Termin in sec

return "Wrong timespec, use \"yyyy-mm-ddThh:mm:ss\"" if($tm !~ m/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/);
my ($y,$m,$d,$h,$m2,$s) = ($1,$2,$3,$4,$5,$6);
my $abstime = mktime($s,$m2,$h,$d,$m-1,$y-1900, 0,0,-1);
my $now = int(time);

my $diff = $now-$abstime;
if ($diff>0){
# bei Neuberechnung sechs Wochen zur aktuellen Zeit addieren
# wird auch bei Erstberechnung aufgerufen, wenn Timestamp in der Vergangenheit
my $temp = ((int($diff/$delta)+1)*$delta)+$abstime;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($temp);
return mktime($s,$m2,$h,$mday,$mon,$year);
} else {return $abstime;}
}

</syntaxhighlight>Dabei wird der erste Ausführungstermin im FHEM-üblichen Format ("yyyy-mm-ddThh:mm:ss") und das Intervall in Tagen übergeben. Die Variable $delta enthält dann das Intervall in Sekunden. Es wird zwar mit dem Timestamp gerechnet. Zurückgegeben wird aber das berechnete Datum und die der Funktion übergebene Uhrzeit. Das verhindert Probleme mit der Zeitumstellung. Hier die Definition für einen Termin alle sechs Wochen, beginnend am 29.05.2024 um 18:45 Uhr. Auch hier wird die Heizung zwei Stunden später wieder herunter gestellt.<syntaxhighlight lang="perl">
defmod at_heat2_Lasse at *{at_xdays("2024-05-29T18:45:00",42)} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_Lasse at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>
[[Kategorie:Code Snippets]]

At

2024-07-25T18:03:39Z

F Klee: Links hinzu gefügt

{{SEITENTITEL:at}}
{{Infobox Modul
|ModPurpose=Setzt einen Fhem-Befehl zu einem späteren Zeitpunkt ab.
|ModType=h

|ModCmdRef=at
|ModTechName=90_at.pm
|ModOwner={{Link2FU|8|rudolfkoenig}}
}}

[[at]] ist ein Erweiterungsmodul, mit dessen Hilfe FHEM-Befehle/-Aktionen zu einem späteren Zeitpunkt ausgeführt werden können. Es läßt sich sowohl einmalige Ausführung, als auch regelmäßige Wiederholung erzielen, Zeitangaben können relativ oder absolut erfolgen.

== Voraussetzungen ==

Keine.

== Anwendung ==
=== Define ===
<code>define <name> at <timespec|datespec> <command></code>

=== Besonderheit ===
*timespec - '''nur Zeit''' im Format HH:MM:SS '''kann eine''' Perlfunktion sein.
*datespec - '''Datum und Zeit''' ISO 8601 oder "number of sec since 1970" '''darf keine''' Perlfunktion sein.
Siehe {{Link2Forum|Topic=91625|Message=168475}}

=== Beispiele ===
*<code>define MeineAktion at 02:02:00 set lamp on</code> → das nächste Mal um zwei Minuten nach 2 Uhr "lamp" einschalten
*<code>define MeineAktion at *02:02:00 set lamp on</code> → jeden Tag um zwei Minuten nach 2 Uhr "lamp" einschalten
*<code>define MeineAktion at {ReadingsVal("Dummy","Zeit","")} set lamp on</code> → das nächste Mal um (Perlfunktion liest Zeit aus dem Dummy) "lamp" einschalten
*<code>define MeineAktion at 2016-01-25T02:02:00 set lamp on</code> → das nächste Mal am 25.01.2016 um zwei Minuten nach 2 Uhr "lamp" einschalten (ISO 8601)
*<code>define MeineAktion at 1453683720 set lamp on</code> → das nächste Mal am 25.01.2016 um zwei Minuten nach 2 Uhr "lamp" einschalten (number of sec since 1970)
*<code>define MeineAktion at +02:02:00 set lamp on</code> → in zwei Stunden und 2 Minuten "lamp" einschalten
*<code>define MeineAktion at +*02:02:00 set lamp on</code> → alle zwei Stunden und 2 Minuten "lamp" einschalten
Um datespec auch variabel mit setzen zu können gibt es einen Workaround: Perlebene, Perlfunktion und Übergabe in Variable.

Beispiele für "number of seconds since 1970"
<syntaxhighlight lang="perl">
{my $time=time_str2num("2019-09-14 23:00:00");;fhem("define MeineAktion at $time set lamp on")}
{my $time=1568494800;;fhem("define MeineAktion at $time set lamp on")}
</syntaxhighlight>
Beispiel im ISO 8601 Format
<syntaxhighlight lang="perl">{my $time="2019-09-14T23:00:00";;fhem("define MeineAktion at $time set lamp on")}</syntaxhighlight>

=== Mehrere Aktionen ausführen ===
Die Verwendung der Semikolon erfordert immer besondere Aufmerksamkeit!
*<code>set lampe1 on ; set lampe2 on </code> → Schaltet sofort beide Lampen ein ( ein bisschen OT, weil kein at)
*<code>define morgens at *7:00:00 set lampe1 on ; set lampe2 on</code> → schaltet lampe 1 immer um 7 an, aber lampe2 sofort. Der erste Befehl landet in der config (im at) der zweite Befehl wird genau wie der define Befehl einfach sofort ausgeführt.
*<code>define morgens at *7:00:00 set lampe1 on ;; set lampe2 on</code> → schaltet BEIDE Lampen immer um 7 an. Beide Befehle landen in der config (im at), nur der define Befehl wird ausgeführt
*<code>define morgens at *7:00:00 set lampe1,lampe2 on</code> → schaltet BEIDE Lampen immer um 7 an. Geht nur wenn der gleiche Befehl an 2 oder mehr Geräte gesendet werden soll

=== at_ultimo ===
Die integrierte Funktion at_ultimo() dient dazu, an jedem letzten Tag des Monats einen FHEM-Befehl auszuführen. Sie kann als Perlfunc für timespec verwendet werden:
:<code>define at_ultimo at *{at_ultimo()} set Lampe1 off</code>

Dadurch wird ein at-device erstellt, das am letzten Tag des Monats um 23:59:00 Uhr ausgeführt wird.

at_ultimo() kann zusätzliche Parameter annehmen, um eine andere Zeit an diesem Tag anzugeben:
:<code>define at_ultimo at *{at_ultimo(12,23,45)} set Lampe1 off</code>

Dadurch wird ein at-device erstellt, das am letzten Tag des Monats um 12:23:45 Uhr ausgeführt wird.

=== Attribute ===
...

=== Testen ===
{{Randnotiz|RNText='''Versionsspezifisch:''' Der Befehl ''execNow'' ist in FHEM 5.7/90_at.pm ab 30.4.2016 verfügbar.}}
Mit dem Befehl
:<code>set <devspec> execNow</code>
lässt sich eine ''at''-Definition (einmalig, beispielsweise zu Testzwecken) unabhängig vom Erreichen der angegebenen Zeitspezifikation ausführen.

=== Ändern / Modifizieren ===
Das Zeit-Attribut eines existierenden Timers sollte via <code>modifyTimeSpec</code> (Befehls-Syntax via Web-Interface ermitteln) geändert werden können.
Details dazu in den Forenbeiträgen
* {{Link2Forum|Topic=76227|LinkText=modifyTimeSpec fehlerhaft!?}}
* {{Link2Forum|Topic=36326|LinkText=defmod}}

== Anwendungsbeispiele ==
* [[AT an einem bestimmten Wochentag ausführen|at an einem bestimmten Wochentag ausführen]]
* [[AT kleine Helferlein#AT am x-ten Wochentag im Monat ausführen|at am x-ten Wochentag im Monat ausführen]]
* [[AT kleine Helferlein#AT alle x Tage ausführen|at alle x Tage ausführen]]
* [[AT um eine Temperaturabhängige Nachtabsenkung zu realisieren|at um eine Temperaturabhängige Nachtabsenkung zu realisieren]]
* [[AT zu einem absoluten Datum ausführen|at zu einem absoluten Datum ausführen]]
* [[SUNRISE_EL|at in Verbindung mit SUNRISE_EL]]

== Links ==
* Abfrage, ob at definiert ist: {{Link2Forum|Topic=23584|Message=841269}}

AT kleine Helferlein

2024-07-25T18:00:58Z

F Klee: Anker hinzu gefügt

Ein AT kann statt einer Uhrzeit bzw. eines Datums mit einer Uhrzeit auch eine Perl-Funktion nutzen. Beispiel solcher Funktionen sind [[At#at ultimo|at_ultimo]] oder das Modul [[SUNRISE_EL]]. Hier sollen weitere Funktionen vorgestellt werden.

Der Code kann in der [[99 myUtils anlegen|99 myUtils]] untergebracht werden.

== {{Anker|AT am x-ten Wochentag im Monat ausführen}}AT am x-ten Wochentag im Monat ausführen ==

Aufgabe ist es, das at z.B. an jedem 2. Montag im Monat auszuführen. Zusätzlich gibt es auch die Möglichkeit, das at immer am z.B. letzten Montag im Monat auszuführen.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# x.ten Wochentags im Monat
#
# x=1-4 x.ter Wochentag im Monat
# x=9 letzter Wochentag im Monat
# w=1-7 Wochentag, 1=Montag
# h,m,s Uhrzeit Stunde, Minute, Sekunde
#
sub at_xwday($$$$$) {
my ($x,$w,$h,$m,$s) = @_;

my $ziel_tag = 0;

# akt. Datum und Uhrzeit in Variablen aufteilen
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);

# bei Neuberechnung einen Monat addieren
my $add = $data{AT_RECOMPUTE} ? 1 : 0;
$mon = $mon + $add;

my ($nm, $ny) = ($mon == 12) ? (0,$year+1) : ($mon,$year);

# Letztes Vorkommen des Wochentags berechnen?
if ($x == 9) {
# Berechnen des letzten Tags des Monats
# ersten Tag des Folgemonats als timestamp
my ($xm, $xy) = ($mon == 11) ? (0,$year+1) : ($mon+1,$year);
my $nt = mktime(0, 0, 0, 1, $xm, $xy);

# letzter Tag des aktuellen Monats = erster Tag des Folgemonats minus ein Tag
my ($letzter_tag_des_monats, $letzter_wochentag) = (localtime($nt - DAYSECONDS))[3,6];

# Prüfen, ob der letzte Wochentag im Monat mit dem gewünschten Wochentag übereinstimmt
$ziel_tag = $letzter_tag_des_monats;
if ($letzter_wochentag > $w) {
# Falls der letzte Wochentag später im Monat ist, subtrahiere die Differenz
my $differenz = $letzter_wochentag - $w;
$ziel_tag -= $differenz;
} elsif ($letzter_wochentag < $w) {
# Falls der letzte Wochentag früher im Monat ist, subtrahiere 7 plus die Differenz
my $differenz = $w - $letzter_wochentag;
$ziel_tag -= (7 - $differenz);
}
} else {
# Berechne den Tag des ersten Vorkommens des Wochentags im Monat
my $erster_tag = 1;
my $erster_tag_des_monats = (localtime(mktime(0,0,0,$erster_tag,$nm,$ny)))[6];
my $erstes_vorkommen = ($w - $erster_tag_des_monats + 7) % 7 + 1;

# Berechne den Tag des x.ten Vorkommens des Wochentags im Monat
$ziel_tag = $erstes_vorkommen + 7 * ($x - 1);

# Überprüfe, ob das Datum im gültigen Bereich liegt
if ($ziel_tag > 31 || $ziel_tag < 1) {
return "Ungültiges Datum";
}
}
return mktime($s,$m,$h,$ziel_tag,$nm,$ny);
}

</syntaxhighlight>Als Parameter benötigt die Funktion, welches Vorkommen des Wochentags berechnet werden soll (1-4). Soll das letzte Vorkommen berechnet werden, übergibt man 9. Als Wochentag wird 1-7 angegeben, wobei Montag der Wochentag 1 ist. Danach kommen als getrennte Parameter Stunde, Minute und Sekunde. Die Definition sieht dann so aus<syntaxhighlight lang="perl">
defmod at_heat1_Treffen_FG_Radverkehr at *{at_xwday(1,2,17,45,0)} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_FG_Radverkehr at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>Die Heizung wird für das Treffen der Fachgruppe Radverkehr am ersten Dienstag im Monat auf 21 Grad gestellt. Gleichzeitig wird ein AT gestartet, das die Heizung zwei Stunden später wieder auf 15 Grad reduziert. Kleiner Tipp: Man kann im AT auch zwei FHEM-Befehle hintereinander senden. Klappte in diesem Fall aber nur über den kleinen Umweg über Perl.

== AT alle x Tage ausführen ==

Soll ein Termin z.B. alle sechs Wochen stattfinden, so kann folgende Funktion genutzt werden.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# nächsten Treffens in x Tagen

sub at_xdays($$) {
my ($tm,$days) = @_;
my $delta = $days * DAYSECONDS; # Nächster Termin in sec

return "Wrong timespec, use \"yyyy-mm-ddThh:mm:ss\"" if($tm !~ m/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/);
my ($y,$m,$d,$h,$m2,$s) = ($1,$2,$3,$4,$5,$6);
my $abstime = mktime($s,$m2,$h,$d,$m-1,$y-1900, 0,0,-1);
my $now = int(time);

my $diff = $now-$abstime;
if ($diff>0){
# bei Neuberechnung sechs Wochen zur aktuellen Zeit addieren
# wird auch bei Erstberechnung aufgerufen, wenn Timestamp in der Vergangenheit
my $temp = ((int($diff/$delta)+1)*$delta)+$abstime;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($temp);
return mktime($s,$m2,$h,$mday,$mon,$year);
} else {return $abstime;}
}

</syntaxhighlight>Dabei wird der erste Ausführungstermin im FHEM-üblichen Format ("yyyy-mm-ddThh:mm:ss") und das Intervall in Tagen übergeben. Die Variable $delta enthält dann das Intervall in Sekunden. Es wird zwar mit dem Timestamp gerechnet. Zurückgegeben wird aber das berechnete Datum und die der Funktion übergebene Uhrzeit. Das verhindert Probleme mit der Zeitumstellung. Hier die Definition für einen Termin alle sechs Wochen, beginnend am 29.05.2024 um 18:45 Uhr. Auch hier wird die Heizung zwei Stunden später wieder herunter gestellt.<syntaxhighlight lang="perl">
defmod at_heat2_Lasse at *{at_xdays("2024-05-29T18:45:00",42)} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_Lasse at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>
[[Kategorie:Code Snippets]]

Dummy

2024-07-22T10:22:46Z

F Klee:

{{SEITENTITEL:dummy}} 
{{Infobox Modul
|ModPurpose=Definition von Hilfsobjekten
|ModType=h
|ModCmdRef=dummy
|ModForumArea=Automatisierung
|ModTechName=98_dummy.pm
|ModOwner=Rudolf König/rudolfkoenig ({{Link2FU|8|Forum}}/[[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

Geräte vom Typ [[dummy]] können für verschiedene Zwecke genutzt werden, die im folgenden anhand von Beispielen aufgeführt werden. Wenn geplant ist, mit einem dummy Schalter zu definieren (Ein-/Ausschaltung), ist wahrscheinlich ein [[readingsProxy]] besser geeignet.

Zusatzlich zum Device ''dummy'' gibt es auch ein gleichnamiges [[dummy (Attribut)|allgemeingültiges Attribut]].

== Definition ==
Siehe {{Link2CmdRef|Anker=dummydefine}}.

== Attribute ==
Siehe {{Link2CmdRef|Anker=dummyattr}}.

== Beispiele ==
=== Jahreszeiten ===
[[Datei:dummySeasons.png|mini|right|Darstellung mit allen vorgesehenen Icons]]
Eine typische Anwendung eines ''dummy'' besteht in der Platzierung eines Buttons (Icon, Schaltfläche) auf der Benutzeroberfläche, wobei diesem "Device" unterschiedliche Werte zugeordnet werden können. Im Detail soll das verdeutlicht werden am Dummy
[[Datei:dummySeasonsInternals.png|mini|right|Auswahlliste in der ''Details''-Ansicht des ''dummy'' Objekts aufgrund des Attributs ''setState'']]
* '''dy_Season'''
* mit dem ''alias'' '''Jahreszeit''' und
* vier vorgesehenen Werten,
* die jeweils durch ein spezifisches Icon dargestellt und
* durch Klick auf das Icon gewechselt werden können.
Hierbei werden die "erlaubten" Werte für den ''state'' durch das Attribut ''[[setList]]'' festgelegt:
:<code>attr dy_Season setList state:Winter,Frühling,Sommer,Herbst</code>
Damit werden "Winter", "Frühling", "Sommer", "Herbst" in der Auswahlliste angeboten.

Die Zuordnung von Icons zu den Werten sowie die Festlegung des Folgezustands nach anklicken des Icons werden mit dem Attribut ''[[devStateIcon]]'' bestimmt:
:<code>attr dy_Season devStateIcon Sommer:weather_summer:Herbst Frühling:weather_pollen:Sommer Herbst:weather_wind:Winter Winter:weather_winter:Frühling</code>

Der bei diesem ''dummy'' gesetzte Wert (state) kann in Folge z.B. in Bedingungen verwendet werden; hier ein Auszug aus einem [[DOIF]]
:<code>([12:45] and [dy_Season:state] eq "Sommer") (...)</code>
bei dem die definierte Aktion (...) um 12:45 Uhr nur dann durchgeführt würde, wenn das beschriebene ''dummy'' Objekt auf "Sommer" steht. Generell gesagt lassen sich also mit Hilfe dieses Mechanismus Aktionen in Abhängigkeit einer (benutzerdefinierten!) Jahreszeit bedingt ausführen.

=== ntfy_setreading ===
{{Randnotiz|RNTyp=[g|Info]|RNText=Es wird nur auf Devices getriggert, die mit "d_" anfangen. Sollten die dummy Devices anders heißen, muss das entsprechend in der DEF angepasst werden.}}
Wird bei einem Dummy mit [[setList]] gearbeitet, um mehrere Readings in einem Dummy zu haben, erfolgt bei einer Änderung nur das Setzen des Status nach <reading> <value>. Ein Reading wird dabei nicht angelegt oder aktualisiert. Damit dies doch geschieht, muss ein notify nach folgendem Muster angelegt werden:
<br clear=all>
{{Randnotiz|RNTyp=y|RNText=Das Konstrukt mit ~~ verursacht massive Warnungen im Log wegen (der Perl Funktion) Smartmatch und ist aus diesem Grund nicht zu empfehlen!}}
:<code>define ntfy_setreading notify d_.* { if( ($EVENT ~~ / /) and ($EVENT !~ /: /) ) {fhem("setreading $NAME $EVENT")} }</code>

=== d_label ===
Für [[readingsGroup]]s kann es hilfreich sein, Überschriften aus einem Reading zu bekommen. So können sie beispielsweise mit valueColumns bearbeitet werden und Sonderzeichen wie {{Taste|:}} oder Leerzeichen ({{Taste| }}) müssen nicht umständlich eingefügt werden.
:<code>define d_label dummy</code>
Durch das [[#ntfy_setreading|ntfy_setreading]] können Labels nun einfach über einen set Befehl erstellt werden:
:<code>set d_label HHMM (HH:MM)</code>
Damit wird ein Reading ''HHMM'' erzeugt mit dem Wert ''(HH:MM)''.

Statt in einem dummy können diese Hilfs-Readings auch direkt in der readingsGroup untergebracht werden. Auch die Verwendung mit dem !-Flag in der readingsGroup bietet sich an.
=== set ===
Mit der Anweisung
:<code>set ''dummyName'' dummyWert</code>
wird dem Dummy ''dummyName'' der Wert ''dummyWert'' zugewiesen. In der Detail-Ansicht (oder dem ''list'') von ''dummyName'' erscheint der zugewiesene Wert im '''Internal''' ''STATE'' sowie im '''Reading''' ''state''.

DWD OpenData

2024-06-28T18:45:59Z

F Klee: /* Readings */

{{Hinweis|Versionsänderung: Die Vorhersagedaten wurden Mitte September 2018 von CSV auf KML umgestellt. Diese Umstellung ist inkompatibel: das DWD_OpenData-Modul muss aktualisiert werden, einige Reading-Namen haben sich geändert und der Weblink muss deinstalliert und neu installiert werden (siehe diesen {{Link2Forum|Topic=83097|Message=840270|Linktext=Beitrag im Forum}}).}}
{{Infobox Modul
|ModPurpose=Daten vom DWD OpenData Server abrufen
|ModType=d
|ModCmdRef=DWD_OpenData
|ModForumArea=Unterstützende Dienste/Wettermodule
|ModTechName=55_DWD_OpenData.pm
|ModOwner=JensB ({{Link2FU|14024|Forum}}/[[Benutzer Diskussion:JensB|Wiki]])
}}
Der Deutsche Wetterdienst (DWD) stellt Wetterdaten über den [https://www.dwd.de/DE/leistungen/opendata/opendata.html Open Data Server] zur Verfügung. Die Verwendung dieses Dienstes und der vom DWD zur Verfügung gestellten Daten unterliegt den auf der OpenData Webseite beschriebenen Bedingungen. Einen Überblick über die verfügbaren Daten findet man in der Tabelle [https://www.dwd.de/DE/leistungen/opendata/help/inhalt_allgemein/opendata_content_de_en_xls.xls OpenData_weather_content.xls] oder hier: https://opendata.dwd.de/weather/lib/MetElementDefinition.xml.

== Anwendung ==
Aufgrund der unterschiedlichen vom DWD bereitgestellten Datenformate benötigt das Modul zur Dekodierung je nach gewünschtem Funktionsumfang zusätzliche Perl-Module, die nicht standardmäßig vorinstalliert sind und je nach Systemkonfiguration nachinstalliert werden müssen. Außerdem unterstützt das Modul Zeitzonen, um z.B. die Wettervorhersage internationaler Stationen in Ortszeit darstellen zu können. Hierfür sind je nach Systemkonfiguration weitere Einstellungen erforderlich. Auch die Sprache der Wochentage für die Wettervorhersage ist frei wählbar. Je nach Systemkonfiguration ist aber die Standardsprache u.U. auf Englisch eingestellt, was weitere Anpassungen der Systemkonfiguration erforderlich macht.

=== Vorbereitung ===
Im folgenden wird z.T. von einem System mit Rasbian oder Debian mit System-V Startsystem ausgegangen. Auf anderen Betriebssystemen und auf Systemen mit System-D müssen die Installationsschritte ggf. angepasst werden.

1. Für die Wettervorhersage und die Wetterwarnungen:
Installation des Perl-Moduls ''XML::LibXML'' über die System-Kommandozeile mit
<syntaxhighlight lang="bash">
sudo apt-get install libxml-libxml-perl
</syntaxhighlight>
oder mit CPAN.

2. Weiterhin ist das Perl-Modul '' DateTime'' erforderlich. Dieses lässt sich mit <syntaxhighlight lang="bash">sudo apt-get install libdatetime-perl</syntaxhighlight> installieren.

3. Falls man einen eigenen Internet-Proxy nutzt:
Die Konfiguration des Proxies für FHEM erfolgt z.B. durch Eintrag von
<pre>
attr global proxy <myProxyHost>:<myProxyPort>
</pre>
in die [[Konfiguration]], wobei ''myProxyHost'' durch den Namen oder die IP-Adresse des Proxy-Servers ersetzt werden muss und für ''myProxyPort'' der Port des Proxy-Servers eingetragen werden muss (oft 3128).

3. FHEM Uhrzeit und Zeitzone:
Durch Eingabe von
<pre>
{localtime()}
</pre>
in die FHEM-Kommandozeile überprüfen, ob die FHEM-Uhrzeit plausibel ist. Ist dies nicht der Fall sollten die Uhrzeit auf Systemebene überprüft werden und ggf. die Systemeinstellungen angepasst werden.
Ermitteln der Bezeichnung der eigenen Zeitzone über die System-Kommandozeile mit
<pre>
tzselect
</pre>
und diese Bezeichnung in die Datei ''/etc/timezone'' eintragen und
<pre>
export TZ=`cat /etc/timezone`
</pre>
der Datei ''/etc/profile'' hinzufügen und dann das System neu starten. Nun muss die Zeitanzeige in FHEM korrekt sein.

4. FHEM Sprache:
Durch Eingabe von
<pre>
{$ENV{LANG}}
</pre> in die FHEM-Kommandozeile überprüfen, in welcher Sprache der Wochentag angezeigt wird. Stimmt die Sprache nicht, dann auf der System-Kommandozeile
<pre>
dpkg-reconfigure locales
</pre> eingeben und aus der Liste z.B. ''de_DE.UTF-8'' zusätzlich auswählen. Dieser Befehl gilt für Debian-basierte Betriebssysteme - für andere Betriebssysteme ist eine analoge Funktion zu verwenden. Mit Eingabe von
<pre>
locale -a
</pre> auf der System-Kommandozeile überprüfen, ob die ausgewählte Sprache nun zur Verfügung steht. Sollte FHEM nach einem Neustart noch immer nicht die gewünschte Sprache verwenden, kann man auf einem System V Linux durch Hinzufügen von z.B.
<pre>
export LANG=de_DE.UTF-8
</pre> in die Datei ''/etc/init.d/fhem'' (irgendwo zwischen ''start'' und ''perl'') und erneutem Neustart von FHEM die Sprache für FHEM erzwingen. Bei einem Systemd Linux kann man die Einstellungen mit ''systemctl edit --full fhem.service'' bearbeiten. Spätestes jetzt muss die Wochentagsanzeige in FHEM korrekt sein.

5. Nur für den Weblink erforderlich:
Installation des Perl-Moduls ''DateTime'' über die System-Kommandozeile mit
<pre>
sudo apt-get install libdatetime-perl
</pre>
oder mit CPAN.

=== Define ===
Siehe {{Link2CmdRef|Anker=DWD_OpenDatadefine|Label=Commandref}}.

=== Attributes ===
Siehe {{Link2CmdRef|Anker=DWD_OpenDataattr|Label=Commandref}}.

=== Readings ===
Die Prognosewerte sind wie folgt aufgebaut:
fc<day>_[<sample>_]<property>
Eine Beschreibung der über 70 verfügbaren Eigenschaften und ihrer Maßeinheiten finden Sie hier. Die Maßeinheiten für Temperaturen und Windgeschwindigkeiten werden jeweils in °C und km/h umgerechnet. In den folgenden Abschnitten sind nur einige ausgewählte Eigenschaften aufgeführt:

* day – relativer Tag (0 .. 9) basierend auf dem Zeitzonenattribut, wobei 0 für heute steht

* sample – relative Zeit (0 .. 3, 7 oder 23), die einem Vielfachen von 6, 3 oder 1 Stunde UTC entspricht, abhängig vom Attribut forecastResolution

* day properties (normalerweise für 06:00 Uhr Stationszeit, siehe Rohdaten der Station für tatsächliche Zeitbeziehung)
date – Datum basierend auf dem Zeitzonenattribut
weekday – abgekürzter Wochentag basierend auf dem Zeitzonenattribut in der Sprache Ihres FHEM-Systems
Tn [°C] – Mindesttemperatur der letzten 12 Stunden
Tx [°C] – Höchsttemperatur der letzten 12 Stunden (normalerweise um 18:00 Stationszeit)
Tm [°C] – Durchschnittstemperatur der letzten 24 Stunden
Tg [°C] – Mindesttemperatur 5 cm über dem Boden der letzten 12 Stunden
PEvap [kg/m2] – Evapotranspiration der letzten 24 Stunden
SunD [s] - Gesamtsonnenscheindauer des vorherigen Tages

* hour properties
time - Zeit basierend auf dem Zeitzonenattribut
TTT [°C] - Trockentemperatur in 2 Metern Höhe über dem Boden
Td [°C] - Taupunkttemperatur in 2 Metern Höhe über dem Boden
DD [°] - durchschnittliche Windrichtung in 10 m Höhe über dem Boden
FF [km/h] - durchschnittliche Windgeschwindigkeit in 10 m Höhe über dem Boden
FX1 [km/h] - maximale Windgeschwindigkeit in der letzten Stunde
SunD1 [s] - Sonnenscheindauer in der letzten Stunde
SunD3 [s] - Sonnenscheindauer in den letzten 3 Stunden
RR1c [kg/m2] - Niederschlagsmenge in der letzten Stunde
RR3c [kg/m2] - Niederschlagsmenge in den letzten 3 Stunden
RR6c [kg/m2] - Niederschlagsmenge in den letzten 6 Stunden
R600 [%] - Regenwahrscheinlichkeit in den letzten 6 Stunden
RRhc [kg/m2] - Niederschlagsmenge in den letzten 12 Stunden
Rh00 [%] - Regenwahrscheinlichkeit in den letzten 12 Stunden
RRdc [kg/m2] - Niederschlagsmenge in den letzten 24 Stunden
Rd00 [%] - Regenwahrscheinlichkeit in den letzten 24 Stunden
ww - Wettercode (siehe WMO 4680/4677, SYNOP)
wwd - deutsche Wettercodebeschreibung
VV [m] - horizontale Sichtweite
Neff [%] - effektive Wolkenbedeckung
Nl [%] - untere Wolkenbedeckung unter 2000 m
Nm [%] - mittlere Wolkenbedeckung unter 7000 m
Nh [%] - hohe Wolkenbedeckung über 7000 m
PPPP [hPa] - Druckäquivalent auf Meereshöhe

* Zusätzliche Tageseigenschaften, nicht vom DWD bereitgestellt
SunRise - Sonnenaufgangszeit basierend auf dem Zeitzonenattribut
SunSet - Sonnenuntergangszeit basierend auf dem Zeitzonenattribut

* Zusätzliche Stundeneigenschaften, nicht vom DWD bereitgestellt
SunAz [°] - Sonnenazimut
SunEl [°] - Sonnenhöhe
SunUp - Sonnenaufgang (0: Nacht, 1: Tag)

Zusätzlich gibt es globale Prognosewerte:

* fc_state - Status der letzten Prognoseaktualisierung, mögliche Werte sind „updated“ und „error: ...“
* fc_station - Prognosestationscode (WMO oder DWD)
* fc_description - Stationsbeschreibung
* fc_coordinates - Weltkoordinate und Höhe der Station
* fc_time - Zeitpunkt der Veröffentlichung der Prognose basierend auf dem Zeitzonenattribut
* fc_copyright - rechtliche Informationen, müssen mit Prognosedaten angezeigt werden, siehe DWD-Nutzungsbedingungen

Die Alarmwerte sind nach Beginn sortiert und folgendermaßen aufgebaut:
a_<index>_<property>

* index - Alarmindex, beginnend mit 0, Gesamtanzahl a_count, sortiert nach Beginn

* alert properties
category - „Met“ oder „Health“
event - numerischer Ereigniscode, siehe DWD-Dokumentation für Details
eventDesc - kurze Ereignisbeschreibung in ausgewählter Sprache
eventGroup - Ereignisgruppe, siehe DWD-Dokumentation für Details
responseType - „None“ = nein Anweisungen, „Vorbereiten“ = Anweisungen, „AllClear“ = Alarm gelöscht
urgency – „Immediate“ = Warnung oder „Zukünftig“ = Information
severity – „Minor, „Moderate“, „Severe“ or „Extreme“
areaColor – RGB-Farbe je nach Dringlichkeit und Schweregrad, durch Komma getrennte Dezimalzahlen
onset – Startzeit des Alarms basierend auf dem Zeitzonenattribut
expires – Endzeit des Alarms basierend auf dem Zeitzonenattribut
headline – Überschrift in ausgewählter Sprache, normalerweise eine Kombination der Eigenschaften Dringlichkeit und Ereignis
description – Beschreibung des Alarms in ausgewählter Sprache
instruction – Sicherheitsanweisungen in ausgewählter Sprache
area – numerische Warnzellen-ID
areaDesc – Beschreibung des Bereichs, z. B. „Stadt Berlin“
altitude – min. Höhe [m]
ceiling – max. Höhe [m]

Zusätzlich gibt es einige globale Alarmwerte:

* a_state – Status der letzten Alarmaktualisierung, mögliche Werte sind „aktualisiert“ und „Fehler: ...“

* a_time – Zeitpunkt des Downloads der letzten Alarmaktualisierung, basierend auf der Zeitzone attribut

* a_count – Anzahl der für die ausgewählte Warnzellen-ID verfügbaren Alarme

* a_copyright – rechtliche Informationen, müssen mit Prognosedaten angezeigt werden, siehe DWD-Nutzungsbedingungen, nicht verfügbar, wenn count null ist

Alarme sollten unabhängig von der Dringlichkeit für onset <= now < expires und responseType != „AllClear“ als aktiv betrachtet werden. Inaktive Alarme mit responseType = „AllClear“ können relevante Anweisungen enthalten.

Beachten Sie, dass alle Alarmwerte bei jeder Aktualisierung vollständig ersetzt und neu indexiert werden!

Weitere Informationen zu den Alarmeigenschaften finden Sie in der Dokumentation des CAP DWS-Profils.

== Anwendungsbeispiele ==
=== Beispiel zur Modul-Einrichtung ===

* Wettervorhersage
Für die Wettervorhersage muss der Stationscode ermittelt werden. Dazu den [https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/mosmix_stationskatalog.pdf MOSMIX Stationskatalog] herunterladen, öffnen und die gewünschte Station heraussuchen (Spalte ''id''). Einen Teil der deutschen Stationen kann man auch der [https://www.dwd.de/DE/derdwd/messnetz/bodenbeobachtung/messnetzkarte_boden.pdf Bodenmessnetzkarte] entnehmen. Den ermittelten Stationscode kann man dann entweder für eine Einzelabfrage als Parameter für das Kommando ''get forecast'' verwenden oder für die automatische Aktualisierung als Attribut ''forecastStation'' hinterlegen. Insgesamt werden vom DWD mehr als 70 Merkmale zur Verfügung gestellt. Eine Auflistung findet sich im Dokument [https://opendata.dwd.de/weather/lib/MetElementDefinition.xml MetElementDefinition]. Nur ein kleiner Teil der Merkmale wird in der Standardeinstellung des Moduls als Reading zur Verfügung gestellt. Wer andere Merkmale benötigt muss sie mit Komma getrennt dem Attribut ''forecastProperties'' zuweisen. Es empfiehlt sich zur Performance-Optimierung sowohl das Attribut ''forecastDays'' als auch das Attribut ''forecastProperties'' auf den tatsächlichen Bedarf einzustellen.

* Wetterwarnungen
Für die Wetterwarnungen muss die Warnzelle ermittelt werden. Dazu [https://www.dwd.de/DE/leistungen/opendata/help/warnungen/cap_warncellids_csv.csv Warnzellen-ID Katalog] herunterladen, öffnen und die gewünschte Warnzelle heraussuchen. Unterstützt werden Gemeinden (beginnen mit 8), Landkreise (beginnen mit 1 oder 9) oder Küste (beginnen mit 5). Die Warnzellen-ID kann man dann entweder für eine Einzelabfrage als Parameter für das Kommando ''get alerts'' verwenden oder für die automatische Aktualisierung als Attribut ''alertArea'' hinterlegen. Die Warnzellen-ID ist ab der 2. Stelle identisch mit den ersten Ziffern des amtlichen Gemeindeschlüssels. Man kann z.B. den Namen von Gemeinde oder Landkreis bei den [https://www.statistik-bw.de/Statistik-Portal/gemeindeverz.asp Statistischen Ämtern des Bundes und der Länder] eingeben, den amtlichen Gemeindeschlüssel ermitteln und dann mit vorangestellter 1, 8 oder 9 im Warnzellen-ID Katalog des DWD nach einem Eintrag mit exakter oder weitgehender Übereinstimmung suchen. Wem das zu kompliziert vorkommt, der kann bei mehrdeutigen Gemeinde- bzw. Landkreisbezeichnungen auch versuchen auszuprobieren, welche die richtige Warnzellen-ID ist.

Um das Modul mit automatisch Aktualisierung von Vorhersage und Wetterwarnungen zu nutzen, kann z.B. folgendes in die [[Konfiguration]] eingetragen werden:

<pre>
define DWD DWD_OpenData
attr DWD alertArea 111000000
attr DWD forecastStation 99810
attr DWD forecastDays 3
attr DWD forecastWW2Text 1
</pre>

* Performance
Das DWD_OpenData-Modul ist ein Datenmodul mit relativ vielen Readings. In der Standardkonfiguration wird, wie bei jedem anderen FHEM Modul, bei jeder Änderung jedes Readings ein FHEM internes Ereignis erzeugt, damit andere FHEM Devices auf diese Änderungen reagieren können. Diese Ereignisse sorgen auch dafür, dass man Änderungen in der Weboberfläche sofort angezeigt bekommt, ohne die Webseite neu aufzurufen. Interessiert sich aber kein FHEM Device für die Änderungsbenachrichtigung bestimmter Readings, entsteht unnötiger Verarbeitungs-Overhead, der je nach FHEM Konfiguration und verfügbarer CPU-Leistung auch mehrere Sekunden benötigen kann und in dieser Zeit andere Abläufe blockiert. Um die Performance zu optimieren, empfiehlt es sich, mit [[event-on-update-reading]] für eine angepasste und dadurch effizientere Verarbeitung zu sorgen, indem man nur für jene Readings Ereignisse zulässt, welche man für die Weiterverarbeitung braucht. Der DWD_OpenData_Weblink braucht z.B. gar keine Ereignisse, um zu funktionieren. Hier eine minimalistische Beispielkonfiguration:

<pre>
attr DWD event-on-update-reading state,fc_state,a_state
</pre>

Weitere Details zur Installation und Konfiguration des Moduls finden sich in der
{{Link2CmdRef|Anker=DWD_OpenData|Label=Commandref}}.

=== Beispiel für die Einrichtung eines Meteogramms ===
Um den vorhergesagten Wetterverlauf als Meteogramm in Kurvenform mit [[SVG]] darzustellen, kann man wie folgt vorgehen:

1. 99_myUtils.pm

Für die Bestimmung der Werte für den SVG-Plot wird eine Perl-Funktion benötigt, die in die Datei 99_myUtils.pm vor dem Ende eingefügt wird. Wer diese FHEM-Datei noch nicht nutzt, legt sie einfach an (siehe [[99_myUtils_anlegen]]).
<syntaxhighlight lang="perl">
package main;

use strict;
use warnings;

...

#
# (c) mumpitzstuff 19.12.2018
#
# see https://forum.fhem.de/index.php/topic,83097.msg874150.html#msg874150
#
sub logProxy_dwd2Plot($$$$;$$$)
{
my ($device, $fcValue, $from, $to, $fcHour, $expMode, $shiftTime) = @_;
my $regex;
my @rl;

return undef if(!$device);

if ($fcValue =~ s/_$//)
{
$regex = "^fc[\\d]+_[\\d]+_".$fcValue."\$";
}
else
{
$regex = "^fc[\\d]+_".$fcValue."\$";
}

$fcHour = 12 if(!defined($fcHour));
$expMode = "point" if(!defined($expMode));
#Log3 undef,2, "Regex: ".$regex;

# ermitteln aller relevanten Readings
if ( defined($defs{$device}) )
{
if ( $defs{$device}{TYPE} eq "DWD_OpenData" )
{
@rl = sort
{
my ($an) = ($a =~ m/fc(\d+)_.*/);
my ($bn) = ($b =~ m/fc(\d+)_.*/);
my ($ao) = ($a =~ m/fc\d+_(\d+).*/);
my ($bo) = ($b =~ m/fc\d+_(\d+).*/);
$an <=> $bn or $ao <=> $bo or $a cmp $b;
} ( grep /${regex}/,keys %{$defs{$device}{READINGS}} );
return undef if ( !@rl );
}
else
{
Log3 undef, 2, "logProxy_dwd2Plot: $device is not a DWD_OpenData device";
return undef;
}
}

my $fromsec = SVG_time_to_sec($from);
my $tosec = SVG_time_to_sec($to);
my $sec = $fromsec;
my ($h, $hp, $fcDay, $mday, $mon, $year);
my $timestamp;

my $reading;
my $value;
my $prev_value;
my $min = 999999;
my $max = -999999;
my $ret = "";

# while not end of plot range reached
while (($sec < $tosec) && @rl)
{
#remember previous value for start of plot range
$prev_value = $value;

$reading = shift @rl;
($fcDay) = $reading =~ m/^fc(\d+).*/;
($hp) = $reading =~ m/^fc\d+_(\d+).*/;
#Log 1, "hp: ".$hp;

if ($hp)
{
$h = ReadingsVal($device, "fc".$fcDay."_".$hp."_time", $fcHour);
if ($h =~ m/^(\d+):\d+/)
{
$h = $1;
}
}
else
{
$h = $fcHour;
}

$value = ReadingsVal($device, $reading, undef);

# calculate minutes of sunshine per hour
if ($fcValue =~ /^SunD(\d+)/)
{
if (defined($1))
{
$value = $value / ($1 * 36);
}
else
{
$value = $value / (12 * 36);
}
}

# calculate amount of rain per hour
if ($fcValue =~ /^RR(\d+)c$/)
{
if (defined($1))
{
$value /= $1;
}
}

($year, $mon, $mday) = split('\-',ReadingsVal($device, "fc".$fcDay."_date",undef));
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, $h, 0, 0);
$sec = SVG_time_to_sec($timestamp);
if (defined($shiftTime))
{
$sec += $shiftTime;
$timestamp = logProxy_shiftTime($timestamp, $shiftTime);
}

# skip all values before start of plot range
next if ( $sec < $fromsec );

# add first value at start of plot range
if ( !$ret && $prev_value )
{
$min = $prev_value if ( $prev_value < $min );
$max = $prev_value if ( $prev_value > $max );
$ret .= "$from $prev_value\n";
}

# done if after end of plot range
last if ($sec > $tosec);

$min = $value if ( $value < $min );
$max = $value if ( $value > $max );

# add actual control point
$ret .= "$timestamp $value\n";
}

if (($sec < $tosec) && !@rl && ($expMode eq "day"))
{
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, 23, 59, 59);
$_ = SVG_time_to_sec($timestamp);
if (defined($shiftTime))
{
$_ += $shiftTime;
$timestamp = logProxy_shiftTime($timestamp, $shiftTime);
}

if ($_ < $tosec)
{
$ret .= "$timestamp $value\n";
}
else
{
$ret .= "$to $value\n";
}
}
elsif (($sec > $tosec) && ($expMode eq "day"))
{
$value = $prev_value + ($value - $prev_value) * (86400 + ($tosec - $sec)) / 86400;
$ret .= "$to $value\n";
}

return ($ret, $min, $max, $prev_value);
}

1;
</syntaxhighlight>

2. LogProxy

Wer bereits ein [[logProxy]]-Device hat, muss den Namen seines logProxy-Devices in die weiter unter aufgeführte GPlot-Konfiguration eintragen. Ansonsten wird es wie folgt neu erstellt:
<pre>
define LogProxy logProxy
</pre>

3. FileLog

Das Meteogramm kennt anders als andere FHEM-Plots keine Vergangenheit außer heute. Trotzdem wird aus formalen Gründen ein [[FileLog]]-Device benötigt. Dazu kann ein beliebiges vorhandenes FileLog-Device verwendet werden. Wer will, kann hierfür aber auch ein neues FileLog Device für das DWD_OpenData-Device anlegen (Achtung: wird schnell umfangreich):
<pre>
define FileLog_DWD FileLog ./log/DWD-%Y-%m.log DWD
</pre>

Im folgenden wird für das FileLog-Device der Platzhalter ''FileLog_Dummy'' verwendet, der mit dem Namen des gewählten FileLog-Devices zu ersetzen ist.

4. SVG Plot

Das eigentliche Meteogramm ist ein SVG-Device. Will man mehrere Tage darstellen bietet sich die folgende Definition an:
<pre>
define SVG_DWD SVG FileLog_Dummy:SVG_DWD:CURRENT
attr SVG_DWD fixedoffset 6
attr SVG_DWD fixedrange 7days
attr SVG_DWD nrAxis 1,2
</pre>

Dabei muss das SVG-Attribut ''fixedoffset'' entweder gleich oder kleiner als die Einstellung des DWD_OpenData-Attributs ''forecastDays'' (Standardwert: 6 Tage) gewählt werden und das SVG-Attribut ''fixedrange'' um eins größer als ''fixedoffset'' eingestellt werden.

Will man stattdessen nur die nächsten 24 Stunden anzeigen, nimmt man folgende Einstellungen:
<pre>
define SVG_DWD SVG FileLog_Dummy:SVG_DWD:CURRENT
attr SVG_DWD endPlotNow 1
attr SVG_DWD fixedoffset 1
attr SVG_FileLog_WETTER_DWD_3 label "Tmin: $data{max1} °C, Tmax: $data{min1} °C"
attr SVG_DWD nrAxis 1,2
</pre>

Um die DWD_OpenData-Readings mit dem Plot zu verknüpfen, muss man nun die GPlot-Konfigurationsdatei des SVG-Plots manuell bearbeiten. Dazu auf den Link klicken, der im SVG_DWD-Device am Internal ''GPLOTFILE'' steht. Die y-Wertebereiche für die Regenmenge und die Temperaturen sind im Beispiel auskommentiert (Autorange). Das kann man so lassen oder man stellt sie nach den eigenen Wetter-Gegebenheiten ein. Je nach Konfiguration des DWD_OpenData-Attributs ''forecastResolution'' sind aber noch einige weitere Einstellungen anzupassen. Das folgende Beispiel ist für die 3h-Auflösung:
<pre>
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Wettervorhersage'
set ytics
set y2tics
set grid ytics
set ylabel "Regen [mm]"
#set yrange [0:4]
set y2label "Temperatur [°C]"
#set y2range [-5:35]
set y3label "Wolken/Regen/Sonne [%]"
set y3range [0:100]

#LogProxy Func:logProxy_dwd2Plot("DWD","TTT_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","Tx",$from,$to,18,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","Tn",$from,$to,6,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","SunD3_",$from,$to,0,"day",(-3*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","RR3c_",$from,$to,0,"day",(-3*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","FX1_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","R600_",$from,$to,0,"day",(-3*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","Neff_",$from,$to,0,"day")
#LogProxy ConstX:TimeNow(),0,100
#LogProxy ConstY:0

plot "<IN>" using 1:2 axes x1y2 title 'T' ls l0 lw 2 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y2 title 'Tmax' ls l0dot lw 2 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y2 title 'Tmin' ls l0dot lw 2 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Sonne' ls l4fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Regenmenge' ls l2fill lw 1 with steps,\
"<IN>" using 1:2 axes x1y3 title 'Wind' ls l1 lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Regen' ls l5fill lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Wolken' ls l6fill lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 notitle ls l5 lw 4 with lines,\
"<IN>" using 1:2 axes x1y2 notitle ls l5 lw 1 with lines
</pre>

Verwendet man dagegen eine Auflösung von 1 Stunde, sind folgende LogProxy-Einträge erforderlich:
<pre>
#LogProxy Func:logProxy_dwd2Plot("DWD","TTT_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","Tx",$from,$to,18,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","Tn",$from,$to,6,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","SunD1_",$from,$to,0,"day",(-1*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","RR1c_",$from,$to,0,"day",(-1*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","FX1_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","R101_",$from,$to,0,"day",(-0.5*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","Neff_",$from,$to,0,"day")
#LogProxy ConstX:TimeNow(),0,100
#LogProxy ConstY:0
</pre>

Für die Darstellung der nächsten 24 Stunden mit einer Auflösung von 1 Stunde nimmt man folgende GPlot-Konfiguration:
<pre>
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics
set y2tics
set y3tics
set grid xtics y2tics
set ylabel "Regen [mm]"
set y2label "Temperatur [°C]"
set y3label "Wolken/Regen/Sonne [%]"
set y3range [0:100]

#LogProxy Func:logProxy_dwd2Plot("DWD","TTT_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","SunD1_",$from,$to,0,"day",(-1*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","RR1c_",$from,$to,0,"day",(-1*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","FX1_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","R101_",$from,$to,0,"day",(-0.5*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","Neff_",$from,$to,0,"day")
#LogProxy ConstY:0

plot "<IN>" using 1:2 axes x1y2 title 'T' ls l0 lw 2 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Sonne' ls l4fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Regenmenge' ls l2fill lw 1 with steps,\
"<IN>" using 1:2 axes x1y3 title 'Wind' ls l1 lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Regen' ls l5fill lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Wolken' ls l6fill lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y2 notitle ls l2 lw 2 with lines
</pre>

Je nachdem, welche Auflösung man verwendet, werden unterschiedliche Readings des DWD_OpenData-Devices benötigt. Diese sind in den LogProxy-Zeilen in der GPlot-Konfigurationsdatei zu finden und müssen auf jeden Fall dem Attribut ''forecastProperties'' des DWD_OpenData-Device hinzugefügt werden.

Viele Detaileinstellungen des Meteogramms lassen sich individualisieren. Man kann z.B. mehr oder weniger Daten anzeigen und zumindest für ''heute'' auch aktuelle Messwerte hinzufügen.

Hier ein Beispiel für ein Meteogramm über 4 Tage mit 3 Stunden Auflösung:

[[File:DWDODmeteogram4d3h.png|500px]]

=== Beispiel für die Einrichtung eines Weblinks ===
Zur graphischen Darstellung der Vorhersage und der Wetterwarnungen mit [[FHEMWEB]] steht das Modul [https://raw.githubusercontent.com/jnsbyr/fhem/master/FHEM/98_DWD_OpenData_Weblink.pm 98_DWD_OpenData_Weblink.pm] zur Verfügung.

Zunächst die Moduldatei herunterladen und in das Modulverzeichnis ''fhem/FHEM'' kopieren. Entweder die Datei direkt auf den FHEM-Server herunterladen (z.B. mit ''wget'') oder beim indirekten Herunterladen darauf achten, dass dabei das Encoding nicht verändert wird (also z.B. bei WinSCP den Binär-Modus und nicht den Text-Modus verwenden). Ansonsten werden später z.B. Sonderzeichen wie ''°C'' falsch angezeigt.

Anschließend kann in die [[Konfiguration]] z.B. folgendes eingetragen werden:
<syntaxhighlight lang="text">
define DWD_Weblink_Generator DWD_OpenData_Weblink
attr DWD_Weblink_Generator IODev DWD
attr DWD_Weblink_Generator forecastDays 4
# refreshRate nur dann setzten, wenn der Browser Java-Script beherrscht:
attr DWD_Weblink_Generator refreshRate 900

define DWD_Weblink weblink htmlCode { DWD_OpenData_Weblink::AsHtmlH("DWD_Weblink_Generator") }
</syntaxhighlight>

Damit legt man das Weblink-Generator-Device an und verknüpft es mit dem DWD_OpenData-Device. Außerdem wird der [[weblink ]] selbst angelegt, der seinerseits mit dem Weblink-Generator-Device verknüpft wird. Der Weblink benötigt für seine Funktion eine bestimmte Auswahl der Vorhersage-Merkmale. Wer das Attribut ''forecastProperties'' des DWD_OpenData-Moduls anpassen will, muss diese Merkmale auf jeden Fall mit berücksichtigen.

Wenn vom Weblink nichts im Browser zu sehen ist, kann das daran liegen, dass der Browser kein aktuelles JavaScript verwendet oder JavaScript deaktiviert ist. Dann sollte das Attribut ''refreshRate'' auf 0 Sekunden eingestellt oder gelöscht werden. Mit aktiviertem Refresh werden die Daten auch ohne Seitenneuaufbau regelmäßig und bei Tab-Wechsel aktualisiert.

Die Liste der erforderlichen Vorhersage-Merkmale finden sich zusammen mit allen weiteren Details zur Installation und Konfiguration in der Modulhilfe von ''98_DWD_OpenData_Weblink.pm'', die man z.B. nach dem Anlegen des Weblink-Generator-Devices über die Weboberfläche abrufen kann.

Hier ein Ausschnitt aus der Darstellung des Weblinks mit [[FHEMWEB]]:
[[File:DWDODweblink.png|500px]]

=== Beispiel für die Einbindung auf einer Webseite außerhalb von FHEM ===
Für manche Anwendungsfälle, etwa die Ansicht in FTUI, ist es erforderlich, das mit dem '''DWD_Weblink_Generator''' erzeugte Bild an anderer Stelle in eine Webseite einzubinden. Dazu kann man folgende Schritte verwenden.

Zunächst wird ein statisches CSS-Stylesheet erzeugt, etwa in der Datei ''ftui_weather.css'' im Unterverzeichnis ''css''. Dorthin werden die ganzen CSS-Klassen geschrieben, die der Webbrowser benötigt, um aus den Daten des DWD_Weblink_Generator eine Tabelle zu machen (siehe den etwas länglichen Code am Ende dieses Abschnitts).

Dann ist zunächst dafür zu sorgen, dass im Header der Webseite, die später die Wettervorhersage anzeigen soll, dieses Stylesheet eingebunden wird. Dazu muss in den Header die Zeile
<syntaxhighlight lang="html">
<link rel="stylesheet" href="css/ftui_weather.css"/>
</syntaxhighlight>
eingetragen werden.

Der zweite Schritt besteht darin, ebenfalls in den Header der betreffenden Webseite ein paar Zeilen JavaScript einzubinden, die dem Holen der Daten dienen:
<syntaxhighlight lang="html">
<script>
function getDWDOpenDataWeblink() {
var fwcsrf = "<HIER DER csrf-Token DES ENTFERNTEN FHEM-SERVERS>";
$. get ("http://<HIER DIE ADRESSE DES ENTFERNTEN FHEM-SERVERS>:8083/fhem?cmd=get%20DWD_Weblink_Generator%20horizontalForecast&XHR=1&fwcsrf=" + fwcsrf,
function (forecastElements) {
$("#DWD_OpenData_Weblink").html(forecastElements);
});
}

function getdata() {
getDWDOpenDataWeblink();
setInterval(getDWDOpenDataWeblink, 900000);
$(window).on("focus", getDWDOpenDataWeblink);
};
</script>
</syntaxhighlight>

Der dritte Schritt besteht darin, auf der betreffenden Webseite einen Ort zu definieren, an welchen das Wettervorhersagebild geschoben wird, z.B.
<syntaxhighlight lang="html">
<div id="DWD_OpenData_Weblink" style="position:absolute; left:10px;top:500px; width:600px; height:200px; float:left; overflow-y:hidden;overflow-x:auto;"></div>
</syntaxhighlight>

Der letzte Schritt sorgt dafür, dass die oben definierte JavaScript-Funktion beim Laden der Webseite auch aufgerufen wird. Dazu muss ein entsprechendes Attribut im body-Tag der Seite eingebaut werden:
<syntaxhighlight lang="html">
<body onload="getdata()">
</syntaxhighlight>

Nachstehend nun der etwas längliche CSS-Code für das statische Stylesheet:
<syntaxhighlight lang="css">
/* weather table with fixed column width */
.weatherForecast {
display: table;
table-layout: fixed;
column-gap: 40px;
}
/* weather table header row */
.weatherHeaderRow {
display: table-header-group;
white-space: nowrap;
}
/* weather table data row */
.weatherDataRow {
display: table-row-group;
}
/* weather table data cells */
#weatherFontBold {
font-weight: bold;
}
.weatherWeekday {
display: table-cell;
min-width: 80px;
text-align: center;
vertical-align: middle;
}
.weatherCondition {
display: table-cell;
position: relative;
top: -4px;
text-align: center;
vertical-align: middle;
font-size: 80%;
word-wrap: break-word;
}
.weatherTemperature {
display: table-cell;
text-align: center;
vertical-align: middle;
font-size: 100%;
white-space: nowrap;
}
.weatherWind {
display: table-cell;
text-align: center;
vertical-align: middle;
font-size: 80%;
padding-top: 3px;
}
/* weather table condition icon cell */
.weatherIcon {
display: table-cell;
position: relative;
text-align: center;
}
/* weather icon */
.weatherIcon img {
width: 100%;
height: auto;
position: relative;
}
/* embedded alert icon with pointer support */
.weatherAlertIcon {
position: absolute;
top: 5px;
right: 5px;
width: 25px;
height: 22px;
background-size: 25px 22px;
background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACgAAAAkCAMAAADM4ogkAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAyppVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2LjE0NjcyOSwgMjAxMi8wNS8wMy0xMzo0MDowMyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIEVsZW1lbnRzIDEyLjAgV2luZG93cyIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDo1RjU1NzJBRDMyRTcxMUU1QTk4MkI0RTkwODEwODQ1QSIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDo1RjU1NzJBRTMyRTcxMUU1QTk4MkI0RTkwODEwODQ1QSI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5jZUlEPSJ4bXAuaWlkOjVGNTU3MkFCMzJFNzExRTVBOTgyQjRFOTA4MTA4NDVBIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOjVGNTU3MkFDMzJFNzExRTVBOTgyQjRFOTA4MTA4NDVBIi8+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8P3hwYWNrZXQgZW5kPSJyIj8+oFydjAAAAwBQTFRF9fX267W51Csy9d7c1VBV9uPc/vz89+nl5YB/2Flk2mZp1Cgv0Csw5pWR7K2t1Soy1Cow7b6y0iUr+/r61jI54X+A+uvq21xV44qO/fj400tU1kxG3nNx2mJp34Bz/Pj2a2tr4Ht91S43fn5+1jA31S0y0iYu1TA1/ff3+/TxEhIS3W1u1jA010Q++efj1kVH1Tk+gYGB6qWh4oWEtra21TI48sjH1VVc1tbW1jY22ltd4YF/1kFHl5eX/vz7/Pz84nZt+evt9+Tm2mNu1Sw14YSD1Ss04YKC0isv4X5/0zc21CUu8cnL0jA20jAz22xy1jE422Zv1i800isw1Cgx11xjKysr1FFZ4X190iQsGRkZ0jY+1TE41Cww0y0y0ykt1i431i4z0y800ikvPz4/AAAA////DQwM1TI30yYs1TE31TA21TE21S401S801S810ycs//7+1TA3///+/v791TI2/v//0Sov0iYt0yYt6urqkZGR1TM40ycu1S414ODg4YB3+/Hw7bK0/vv78fHxh4eH+OPf0i8w1DI30icu1y843Zia/PX13Nvb6aWZ4YKE+fDv21RT00E83G5y3m9x7tDF3Gdu99fW1EJK1ktK3t7e5I+R4oeH3WNp3oCF+vH16ZOJ1Sw27cG31i018dDL4qOf3Wde7Kqe+O7m2ERH+e3o+u/t4YuY/Pb15IqG5p2R4np52TA82mhx2V1p3mpx5oWL66uiRkZG4YOR/v7+1ygz1TxC8dDV9dHS2VJL1CUw8by79+Hg7bq3vr6+9dnR1Tc49d/X11le77yv22hl2lVY+Ofo33540icspqan+/f49N/h5J6m2HB7zczN3nZ88c3FsrKz3HZ74ICC4YGA1oJy10JD+Onj8c3J1Dk71T494oaE4HpxNTU14XRz7Ozs7+/vcG9v+/bz/Pj1/fr3IiIi676/5IJx4Hpr6amn56On6aGd2mlu4X2A22Vm2WFk1jI33GNk+/Ds2VJU2FZW8/Pz78jD3V1v55iY3W1x////C1yJRAAAAQB0Uk5T////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////AFP3ByUAAAMKSURBVHjajNEFWBNxGAbwOXEoUzYnqCgGuPMUUFE8sRuwgDlUEJmK8z6/XWyEEjrswu7u7u7u7u4u7G7FWxoj/J6L9/7v77nnQpTpMM7XFkocV0UOK2VKbkt3/R+4KY0Zlnw8d7ikBeu9VroRcoXPg5F1Y5Mn5wYPaRnGqOxMfPbIGXZfFMxxJGtg0lxzhoWlKpYfSrCd9f4rc4JPKs1l9B1aeabGoLRQTnBxG8T2K2DwLV7FRVTOHi47yKKmxGyAagoGxb7x2cLSMuS0eZIAMopJUaWtkR3M1yUBpe8lkuoj4WYYm8Bf98gaxjdsSik7toKydPQ0OKEzUnGuWcOLWgZPXoCe3Wi6HlS+zVMG/35Zwfq7eqO+wxk4T9N0OYDXKQylnZ4VnKdxM5bfAtDTh6arAlT4IldxXYo6woyS3hwxpRHA12ia7gUA3yKUKL8f7wCPiClMOSsA0VPTMwIkeeoQm+39F1asZECZ02kBFGlH06eEM+Rt0RvFHyX/wNUy7JGex9Q3EGB1U4BCLVXK9D1/wxu1lJS8lMTc36Pp/eZQcaoM9Us9/oSJL8QUGbrDXMNmOvqBJe3TxqC22p/wgIbBlrMsLZSju1pT93dSZDsW/Q3rF/NG3r+xte4zqKY1QY0IBuVvwQ4LazFGUTzRVhexJziahkzyTht8PM6AwXUbWbutj3za2W+5IIxEovYAKxwlww+KV7buYTfzL7TODOGry/tb4KdaCSg/VsFWDfSx/ELLLK9CILl9hBnOEaOq4DN7BZe6lv36++plJ3ST/zDBfEOEN6udBNnNWDHFhTpnihIbNkXKUNfLyyuqeciVOwFvr7oHrApqHhTiPjog6EqdNVFVDIji/JmiiYQbopFM3R0XF6fT6VJ15jFFnUJhSqQRETV5RXfnGykhMea9B2M624ezBaOmuKiv1GDg9TxJ8sIxltB7E0QsT/BqpdrPT9g4P7VaTcZKL4vGDP/psq71BpdSLj9nTmod3mTC+HDfN+FN2jodjlwfGRnoFNg2cH2B7+ca/xJgAFL1l3PxpIx4AAAAAElFTkSuQmCC);
}
.weatherAlertIcon:hover {
opacity: 0.7;
}
.weatherAlertIcon:focus {
opacity: 1.0;
}
/* opaque white background for alerts dialog */
.weatherOverlay {
display: none;
position: fixed;
z-index: 1;
opacity: 0.2;
top: 0;
left: 0;
width: 100%;
height: 100%;
background: white;
}
.weatherAlertIcon:focus .weatherOverlay {
display: block;
}
/* alerts dialog box */
[class ^= weatherAlertBox] {
display: none;
position: absolute;
z-index: 2;
opacity: 1;
top: 0;
border: 3px solid white;
border-radius: 3px;
box-shadow: 0px 0px 6px 4px #666;
background: #EEE;
}
.weatherAlertIcon:focus .weatherAlertBoxLeft {
display: block;
right: -268px;
}
.weatherAlertIcon:focus .weatherAlertBoxCenter {
display: block;
left: -178px;
}
.weatherAlertIcon:focus .weatherAlertBoxRight {
display: block;
left: -312px;
}
/* alerts dialog close button */
.weatherAlertsClose {
position: absolute;
top: -12px;
right: -13px;

border-radius: 12px;
box-shadow: 1px 1px 3px #666;

line-height: 21px;
width: 21px;
background: #606061;

text-align: center;
text-decoration: none;
font-family: Sans-serif;
font-weight: bold;
color: white;
}
.weatherAlertsClose:hover {
opacity: 0.8;
}
/* alerts dialog title */
.weaterAlertsTitle {
font-weight: bold;
color: black;
}
/* alert messages */
[class ^= weaterAlertMessage] {
float: left;
text-align: left;
white-space: nowrap;
}
.weaterAlertMessage p {
white-space: normal;
}
</syntaxhighlight>

DWD OpenData

2024-06-28T18:45:05Z

F Klee: Formattierung optimiert

{{Hinweis|Versionsänderung: Die Vorhersagedaten wurden Mitte September 2018 von CSV auf KML umgestellt. Diese Umstellung ist inkompatibel: das DWD_OpenData-Modul muss aktualisiert werden, einige Reading-Namen haben sich geändert und der Weblink muss deinstalliert und neu installiert werden (siehe diesen {{Link2Forum|Topic=83097|Message=840270|Linktext=Beitrag im Forum}}).}}
{{Infobox Modul
|ModPurpose=Daten vom DWD OpenData Server abrufen
|ModType=d
|ModCmdRef=DWD_OpenData
|ModForumArea=Unterstützende Dienste/Wettermodule
|ModTechName=55_DWD_OpenData.pm
|ModOwner=JensB ({{Link2FU|14024|Forum}}/[[Benutzer Diskussion:JensB|Wiki]])
}}
Der Deutsche Wetterdienst (DWD) stellt Wetterdaten über den [https://www.dwd.de/DE/leistungen/opendata/opendata.html Open Data Server] zur Verfügung. Die Verwendung dieses Dienstes und der vom DWD zur Verfügung gestellten Daten unterliegt den auf der OpenData Webseite beschriebenen Bedingungen. Einen Überblick über die verfügbaren Daten findet man in der Tabelle [https://www.dwd.de/DE/leistungen/opendata/help/inhalt_allgemein/opendata_content_de_en_xls.xls OpenData_weather_content.xls] oder hier: https://opendata.dwd.de/weather/lib/MetElementDefinition.xml.

== Anwendung ==
Aufgrund der unterschiedlichen vom DWD bereitgestellten Datenformate benötigt das Modul zur Dekodierung je nach gewünschtem Funktionsumfang zusätzliche Perl-Module, die nicht standardmäßig vorinstalliert sind und je nach Systemkonfiguration nachinstalliert werden müssen. Außerdem unterstützt das Modul Zeitzonen, um z.B. die Wettervorhersage internationaler Stationen in Ortszeit darstellen zu können. Hierfür sind je nach Systemkonfiguration weitere Einstellungen erforderlich. Auch die Sprache der Wochentage für die Wettervorhersage ist frei wählbar. Je nach Systemkonfiguration ist aber die Standardsprache u.U. auf Englisch eingestellt, was weitere Anpassungen der Systemkonfiguration erforderlich macht.

=== Vorbereitung ===
Im folgenden wird z.T. von einem System mit Rasbian oder Debian mit System-V Startsystem ausgegangen. Auf anderen Betriebssystemen und auf Systemen mit System-D müssen die Installationsschritte ggf. angepasst werden.

1. Für die Wettervorhersage und die Wetterwarnungen:
Installation des Perl-Moduls ''XML::LibXML'' über die System-Kommandozeile mit
<syntaxhighlight lang="bash">
sudo apt-get install libxml-libxml-perl
</syntaxhighlight>
oder mit CPAN.

2. Weiterhin ist das Perl-Modul '' DateTime'' erforderlich. Dieses lässt sich mit <syntaxhighlight lang="bash">sudo apt-get install libdatetime-perl</syntaxhighlight> installieren.

3. Falls man einen eigenen Internet-Proxy nutzt:
Die Konfiguration des Proxies für FHEM erfolgt z.B. durch Eintrag von
<pre>
attr global proxy <myProxyHost>:<myProxyPort>
</pre>
in die [[Konfiguration]], wobei ''myProxyHost'' durch den Namen oder die IP-Adresse des Proxy-Servers ersetzt werden muss und für ''myProxyPort'' der Port des Proxy-Servers eingetragen werden muss (oft 3128).

3. FHEM Uhrzeit und Zeitzone:
Durch Eingabe von
<pre>
{localtime()}
</pre>
in die FHEM-Kommandozeile überprüfen, ob die FHEM-Uhrzeit plausibel ist. Ist dies nicht der Fall sollten die Uhrzeit auf Systemebene überprüft werden und ggf. die Systemeinstellungen angepasst werden.
Ermitteln der Bezeichnung der eigenen Zeitzone über die System-Kommandozeile mit
<pre>
tzselect
</pre>
und diese Bezeichnung in die Datei ''/etc/timezone'' eintragen und
<pre>
export TZ=`cat /etc/timezone`
</pre>
der Datei ''/etc/profile'' hinzufügen und dann das System neu starten. Nun muss die Zeitanzeige in FHEM korrekt sein.

4. FHEM Sprache:
Durch Eingabe von
<pre>
{$ENV{LANG}}
</pre> in die FHEM-Kommandozeile überprüfen, in welcher Sprache der Wochentag angezeigt wird. Stimmt die Sprache nicht, dann auf der System-Kommandozeile
<pre>
dpkg-reconfigure locales
</pre> eingeben und aus der Liste z.B. ''de_DE.UTF-8'' zusätzlich auswählen. Dieser Befehl gilt für Debian-basierte Betriebssysteme - für andere Betriebssysteme ist eine analoge Funktion zu verwenden. Mit Eingabe von
<pre>
locale -a
</pre> auf der System-Kommandozeile überprüfen, ob die ausgewählte Sprache nun zur Verfügung steht. Sollte FHEM nach einem Neustart noch immer nicht die gewünschte Sprache verwenden, kann man auf einem System V Linux durch Hinzufügen von z.B.
<pre>
export LANG=de_DE.UTF-8
</pre> in die Datei ''/etc/init.d/fhem'' (irgendwo zwischen ''start'' und ''perl'') und erneutem Neustart von FHEM die Sprache für FHEM erzwingen. Bei einem Systemd Linux kann man die Einstellungen mit ''systemctl edit --full fhem.service'' bearbeiten. Spätestes jetzt muss die Wochentagsanzeige in FHEM korrekt sein.

5. Nur für den Weblink erforderlich:
Installation des Perl-Moduls ''DateTime'' über die System-Kommandozeile mit
<pre>
sudo apt-get install libdatetime-perl
</pre>
oder mit CPAN.

=== Define ===
Siehe {{Link2CmdRef|Anker=DWD_OpenDatadefine|Label=Commandref}}.

=== Attributes ===
Siehe {{Link2CmdRef|Anker=DWD_OpenDataattr|Label=Commandref}}.

=== Readings ===
Die Prognosewerte sind wie folgt aufgebaut:
fc<day>_[<sample>_]<property>
Eine Beschreibung der über 70 verfügbaren Eigenschaften und ihrer Maßeinheiten finden Sie hier. Die Maßeinheiten für Temperaturen und Windgeschwindigkeiten werden jeweils in °C und km/h umgerechnet. In den folgenden Abschnitten sind nur einige ausgewählte Eigenschaften aufgeführt:

* day – relativer Tag (0 .. 9) basierend auf dem Zeitzonenattribut, wobei 0 für heute steht

* sample – relative Zeit (0 .. 3, 7 oder 23), die einem Vielfachen von 6, 3 oder 1 Stunde UTC entspricht, abhängig vom Attribut forecastResolution

* day properties (normalerweise für 06:00 Uhr Stationszeit, siehe Rohdaten der Station für tatsächliche Zeitbeziehung)
date – Datum basierend auf dem Zeitzonenattribut
weekday – abgekürzter Wochentag basierend auf dem Zeitzonenattribut in der Sprache Ihres FHEM-Systems
Tn [°C] – Mindesttemperatur der letzten 12 Stunden
Tx [°C] – Höchsttemperatur der letzten 12 Stunden (normalerweise um 18:00 Stationszeit)
Tm [°C] – Durchschnittstemperatur der letzten 24 Stunden
Tg [°C] – Mindesttemperatur 5 cm über dem Boden der letzten 12 Stunden
PEvap [kg/m2] – Evapotranspiration der letzten 24 Stunden
SunD [s] - Gesamtsonnenscheindauer des vorherigen Tages

* hour properties time - Zeit basierend auf dem Zeitzonenattribut
TTT [°C] - Trockentemperatur in 2 Metern Höhe über dem Boden
Td [°C] - Taupunkttemperatur in 2 Metern Höhe über dem Boden
DD [°] - durchschnittliche Windrichtung in 10 m Höhe über dem Boden
FF [km/h] - durchschnittliche Windgeschwindigkeit in 10 m Höhe über dem Boden
FX1 [km/h] - maximale Windgeschwindigkeit in der letzten Stunde
SunD1 [s] - Sonnenscheindauer in der letzten Stunde
SunD3 [s] - Sonnenscheindauer in den letzten 3 Stunden
RR1c [kg/m2] - Niederschlagsmenge in der letzten Stunde
RR3c [kg/m2] - Niederschlagsmenge in den letzten 3 Stunden
RR6c [kg/m2] - Niederschlagsmenge in den letzten 6 Stunden
R600 [%] - Regenwahrscheinlichkeit in den letzten 6 Stunden
RRhc [kg/m2] - Niederschlagsmenge in den letzten 12 Stunden
Rh00 [%] - Regenwahrscheinlichkeit in den letzten 12 Stunden
RRdc [kg/m2] - Niederschlagsmenge in den letzten 24 Stunden
Rd00 [%] - Regenwahrscheinlichkeit in den letzten 24 Stunden
ww - Wettercode (siehe WMO 4680/4677, SYNOP)
wwd - deutsche Wettercodebeschreibung
VV [m] - horizontale Sichtweite
Neff [%] - effektive Wolkenbedeckung
Nl [%] - untere Wolkenbedeckung unter 2000 m
Nm [%] - mittlere Wolkenbedeckung unter 7000 m
Nh [%] - hohe Wolkenbedeckung über 7000 m
PPPP [hPa] - Druckäquivalent auf Meereshöhe

* Zusätzliche Tageseigenschaften, nicht vom DWD bereitgestellt
SunRise - Sonnenaufgangszeit basierend auf dem Zeitzonenattribut
SunSet - Sonnenuntergangszeit basierend auf dem Zeitzonenattribut

* Zusätzliche Stundeneigenschaften, nicht vom DWD bereitgestellt
SunAz [°] - Sonnenazimut
SunEl [°] - Sonnenhöhe
SunUp - Sonnenaufgang (0: Nacht, 1: Tag)

Zusätzlich gibt es globale Prognosewerte:

* fc_state - Status der letzten Prognoseaktualisierung, mögliche Werte sind „updated“ und „error: ...“
* fc_station - Prognosestationscode (WMO oder DWD)
* fc_description - Stationsbeschreibung
* fc_coordinates - Weltkoordinate und Höhe der Station
* fc_time - Zeitpunkt der Veröffentlichung der Prognose basierend auf dem Zeitzonenattribut
* fc_copyright - rechtliche Informationen, müssen mit Prognosedaten angezeigt werden, siehe DWD-Nutzungsbedingungen

Die Alarmwerte sind nach Beginn sortiert und folgendermaßen aufgebaut:
a_<index>_<property>

* index - Alarmindex, beginnend mit 0, Gesamtanzahl a_count, sortiert nach Beginn

* alert properties
category - „Met“ oder „Health“
event - numerischer Ereigniscode, siehe DWD-Dokumentation für Details
eventDesc - kurze Ereignisbeschreibung in ausgewählter Sprache
eventGroup - Ereignisgruppe, siehe DWD-Dokumentation für Details
responseType - „None“ = nein Anweisungen, „Vorbereiten“ = Anweisungen, „AllClear“ = Alarm gelöscht
urgency – „Immediate“ = Warnung oder „Zukünftig“ = Information
severity – „Minor, „Moderate“, „Severe“ or „Extreme“
areaColor – RGB-Farbe je nach Dringlichkeit und Schweregrad, durch Komma getrennte Dezimalzahlen
onset – Startzeit des Alarms basierend auf dem Zeitzonenattribut
expires – Endzeit des Alarms basierend auf dem Zeitzonenattribut
headline – Überschrift in ausgewählter Sprache, normalerweise eine Kombination der Eigenschaften Dringlichkeit und Ereignis
description – Beschreibung des Alarms in ausgewählter Sprache
instruction – Sicherheitsanweisungen in ausgewählter Sprache
area – numerische Warnzellen-ID
areaDesc – Beschreibung des Bereichs, z. B. „Stadt Berlin“
altitude – min. Höhe [m]
ceiling – max. Höhe [m]

Zusätzlich gibt es einige globale Alarmwerte:

* a_state – Status der letzten Alarmaktualisierung, mögliche Werte sind „aktualisiert“ und „Fehler: ...“

* a_time – Zeitpunkt des Downloads der letzten Alarmaktualisierung, basierend auf der Zeitzone attribut

* a_count – Anzahl der für die ausgewählte Warnzellen-ID verfügbaren Alarme

* a_copyright – rechtliche Informationen, müssen mit Prognosedaten angezeigt werden, siehe DWD-Nutzungsbedingungen, nicht verfügbar, wenn count null ist

Alarme sollten unabhängig von der Dringlichkeit für onset <= now < expires und responseType != „AllClear“ als aktiv betrachtet werden. Inaktive Alarme mit responseType = „AllClear“ können relevante Anweisungen enthalten.

Beachten Sie, dass alle Alarmwerte bei jeder Aktualisierung vollständig ersetzt und neu indexiert werden!

Weitere Informationen zu den Alarmeigenschaften finden Sie in der Dokumentation des CAP DWS-Profils.

== Anwendungsbeispiele ==
=== Beispiel zur Modul-Einrichtung ===

* Wettervorhersage
Für die Wettervorhersage muss der Stationscode ermittelt werden. Dazu den [https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/mosmix_stationskatalog.pdf MOSMIX Stationskatalog] herunterladen, öffnen und die gewünschte Station heraussuchen (Spalte ''id''). Einen Teil der deutschen Stationen kann man auch der [https://www.dwd.de/DE/derdwd/messnetz/bodenbeobachtung/messnetzkarte_boden.pdf Bodenmessnetzkarte] entnehmen. Den ermittelten Stationscode kann man dann entweder für eine Einzelabfrage als Parameter für das Kommando ''get forecast'' verwenden oder für die automatische Aktualisierung als Attribut ''forecastStation'' hinterlegen. Insgesamt werden vom DWD mehr als 70 Merkmale zur Verfügung gestellt. Eine Auflistung findet sich im Dokument [https://opendata.dwd.de/weather/lib/MetElementDefinition.xml MetElementDefinition]. Nur ein kleiner Teil der Merkmale wird in der Standardeinstellung des Moduls als Reading zur Verfügung gestellt. Wer andere Merkmale benötigt muss sie mit Komma getrennt dem Attribut ''forecastProperties'' zuweisen. Es empfiehlt sich zur Performance-Optimierung sowohl das Attribut ''forecastDays'' als auch das Attribut ''forecastProperties'' auf den tatsächlichen Bedarf einzustellen.

* Wetterwarnungen
Für die Wetterwarnungen muss die Warnzelle ermittelt werden. Dazu [https://www.dwd.de/DE/leistungen/opendata/help/warnungen/cap_warncellids_csv.csv Warnzellen-ID Katalog] herunterladen, öffnen und die gewünschte Warnzelle heraussuchen. Unterstützt werden Gemeinden (beginnen mit 8), Landkreise (beginnen mit 1 oder 9) oder Küste (beginnen mit 5). Die Warnzellen-ID kann man dann entweder für eine Einzelabfrage als Parameter für das Kommando ''get alerts'' verwenden oder für die automatische Aktualisierung als Attribut ''alertArea'' hinterlegen. Die Warnzellen-ID ist ab der 2. Stelle identisch mit den ersten Ziffern des amtlichen Gemeindeschlüssels. Man kann z.B. den Namen von Gemeinde oder Landkreis bei den [https://www.statistik-bw.de/Statistik-Portal/gemeindeverz.asp Statistischen Ämtern des Bundes und der Länder] eingeben, den amtlichen Gemeindeschlüssel ermitteln und dann mit vorangestellter 1, 8 oder 9 im Warnzellen-ID Katalog des DWD nach einem Eintrag mit exakter oder weitgehender Übereinstimmung suchen. Wem das zu kompliziert vorkommt, der kann bei mehrdeutigen Gemeinde- bzw. Landkreisbezeichnungen auch versuchen auszuprobieren, welche die richtige Warnzellen-ID ist.

Um das Modul mit automatisch Aktualisierung von Vorhersage und Wetterwarnungen zu nutzen, kann z.B. folgendes in die [[Konfiguration]] eingetragen werden:

<pre>
define DWD DWD_OpenData
attr DWD alertArea 111000000
attr DWD forecastStation 99810
attr DWD forecastDays 3
attr DWD forecastWW2Text 1
</pre>

* Performance
Das DWD_OpenData-Modul ist ein Datenmodul mit relativ vielen Readings. In der Standardkonfiguration wird, wie bei jedem anderen FHEM Modul, bei jeder Änderung jedes Readings ein FHEM internes Ereignis erzeugt, damit andere FHEM Devices auf diese Änderungen reagieren können. Diese Ereignisse sorgen auch dafür, dass man Änderungen in der Weboberfläche sofort angezeigt bekommt, ohne die Webseite neu aufzurufen. Interessiert sich aber kein FHEM Device für die Änderungsbenachrichtigung bestimmter Readings, entsteht unnötiger Verarbeitungs-Overhead, der je nach FHEM Konfiguration und verfügbarer CPU-Leistung auch mehrere Sekunden benötigen kann und in dieser Zeit andere Abläufe blockiert. Um die Performance zu optimieren, empfiehlt es sich, mit [[event-on-update-reading]] für eine angepasste und dadurch effizientere Verarbeitung zu sorgen, indem man nur für jene Readings Ereignisse zulässt, welche man für die Weiterverarbeitung braucht. Der DWD_OpenData_Weblink braucht z.B. gar keine Ereignisse, um zu funktionieren. Hier eine minimalistische Beispielkonfiguration:

<pre>
attr DWD event-on-update-reading state,fc_state,a_state
</pre>

Weitere Details zur Installation und Konfiguration des Moduls finden sich in der
{{Link2CmdRef|Anker=DWD_OpenData|Label=Commandref}}.

=== Beispiel für die Einrichtung eines Meteogramms ===
Um den vorhergesagten Wetterverlauf als Meteogramm in Kurvenform mit [[SVG]] darzustellen, kann man wie folgt vorgehen:

1. 99_myUtils.pm

Für die Bestimmung der Werte für den SVG-Plot wird eine Perl-Funktion benötigt, die in die Datei 99_myUtils.pm vor dem Ende eingefügt wird. Wer diese FHEM-Datei noch nicht nutzt, legt sie einfach an (siehe [[99_myUtils_anlegen]]).
<syntaxhighlight lang="perl">
package main;

use strict;
use warnings;

...

#
# (c) mumpitzstuff 19.12.2018
#
# see https://forum.fhem.de/index.php/topic,83097.msg874150.html#msg874150
#
sub logProxy_dwd2Plot($$$$;$$$)
{
my ($device, $fcValue, $from, $to, $fcHour, $expMode, $shiftTime) = @_;
my $regex;
my @rl;

return undef if(!$device);

if ($fcValue =~ s/_$//)
{
$regex = "^fc[\\d]+_[\\d]+_".$fcValue."\$";
}
else
{
$regex = "^fc[\\d]+_".$fcValue."\$";
}

$fcHour = 12 if(!defined($fcHour));
$expMode = "point" if(!defined($expMode));
#Log3 undef,2, "Regex: ".$regex;

# ermitteln aller relevanten Readings
if ( defined($defs{$device}) )
{
if ( $defs{$device}{TYPE} eq "DWD_OpenData" )
{
@rl = sort
{
my ($an) = ($a =~ m/fc(\d+)_.*/);
my ($bn) = ($b =~ m/fc(\d+)_.*/);
my ($ao) = ($a =~ m/fc\d+_(\d+).*/);
my ($bo) = ($b =~ m/fc\d+_(\d+).*/);
$an <=> $bn or $ao <=> $bo or $a cmp $b;
} ( grep /${regex}/,keys %{$defs{$device}{READINGS}} );
return undef if ( !@rl );
}
else
{
Log3 undef, 2, "logProxy_dwd2Plot: $device is not a DWD_OpenData device";
return undef;
}
}

my $fromsec = SVG_time_to_sec($from);
my $tosec = SVG_time_to_sec($to);
my $sec = $fromsec;
my ($h, $hp, $fcDay, $mday, $mon, $year);
my $timestamp;

my $reading;
my $value;
my $prev_value;
my $min = 999999;
my $max = -999999;
my $ret = "";

# while not end of plot range reached
while (($sec < $tosec) && @rl)
{
#remember previous value for start of plot range
$prev_value = $value;

$reading = shift @rl;
($fcDay) = $reading =~ m/^fc(\d+).*/;
($hp) = $reading =~ m/^fc\d+_(\d+).*/;
#Log 1, "hp: ".$hp;

if ($hp)
{
$h = ReadingsVal($device, "fc".$fcDay."_".$hp."_time", $fcHour);
if ($h =~ m/^(\d+):\d+/)
{
$h = $1;
}
}
else
{
$h = $fcHour;
}

$value = ReadingsVal($device, $reading, undef);

# calculate minutes of sunshine per hour
if ($fcValue =~ /^SunD(\d+)/)
{
if (defined($1))
{
$value = $value / ($1 * 36);
}
else
{
$value = $value / (12 * 36);
}
}

# calculate amount of rain per hour
if ($fcValue =~ /^RR(\d+)c$/)
{
if (defined($1))
{
$value /= $1;
}
}

($year, $mon, $mday) = split('\-',ReadingsVal($device, "fc".$fcDay."_date",undef));
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, $h, 0, 0);
$sec = SVG_time_to_sec($timestamp);
if (defined($shiftTime))
{
$sec += $shiftTime;
$timestamp = logProxy_shiftTime($timestamp, $shiftTime);
}

# skip all values before start of plot range
next if ( $sec < $fromsec );

# add first value at start of plot range
if ( !$ret && $prev_value )
{
$min = $prev_value if ( $prev_value < $min );
$max = $prev_value if ( $prev_value > $max );
$ret .= "$from $prev_value\n";
}

# done if after end of plot range
last if ($sec > $tosec);

$min = $value if ( $value < $min );
$max = $value if ( $value > $max );

# add actual control point
$ret .= "$timestamp $value\n";
}

if (($sec < $tosec) && !@rl && ($expMode eq "day"))
{
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, 23, 59, 59);
$_ = SVG_time_to_sec($timestamp);
if (defined($shiftTime))
{
$_ += $shiftTime;
$timestamp = logProxy_shiftTime($timestamp, $shiftTime);
}

if ($_ < $tosec)
{
$ret .= "$timestamp $value\n";
}
else
{
$ret .= "$to $value\n";
}
}
elsif (($sec > $tosec) && ($expMode eq "day"))
{
$value = $prev_value + ($value - $prev_value) * (86400 + ($tosec - $sec)) / 86400;
$ret .= "$to $value\n";
}

return ($ret, $min, $max, $prev_value);
}

1;
</syntaxhighlight>

2. LogProxy

Wer bereits ein [[logProxy]]-Device hat, muss den Namen seines logProxy-Devices in die weiter unter aufgeführte GPlot-Konfiguration eintragen. Ansonsten wird es wie folgt neu erstellt:
<pre>
define LogProxy logProxy
</pre>

3. FileLog

Das Meteogramm kennt anders als andere FHEM-Plots keine Vergangenheit außer heute. Trotzdem wird aus formalen Gründen ein [[FileLog]]-Device benötigt. Dazu kann ein beliebiges vorhandenes FileLog-Device verwendet werden. Wer will, kann hierfür aber auch ein neues FileLog Device für das DWD_OpenData-Device anlegen (Achtung: wird schnell umfangreich):
<pre>
define FileLog_DWD FileLog ./log/DWD-%Y-%m.log DWD
</pre>

Im folgenden wird für das FileLog-Device der Platzhalter ''FileLog_Dummy'' verwendet, der mit dem Namen des gewählten FileLog-Devices zu ersetzen ist.

4. SVG Plot

Das eigentliche Meteogramm ist ein SVG-Device. Will man mehrere Tage darstellen bietet sich die folgende Definition an:
<pre>
define SVG_DWD SVG FileLog_Dummy:SVG_DWD:CURRENT
attr SVG_DWD fixedoffset 6
attr SVG_DWD fixedrange 7days
attr SVG_DWD nrAxis 1,2
</pre>

Dabei muss das SVG-Attribut ''fixedoffset'' entweder gleich oder kleiner als die Einstellung des DWD_OpenData-Attributs ''forecastDays'' (Standardwert: 6 Tage) gewählt werden und das SVG-Attribut ''fixedrange'' um eins größer als ''fixedoffset'' eingestellt werden.

Will man stattdessen nur die nächsten 24 Stunden anzeigen, nimmt man folgende Einstellungen:
<pre>
define SVG_DWD SVG FileLog_Dummy:SVG_DWD:CURRENT
attr SVG_DWD endPlotNow 1
attr SVG_DWD fixedoffset 1
attr SVG_FileLog_WETTER_DWD_3 label "Tmin: $data{max1} °C, Tmax: $data{min1} °C"
attr SVG_DWD nrAxis 1,2
</pre>

Um die DWD_OpenData-Readings mit dem Plot zu verknüpfen, muss man nun die GPlot-Konfigurationsdatei des SVG-Plots manuell bearbeiten. Dazu auf den Link klicken, der im SVG_DWD-Device am Internal ''GPLOTFILE'' steht. Die y-Wertebereiche für die Regenmenge und die Temperaturen sind im Beispiel auskommentiert (Autorange). Das kann man so lassen oder man stellt sie nach den eigenen Wetter-Gegebenheiten ein. Je nach Konfiguration des DWD_OpenData-Attributs ''forecastResolution'' sind aber noch einige weitere Einstellungen anzupassen. Das folgende Beispiel ist für die 3h-Auflösung:
<pre>
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Wettervorhersage'
set ytics
set y2tics
set grid ytics
set ylabel "Regen [mm]"
#set yrange [0:4]
set y2label "Temperatur [°C]"
#set y2range [-5:35]
set y3label "Wolken/Regen/Sonne [%]"
set y3range [0:100]

#LogProxy Func:logProxy_dwd2Plot("DWD","TTT_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","Tx",$from,$to,18,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","Tn",$from,$to,6,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","SunD3_",$from,$to,0,"day",(-3*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","RR3c_",$from,$to,0,"day",(-3*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","FX1_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","R600_",$from,$to,0,"day",(-3*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","Neff_",$from,$to,0,"day")
#LogProxy ConstX:TimeNow(),0,100
#LogProxy ConstY:0

plot "<IN>" using 1:2 axes x1y2 title 'T' ls l0 lw 2 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y2 title 'Tmax' ls l0dot lw 2 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y2 title 'Tmin' ls l0dot lw 2 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Sonne' ls l4fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Regenmenge' ls l2fill lw 1 with steps,\
"<IN>" using 1:2 axes x1y3 title 'Wind' ls l1 lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Regen' ls l5fill lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Wolken' ls l6fill lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 notitle ls l5 lw 4 with lines,\
"<IN>" using 1:2 axes x1y2 notitle ls l5 lw 1 with lines
</pre>

Verwendet man dagegen eine Auflösung von 1 Stunde, sind folgende LogProxy-Einträge erforderlich:
<pre>
#LogProxy Func:logProxy_dwd2Plot("DWD","TTT_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","Tx",$from,$to,18,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","Tn",$from,$to,6,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","SunD1_",$from,$to,0,"day",(-1*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","RR1c_",$from,$to,0,"day",(-1*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","FX1_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","R101_",$from,$to,0,"day",(-0.5*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","Neff_",$from,$to,0,"day")
#LogProxy ConstX:TimeNow(),0,100
#LogProxy ConstY:0
</pre>

Für die Darstellung der nächsten 24 Stunden mit einer Auflösung von 1 Stunde nimmt man folgende GPlot-Konfiguration:
<pre>
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics
set y2tics
set y3tics
set grid xtics y2tics
set ylabel "Regen [mm]"
set y2label "Temperatur [°C]"
set y3label "Wolken/Regen/Sonne [%]"
set y3range [0:100]

#LogProxy Func:logProxy_dwd2Plot("DWD","TTT_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","SunD1_",$from,$to,0,"day",(-1*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","RR1c_",$from,$to,0,"day",(-1*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","FX1_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","R101_",$from,$to,0,"day",(-0.5*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","Neff_",$from,$to,0,"day")
#LogProxy ConstY:0

plot "<IN>" using 1:2 axes x1y2 title 'T' ls l0 lw 2 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Sonne' ls l4fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Regenmenge' ls l2fill lw 1 with steps,\
"<IN>" using 1:2 axes x1y3 title 'Wind' ls l1 lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Regen' ls l5fill lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Wolken' ls l6fill lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y2 notitle ls l2 lw 2 with lines
</pre>

Je nachdem, welche Auflösung man verwendet, werden unterschiedliche Readings des DWD_OpenData-Devices benötigt. Diese sind in den LogProxy-Zeilen in der GPlot-Konfigurationsdatei zu finden und müssen auf jeden Fall dem Attribut ''forecastProperties'' des DWD_OpenData-Device hinzugefügt werden.

Viele Detaileinstellungen des Meteogramms lassen sich individualisieren. Man kann z.B. mehr oder weniger Daten anzeigen und zumindest für ''heute'' auch aktuelle Messwerte hinzufügen.

Hier ein Beispiel für ein Meteogramm über 4 Tage mit 3 Stunden Auflösung:

[[File:DWDODmeteogram4d3h.png|500px]]

=== Beispiel für die Einrichtung eines Weblinks ===
Zur graphischen Darstellung der Vorhersage und der Wetterwarnungen mit [[FHEMWEB]] steht das Modul [https://raw.githubusercontent.com/jnsbyr/fhem/master/FHEM/98_DWD_OpenData_Weblink.pm 98_DWD_OpenData_Weblink.pm] zur Verfügung.

Zunächst die Moduldatei herunterladen und in das Modulverzeichnis ''fhem/FHEM'' kopieren. Entweder die Datei direkt auf den FHEM-Server herunterladen (z.B. mit ''wget'') oder beim indirekten Herunterladen darauf achten, dass dabei das Encoding nicht verändert wird (also z.B. bei WinSCP den Binär-Modus und nicht den Text-Modus verwenden). Ansonsten werden später z.B. Sonderzeichen wie ''°C'' falsch angezeigt.

Anschließend kann in die [[Konfiguration]] z.B. folgendes eingetragen werden:
<syntaxhighlight lang="text">
define DWD_Weblink_Generator DWD_OpenData_Weblink
attr DWD_Weblink_Generator IODev DWD
attr DWD_Weblink_Generator forecastDays 4
# refreshRate nur dann setzten, wenn der Browser Java-Script beherrscht:
attr DWD_Weblink_Generator refreshRate 900

define DWD_Weblink weblink htmlCode { DWD_OpenData_Weblink::AsHtmlH("DWD_Weblink_Generator") }
</syntaxhighlight>

Damit legt man das Weblink-Generator-Device an und verknüpft es mit dem DWD_OpenData-Device. Außerdem wird der [[weblink ]] selbst angelegt, der seinerseits mit dem Weblink-Generator-Device verknüpft wird. Der Weblink benötigt für seine Funktion eine bestimmte Auswahl der Vorhersage-Merkmale. Wer das Attribut ''forecastProperties'' des DWD_OpenData-Moduls anpassen will, muss diese Merkmale auf jeden Fall mit berücksichtigen.

Wenn vom Weblink nichts im Browser zu sehen ist, kann das daran liegen, dass der Browser kein aktuelles JavaScript verwendet oder JavaScript deaktiviert ist. Dann sollte das Attribut ''refreshRate'' auf 0 Sekunden eingestellt oder gelöscht werden. Mit aktiviertem Refresh werden die Daten auch ohne Seitenneuaufbau regelmäßig und bei Tab-Wechsel aktualisiert.

Die Liste der erforderlichen Vorhersage-Merkmale finden sich zusammen mit allen weiteren Details zur Installation und Konfiguration in der Modulhilfe von ''98_DWD_OpenData_Weblink.pm'', die man z.B. nach dem Anlegen des Weblink-Generator-Devices über die Weboberfläche abrufen kann.

Hier ein Ausschnitt aus der Darstellung des Weblinks mit [[FHEMWEB]]:
[[File:DWDODweblink.png|500px]]

=== Beispiel für die Einbindung auf einer Webseite außerhalb von FHEM ===
Für manche Anwendungsfälle, etwa die Ansicht in FTUI, ist es erforderlich, das mit dem '''DWD_Weblink_Generator''' erzeugte Bild an anderer Stelle in eine Webseite einzubinden. Dazu kann man folgende Schritte verwenden.

Zunächst wird ein statisches CSS-Stylesheet erzeugt, etwa in der Datei ''ftui_weather.css'' im Unterverzeichnis ''css''. Dorthin werden die ganzen CSS-Klassen geschrieben, die der Webbrowser benötigt, um aus den Daten des DWD_Weblink_Generator eine Tabelle zu machen (siehe den etwas länglichen Code am Ende dieses Abschnitts).

Dann ist zunächst dafür zu sorgen, dass im Header der Webseite, die später die Wettervorhersage anzeigen soll, dieses Stylesheet eingebunden wird. Dazu muss in den Header die Zeile
<syntaxhighlight lang="html">
<link rel="stylesheet" href="css/ftui_weather.css"/>
</syntaxhighlight>
eingetragen werden.

Der zweite Schritt besteht darin, ebenfalls in den Header der betreffenden Webseite ein paar Zeilen JavaScript einzubinden, die dem Holen der Daten dienen:
<syntaxhighlight lang="html">
<script>
function getDWDOpenDataWeblink() {
var fwcsrf = "<HIER DER csrf-Token DES ENTFERNTEN FHEM-SERVERS>";
$. get ("http://<HIER DIE ADRESSE DES ENTFERNTEN FHEM-SERVERS>:8083/fhem?cmd=get%20DWD_Weblink_Generator%20horizontalForecast&XHR=1&fwcsrf=" + fwcsrf,
function (forecastElements) {
$("#DWD_OpenData_Weblink").html(forecastElements);
});
}

function getdata() {
getDWDOpenDataWeblink();
setInterval(getDWDOpenDataWeblink, 900000);
$(window).on("focus", getDWDOpenDataWeblink);
};
</script>
</syntaxhighlight>

Der dritte Schritt besteht darin, auf der betreffenden Webseite einen Ort zu definieren, an welchen das Wettervorhersagebild geschoben wird, z.B.
<syntaxhighlight lang="html">
<div id="DWD_OpenData_Weblink" style="position:absolute; left:10px;top:500px; width:600px; height:200px; float:left; overflow-y:hidden;overflow-x:auto;"></div>
</syntaxhighlight>

Der letzte Schritt sorgt dafür, dass die oben definierte JavaScript-Funktion beim Laden der Webseite auch aufgerufen wird. Dazu muss ein entsprechendes Attribut im body-Tag der Seite eingebaut werden:
<syntaxhighlight lang="html">
<body onload="getdata()">
</syntaxhighlight>

Nachstehend nun der etwas längliche CSS-Code für das statische Stylesheet:
<syntaxhighlight lang="css">
/* weather table with fixed column width */
.weatherForecast {
display: table;
table-layout: fixed;
column-gap: 40px;
}
/* weather table header row */
.weatherHeaderRow {
display: table-header-group;
white-space: nowrap;
}
/* weather table data row */
.weatherDataRow {
display: table-row-group;
}
/* weather table data cells */
#weatherFontBold {
font-weight: bold;
}
.weatherWeekday {
display: table-cell;
min-width: 80px;
text-align: center;
vertical-align: middle;
}
.weatherCondition {
display: table-cell;
position: relative;
top: -4px;
text-align: center;
vertical-align: middle;
font-size: 80%;
word-wrap: break-word;
}
.weatherTemperature {
display: table-cell;
text-align: center;
vertical-align: middle;
font-size: 100%;
white-space: nowrap;
}
.weatherWind {
display: table-cell;
text-align: center;
vertical-align: middle;
font-size: 80%;
padding-top: 3px;
}
/* weather table condition icon cell */
.weatherIcon {
display: table-cell;
position: relative;
text-align: center;
}
/* weather icon */
.weatherIcon img {
width: 100%;
height: auto;
position: relative;
}
/* embedded alert icon with pointer support */
.weatherAlertIcon {
position: absolute;
top: 5px;
right: 5px;
width: 25px;
height: 22px;
background-size: 25px 22px;
background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACgAAAAkCAMAAADM4ogkAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAyppVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2LjE0NjcyOSwgMjAxMi8wNS8wMy0xMzo0MDowMyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIEVsZW1lbnRzIDEyLjAgV2luZG93cyIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDo1RjU1NzJBRDMyRTcxMUU1QTk4MkI0RTkwODEwODQ1QSIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDo1RjU1NzJBRTMyRTcxMUU1QTk4MkI0RTkwODEwODQ1QSI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5jZUlEPSJ4bXAuaWlkOjVGNTU3MkFCMzJFNzExRTVBOTgyQjRFOTA4MTA4NDVBIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOjVGNTU3MkFDMzJFNzExRTVBOTgyQjRFOTA4MTA4NDVBIi8+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8P3hwYWNrZXQgZW5kPSJyIj8+oFydjAAAAwBQTFRF9fX267W51Csy9d7c1VBV9uPc/vz89+nl5YB/2Flk2mZp1Cgv0Csw5pWR7K2t1Soy1Cow7b6y0iUr+/r61jI54X+A+uvq21xV44qO/fj400tU1kxG3nNx2mJp34Bz/Pj2a2tr4Ht91S43fn5+1jA31S0y0iYu1TA1/ff3+/TxEhIS3W1u1jA010Q++efj1kVH1Tk+gYGB6qWh4oWEtra21TI48sjH1VVc1tbW1jY22ltd4YF/1kFHl5eX/vz7/Pz84nZt+evt9+Tm2mNu1Sw14YSD1Ss04YKC0isv4X5/0zc21CUu8cnL0jA20jAz22xy1jE422Zv1i800isw1Cgx11xjKysr1FFZ4X190iQsGRkZ0jY+1TE41Cww0y0y0ykt1i431i4z0y800ikvPz4/AAAA////DQwM1TI30yYs1TE31TA21TE21S401S801S810ycs//7+1TA3///+/v791TI2/v//0Sov0iYt0yYt6urqkZGR1TM40ycu1S414ODg4YB3+/Hw7bK0/vv78fHxh4eH+OPf0i8w1DI30icu1y843Zia/PX13Nvb6aWZ4YKE+fDv21RT00E83G5y3m9x7tDF3Gdu99fW1EJK1ktK3t7e5I+R4oeH3WNp3oCF+vH16ZOJ1Sw27cG31i018dDL4qOf3Wde7Kqe+O7m2ERH+e3o+u/t4YuY/Pb15IqG5p2R4np52TA82mhx2V1p3mpx5oWL66uiRkZG4YOR/v7+1ygz1TxC8dDV9dHS2VJL1CUw8by79+Hg7bq3vr6+9dnR1Tc49d/X11le77yv22hl2lVY+Ofo33540icspqan+/f49N/h5J6m2HB7zczN3nZ88c3FsrKz3HZ74ICC4YGA1oJy10JD+Onj8c3J1Dk71T494oaE4HpxNTU14XRz7Ozs7+/vcG9v+/bz/Pj1/fr3IiIi676/5IJx4Hpr6amn56On6aGd2mlu4X2A22Vm2WFk1jI33GNk+/Ds2VJU2FZW8/Pz78jD3V1v55iY3W1x////C1yJRAAAAQB0Uk5T////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////AFP3ByUAAAMKSURBVHjajNEFWBNxGAbwOXEoUzYnqCgGuPMUUFE8sRuwgDlUEJmK8z6/XWyEEjrswu7u7u7u7u4u7G7FWxoj/J6L9/7v77nnQpTpMM7XFkocV0UOK2VKbkt3/R+4KY0Zlnw8d7ikBeu9VroRcoXPg5F1Y5Mn5wYPaRnGqOxMfPbIGXZfFMxxJGtg0lxzhoWlKpYfSrCd9f4rc4JPKs1l9B1aeabGoLRQTnBxG8T2K2DwLV7FRVTOHi47yKKmxGyAagoGxb7x2cLSMuS0eZIAMopJUaWtkR3M1yUBpe8lkuoj4WYYm8Bf98gaxjdsSik7toKydPQ0OKEzUnGuWcOLWgZPXoCe3Wi6HlS+zVMG/35Zwfq7eqO+wxk4T9N0OYDXKQylnZ4VnKdxM5bfAtDTh6arAlT4IldxXYo6woyS3hwxpRHA12ia7gUA3yKUKL8f7wCPiClMOSsA0VPTMwIkeeoQm+39F1asZECZ02kBFGlH06eEM+Rt0RvFHyX/wNUy7JGex9Q3EGB1U4BCLVXK9D1/wxu1lJS8lMTc36Pp/eZQcaoM9Us9/oSJL8QUGbrDXMNmOvqBJe3TxqC22p/wgIbBlrMsLZSju1pT93dSZDsW/Q3rF/NG3r+xte4zqKY1QY0IBuVvwQ4LazFGUTzRVhexJziahkzyTht8PM6AwXUbWbutj3za2W+5IIxEovYAKxwlww+KV7buYTfzL7TODOGry/tb4KdaCSg/VsFWDfSx/ELLLK9CILl9hBnOEaOq4DN7BZe6lv36++plJ3ST/zDBfEOEN6udBNnNWDHFhTpnihIbNkXKUNfLyyuqeciVOwFvr7oHrApqHhTiPjog6EqdNVFVDIji/JmiiYQbopFM3R0XF6fT6VJ15jFFnUJhSqQRETV5RXfnGykhMea9B2M624ezBaOmuKiv1GDg9TxJ8sIxltB7E0QsT/BqpdrPT9g4P7VaTcZKL4vGDP/psq71BpdSLj9nTmod3mTC+HDfN+FN2jodjlwfGRnoFNg2cH2B7+ca/xJgAFL1l3PxpIx4AAAAAElFTkSuQmCC);
}
.weatherAlertIcon:hover {
opacity: 0.7;
}
.weatherAlertIcon:focus {
opacity: 1.0;
}
/* opaque white background for alerts dialog */
.weatherOverlay {
display: none;
position: fixed;
z-index: 1;
opacity: 0.2;
top: 0;
left: 0;
width: 100%;
height: 100%;
background: white;
}
.weatherAlertIcon:focus .weatherOverlay {
display: block;
}
/* alerts dialog box */
[class ^= weatherAlertBox] {
display: none;
position: absolute;
z-index: 2;
opacity: 1;
top: 0;
border: 3px solid white;
border-radius: 3px;
box-shadow: 0px 0px 6px 4px #666;
background: #EEE;
}
.weatherAlertIcon:focus .weatherAlertBoxLeft {
display: block;
right: -268px;
}
.weatherAlertIcon:focus .weatherAlertBoxCenter {
display: block;
left: -178px;
}
.weatherAlertIcon:focus .weatherAlertBoxRight {
display: block;
left: -312px;
}
/* alerts dialog close button */
.weatherAlertsClose {
position: absolute;
top: -12px;
right: -13px;

border-radius: 12px;
box-shadow: 1px 1px 3px #666;

line-height: 21px;
width: 21px;
background: #606061;

text-align: center;
text-decoration: none;
font-family: Sans-serif;
font-weight: bold;
color: white;
}
.weatherAlertsClose:hover {
opacity: 0.8;
}
/* alerts dialog title */
.weaterAlertsTitle {
font-weight: bold;
color: black;
}
/* alert messages */
[class ^= weaterAlertMessage] {
float: left;
text-align: left;
white-space: nowrap;
}
.weaterAlertMessage p {
white-space: normal;
}
</syntaxhighlight>

DWD OpenData

2024-06-28T18:25:45Z

F Klee: Readings hinzu gefügt

{{Hinweis|Versionsänderung: Die Vorhersagedaten wurden Mitte September 2018 von CSV auf KML umgestellt. Diese Umstellung ist inkompatibel: das DWD_OpenData-Modul muss aktualisiert werden, einige Reading-Namen haben sich geändert und der Weblink muss deinstalliert und neu installiert werden (siehe diesen {{Link2Forum|Topic=83097|Message=840270|Linktext=Beitrag im Forum}}).}}
{{Infobox Modul
|ModPurpose=Daten vom DWD OpenData Server abrufen
|ModType=d
|ModCmdRef=DWD_OpenData
|ModForumArea=Unterstützende Dienste/Wettermodule
|ModTechName=55_DWD_OpenData.pm
|ModOwner=JensB ({{Link2FU|14024|Forum}}/[[Benutzer Diskussion:JensB|Wiki]])
}}
Der Deutsche Wetterdienst (DWD) stellt Wetterdaten über den [https://www.dwd.de/DE/leistungen/opendata/opendata.html Open Data Server] zur Verfügung. Die Verwendung dieses Dienstes und der vom DWD zur Verfügung gestellten Daten unterliegt den auf der OpenData Webseite beschriebenen Bedingungen. Einen Überblick über die verfügbaren Daten findet man in der Tabelle [https://www.dwd.de/DE/leistungen/opendata/help/inhalt_allgemein/opendata_content_de_en_xls.xls OpenData_weather_content.xls] oder hier: https://opendata.dwd.de/weather/lib/MetElementDefinition.xml.

== Anwendung ==
Aufgrund der unterschiedlichen vom DWD bereitgestellten Datenformate benötigt das Modul zur Dekodierung je nach gewünschtem Funktionsumfang zusätzliche Perl-Module, die nicht standardmäßig vorinstalliert sind und je nach Systemkonfiguration nachinstalliert werden müssen. Außerdem unterstützt das Modul Zeitzonen, um z.B. die Wettervorhersage internationaler Stationen in Ortszeit darstellen zu können. Hierfür sind je nach Systemkonfiguration weitere Einstellungen erforderlich. Auch die Sprache der Wochentage für die Wettervorhersage ist frei wählbar. Je nach Systemkonfiguration ist aber die Standardsprache u.U. auf Englisch eingestellt, was weitere Anpassungen der Systemkonfiguration erforderlich macht.

=== Vorbereitung ===
Im folgenden wird z.T. von einem System mit Rasbian oder Debian mit System-V Startsystem ausgegangen. Auf anderen Betriebssystemen und auf Systemen mit System-D müssen die Installationsschritte ggf. angepasst werden.

1. Für die Wettervorhersage und die Wetterwarnungen:
Installation des Perl-Moduls ''XML::LibXML'' über die System-Kommandozeile mit
<syntaxhighlight lang="bash">
sudo apt-get install libxml-libxml-perl
</syntaxhighlight>
oder mit CPAN.

2. Weiterhin ist das Perl-Modul '' DateTime'' erforderlich. Dieses lässt sich mit <syntaxhighlight lang="bash">sudo apt-get install libdatetime-perl</syntaxhighlight> installieren.

3. Falls man einen eigenen Internet-Proxy nutzt:
Die Konfiguration des Proxies für FHEM erfolgt z.B. durch Eintrag von
<pre>
attr global proxy <myProxyHost>:<myProxyPort>
</pre>
in die [[Konfiguration]], wobei ''myProxyHost'' durch den Namen oder die IP-Adresse des Proxy-Servers ersetzt werden muss und für ''myProxyPort'' der Port des Proxy-Servers eingetragen werden muss (oft 3128).

3. FHEM Uhrzeit und Zeitzone:
Durch Eingabe von
<pre>
{localtime()}
</pre>
in die FHEM-Kommandozeile überprüfen, ob die FHEM-Uhrzeit plausibel ist. Ist dies nicht der Fall sollten die Uhrzeit auf Systemebene überprüft werden und ggf. die Systemeinstellungen angepasst werden.
Ermitteln der Bezeichnung der eigenen Zeitzone über die System-Kommandozeile mit
<pre>
tzselect
</pre>
und diese Bezeichnung in die Datei ''/etc/timezone'' eintragen und
<pre>
export TZ=`cat /etc/timezone`
</pre>
der Datei ''/etc/profile'' hinzufügen und dann das System neu starten. Nun muss die Zeitanzeige in FHEM korrekt sein.

4. FHEM Sprache:
Durch Eingabe von
<pre>
{$ENV{LANG}}
</pre> in die FHEM-Kommandozeile überprüfen, in welcher Sprache der Wochentag angezeigt wird. Stimmt die Sprache nicht, dann auf der System-Kommandozeile
<pre>
dpkg-reconfigure locales
</pre> eingeben und aus der Liste z.B. ''de_DE.UTF-8'' zusätzlich auswählen. Dieser Befehl gilt für Debian-basierte Betriebssysteme - für andere Betriebssysteme ist eine analoge Funktion zu verwenden. Mit Eingabe von
<pre>
locale -a
</pre> auf der System-Kommandozeile überprüfen, ob die ausgewählte Sprache nun zur Verfügung steht. Sollte FHEM nach einem Neustart noch immer nicht die gewünschte Sprache verwenden, kann man auf einem System V Linux durch Hinzufügen von z.B.
<pre>
export LANG=de_DE.UTF-8
</pre> in die Datei ''/etc/init.d/fhem'' (irgendwo zwischen ''start'' und ''perl'') und erneutem Neustart von FHEM die Sprache für FHEM erzwingen. Bei einem Systemd Linux kann man die Einstellungen mit ''systemctl edit --full fhem.service'' bearbeiten. Spätestes jetzt muss die Wochentagsanzeige in FHEM korrekt sein.

5. Nur für den Weblink erforderlich:
Installation des Perl-Moduls ''DateTime'' über die System-Kommandozeile mit
<pre>
sudo apt-get install libdatetime-perl
</pre>
oder mit CPAN.

=== Define ===
Siehe {{Link2CmdRef|Anker=DWD_OpenDatadefine|Label=Commandref}}.

=== Attributes ===
Siehe {{Link2CmdRef|Anker=DWD_OpenDataattr|Label=Commandref}}.

=== Readings ===
Die Prognosewerte sind wie folgt aufgebaut:
fc<day>_[<sample>_]<property>
Eine Beschreibung der über 70 verfügbaren Eigenschaften und ihrer Maßeinheiten finden Sie hier. Die Maßeinheiten für Temperaturen und Windgeschwindigkeiten werden jeweils in °C und km/h umgerechnet. In den folgenden Abschnitten sind nur einige ausgewählte Eigenschaften aufgeführt:

* day – relativer Tag (0 .. 9) basierend auf dem Zeitzonenattribut, wobei 0 für heute steht

* sample – relative Zeit (0 .. 3, 7 oder 23), die einem Vielfachen von 6, 3 oder 1 Stunde UTC entspricht, abhängig vom Attribut forecastResolution

* day properties (normalerweise für 06:00 Uhr Stationszeit, siehe Rohdaten der Station für tatsächliche Zeitbeziehung) date – Datum basierend auf dem Zeitzonenattribut weekday – abgekürzter Wochentag basierend auf dem Zeitzonenattribut in der Sprache Ihres FHEM-Systems Tn [°C] – Mindesttemperatur der letzten 12 Stunden Tx [°C] – Höchsttemperatur der letzten 12 Stunden (normalerweise um 18:00 Stationszeit) Tm [°C] – Durchschnittstemperatur der letzten 24 Stunden Tg [°C] – Mindesttemperatur 5 cm über dem Boden der letzten 12 Stunden PEvap [kg/m2] – Evapotranspiration der letzten 24 Stunden SunD [s] - Gesamtsonnenscheindauer des vorherigen Tages

* hour properties time - Zeit basierend auf dem Zeitzonenattribut TTT [°C] - Trockentemperatur in 2 Metern Höhe über dem Boden Td [°C] - Taupunkttemperatur in 2 Metern Höhe über dem Boden DD [°] - durchschnittliche Windrichtung in 10 m Höhe über dem Boden FF [km/h] - durchschnittliche Windgeschwindigkeit in 10 m Höhe über dem Boden FX1 [km/h] - maximale Windgeschwindigkeit in der letzten Stunde SunD1 [s] - Sonnenscheindauer in der letzten Stunde SunD3 [s] - Sonnenscheindauer in den letzten 3 Stunden RR1c [kg/m2] - Niederschlagsmenge in der letzten Stunde RR3c [kg/m2] - Niederschlagsmenge in den letzten 3 Stunden RR6c [kg/m2] - Niederschlagsmenge in den letzten 6 Stunden R600 [%] - Regenwahrscheinlichkeit in den letzten 6 Stunden RRhc [kg/m2] - Niederschlagsmenge in den letzten 12 Stunden Rh00 [%] - Regenwahrscheinlichkeit in den letzten 12 Stunden RRdc [kg/m2] - Niederschlagsmenge in den letzten 24 Stunden Rd00 [%] - Regenwahrscheinlichkeit in den letzten 24 Stunden ww - Wettercode (siehe WMO 4680/4677, SYNOP) wwd - deutsche Wettercodebeschreibung VV [m] - horizontale Sichtweite Neff [%] - effektive Wolkenbedeckung Nl [%] - untere Wolkenbedeckung unter 2000 m Nm [%] - mittlere Wolkenbedeckung unter 7000 m Nh [%] - hohe Wolkenbedeckung über 7000 m PPPP [hPa] - Druckäquivalent auf Meereshöhe

* Zusätzliche Tageseigenschaften, nicht vom DWD bereitgestellt SunRise - Sonnenaufgangszeit basierend auf dem Zeitzonenattribut SunSet - Sonnenuntergangszeit basierend auf dem Zeitzonenattribut

* Zusätzliche Stundeneigenschaften, nicht vom DWD bereitgestellt SunAz [°] - Sonnenazimut SunEl [°] - Sonnenhöhe SunUp - Sonnenaufgang (0: Nacht, 1: Tag)

Zusätzlich gibt es globale Prognosewerte:

* fc_state - Status der letzten Prognoseaktualisierung, mögliche Werte sind „updated“ und „error: ...“
* fc_station - Prognosestationscode (WMO oder DWD)
* fc_description - Stationsbeschreibung
* fc_coordinates - Weltkoordinate und Höhe der Station
* fc_time - Zeitpunkt der Veröffentlichung der Prognose basierend auf dem Zeitzonenattribut
* fc_copyright - rechtliche Informationen, müssen mit Prognosedaten angezeigt werden, siehe DWD-Nutzungsbedingungen

Die Alarmwerte sind nach Beginn sortiert und folgendermaßen aufgebaut:
a_<index>_<property>

* index - Alarmindex, beginnend mit 0, Gesamtanzahl a_count, sortiert nach Beginn

* alert properties category - „Met“ oder „Health“ event - numerischer Ereigniscode, siehe DWD-Dokumentation für Details eventDesc - kurze Ereignisbeschreibung in ausgewählter Sprache eventGroup - Ereignisgruppe, siehe DWD-Dokumentation für Details responseType - „None“ = nein Anweisungen, „Vorbereiten“ = Anweisungen, „AllClear“ = Alarm gelöscht urgency – „Immediate“ = Warnung oder „Zukünftig“ = Information severity – „Minor, „Moderate“, „Severe“ or „Extreme“ areaColor – RGB-Farbe je nach Dringlichkeit und Schweregrad, durch Komma getrennte Dezimalzahlen onset – Startzeit des Alarms basierend auf dem Zeitzonenattribut expires – Endzeit des Alarms basierend auf dem Zeitzonenattribut headline – Überschrift in ausgewählter Sprache, normalerweise eine Kombination der Eigenschaften Dringlichkeit und Ereignis description – Beschreibung des Alarms in ausgewählter Sprache instruction – Sicherheitsanweisungen in ausgewählter Sprache area – numerische Warnzellen-ID areaDesc – Beschreibung des Bereichs, z. B. „Stadt Berlin“ altitude – min. Höhe [m] ceiling – max. Höhe [m]

Zusätzlich gibt es einige globale Alarmwerte:

* a_state – Status der letzten Alarmaktualisierung, mögliche Werte sind „aktualisiert“ und „Fehler: ...“

* a_time – Zeitpunkt des Downloads der letzten Alarmaktualisierung, basierend auf der Zeitzone attribut

* a_count – Anzahl der für die ausgewählte Warnzellen-ID verfügbaren Alarme

* a_copyright – rechtliche Informationen, müssen mit Prognosedaten angezeigt werden, siehe DWD-Nutzungsbedingungen, nicht verfügbar, wenn count null ist

Alarme sollten unabhängig von der Dringlichkeit für onset <= now < expires und responseType != „AllClear“ als aktiv betrachtet werden. Inaktive Alarme mit responseType = „AllClear“ können relevante Anweisungen enthalten.

Beachten Sie, dass alle Alarmwerte bei jeder Aktualisierung vollständig ersetzt und neu indexiert werden!

Weitere Informationen zu den Alarmeigenschaften finden Sie in der Dokumentation des CAP DWS-Profils.

== Anwendungsbeispiele ==
=== Beispiel zur Modul-Einrichtung ===

* Wettervorhersage
Für die Wettervorhersage muss der Stationscode ermittelt werden. Dazu den [https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/mosmix_stationskatalog.pdf MOSMIX Stationskatalog] herunterladen, öffnen und die gewünschte Station heraussuchen (Spalte ''id''). Einen Teil der deutschen Stationen kann man auch der [https://www.dwd.de/DE/derdwd/messnetz/bodenbeobachtung/messnetzkarte_boden.pdf Bodenmessnetzkarte] entnehmen. Den ermittelten Stationscode kann man dann entweder für eine Einzelabfrage als Parameter für das Kommando ''get forecast'' verwenden oder für die automatische Aktualisierung als Attribut ''forecastStation'' hinterlegen. Insgesamt werden vom DWD mehr als 70 Merkmale zur Verfügung gestellt. Eine Auflistung findet sich im Dokument [https://opendata.dwd.de/weather/lib/MetElementDefinition.xml MetElementDefinition]. Nur ein kleiner Teil der Merkmale wird in der Standardeinstellung des Moduls als Reading zur Verfügung gestellt. Wer andere Merkmale benötigt muss sie mit Komma getrennt dem Attribut ''forecastProperties'' zuweisen. Es empfiehlt sich zur Performance-Optimierung sowohl das Attribut ''forecastDays'' als auch das Attribut ''forecastProperties'' auf den tatsächlichen Bedarf einzustellen.

* Wetterwarnungen
Für die Wetterwarnungen muss die Warnzelle ermittelt werden. Dazu [https://www.dwd.de/DE/leistungen/opendata/help/warnungen/cap_warncellids_csv.csv Warnzellen-ID Katalog] herunterladen, öffnen und die gewünschte Warnzelle heraussuchen. Unterstützt werden Gemeinden (beginnen mit 8), Landkreise (beginnen mit 1 oder 9) oder Küste (beginnen mit 5). Die Warnzellen-ID kann man dann entweder für eine Einzelabfrage als Parameter für das Kommando ''get alerts'' verwenden oder für die automatische Aktualisierung als Attribut ''alertArea'' hinterlegen. Die Warnzellen-ID ist ab der 2. Stelle identisch mit den ersten Ziffern des amtlichen Gemeindeschlüssels. Man kann z.B. den Namen von Gemeinde oder Landkreis bei den [https://www.statistik-bw.de/Statistik-Portal/gemeindeverz.asp Statistischen Ämtern des Bundes und der Länder] eingeben, den amtlichen Gemeindeschlüssel ermitteln und dann mit vorangestellter 1, 8 oder 9 im Warnzellen-ID Katalog des DWD nach einem Eintrag mit exakter oder weitgehender Übereinstimmung suchen. Wem das zu kompliziert vorkommt, der kann bei mehrdeutigen Gemeinde- bzw. Landkreisbezeichnungen auch versuchen auszuprobieren, welche die richtige Warnzellen-ID ist.

Um das Modul mit automatisch Aktualisierung von Vorhersage und Wetterwarnungen zu nutzen, kann z.B. folgendes in die [[Konfiguration]] eingetragen werden:

<pre>
define DWD DWD_OpenData
attr DWD alertArea 111000000
attr DWD forecastStation 99810
attr DWD forecastDays 3
attr DWD forecastWW2Text 1
</pre>

* Performance
Das DWD_OpenData-Modul ist ein Datenmodul mit relativ vielen Readings. In der Standardkonfiguration wird, wie bei jedem anderen FHEM Modul, bei jeder Änderung jedes Readings ein FHEM internes Ereignis erzeugt, damit andere FHEM Devices auf diese Änderungen reagieren können. Diese Ereignisse sorgen auch dafür, dass man Änderungen in der Weboberfläche sofort angezeigt bekommt, ohne die Webseite neu aufzurufen. Interessiert sich aber kein FHEM Device für die Änderungsbenachrichtigung bestimmter Readings, entsteht unnötiger Verarbeitungs-Overhead, der je nach FHEM Konfiguration und verfügbarer CPU-Leistung auch mehrere Sekunden benötigen kann und in dieser Zeit andere Abläufe blockiert. Um die Performance zu optimieren, empfiehlt es sich, mit [[event-on-update-reading]] für eine angepasste und dadurch effizientere Verarbeitung zu sorgen, indem man nur für jene Readings Ereignisse zulässt, welche man für die Weiterverarbeitung braucht. Der DWD_OpenData_Weblink braucht z.B. gar keine Ereignisse, um zu funktionieren. Hier eine minimalistische Beispielkonfiguration:

<pre>
attr DWD event-on-update-reading state,fc_state,a_state
</pre>

Weitere Details zur Installation und Konfiguration des Moduls finden sich in der
{{Link2CmdRef|Anker=DWD_OpenData|Label=Commandref}}.

=== Beispiel für die Einrichtung eines Meteogramms ===
Um den vorhergesagten Wetterverlauf als Meteogramm in Kurvenform mit [[SVG]] darzustellen, kann man wie folgt vorgehen:

1. 99_myUtils.pm

Für die Bestimmung der Werte für den SVG-Plot wird eine Perl-Funktion benötigt, die in die Datei 99_myUtils.pm vor dem Ende eingefügt wird. Wer diese FHEM-Datei noch nicht nutzt, legt sie einfach an (siehe [[99_myUtils_anlegen]]).
<syntaxhighlight lang="perl">
package main;

use strict;
use warnings;

...

#
# (c) mumpitzstuff 19.12.2018
#
# see https://forum.fhem.de/index.php/topic,83097.msg874150.html#msg874150
#
sub logProxy_dwd2Plot($$$$;$$$)
{
my ($device, $fcValue, $from, $to, $fcHour, $expMode, $shiftTime) = @_;
my $regex;
my @rl;

return undef if(!$device);

if ($fcValue =~ s/_$//)
{
$regex = "^fc[\\d]+_[\\d]+_".$fcValue."\$";
}
else
{
$regex = "^fc[\\d]+_".$fcValue."\$";
}

$fcHour = 12 if(!defined($fcHour));
$expMode = "point" if(!defined($expMode));
#Log3 undef,2, "Regex: ".$regex;

# ermitteln aller relevanten Readings
if ( defined($defs{$device}) )
{
if ( $defs{$device}{TYPE} eq "DWD_OpenData" )
{
@rl = sort
{
my ($an) = ($a =~ m/fc(\d+)_.*/);
my ($bn) = ($b =~ m/fc(\d+)_.*/);
my ($ao) = ($a =~ m/fc\d+_(\d+).*/);
my ($bo) = ($b =~ m/fc\d+_(\d+).*/);
$an <=> $bn or $ao <=> $bo or $a cmp $b;
} ( grep /${regex}/,keys %{$defs{$device}{READINGS}} );
return undef if ( !@rl );
}
else
{
Log3 undef, 2, "logProxy_dwd2Plot: $device is not a DWD_OpenData device";
return undef;
}
}

my $fromsec = SVG_time_to_sec($from);
my $tosec = SVG_time_to_sec($to);
my $sec = $fromsec;
my ($h, $hp, $fcDay, $mday, $mon, $year);
my $timestamp;

my $reading;
my $value;
my $prev_value;
my $min = 999999;
my $max = -999999;
my $ret = "";

# while not end of plot range reached
while (($sec < $tosec) && @rl)
{
#remember previous value for start of plot range
$prev_value = $value;

$reading = shift @rl;
($fcDay) = $reading =~ m/^fc(\d+).*/;
($hp) = $reading =~ m/^fc\d+_(\d+).*/;
#Log 1, "hp: ".$hp;

if ($hp)
{
$h = ReadingsVal($device, "fc".$fcDay."_".$hp."_time", $fcHour);
if ($h =~ m/^(\d+):\d+/)
{
$h = $1;
}
}
else
{
$h = $fcHour;
}

$value = ReadingsVal($device, $reading, undef);

# calculate minutes of sunshine per hour
if ($fcValue =~ /^SunD(\d+)/)
{
if (defined($1))
{
$value = $value / ($1 * 36);
}
else
{
$value = $value / (12 * 36);
}
}

# calculate amount of rain per hour
if ($fcValue =~ /^RR(\d+)c$/)
{
if (defined($1))
{
$value /= $1;
}
}

($year, $mon, $mday) = split('\-',ReadingsVal($device, "fc".$fcDay."_date",undef));
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, $h, 0, 0);
$sec = SVG_time_to_sec($timestamp);
if (defined($shiftTime))
{
$sec += $shiftTime;
$timestamp = logProxy_shiftTime($timestamp, $shiftTime);
}

# skip all values before start of plot range
next if ( $sec < $fromsec );

# add first value at start of plot range
if ( !$ret && $prev_value )
{
$min = $prev_value if ( $prev_value < $min );
$max = $prev_value if ( $prev_value > $max );
$ret .= "$from $prev_value\n";
}

# done if after end of plot range
last if ($sec > $tosec);

$min = $value if ( $value < $min );
$max = $value if ( $value > $max );

# add actual control point
$ret .= "$timestamp $value\n";
}

if (($sec < $tosec) && !@rl && ($expMode eq "day"))
{
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, 23, 59, 59);
$_ = SVG_time_to_sec($timestamp);
if (defined($shiftTime))
{
$_ += $shiftTime;
$timestamp = logProxy_shiftTime($timestamp, $shiftTime);
}

if ($_ < $tosec)
{
$ret .= "$timestamp $value\n";
}
else
{
$ret .= "$to $value\n";
}
}
elsif (($sec > $tosec) && ($expMode eq "day"))
{
$value = $prev_value + ($value - $prev_value) * (86400 + ($tosec - $sec)) / 86400;
$ret .= "$to $value\n";
}

return ($ret, $min, $max, $prev_value);
}

1;
</syntaxhighlight>

2. LogProxy

Wer bereits ein [[logProxy]]-Device hat, muss den Namen seines logProxy-Devices in die weiter unter aufgeführte GPlot-Konfiguration eintragen. Ansonsten wird es wie folgt neu erstellt:
<pre>
define LogProxy logProxy
</pre>

3. FileLog

Das Meteogramm kennt anders als andere FHEM-Plots keine Vergangenheit außer heute. Trotzdem wird aus formalen Gründen ein [[FileLog]]-Device benötigt. Dazu kann ein beliebiges vorhandenes FileLog-Device verwendet werden. Wer will, kann hierfür aber auch ein neues FileLog Device für das DWD_OpenData-Device anlegen (Achtung: wird schnell umfangreich):
<pre>
define FileLog_DWD FileLog ./log/DWD-%Y-%m.log DWD
</pre>

Im folgenden wird für das FileLog-Device der Platzhalter ''FileLog_Dummy'' verwendet, der mit dem Namen des gewählten FileLog-Devices zu ersetzen ist.

4. SVG Plot

Das eigentliche Meteogramm ist ein SVG-Device. Will man mehrere Tage darstellen bietet sich die folgende Definition an:
<pre>
define SVG_DWD SVG FileLog_Dummy:SVG_DWD:CURRENT
attr SVG_DWD fixedoffset 6
attr SVG_DWD fixedrange 7days
attr SVG_DWD nrAxis 1,2
</pre>

Dabei muss das SVG-Attribut ''fixedoffset'' entweder gleich oder kleiner als die Einstellung des DWD_OpenData-Attributs ''forecastDays'' (Standardwert: 6 Tage) gewählt werden und das SVG-Attribut ''fixedrange'' um eins größer als ''fixedoffset'' eingestellt werden.

Will man stattdessen nur die nächsten 24 Stunden anzeigen, nimmt man folgende Einstellungen:
<pre>
define SVG_DWD SVG FileLog_Dummy:SVG_DWD:CURRENT
attr SVG_DWD endPlotNow 1
attr SVG_DWD fixedoffset 1
attr SVG_FileLog_WETTER_DWD_3 label "Tmin: $data{max1} °C, Tmax: $data{min1} °C"
attr SVG_DWD nrAxis 1,2
</pre>

Um die DWD_OpenData-Readings mit dem Plot zu verknüpfen, muss man nun die GPlot-Konfigurationsdatei des SVG-Plots manuell bearbeiten. Dazu auf den Link klicken, der im SVG_DWD-Device am Internal ''GPLOTFILE'' steht. Die y-Wertebereiche für die Regenmenge und die Temperaturen sind im Beispiel auskommentiert (Autorange). Das kann man so lassen oder man stellt sie nach den eigenen Wetter-Gegebenheiten ein. Je nach Konfiguration des DWD_OpenData-Attributs ''forecastResolution'' sind aber noch einige weitere Einstellungen anzupassen. Das folgende Beispiel ist für die 3h-Auflösung:
<pre>
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Wettervorhersage'
set ytics
set y2tics
set grid ytics
set ylabel "Regen [mm]"
#set yrange [0:4]
set y2label "Temperatur [°C]"
#set y2range [-5:35]
set y3label "Wolken/Regen/Sonne [%]"
set y3range [0:100]

#LogProxy Func:logProxy_dwd2Plot("DWD","TTT_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","Tx",$from,$to,18,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","Tn",$from,$to,6,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","SunD3_",$from,$to,0,"day",(-3*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","RR3c_",$from,$to,0,"day",(-3*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","FX1_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","R600_",$from,$to,0,"day",(-3*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","Neff_",$from,$to,0,"day")
#LogProxy ConstX:TimeNow(),0,100
#LogProxy ConstY:0

plot "<IN>" using 1:2 axes x1y2 title 'T' ls l0 lw 2 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y2 title 'Tmax' ls l0dot lw 2 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y2 title 'Tmin' ls l0dot lw 2 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Sonne' ls l4fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Regenmenge' ls l2fill lw 1 with steps,\
"<IN>" using 1:2 axes x1y3 title 'Wind' ls l1 lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Regen' ls l5fill lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Wolken' ls l6fill lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 notitle ls l5 lw 4 with lines,\
"<IN>" using 1:2 axes x1y2 notitle ls l5 lw 1 with lines
</pre>

Verwendet man dagegen eine Auflösung von 1 Stunde, sind folgende LogProxy-Einträge erforderlich:
<pre>
#LogProxy Func:logProxy_dwd2Plot("DWD","TTT_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","Tx",$from,$to,18,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","Tn",$from,$to,6,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","SunD1_",$from,$to,0,"day",(-1*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","RR1c_",$from,$to,0,"day",(-1*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","FX1_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","R101_",$from,$to,0,"day",(-0.5*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","Neff_",$from,$to,0,"day")
#LogProxy ConstX:TimeNow(),0,100
#LogProxy ConstY:0
</pre>

Für die Darstellung der nächsten 24 Stunden mit einer Auflösung von 1 Stunde nimmt man folgende GPlot-Konfiguration:
<pre>
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics
set y2tics
set y3tics
set grid xtics y2tics
set ylabel "Regen [mm]"
set y2label "Temperatur [°C]"
set y3label "Wolken/Regen/Sonne [%]"
set y3range [0:100]

#LogProxy Func:logProxy_dwd2Plot("DWD","TTT_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","SunD1_",$from,$to,0,"day",(-1*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","RR1c_",$from,$to,0,"day",(-1*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","FX1_",$from,$to,0,"day")
#LogProxy Func:logProxy_dwd2Plot("DWD","R101_",$from,$to,0,"day",(-0.5*3600))
#LogProxy Func:logProxy_dwd2Plot("DWD","Neff_",$from,$to,0,"day")
#LogProxy ConstY:0

plot "<IN>" using 1:2 axes x1y2 title 'T' ls l0 lw 2 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Sonne' ls l4fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Regenmenge' ls l2fill lw 1 with steps,\
"<IN>" using 1:2 axes x1y3 title 'Wind' ls l1 lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Regen' ls l5fill lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y3 title 'Wolken' ls l6fill lw 1 with quadraticSmooth,\
"<IN>" using 1:2 axes x1y2 notitle ls l2 lw 2 with lines
</pre>

Je nachdem, welche Auflösung man verwendet, werden unterschiedliche Readings des DWD_OpenData-Devices benötigt. Diese sind in den LogProxy-Zeilen in der GPlot-Konfigurationsdatei zu finden und müssen auf jeden Fall dem Attribut ''forecastProperties'' des DWD_OpenData-Device hinzugefügt werden.

Viele Detaileinstellungen des Meteogramms lassen sich individualisieren. Man kann z.B. mehr oder weniger Daten anzeigen und zumindest für ''heute'' auch aktuelle Messwerte hinzufügen.

Hier ein Beispiel für ein Meteogramm über 4 Tage mit 3 Stunden Auflösung:

[[File:DWDODmeteogram4d3h.png|500px]]

=== Beispiel für die Einrichtung eines Weblinks ===
Zur graphischen Darstellung der Vorhersage und der Wetterwarnungen mit [[FHEMWEB]] steht das Modul [https://raw.githubusercontent.com/jnsbyr/fhem/master/FHEM/98_DWD_OpenData_Weblink.pm 98_DWD_OpenData_Weblink.pm] zur Verfügung.

Zunächst die Moduldatei herunterladen und in das Modulverzeichnis ''fhem/FHEM'' kopieren. Entweder die Datei direkt auf den FHEM-Server herunterladen (z.B. mit ''wget'') oder beim indirekten Herunterladen darauf achten, dass dabei das Encoding nicht verändert wird (also z.B. bei WinSCP den Binär-Modus und nicht den Text-Modus verwenden). Ansonsten werden später z.B. Sonderzeichen wie ''°C'' falsch angezeigt.

Anschließend kann in die [[Konfiguration]] z.B. folgendes eingetragen werden:
<syntaxhighlight lang="text">
define DWD_Weblink_Generator DWD_OpenData_Weblink
attr DWD_Weblink_Generator IODev DWD
attr DWD_Weblink_Generator forecastDays 4
# refreshRate nur dann setzten, wenn der Browser Java-Script beherrscht:
attr DWD_Weblink_Generator refreshRate 900

define DWD_Weblink weblink htmlCode { DWD_OpenData_Weblink::AsHtmlH("DWD_Weblink_Generator") }
</syntaxhighlight>

Damit legt man das Weblink-Generator-Device an und verknüpft es mit dem DWD_OpenData-Device. Außerdem wird der [[weblink ]] selbst angelegt, der seinerseits mit dem Weblink-Generator-Device verknüpft wird. Der Weblink benötigt für seine Funktion eine bestimmte Auswahl der Vorhersage-Merkmale. Wer das Attribut ''forecastProperties'' des DWD_OpenData-Moduls anpassen will, muss diese Merkmale auf jeden Fall mit berücksichtigen.

Wenn vom Weblink nichts im Browser zu sehen ist, kann das daran liegen, dass der Browser kein aktuelles JavaScript verwendet oder JavaScript deaktiviert ist. Dann sollte das Attribut ''refreshRate'' auf 0 Sekunden eingestellt oder gelöscht werden. Mit aktiviertem Refresh werden die Daten auch ohne Seitenneuaufbau regelmäßig und bei Tab-Wechsel aktualisiert.

Die Liste der erforderlichen Vorhersage-Merkmale finden sich zusammen mit allen weiteren Details zur Installation und Konfiguration in der Modulhilfe von ''98_DWD_OpenData_Weblink.pm'', die man z.B. nach dem Anlegen des Weblink-Generator-Devices über die Weboberfläche abrufen kann.

Hier ein Ausschnitt aus der Darstellung des Weblinks mit [[FHEMWEB]]:
[[File:DWDODweblink.png|500px]]

=== Beispiel für die Einbindung auf einer Webseite außerhalb von FHEM ===
Für manche Anwendungsfälle, etwa die Ansicht in FTUI, ist es erforderlich, das mit dem '''DWD_Weblink_Generator''' erzeugte Bild an anderer Stelle in eine Webseite einzubinden. Dazu kann man folgende Schritte verwenden.

Zunächst wird ein statisches CSS-Stylesheet erzeugt, etwa in der Datei ''ftui_weather.css'' im Unterverzeichnis ''css''. Dorthin werden die ganzen CSS-Klassen geschrieben, die der Webbrowser benötigt, um aus den Daten des DWD_Weblink_Generator eine Tabelle zu machen (siehe den etwas länglichen Code am Ende dieses Abschnitts).

Dann ist zunächst dafür zu sorgen, dass im Header der Webseite, die später die Wettervorhersage anzeigen soll, dieses Stylesheet eingebunden wird. Dazu muss in den Header die Zeile
<syntaxhighlight lang="html">
<link rel="stylesheet" href="css/ftui_weather.css"/>
</syntaxhighlight>
eingetragen werden.

Der zweite Schritt besteht darin, ebenfalls in den Header der betreffenden Webseite ein paar Zeilen JavaScript einzubinden, die dem Holen der Daten dienen:
<syntaxhighlight lang="html">
<script>
function getDWDOpenDataWeblink() {
var fwcsrf = "<HIER DER csrf-Token DES ENTFERNTEN FHEM-SERVERS>";
$. get ("http://<HIER DIE ADRESSE DES ENTFERNTEN FHEM-SERVERS>:8083/fhem?cmd=get%20DWD_Weblink_Generator%20horizontalForecast&XHR=1&fwcsrf=" + fwcsrf,
function (forecastElements) {
$("#DWD_OpenData_Weblink").html(forecastElements);
});
}

function getdata() {
getDWDOpenDataWeblink();
setInterval(getDWDOpenDataWeblink, 900000);
$(window).on("focus", getDWDOpenDataWeblink);
};
</script>
</syntaxhighlight>

Der dritte Schritt besteht darin, auf der betreffenden Webseite einen Ort zu definieren, an welchen das Wettervorhersagebild geschoben wird, z.B.
<syntaxhighlight lang="html">
<div id="DWD_OpenData_Weblink" style="position:absolute; left:10px;top:500px; width:600px; height:200px; float:left; overflow-y:hidden;overflow-x:auto;"></div>
</syntaxhighlight>

Der letzte Schritt sorgt dafür, dass die oben definierte JavaScript-Funktion beim Laden der Webseite auch aufgerufen wird. Dazu muss ein entsprechendes Attribut im body-Tag der Seite eingebaut werden:
<syntaxhighlight lang="html">
<body onload="getdata()">
</syntaxhighlight>

Nachstehend nun der etwas längliche CSS-Code für das statische Stylesheet:
<syntaxhighlight lang="css">
/* weather table with fixed column width */
.weatherForecast {
display: table;
table-layout: fixed;
column-gap: 40px;
}
/* weather table header row */
.weatherHeaderRow {
display: table-header-group;
white-space: nowrap;
}
/* weather table data row */
.weatherDataRow {
display: table-row-group;
}
/* weather table data cells */
#weatherFontBold {
font-weight: bold;
}
.weatherWeekday {
display: table-cell;
min-width: 80px;
text-align: center;
vertical-align: middle;
}
.weatherCondition {
display: table-cell;
position: relative;
top: -4px;
text-align: center;
vertical-align: middle;
font-size: 80%;
word-wrap: break-word;
}
.weatherTemperature {
display: table-cell;
text-align: center;
vertical-align: middle;
font-size: 100%;
white-space: nowrap;
}
.weatherWind {
display: table-cell;
text-align: center;
vertical-align: middle;
font-size: 80%;
padding-top: 3px;
}
/* weather table condition icon cell */
.weatherIcon {
display: table-cell;
position: relative;
text-align: center;
}
/* weather icon */
.weatherIcon img {
width: 100%;
height: auto;
position: relative;
}
/* embedded alert icon with pointer support */
.weatherAlertIcon {
position: absolute;
top: 5px;
right: 5px;
width: 25px;
height: 22px;
background-size: 25px 22px;
background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACgAAAAkCAMAAADM4ogkAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAyppVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2LjE0NjcyOSwgMjAxMi8wNS8wMy0xMzo0MDowMyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIEVsZW1lbnRzIDEyLjAgV2luZG93cyIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDo1RjU1NzJBRDMyRTcxMUU1QTk4MkI0RTkwODEwODQ1QSIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDo1RjU1NzJBRTMyRTcxMUU1QTk4MkI0RTkwODEwODQ1QSI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5jZUlEPSJ4bXAuaWlkOjVGNTU3MkFCMzJFNzExRTVBOTgyQjRFOTA4MTA4NDVBIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOjVGNTU3MkFDMzJFNzExRTVBOTgyQjRFOTA4MTA4NDVBIi8+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8P3hwYWNrZXQgZW5kPSJyIj8+oFydjAAAAwBQTFRF9fX267W51Csy9d7c1VBV9uPc/vz89+nl5YB/2Flk2mZp1Cgv0Csw5pWR7K2t1Soy1Cow7b6y0iUr+/r61jI54X+A+uvq21xV44qO/fj400tU1kxG3nNx2mJp34Bz/Pj2a2tr4Ht91S43fn5+1jA31S0y0iYu1TA1/ff3+/TxEhIS3W1u1jA010Q++efj1kVH1Tk+gYGB6qWh4oWEtra21TI48sjH1VVc1tbW1jY22ltd4YF/1kFHl5eX/vz7/Pz84nZt+evt9+Tm2mNu1Sw14YSD1Ss04YKC0isv4X5/0zc21CUu8cnL0jA20jAz22xy1jE422Zv1i800isw1Cgx11xjKysr1FFZ4X190iQsGRkZ0jY+1TE41Cww0y0y0ykt1i431i4z0y800ikvPz4/AAAA////DQwM1TI30yYs1TE31TA21TE21S401S801S810ycs//7+1TA3///+/v791TI2/v//0Sov0iYt0yYt6urqkZGR1TM40ycu1S414ODg4YB3+/Hw7bK0/vv78fHxh4eH+OPf0i8w1DI30icu1y843Zia/PX13Nvb6aWZ4YKE+fDv21RT00E83G5y3m9x7tDF3Gdu99fW1EJK1ktK3t7e5I+R4oeH3WNp3oCF+vH16ZOJ1Sw27cG31i018dDL4qOf3Wde7Kqe+O7m2ERH+e3o+u/t4YuY/Pb15IqG5p2R4np52TA82mhx2V1p3mpx5oWL66uiRkZG4YOR/v7+1ygz1TxC8dDV9dHS2VJL1CUw8by79+Hg7bq3vr6+9dnR1Tc49d/X11le77yv22hl2lVY+Ofo33540icspqan+/f49N/h5J6m2HB7zczN3nZ88c3FsrKz3HZ74ICC4YGA1oJy10JD+Onj8c3J1Dk71T494oaE4HpxNTU14XRz7Ozs7+/vcG9v+/bz/Pj1/fr3IiIi676/5IJx4Hpr6amn56On6aGd2mlu4X2A22Vm2WFk1jI33GNk+/Ds2VJU2FZW8/Pz78jD3V1v55iY3W1x////C1yJRAAAAQB0Uk5T////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////AFP3ByUAAAMKSURBVHjajNEFWBNxGAbwOXEoUzYnqCgGuPMUUFE8sRuwgDlUEJmK8z6/XWyEEjrswu7u7u7u7u4u7G7FWxoj/J6L9/7v77nnQpTpMM7XFkocV0UOK2VKbkt3/R+4KY0Zlnw8d7ikBeu9VroRcoXPg5F1Y5Mn5wYPaRnGqOxMfPbIGXZfFMxxJGtg0lxzhoWlKpYfSrCd9f4rc4JPKs1l9B1aeabGoLRQTnBxG8T2K2DwLV7FRVTOHi47yKKmxGyAagoGxb7x2cLSMuS0eZIAMopJUaWtkR3M1yUBpe8lkuoj4WYYm8Bf98gaxjdsSik7toKydPQ0OKEzUnGuWcOLWgZPXoCe3Wi6HlS+zVMG/35Zwfq7eqO+wxk4T9N0OYDXKQylnZ4VnKdxM5bfAtDTh6arAlT4IldxXYo6woyS3hwxpRHA12ia7gUA3yKUKL8f7wCPiClMOSsA0VPTMwIkeeoQm+39F1asZECZ02kBFGlH06eEM+Rt0RvFHyX/wNUy7JGex9Q3EGB1U4BCLVXK9D1/wxu1lJS8lMTc36Pp/eZQcaoM9Us9/oSJL8QUGbrDXMNmOvqBJe3TxqC22p/wgIbBlrMsLZSju1pT93dSZDsW/Q3rF/NG3r+xte4zqKY1QY0IBuVvwQ4LazFGUTzRVhexJziahkzyTht8PM6AwXUbWbutj3za2W+5IIxEovYAKxwlww+KV7buYTfzL7TODOGry/tb4KdaCSg/VsFWDfSx/ELLLK9CILl9hBnOEaOq4DN7BZe6lv36++plJ3ST/zDBfEOEN6udBNnNWDHFhTpnihIbNkXKUNfLyyuqeciVOwFvr7oHrApqHhTiPjog6EqdNVFVDIji/JmiiYQbopFM3R0XF6fT6VJ15jFFnUJhSqQRETV5RXfnGykhMea9B2M624ezBaOmuKiv1GDg9TxJ8sIxltB7E0QsT/BqpdrPT9g4P7VaTcZKL4vGDP/psq71BpdSLj9nTmod3mTC+HDfN+FN2jodjlwfGRnoFNg2cH2B7+ca/xJgAFL1l3PxpIx4AAAAAElFTkSuQmCC);
}
.weatherAlertIcon:hover {
opacity: 0.7;
}
.weatherAlertIcon:focus {
opacity: 1.0;
}
/* opaque white background for alerts dialog */
.weatherOverlay {
display: none;
position: fixed;
z-index: 1;
opacity: 0.2;
top: 0;
left: 0;
width: 100%;
height: 100%;
background: white;
}
.weatherAlertIcon:focus .weatherOverlay {
display: block;
}
/* alerts dialog box */
[class ^= weatherAlertBox] {
display: none;
position: absolute;
z-index: 2;
opacity: 1;
top: 0;
border: 3px solid white;
border-radius: 3px;
box-shadow: 0px 0px 6px 4px #666;
background: #EEE;
}
.weatherAlertIcon:focus .weatherAlertBoxLeft {
display: block;
right: -268px;
}
.weatherAlertIcon:focus .weatherAlertBoxCenter {
display: block;
left: -178px;
}
.weatherAlertIcon:focus .weatherAlertBoxRight {
display: block;
left: -312px;
}
/* alerts dialog close button */
.weatherAlertsClose {
position: absolute;
top: -12px;
right: -13px;

border-radius: 12px;
box-shadow: 1px 1px 3px #666;

line-height: 21px;
width: 21px;
background: #606061;

text-align: center;
text-decoration: none;
font-family: Sans-serif;
font-weight: bold;
color: white;
}
.weatherAlertsClose:hover {
opacity: 0.8;
}
/* alerts dialog title */
.weaterAlertsTitle {
font-weight: bold;
color: black;
}
/* alert messages */
[class ^= weaterAlertMessage] {
float: left;
text-align: left;
white-space: nowrap;
}
.weaterAlertMessage p {
white-space: normal;
}
</syntaxhighlight>

Calendar

2024-06-23T06:26:42Z

F Klee: Kapitel "Events" aus commandref in Wiki übernommen.

{{Infobox Modul
|ModPurpose=Anlegen eines Kalenderobjekts
|ModType=h
|ModForumArea=Unterstützende Dienste/Kalendermodule
|ModTechName=57_Calendar.pm
|ModOwner=borisneubert ({{Link2FU|10|Dr. Boris Neubert}})
}}

[[Calendar]] ist ein Hilfsmodul, das Kalenderereignisse aus einer Datei oder einem über die URL angegeben Kalender holt. Der Kalender muss im iCal-Format vorliegen.

Zur Anzeige der Kalenderereignisse kann das Modul [[CALVIEW]] verwendet werden.

== Voraussetzungen ==
Wenn die Kalender-URL mit ''https://'' beginnt, muss das Perl Modul IO::Socket::SSL installiert sein (z.B. mit <code>cpan -i IO::Socket::SSL</code> oder mit <code>apt-get install libio-socket-ssl-perl</code>).

== Anwendung ==
=== Define ===
Siehe {{Link2CmdRef|Anker=Calendardefine}};
:<code>define <name> Calendar ical url <URL> [<interval>]</code>
:<code>define <name> Calendar ical file <FILENAME> [<interval>]</code>

Sofern für den Zugriff auf den Kalender Benutzername und Passwort erforderlich sind, können diese in der URL beispielsweise so mit angegeben werden:
:<code>define myCalendar Calendar ical url <nowiki>https://user:password@my.domain.com/.../yourcalendar.ics</nowiki></code>

=== Attribute ===
Siehe {{Link2CmdRef|Anker=Calendarattr}};

=== Events ===
Wenn der Kalendar neu geladen oder aktualisiert oder eine Alarm-, Start- oder Endzeit erreicht wurde, wird ein FHEM-Event erzeugt:

<code>triggered</code>

Man kann sich darauf verlassen, dass alle Readings des Kalenders in einem konsistenten und aktuellen Zustand befinden, wenn dieses Event empfangen wird.

Wenn ein Termin geändert wurde, werden zwei FHEM-Events erzeugt:

<code>changed: UID <mode></code>

<code><mode>: UID</code>

<mode> ist der aktuelle Modus des Termins nach der Änderung. Bitte beachten: Im FHEM-Event befindet sich ein Doppelpunkt gefolgt von einem Leerzeichen.

FHEM-Events sollten nur auf den vorgenannten Events basieren und nicht auf FHEM-Events, die durch ändern eines mode... Readings ausgelöst werden.

== Anwendungsbeispiel(e) ==
* Einbindung von owncloud-Kalendern
Für ownCloud-Kalender muss bei der Definition als <URL> der Link zum Export des jeweiligen Kalenders angegeben werden. Der Link kann in der Weboberfläche von ownCloud gefunden werden. Für ownCloud 9.0 folgt dieser URL z.B. dem folgenden Muster:
:<code>http://<ownCloud-Benutzer>:<ownCloud-Passwort>@example.com/owncloud/remote.php/dav/calendars/<ownCloud-Benutzer>/<Kalendername>?export</code>
Der Standard für <Kalendername> ist <code>defaultcalendar</code>
* [[Google-Kalender zur Steuerung von Dummies]]
* [[Wochenende, Feiertage und Schulferien]]
* Limitierungen im Sinne der Datenarmut nutzen
Die Attribute <code>hideOlderThan <timespec></code> und <code>hideLaterThan <timespec></code> bewirken, dass nur Kalendereinträge des definierten Zeitraums angezeigt werden. Gerade bei langjährig genutzen Kalendern kann die Datenmenge ansonsten extrem groß werden und schlägt sich in entsprechend langen Update-Runs nieder.

== Links ==
* Modul, das alle Termine aus einer bestehenden Instanz von [[Calendar]] in Readings übernimmt: [[CALVIEW]]

AT kleine Helferlein

2024-04-26T16:33:52Z

F Klee: /* AT alle x Wochen ausführen */

Ein AT kann statt einer Uhrzeit bzw. eines Datums mit einer Uhrzeit auch eine Perl-Funktion nutzen. Beispiel solcher Funktionen sind [[At#at ultimo|at_ultimo]] oder das Modul [[SUNRISE_EL]]. Hier sollen weitere Funktionen vorgestellt werden.

Der Code kann in der [[99 myUtils anlegen|99 myUtils]] untergebracht werden.

== AT am x-ten Wochentag im Monat ausführen ==

Aufgabe ist es, das at z.B. an jedem 2. Montag im Monat auszuführen. Zusätzlich gibt es auch die Möglichkeit, das at immer am z.B. letzten Montag im Monat auszuführen.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# x.ten Wochentags im Monat
#
# x=1-4 x.ter Wochentag im Monat
# x=9 letzter Wochentag im Monat
# w=1-7 Wochentag, 1=Montag
# h,m,s Uhrzeit Stunde, Minute, Sekunde
#
sub at_xwday($$$$$) {
my ($x,$w,$h,$m,$s) = @_;

my $ziel_tag = 0;

# akt. Datum und Uhrzeit in Variablen aufteilen
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);

# bei Neuberechnung einen Monat addieren
my $add = $data{AT_RECOMPUTE} ? 1 : 0;
$mon = $mon + $add;

my ($nm, $ny) = ($mon == 12) ? (0,$year+1) : ($mon,$year);

# Letztes Vorkommen des Wochentags berechnen?
if ($x == 9) {
# Berechnen des letzten Tags des Monats
# ersten Tag des Folgemonats als timestamp
my ($xm, $xy) = ($mon == 11) ? (0,$year+1) : ($mon+1,$year);
my $nt = mktime(0, 0, 0, 1, $xm, $xy);

# letzter Tag des aktuellen Monats = erster Tag des Folgemonats minus ein Tag
my ($letzter_tag_des_monats, $letzter_wochentag) = (localtime($nt - DAYSECONDS))[3,6];

# Prüfen, ob der letzte Wochentag im Monat mit dem gewünschten Wochentag übereinstimmt
$ziel_tag = $letzter_tag_des_monats;
if ($letzter_wochentag > $w) {
# Falls der letzte Wochentag später im Monat ist, subtrahiere die Differenz
my $differenz = $letzter_wochentag - $w;
$ziel_tag -= $differenz;
} elsif ($letzter_wochentag < $w) {
# Falls der letzte Wochentag früher im Monat ist, subtrahiere 7 plus die Differenz
my $differenz = $w - $letzter_wochentag;
$ziel_tag -= (7 - $differenz);
}
} else {
# Berechne den Tag des ersten Vorkommens des Wochentags im Monat
my $erster_tag = 1;
my $erster_tag_des_monats = (localtime(mktime(0,0,0,$erster_tag,$nm,$ny)))[6];
my $erstes_vorkommen = ($w - $erster_tag_des_monats + 7) % 7 + 1;

# Berechne den Tag des x.ten Vorkommens des Wochentags im Monat
$ziel_tag = $erstes_vorkommen + 7 * ($x - 1);

# Überprüfe, ob das Datum im gültigen Bereich liegt
if ($ziel_tag > 31 || $ziel_tag < 1) {
return "Ungültiges Datum";
}
}
return mktime($s,$m,$h,$ziel_tag,$nm,$ny);
}

</syntaxhighlight>Als Parameter benötigt die Funktion, welches Vorkommen des Wochentags berechnet werden soll (1-4). Soll das letzte Vorkommen berechnet werden, übergibt man 9. Als Wochentag wird 1-7 angegeben, wobei Montag der Wochentag 1 ist. Danach kommen als getrennte Parameter Stunde, Minute und Sekunde. Die Definition sieht dann so aus<syntaxhighlight lang="perl">
defmod at_heat1_Treffen_FG_Radverkehr at *{at_xwday(1,2,17,45,0)} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_FG_Radverkehr at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>Die Heizung wird für das Treffen der Fachgruppe Radverkehr am ersten Dienstag im Monat auf 21 Grad gestellt. Gleichzeitig wird ein AT gestartet, das die Heizung zwei Stunden später wieder auf 15 Grad reduziert. Kleiner Tipp: Man kann im AT auch zwei FHEM-Befehle hintereinander senden. Klappte in diesem Fall aber nur über den kleinen Umweg über Perl.

== AT alle x Tage ausführen ==

Soll ein Termin z.B. alle sechs Wochen stattfinden, so kann folgende Funktion genutzt werden.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# nächsten Treffens in x Tagen

sub at_xdays($$) {
my ($tm,$days) = @_;
my $delta = $days * DAYSECONDS; # Nächster Termin in sec

return "Wrong timespec, use \"yyyy-mm-ddThh:mm:ss\"" if($tm !~ m/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/);
my ($y,$m,$d,$h,$m2,$s) = ($1,$2,$3,$4,$5,$6);
my $abstime = mktime($s,$m2,$h,$d,$m-1,$y-1900, 0,0,-1);
my $now = int(time);

my $diff = $now-$abstime;
if ($diff>0){
# bei Neuberechnung sechs Wochen zur aktuellen Zeit addieren
# wird auch bei Erstberechnung aufgerufen, wenn Timestamp in der Vergangenheit
my $temp = ((int($diff/$delta)+1)*$delta)+$abstime;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($temp);
return mktime($s,$m2,$h,$mday,$mon,$year);
} else {return $abstime;}
}

</syntaxhighlight>Dabei wird der erste Ausführungstermin im FHEM-üblichen Format ("yyyy-mm-ddThh:mm:ss") und das Intervall in Tagen übergeben. Die Variable $delta enthält dann das Intervall in Sekunden. Es wird zwar mit dem Timestamp gerechnet. Zurückgegeben wird aber das berechnete Datum und die der Funktion übergebene Uhrzeit. Das verhindert Probleme mit der Zeitumstellung. Hier die Definition für einen Termin alle sechs Wochen, beginnend am 29.05.2024 um 18:45 Uhr. Auch hier wird die Heizung zwei Stunden später wieder herunter gestellt.<syntaxhighlight lang="perl">
defmod at_heat2_Lasse at *{at_xdays("2024-05-29T18:45:00",42)} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_Lasse at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>
[[Kategorie:Code Snippets]]

AT kleine Helferlein

2024-04-26T15:31:57Z

F Klee: /* AT alle x Wochen ausführen */

Ein AT kann statt einer Uhrzeit bzw. eines Datums mit einer Uhrzeit auch eine Perl-Funktion nutzen. Beispiel solcher Funktionen sind [[At#at ultimo|at_ultimo]] oder das Modul [[SUNRISE_EL]]. Hier sollen weitere Funktionen vorgestellt werden.

Der Code kann in der [[99 myUtils anlegen|99 myUtils]] untergebracht werden.

== AT am x-ten Wochentag im Monat ausführen ==

Aufgabe ist es, das at z.B. an jedem 2. Montag im Monat auszuführen. Zusätzlich gibt es auch die Möglichkeit, das at immer am z.B. letzten Montag im Monat auszuführen.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# x.ten Wochentags im Monat
#
# x=1-4 x.ter Wochentag im Monat
# x=9 letzter Wochentag im Monat
# w=1-7 Wochentag, 1=Montag
# h,m,s Uhrzeit Stunde, Minute, Sekunde
#
sub at_xwday($$$$$) {
my ($x,$w,$h,$m,$s) = @_;

my $ziel_tag = 0;

# akt. Datum und Uhrzeit in Variablen aufteilen
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);

# bei Neuberechnung einen Monat addieren
my $add = $data{AT_RECOMPUTE} ? 1 : 0;
$mon = $mon + $add;

my ($nm, $ny) = ($mon == 12) ? (0,$year+1) : ($mon,$year);

# Letztes Vorkommen des Wochentags berechnen?
if ($x == 9) {
# Berechnen des letzten Tags des Monats
# ersten Tag des Folgemonats als timestamp
my ($xm, $xy) = ($mon == 11) ? (0,$year+1) : ($mon+1,$year);
my $nt = mktime(0, 0, 0, 1, $xm, $xy);

# letzter Tag des aktuellen Monats = erster Tag des Folgemonats minus ein Tag
my ($letzter_tag_des_monats, $letzter_wochentag) = (localtime($nt - DAYSECONDS))[3,6];

# Prüfen, ob der letzte Wochentag im Monat mit dem gewünschten Wochentag übereinstimmt
$ziel_tag = $letzter_tag_des_monats;
if ($letzter_wochentag > $w) {
# Falls der letzte Wochentag später im Monat ist, subtrahiere die Differenz
my $differenz = $letzter_wochentag - $w;
$ziel_tag -= $differenz;
} elsif ($letzter_wochentag < $w) {
# Falls der letzte Wochentag früher im Monat ist, subtrahiere 7 plus die Differenz
my $differenz = $w - $letzter_wochentag;
$ziel_tag -= (7 - $differenz);
}
} else {
# Berechne den Tag des ersten Vorkommens des Wochentags im Monat
my $erster_tag = 1;
my $erster_tag_des_monats = (localtime(mktime(0,0,0,$erster_tag,$nm,$ny)))[6];
my $erstes_vorkommen = ($w - $erster_tag_des_monats + 7) % 7 + 1;

# Berechne den Tag des x.ten Vorkommens des Wochentags im Monat
$ziel_tag = $erstes_vorkommen + 7 * ($x - 1);

# Überprüfe, ob das Datum im gültigen Bereich liegt
if ($ziel_tag > 31 || $ziel_tag < 1) {
return "Ungültiges Datum";
}
}
return mktime($s,$m,$h,$ziel_tag,$nm,$ny);
}

</syntaxhighlight>Als Parameter benötigt die Funktion, welches Vorkommen des Wochentags berechnet werden soll (1-4). Soll das letzte Vorkommen berechnet werden, übergibt man 9. Als Wochentag wird 1-7 angegeben, wobei Montag der Wochentag 1 ist. Danach kommen als getrennte Parameter Stunde, Minute und Sekunde. Die Definition sieht dann so aus<syntaxhighlight lang="perl">
defmod at_heat1_Treffen_FG_Radverkehr at *{at_xwday(1,2,17,45,0)} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_FG_Radverkehr at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>Die Heizung wird für das Treffen der Fachgruppe Radverkehr am ersten Dienstag im Monat auf 21 Grad gestellt. Gleichzeitig wird ein AT gestartet, das die Heizung zwei Stunden später wieder auf 15 Grad reduziert. Kleiner Tipp: Man kann im AT auch zwei FHEM-Befehle hintereinander senden. Klappte in diesem Fall aber nur über den kleinen Umweg über Perl.

== AT alle x Wochen ausführen ==

Soll ein Termin z.B. alle sechs Wochen stattfinden, so kann folgende Funktion genutzt werden.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# nächsten Treffens in sechs Wochen

sub at_sixweek($) {
my ($tm) = @_;
my $delta = 42 * DAYSECONDS; # Nächster Termin in sec, hier sechs Wochen

return "Wrong timespec, use \"yyyy-mm-ddThh:mm:ss\"" if($tm !~ m/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/);
my ($y,$m,$d,$h,$m2,$s) = ($1,$2,$3,$4,$5,$6);
my $abstime = mktime($s,$m2,$h,$d,$m-1,$y-1900, 0,0,-1);
my $now = int(time);

my $diff = $now-$abstime;
if ($diff>0){
# bei Neuberechnung sechs Wochen zur aktuellen Zeit addieren
# wird auch bei Erstberechnung aufgerufen, wenn Timestamp in der Vergangenheit
my $temp = ((int($diff/$delta)+1)*$delta)+$abstime;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($temp);
return mktime($s,$m2,$h,$mday,$mon,$year);
} else {return $abstime;}
}

</syntaxhighlight>Dabei wird der erste Ausführungstermin im FHEM-üblichen Format ("yyyy-mm-ddThh:mm:ss") übergeben. Die Variable $delta enthält das Intervall in Sekunden. Es kann entsprechend angepasst werden. Es wird zwar mit dem Timestamp gerechnet. Zurückgegeben wird aber das berechnete Datum und die der Funktion übergebene Uhrzeit. Das verhindert Probleme mit der Zeitumstellung. Hier die Definition für einen Termin alle sechs Wochen, beginnend am 29.05.2024 um 18:45 Uhr. Auch hier wird die Heizung zwei Stunden später wieder herunter gestellt.<syntaxhighlight lang="perl">
defmod at_heat2_Lasse at *{at_sixweek("2024-05-29T18:45:00")} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_Lasse at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>
[[Kategorie:Code Snippets]]

AT kleine Helferlein

2024-04-26T15:23:15Z

F Klee: Fehler in Funktion at_sixweek() behoben

Ein AT kann statt einer Uhrzeit bzw. eines Datums mit einer Uhrzeit auch eine Perl-Funktion nutzen. Beispiel solcher Funktionen sind [[At#at ultimo|at_ultimo]] oder das Modul [[SUNRISE_EL]]. Hier sollen weitere Funktionen vorgestellt werden.

Der Code kann in der [[99 myUtils anlegen|99 myUtils]] untergebracht werden.

== AT am x-ten Wochentag im Monat ausführen ==

Aufgabe ist es, das at z.B. an jedem 2. Montag im Monat auszuführen. Zusätzlich gibt es auch die Möglichkeit, das at immer am z.B. letzten Montag im Monat auszuführen.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# x.ten Wochentags im Monat
#
# x=1-4 x.ter Wochentag im Monat
# x=9 letzter Wochentag im Monat
# w=1-7 Wochentag, 1=Montag
# h,m,s Uhrzeit Stunde, Minute, Sekunde
#
sub at_xwday($$$$$) {
my ($x,$w,$h,$m,$s) = @_;

my $ziel_tag = 0;

# akt. Datum und Uhrzeit in Variablen aufteilen
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);

# bei Neuberechnung einen Monat addieren
my $add = $data{AT_RECOMPUTE} ? 1 : 0;
$mon = $mon + $add;

my ($nm, $ny) = ($mon == 12) ? (0,$year+1) : ($mon,$year);

# Letztes Vorkommen des Wochentags berechnen?
if ($x == 9) {
# Berechnen des letzten Tags des Monats
# ersten Tag des Folgemonats als timestamp
my ($xm, $xy) = ($mon == 11) ? (0,$year+1) : ($mon+1,$year);
my $nt = mktime(0, 0, 0, 1, $xm, $xy);

# letzter Tag des aktuellen Monats = erster Tag des Folgemonats minus ein Tag
my ($letzter_tag_des_monats, $letzter_wochentag) = (localtime($nt - DAYSECONDS))[3,6];

# Prüfen, ob der letzte Wochentag im Monat mit dem gewünschten Wochentag übereinstimmt
$ziel_tag = $letzter_tag_des_monats;
if ($letzter_wochentag > $w) {
# Falls der letzte Wochentag später im Monat ist, subtrahiere die Differenz
my $differenz = $letzter_wochentag - $w;
$ziel_tag -= $differenz;
} elsif ($letzter_wochentag < $w) {
# Falls der letzte Wochentag früher im Monat ist, subtrahiere 7 plus die Differenz
my $differenz = $w - $letzter_wochentag;
$ziel_tag -= (7 - $differenz);
}
} else {
# Berechne den Tag des ersten Vorkommens des Wochentags im Monat
my $erster_tag = 1;
my $erster_tag_des_monats = (localtime(mktime(0,0,0,$erster_tag,$nm,$ny)))[6];
my $erstes_vorkommen = ($w - $erster_tag_des_monats + 7) % 7 + 1;

# Berechne den Tag des x.ten Vorkommens des Wochentags im Monat
$ziel_tag = $erstes_vorkommen + 7 * ($x - 1);

# Überprüfe, ob das Datum im gültigen Bereich liegt
if ($ziel_tag > 31 || $ziel_tag < 1) {
return "Ungültiges Datum";
}
}
return mktime($s,$m,$h,$ziel_tag,$nm,$ny);
}

</syntaxhighlight>Als Parameter benötigt die Funktion, welches Vorkommen des Wochentags berechnet werden soll (1-4). Soll das letzte Vorkommen berechnet werden, übergibt man 9. Als Wochentag wird 1-7 angegeben, wobei Montag der Wochentag 1 ist. Danach kommen als getrennte Parameter Stunde, Minute und Sekunde. Die Definition sieht dann so aus<syntaxhighlight lang="perl">
defmod at_heat1_Treffen_FG_Radverkehr at *{at_xwday(1,2,17,45,0)} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_FG_Radverkehr at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>Die Heizung wird für das Treffen der Fachgruppe Radverkehr am ersten Dienstag im Monat auf 21 Grad gestellt. Gleichzeitig wird ein AT gestartet, das die Heizung zwei Stunden später wieder auf 15 Grad reduziert. Kleiner Tipp: Man kann im AT auch zwei FHEM-Befehle hintereinander senden. Klappte in diesem Fall aber nur über den kleinen Umweg über Perl.

== AT alle x Wochen ausführen ==

Soll ein Termin z.B. alle sechs Wochen stattfinden, so kann folgende Funktion genutzt werden.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# nächsten Treffens in sechs Wochen

sub at_sixweek($) {
my ($tm) = @_;
my $delta = 3628800; # Nächster Termin in sec, hier sechs Wochen

return "Wrong timespec, use \"yyyy-mm-ddThh:mm:ss\"" if($tm !~ m/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/);
my ($y,$m,$d,$h,$m2,$s) = ($1,$2,$3,$4,$5,$6);
my $abstime = mktime($s,$m2,$h,$d,$m-1,$y-1900, 0,0,-1);
my $now = int(time);

my $diff = $now-$abstime;
if ($diff>0){
# bei Neuberechnung sechs Wochen zur aktuellen Zeit addieren
# wird auch bei Erstberechnung aufgerufen, wenn Timestamp in der Vergangenheit
my $temp = ((int($diff/$delta)+1)*$delta)+$abstime;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($temp);
return mktime($s,$m2,$h,$mday,$mon,$year);
} else {return $abstime;}
}

</syntaxhighlight>Dabei wird der erste Ausführungstermin im FHEM-üblichen Format ("yyyy-mm-ddThh:mm:ss") übergeben. Die Variable $delta enthält das Intervall in Sekunden. Es kann entsprechend angepasst werden. Es wird zwar mit dem Timestamp gerechnet. Zurückgegeben wird aber das berechnete Datum und die der Funktion übergebene Uhrzeit. Das verhindert Probleme mit der Zeitumstellung. Hier die Definition für einen Termin alle sechs Wochen, beginnend am 29.05.2024 um 18:45 Uhr. Auch hier wird die Heizung zwei Stunden später wieder herunter gestellt.<syntaxhighlight lang="perl">
defmod at_heat2_Lasse at *{at_sixweek("2024-05-29T18:45:00")} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_Lasse at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>
[[Kategorie:Code Snippets]]

AT kleine Helferlein

2024-04-22T17:14:52Z

F Klee:

Ein AT kann statt einer Uhrzeit bzw. eines Datums mit einer Uhrzeit auch eine Perl-Funktion nutzen. Beispiel solcher Funktionen sind [[At#at ultimo|at_ultimo]] oder das Modul [[SUNRISE_EL]]. Hier sollen weitere Funktionen vorgestellt werden.

Der Code kann in der [[99 myUtils anlegen|99 myUtils]] untergebracht werden.

== AT am x-ten Wochentag im Monat ausführen ==

Aufgabe ist es, das at z.B. an jedem 2. Montag im Monat auszuführen. Zusätzlich gibt es auch die Möglichkeit, das at immer am z.B. letzten Montag im Monat auszuführen.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# x.ten Wochentags im Monat
#
# x=1-4 x.ter Wochentag im Monat
# x=9 letzter Wochentag im Monat
# w=1-7 Wochentag, 1=Montag
# h,m,s Uhrzeit Stunde, Minute, Sekunde
#
sub at_xwday($$$$$) {
my ($x,$w,$h,$m,$s) = @_;

my $ziel_tag = 0;

# akt. Datum und Uhrzeit in Variablen aufteilen
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);

# bei Neuberechnung einen Monat addieren
my $add = $data{AT_RECOMPUTE} ? 1 : 0;
$mon = $mon + $add;

my ($nm, $ny) = ($mon == 12) ? (0,$year+1) : ($mon,$year);

# Letztes Vorkommen des Wochentags berechnen?
if ($x == 9) {
# Berechnen des letzten Tags des Monats
# ersten Tag des Folgemonats als timestamp
my ($xm, $xy) = ($mon == 11) ? (0,$year+1) : ($mon+1,$year);
my $nt = mktime(0, 0, 0, 1, $xm, $xy);

# letzter Tag des aktuellen Monats = erster Tag des Folgemonats minus ein Tag
my ($letzter_tag_des_monats, $letzter_wochentag) = (localtime($nt - DAYSECONDS))[3,6];

# Prüfen, ob der letzte Wochentag im Monat mit dem gewünschten Wochentag übereinstimmt
$ziel_tag = $letzter_tag_des_monats;
if ($letzter_wochentag > $w) {
# Falls der letzte Wochentag später im Monat ist, subtrahiere die Differenz
my $differenz = $letzter_wochentag - $w;
$ziel_tag -= $differenz;
} elsif ($letzter_wochentag < $w) {
# Falls der letzte Wochentag früher im Monat ist, subtrahiere 7 plus die Differenz
my $differenz = $w - $letzter_wochentag;
$ziel_tag -= (7 - $differenz);
}
} else {
# Berechne den Tag des ersten Vorkommens des Wochentags im Monat
my $erster_tag = 1;
my $erster_tag_des_monats = (localtime(mktime(0,0,0,$erster_tag,$nm,$ny)))[6];
my $erstes_vorkommen = ($w - $erster_tag_des_monats + 7) % 7 + 1;

# Berechne den Tag des x.ten Vorkommens des Wochentags im Monat
$ziel_tag = $erstes_vorkommen + 7 * ($x - 1);

# Überprüfe, ob das Datum im gültigen Bereich liegt
if ($ziel_tag > 31 || $ziel_tag < 1) {
return "Ungültiges Datum";
}
}
return mktime($s,$m,$h,$ziel_tag,$nm,$ny);
}

</syntaxhighlight>Als Parameter benötigt die Funktion, welches Vorkommen des Wochentags berechnet werden soll (1-4). Soll das letzte Vorkommen berechnet werden, übergibt man 9. Als Wochentag wird 1-7 angegeben, wobei Montag der Wochentag 1 ist. Danach kommen als getrennte Parameter Stunde, Minute und Sekunde. Die Definition sieht dann so aus<syntaxhighlight lang="perl">
defmod at_heat1_Treffen_FG_Radverkehr at *{at_xwday(1,2,17,45,0)} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_FG_Radverkehr at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>Die Heizung wird für das Treffen der Fachgruppe Radverkehr am ersten Dienstag im Monat auf 21 Grad gestellt. Gleichzeitig wird ein AT gestartet, das die Heizung zwei Stunden später wieder auf 15 Grad reduziert. Kleiner Tipp: Man kann im AT auch zwei FHEM-Befehle hintereinander senden. Klappte in diesem Fall aber nur über den kleinen Umweg über Perl.

== AT alle x Wochen ausführen ==

Soll ein Termin z.B. alle sechs Wochen stattfinden, so kann folgende Funktion genutzt werden.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# nächsten Treffens in sechs Wochen

sub at_sixweek($) {
my ($tm) = @_;
my $delta = 3628800; # Zeit zwischen den Terminen in Sekunden, hier 6 Wochen

return "Wrong timespec, use \"yyyy-mm-ddThh:mm:ss\"" if($tm !~ m/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/);
my ($y,$m,$d,$h,$m2,$s) = ($1,$2,$3,$4,$5,$6);
my $abstime = mktime($s,$m2,$h,$d,$m-1,$y-1900, 0,0,-1);

if ($data{AT_RECOMPUTE}){
# bei Neuberechnung sechs Wochen zur aktuellen Zeit addieren
my $now = int(time);
$abstime = $now+$delta;
}

return $abstime;
}

</syntaxhighlight>Dabei wird der erste Ausführungstermin im FHEM-üblichen Format ("yyyy-mm-ddThh:mm:ss") übergeben. Die Variable $delta enthält das Intervall in Sekunden. Es kann entsprechend angepasst werden. Die Neuberechnung erfolgt ausgehend vom aktuellen Datum/Uhrzeit. Es kann also als erster Termin nur ein Termin in der Zukunft angegeben werden. Hier die Definition für einen Termin alle sechs Wochen, beginnend am 29.05.2024 um 18:45 Uhr. Auch hier wird die Heizung zwei Stunden später wieder herunter gestellt.<syntaxhighlight lang="perl">
defmod at_heat2_Lasse at *{at_sixweek("2024-05-29T18:45:00")} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_Lasse at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>
[[Kategorie:Code Snippets]]

AT kleine Helferlein

2024-04-22T17:00:53Z

F Klee:

Ein AT kann statt einer Uhrzeit bzw. eines Datums mit einer Uhrzeit auch eine Perl-Funktion nutzen. Beispiel solcher Funktionen sind [[At#at ultimo|at_ultimo]] oder das Modul [[SUNRISE_EL]]. Hier sollen weitere Funktionen vorgestellt werden.

Der Code kann in der [[99 myUtils anlegen|99 myUtils]] untergebracht werden.

== AT am x-ten Wochentag im Monat ausführen ==

Aufgabe ist es, das at z.B. an jedem 2. Montag im Monat auszuführen. Zusätzlich gibt es auch die Möglichkeit, das at immer am z.B. letzten Montag im Monat auszuführen.<syntaxhighlight lang="perl6">
########################################
#
# Berechnung des Datums des
# x.ten Wochentags im Monat
#
# x=1-4 x.ter Wochentag im Monat
# x=9 letzter Wochentag im Monat
# w=1-7 Wochentag, 1=Montag
# h,m,s Uhrzeit Stunde, Minute, Sekunde
#
sub at_xwday($$$$$) {
my ($x,$w,$h,$m,$s) = @_;

my $ziel_tag = 0;

# akt. Datum und Uhrzeit in Variablen aufteilen
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);

# bei Neuberechnung einen Monat addieren
my $add = $data{AT_RECOMPUTE} ? 1 : 0;
$mon = $mon + $add;

my ($nm, $ny) = ($mon == 12) ? (0,$year+1) : ($mon,$year);

# Letztes Vorkommen des Wochentags berechnen?
if ($x == 9) {
# Berechnen des letzten Tags des Monats
# ersten Tag des Folgemonats als timestamp
my ($xm, $xy) = ($mon == 11) ? (0,$year+1) : ($mon+1,$year);
my $nt = mktime(0, 0, 0, 1, $xm, $xy);

# letzter Tag des aktuellen Monats = erster Tag des Folgemonats minus ein Tag
my ($letzter_tag_des_monats, $letzter_wochentag) = (localtime($nt - DAYSECONDS))[3,6];

# Prüfen, ob der letzte Wochentag im Monat mit dem gewünschten Wochentag übereinstimmt
$ziel_tag = $letzter_tag_des_monats;
if ($letzter_wochentag > $w) {
# Falls der letzte Wochentag später im Monat ist, subtrahiere die Differenz
my $differenz = $letzter_wochentag - $w;
$ziel_tag -= $differenz;
} elsif ($letzter_wochentag < $w) {
# Falls der letzte Wochentag früher im Monat ist, subtrahiere 7 plus die Differenz
my $differenz = $w - $letzter_wochentag;
$ziel_tag -= (7 - $differenz);
}
} else {
# Berechne den Tag des ersten Vorkommens des Wochentags im Monat
my $erster_tag = 1;
my $erster_tag_des_monats = (localtime(mktime(0,0,0,$erster_tag,$nm,$ny)))[6];
my $erstes_vorkommen = ($w - $erster_tag_des_monats + 7) % 7 + 1;

# Berechne den Tag des x.ten Vorkommens des Wochentags im Monat
$ziel_tag = $erstes_vorkommen + 7 * ($x - 1);

# Überprüfe, ob das Datum im gültigen Bereich liegt
if ($ziel_tag > 31 || $ziel_tag < 1) {
return "Ungültiges Datum";
}
}
return mktime($s,$m,$h,$ziel_tag,$nm,$ny);
}

</syntaxhighlight>Als Parameter benötigt die Funktion, welches Vorkommen des Wochentags berechnet werden soll (1-4). Soll das letzte Vorkommen berechnet werden, übergibt man 9. Als Wochentag wird 1-7 angegeben, wobei Montag der Wochentag 1 ist. Danach kommen als getrennte Parameter Stunde, Minute und Sekunde. Die Definition sieht dann so aus<syntaxhighlight>
defmod at_heat1_Treffen_FG_Radverkehr at *{at_xwday(1,2,17,45,0)} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_FG_Radverkehr at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>Die Heizung wird für das Treffen der Fachgruppe Radverkehr am ersten Dienstag im Monat auf 21 Grad gestellt. Gleichzeitig wird ein AT gestartet, das die Heizung zwei Stunden später wieder auf 15 Grad reduziert. Kleiner Tipp: Man kann im AT auch zwei FHEM-Befehle hintereinander senden. Klappte in diesem Fall aber nur über den kleinen Umweg über Perl.

== AT alle x Wochen ausführen ==

Soll ein Termin z.B. alle sechs Wochen stattfinden, so kann folgende Funktion genutzt werden.<syntaxhighlight lang="perl6">
########################################
#
# Berechnung des Datums des
# nächsten Treffens in sechs Wochen

sub at_sixweek($) {
my ($tm) = @_;
my $delta = 3628800; # Zeit zwischen den Terminen in Sekunden, hier 6 Wochen

return "Wrong timespec, use \"yyyy-mm-ddThh:mm:ss\"" if($tm !~ m/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/);
my ($y,$m,$d,$h,$m2,$s) = ($1,$2,$3,$4,$5,$6);
my $abstime = mktime($s,$m2,$h,$d,$m-1,$y-1900, 0,0,-1);

if ($data{AT_RECOMPUTE}){
# bei Neuberechnung sechs Wochen zur aktuellen Zeit addieren
my $now = int(time);
$abstime = $now+$delta;
}

return $abstime;
}

</syntaxhighlight>Dabei wird der erste Ausführungstermin im FHEM-üblichen Format ("yyyy-mm-ddThh:mm:ss") übergeben. Die Variable $delta enthält das Intervall in Sekunden. Es kann entsprechend angepasst werden. Die Neuberechnung erfolgt ausgehend vom aktuellen Datum/Uhrzeit. Es kann also als erster Termin nur ein Termin in der Zukunft angegeben werden. Hier die Definition für einen Termin alle sechs Wochen, beginnend am 29.05.2024 um 18:45 Uhr. Auch hier wird die Heizung zwei Stunden später wieder herunter gestellt.<syntaxhighlight>
defmod at_heat2_Lasse at *{at_sixweek("2024-05-29T18:45:00")} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_Lasse at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>
[[Kategorie:Code Snippets]]

AT kleine Helferlein

2024-04-22T16:31:13Z

F Klee: Beispieldefinitionen hinzugefügt.

Ein AT kann statt einer Uhrzeit bzw. eines Datums mit einer Uhrzeit auch eine Perl-Funktion nutzen. Beispiel solcher Funktionen sind [[At#at ultimo|at_ultimo]] oder das Modul [[SUNRISE_EL]]. Hier sollen weitere Funktionen vorgestellt werden.

Der Code kann in der [[99 myUtils anlegen|99 myUtils]] untergebracht werden.

== AT am x-ten Wochentag im Monat ausführen ==

Aufgabe ist es, das at z.B. an jedem 2. Montag im Monat auszuführen. Zusätzlich gibt es auch die Möglichkeit, das at immer am z.B. letzten Montag im Monat auszuführen.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# x.ten Wochentags im Monat
#
# x=1-4 x.ter Wochentag im Monat
# x=9 letzter Wochentag im Monat
# w=1-7 Wochentag, 1=Montag
# h,m,s Uhrzeit Stunde, Minute, Sekunde
#
sub at_xwday($$$$$) {
my ($x,$w,$h,$m,$s) = @_;

my $ziel_tag = 0;

# akt. Datum und Uhrzeit in Variablen aufteilen
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);

# bei Neuberechnung einen Monat addieren
my $add = $data{AT_RECOMPUTE} ? 1 : 0;
$mon = $mon + $add;

my ($nm, $ny) = ($mon == 12) ? (0,$year+1) : ($mon,$year);

# Letztes Vorkommen des Wochentags berechnen?
if ($x == 9) {
# Berechnen des letzten Tags des Monats
# ersten Tag des Folgemonats als timestamp
my ($xm, $xy) = ($mon == 11) ? (0,$year+1) : ($mon+1,$year);
my $nt = mktime(0, 0, 0, 1, $xm, $xy);

# letzter Tag des aktuellen Monats = erster Tag des Folgemonats minus ein Tag
my ($letzter_tag_des_monats, $letzter_wochentag) = (localtime($nt - DAYSECONDS))[3,6];

# Prüfen, ob der letzte Wochentag im Monat mit dem gewünschten Wochentag übereinstimmt
$ziel_tag = $letzter_tag_des_monats;
if ($letzter_wochentag > $w) {
# Falls der letzte Wochentag später im Monat ist, subtrahiere die Differenz
my $differenz = $letzter_wochentag - $w;
$ziel_tag -= $differenz;
} elsif ($letzter_wochentag < $w) {
# Falls der letzte Wochentag früher im Monat ist, subtrahiere 7 plus die Differenz
my $differenz = $w - $letzter_wochentag;
$ziel_tag -= (7 - $differenz);
}
} else {
# Berechne den Tag des ersten Vorkommens des Wochentags im Monat
my $erster_tag = 1;
my $erster_tag_des_monats = (localtime(mktime(0,0,0,$erster_tag,$nm,$ny)))[6];
my $erstes_vorkommen = ($w - $erster_tag_des_monats + 7) % 7 + 1;

# Berechne den Tag des x.ten Vorkommens des Wochentags im Monat
$ziel_tag = $erstes_vorkommen + 7 * ($x - 1);

# Überprüfe, ob das Datum im gültigen Bereich liegt
if ($ziel_tag > 31 || $ziel_tag < 1) {
return "Ungültiges Datum";
}
}
return mktime($s,$m,$h,$ziel_tag,$nm,$ny);
}

</syntaxhighlight>Als Parameter benötigt die Funktion, welches Vorkommen des Wochentags berechnet werden soll (1-4). Soll das letzte Vorkommen berechnet werden, übergibt man 9. Als Wochentag wird 1-7 angegeben, wobei Montag der Wochentag 1 ist. Danach kommen als getrennte Parameter Stunde, Minute und Sekunde. Die Definition sieht dann so aus<syntaxhighlight>
defmod at_heat1_Treffen_FG_Radverkehr at *{at_xwday(1,2,17,45,0)} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_FG_Radverkehr at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>Die Heizung wird für das Treffen der Fachgruppe Radverkehr am ersten Dienstag im Monat auf 21 Grad gestellt. Gleichzeitig wird ein AT gestartet, das die Heizung zwei Stunden später wieder auf 15 Grad reduziert. Kleiner Tipp: Man kann im AT auch zwei FHEM-Befehle hintereinander senden. Klappte in diesem Fall aber nur über den kleinen Umweg über Perl.

== AT alle x Wochen ausführen ==

Soll ein Termin z.B. alle sechs Wochen stattfinden, so kann folgende Funktion genutzt werden.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# nächsten Treffens in sechs Wochen

sub at_sixweek($) {
my ($tm) = @_;
my $delta = 3628800; # Zeit zwischen den Terminen in Sekunden, hier 6 Wochen

return "Wrong timespec, use \"yyyy-mm-ddThh:mm:ss\"" if($tm !~ m/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/);
my ($y,$m,$d,$h,$m2,$s) = ($1,$2,$3,$4,$5,$6);
my $abstime = mktime($s,$m2,$h,$d,$m-1,$y-1900, 0,0,-1);

if ($data{AT_RECOMPUTE}){
# bei Neuberechnung sechs Wochen zur aktuellen Zeit addieren
my $now = int(time);
$abstime = $now+$delta;
}

return $abstime;
}

</syntaxhighlight>Dabei wird der erste Ausführungstermin im FHEM-üblichen Format ("yyyy-mm-ddThh:mm:ss") übergeben. Die Variable $delta enthält das Intervall in Sekunden. Es kann entsprechend angepasst werden. Die Neuberechnung erfolgt ausgehend vom aktuellen Datum/Uhrzeit. Es kann also als erster Termin nur ein Termin in der Zukunft angegeben werden. Hier die Definition für einen Termin alle sechs Wochen, beginnend am 29.05.2024 um 18:45 Uhr. Auch hier wird die Heizung zwei Stunden später wieder herunter gestellt.<syntaxhighlight>
defmod at_heat2_Lasse at *{at_sixweek("2024-05-29T18:45:00")} {\
fhem("set TRV_Laden temp 21.0");;\
fhem("defmod at_heat_off_Lasse at +02:00:00 set TRV_Laden temp 15.0");;\
}
</syntaxhighlight>
[[Kategorie:Code Snippets]]

AT kleine Helferlein

2024-04-20T16:24:26Z

F Klee: /* AT am x-ten Wochentag im Monat ausführen */

Ein AT kann statt einer Uhrzeit bzw. eines Datums mit einer Uhrzeit auch eine Perl-Funktion nutzen. Beispiel solcher Funktionen sind [[At#at ultimo|at_ultimo]] oder das Modul [[SUNRISE_EL]]. Hier sollen weitere Funktionen vorgestellt werden.

Der Code kann in der [[99 myUtils anlegen|99 myUtils]] untergebracht werden.

== AT am x-ten Wochentag im Monat ausführen ==

Aufgabe ist es, das at z.B. an jedem 2. Montag im Monat auszuführen. Zusätzlich gibt es auch die Möglichkeit, das at immer am z.B. letzten Montag im Monat auszuführen.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# x.ten Wochentags im Monat
#
# x=1-4 x.ter Wochentag im Monat
# x=9 letzter Wochentag im Monat
# w=1-7 Wochentag, 1=Montag
# h,m,s Uhrzeit Stunde, Minute, Sekunde
#
sub at_xwday($$$$$) {
my ($x,$w,$h,$m,$s) = @_;

my $ziel_tag = 0;

# akt. Datum und Uhrzeit in Variablen aufteilen
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);

# bei Neuberechnung einen Monat addieren
my $add = $data{AT_RECOMPUTE} ? 1 : 0;
$mon = $mon + $add;

my ($nm, $ny) = ($mon == 12) ? (0,$year+1) : ($mon,$year);

# Letztes Vorkommen des Wochentags berechnen?
if ($x == 9) {
# Berechnen des letzten Tags des Monats
# ersten Tag des Folgemonats als timestamp
my ($xm, $xy) = ($mon == 11) ? (0,$year+1) : ($mon+1,$year);
my $nt = mktime(0, 0, 0, 1, $xm, $xy);

# letzter Tag des aktuellen Monats = erster Tag des Folgemonats minus ein Tag
my ($letzter_tag_des_monats, $letzter_wochentag) = (localtime($nt - DAYSECONDS))[3,6];

# Prüfen, ob der letzte Wochentag im Monat mit dem gewünschten Wochentag übereinstimmt
$ziel_tag = $letzter_tag_des_monats;
if ($letzter_wochentag > $w) {
# Falls der letzte Wochentag später im Monat ist, subtrahiere die Differenz
my $differenz = $letzter_wochentag - $w;
$ziel_tag -= $differenz;
} elsif ($letzter_wochentag < $w) {
# Falls der letzte Wochentag früher im Monat ist, subtrahiere 7 plus die Differenz
my $differenz = $w - $letzter_wochentag;
$ziel_tag -= (7 - $differenz);
}
} else {
# Berechne den Tag des ersten Vorkommens des Wochentags im Monat
my $erster_tag = 1;
my $erster_tag_des_monats = (localtime(mktime(0,0,0,$erster_tag,$nm,$ny)))[6];
my $erstes_vorkommen = ($w - $erster_tag_des_monats + 7) % 7 + 1;

# Berechne den Tag des x.ten Vorkommens des Wochentags im Monat
$ziel_tag = $erstes_vorkommen + 7 * ($x - 1);

# Überprüfe, ob das Datum im gültigen Bereich liegt
if ($ziel_tag > 31 || $ziel_tag < 1) {
return "Ungültiges Datum";
}
}
return mktime($s,$m,$h,$ziel_tag,$nm,$ny);
}

</syntaxhighlight>Als Parameter benötigt die Funktion, welches Vorkommen des Wochentags berechnet werden soll (1-4). Soll das letzte Vorkommen berechnet werden, übergibt man 9. Als Wochentag wird 1-7 angegeben, wobei Montag der Wochentag 1 ist. Danach kommen als getrennte Parameter Stunde, Minute und Sekunde.

== AT alle x Wochen ausführen ==

Soll ein Termin z.B. alle sechs Wochen stattfinden, so kann folgende Funktion genutzt werden.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# nächsten Treffens in sechs Wochen

sub at_sixweek($) {
my ($tm) = @_;
my $delta = 3628800; # Zeit zwischen den Terminen in Sekunden, hier 6 Wochen

return "Wrong timespec, use \"yyyy-mm-ddThh:mm:ss\"" if($tm !~ m/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/);
my ($y,$m,$d,$h,$m2,$s) = ($1,$2,$3,$4,$5,$6);
my $abstime = mktime($s,$m2,$h,$d,$m-1,$y-1900, 0,0,-1);

if ($data{AT_RECOMPUTE}){
# bei Neuberechnung sechs Wochen zur aktuellen Zeit addieren
my $now = int(time);
$abstime = $now+$delta;
}

return $abstime;
}

</syntaxhighlight>Dabei wird der erste Ausführungstermin im FHEM-üblichen Format ("yyyy-mm-ddThh:mm:ss") übergeben. Die Variable $delta enthält das Intervall in Sekunden. Es kann entsprechend angepasst werden. Die Neuberechnung erfolgt ausgehend vom aktuellen Datum/Uhrzeit. Es kann also als erster Termin nur ein Termin in der Zukunft angegeben werden.
[[Kategorie:Code Snippets]]

AT kleine Helferlein

2024-04-20T16:20:29Z

F Klee: /* AT am x-ten Wochentag im Monat ausführen */

Ein AT kann statt einer Uhrzeit bzw. eines Datums mit einer Uhrzeit auch eine Perl-Funktion nutzen. Beispiel solcher Funktionen sind [[At#at ultimo|at_ultimo]] oder das Modul [[SUNRISE_EL]]. Hier sollen weitere Funktionen vorgestellt werden.

Der Code kann in der [[99 myUtils anlegen|99 myUtils]] untergebracht werden.

=== AT am x-ten Wochentag im Monat ausführen ===
Aufgabe ist es, das at z.B. an jedem 2. Montag im Monat auszuführen. Zusätzlich gibt es auch die Möglichkeit, das at immer am z.B. letzten Montag im Monat auszuführen.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# x.ten Wochentags im Monat
#
# x=1-4 x.ter Wochentag im Monat
# x=9 letzter Wochentag im Monat
# w=1-7 Wochentag, 1=Montag
# h,m,s Uhrzeit Stunde, Minute, Sekunde
#
sub at_xwday($$$$$) {
my ($x,$w,$h,$m,$s) = @_;

my $ziel_tag = 0;

# akt. Datum und Uhrzeit in Variablen aufteilen
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);

# bei Neuberechnung einen Monat addieren
my $add = $data{AT_RECOMPUTE} ? 1 : 0;
$mon = $mon + $add;

my ($nm, $ny) = ($mon == 12) ? (0,$year+1) : ($mon,$year);

# Letztes Vorkommen des Wochentags berechnen?
if ($x == 9) {
# Berechnen des letzten Tags des Monats
# ersten Tag des Folgemonats als timestamp
my ($xm, $xy) = ($mon == 11) ? (0,$year+1) : ($mon+1,$year);
my $nt = mktime(0, 0, 0, 1, $xm, $xy);

# letzter Tag des aktuellen Monats = erster Tag des Folgemonats minus ein Tag
my ($letzter_tag_des_monats, $letzter_wochentag) = (localtime($nt - DAYSECONDS))[3,6];

# Prüfen, ob der letzte Wochentag im Monat mit dem gewünschten Wochentag übereinstimmt
$ziel_tag = $letzter_tag_des_monats;
if ($letzter_wochentag > $w) {
# Falls der letzte Wochentag später im Monat ist, subtrahiere die Differenz
my $differenz = $letzter_wochentag - $w;
$ziel_tag -= $differenz;
} elsif ($letzter_wochentag < $w) {
# Falls der letzte Wochentag früher im Monat ist, subtrahiere 7 plus die Differenz
my $differenz = $w - $letzter_wochentag;
$ziel_tag -= (7 - $differenz);
}
} else {
# Berechne den Tag des ersten Vorkommens des Wochentags im Monat
my $erster_tag = 1;
my $erster_tag_des_monats = (localtime(mktime(0,0,0,$erster_tag,$nm,$ny)))[6];
my $erstes_vorkommen = ($w - $erster_tag_des_monats + 7) % 7 + 1;

# Berechne den Tag des x.ten Vorkommens des Wochentags im Monat
$ziel_tag = $erstes_vorkommen + 7 * ($x - 1);

# Überprüfe, ob das Datum im gültigen Bereich liegt
if ($ziel_tag > 31 || $ziel_tag < 1) {
return "Ungültiges Datum";
}
}
return mktime($s,$m,$h,$ziel_tag,$nm,$ny);
}

</syntaxhighlight>Als Parameter benötigt die Funktion, welches Vorkommen des Wochentags berechnet werden soll (1-4). Soll das letzte Vorkommen berechnet werden, übergibt man 9. Als Wochentag wird 1-7 angegeben, wobei Montag der Wochentag 1 ist. Danach kommen als getrennte Parameter Stunde, Minute und Sekunde.

=== AT alle x Wochen ausführen ===
Soll ein Termin z.B. alle sechs Wochen stattfinden, so kann folgende Funktion genutzt werden.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# nächsten Treffens in sechs Wochen

sub at_sixweek($) {
my ($tm) = @_;
my $delta = 3628800; # Zeit zwischen den Terminen in Sekunden, hier 6 Wochen

return "Wrong timespec, use \"yyyy-mm-ddThh:mm:ss\"" if($tm !~ m/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/);
my ($y,$m,$d,$h,$m2,$s) = ($1,$2,$3,$4,$5,$6);
my $abstime = mktime($s,$m2,$h,$d,$m-1,$y-1900, 0,0,-1);

if ($data{AT_RECOMPUTE}){
# bei Neuberechnung sechs Wochen zur aktuellen Zeit addieren
my $now = int(time);
$abstime = $now+$delta;
}

return $abstime;
}

</syntaxhighlight>Dabei wird der erste Ausführungstermin im FHEM-üblichen Format ("yyyy-mm-ddThh:mm:ss") übergeben. Die Variable $delta enthält das Intervall in Sekunden. Es kann entsprechend angepasst werden. Die Neuberechnung erfolgt ausgehend vom aktuellen Datum/Uhrzeit. Es kann also als erster Termin nur ein Termin in der Zukunft angegeben werden.
[[Kategorie:Code Snippets]]

AT kleine Helferlein

2024-04-20T16:08:22Z

F Klee:

Ein AT kann statt einer Uhrzeit bzw. eines Datums mit einer Uhrzeit auch eine Perl-Funktion nutzen. Beispiel solcher Funktionen sind [[At#at ultimo|at_ultimo]] oder das Modul [[SUNRISE_EL]]. Hier sollen weitere Funktionen vorgestellt werden.

Der Code kann in der [[99 myUtils anlegen|99 myUtils]] untergebracht werden.

=== AT am x-ten Wochentag im Monat ausführen ===
Aufgabe ist es, das at z.B. an jedem 2. Montag im Monat auszuführen. Zusätzlich gibt es auch die Möglichkeit, das at immer am z.B. letzten Montag im Monat auszuführen.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# x.ten Wochentags im Monat
#
# x=1-4 x.ter Wochentag im Monat
# x=9 letzter Wochentag im Monat
# w=1-7 Wochentag, 1=Montag
# h,m,s Uhrzeit Stunde, Minute, Sekunde
#
sub at_xwday($$$$$) {
my ($x,$w,$h,$m,$s) = @_;

my $ziel_tag = 0;

# akt. Datum und Uhrzeit in Variablen aufteilen
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);

# bei Neuberechnung einen Monat addieren
my $add = $data{AT_RECOMPUTE} ? 1 : 0;
$mon = $mon + $add;

my ($nm, $ny) = ($mon == 12) ? (0,$year+1) : ($mon,$year);

# Letztes Vorkommen des Wochentags berechnen?
if ($x == 9) {
# Berechnen des letzten Tags des Monats
# ersten Tag des Folgemonats als timestamp
my ($xm, $xy) = ($mon == 11) ? (0,$year+1) : ($mon+1,$year);
my $nt = mktime(0, 0, 0, 1, $xm, $xy);

# letzter Tag des aktuellen Monats = erster Tag des Folgemonats minus ein Tag
my ($letzter_tag_des_monats, $letzter_wochentag) = (localtime($nt - DAYSECONDS))[3,6];

# Prüfen, ob der letzte Wochentag im Monat mit dem gewünschten Wochentag übereinstimmt
$ziel_tag = $letzter_tag_des_monats;
if ($letzter_wochentag > $w) {
# Falls der letzte Wochentag später im Monat ist, subtrahiere die Differenz
my $differenz = $letzter_wochentag - $w;
$ziel_tag -= $differenz;
} elsif ($letzter_wochentag < $w) {
# Falls der letzte Wochentag früher im Monat ist, subtrahiere 7 plus die Differenz
my $differenz = $w - $letzter_wochentag;
$ziel_tag -= (7 - $differenz);
}
} else {
# Berechne den Tag des ersten Vorkommens des Wochentags im Monat
my $erster_tag = 1;
my $erster_tag_des_monats = (localtime(mktime(0,0,0,$erster_tag,$nm,$ny)))[6];
my $erstes_vorkommen = ($w - $erster_tag_des_monats + 7) % 7 + 1;

# Berechne den Tag des x.ten Vorkommens des Wochentags im Monat
$ziel_tag = $erstes_vorkommen + 7 * ($x - 1);

# Überprüfe, ob das Datum im gültigen Bereich liegt
if ($ziel_tag > 31 || $ziel_tag < 1) {
return "Ungültiges Datum";
}
}
return mktime($s,$m,$h,$ziel_tag,$nm,$ny);
}

</syntaxhighlight>Als Parameter benötigt die Funktion, welches Vorkommen des Wochentags berechnet werden soll (1-4). Soll das letzte Vorkommen berechnet werden, übergibt man 9. Der Montag ist der Wochentag 1. Danach kommen als getrennte Parameter Stunde, Minute und Sekunde.

=== AT alle x Wochen ausführen ===
Soll ein Termin z.B. alle sechs Wochen stattfinden, so kann folgende Funktion genutzt werden.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# nächsten Treffens in sechs Wochen

sub at_sixweek($) {
my ($tm) = @_;
my $delta = 3628800; # Zeit zwischen den Terminen in Sekunden, hier 6 Wochen

return "Wrong timespec, use \"yyyy-mm-ddThh:mm:ss\"" if($tm !~ m/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/);
my ($y,$m,$d,$h,$m2,$s) = ($1,$2,$3,$4,$5,$6);
my $abstime = mktime($s,$m2,$h,$d,$m-1,$y-1900, 0,0,-1);

if ($data{AT_RECOMPUTE}){
# bei Neuberechnung sechs Wochen zur aktuellen Zeit addieren
my $now = int(time);
$abstime = $now+$delta;
}

return $abstime;
}

</syntaxhighlight>Dabei wird der erste Ausführungstermin im FHEM-üblichen Format ("yyyy-mm-ddThh:mm:ss") übergeben. Die Variable $delta enthält das Intervall in Sekunden. Es kann entsprechend angepasst werden. Die Neuberechnung erfolgt ausgehend vom aktuellen Datum/Uhrzeit. Es kann also als erster Termin nur ein Termin in der Zukunft angegeben werden.
[[Kategorie:Code Snippets]]

AT kleine Helferlein

2024-04-20T16:07:13Z

F Klee: Inhalt eingefügt

Ein AT kann statt einer Uhrzeit bzw. eines Datums mit einer Uhrzeit auch eine Perl-Funktion nutzen. Beispiel solcher Funktionen sind [[At#at ultimo|at_ultimo]] oder das Modul [[SUNRISE_EL]]. Hier sollen weitere Funktionen gezeigt werden.

Der Code kann in der [[99 myUtils anlegen|99 myUtils]] untergebracht werden.

=== AT am x-ten Wochentag im Monat ausführen ===
Aufgabe ist es, das at z.B. an jedem 2. Montag im Monat auszuführen. Zusätzlich gibt es auch die Möglichkeit, das at immer am z.B. letzten Montag im Monat auszuführen.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# x.ten Wochentags im Monat
#
# x=1-4 x.ter Wochentag im Monat
# x=9 letzter Wochentag im Monat
# w=1-7 Wochentag, 1=Montag
# h,m,s Uhrzeit Stunde, Minute, Sekunde
#
sub at_xwday($$$$$) {
my ($x,$w,$h,$m,$s) = @_;

my $ziel_tag = 0;

# akt. Datum und Uhrzeit in Variablen aufteilen
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);

# bei Neuberechnung einen Monat addieren
my $add = $data{AT_RECOMPUTE} ? 1 : 0;
$mon = $mon + $add;

my ($nm, $ny) = ($mon == 12) ? (0,$year+1) : ($mon,$year);

# Letztes Vorkommen des Wochentags berechnen?
if ($x == 9) {
# Berechnen des letzten Tags des Monats
# ersten Tag des Folgemonats als timestamp
my ($xm, $xy) = ($mon == 11) ? (0,$year+1) : ($mon+1,$year);
my $nt = mktime(0, 0, 0, 1, $xm, $xy);

# letzter Tag des aktuellen Monats = erster Tag des Folgemonats minus ein Tag
my ($letzter_tag_des_monats, $letzter_wochentag) = (localtime($nt - DAYSECONDS))[3,6];

# Prüfen, ob der letzte Wochentag im Monat mit dem gewünschten Wochentag übereinstimmt
$ziel_tag = $letzter_tag_des_monats;
if ($letzter_wochentag > $w) {
# Falls der letzte Wochentag später im Monat ist, subtrahiere die Differenz
my $differenz = $letzter_wochentag - $w;
$ziel_tag -= $differenz;
} elsif ($letzter_wochentag < $w) {
# Falls der letzte Wochentag früher im Monat ist, subtrahiere 7 plus die Differenz
my $differenz = $w - $letzter_wochentag;
$ziel_tag -= (7 - $differenz);
}
} else {
# Berechne den Tag des ersten Vorkommens des Wochentags im Monat
my $erster_tag = 1;
my $erster_tag_des_monats = (localtime(mktime(0,0,0,$erster_tag,$nm,$ny)))[6];
my $erstes_vorkommen = ($w - $erster_tag_des_monats + 7) % 7 + 1;

# Berechne den Tag des x.ten Vorkommens des Wochentags im Monat
$ziel_tag = $erstes_vorkommen + 7 * ($x - 1);

# Überprüfe, ob das Datum im gültigen Bereich liegt
if ($ziel_tag > 31 || $ziel_tag < 1) {
return "Ungültiges Datum";
}
}
return mktime($s,$m,$h,$ziel_tag,$nm,$ny);
}

</syntaxhighlight>Als Parameter benötigt die Funktion, welches Vorkommen des Wochentags berechnet werden soll (1-4). Soll das letzte Vorkommen berechnet werden, übergibt man 9. Der Montag ist der Wochentag 1. Danach kommen als getrennte Parameter Stunde, Minute und Sekunde.

=== AT alle x Wochen ausführen ===
Soll ein Termin z.B. alle sechs Wochen stattfinden, so kann folgende Funktion genutzt werden.<syntaxhighlight lang="perl">
########################################
#
# Berechnung des Datums des
# nächsten Treffens in sechs Wochen

sub at_sixweek($) {
my ($tm) = @_;
my $delta = 3628800; # Zeit zwischen den Terminen in Sekunden, hier 6 Wochen

return "Wrong timespec, use \"yyyy-mm-ddThh:mm:ss\"" if($tm !~ m/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/);
my ($y,$m,$d,$h,$m2,$s) = ($1,$2,$3,$4,$5,$6);
my $abstime = mktime($s,$m2,$h,$d,$m-1,$y-1900, 0,0,-1);

if ($data{AT_RECOMPUTE}){
# bei Neuberechnung sechs Wochen zur aktuellen Zeit addieren
my $now = int(time);
$abstime = $now+$delta;
}

return $abstime;
}

</syntaxhighlight>Dabei wird der erste Ausführungstermin im FHEM-üblichen Format ("yyyy-mm-ddThh:mm:ss") übergeben. Die Variable $delta enthält das Intervall in Sekunden. Es kann entsprechend angepasst werden. Die Neuberechnung erfolgt ausgehend vom aktuellen Datum/Uhrzeit. Es kann also als erster Termin nur ein Termin in der Zukunft angegeben werden.
[[Kategorie:Code Snippets]]

AT kleine Helferlein

2024-04-20T15:14:49Z

F Klee:

AT kleine Helferlein

2024-04-20T14:36:19Z

F Klee: Seite erstellt

Ein AT kann statt einer Uhrzeit bzw. eines Datums mit einer Uhrzeit auch eine Perl-Funktion nutzen. Beispiel solcher Funktionen sind [[At#at ultimo|at_ultimo]] oder das Modul [[SUNRISE_EL]]. Hier sollen weitere Funktionen gezeigt werden.

=== AT am x-ten Wochentag im Monat ausführen ===

=== AT alle x Wochen ausführen ===
[[Kategorie:Code Snippets]]

ABFALL

2024-03-23T15:35:03Z

F Klee: /* Voraussetzungen */

{{Infobox Modul
|ModPurpose=Filtern von (Abfall-)Terminen aus einem Calendar.
|ModType=x
|ModFTopic=48237
|ModForumArea=Codeschnipsel
|ModTechName=57_ABFALL.pm
|ModOwner=Constantin / {{Link2FU|14026|uniqueck}}
}}

[[ABFALL]] ist ein (inoffizielles, nicht Bestandteil der Distribution) Hilfsmodul, das bestimmte Termine aus einem bestehenden Kalender des Moduls [[Calendar]] in Readings übernimmt.

== Voraussetzungen ==
Es muss ein [[Calendar]]-Objekt definiert sein. Der dabei benutzte Name muss in der Definition des ABFALL-Objekts spezifiziert werden.
Es können auch mehrere Calendar Objekte übergeben werden.

Sonderzeichen aus dem Namen der Termine werden entfernt, um die Namen der generierten Readings FHEM-tauglich zu machen, für die Werte der Readings bleiben diese allerdings erhalten.

== Anwendung ==
=== Installation ===
Mit folgendem Befehl kann das Modul direkt in den Standard FHEM Update Prozess eingeklinkt werden.
:<code>update add https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt</code>
Um es nur zu installieren, kann auch einfach nur das Command
:<code>update all https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt</code>
eingegeben werden.

=== Entwicklungsstrang ===
:<code>update add https://raw.githubusercontent.com/uniqueck/fhem-abfall/develop/controls_fhemabfall.txt</code>
bzw.
:<code>update all https://raw.githubusercontent.com/uniqueck/fhem-abfall/develop/controls_fhemabfall.txt</code>

=== Define ===
:<code>define <Name> ABFALL <calendarname>,<calendarname2>,...</code>

Erläuterung der Parameter im '''define''':
;<calendarname>
:Name des '''Calendar''' Kalenders

Beispiel:
:<code>define AbfallGoogleCalender Calendar ical url https://......</code>
:<code>define myABFALL ABFALL AbfallGoogleCalender</code>

=== Werte aktualisieren ===
Die Werte aktualisieren sich abhängig vom [[notify]] der entsprechenden Calendar Instanz, welche im define angegeben wurde(n).

=== Weitere Attribute ===

{| class="wikitable"
!Attribut
!Werteliste
!Beschreibung
!Default Wert
|-
!align="right" |calendarname_praefix
|0 und 1
|soll der Kalendername als praefix dem Reading vorangestellt werden, sollte bei nur einem Kalender auf 0 gesetzt werden
|1 - praefix wird vorangestellt, sofern mehrere Kalender angegeben wurden, ansonsten 0 - praefix wird nicht vorangestellt
|-
!align="right" |abfall_clear_reading_regex
|
|regex zum Entfernen von Anteilen aus dem Termin, dieser wird vor dem Entfernen von Sonderzeichen aus den Namen der Termine angewandt.
|
|-
!align="right" |disable
|0 und 1
|deaktiviert das Modul
|0
|-
!align="right" |weekday_mapping
|
|Mapping, wie die Readings der Tage angezeigt werden sollen, zum Beispiel So Mo Di Mi Do Fr Sa
|Sonntag Montag Dienstag Mittwoch Donnerstag Freitag Samstag
|-
!align="right" |delimiter_text_reading
|
|Wenn zwei Abholungen an ein und demselben Tag existieren, wird dieses Trennzeichen genutzt, um die beiden (oder mehrere) Werte zu einem Text zu verbinden. Nur relevant für die Readings next_text und now_text
|und
|-
!align="right" |delimiter_reading
|
|wie attribute delimiter_text_reading, allerdings nur für die readings next und now
|
|-
!align="right" |filter
|
|regex zum Filtern der Namen der Termine aus den Kalendern, so dass nur solche genutzt werden, welche diesem Filter entsprechen
|
|-
|}

== Anwendungsbeispiel(e) ==
=== Einbindung ins Tablet UI ===
<pre><div data-device="myABFALL" data-type="symbol" class="bigger warn wider"
data-get="next" data-get-warn=".*(\d+).*"
data-get-on='["Restmuell_.*","Wertstoff_.*"]'
data-colors='["#000","#6EB54C"]'
data-icons='["fa-trash-o","fa-trash-o"]'></div></pre>

=== Einbindung ins Tablet UI, erweitert ===
Fallen die Leerungen zweier verschiedener Tonnen nicht auf den selben Tag, reicht es normalerweise, nur ein Symbol auf der Oberfläche zu platzieren und dieses dann dynamisch zu befüllen. In folgendem Beispiel werden folgende Anforderungen umgesetzt:
* Anzeige unterschiedlicher Symbole bzw. Farben für Papiertonne, Restmülltonne, Biotonne und gelbe Säcke
* Anzeige der verbleibenden Tage bis zur Leerung als "Warn"-Marker in Rot, aber nur, wenn die Leerung innerhalb der nächsten 2 Tage ist
* Blinken des Symbols, wenn die nächste Leerung morgen ansteht
* Rotation des Symbols, wenn die nächste Leerung noch am selben Tag ansteht. Nach einer bestimmten Uhrzeit (z.B. 9 Uhr morgens) soll dann auf die nächste Tonne geschaltet werden
* Anzeige des Datums bzw. von "heute" oder "morgen" unter dem Symbol als Label

Zur Datumsanzeige wird eine kleine Hilfsfunktion in die 99_myUtils eingebaut.
<syntaxhighlight lang="perl">
sub datumHeuteMorgen($){
my $compareDate = shift;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
$year += 1900; $mon += 1;
my $heute = sprintf('%02d.%02d.%04d', $mday, $mon, $year);
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime(time+86400);
$year += 1900; $mon += 1;
my $morgen = sprintf('%02d.%02d.%04d', $mday, $mon, $year);
return "heute" if $compareDate eq $heute;
return "morgen" if $compareDate eq $morgen;
return $compareDate;
}
</syntaxhighlight>
Diese Funktion wird in den userReadings des Abfall-Moduls verwendet. Das Abfallmodul erzeugt eine Gruppe von Readings mit dem Namen now_*, wenn die Leerung am selben Tag ansteht, bzw. genau dann, wenn der Termin im zu Grunde liegenden Kalender gerade aktiv ist. In diesem Beispiel liegt dem Kalender-Modul ein Google-Kalender zu Grunde, bei dem die Termine immer von 0 Uhr bis 9 Uhr morgens eingetragen sind. Dadurch wird erreicht, dass die Anzeige nach 9 Uhr weiterspringt, weil dann die now-Readings verschwinden.

Folgende userReadings werden zum Abfallmodul hinzugefügt, welches in diesem Beispiel "myABFALL" genannt ist:
<syntaxhighlight lang="perl">
attr myABFALL userReadings ftui_datum {ReadingsVal("myABFALL","now_text","") eq "" ? datumHeuteMorgen(ReadingsVal("myABFALL","next_date","")) : "heute";},ftui_next {ReadingsVal("myABFALL","now_text","") eq "" ? ReadingsVal("myABFALL","next","") : ReadingsVal("myABFALL","now","")."_0";;}
</syntaxhighlight>
Das Reading "ftui_next" bildet die Grundlage für das Symbol in TabletUI, das Reading "ftui_datum" wird für das Label genutzt.

Somit lässt sich ganze in FTUI wie folgt darstellen:
<syntaxhighlight lang="html">
<div data-device="myABFALL"
data-type="symbol"
data-get="ftui_next"
data-get-on='["Biotonne_0$","Biotonne_1$","Biotonne_.*","GelberSack_0$","GelberSack_1$","GelberSack_.*","Papiertonne_0$","Papiertonne_1$","Papiertonne_.*","Restmuelltonne_0$","Restmuelltonne_1$","Restmuelltonne_.*"]'
data-get-warn=".*([0|1|2]).*"
data-colors='["#8B4513","#8B4513","#8B4513","#f4e946","#f4e946","#f4e946","#2d9e1c","#2d9e1c","#2d9e1c","#696969","#696969","#696969"]'
class="large warn"
data-icons='["fa-trash-o fa-spin","fa-trash-o blink","fa-trash-o","fs-bag fa-spin","fs-bag blink","fs-bag","fs-dustbin fa-spin","fs-dustbin blink","fs-dustbin","fa-trash fa-spin","fa-trash blink","fa-trash"]'
/>
<div data-device="myABFALL" data-get="ftui_datum" data-type="label"/>
</syntaxhighlight>
Für Jede Tonne werden hier drei Zustände unterschieden und einzeln in "data-get-on", "data-on-colors" und "data-icons" zugeordnet. Daher haben diese Listen jeweils 12 Einträge.

=== Benachrichtigung ===
==== DOIF ====
====== TelegramBot Beispiel ======
<pre>[myABFALL:next_days] == 1) ( set fhemBot message 'Morgen wird [myABFALL:next_text] abgeholt')
[myABFALL:now_text] ne "") ( set fhemBot message 'Heute wird [myABFALL:now_text] abgeholt')</pre>

====== Pushbullet Beispiel ======

Die morgigen Leerungen per Push um 19:30 mittels [[Pushbullet]]:

<code>define dAbfallmorgen doif ([19:30] and [myABFALL:next_days] == 1) ( msg |Morgen wird [myABFALL:next_text] abgeholt)

attr dAbfallmorgen do always</code>

Die heutigen Leerungen per Push um 07:00 mittels Pushbullet:

<code>define dAbfallheute doif ([07:00] and [myABFALL:now_text] ne "") ( msg |Heute wird [myABFALL:now_text] abgeholt)

attr dAbfallheute do always</code>

=== Links ===
* Forenthema {{Link2Forum|Topic=50177|LinkText=Abfall Visualisierung mit Bilderrahmen}}

At

2024-03-16T15:46:59Z

F Klee: /* at_ultimo */

{{SEITENTITEL:at}}
{{Infobox Modul
|ModPurpose=Setzt einen Fhem-Befehl zu einem späteren Zeitpunkt ab.
|ModType=h

|ModCmdRef=at
|ModTechName=90_at.pm
|ModOwner={{Link2FU|8|rudolfkoenig}}
}}

[[at]] ist ein Erweiterungsmodul, mit dessen Hilfe FHEM-Befehle/-Aktionen zu einem späteren Zeitpunkt ausgeführt werden können. Es läßt sich sowohl einmalige Ausführung, als auch regelmäßige Wiederholung erzielen, Zeitangaben können relativ oder absolut erfolgen.

== Voraussetzungen ==

Keine.

== Anwendung ==
=== Define ===
<code>define <name> at <timespec|datespec> <command></code>

=== Besonderheit ===
*timespec - '''nur Zeit''' im Format HH:MM:SS '''kann eine''' Perlfunktion sein.
*datespec - '''Datum und Zeit''' ISO 8601 oder "number of sec since 1970" '''darf keine''' Perlfunktion sein.
Siehe {{Link2Forum|Topic=91625|Message=168475}}

=== Beispiele ===
*<code>define MeineAktion at 02:02:00 set lamp on</code> → das nächste Mal um zwei Minuten nach 2 Uhr "lamp" einschalten
*<code>define MeineAktion at *02:02:00 set lamp on</code> → jeden Tag um zwei Minuten nach 2 Uhr "lamp" einschalten
*<code>define MeineAktion at {ReadingsVal("Dummy","Zeit","")} set lamp on</code> → das nächste Mal um (Perlfunktion liest Zeit aus dem Dummy) "lamp" einschalten
*<code>define MeineAktion at 2016-01-25T02:02:00 set lamp on</code> → das nächste Mal am 25.01.2016 um zwei Minuten nach 2 Uhr "lamp" einschalten (ISO 8601)
*<code>define MeineAktion at 1453683720 set lamp on</code> → das nächste Mal am 25.01.2016 um zwei Minuten nach 2 Uhr "lamp" einschalten (number of sec since 1970)
*<code>define MeineAktion at +02:02:00 set lamp on</code> → in zwei Stunden und 2 Minuten "lamp" einschalten
*<code>define MeineAktion at +*02:02:00 set lamp on</code> → alle zwei Stunden und 2 Minuten "lamp" einschalten
Um datespec auch variabel mit setzen zu können gibt es einen Workaround: Perlebene, Perlfunktion und Übergabe in Variable.

Beispiele für "number of seconds since 1970"
<syntaxhighlight lang="perl">
{my $time=time_str2num("2019-09-14 23:00:00");;fhem("define MeineAktion at $time set lamp on")}
{my $time=1568494800;;fhem("define MeineAktion at $time set lamp on")}
</syntaxhighlight>
Beispiel im ISO 8601 Format
<syntaxhighlight lang="perl">{my $time="2019-09-14T23:00:00";;fhem("define MeineAktion at $time set lamp on")}</syntaxhighlight>

=== Mehrere Aktionen ausführen ===
Die Verwendung der Semikolon erfordert immer besondere Aufmerksamkeit!
*<code>set lampe1 on ; set lampe2 on </code> → Schaltet sofort beide Lampen ein ( ein bisschen OT, weil kein at)
*<code>define morgens at *7:00:00 set lampe1 on ; set lampe2 on</code> → schaltet lampe 1 immer um 7 an, aber lampe2 sofort. Der erste Befehl landet in der config (im at) der zweite Befehl wird genau wie der define Befehl einfach sofort ausgeführt.
*<code>define morgens at *7:00:00 set lampe1 on ;; set lampe2 on</code> → schaltet BEIDE Lampen immer um 7 an. Beide Befehle landen in der config (im at), nur der define Befehl wird ausgeführt
*<code>define morgens at *7:00:00 set lampe1,lampe2 on</code> → schaltet BEIDE Lampen immer um 7 an. Geht nur wenn der gleiche Befehl an 2 oder mehr Geräte gesendet werden soll

=== at_ultimo ===
Die integrierte Funktion at_ultimo() dient dazu, an jedem letzten Tag des Monats einen FHEM-Befehl auszuführen. Sie kann als Perlfunc für timespec verwendet werden:

<code>
define at_ultimo at *{at_ultimo()} set Lampe1 off
</code>

Dadurch wird ein at-device erstellt, das am letzten Tag des Monats um 23:59:00 Uhr ausgeführt wird.

at_ultimo() kann zusätzliche Parameter annehmen, um eine andere Zeit an diesem Tag anzugeben:

<code>
define at_ultimo at *{at_ultimo(12,23,45)} set Lampe1 off
</code>

Dadurch wird ein at-device erstellt, das am letzten Tag des Monats um 12:23:45 Uhr ausgeführt wird.

=== Attribute ===
...

=== Testen ===
{{Randnotiz|RNText='''Versionsspezifisch:''' Der Befehl ''execNow'' ist in FHEM 5.7/90_at.pm ab 30.4.2016 verfügbar.}}
Mit dem Befehl
:<code>set <devspec> execNow</code>
lässt sich eine ''at''-Definition (einmalig, beispielsweise zu Testzwecken) unabhängig vom Erreichen der angegebenen Zeitspezifikation ausführen.

=== Ändern / Modifizieren ===
Das Zeit-Attribut eines existierenden Timers sollte via <code>modifyTimeSpec</code> (Befehls-Syntax via Web-Interface ermitteln) geändert werden können.
Details dazu in den Forenbeiträgen
* {{Link2Forum|Topic=76227|LinkText=modifyTimeSpec fehlerhaft!?}}
* {{Link2Forum|Topic=36326|LinkText=defmod}}

== Anwendungsbeispiele ==
* [[AT an einem bestimmten Wochentag ausführen|at an einem bestimmten Wochentag ausführen]]
* [[AT um eine Temperaturabhängige Nachtabsenkung zu realisieren|at um eine Temperaturabhängige Nachtabsenkung zu realisieren]]
* [[AT zu einem absoluten Datum ausführen|at zu einem absoluten Datum ausführen]]
* [[SUNRISE_EL|at in Verbindung mit SUNRISE_EL]]

== Links ==
* Abfrage, ob at definiert ist: {{Link2Forum|Topic=23584|Message=841269}}

At

2024-03-16T15:42:15Z

F Klee: at_ultimo hinzu gefügt

{{SEITENTITEL:at}}
{{Infobox Modul
|ModPurpose=Setzt einen Fhem-Befehl zu einem späteren Zeitpunkt ab.
|ModType=h

|ModCmdRef=at
|ModTechName=90_at.pm
|ModOwner={{Link2FU|8|rudolfkoenig}}
}}

[[at]] ist ein Erweiterungsmodul, mit dessen Hilfe FHEM-Befehle/-Aktionen zu einem späteren Zeitpunkt ausgeführt werden können. Es läßt sich sowohl einmalige Ausführung, als auch regelmäßige Wiederholung erzielen, Zeitangaben können relativ oder absolut erfolgen.

== Voraussetzungen ==

Keine.

== Anwendung ==
=== Define ===
<code>define <name> at <timespec|datespec> <command></code>

=== Besonderheit ===
*timespec - '''nur Zeit''' im Format HH:MM:SS '''kann eine''' Perlfunktion sein.
*datespec - '''Datum und Zeit''' ISO 8601 oder "number of sec since 1970" '''darf keine''' Perlfunktion sein.
Siehe {{Link2Forum|Topic=91625|Message=168475}}

=== Beispiele ===
*<code>define MeineAktion at 02:02:00 set lamp on</code> → das nächste Mal um zwei Minuten nach 2 Uhr "lamp" einschalten
*<code>define MeineAktion at *02:02:00 set lamp on</code> → jeden Tag um zwei Minuten nach 2 Uhr "lamp" einschalten
*<code>define MeineAktion at {ReadingsVal("Dummy","Zeit","")} set lamp on</code> → das nächste Mal um (Perlfunktion liest Zeit aus dem Dummy) "lamp" einschalten
*<code>define MeineAktion at 2016-01-25T02:02:00 set lamp on</code> → das nächste Mal am 25.01.2016 um zwei Minuten nach 2 Uhr "lamp" einschalten (ISO 8601)
*<code>define MeineAktion at 1453683720 set lamp on</code> → das nächste Mal am 25.01.2016 um zwei Minuten nach 2 Uhr "lamp" einschalten (number of sec since 1970)
*<code>define MeineAktion at +02:02:00 set lamp on</code> → in zwei Stunden und 2 Minuten "lamp" einschalten
*<code>define MeineAktion at +*02:02:00 set lamp on</code> → alle zwei Stunden und 2 Minuten "lamp" einschalten
Um datespec auch variabel mit setzen zu können gibt es einen Workaround: Perlebene, Perlfunktion und Übergabe in Variable.

Beispiele für "number of seconds since 1970"
<syntaxhighlight lang="perl">
{my $time=time_str2num("2019-09-14 23:00:00");;fhem("define MeineAktion at $time set lamp on")}
{my $time=1568494800;;fhem("define MeineAktion at $time set lamp on")}
</syntaxhighlight>
Beispiel im ISO 8601 Format
<syntaxhighlight lang="perl">{my $time="2019-09-14T23:00:00";;fhem("define MeineAktion at $time set lamp on")}</syntaxhighlight>

=== Mehrere Aktionen ausführen ===
Die Verwendung der Semikolon erfordert immer besondere Aufmerksamkeit!
*<code>set lampe1 on ; set lampe2 on </code> → Schaltet sofort beide Lampen ein ( ein bisschen OT, weil kein at)
*<code>define morgens at *7:00:00 set lampe1 on ; set lampe2 on</code> → schaltet lampe 1 immer um 7 an, aber lampe2 sofort. Der erste Befehl landet in der config (im at) der zweite Befehl wird genau wie der define Befehl einfach sofort ausgeführt.
*<code>define morgens at *7:00:00 set lampe1 on ;; set lampe2 on</code> → schaltet BEIDE Lampen immer um 7 an. Beide Befehle landen in der config (im at), nur der define Befehl wird ausgeführt
*<code>define morgens at *7:00:00 set lampe1,lampe2 on</code> → schaltet BEIDE Lampen immer um 7 an. Geht nur wenn der gleiche Befehl an 2 oder mehr Geräte gesendet werden soll

=== at_ultimo ===
Die integrierte Funktion at_ultimo() dient dazu, an jedem letzten Tag des Monats einen FHEM-Befehl auszuführen. Sie kann als Perlfunc für timespec verwendet werden:

<code>
define at_ultimo at *{at_ultimo()} set Lampe1 off
</code>

Dadurch wird ein At-Gerät erstellt, das am letzten Tag des Monats um 23:59:00 Uhr ausgeführt wird.

at_ultimo() kann zusätzliche Parameter annehmen, um eine andere Zeit an diesem Tag anzugeben:

<code>
define at_ultimo at *{at_ultimo(12,23,45)} set Lampe1 off
</code>

Dadurch wird ein AT-Gerät erstellt, das am letzten Tag des Monats um 12:23:45 Uhr ausgeführt wird.

=== Attribute ===
...

=== Testen ===
{{Randnotiz|RNText='''Versionsspezifisch:''' Der Befehl ''execNow'' ist in FHEM 5.7/90_at.pm ab 30.4.2016 verfügbar.}}
Mit dem Befehl
:<code>set <devspec> execNow</code>
lässt sich eine ''at''-Definition (einmalig, beispielsweise zu Testzwecken) unabhängig vom Erreichen der angegebenen Zeitspezifikation ausführen.

=== Ändern / Modifizieren ===
Das Zeit-Attribut eines existierenden Timers sollte via <code>modifyTimeSpec</code> (Befehls-Syntax via Web-Interface ermitteln) geändert werden können.
Details dazu in den Forenbeiträgen
* {{Link2Forum|Topic=76227|LinkText=modifyTimeSpec fehlerhaft!?}}
* {{Link2Forum|Topic=36326|LinkText=defmod}}

== Anwendungsbeispiele ==
* [[AT an einem bestimmten Wochentag ausführen|at an einem bestimmten Wochentag ausführen]]
* [[AT um eine Temperaturabhängige Nachtabsenkung zu realisieren|at um eine Temperaturabhängige Nachtabsenkung zu realisieren]]
* [[AT zu einem absoluten Datum ausführen|at zu einem absoluten Datum ausführen]]
* [[SUNRISE_EL|at in Verbindung mit SUNRISE_EL]]

== Links ==
* Abfrage, ob at definiert ist: {{Link2Forum|Topic=23584|Message=841269}}

AT zu einem absoluten Datum ausführen

2023-11-03T15:30:59Z

F Klee:

'''Achtung:''' der Befehl [[at]] kennt im Gegensatz zur Behauptung im Artikel unten durchaus Ausführungen zu einem bestimmten Datum.

Das letztgenannte Beispiel kann z.b. mit
<nowiki>define Licht_25_Januar_an at 2011-01-25T07:15:00 set Licht1 on</nowiki>
Realisiert werden, siehe auch Commandrefeintrag.

Die unten dargestellt Lösung, täglich bei Erreichen der gewünschten Uhrzeit zu prüfen ob der richtige Tag erreicht wurde, erfordert mehr Code und ist auch Perfomanceseitig ungünstiger.

________________________________________________________________________________________________

Mit dem Befehl [[at]] können in FHEM Aktionen zu einem definierten Zeitpunkt ausgeführt werden:

<nowiki>define morgens_Licht_an at *07:15:00 set Licht1 on</nowiki>
Es können nur relative und absolute Uhrzeiten, jedoch nicht ein bestimmtes Datum definiert werden.

Allerdings kann die Ausführung an Bedingungen geknüpft sein, wie z.b. bestimmte Wochentage oder nur am Wochenende:

<nowiki>define morgens_Licht_Wochenende at *07:15:00 {if (!($we)) {fhem("set Licht1 on")} }</nowiki>
Auf die selbe Art kann auch auf ein Ausführungsdatum geprüft werden.

<nowiki>define Licht_25_Januar_an at *07:15:00 {if($year==2011 && $month==1 && $mday==25) {fhem("set Licht1 on")} }</nowiki>
In diesem Fall wird täglich um 7:15 Uhr geprüft, ob der 25. Januar 2011 ist und falls ja, wird die Aktion ausgeführt.

Da dieser Fall nur einmal zutrifft, ist es sinnvoll, die Aktion nach Auslösung zu löschen, damit nicht nach dem 25. Januar 2011 weiter täglich geprüft wird, ob das Datum nochmal auftritt:

<pre>define Licht_25_Januar_an at *07:15:00 {if($year==2011 && $month==1 && $mday==25) \
{fhem ("set Licht1 on; delete Licht_25_Januar_an"} }</pre>

[[Kategorie:Code Snippets]]

MQTT2 DEVICE - Schritt für Schritt

2023-10-28T16:20:31Z

F Klee: /* periodicCmd */

== Einführung ==
Das Protokoll [[MQTT]] ermöglicht einen flexiblen Datenaustausch zwischen unterschiedlichsten Geräten und FHEM und insbesondere auch bidirektionale Kommunikation von und zu FHEM. Es gibt dabei jedoch nur einen geringen Grad der Standardisierung des Datenaustauschs. In der Praxis sind daher relative viele unterschiedliche Wege aufzufinden, wie die Kommunikation via MQTT in den externen Geräten und Diensten konkret umgesetzt wurde - jeder Autor einer firmware oder Software kann dies so lösen, wie es ihm beliebt, und nicht jeder beherzigt dabei den Grundsatz, dass die Kommunikation via MQTT "leichtgewichtig" sein sollte.

{{Randnotiz|RNTyp=Info|RNText=Grundsätzlich stehen für viele Geräte-Typen bereits Vorlagen zur Verfügung, siehe [[AttrTemplate|attrTemplate]], die einem die wesentliche Konfigurationsarbeit abnehmen können, wie sie hier beschrieben ist. Die damit jeweils erzeugten Konfigurationen sind Einrichtungsbeispiele, die v.a. eine in sich konsistenze Zusammenstellung der verschiedenen Attribute enthalten. Es steht jedem User frei, diese Ausgangsbasis dann nach seinem Belieben zu ändern. Spätere Änderungen des verwendeten attrTemplate wirken sich nicht automatisch auf die durch frühere Versionen oder den User nachkonfigurierte Geräte aus! Da es vorkommen kann, dass sich die per MQTT übermittelten Daten und Topics ändern, wenn z.B. eine firmware aktualisiert wurden, kann dies Anpassungen am jeweiligen Template erforderlich machen. Grundsätzlich sollen die per attrTemplate für MQTT2_DEVICE verfügbaren attrTemplate jeweils für die aktuellste verfügbare stabile firmware-Version passen.}}

Das Modul [[MQTT2_DEVICE]] bietet eine Vielzahl von Möglichkeiten, auf die verschiedensten Anforderungen einzugehen, und die ein- und ausgehenden Daten zu einem oder mehreren FHEM-[[Gerät|Gerät/en]] zusammenzufassen. Eine Übersicht häufig vorkommender MQTT-Geräte ist in [[MQTT2-Module - Praxisbeispiele]] zu finden.

Ziel dieses Artikels ist die Darstellung der Schritte, die sich als zweckmäßig erwiesen haben zur Einrichtung von "guten" FHEM-Geräten.
{{Randnotiz|RNTyp=Info|RNText=Viele - teils komplexe Beispiele und weitere Verweise sind im {{Link2Forum|Topic=116162|LinkText=MQTT-Workshop für MQTT2-Module}} zu finden.}}Dabei soll am Ende erreicht werden:
* standardisierte set- (und ggf. get-)-Kommandos, insbesondere unter Beachtung der [[DevelopmentGuidelinesReadings| Developer Guidelines für Readings]]
* Schließen des Informationskreises von eventuellen Kommandos bis zur Rückmeldung des (externen) Gerätes oder Dienstes (im Folgenden: "Gegenstelle")
* standardisierte Reading-Namen, damit möglichst Auswertungen nicht speziell an das jeweilige Gerät angepasst werden müssen
* Reduzierung und Vermeidung von unnötigen Datenpunkten und Events
* Einrichten von regelmäßigen Abfrage-Timern (falls erforderlich!).

== Vorbereitung ==
=== MQTT2_SERVER ===
Selbst, wenn grundsätzlich ein externer MQTT-Server IO-Device zum Einsatz kommt, ist sehr zu empfehlen, für die Beschäftigung mit einem neuen, unbekannten Device zunächst einen {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} einzurichten. Ist der Port 1883 bereits belegt, nimmt man einfach einen anderen Port, z.B. 1884: <code>define m2server MQTT2_SERVER 1884 global</code>. Sollte die Gegenstelle tiefer strukturierte Daten im JSON-Format über verschiedene Topics als Payload übermittelt, kann es ausnahmsweise hilfreich sein, '''in der Einrichtungsphase''' auch das Attribut "autocreate" am MQTT2_SERVER auf "complex" zu stellen: <code>attr m2server autocreate complex</code>. Weiter muss die allgemeine [[Autocreate|autocreate-Instanz]] aktiv sein. Für den Regelbetrieb und für einfache, bekannte Devices (sowie für solche, für die bereits attrTemplate vorhanden sind), wird ausdrücklich empfohlen, das ''autocreate''-Atribut am m2server gar nicht erst zu setzten, dann wird ''autocreate'' mit der (default) Einstellung ''simple'' verwendet. Die Hintergründe sind nachfolgend im Abschnitt zu ''json2nameValue()'' zu finden.

=== Begrifflichkeiten ===
Ein typisches, von "autocreate" erstelltes Gerät sieht dann z.b. (mit autocreate = simple am MQTT2_SERVER) so aus:
<syntaxhighlight lang="text">
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/LWT:.* LWT\
DVES_9B01BD:tele/DVES_9B01BD/UPTIME:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/SENSOR:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO1:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO2:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO3:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/RESULT:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
</syntaxhighlight>
Wir unterscheiden bei jeder Zeile des readingList-Attributs vier Elemente, die ersten drei werden jeweils durch einen Doppelpunkt voneinander getrennt:
==== CID ====
Dies ist die Gerätekennung (hier: DVES_9B01BD). Diese ist auch Bestandteil des ''define'', über diese wird ermittelt, zu welchem FHEM-Gerät via MQTT eingehende Informationen zugeordnet werden sollen. Diese Angabe ist weder im define noch in der readingList zwingend, aber in der Definition für den Hauptkanal eines Gerätes empfohlen. Es empfiehlt sich, die CID-Angaben bei eigenen readingList-Einträgen wegzulassen bzw. diese zu löschen. So kann einfacher zwischen automatisch generierten und eigenen Angaben unterschieden werden und die Geräte sind leichter zwischen verschiedenen IO-Modulen zu verschieben.
==== Topic ====
Datenpunkt, an den eine Information gesendet wird. Empfangsseitig sind dies hier z.B. ''tele/DVES_9B01BD/STATE'' oder ''tele/DVES_9B01BD/LWT''.
Enthält der Topic Doppelpunkte oder Sonderzeichen, kann dies zu Problemen führen. Da der Topic intern als ''regex'' behandelt wird, kann man sich das in solchen Sonderfälle dadurch zu nutze machen, dass man z.B problematische Zeichen durch Punkte oder "beliebige Zeichenfolgen" ersetzt. So kann z.B. aus dem per autocreate erstellten <code>attr reader readingList SMLReader/Strom/sensor/1/obis/1-0:1.8.0/255/value:.* Strombezug_tariflos</code> folgendes abgeleitet werden: <code>attr reader readingList SMLReader/Strom/sensor/1/obis/1-0.1.8.0/255/value:.* Strombezug_tariflos</code>,

==== Payload ====
Der jeweilige Nachrichteninhalt. Da dieser nicht im vorhinein bekannt ist, wird er in der readingList typischerweise als "beliebige Zeichenfolge" (".*") notiert.

==== Auswertung ====
Dies kann entweder direkt der Reading-Name sein, dem die Payload zugeordnet werden soll, oder ein Perl-Ausdruck. Hier wird z.B. die eingehende Information für ''tele/DVES_9B01BD/LWT'' dem Reading ''LWT'' zugeordnet, während die Informationen aus ''tele/DVES_9B01BD/STATE'' an die Funktion ''json2nameValue()'' übergeben werden. ''$EVENT'' entspricht dabei der ''Payload''.

=== defaults ===
Für unbekannte Gegenstellen ist zunächst immer zu empfehlen, deren "Grundeinstellungen" zu verwenden, und Anpassungen erst und nur insoweit vorzunehmen, als es für ein besseres Zusammenspiel mit FHEM sinnvoll ist. Abzuraten ist insbesondere von:
* Änderungen der Topics und Topic-Sturkturen (ausgenommen den Fall, dass schon andere Gegenstellen im Einsatz sind, die identische Topics verwenden)
* Vergabe von ''friendly names''

== Bestandsaufnahme ==
=== Projektseiten finden ===
Viele Geräte, die das MQTT-Protokoll verwenden, haben eigene Projektseiten oder API-Beschreibungen, denen man entnehmen kann, wie mit dieser Gegenstelle Daten ausgetauscht werden können. Diese sollte man bei allen weiteren Schritten stets zur Hand haben. Dabei kann es neben der allgemeinen Beschreibung auch ein oder mehrere Detail-Seiten geben, auf denen nähere Informationen zu den spezifischen Geräte zu finden sein können.

=== MQTT - Datenverkehr mitlesen ===
Sowohl MQTT2_SERVER wie MQTT2_CLIENT bieten in der Detailansicht die Option ''Show MQTT traffic''. Darüber läßt sich der ein- und ausgehende Datenverkehr bequem mitlesen. Bei MQTT2_CLIENT wird dabei allerdings vorausgesetzt, dass er überhaupt Daten vom MQTT-Server erhält, also insbesondere die ''subscriptions'' korrekt gesetzt sind (falls per Attribut eingeschränkt).

=== readingList ===
Zunächst empfiehlt es sich, einfach die Gegenstelle neu zu starten und (ggf. über ein FileLog) aufzuzuzeichnen, was über welchen Topic wie oft an Informationen gesendet wird. Dabei kann und sollte durchaus - sofern dies möglich ist - der eine oder andere Schaltvorgang (z.B. über das Web-Interface der Gegenstelle) durchgeführt werden, sofern dies möglich ist (oder allgemeiner: möglichst viele bekannte Anweisungen ausführen lassen). Am Ende sollte man eine möglichst vollständige Auflistung in der readingList erhalten haben.
Falls strukturierte Daten im JSON-Format als Payload verwendet werden, kann man diese auch zusätzlich ohne die Verarbeitung durch ''json2nameValue()'' aufzeichnen, z.B. indem man die betreffende Zeile in der readingList doppelt:
<syntaxhighlight lang="text">
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
attr MQTT2_DVES_9B01BD readingList tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\
tele/DVES_9B01BD/STATE:.* json_STATE\
tele/DVES_9B01BD/LWT:.* LWT\
[...]
</syntaxhighlight>
So kann man mit Hilfe des betreffenden Logs ggf. auch über ein externes Tool wie mosquitto_pub MQTT-Nachrichten an FHEM generieren, ohne darauf warten zu müssen, dass diese von der Gegenstelle selbst erzeugt werden.

=== ignoreRegexp ===
Manche Gegenstellen senden beim Start Konfigurationsinformationen, die allerdings nicht durch FHEM ausgewertet werden können. Die betreffenden Topics sollte man (allgemein) so in die ignoreRegexp beim MQTT2_SERVER bzw. [[MQTT2_CLIENT]] aufnehmen, dass derartige Informationen künftig gar nicht mehr an MQTT2_DEVICE weitergereicht werden. Danach kann man die betreffenden Zeilen aus der readingList löschen! Entsprechendes gilt für die hierüber generierten Readings.

Weiter ist zu empfehlen, in diese ignoreRegexp auch die Topics aufzunehmen, über die Gegenstellen typischerweise Kommandos entgegennehmen. Dies könnte z.B. so aussehen:
<code>attr m2server ignoreRegexp shellies/[^/]+/command|cmnd/[^/]+/|homeassistant/.*/config|tasmota/discovery</code>

=== Viele Geräte? ===
==== "split" ====
Sind auf einer Hardware mehrere "Hauptschalter" vorhanden (z.B. ein Relay-Board), ist sehr zu empfehlen, für jeden dieser "Hauptschalter" ein eigenes FHEM-Gerät anzulegen (für logische Einheiten wie Rollladenaktoren ggf. paarweise). MQTT2_DEVICE unterstützt [[DevelopmentModuleAPI#SetExtensions|SetExtensions]] und kann daher Kommandos wie "on-for-timer" über FHEM-interne Mechanismen gut umsetzen. Dies erfordert allerdings, dass die Kommandos "on" und "off" verfügbar sein müssen.
Wird ein Gerät gesplittet, sollten im Gerät, das den ersten (Haupt-) Kanal repräsentiert dann alle Kommunikationsdaten gebündelt werden, Querverweise zu den weiteren Kanälen kann man über das spezielle Readings "associatedWith" herstellen.

==== bridgeRegexp ====
{{Randnotiz|RNTyp=Info|RNText=Manche derartige Interfaces müssen zunächst entsprechend konfiguriert werden, dass die zu einem Sensor oder Aktor gehörenden Daten jeweils auf einem eigenen Topic ausgegeben werden. Insbesondere ist dies bei Tasmota (ZigBee oder Bluetooth) der Fall!}}
In eher seltenen Fällen kommt es vor, dass eine Gegenstelle eine Art "Brücke" zu einer Mehrzahl über diese Brücke anzusteuernder (oder zu empfangender) Aktoren oder Sensoren darstellt. In diesen Fällen kann es geboten sein, die eigentliche Gegenstelle als Hauptdevice darzustellen und für jede weitere Hardware (Sensor oder Aktor) dann ein oder mehrere Einzeldevices anzulegen. Dies kann mit Hilfe des Attributs bridgeRegexp automatisiert erfolgen, wenn sich der Sensor/Aktor aus der Topic-Struktur ablesen läßt.

== readingList optimieren==
=== gute Reading-Namen - Klartext ===
Viele Gegenstellen senden z.B. einen online/offline-Status als "last will and testament" unter einem Topic, der mit "LWT" endet. Dieses hier sendet zwar passende Daten, aber an einen anderen Topic. In solchen Fällen man kann den von autocreate erzeugten Eintrag einfach anpassen:
attr DEVICE readingList /dingtian/DEVNAME/out/lwt_availability:.* LWT

=== Bedingte Hash-Rückgaben ===
Manchmal erfolgt zwar die Übergabe eines Klartextes als $EVENT - allerdings nicht in der Form, wie man das in FHEM gerne hätte. Hier als "0" oder "1". Mit etwas Perl und der Rückgabe eines Hashes kann man so etwas beliebig umformen:
attr DEVICE readingList DEVNAME/relay/0:.* { $EVENT ? {state=>'on'} : {state=>'off'} }\
DEVNAME/status:.* { $EVENT ? {LWT=>'Online'} : {LWT=>'Offline'} }
Weiteres Beispiel: Der "state" kommt in Großschreibung und soll in Kleinschreibung geändert werden:
attr DEVICE readingList switchbot/esp32_2/bot/switchbottwo/state:.* { { state => lc $EVENT } }

=== json2nameValue() ===
Mit Hilfe der Funktion json2nameValue() (in Verbindung mit dem attribut ''jsonMap'') lassen sich
* "gute Reading-Namen" auch aus JSON-Payloads erzeugen (2. und 3. Argument)
* unnötige Readings vorab ausfiltern (3., 4. und 5. Argument)
Beispiele für die Verwendung der Argumente 1 bis 3 sind der commandref in der Erläuterung des Attributs ''jsonMap'' bei MQTT2_DEVICE zu entnehmen, die (wie die Argumente 2 und 3 optionalen) Argumente 4 und 5 entsprechen einem Positiv- bzw.- Negativ-Filter, gefiltert wird, wenn die jeweils übergebene regexp matcht (5. Argument) bzw. nicht matcht (4. Argument).
Wird (übergangsweise!) ''autocreate'' in der ''complex''-Variante eingestellt, werden für alle (bisher nicht bekannten) Topics Einträge wie dieser erzeugt:
attr MQTT2_DVES_9B01BD readingList tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT,'STATE_',$JSONMAP) }
* Das zweite Argument (''STATE_'') ist ein "Präfix", der allen aus dem JSON erzeugten Readings aus diesem Topic (zunächst) vorangestellt wird. Mit dessen Hilfe läßt sich rekonsturieren, aus welchem Topic die betreffende Information ursprünglich kam. In der Regel ist dies nach der Einrichtung nicht mehr wichtig, und dieses Argument kann auf "nichts" (zwei einfache Quotes) gestellt werden. Allerdings kann es in Einzelfällen sinnvoll sein, Präfixe zu verwenden, um zwischen scheinbar gleichen Werte aus unterschiedlichen Quellen zu unterscheiden. Dies kann man erst abschließend entscheiden, wenn alle von der Gegenstelle gelieferten Daten bekannt sind.
* Das dritte Argument ''$JSONMAP'' kann in der Regel so belassen werden. Dann kann mit Hilfe des Attributs ''jsonMap'' eine Zuordnungstabelle für Namensänderungen für die zu generierenden Readingnamen erzeugt und/oder Werte schlicht gelöscht werden.

=== Auswertung unterbinden ===
Indem man einen Perl-Aufruf festlegt (geschweifte Klammern), dieser aber nichts zurückgibt, kann man bestimmte unerwünschte Readings ausfiltern. Im einfachsten Fall wäre dies:
shellies/DEVNAME/temperature_f:.* {}

Komplexer mit Auswertung der Payload:
STATTOPIC/RESULT:.* { $EVENT =~ m{HSBColor...(\d+),(\d+),(\d+)} ? $2 eq ReadingsVal($NAME,'saturation','unknown') ? return : { saturation=>$2 } : return }

=== Perl ===
Wie am Beispiel der speziellen Funktion <code>json2nameValue()</code> sowie der Hash-Rückgabe bereits dargestellt, ist es möglich, bei der Auswertung auch Perl-Funktionen einzusetzen, und diverse Variablen an diese zu übergeben. Ebenso ist es möglich, eigenen Perl-Code zu verwenden, der z.B. dann längere Zuordnungstabellen, Event-Reduzierungsmechanismen, ... enthalten kann.

== Events optimieren==
Leider senden relativ viele Gegenstellen in ihren Standardeinstellungen sehr viele Daten, auch ohne dass sich etwas geändert hätte. Dies erzeugt uU. in FHEM eine erhebliche Last, so dass es dringend zu empfehlen ist, alle Maßnahmen zu prüfen, durch die dieses Verhalten unterbunden oder vermindert werden kann. Dabei sollte möglichst frühzeitig eingegriffen werden, entsprechend den folgenden Handlungsoptionen: Daten, die die firmware gar nicht erst sendet, muss FHEM nicht am Interface-Modul entgegennehmen. Daten, die direkt am Interface-Modul verworfen werden (ignoreRegexp), muss das Client-Modul nicht auswerten. Readings, die man (an einem bestimmten Device) nicht benötigt, sollte man nicht erzeugen, damit keine [[Eventhandler]] aktiv werden müssen, unveränderte, aber gewünschte Daten müssen nicht unbedingt (immer) Events erzeugen.

=== firmware-Einstellungen ===
Bei manchen firmwares kann man einstellen, ob bzw. wie oft oder aus welchem Anlass Daten gesendet werden sollen. Es wird dringlich empfohlen, bei "gesprächigen" Gegenstellen zu recherchieren, ob und in welcher Weise diese derartige Möglichkeiten bietet. Falls solche nicht vorhanden sind, lohnt es sich, auf den betreffenden Projektseiten nachzufragen, ob es diese Optionen gibt - nicht selten hat sich ein firmware-Autor darüber schlicht noch keine Gedanken gemacht und baut in der nächsten Version ggf. entsprechende Optionen ein?

=== Auswertung unterbinden ===
(s.o. für Topics/Readings, die gar nicht benötigt werden). Dies ist insbesondere auch zu empfehlen, wenn identische Daten zum gleichen Zeitpunkt sowohl als Klartext wie auch in einem JSON-Format übermittelt werden. In solchen Fällen ist es eher zu empfehlen, die JSON-Zweige zu abonnieren und den Rest (ggf. über einen ignoreRegexp-Eintrag) gar nicht auszuwerten.
Doppelungen sollten in jedem Fall vermieden werden!
Grundsätzlich erzeugt jeder Topic eine eigene Event-Loop, mehrere Readings-updates, die aus einer einzigen JSON-Payload abgeleitet werden, erzeugen dagegen eine gemeinsame Event-Loop. Durch solche Maßnahmen läßt sich die Systembelastung deutlich reduzieren.
Für Daten aus JSON-Payloads besteht darüber hinaus die Möglichkeit, diese komplett auszufiltern (siehe jsonMap weiter oben)

=== event-on-change-reading und Co. ===
Da die firmwares häufig recht gesprächig programmiert sind, sollte man auf eine sinnvolle Begrenzung der durch Aktualisierungen verursachten Events besonderen Wert legen. Dazu ist in erster Linie das Attribut [[Event-on-change-reading|event-on-change-reading]] zu bearbeiten und ggf. passende threshold-Werte zu setzen, es empfiehlt sich allerdings, dabei auch zu untersuchen, inwieweit die weiteren, funktional ergänzenden Attribute zu setzen sind:
* [[Event-min-interval|event-min-interval]]
* [[Event-on-update-reading|event-on-update-reading]]
* timestamp-on-change-reading und
* [[Event-aggregator|event-aggregator]]

=== gute Reading-Namen - userReadings ===
Manchmal werden per MQTT Werte übersendet, die so nicht direkt verwendbar sind. Beispiele hierfür wären:
* Batteriespannungen in mV (z.B. bei zigbee2mqtt)
* Farbwerte als Einzelreading (für die Anzeige in FHEM wird aber ein RGB-Wert benötigt)
In diesen Fällen kann man zwar nicht ohne weiteres den Ausgangswert umrechnen lassen, (über externe Module wie readingsChange sehr wohl), aber es ist über den Weg "userReadings" ohne weiteres möglich, passende Readings zu generieren. Dabei sollte aber zur Verringerung der Systembelastung allgemein sowie ggf. falscher Ergebnisse unbedingt darauf geachtet werden, dass diese auch mit einer ''trigger''-Angabe versehen sind!

== setList ==

=== Allgemeines ===
Die setList ist dazu gedacht, Kommandos zu definieren, welche an die Gegenstelle gesendet werden können.

=== Syntax ===
In der Regel besteht jede Zeile aus folgenden, per Leerzeichen getrennten Argumenten:
* einem setter-Namen, ggf. ergänzt durch ein widget (s.u.)
* einem Topic, unter dem die Payload gesendet werden soll und
* der Payload.
Es können diverse Variablen genutzt werden, u.A. auch $EVENT und $EVTPARTx-Elemente, die der Rückgabe (setter-Name und ggf. gesetzter Wert) aus dem jeweiligen "widget" entsprechen.

=== on und off ===
Damit die weitergehenden Befehle wie ''on-for-timer'' aus den [[DevelopmentModuleIntro#X_Set|SetExtensions]] funktionieren, muss ein MQTT2_DEVICE die Befehle "on" und "off" kennen. Diese sollten also - wenn es eine Art "Hauptschalter" gibt - gesondert für diesen Hauptschalter angegeben werden.
Hat ein Gerät mehrerer solcher "Hauptschalter", empfiehlt es sich, für jeden dieser Schalter eine eigene MQTT2_DEVICE-Instanz anzulegen.

==== setStateList ====
Gibt es in einem Device neben dem "Hauptschalter" weitere setzbare Readings (z.B. für Helligkeit und Farbe oder eine Temperatur), empfiehlt es sich v.a. dann, wenn das Gerät den Empfang (bzw. die Ausführung) von Befehlen bestätigt, nur die auf den jeweiligen Hauptschalter bezogenen ''set''-Anweisungen in ''state'' zu schreiben. Diese (z.B. on, off und toggle) wären dann in das ''setStateList''-Attribut aufzunehmen.

==== setExtensionsEvent ====
Will man per SetExtensions realisierte laufende Timer visualisieren, empfiehlt es sich, dieses Attribut zu setzen.

=== widgets ===
In der setList können prinzipiell alle in [[FHEMWEB/Widgets|Widgets]] dargestellten Eingabemöglichkeiten verwendet werden.

=== Perl-Kommandos ===
Eigentlich ist die setList dazu gedacht, eine publish-Anweisungen über das IODev abzusetzen. Da aber generisch auch Perl-Code aufgerufen werden kann, ist dies nicht zwingend, so dass zum einen aus Perl heraus auch mehrfach-Publishes ebenso möglich sind wie beliebige "fhem"-Kommandos, die gar nichts mit MQTT zu tun haben müssen (z.B. das regelmäßige Löschen von evtl. veralteten Readings am betreffenden Gerät). Wird Text zurückgegeben, wird dies als "<topic> <payload>" interpretiert und dies gepublisht, erfolgt gar keine Rückgabe, unterbleibt dies.

== getList ==
Die getList ist dazu gedacht, asynchrone Abfragen an die Gegenstelle zu ermöglichen.
Die Syntax dabei ist
* einem getter-Namen, ggf. ergänzt durch ein widget (s.u.)
* Reading-Name, unter dem die Antwort erwartet wird
* einem Topic, unter dem die Payload gesendet werden soll und
* (optional) der Payload.
Auch hier können diverse Variablen genutzt werden, und/oder das ganze für die Ausführung von Perl-Code genutzt werden.

== periodicCmd ==
Für regelmäßige Aufgaben (mit mind. minütlicher Frequenz) kann eine Liste von get- oder set-Kommandos angegeben werden. Dies kann für regelmäßige Abfragen ebenso genutzt werden wie z.B. zum Löschen veralteter Informationen/Readings.

== Abschließende Aufgaben ==
Um das finale Aussehen des Gerätes zu beeinflussen, stehen dann noch die weiteren allgemeinen Attribute zur Verfügung, die in [[DeviceOverview anpassen]] beschrieben sind.

== Hinweise ==
<references />
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT]]

MQTT2 DEVICE - Schritt für Schritt

2023-10-28T16:03:05Z

F Klee: /* readingList */

== Einführung ==
Das Protokoll [[MQTT]] ermöglicht einen flexiblen Datenaustausch zwischen unterschiedlichsten Geräten und FHEM und insbesondere auch bidirektionale Kommunikation von und zu FHEM. Es gibt dabei jedoch nur einen geringen Grad der Standardisierung des Datenaustauschs. In der Praxis sind daher relative viele unterschiedliche Wege aufzufinden, wie die Kommunikation via MQTT in den externen Geräten und Diensten konkret umgesetzt wurde - jeder Autor einer firmware oder Software kann dies so lösen, wie es ihm beliebt, und nicht jeder beherzigt dabei den Grundsatz, dass die Kommunikation via MQTT "leichtgewichtig" sein sollte.

{{Randnotiz|RNTyp=Info|RNText=Grundsätzlich stehen für viele Geräte-Typen bereits Vorlagen zur Verfügung, siehe [[AttrTemplate|attrTemplate]], die einem die wesentliche Konfigurationsarbeit abnehmen können, wie sie hier beschrieben ist. Die damit jeweils erzeugten Konfigurationen sind Einrichtungsbeispiele, die v.a. eine in sich konsistenze Zusammenstellung der verschiedenen Attribute enthalten. Es steht jedem User frei, diese Ausgangsbasis dann nach seinem Belieben zu ändern. Spätere Änderungen des verwendeten attrTemplate wirken sich nicht automatisch auf die durch frühere Versionen oder den User nachkonfigurierte Geräte aus! Da es vorkommen kann, dass sich die per MQTT übermittelten Daten und Topics ändern, wenn z.B. eine firmware aktualisiert wurden, kann dies Anpassungen am jeweiligen Template erforderlich machen. Grundsätzlich sollen die per attrTemplate für MQTT2_DEVICE verfügbaren attrTemplate jeweils für die aktuellste verfügbare stabile firmware-Version passen.}}

Das Modul [[MQTT2_DEVICE]] bietet eine Vielzahl von Möglichkeiten, auf die verschiedensten Anforderungen einzugehen, und die ein- und ausgehenden Daten zu einem oder mehreren FHEM-[[Gerät|Gerät/en]] zusammenzufassen. Eine Übersicht häufig vorkommender MQTT-Geräte ist in [[MQTT2-Module - Praxisbeispiele]] zu finden.

Ziel dieses Artikels ist die Darstellung der Schritte, die sich als zweckmäßig erwiesen haben zur Einrichtung von "guten" FHEM-Geräten.
{{Randnotiz|RNTyp=Info|RNText=Viele - teils komplexe Beispiele und weitere Verweise sind im {{Link2Forum|Topic=116162|LinkText=MQTT-Workshop für MQTT2-Module}} zu finden.}}Dabei soll am Ende erreicht werden:
* standardisierte set- (und ggf. get-)-Kommandos, insbesondere unter Beachtung der [[DevelopmentGuidelinesReadings| Developer Guidelines für Readings]]
* Schließen des Informationskreises von eventuellen Kommandos bis zur Rückmeldung des (externen) Gerätes oder Dienstes (im Folgenden: "Gegenstelle")
* standardisierte Reading-Namen, damit möglichst Auswertungen nicht speziell an das jeweilige Gerät angepasst werden müssen
* Reduzierung und Vermeidung von unnötigen Datenpunkten und Events
* Einrichten von regelmäßigen Abfrage-Timern (falls erforderlich!).

== Vorbereitung ==
=== MQTT2_SERVER ===
Selbst, wenn grundsätzlich ein externer MQTT-Server IO-Device zum Einsatz kommt, ist sehr zu empfehlen, für die Beschäftigung mit einem neuen, unbekannten Device zunächst einen {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} einzurichten. Ist der Port 1883 bereits belegt, nimmt man einfach einen anderen Port, z.B. 1884: <code>define m2server MQTT2_SERVER 1884 global</code>. Sollte die Gegenstelle tiefer strukturierte Daten im JSON-Format über verschiedene Topics als Payload übermittelt, kann es ausnahmsweise hilfreich sein, '''in der Einrichtungsphase''' auch das Attribut "autocreate" am MQTT2_SERVER auf "complex" zu stellen: <code>attr m2server autocreate complex</code>. Weiter muss die allgemeine [[Autocreate|autocreate-Instanz]] aktiv sein. Für den Regelbetrieb und für einfache, bekannte Devices (sowie für solche, für die bereits attrTemplate vorhanden sind), wird ausdrücklich empfohlen, das ''autocreate''-Atribut am m2server gar nicht erst zu setzten, dann wird ''autocreate'' mit der (default) Einstellung ''simple'' verwendet. Die Hintergründe sind nachfolgend im Abschnitt zu ''json2nameValue()'' zu finden.

=== Begrifflichkeiten ===
Ein typisches, von "autocreate" erstelltes Gerät sieht dann z.b. (mit autocreate = simple am MQTT2_SERVER) so aus:
<syntaxhighlight lang="text">
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/LWT:.* LWT\
DVES_9B01BD:tele/DVES_9B01BD/UPTIME:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/SENSOR:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO1:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO2:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO3:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/RESULT:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
</syntaxhighlight>
Wir unterscheiden bei jeder Zeile des readingList-Attributs vier Elemente, die ersten drei werden jeweils durch einen Doppelpunkt voneinander getrennt:
==== CID ====
Dies ist die Gerätekennung (hier: DVES_9B01BD). Diese ist auch Bestandteil des ''define'', über diese wird ermittelt, zu welchem FHEM-Gerät via MQTT eingehende Informationen zugeordnet werden sollen. Diese Angabe ist weder im define noch in der readingList zwingend, aber in der Definition für den Hauptkanal eines Gerätes empfohlen. Es empfiehlt sich, die CID-Angaben bei eigenen readingList-Einträgen wegzulassen bzw. diese zu löschen. So kann einfacher zwischen automatisch generierten und eigenen Angaben unterschieden werden und die Geräte sind leichter zwischen verschiedenen IO-Modulen zu verschieben.
==== Topic ====
Datenpunkt, an den eine Information gesendet wird. Empfangsseitig sind dies hier z.B. ''tele/DVES_9B01BD/STATE'' oder ''tele/DVES_9B01BD/LWT''.
Enthält der Topic Doppelpunkte oder Sonderzeichen, kann dies zu Problemen führen. Da der Topic intern als ''regex'' behandelt wird, kann man sich das in solchen Sonderfälle dadurch zu nutze machen, dass man z.B problematische Zeichen durch Punkte oder "beliebige Zeichenfolgen" ersetzt. So kann z.B. aus dem per autocreate erstellten <code>attr reader readingList SMLReader/Strom/sensor/1/obis/1-0:1.8.0/255/value:.* Strombezug_tariflos</code> folgendes abgeleitet werden: <code>attr reader readingList SMLReader/Strom/sensor/1/obis/1-0.1.8.0/255/value:.* Strombezug_tariflos</code>,

==== Payload ====
Der jeweilige Nachrichteninhalt. Da dieser nicht im vorhinein bekannt ist, wird er in der readingList typischerweise als "beliebige Zeichenfolge" (".*") notiert.

==== Auswertung ====
Dies kann entweder direkt der Reading-Name sein, dem die Payload zugeordnet werden soll, oder ein Perl-Ausdruck. Hier wird z.B. die eingehende Information für ''tele/DVES_9B01BD/LWT'' dem Reading ''LWT'' zugeordnet, während die Informationen aus ''tele/DVES_9B01BD/STATE'' an die Funktion ''json2nameValue()'' übergeben werden. ''$EVENT'' entspricht dabei der ''Payload''.

=== defaults ===
Für unbekannte Gegenstellen ist zunächst immer zu empfehlen, deren "Grundeinstellungen" zu verwenden, und Anpassungen erst und nur insoweit vorzunehmen, als es für ein besseres Zusammenspiel mit FHEM sinnvoll ist. Abzuraten ist insbesondere von:
* Änderungen der Topics und Topic-Sturkturen (ausgenommen den Fall, dass schon andere Gegenstellen im Einsatz sind, die identische Topics verwenden)
* Vergabe von ''friendly names''

== Bestandsaufnahme ==
=== Projektseiten finden ===
Viele Geräte, die das MQTT-Protokoll verwenden, haben eigene Projektseiten oder API-Beschreibungen, denen man entnehmen kann, wie mit dieser Gegenstelle Daten ausgetauscht werden können. Diese sollte man bei allen weiteren Schritten stets zur Hand haben. Dabei kann es neben der allgemeinen Beschreibung auch ein oder mehrere Detail-Seiten geben, auf denen nähere Informationen zu den spezifischen Geräte zu finden sein können.

=== MQTT - Datenverkehr mitlesen ===
Sowohl MQTT2_SERVER wie MQTT2_CLIENT bieten in der Detailansicht die Option ''Show MQTT traffic''. Darüber läßt sich der ein- und ausgehende Datenverkehr bequem mitlesen. Bei MQTT2_CLIENT wird dabei allerdings vorausgesetzt, dass er überhaupt Daten vom MQTT-Server erhält, also insbesondere die ''subscriptions'' korrekt gesetzt sind (falls per Attribut eingeschränkt).

=== readingList ===
Zunächst empfiehlt es sich, einfach die Gegenstelle neu zu starten und (ggf. über ein FileLog) aufzuzuzeichnen, was über welchen Topic wie oft an Informationen gesendet wird. Dabei kann und sollte durchaus - sofern dies möglich ist - der eine oder andere Schaltvorgang (z.B. über das Web-Interface der Gegenstelle) durchgeführt werden, sofern dies möglich ist (oder allgemeiner: möglichst viele bekannte Anweisungen ausführen lassen). Am Ende sollte man eine möglichst vollständige Auflistung in der readingList erhalten haben.
Falls strukturierte Daten im JSON-Format als Payload verwendet werden, kann man diese auch zusätzlich ohne die Verarbeitung durch ''json2nameValue()'' aufzeichnen, z.B. indem man die betreffende Zeile in der readingList doppelt:
<syntaxhighlight lang="text">
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
attr MQTT2_DVES_9B01BD readingList tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\
tele/DVES_9B01BD/STATE:.* json_STATE\
tele/DVES_9B01BD/LWT:.* LWT\
[...]
</syntaxhighlight>
So kann man mit Hilfe des betreffenden Logs ggf. auch über ein externes Tool wie mosquitto_pub MQTT-Nachrichten an FHEM generieren, ohne darauf warten zu müssen, dass diese von der Gegenstelle selbst erzeugt werden.

=== ignoreRegexp ===
Manche Gegenstellen senden beim Start Konfigurationsinformationen, die allerdings nicht durch FHEM ausgewertet werden können. Die betreffenden Topics sollte man (allgemein) so in die ignoreRegexp beim MQTT2_SERVER bzw. [[MQTT2_CLIENT]] aufnehmen, dass derartige Informationen künftig gar nicht mehr an MQTT2_DEVICE weitergereicht werden. Danach kann man die betreffenden Zeilen aus der readingList löschen! Entsprechendes gilt für die hierüber generierten Readings.

Weiter ist zu empfehlen, in diese ignoreRegexp auch die Topics aufzunehmen, über die Gegenstellen typischerweise Kommandos entgegennehmen. Dies könnte z.B. so aussehen:
<code>attr m2server ignoreRegexp shellies/[^/]+/command|cmnd/[^/]+/|homeassistant/.*/config|tasmota/discovery</code>

=== Viele Geräte? ===
==== "split" ====
Sind auf einer Hardware mehrere "Hauptschalter" vorhanden (z.B. ein Relay-Board), ist sehr zu empfehlen, für jeden dieser "Hauptschalter" ein eigenes FHEM-Gerät anzulegen (für logische Einheiten wie Rollladenaktoren ggf. paarweise). MQTT2_DEVICE unterstützt [[DevelopmentModuleAPI#SetExtensions|SetExtensions]] und kann daher Kommandos wie "on-for-timer" über FHEM-interne Mechanismen gut umsetzen. Dies erfordert allerdings, dass die Kommandos "on" und "off" verfügbar sein müssen.
Wird ein Gerät gesplittet, sollten im Gerät, das den ersten (Haupt-) Kanal repräsentiert dann alle Kommunikationsdaten gebündelt werden, Querverweise zu den weiteren Kanälen kann man über das spezielle Readings "associatedWith" herstellen.

==== bridgeRegexp ====
{{Randnotiz|RNTyp=Info|RNText=Manche derartige Interfaces müssen zunächst entsprechend konfiguriert werden, dass die zu einem Sensor oder Aktor gehörenden Daten jeweils auf einem eigenen Topic ausgegeben werden. Insbesondere ist dies bei Tasmota (ZigBee oder Bluetooth) der Fall!}}
In eher seltenen Fällen kommt es vor, dass eine Gegenstelle eine Art "Brücke" zu einer Mehrzahl über diese Brücke anzusteuernder (oder zu empfangender) Aktoren oder Sensoren darstellt. In diesen Fällen kann es geboten sein, die eigentliche Gegenstelle als Hauptdevice darzustellen und für jede weitere Hardware (Sensor oder Aktor) dann ein oder mehrere Einzeldevices anzulegen. Dies kann mit Hilfe des Attributs bridgeRegexp automatisiert erfolgen, wenn sich der Sensor/Aktor aus der Topic-Struktur ablesen läßt.

== readingList optimieren==
=== gute Reading-Namen - Klartext ===
Viele Gegenstellen senden z.B. einen online/offline-Status als "last will and testament" unter einem Topic, der mit "LWT" endet. Dieses hier sendet zwar passende Daten, aber an einen anderen Topic. In solchen Fällen man kann den von autocreate erzeugten Eintrag einfach anpassen:
attr DEVICE readingList /dingtian/DEVNAME/out/lwt_availability:.* LWT

=== Bedingte Hash-Rückgaben ===
Manchmal erfolgt zwar die Übergabe eines Klartextes als $EVENT - allerdings nicht in der Form, wie man das in FHEM gerne hätte. Hier als "0" oder "1". Mit etwas Perl und der Rückgabe eines Hashes kann man so etwas beliebig umformen:
attr DEVICE readingList DEVNAME/relay/0:.* { $EVENT ? {state=>'on'} : {state=>'off'} }\
DEVNAME/status:.* { $EVENT ? {LWT=>'Online'} : {LWT=>'Offline'} }
Weiteres Beispiel: Der "state" kommt in Großschreibung und soll in Kleinschreibung geändert werden:
attr DEVICE readingList switchbot/esp32_2/bot/switchbottwo/state:.* { { state => lc $EVENT } }

=== json2nameValue() ===
Mit Hilfe der Funktion json2nameValue() (in Verbindung mit dem attribut ''jsonMap'') lassen sich
* "gute Reading-Namen" auch aus JSON-Payloads erzeugen (2. und 3. Argument)
* unnötige Readings vorab ausfiltern (3., 4. und 5. Argument)
Beispiele für die Verwendung der Argumente 1 bis 3 sind der commandref in der Erläuterung des Attributs ''jsonMap'' bei MQTT2_DEVICE zu entnehmen, die (wie die Argumente 2 und 3 optionalen) Argumente 4 und 5 entsprechen einem Positiv- bzw.- Negativ-Filter, gefiltert wird, wenn die jeweils übergebene regexp matcht (5. Argument) bzw. nicht matcht (4. Argument).
Wird (übergangsweise!) ''autocreate'' in der ''complex''-Variante eingestellt, werden für alle (bisher nicht bekannten) Topics Einträge wie dieser erzeugt:
attr MQTT2_DVES_9B01BD readingList tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT,'STATE_',$JSONMAP) }
* Das zweite Argument (''STATE_'') ist ein "Präfix", der allen aus dem JSON erzeugten Readings aus diesem Topic (zunächst) vorangestellt wird. Mit dessen Hilfe läßt sich rekonsturieren, aus welchem Topic die betreffende Information ursprünglich kam. In der Regel ist dies nach der Einrichtung nicht mehr wichtig, und dieses Argument kann auf "nichts" (zwei einfache Quotes) gestellt werden. Allerdings kann es in Einzelfällen sinnvoll sein, Präfixe zu verwenden, um zwischen scheinbar gleichen Werte aus unterschiedlichen Quellen zu unterscheiden. Dies kann man erst abschließend entscheiden, wenn alle von der Gegenstelle gelieferten Daten bekannt sind.
* Das dritte Argument ''$JSONMAP'' kann in der Regel so belassen werden. Dann kann mit Hilfe des Attributs ''jsonMap'' eine Zuordnungstabelle für Namensänderungen für die zu generierenden Readingnamen erzeugt und/oder Werte schlicht gelöscht werden.

=== Auswertung unterbinden ===
Indem man einen Perl-Aufruf festlegt (geschweifte Klammern), dieser aber nichts zurückgibt, kann man bestimmte unerwünschte Readings ausfiltern. Im einfachsten Fall wäre dies:
shellies/DEVNAME/temperature_f:.* {}

Komplexer mit Auswertung der Payload:
STATTOPIC/RESULT:.* { $EVENT =~ m{HSBColor...(\d+),(\d+),(\d+)} ? $2 eq ReadingsVal($NAME,'saturation','unknown') ? return : { saturation=>$2 } : return }

=== Perl ===
Wie am Beispiel der speziellen Funktion <code>json2nameValue()</code> sowie der Hash-Rückgabe bereits dargestellt, ist es möglich, bei der Auswertung auch Perl-Funktionen einzusetzen, und diverse Variablen an diese zu übergeben. Ebenso ist es möglich, eigenen Perl-Code zu verwenden, der z.B. dann längere Zuordnungstabellen, Event-Reduzierungsmechanismen, ... enthalten kann.

== Events optimieren==
Leider senden relativ viele Gegenstellen in ihren Standardeinstellungen sehr viele Daten, auch ohne dass sich etwas geändert hätte. Dies erzeugt uU. in FHEM eine erhebliche Last, so dass es dringend zu empfehlen ist, alle Maßnahmen zu prüfen, durch die dieses Verhalten unterbunden oder vermindert werden kann. Dabei sollte möglichst frühzeitig eingegriffen werden, entsprechend den folgenden Handlungsoptionen: Daten, die die firmware gar nicht erst sendet, muss FHEM nicht am Interface-Modul entgegennehmen. Daten, die direkt am Interface-Modul verworfen werden (ignoreRegexp), muss das Client-Modul nicht auswerten. Readings, die man (an einem bestimmten Device) nicht benötigt, sollte man nicht erzeugen, damit keine [[Eventhandler]] aktiv werden müssen, unveränderte, aber gewünschte Daten müssen nicht unbedingt (immer) Events erzeugen.

=== firmware-Einstellungen ===
Bei manchen firmwares kann man einstellen, ob bzw. wie oft oder aus welchem Anlass Daten gesendet werden sollen. Es wird dringlich empfohlen, bei "gesprächigen" Gegenstellen zu recherchieren, ob und in welcher Weise diese derartige Möglichkeiten bietet. Falls solche nicht vorhanden sind, lohnt es sich, auf den betreffenden Projektseiten nachzufragen, ob es diese Optionen gibt - nicht selten hat sich ein firmware-Autor darüber schlicht noch keine Gedanken gemacht und baut in der nächsten Version ggf. entsprechende Optionen ein?

=== Auswertung unterbinden ===
(s.o. für Topics/Readings, die gar nicht benötigt werden). Dies ist insbesondere auch zu empfehlen, wenn identische Daten zum gleichen Zeitpunkt sowohl als Klartext wie auch in einem JSON-Format übermittelt werden. In solchen Fällen ist es eher zu empfehlen, die JSON-Zweige zu abonnieren und den Rest (ggf. über einen ignoreRegexp-Eintrag) gar nicht auszuwerten.
Doppelungen sollten in jedem Fall vermieden werden!
Grundsätzlich erzeugt jeder Topic eine eigene Event-Loop, mehrere Readings-updates, die aus einer einzigen JSON-Payload abgeleitet werden, erzeugen dagegen eine gemeinsame Event-Loop. Durch solche Maßnahmen läßt sich die Systembelastung deutlich reduzieren.
Für Daten aus JSON-Payloads besteht darüber hinaus die Möglichkeit, diese komplett auszufiltern (siehe jsonMap weiter oben)

=== event-on-change-reading und Co. ===
Da die firmwares häufig recht gesprächig programmiert sind, sollte man auf eine sinnvolle Begrenzung der durch Aktualisierungen verursachten Events besonderen Wert legen. Dazu ist in erster Linie das Attribut [[Event-on-change-reading|event-on-change-reading]] zu bearbeiten und ggf. passende threshold-Werte zu setzen, es empfiehlt sich allerdings, dabei auch zu untersuchen, inwieweit die weiteren, funktional ergänzenden Attribute zu setzen sind:
* [[Event-min-interval|event-min-interval]]
* [[Event-on-update-reading|event-on-update-reading]]
* timestamp-on-change-reading und
* [[Event-aggregator|event-aggregator]]

=== gute Reading-Namen - userReadings ===
Manchmal werden per MQTT Werte übersendet, die so nicht direkt verwendbar sind. Beispiele hierfür wären:
* Batteriespannungen in mV (z.B. bei zigbee2mqtt)
* Farbwerte als Einzelreading (für die Anzeige in FHEM wird aber ein RGB-Wert benötigt)
In diesen Fällen kann man zwar nicht ohne weiteres den Ausgangswert umrechnen lassen, (über externe Module wie readingsChange sehr wohl), aber es ist über den Weg "userReadings" ohne weiteres möglich, passende Readings zu generieren. Dabei sollte aber zur Verringerung der Systembelastung allgemein sowie ggf. falscher Ergebnisse unbedingt darauf geachtet werden, dass diese auch mit einer ''trigger''-Angabe versehen sind!

== setList ==

=== Allgemeines ===
Die setList ist dazu gedacht, Kommandos zu definieren, welche an die Gegenstelle gesendet werden können.

=== Syntax ===
In der Regel besteht jede Zeile aus folgenden, per Leerzeichen getrennten Argumenten:
* einem setter-Namen, ggf. ergänzt durch ein widget (s.u.)
* einem Topic, unter dem die Payload gesendet werden soll und
* der Payload.
Es können diverse Variablen genutzt werden, u.A. auch $EVENT und $EVTPARTx-Elemente, die der Rückgabe (setter-Name und ggf. gesetzter Wert) aus dem jeweiligen "widget" entsprechen.

=== on und off ===
Damit die weitergehenden Befehle wie ''on-for-timer'' aus den [[DevelopmentModuleIntro#X_Set|SetExtensions]] funktionieren, muss ein MQTT2_DEVICE die Befehle "on" und "off" kennen. Diese sollten also - wenn es eine Art "Hauptschalter" gibt - gesondert für diesen Hauptschalter angegeben werden.
Hat ein Gerät mehrerer solcher "Hauptschalter", empfiehlt es sich, für jeden dieser Schalter eine eigene MQTT2_DEVICE-Instanz anzulegen.

==== setStateList ====
Gibt es in einem Device neben dem "Hauptschalter" weitere setzbare Readings (z.B. für Helligkeit und Farbe oder eine Temperatur), empfiehlt es sich v.a. dann, wenn das Gerät den Empfang (bzw. die Ausführung) von Befehlen bestätigt, nur die auf den jeweiligen Hauptschalter bezogenen ''set''-Anweisungen in ''state'' zu schreiben. Diese (z.B. on, off und toggle) wären dann in das ''setStateList''-Attribut aufzunehmen.

==== setExtensionsEvent ====
Will man per SetExtensions realisierte laufende Timer visualisieren, empfiehlt es sich, dieses Attribut zu setzen.

=== widgets ===
In der setList können prinzipiell alle in [[FHEMWEB/Widgets|Widgets]] dargestellten Eingabemöglichkeiten verwendet werden.

=== Perl-Kommandos ===
Eigentlich ist die setList dazu gedacht, eine publish-Anweisungen über das IODev abzusetzen. Da aber generisch auch Perl-Code aufgerufen werden kann, ist dies nicht zwingend, so dass zum einen aus Perl heraus auch mehrfach-Publishes ebenso möglich sind wie beliebige "fhem"-Kommandos, die gar nichts mit MQTT zu tun haben müssen (z.B. das regelmäßige Löschen von evtl. veralteten Readings am betreffenden Gerät). Wird Text zurückgegeben, wird dies als "<topic> <payload>" interpretiert und dies gepublisht, erfolgt gar keine Rückgabe, unterbleibt dies.

== getList ==
Die getList ist dazu gedacht, asynchrone Abfragen an die Gegenstelle zu ermöglichen.
Die Syntax dabei ist
* einem getter-Namen, ggf. ergänzt durch ein widget (s.u.)
* Reading-Name, unter dem die Antwort erwartet wird
* einem Topic, unter dem die Payload gesendet werden soll und
* (optional) der Payload.
Auch hier können diverse Variablen genutzt werden, und/oder das ganze für die Ausführung von Perl-Code genutzt werden.

== periodicCmd ==
Für regelmäßige Aufgaben (mit mind. minütlicher Frequenz) kann eine Liste con get- oder set-Kommandos angegeben werden. Dies kann für regelmäßige Abfragen ebenso genutzt werden wie z.B. zum Löschen veralteter Informationen/Readings.

== Abschließende Aufgaben ==
Um das finale Aussehen des Gerätes zu beeinflussen, stehen dann noch die weiteren allgemeinen Attribute zur Verfügung, die in [[DeviceOverview anpassen]] beschrieben sind.

== Hinweise ==
<references />
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT]]

SetList

2023-10-28T13:10:23Z

F Klee: /* Einschränkungen */

{{SEITENTITEL:setList}} 


Das Attribut [[setList]] dient dazu, bei generischen Devices die Liste der möglichen set Kommandos zu spezifizieren.

{{Todo|Bitte analog zu [[eventMap]] mit Inhalt füllen.}}

== Syntax ==
Das ''setList'' Attribut wird in der folgenden Weise spezifiziert:
:<code><nowiki>attr <device> setList <Reading1>:⟨<Modifier1>,⟩<Value1>,<Value2>,<...> <Reading2>:⟨<Modifier2>,⟩<Value1>,<Value2>,<...> ...</nowiki></code>
Es ist auch möglich, zur Verbesserung der Übersichtlichkeit und Lesbarkeit, das setList Attribut mehrzeilig zu formulieren.

== Einschränkungen ==
Dieses Attribut existiert nur bei [[DOIF]]-, [[dummy]]-, [[MSwitch]]- und [[readingsProxy]]-Devices.
[[MQTT2 DEVICE]] nutzt setList um Änderungen an State bzw. Readings an den Server zu übermitteln, der diese dann an die eigentlichen Geräte weitergibt oder dort vorhält. Für jedes Reading ist eine eigene Zeile erforderlich, das Aussehen in der Detailansicht des Geräts kann direkt über eine entsprechende widget-Definition vorgenommen werden.

== Beispiele ==

In diesem ersten Beispiel wird der ''state'' als Schiebebalken (slider) angezeigt. Wobei die erste Zahl den niedrigsten möglichen Wert angibt. Die zweite den Wert, um den jeweils erhöht wird. Und die dritte den maximal möglichen Wert.
define Raumtemperatur dummy
attr Raumtemperatur setList :slider,10,0.5,30

Hier wird für den ''state'' eine Uhrzeit angegeben. Die kann mit zwei Schiebebalken (einer für die Stunden, einer für die Minuten) gesetzt werden.
define Wecker_Uhrzeit dummy
attr Wecker_Uhrzeit setList :time

Möchte man Farbwerte einstellen, kann man ''colorpicker'' verwenden. Damit kann dann auf einer Palette eine Farbe gewählt werden.
define Farbe dummy
attr Farbe setList :colorpicker

define Wecker_Uhrzeit dummy
attr Wecker_Uhrzeit setList state:AUS,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:35,06:40,06:45,06:50,06:55,07:00,07:05,07:10,07:15,07:20,07:25,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45
attr Wecker_Uhrzeit readingList state
attr Wecker_Uhrzeit webCmd state

define Beschattung_auto dummy
attr Beschattung_auto setList state:aktiv,passiv
attr Beschattung_auto readingList state
attr Beschattung_auto webCmd state

define Heizungsmodus dummy
attr Heizungsmodus setList state:auto,FHEM,Frostschutz,AUS
attr Heizungsmodus readingList state
attr Heizungsmodus webCmd state

define TV_ProgrammKanal dummy
attr TV_ProgrammKanal setList ARD_Ch ZDF_Ch HR_Ch RTL_Ch Sat1_Ch VOX_Ch Pro7_Ch Kabel1_Ch COMEDYCENTRAL_Ch DREISAT_Ch ARTE_Ch EINSPLUS_Ch EINSFESTIVAL_Ch ZDFNEO_Ch NDR_Ch MDR_Ch BR_Ch RBB_Ch SWR_Ch WDR_Ch RTL2_Ch SUPERRTL_Ch SPORT1_Ch EUROSPORT_Ch DMAX_Ch N24_Ch NTV_Ch RTLNITRO_Ch SAT1GOLD_Ch SIXX_Ch TELE5_Ch
attr TV_ProgrammKanal readingList state

define benzinpreis dummy
attr benzinpreis readingList SuperE5_2 SuperPlus_2
attr benzinpreis setList SuperE5_2:slider,140,1,200 SuperPlus_2:slider,140,1,200
attr benzinpreis stateFormat SuperE5, SuperPlus
attr benzinpreis userReadings SuperE5 {(ReadingsVal("oil","SuperE5_2",0) / 100 )}, SuperPlus {(ReadingsVal("oil","SuperPlus_2",0) / 100 )}
attr benzinpreis webCmd SuperE5_2:SuperPlus_2

== Links ==
* Ausführliche Beschreibung (mit Beispielen) zu [[eventMap]], [[devStateIcon]], setList und [[webCmd]] in {{Link2Forum|Topic=12080|LinkText=diesem Forenthread}}

[[Kategorie:Attribut (allgemeingültig)]]

SetList

2023-10-28T13:03:50Z

F Klee: /* Syntax */

{{SEITENTITEL:setList}} 


Das Attribut [[setList]] dient dazu, bei generischen Devices die Liste der möglichen set Kommandos zu spezifizieren.

{{Todo|Bitte analog zu [[eventMap]] mit Inhalt füllen.}}

== Syntax ==
Das ''setList'' Attribut wird in der folgenden Weise spezifiziert:
:<code><nowiki>attr <device> setList <Reading1>:⟨<Modifier1>,⟩<Value1>,<Value2>,<...> <Reading2>:⟨<Modifier2>,⟩<Value1>,<Value2>,<...> ...</nowiki></code>
Es ist auch möglich, zur Verbesserung der Übersichtlichkeit und Lesbarkeit, das setList Attribut mehrzeilig zu formulieren.

== Einschränkungen ==
Dieses Attribut existiert nur bei [[DOIF]]-, [[dummy]]-, [[MSwitch]]- und [[readingsProxy]]-Devices.

== Beispiele ==

In diesem ersten Beispiel wird der ''state'' als Schiebebalken (slider) angezeigt. Wobei die erste Zahl den niedrigsten möglichen Wert angibt. Die zweite den Wert, um den jeweils erhöht wird. Und die dritte den maximal möglichen Wert.
define Raumtemperatur dummy
attr Raumtemperatur setList :slider,10,0.5,30

Hier wird für den ''state'' eine Uhrzeit angegeben. Die kann mit zwei Schiebebalken (einer für die Stunden, einer für die Minuten) gesetzt werden.
define Wecker_Uhrzeit dummy
attr Wecker_Uhrzeit setList :time

Möchte man Farbwerte einstellen, kann man ''colorpicker'' verwenden. Damit kann dann auf einer Palette eine Farbe gewählt werden.
define Farbe dummy
attr Farbe setList :colorpicker

define Wecker_Uhrzeit dummy
attr Wecker_Uhrzeit setList state:AUS,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:35,06:40,06:45,06:50,06:55,07:00,07:05,07:10,07:15,07:20,07:25,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45
attr Wecker_Uhrzeit readingList state
attr Wecker_Uhrzeit webCmd state

define Beschattung_auto dummy
attr Beschattung_auto setList state:aktiv,passiv
attr Beschattung_auto readingList state
attr Beschattung_auto webCmd state

define Heizungsmodus dummy
attr Heizungsmodus setList state:auto,FHEM,Frostschutz,AUS
attr Heizungsmodus readingList state
attr Heizungsmodus webCmd state

define TV_ProgrammKanal dummy
attr TV_ProgrammKanal setList ARD_Ch ZDF_Ch HR_Ch RTL_Ch Sat1_Ch VOX_Ch Pro7_Ch Kabel1_Ch COMEDYCENTRAL_Ch DREISAT_Ch ARTE_Ch EINSPLUS_Ch EINSFESTIVAL_Ch ZDFNEO_Ch NDR_Ch MDR_Ch BR_Ch RBB_Ch SWR_Ch WDR_Ch RTL2_Ch SUPERRTL_Ch SPORT1_Ch EUROSPORT_Ch DMAX_Ch N24_Ch NTV_Ch RTLNITRO_Ch SAT1GOLD_Ch SIXX_Ch TELE5_Ch
attr TV_ProgrammKanal readingList state

define benzinpreis dummy
attr benzinpreis readingList SuperE5_2 SuperPlus_2
attr benzinpreis setList SuperE5_2:slider,140,1,200 SuperPlus_2:slider,140,1,200
attr benzinpreis stateFormat SuperE5, SuperPlus
attr benzinpreis userReadings SuperE5 {(ReadingsVal("oil","SuperE5_2",0) / 100 )}, SuperPlus {(ReadingsVal("oil","SuperPlus_2",0) / 100 )}
attr benzinpreis webCmd SuperE5_2:SuperPlus_2

== Links ==
* Ausführliche Beschreibung (mit Beispielen) zu [[eventMap]], [[devStateIcon]], setList und [[webCmd]] in {{Link2Forum|Topic=12080|LinkText=diesem Forenthread}}

[[Kategorie:Attribut (allgemeingültig)]]

SetList

2023-10-28T12:59:57Z

F Klee: /* Syntax */

{{SEITENTITEL:setList}} 


Das Attribut [[setList]] dient dazu, bei generischen Devices die Liste der möglichen set Kommandos zu spezifizieren.

{{Todo|Bitte analog zu [[eventMap]] mit Inhalt füllen.}}

== Syntax ==
Das ''setList'' Attribut wird in der folgenden Weise spezifiziert:
:<code><nowiki>attr <device> setList <Reading1>:⟨<Modifier1>,⟩<Value1>,<Value2>,<...> <Reading2>:⟨<Modifier2>,⟩<Value1>,<Value2>,<...> ...</nowiki></code>

== Einschränkungen ==
Dieses Attribut existiert nur bei [[DOIF]]-, [[dummy]]-, [[MSwitch]]- und [[readingsProxy]]-Devices.

== Beispiele ==

In diesem ersten Beispiel wird der ''state'' als Schiebebalken (slider) angezeigt. Wobei die erste Zahl den niedrigsten möglichen Wert angibt. Die zweite den Wert, um den jeweils erhöht wird. Und die dritte den maximal möglichen Wert.
define Raumtemperatur dummy
attr Raumtemperatur setList :slider,10,0.5,30

Hier wird für den ''state'' eine Uhrzeit angegeben. Die kann mit zwei Schiebebalken (einer für die Stunden, einer für die Minuten) gesetzt werden.
define Wecker_Uhrzeit dummy
attr Wecker_Uhrzeit setList :time

Möchte man Farbwerte einstellen, kann man ''colorpicker'' verwenden. Damit kann dann auf einer Palette eine Farbe gewählt werden.
define Farbe dummy
attr Farbe setList :colorpicker

define Wecker_Uhrzeit dummy
attr Wecker_Uhrzeit setList state:AUS,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:35,06:40,06:45,06:50,06:55,07:00,07:05,07:10,07:15,07:20,07:25,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45
attr Wecker_Uhrzeit readingList state
attr Wecker_Uhrzeit webCmd state

define Beschattung_auto dummy
attr Beschattung_auto setList state:aktiv,passiv
attr Beschattung_auto readingList state
attr Beschattung_auto webCmd state

define Heizungsmodus dummy
attr Heizungsmodus setList state:auto,FHEM,Frostschutz,AUS
attr Heizungsmodus readingList state
attr Heizungsmodus webCmd state

define TV_ProgrammKanal dummy
attr TV_ProgrammKanal setList ARD_Ch ZDF_Ch HR_Ch RTL_Ch Sat1_Ch VOX_Ch Pro7_Ch Kabel1_Ch COMEDYCENTRAL_Ch DREISAT_Ch ARTE_Ch EINSPLUS_Ch EINSFESTIVAL_Ch ZDFNEO_Ch NDR_Ch MDR_Ch BR_Ch RBB_Ch SWR_Ch WDR_Ch RTL2_Ch SUPERRTL_Ch SPORT1_Ch EUROSPORT_Ch DMAX_Ch N24_Ch NTV_Ch RTLNITRO_Ch SAT1GOLD_Ch SIXX_Ch TELE5_Ch
attr TV_ProgrammKanal readingList state

define benzinpreis dummy
attr benzinpreis readingList SuperE5_2 SuperPlus_2
attr benzinpreis setList SuperE5_2:slider,140,1,200 SuperPlus_2:slider,140,1,200
attr benzinpreis stateFormat SuperE5, SuperPlus
attr benzinpreis userReadings SuperE5 {(ReadingsVal("oil","SuperE5_2",0) / 100 )}, SuperPlus {(ReadingsVal("oil","SuperPlus_2",0) / 100 )}
attr benzinpreis webCmd SuperE5_2:SuperPlus_2

== Links ==
* Ausführliche Beschreibung (mit Beispielen) zu [[eventMap]], [[devStateIcon]], setList und [[webCmd]] in {{Link2Forum|Topic=12080|LinkText=diesem Forenthread}}

[[Kategorie:Attribut (allgemeingültig)]]

VALVES

2023-05-20T14:23:19Z

F Klee: Link zum Support-Thread hinzu gefügt

{{Infobox Modul
|ModPurpose=Durchschnitt mit individueller Gewichtung und Ignore

|ModType=x

|ModForumArea=codeschnipsel
|ModTechName=39_VALVES.pm
|ModOwner=epsrw1,cwagner}}
[[VALVES]] bietet eine einfache Möglichkeit, den nach flexibel konfigurierbaren Regeln gewichteten Durchschnittswert einer Gruppe von Werten zu berechnen.

== Features ==
<u>Diese Wiki-Seite beschreibt den Versionsstand 1.0 des VALVES-Moduls.</u>

Die Namensgebung beruht auf der primären Anwendung des Moduls auf Valve-Position-Readings von Heizungsthermostaten.

Thread im Forum:{{Link2Forum|Topic=24658|Message=177528}}

== Beschreibung ==
[[Datei:dok39_VALVES.jpg|mini|Funktionsweise]]

VALVES bietet als kleines Helferlein die Möglichkeit, einen halbwegs sinnvollen und individuell gewichteten Durchschnittswert der Readings mehrerer verschiedener Devices zu berechnen.

Für jeden Wert einzeln kann ein Offset definiert werden. Es können dynamisch jeweils die höchsten/niedrigsten 0 bis 3 Werte ignoriert werden. Eine weitere Einstellung ermöglicht, bestimmte Werte doppelt zu zählen.

''Im Anwendungsbeispiel [[Raumbedarfsabhängige Heizungssteuerung]] wird das Modul zum Beispiel verwendet, um den Durchschnittswert der Ventilöffnungen aller Heizkörper zu berechnen. Die individuelle Gewichtung über Attr ermöglicht hierbei einen virtuellen hydraulischen Abgleich.''

Die Liste aller auszulesenden Devices wird in einem ATTR eingestellt, der Name des Readings in einem weiteren. Das Modul prüft dann regelmäßig (attr: poll interval) die Daten der FHEM-Devices und berechnet neu, wenn ein Änderung festgestellt wird.

Für die Beeinflussung des Durchschnittes hat man folgende Attribute:

* ignoriere niedrigste 0...3 Positionen

* ignoriere höchste 0...3 Positionen

* ignoriere namentlich genannte Devices

* priority-device Liste (zählen doppelt)

* valves<Devicename>Gewichtung optionale Einzeleinstellung für jedes Reading, multipliziere mit Attr-Wert (zB:0,95 um 5% abzuziehen). Damit können Unterschiede bekannte gleichbleibende Meßungenauigkeiten kompensiert werden, oder verschieden große Geräte in vergleichbare Rechengrößen konvertiert werden.

== Define ==
:<code>define <name> VALVES </code>

== Attribute ==
Alle Attribute sind auch in FHEM durch das Kommando get attrHelp <varname> erklärt, fürs "schnelle Nachschauen zwischendurch".

valvesInitialDelay -> Startverzögerung

valvesPollInterval -> Berechnungsfrequenz

valvesDeviceList -> '''Pflicht-Attr''', Liste Thermostate mit valve-pos Readings

valvesDeviceReading -> '''Pflicht-Attr''', Bezeichnung valve-pos Reading

valvesIgnoreLowest -> Niedrigste N Werte ignorieren

valvesIgnoreHighest -> Höchste N Werte ignorieren

valvesIgnoreDeviceList -> Device(s) die komplett ignoriert werden, z.B. temporärer Eintrag für Gästezimmer

valvesPriorityDeviceList -> Devices, die doppelt gezählt werden

valves<Devicename> Gewichtung -> Faktor für einzelnes Device für individuelle Gewichtung

== Settings ==
reset -> Alle Readings zurücksetzen

== Readings ==
state -> Fehlermeldung oder Mittelwert nach oben beschriebener Berechnung

valve_<Devicename> -> Berechnete virtuelle Ventilstellung pro Gerät

valveDetail_<Devicename> -> Debug-Info mit Details

raw_average -> Simpler Mittelwert ohne Berücksichtigung der Gewichtungen (ignores werden auch hier ignoriert)

valve_average -> Mittelwert nach oben beschriebener Berechnung

valve_max -> Größte aktuelle Ventilöffnung seit letztem Reset

valve_min -> Kleinste aktuelle Ventilöffnung seit letztem Reset

== Weblinks ==
* {{Link2Forum|Topic=24658|Message=177528}} Thread im Forum, in dem dieses Modul vorgestellt wurde
* {{Link2Forum|Topic=131849|Message=0}} Support-Thread
* ...

[[Kategorie:Regelungstechnik]]
[[Kategorie:Heizungssteuerung]]

OpenWB

2023-04-05T06:40:56Z

F Klee: Zur Kategorie "HOWTOS" hinzu gefügt

== Integration der openWB in FHEM - Ladeleistung anzeigen und Umschalten des Lademodus ==
Ausgangssituation ist ein funktionierendes FHEM, ohne weitere Vorbedingungen.<syntaxhighlight lang="perl">
defmod openwb MQTT <openWBip>:1883
attr openwb room Auto,MQTT

</syntaxhighlight>Dadurch wird der MQTT-Server der openWB angesprochen, FHEM ist der Client.

Ein Ladepunkt wird als MQTT_Device angelegt:<syntaxhighlight lang="perl">
defmod lp1 MQTT_DEVICE
attr lp1 IODev openwb
attr lp1 publishSet_chargeMode openWB/set/ChargeMode
attr lp1 room Auto,Dashboard,MQTT
attr lp1 stateFormat power
attr lp1 subscribeReading_chargeMode openWB/global/ChargeMode
attr lp1 subscribeReading_plugStat openWB/lp/1/boolPlugStat
attr lp1 subscribeReading_power openWB/lp/1/W
</syntaxhighlight>Die Umsetzung basiert auf openWB 1.9.x, der Lademodus "ChargeMode" gilt hier noch global für alle Ladepunkte.

Beispielhaft die Definition des zweiten Ladepunktes, eine zweite openWB, die als "nur Ladepunkt" mit der angesprochenen openWB verbunden ist.

Eine openWB kann derzeit 8 Ladepunkte verwalten, die Nummern müssen entsprechend inkrementiert werden.<syntaxhighlight lang="perl">
defmod lp2 MQTT_DEVICE
attr lp2 IODev openwb
attr lp2 publishSet_chargeMode openWB/set/ChargeMode
attr lp2 room Auto,Dashboard,MQTT
attr lp2 stateFormat power
attr lp2 subscribeReading_chargeMode openWB/global/ChargeMode
attr lp2 subscribeReading_plugStat openWB/lp/2/boolPlugStat
attr lp2 subscribeReading_power openWB/lp/2/W
</syntaxhighlight>Die MQTT-Topics zum Lesen und Schreiben von Werten sind ganz unten auf dieser Wiki-Seite zu finden.

Die Einbindung in die TabletUI sieht bei mir so aus:
[[Datei:Ladepunkte in TabletUI.png|alternativtext=Darstellung der openWB Ladepunkte in der TabletUI|mini|488x488px|Beispielhafte Darstellung in der TabletUI]]
[[Datei:Auswahl des Lademodus.png|alternativtext=Darstellung der openWB Ladepunkte in der TabletUI - Auswahl des Lademodus|mini|486x486px|Auswahl des Lademodus per CircleMenu]]
<syntaxhighlight lang="html">
<div class="cell-60 left-space right-space">
<div data-type="symbol" data-icon="fa-car" class="tall compressed" data-color="lightgray">
<div data-type="circlemenu" data-direction="full" class="mini" style="top: -0.5em;">
<ul class="mini">
<li><div data-type="push" data-device="lp1" data-get="chargeMode" data-states='[0,1,2,3,4]' data-colors='["lightgreen","greenyellow","yellow","grey","black"]' data-icons='["fa-bolt","fa-plus-circle","fa-sun-o","fa-pause-circle-o","fa-stop-circle-o"]' data-background-icon=""></div></li>
<li><div data-type="push" data-device="lp1" data-set="chargeMode" data-get="chargeMode" data-set-on="0" data-get-on="0" data-icon="fa-bolt" data-color="lightgreen" data-background-icon=""></div></li>
<li><div data-type="push" data-device="lp1" data-set="chargeMode" data-get="chargeMode" data-set-on="1" data-get-on="1" data-icon="fa-plus-circle" data-color="greenyellow" data-background-icon=""></div></li>
<li><div data-type="push" data-device="lp1" data-set="chargeMode" data-get="chargeMode" data-set-on="2" data-get-on="2" data-icon="fa-sun-o" data-color="yellow" data-background-icon=""></div></li>
<li><div data-type="push" data-device="lp1" data-set="chargeMode" data-get="chargeMode" data-set-on="3" data-get-on="3" data-icon="fa-pause-circle-o" data-color="grey" data-background-icon=""></div></li>
<li><div data-type="push" data-device="lp1" data-set="chargeMode" data-get="chargeMode" data-set-on="4" data-get-on="4" data-icon="fa-stop-circle-o" data-color="black" data-background-icon=""></div></li>
</ul>
</div>
<div style="font-size: 30% !important;" class="mini " data-pre-text="" data-type="label" data-device="lp1" data-get="power" data-unit="" data-factor="1" data-fix="0"></div>
<div data-type="symbol" data-device="lp1" data-get="plugStat" data-states='[0,1]' data-colors='["white","black"]' data-icons='["","fa-plug"]' data-background-icon="" class="mini" style="font-size: 30% !important; top:1em;"></div></li>
</div>
</div>

</syntaxhighlight>

==Integration OpenWB in FHEM - Übertragung von EVU, PV und Batteriewerten an openWB==
Ausgangssituation ist ein funktionierendes FHEM-System, bei dem bereits der digitale Stromzähler ("Moderne Meßeinrichtung") über das Modul 47_OBIS und der PV-Wechselrichter über ein entsprechendes Modul, z.B. ModbusAttr integriert sind. Als OpenWB-System wurde hier eine reale OpenWB-Wallbox angebunden.

=== Datenquellen ===
Die OpenWB erwartet 1-3 Typen von Datenquellen in dieser Konstellation:
* Die ''EVU-''Schnittstelle, mit der als wesentlicher Steuerparameter der Ladeleistung die Leistungsmessung am Hausübergang herangezogen wird, und daneben die Zählerwerte für Netzbezug und Einspeisung zur Visualisierung übertragen werden sollten. Nur, falls phasenbezogenes Lastmanagement erforderlich sein sollte, sind auch die einzelnen Phasenleistungswerte vom Stromzähler nötig (was nicht jede Moderne Meßeinrichtung auf der OBIS-Schnittstelle bereitstellt)
* Die ''PV-''Schnittstelle, die ebenfalls primär visualisierende Bedeutung hat.
* Die ''Batteriespeicher-''Schnittstelle
OpenWB kann auch z.B. rein mit einer PV-Schnittstelle betrieben werden, in diesem Fall wird ein konstanter Leistungswert für den Hausbezug angenommen.

=== Kommunikationsprotokoll ===
Zur Kommunikation mit FHEM bieten sich 2 Methoden an:
* '''HTTP'''-Abfrage durch OpenWB bei FHEM durch das generische HTTP-Modul von OpenWB Diese Methode beschreibe ich nicht, weil sie mehr Overhead erzeugt und seitens FHEM die Einrichtung eines CSRF-Token-freien Web-Kanals erfordert
* '''MQTT'''-Push durch FHEM zur OpenWB Diese Methode erscheint mir vorteilhafter, weil auf einer stehenden TCP-Verbindung lediglich Meßwerte gepusht werden.

=== Implementierung ===

==== Vorbereitung ====
In der OpenWB-Web-UI unter Modulkonfiguration die entsprechenden Module (EVU, PV, Batterie) auf MQTT stellen. Hinweis: Nicht alle dabei erscheinenden MQTT-Topics müssen mit Werten beliefert werden! Sowohl bei der EVU-Schnittstelle wie bei PV reichen Momentanleistung und Zählerstände für eine zufriedenstellende Anbindung!

==== Definition der OpenWB als MQTT-Target ====
defmod openwb_mqtt MQTT2_CLIENT <ip-der-openwb>:1883
attr openwb_mqtt autocreate simple
attr openwb_mqtt subscriptions openWB/lp/1/#

==== Übertragung der EVU-Meßwerte ====
In diesem Beispiel heißt das die Stromzählerdaten liefernde Device am OBIS-Modul "MT175". Die Zahlen werden per Notify von diesem Device auf MQTT kopiert:
defmod openwb_evu_cons notify MT175:total_consumption:.* { fhem("set openwb_mqtt publish openWB/set/evu/WhImported " . $EVTPART1); }
defmod openwb_evu_feed notify MT175:total_feed:.* { fhem("set openwb_mqtt publish openWB/set/evu/WhExported " . $EVTPART1); }
defmod openwb_evu_w notify MT175:power:.* { fhem("set openwb_mqtt publish openWB/set/evu/W " . int($EVTPART1)); }

==== Übertragung der PV-Meßwerte ====
Sofern die Daten für Momentanleistung und Zählerstand direkt in einem Device vorliegen, können analoge Notifys für dieses Device implementiert werden. Die Zielwerte lauten:
* Für den Momentan-Leistungswert <code>openWB/set/pv/1/W</code>
* Für den Zählerstand <code>openWB/set/pv/1/WhCounter</code>
Dabei muss beachtet werden, dass - wie bei der EVU-Schnittstelle - nur Integerwerte für die Momentanleistung übertragen werden dürfen.

==== Anbindung an Alexa ====
Der generische Smarthome-Skill "FHEMConnector" erlaubt nur die leider immer noch sehr limitierte Syntax von Amazon Alexa. Im Folgenden werden die Definitionen für die Befehle:
* ''"Alexa, schalte Überschussladen ein"''
* ''"Alexa, schalte Überschussladen aus"''
* ''"Alexa, schalte Überschussladen auf 6 (Prozent)"''
dargestellt. "Überschussladen auf 6" bedeutet dabei real den "Min+PV", also Überschussladen mit Minimalleistung von 6 Ampere. Je nach Tagesform von Amazon ist dabei das Sprechen von "Prozent" nötig, auch wenn dies natürlich sachlich falsch ist.
define openwb_ueberschuss dummy
attr openwb_ueberschuss alexaName Überschussladen
attr openwb_ueberschuss genericDeviceType light
attr openwb_ueberschuss readingList pct
attr openwb_ueberschuss setList on off pct
define openwb_ueberschuss_on notify openwb_ueberschuss:on set openwb_mqtt publish openWB/set/ChargeMode 2
define openwb_ueberschuss_off notify openwb_ueberschuss:off set openwb_mqtt publish openWB/set/ChargeMode 3
define openwb_ueberschuss_pct notify openwb_ueberschuss:pct:.* set openwb_mqtt publish openWB/config/set/pv/minCurrentMinPv $EVTPART1 ;; set openwb_mqtt publish openWB/set/ChargeMode 1

==Anwendungs Beispiele==
===Komplexe Anbindung===
[[Bild:Kia.PNG|mini|700px|rechts|WallBox mit Kia Fahrzeug]]
Hier mal ein Beispiel mit weiteren Schnittstellen in der Haussteuerung. Im Hintergrund arbeitet ein Wechselrichter Schwarm mit einem Hausspeicher, der beim BEV Laden gesperrt wird. Die openWB kommuniziert direkt mit den zwei Kostal Wechselrichtern, dem KSEM und dem am Master angeschlossenen Speicher. Das BEV ist über Kia Connect angebunden.
[[Bild:WB_1.PNG|mini|700px|rechts|openWB mit Statistiken]]
[[Bild:Kostal Flow.PNG|mini|700px|rechts|Sowas könnte am Schluss, inklusive Wechselrichter, raus kommen. Die openWBs sind unten links.]]
====Verwendete Schnittstellen / Devices====
=====openWB MQTT=====
Wie oben beschrieben mit folgender MQTT definition. Im Bild ist das DOIF dargestellt und das MQTT Device als kurze Darstellung unterhalb der Tabelle. Das MQTT wird nur zur Kopplung verwendet, hat jedoch jetzt auch ein stateFormat inklusieve Statistiken erhalten.

RAW des MQTT Device
<syntaxhighlight lang="Perl">
defmod WB_1 MQTT2_DEVICE WB_1_MQTT2
attr WB_1 DbLogExclude .*
attr WB_1 DbLogInclude lp_1_.*,.*AllChargePoints.*,ChargeMode
attr WB_1 IODev WB_1_MQTT2
attr WB_1 alias WB_1
attr WB_1 autocreate 0
attr WB_1 comment Die openWB besteht aus zwei Ladepunkten.
attr WB_1 devicetopic openWB
attr WB_1 disable 0
attr WB_1 event-on-change-reading lp_1_.*,.*AllChargePoints.*,ChargeMode
attr WB_1 group PV Eigenverbrauch
attr WB_1 icon fuel
attr WB_1 readingList $DEVICETOPIC/global/WHouseConsumption:.* WHouseConsumption\
$DEVICETOPIC/global/WAllChargePoints:.* WAllChargePoints\
$DEVICETOPIC/global/ChargeMode:.* {my %h=(0=>'SofortLaden',1=>'MinPV',2=>'NurPV',3=>'Stop',4=>'Standby');; return {ChargeMode=>$h{$EVENT}}}\
\
$DEVICETOPIC/global/awattar/boolAwattarEnabled:.* boolAwattarEnabled\
$DEVICETOPIC/global/awattar/ActualPriceForCharging:.* ActualPriceForCharging\
$DEVICETOPIC/global/awattar/MaxPriceForCharging:.* MaxPriceForCharging\
$DEVICETOPIC/global/boolRse:.* boolRse\
$DEVICETOPIC/global/DailyYieldAllChargePointsKwh:.* DailyYieldAllChargePointsKwh\
$DEVICETOPIC/global/rfidConfigured:.* rfidConfigured\
$DEVICETOPIC/global/kWhCounterAllChargePoints:.* kWhCounterAllChargePoints\
$DEVICETOPIC/global/strLastmanagementActive:.* strLastmanagementActive\
$DEVICETOPIC/global/ETProvider/modulePath:.* modulePath\
$DEVICETOPIC/global/cpuTemp:.* cpuTemp\
\
$DEVICETOPIC/system/Uptime:.* Uptime\
$DEVICETOPIC/system/Date:.* Date\
$DEVICETOPIC/system/Timestamp:.* Timestamp\
$DEVICETOPIC/system/Version:.* Version\
$DEVICETOPIC/system/IpAddress:.* IpAddress\
$DEVICETOPIC/system/lastRfId:.* lastRfId\
$DEVICETOPIC/system/updateInProgress:.* updateInProgress\
$DEVICETOPIC/system/ConfiguredChargePoints:.* ConfiguredChargePoints\
$DEVICETOPIC/system/lastlivevalues:.* lastlivevalues\
$DEVICETOPIC/system/randomSleep:.* randomSleep\
$DEVICETOPIC/system/wizzardDone:.* wizzardDone\
$DEVICETOPIC/system/priceForKWh:.* priceForKWh\
$DEVICETOPIC/system/reloadDisplay:.* reloadDisplay\
\
$DEVICETOPIC/evu/ASchieflast:.* ASchieflast\
\
$DEVICETOPIC/lp/1/P%Soc:.* lp_1_Pct_Soc\
$DEVICETOPIC/lp/1/%Soc:.* lp_1_current_Soc\
$DEVICETOPIC/lp/1/\x25Soc:.* lp_1__Soc\
\
$DEVICETOPIC/lp/1/countPhasesInUse:.* lp_1_countPhasesInUse\
$DEVICETOPIC/lp/1/ChargePointEnabled:.* lp_1_ChargePointEnabled\
$DEVICETOPIC/lp/1/ChargeStatus:.* lp_1_ChargeStatus\
\
$DEVICETOPIC/lp/1/kWhDailyCharged:.* lp_1_kWhDailyCharged\
$DEVICETOPIC/lp/1/kWhCounter:.* lp_1_kWhCounter\
$DEVICETOPIC/lp/1/kWhActualCharged:.* lp_1_kWhActualCharged\
$DEVICETOPIC/lp/1/kWhChargedSincePlugged:.* lp_1_kWhChargedSincePlugged\
$DEVICETOPIC/lp/1/energyConsumptionPer100km:.* lp_1_energyConsumptionPer100km\
$DEVICETOPIC/lp/1/kmCharged:.* lp_1_kmCharged\
\
$DEVICETOPIC/lp/1/strChargePointName:.* lp_1_strChargePointName\
$DEVICETOPIC/lp/1/TimeRemaining:.* lp_1_TimeRemaining\
\
$DEVICETOPIC/lp/1/PfPhase2:.* lp_1_PfPhase2\
$DEVICETOPIC/lp/1/PfPhase3:.* lp_1_PfPhase3\
$DEVICETOPIC/lp/1/PfPhase1:.* lp_1_PfPhase1\
$DEVICETOPIC/lp/1/W:.* lp_1_W\
\
$DEVICETOPIC/lp/1/boolPlugStat:.* {my %h=(0=>'no Plug',1=>'Plugged in');; return {lp_1_PlugStat=>$h{$EVENT}}}\
$DEVICETOPIC/lp/1/boolChargeStat:.* {my %h=(0=>'not loading',1=>'loading');; return {lp_1_ChargeStat=>$h{$EVENT}}}\
$DEVICETOPIC/lp/1/AConfigured:.* lp_1_AConfigured\
\
$DEVICETOPIC/lp/1/boolChargePointConfigured:.* lp_1_boolChargePointConfigured\
$DEVICETOPIC/lp/1/boolSocConfigured:.* lp_1_boolSocConfigured\
$DEVICETOPIC/lp/1/boolDirectModeChargekWh:.* lp_1_boolDirectModeChargekWh\
$DEVICETOPIC/lp/1/boolDirectChargeModeSoc:.* lp_1_boolDirectChargeModeSoc\
$DEVICETOPIC/lp/1/boolFinishAtTimeChargeActive:.* lp_1_boolFinishAtTimeChargeActive\
$DEVICETOPIC/lp/1/boolChargeAtNight:.* lp_1_boolChargeAtNight\
$DEVICETOPIC/lp/1/boolSocManual:.* lp_1_boolSocManual\
\
$DEVICETOPIC/lp/1/AutolockStatus:.* lp_1_AutolockStatus\
$DEVICETOPIC/lp/1/AutolockConfigured:.* lp_1_AutolockConfigured\
\
$DEVICETOPIC/lp/1/lastRfId:.* lp_1_lastRfId\
$DEVICETOPIC/lp/1/pluggedladungakt:.* lp_1_pluggedladungakt\
$DEVICETOPIC/lp/1/plugStartkWh:.* lp_1_plugStartkWh\
$DEVICETOPIC/lp/1/MeterSerialNumber:.* lp_1_MeterSerialNumber\
\
\
$DEVICETOPIC/lp/2/P%Soc:.* lp_2_Pct_Soc\
$DEVICETOPIC/lp/2/%Soc:.* lp_2_current_Soc\
$DEVICETOPIC/lp/2/\x25Soc:.* lp_2__Soc\
\
$DEVICETOPIC/lp/2/countPhasesInUse:.* lp_2_countPhasesInUse\
$DEVICETOPIC/lp/2/ChargePointEnabled:.* lp_2_ChargePointEnabled\
$DEVICETOPIC/lp/2/ChargeStatus:.* lp_2_ChargeStatus\
\
$DEVICETOPIC/lp/2/kWhDailyCharged:.* lp_2_kWhDailyCharged\
$DEVICETOPIC/lp/2/kWhCounter:.* lp_2_kWhCounter\
$DEVICETOPIC/lp/2/kWhActualCharged:.* lp_2_kWhActualCharged\
$DEVICETOPIC/lp/2/kWhChargedSincePlugged:.* lp_2_kWhChargedSincePlugged\
$DEVICETOPIC/lp/2/energyConsumptionPer100km:.* lp_2_energyConsumptionPer100km\
$DEVICETOPIC/lp/2/kmCharged:.* lp_2_kmCharged\
\
$DEVICETOPIC/lp/2/strChargePointName:.* lp_2_strChargePointName\
$DEVICETOPIC/lp/2/TimeRemaining:.* lp_2_TimeRemaining\
\
$DEVICETOPIC/lp/2/W:.* lp_2_W\
\
$DEVICETOPIC/lp/2/boolPlugStat:.* {my %h=(0=>'no Plug',1=>'Plugged in');; return {lp_2_PlugStat=>$h{$EVENT}}}\
$DEVICETOPIC/lp/2/boolChargeStat:.* {my %h=(0=>'not loading',1=>'loading');; return {lp_2_ChargeStat=>$h{$EVENT}}}\
$DEVICETOPIC/lp/2/AConfigured:.* lp_2_AConfigured\
\
$DEVICETOPIC/lp/2/boolChargePointConfigured:.* lp_2_boolChargePointConfigured\
$DEVICETOPIC/lp/2/boolSocConfigured:.* lp_2_boolSocConfigured\
$DEVICETOPIC/lp/2/boolDirectModeChargekWh:.* lp_2_boolDirectModeChargekWh\
$DEVICETOPIC/lp/2/boolDirectChargeModeSoc:.* lp_2_boolDirectChargeModeSoc\
$DEVICETOPIC/lp/2/boolFinishAtTimeChargeActive:.* lp_2_boolFinishAtTimeChargeActive\
$DEVICETOPIC/lp/2/boolChargeAtNight:.* lp_2_boolChargeAtNight\
$DEVICETOPIC/lp/2/boolSocManual:.* lp_2_boolSocManual\
\
$DEVICETOPIC/lp/2/AutolockStatus:.* lp_2_AutolockStatus\
$DEVICETOPIC/lp/2/AutolockConfigured:.* lp_2_AutolockConfigured\
\
$DEVICETOPIC/lp/2/lastRfId:.* lp_2_lastRfId\
$DEVICETOPIC/lp/2/pluggedladungakt:.* lp_2_pluggedladungakt\
$DEVICETOPIC/lp/2/plugStartkWh:.* lp_2_plugStartkWh\
$DEVICETOPIC/lp/2/MeterSerialNumber:.* lp_2_MeterSerialNumber\
\
\
$DEVICETOPIC/boolChargeAtNight_direct:.* boolChargeAtNight_direct\
$DEVICETOPIC/boolChargeAtNight_nurpv:.* boolChargeAtNight_nurpv\
$DEVICETOPIC/boolChargeAtNight_minpv:.* boolChargeAtNight_minpv\
$DEVICETOPIC/boolDisplayHouseConsumption:.* boolDisplayHouseConsumption\
$DEVICETOPIC/boolDisplayDailyCharged:.* boolDisplayDailyCharged\
$DEVICETOPIC/boolEvuSmoothedActive:.* boolEvuSmoothedActive\
$DEVICETOPIC/pv/bool70PVDynActive:.* bool70PVDynActive\
$DEVICETOPIC/pv/W70PVDyn:.* W70PVDyn\
$DEVICETOPIC/pv/bool70PVDynStatus:.* bool70PVDynStatus\
$DEVICETOPIC/pv/CounterTillStartPvCharging:.* CounterTillStartPvCharging\
$DEVICETOPIC/pv/W:.* W\
$DEVICETOPIC/config/get/pv/nurpv70dynact:.* nurpv70dynact\
$DEVICETOPIC/config/get/pv/nurpv70dynw:.* nurpv70dynw\
$DEVICETOPIC/config/get/pv/priorityModeEVBattery:.* priorityModeEVBattery\
$DEVICETOPIC/config/get/pv/lp/1/minSocAlwaysToChargeTo:.* lp_1_minSocAlwaysToChargeTo\
$DEVICETOPIC/config/get/pv/lp/1/maxSoc:.* lp_1_maxSoc\
$DEVICETOPIC/config/get/pv/lp/1/minSocAlwaysToChargeToCurrent:.* lp_1_minSocAlwaysToChargeToCurrent\
$DEVICETOPIC/config/get/pv/lp/1/maxSocToChargeTo:.* lp_1_maxSocToChargeTo\
$DEVICETOPIC/config/get/pv/lp/1/minCurrent:.* lp_1_minCurrent\
$DEVICETOPIC/config/get/pv/lp/1/socLimitation:.* lp_1_socLimitation\
$DEVICETOPIC/config/get/pv/lp/2/minCurrent:.* lp_2_minCurrent\
$DEVICETOPIC/config/get/pv/lp/2/maxSoc:.* lp_2_maxSoc\
$DEVICETOPIC/config/get/pv/lp/2/socLimitation:.* lp_2_socLimitation\
$DEVICETOPIC/config/get/pv/socStopChargeAtMinPv:.* socStopChargeAtMinPv\
$DEVICETOPIC/config/get/pv/regulationPoint:.* regulationPoint\
$DEVICETOPIC/config/get/pv/minBatteryDischargeSocAtBattPriority:.* minBatteryDischargeSocAtBattPriority\
$DEVICETOPIC/config/get/pv/minBatteryChargePowerAtEvPriority:.* minBatteryChargePowerAtEvPriority\
$DEVICETOPIC/config/get/pv/minFeedinPowerBeforeStart:.* minFeedinPowerBeforeStart\
$DEVICETOPIC/config/get/pv/boolAdaptiveCharging:.* boolAdaptiveCharging\
$DEVICETOPIC/config/get/pv/adaptiveChargingFactor:.* adaptiveChargingFactor\
$DEVICETOPIC/config/get/pv/batteryDischargePowerAtBattPriority:.* batteryDischargePowerAtBattPriority\
$DEVICETOPIC/config/get/pv/boolShowPriorityIconInTheme:.* boolShowPriorityIconInTheme\
$DEVICETOPIC/config/get/pv/maxPowerConsumptionBeforeStop:.* maxPowerConsumptionBeforeStop\
$DEVICETOPIC/config/get/pv/stopDelay:.* stopDelay\
$DEVICETOPIC/config/get/pv/chargeSubmode:.* chargeSubmode\
$DEVICETOPIC/config/get/pv/minCurrentMinPv:.* minCurrentMinPv\
$DEVICETOPIC/config/get/pv/socStartChargeAtMinPv:.* socStartChargeAtMinPv\
$DEVICETOPIC/config/get/pv/startDelay:.* startDelay\
$DEVICETOPIC/config/get/sofort/lp/2/energyToCharge:.* lp_2_energyToCharge\
$DEVICETOPIC/config/get/sofort/lp/2/chargeLimitation:.* lp_2_chargeLimitation\
$DEVICETOPIC/config/get/sofort/lp/2/socToChargeTo:.* lp_2_socToChargeTo\
$DEVICETOPIC/config/get/sofort/lp/2/current:.* lp_2_current\
\
$DEVICETOPIC/config/get/sofort/lp/1/socToChargeTo:.* lp_1_socToChargeTo\
\
$DEVICETOPIC/config/get/sofort/lp/1/energyToCharge:.* lp_1_energyToCharge\
$DEVICETOPIC/config/get/sofort/lp/1/chargeLimitation:.* lp_1_chargeLimitation\
$DEVICETOPIC/config/get/sofort/lp/1/current:.* lp_1_current\
$DEVICETOPIC/config/get/global/minEVSECurrentAllowed:.* minEVSECurrentAllowed\
$DEVICETOPIC/config/get/global/maxEVSECurrentAllowed:.* maxEVSECurrentAllowed\
$DEVICETOPIC/config/get/global/dataProtectionAcknoledged:.* dataProtectionAcknoledged\
$DEVICETOPIC/config/get/global/slaveMode:.* slaveMode\
$DEVICETOPIC/config/get/u1p3p/standbyPhases:.* standbyPhases\
$DEVICETOPIC/config/get/u1p3p/sofortPhases:.* sofortPhases\
$DEVICETOPIC/config/get/u1p3p/nachtPhases:.* nachtPhases\
$DEVICETOPIC/config/get/u1p3p/minundpvPhases:.* minundpvPhases\
$DEVICETOPIC/config/get/u1p3p/nurpvPhases:.* nurpvPhases\
$DEVICETOPIC/config/get/u1p3p/isConfigured:.* isConfigured\
$DEVICETOPIC/boolChargeAtNight_standby:.* boolChargeAtNight_standby\
$DEVICETOPIC/set/system/reloadDisplay:.* reloadDisplay\
$DEVICETOPIC/set/system/topicSender:.* topicSender\
$DEVICETOPIC/set/lp/2/faultState:.* lp_2_faultState\
$DEVICETOPIC/set/lp/2/faultStr:.* lp_2_faultStr\
$DEVICETOPIC/set/lp/2/ChargePointEnabled:.* lp_2_ChargePointEnabled
attr WB_1 room MQTT2_DEVICE,Strom->Photovoltaik
attr WB_1 setList Lademodus:SofortLaden,Min+PV,NurPV,Stop,Standby { my %h=(SofortLaden=>'0','Min+PV'=>'1',NurPV=>'2',Stop=>'3',Standby=>'4');;qq($DEVICETOPIC/set/ChargeMode $h{$EVTPART1}) }\
DirectChargeSubMode:Aus,kWh_Laden,SoC_Laden { my %h=(Aus=>'0',kWh_Laden=>'1',SoC_Laden=>'2');;qq($DEVICETOPIC/set/lp1/DirectChargeSubMode $h{$EVTPART1}) }\
lp_1_socToChargeTo:50,60,70,80,90,100 { qq($DEVICETOPIC/config/set/sofort/lp/1/socToChargeTo $EVTPART1) }
attr WB_1 sortby 311
attr WB_1 stateFormat {\
my $YearBefore='LogDBRep_Statistic_previous_Year';;\
my $DUMMY = "";;\
my $date = POSIX::strftime("%Y-%m-%d",localtime(time_str2num(ReadingsTimestamp($name, "lastlivevalues",0))));;\
\
my $ChargeMode = ReadingsVal($name,"ChargeMode","n/a");;\
$ChargeMode = ($ChargeMode eq "SofortLaden")? "<span style='color:red'>SofortLaden</span>" : ($ChargeMode eq "MinPV")? "<span style='color:orange'>Min+PV</span>" : ($ChargeMode eq "NurPV")? "<span style='color:green'>NurPV</span>" : $ChargeMode;;\
\
my $lp_1_Name = ReadingsVal($name,"lp_1_strChargePointName","n/a");;\
my $lp_1_Power = ReadingsVal($name,"lp_1_W",0)." W";;\
my $lp_1_Power_1 = ReadingsVal($name,"lp_1_countPhasesInUse",0)."P ".ReadingsVal($name,"lp_1_AConfigured",0)."A";;\
my $lp_1_Status_1 = ReadingsVal($name,"lp_1_PlugStat","n/a")."<br>".ReadingsVal($name,"lp_1_ChargeStat","n/a");;\
my $lp_1_Status_2 = ReadingsVal($name,"lp_1_TimeRemaining","n/a");;\
\
my $lp_1_Power_d = ReadingsVal($name,"lp_1_kWhDailyCharged",0)." kWh";;\
my $lp_1_Power_m = round(ReadingsVal($name,"lp_1_kWhCounter_Month",0),0)." kWh";;\
my $lp_1_Power_j = sprintf("%04d / %04d",ReadingsVal($name,"lp_1_kWhCounter_Year",0),ReadingsVal($YearBefore,"lp_1_kWhCounter_Year",0));;\
my $lp_1_Power_t = round(ReadingsVal($name,"lp_1_kWhCounter",0),0)." kWh";;\
\
my $lp_2_Name = ReadingsVal($name,"lp_2_strChargePointName","n/a");;\
my $lp_2_Power = ReadingsVal($name,"lp_2_W",0)." W";;\
my $lp_2_Power_1 = ReadingsVal($name,"lp_2_countPhasesInUse",0)."P ".ReadingsVal($name,"lp_2_AConfigured",0)."A";;\
my $lp_2_Status_1 = ReadingsVal($name,"lp_2_PlugStat","n/a")."<br>".ReadingsVal($name,"lp_2_ChargeStat","n/a");;\
my $lp_2_Status_2 = "<br>".ReadingsVal($name,"lp_2_TimeRemaining","n/a");;\
\
my $lp_2_Power_d = ReadingsVal($name,"lp_2_kWhDailyCharged",0)." kWh";;\
my $lp_2_Power_m = round(ReadingsVal($name,"lp_2_kWhCounter_Month",0),0)." kWh";;\
my $lp_2_Power_j = sprintf("%04d / %04d",ReadingsVal($name,"lp_2_kWhCounter_Year",0),ReadingsVal($YearBefore,"lp_2_kWhCounter_Year",0));;\
my $lp_2_Power_t = round(ReadingsVal($name,"lp_2_kWhCounter",0),0)." kWh";;\
\
"<html><table border=2 bordercolor='darkgreen' cellspacing=0 style='width: 100%'>\
<colgroup>\
<col span='1' style='width: 52%;;'>\
<col span='1' style='width: 12%;;'>\
<col span='1' style='width: 12%;;'>\
<col span='1' style='width: 12%;;'>\
<col span='1' style='width: 12%;;'>\
</colgroup>\
<tr><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>Wallbox</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold;;text-align:center'>$ChargeMode</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold;;text-align:center'>Status</td><td style='padding-right:5px;;padding-left:5px;;text-align:center;;font-weight:bold'>Restladezeit</td><td style='padding-right:5px;;padding-left:5px;;text-align:center;;font-weight:bold'>Leistung</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'> ; ;".$lp_1_Name."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$DUMMY."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_1_Status_1."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_1_Status_2."<br></td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_1_Power_1."<br>".$lp_1_Power."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'> ; ;".$lp_2_Name."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$DUMMY."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_2_Status_1."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_2_Status_2."<br></td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_2_Power_1."<br>".$lp_2_Power."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>Statistik vom $date</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold;;text-align:center'>aktuell</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold;;text-align:center'>Heute</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold;;text-align:center'>Monat</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold;;text-align:center'>Jahr/Vorjahr</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'> ; ;".$lp_1_Name."<td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_1_Power."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_1_Power_d."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_1_Power_m."<br></td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_1_Power_j."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'> ; ;".$lp_2_Name."<td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_2_Power."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_2_Power_d."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_2_Power_m."<br></td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$lp_2_Power_j."</td></tr>\
</table>\
</html>"\
}
attr WB_1 userReadings lp_1_kWhCounter_Month:lp_1_kWhCounter.* { round(ReadingsVal("$NAME","lp_1_kWhCounter",0) - ReadingsVal("$NAME","lp_1_kWhCounter_init_Month",0),0) },\
lp_1_kWhCounter_Year:lp_1_kWhCounter.* { round(ReadingsVal("$NAME","lp_1_kWhCounter",0) - ReadingsVal("$NAME","lp_1_kWhCounter_init_Year",0),0) },\
\
lp_2_kWhCounter_Month:lp_2_kWhCounter.* { round(ReadingsVal("$NAME","lp_2_kWhCounter",0) - ReadingsVal("$NAME","lp_2_kWhCounter_init_Month",0),0) },\
lp_2_kWhCounter_Year:lp_2_kWhCounter.* { round(ReadingsVal("$NAME","lp_2_kWhCounter",0) - ReadingsVal("$NAME","lp_2_kWhCounter_init_Year",0),0) }
</syntaxhighlight>

=====Kia connect MQTT=====
Das Kia_connect Device empfängt und sendet die MQTT Nachrichten zum Node-red Flow für das Kia BEV.

RAW des Kia connect
<syntaxhighlight lang="Perl">
defmod Kia_connect MQTT2_DEVICE
attr Kia_connect DbLogExclude .*
attr Kia_connect DbLogInclude .*
attr Kia_connect IODev MQTT2_FHEM_Server
attr Kia_connect alias Kia_connect
attr Kia_connect autocreate 1
attr Kia_connect devicetopic bluelinky
attr Kia_connect group PV Eigenverbrauch-Steuerung
attr Kia_connect icon car
attr Kia_connect readingList $DEVICETOPIC/status:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/location.* { json2nameValue($EVENT) }\
$DEVICETOPIC/odometer:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/req_received:.* req_received\
$DEVICETOPIC/req_active:.* req_active
attr Kia_connect room MQTT2_DEVICE,Strom->Photovoltaik
attr Kia_connect setList getOdometer req/$DEVICETOPIC/get_odometer get_odometer\
getStatus req/$DEVICETOPIC/get_status get_status\
getLocation req/$DEVICETOPIC/get_location get_location\
getTripinfo req/$DEVICETOPIC/get_tripinfo\
getAll req/$DEVICETOPIC/get_all get_all\
setChargeTargetSoc req/$DEVICETOPIC/set_chargetargets\
startCharge req/$DEVICETOPIC/start_charging start_charging\
stopCharge req/$DEVICETOPIC/stop_charging stop_charging\
stopClimate req/$DEVICETOPIC/stop_climate stop_climate\
startClimate req/$DEVICETOPIC/start_climate
attr Kia_connect sortby 402
attr Kia_connect stateFormat req_active
attr Kia_connect userReadings atHomeStanding:location.* { ((abs(AttrVal("global","latitude",49.85) - ReadingsVal($NAME,"location_coord_lat",0)) <= 0.001) && (abs(AttrVal("global","longitude",8.49) - ReadingsVal($NAME,"location_coord_lon",0)) <= 0.001) && (ReadingsVal($NAME,"location_speed_value",1) == 0)) ? 'true' : 'false';;;; },\
batSOC:status.* { ReadingsVal($NAME,"status_evStatus_batteryStatus",0);;;;},\
connected:status.* { (ReadingsVal($NAME,"status_evStatus_batteryPlugin",0) != 0) ? 'true' : 'false';;;;},\
charging:status.* { ReadingsVal($NAME,"status_evStatus_batteryCharge",'false');;;;},\
targetSOC:status.* { ReadingsVal($NAME,"status_evStatus_reservChargeInfos_targetSOClist_2_targetSOClevel",0);;;;},\
time2targetSOC:status.* { my $t = ReadingsVal($NAME,"status_evStatus_remainTime2_atc_value",1);;;; sprintf("%02d:%02d", $t/60%60, $t%60);;},\
range:status.* { ReadingsVal($NAME,"status_evStatus_drvDistance_1_rangeByFuel_totalAvailableRange_value",0);;;;},\
bat12v:status.* { ReadingsVal($NAME,"status_battery_batSoc",0);;;;}
</syntaxhighlight>

=====Node-red=====
[[Bild:Kia Flow.PNG|mini|900px|rechts|Node-red Kia Flow]]
Node-red habe ich einfach in einem Docker Container runter geladen und gestartet. Über Port 1880 kommt man direkt in die GUI und kann den ersten Flow laden.

docker-compose .yml Eintrag
<syntaxhighlight lang="Perl">
node-red:
image: nodered/node-red:latest
restart: always
environment:
- TZ=Europe/Berlin
ports:
- 1880:1880
volumes:
- ./node-red/data:/data
</syntaxhighlight>

Danach fehlt im Container noch folgende Erweiterung für den Node-red Flow
<syntaxhighlight lang="Perl">
npm install node-red-contrib-bluelinky
</syntaxhighlight>

=====Kia Connect=====
<pre>
Kia connect ist eine API für Kia und Hyundai E-Autos mit der man Daten vom Auto abfragen kann und auch einige Steuerungen möglich sind.
Mit Node-red und BlueLinky wird die Schnittstelle bedient.
Der Flow ist nicht ursprünglich von mir, wurde jedoch noch erweitert.
Vor dem Laden des Flows sind noch die persönlichen Verbindungsdaten im JSON einzutragen.

Nach dem Laden ist ein Test mit den Inject Symbolen und der Debug Funktionalität möglich und auch sinnvoll.
Unterhalb der MQTT - und BlueLinky Symbole sollte "Verbunden" oder "Ready" erscheinen.
</pre>
'''Wichtig beim Kia ist, dass für das Laden über die openWB als SOC Ziel 100% im standard Modus konfiguriert wird.''' Ansonsten wundert man sich warum das Laden einfach nicht starten möchte. Im Default ist dort bei mir nur 50% eingetragen gewesen :-). Mit jetzt 100% kann die openWB auch selber einen Ziel SOC bestimmen, ansonsten hört das BEV einfach selber auf zu laden.

Weiterhin sollte man darauf achten, dass man nur eine begrenzte Anzahl von Nachrichten mit dem Kia BEV pro Tag austauschen kann. Das wurde im DOIF schon etwas berücksichtigt (1x pro Stunde), kann jedoch bei gleichzeitiger Verwendung der Handy App oder der SOC Abfrage im openWB Kia Modul auch mal zu Fehlern führen. Durch die Stündliche Status Abfrage im DOIF kommt es natürlich zu Verzögerungen im FHEM Status. Dann einfach einmal Manuell abfragen.

Node-red JSON Import
<syntaxhighlight lang="json">
[ {
"id": "866c75dd.edd9a8",
"type": "tab",
"label": "Kia e-Niro",
"disabled": false,
"info": ""
},
{
"id": "bb13a99d.68b8f8",
"type": "mqtt-broker",
"name": "mqtt_Server",
"broker": "<FHEM MQTT IP Adresse>",
"port": "1883",
"clientid": "",
"autoConnect": true,
"usetls": false,
"compatmode": false,
"protocolVersion": "4",
"keepalive": "60",
"cleansession": true,
"birthTopic": "",
"birthQos": "0",
"birthPayload": "",
"birthMsg": {},
"closeTopic": "",
"closeQos": "0",
"closePayload": "",
"closeMsg": {},
"willTopic": "",
"willQos": "0",
"willPayload": "",
"willMsg": {},
"sessionExpiry": ""
},
{
"id": "452a3304.58c8fc",
"type": "bluelinky",
"username": "<Mail Adresse bei Kia>",
"password": "<Passwort>",
"region": "EU",
"pin": "<Pin>",
"vin": "<VIN>",
"brand": "kia"
},
{
"id": "91a345fa.5757a8",
"type": "mqtt in",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "req/bluelinky/get_status",
"qos": "0",
"datatype": "auto",
"broker": "bb13a99d.68b8f8",
"inputs": 0,
"x": 260,
"y": 280,
"wires": [
[
"15dfb508.c6497b",
"ce62ba4f.d86548",
"3f82a275.5a0b6e",
"24d5e0b.3aafc2"
]
]
},
{
"id": "5ad085b9.05739c",
"type": "mqtt in",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "req/bluelinky/start_climate",
"qos": "0",
"datatype": "auto",
"broker": "bb13a99d.68b8f8",
"nl": false,
"rap": false,
"inputs": 0,
"x": 270,
"y": 680,
"wires": [
[
"b27d74de.38c808",
"33b1bc85.662694",
"ce62ba4f.d86548",
"24d5e0b.3aafc2"
]
]
},
{
"id": "15dfb508.c6497b",
"type": "car-status",
"z": "866c75dd.edd9a8",
"name": "Get status",
"dorefresh": true,
"parsed": false,
"bluelinky": "452a3304.58c8fc",
"x": 1110,
"y": 280,
"wires": [
[
"cccc9476.d56dd8",
"226ed925.607bb6"
]
]
},
{
"id": "87abdd88.8ff4d",
"type": "car-odometer",
"z": "866c75dd.edd9a8",
"name": "Get car odometer",
"bluelinky": "452a3304.58c8fc",
"x": 1130,
"y": 200,
"wires": [
[
"40d2361c.579588",
"226ed925.607bb6"
]
]
},
{
"id": "31100f9a.40008",
"type": "function",
"z": "866c75dd.edd9a8",
"name": "locationWrapper",
"func": "if(msg.payload.hasOwnProperty(\"body\")) {\n msg.payload = {\"error\":true};\n return msg;\n}\nelse {\n\n msg.payload = { \n \"location\": msg.payload,\n \"error\": false\n };\n \n return msg;\n}",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 1490,
"y": 120,
"wires": [
[
"85a07155.a0f9f",
"262df5dc.57916a",
"f487d6d6.a4d568"
]
]
},
{
"id": "bea1d927.0f3908",
"type": "car-location",
"z": "866c75dd.edd9a8",
"name": "Get car location",
"bluelinky": "452a3304.58c8fc",
"x": 1120,
"y": 120,
"wires": [
[
"31100f9a.40008",
"226ed925.607bb6"
]
]
},
{
"id": "3c949d67.0d83b2",
"type": "mqtt in",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "req/bluelinky/get_location",
"qos": "0",
"datatype": "auto",
"broker": "bb13a99d.68b8f8",
"nl": false,
"rap": false,
"inputs": 0,
"x": 270,
"y": 120,
"wires": [
[
"bea1d927.0f3908",
"ce62ba4f.d86548",
"3f82a275.5a0b6e",
"24d5e0b.3aafc2"
]
]
},
{
"id": "cccc9476.d56dd8",
"type": "function",
"z": "866c75dd.edd9a8",
"name": "analyseStatus",
"func": "if(msg.payload.hasOwnProperty(\"body\")) {\n msg.payload = {\"error\":true};\n return msg;\n}\nelse {\n let status = msg.payload;\n status.airTemp.value = 14+(parseInt(status.airTemp.value,16)/2);\n try{\n status.evStatus.reservChargeInfos.reservChargeInfo.reservChargeInfoDetail.reservFatcSet.airTemp.value = 14+(parseInt(status.evStatus.reservChargeInfos.reservChargeInfo.reservChargeInfoDetail.reservFatcSet.airTemp.value,16)/2);\n status.evStatus.reservChargeInfos.reserveChargeInfo2.reservChargeInfoDetail.reservFatcSet.airTemp.value = 14+(parseInt(status.evStatus.reservChargeInfos.reserveChargeInfo2.reservChargeInfoDetail.reservFatcSet.airTemp.value,16)/2);\n } catch(e) {}\n\n let time = status.evStatus.remainTime2.atc.value/60;\n let result = { \n \"batSOC\": status.evStatus.batteryStatus,\n \"connected\": (status.evStatus.batteryPlugin !== 0),\n \"charging\": status.evStatus.batteryCharge,\n \"targetSOC\": status.evStatus.reservChargeInfos.targetSOClist[1].targetSOClevel,\n \"time2targetSOC\": (Math.floor(time) + \":\" + (\"0\" + Math.floor((time % 1)*60)).slice(-2)), // h:mm\n \"range\": status.evStatus.drvDistance[0].rangeByFuel.totalAvailableRange.value,\n \"bat12v\": status.battery.batSoc\n };\n \n //msg.payload = result;\n msg.payload = {\n \"status\": status,\n \"error\": false\n \n };\n return msg;\n}",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"x": 1480,
"y": 280,
"wires": [
[
"3efceea0.c81b12",
"262df5dc.57916a",
"f487d6d6.a4d568"
]
]
},
{
"id": "85a07155.a0f9f",
"type": "mqtt out",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "bluelinky/location",
"qos": "",
"retain": "",
"broker": "bb13a99d.68b8f8",
"x": 1910,
"y": 120,
"wires": []
},
{
"id": "3efceea0.c81b12",
"type": "mqtt out",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "bluelinky/status",
"qos": "",
"retain": "",
"broker": "bb13a99d.68b8f8",
"x": 1900,
"y": 280,
"wires": []
},
{
"id": "327104fc.71e1bc",
"type": "mqtt out",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "bluelinky/odometer",
"qos": "",
"retain": "",
"broker": "bb13a99d.68b8f8",
"x": 1910,
"y": 200,
"wires": []
},
{
"id": "844a32f4.2e029",
"type": "mqtt in",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "req/bluelinky/stop_climate",
"qos": "0",
"datatype": "auto",
"broker": "bb13a99d.68b8f8",
"inputs": 0,
"x": 270,
"y": 760,
"wires": [
[
"7d3ae860.d8c9a8",
"33b1bc85.662694",
"ce62ba4f.d86548",
"24d5e0b.3aafc2"
]
]
},
{
"id": "57d91e50.7e96",
"type": "mqtt in",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "req/bluelinky/start_charging",
"qos": "0",
"datatype": "auto",
"broker": "bb13a99d.68b8f8",
"inputs": 0,
"x": 280,
"y": 820,
"wires": [
[
"6eebc52c.ee23dc",
"33b1bc85.662694",
"ce62ba4f.d86548",
"24d5e0b.3aafc2"
]
]
},
{
"id": "6029f0a0.b73e",
"type": "mqtt in",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "req/bluelinky/stop_charging",
"qos": "0",
"datatype": "auto",
"broker": "bb13a99d.68b8f8",
"nl": false,
"rap": false,
"inputs": 0,
"x": 280,
"y": 880,
"wires": [
[
"84a1ae.74912e5",
"33b1bc85.662694",
"ce62ba4f.d86548",
"24d5e0b.3aafc2"
]
]
},
{
"id": "c5ecf76c.e753c8",
"type": "start-car",
"z": "866c75dd.edd9a8",
"name": "Start car",
"bluelinky": "452a3304.58c8fc",
"x": 1100,
"y": 680,
"wires": [
[
"811aa567.e89f98",
"f487d6d6.a4d568"
]
]
},
{
"id": "6eebc52c.ee23dc",
"type": "start-charge",
"z": "866c75dd.edd9a8",
"name": "Start Charging",
"bluelinky": "452a3304.58c8fc",
"x": 1120,
"y": 820,
"wires": [
[
"811aa567.e89f98",
"f487d6d6.a4d568"
]
]
},
{
"id": "84a1ae.74912e5",
"type": "stop-charge",
"z": "866c75dd.edd9a8",
"name": "Stop Charging",
"bluelinky": "452a3304.58c8fc",
"x": 1120,
"y": 880,
"wires": [
[
"811aa567.e89f98",
"f487d6d6.a4d568"
]
]
},
{
"id": "7d3ae860.d8c9a8",
"type": "stop-car",
"z": "866c75dd.edd9a8",
"name": "Stop car",
"bluelinky": "452a3304.58c8fc",
"x": 1100,
"y": 760,
"wires": [
[
"811aa567.e89f98",
"f487d6d6.a4d568"
]
]
},
{
"id": "b27d74de.38c808",
"type": "json",
"z": "866c75dd.edd9a8",
"name": "",
"property": "payload",
"action": "obj",
"pretty": false,
"x": 750,
"y": 680,
"wires": [
[
"c5ecf76c.e753c8",
"33b1bc85.662694"
]
]
},
{
"id": "45a6a8e6.2abfd8",
"type": "mqtt in",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "req/bluelinky/get_odometer",
"qos": "0",
"datatype": "auto",
"broker": "bb13a99d.68b8f8",
"inputs": 0,
"x": 280,
"y": 200,
"wires": [
[
"87abdd88.8ff4d",
"ce62ba4f.d86548",
"3f82a275.5a0b6e",
"24d5e0b.3aafc2"
]
]
},
{
"id": "33b1bc85.662694",
"type": "debug",
"z": "866c75dd.edd9a8",
"name": "",
"active": false,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"statusVal": "",
"statusType": "auto",
"x": 930,
"y": 920,
"wires": []
},
{
"id": "ce62ba4f.d86548",
"type": "mqtt out",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "bluelinky/req_received",
"qos": "",
"retain": "",
"broker": "bb13a99d.68b8f8",
"x": 860,
"y": 480,
"wires": []
},
{
"id": "1babee6c.1c2982",
"type": "mqtt in",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "req/bluelinky/get_all",
"qos": "0",
"datatype": "auto",
"broker": "bb13a99d.68b8f8",
"inputs": 0,
"x": 250,
"y": 360,
"wires": [
[
"ce62ba4f.d86548",
"3f82a275.5a0b6e",
"24d5e0b.3aafc2",
"4375fbb9.00fb44"
]
]
},
{
"id": "262df5dc.57916a",
"type": "debug",
"z": "866c75dd.edd9a8",
"name": "",
"active": false,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"statusVal": "",
"statusType": "auto",
"x": 1850,
"y": 80,
"wires": []
},
{
"id": "811aa567.e89f98",
"type": "debug",
"z": "866c75dd.edd9a8",
"name": "",
"active": false,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"statusVal": "",
"statusType": "auto",
"x": 1470,
"y": 1040,
"wires": []
},
{
"id": "3f82a275.5a0b6e",
"type": "debug",
"z": "866c75dd.edd9a8",
"name": "",
"active": false,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"statusVal": "",
"statusType": "auto",
"x": 930,
"y": 80,
"wires": []
},
{
"id": "24d5e0b.3aafc2",
"type": "change",
"z": "866c75dd.edd9a8",
"name": "",
"rules": [
{
"t": "set",
"p": "payload",
"pt": "msg",
"to": "pending",
"tot": "str"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 790,
"y": 1140,
"wires": [
[
"4dd1ea4a.52f144",
"fecad185.324f8"
]
]
},
{
"id": "f487d6d6.a4d568",
"type": "change",
"z": "866c75dd.edd9a8",
"name": "",
"rules": [
{
"t": "set",
"p": "payload",
"pt": "msg",
"to": "idle",
"tot": "str"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 1910,
"y": 760,
"wires": [
[
"4dd1ea4a.52f144",
"fecad185.324f8"
]
]
},
{
"id": "4dd1ea4a.52f144",
"type": "mqtt out",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "bluelinky/req_active",
"qos": "",
"retain": "",
"broker": "bb13a99d.68b8f8",
"x": 2140,
"y": 1100,
"wires": []
},
{
"id": "fecad185.324f8",
"type": "debug",
"z": "866c75dd.edd9a8",
"name": "",
"active": false,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "false",
"statusVal": "",
"statusType": "auto",
"x": 2110,
"y": 1160,
"wires": []
},
{
"id": "40d2361c.579588",
"type": "function",
"z": "866c75dd.edd9a8",
"name": "odometerWrapper",
"func": "if(msg.payload.hasOwnProperty(\"body\")) {\n msg.payload = {\"error\":true};\n return msg;\n}\nelse {\n msg.payload = { \n \"odometer\": msg.payload,\n \"error\": false\n };\n\n return msg;\n}",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 1490,
"y": 200,
"wires": [
[
"327104fc.71e1bc",
"262df5dc.57916a",
"f487d6d6.a4d568"
]
]
},
{
"id": "226ed925.607bb6",
"type": "debug",
"z": "866c75dd.edd9a8",
"name": "",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"statusVal": "",
"statusType": "auto",
"x": 1430,
"y": 80,
"wires": []
},
{
"id": "4375fbb9.00fb44",
"type": "car-fullstatus",
"z": "866c75dd.edd9a8",
"name": "Get full status",
"dorefresh": true,
"bluelinky": "452a3304.58c8fc",
"x": 1120,
"y": 360,
"wires": [
[
"226ed925.607bb6",
"69b6c4df.ea6bcc",
"89681a97.9e24d8",
"92dc3ff4.1d6e3"
]
]
},
{
"id": "69b6c4df.ea6bcc",
"type": "function",
"z": "866c75dd.edd9a8",
"name": "locationFromFullstatus",
"func": "if(msg.payload.hasOwnProperty(\"body\")) {\n msg.payload = {\"error\":true};\n return msg;\n}\nelse {\n\n msg.payload = { \n \"location\": msg.payload.vehicleLocation,\n \"error\": false\n };\n \n return msg;\n}\n",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"x": 1500,
"y": 360,
"wires": [
[
"85a07155.a0f9f",
"331e5860.907808"
]
]
},
{
"id": "92dc3ff4.1d6e3",
"type": "function",
"z": "866c75dd.edd9a8",
"name": "statusFromFullstatus",
"func": "if(msg.payload.hasOwnProperty(\"body\")) {\n msg.payload = {\"error\":true};\n return msg;\n}\nelse {\n let status = msg.payload.vehicleStatus;\n try{\n status.airTemp.value = 14+(parseInt(status.airTemp.value,16)/2);\n status.evStatus.reservChargeInfos.reservChargeInfo.reservChargeInfoDetail.reservFatcSet.airTemp.value = 14+(parseInt(status.evStatus.reservChargeInfos.reservChargeInfo.reservChargeInfoDetail.reservFatcSet.airTemp.value,16)/2);\n status.evStatus.reservChargeInfos.reserveChargeInfo2.reservChargeInfoDetail.reservFatcSet.airTemp.value = 14+(parseInt(status.evStatus.reservChargeInfos.reserveChargeInfo2.reservChargeInfoDetail.reservFatcSet.airTemp.value,16)/2);\n } catch(e) {}\n\n msg.payload = { \n \"status\": status,\n \"error\": false\n };\n \n return msg;\n}\n",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"x": 1500,
"y": 480,
"wires": [
[
"3efceea0.c81b12",
"f487d6d6.a4d568",
"331e5860.907808"
]
]
},
{
"id": "89681a97.9e24d8",
"type": "function",
"z": "866c75dd.edd9a8",
"name": "odometerFromFullstatus",
"func": "if(msg.payload.hasOwnProperty(\"body\")) {\n msg.payload = {\"error\":true};\n return msg;\n}\nelse {\n\n msg.payload = { \n \"odometer\": msg.payload.odometer,\n \"error\": false\n };\n \n return msg;\n}\n",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"x": 1510,
"y": 420,
"wires": [
[
"327104fc.71e1bc",
"331e5860.907808"
]
]
},
{
"id": "331e5860.907808",
"type": "debug",
"z": "866c75dd.edd9a8",
"name": "",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"statusVal": "",
"statusType": "auto",
"x": 1850,
"y": 520,
"wires": []
},
{
"id": "aa4d220b.f7e19",
"type": "set-chargetargets",
"z": "866c75dd.edd9a8",
"name": "Set charge targets",
"bluelinky": "452a3304.58c8fc",
"x": 1130,
"y": 960,
"wires": [
[
"811aa567.e89f98",
"f487d6d6.a4d568"
]
]
},
{
"id": "4c03338d.2f15ec",
"type": "login",
"z": "866c75dd.edd9a8",
"name": "Login",
"bluelinky": "452a3304.58c8fc",
"x": 1090,
"y": 1040,
"wires": [
[
"811aa567.e89f98"
]
]
},
{
"id": "28b868f5.16cb48",
"type": "inject",
"z": "866c75dd.edd9a8",
"name": "",
"props": [
{
"p": "payload"
},
{
"p": "topic",
"vt": "str"
}
],
"repeat": "43200",
"crontab": "",
"once": true,
"onceDelay": "12",
"topic": "",
"payloadType": "date",
"x": 950,
"y": 1040,
"wires": [
[
"4c03338d.2f15ec"
]
]
},
{
"id": "db9ecdb5.a9683",
"type": "mqtt in",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "req/bluelinky/set_chargetargets",
"qos": "0",
"datatype": "auto",
"broker": "bb13a99d.68b8f8",
"nl": false,
"rap": false,
"inputs": 0,
"x": 290,
"y": 960,
"wires": [
[
"7064a8d53256b646",
"ce62ba4f.d86548",
"24d5e0b.3aafc2"
]
]
},
{
"id": "44155ad70c47b0dd",
"type": "inject",
"z": "866c75dd.edd9a8",
"name": "",
"props": [
{
"p": "payload"
},
{
"p": "topic",
"vt": "str"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "",
"payloadType": "date",
"x": 940,
"y": 260,
"wires": [
[
"15dfb508.c6497b"
]
]
},
{
"id": "7064a8d53256b646",
"type": "json",
"z": "866c75dd.edd9a8",
"name": "",
"property": "payload",
"action": "obj",
"pretty": false,
"x": 750,
"y": 960,
"wires": [
[
"33b1bc85.662694",
"aa4d220b.f7e19"
]
]
},
{
"id": "7064395e56292844",
"type": "inject",
"z": "866c75dd.edd9a8",
"name": "",
"props": [
{
"p": "payload"
},
{
"p": "topic",
"vt": "str"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "",
"payloadType": "date",
"x": 940,
"y": 340,
"wires": [
[
"4375fbb9.00fb44"
]
]
},
{
"id": "5f9ff828080f5fe6",
"type": "lock-car",
"z": "866c75dd.edd9a8",
"name": "Lock car",
"bluelinky": "452a3304.58c8fc",
"x": 1100,
"y": 560,
"wires": [
[
"811aa567.e89f98",
"f487d6d6.a4d568"
]
]
},
{
"id": "492f5b94a865e47b",
"type": "inject",
"z": "866c75dd.edd9a8",
"name": "",
"props": [
{
"p": "payload"
},
{
"p": "topic",
"vt": "str"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "",
"payloadType": "date",
"x": 940,
"y": 540,
"wires": [
[
"5f9ff828080f5fe6"
]
]
},
{
"id": "d6f3f148e765caf9",
"type": "mqtt in",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "req/bluelinky/car_lock",
"qos": "0",
"datatype": "auto",
"broker": "bb13a99d.68b8f8",
"nl": false,
"rap": false,
"inputs": 0,
"x": 260,
"y": 560,
"wires": [
[
"5f9ff828080f5fe6",
"ce62ba4f.d86548"
]
]
},
{
"id": "cdc13a486db22b8e",
"type": "mqtt in",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "req/bluelinky/car_unlock",
"qos": "0",
"datatype": "auto",
"broker": "bb13a99d.68b8f8",
"nl": false,
"rap": false,
"inputs": 0,
"x": 270,
"y": 620,
"wires": [
[
"99f5c3a41ac3e754",
"ce62ba4f.d86548"
]
]
},
{
"id": "99f5c3a41ac3e754",
"type": "unlock-car",
"z": "866c75dd.edd9a8",
"name": "Unlock car",
"bluelinky": "452a3304.58c8fc",
"x": 1110,
"y": 620,
"wires": [
[
"f487d6d6.a4d568",
"811aa567.e89f98"
]
]
},
{
"id": "ab557a0ea621403a",
"type": "inject",
"z": "866c75dd.edd9a8",
"name": "",
"props": [
{
"p": "payload"
},
{
"p": "topic",
"vt": "str"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "",
"payloadType": "date",
"x": 940,
"y": 600,
"wires": [
[
"99f5c3a41ac3e754"
]
]
},
{
"id": "a525de86e4374518",
"type": "inject",
"z": "866c75dd.edd9a8",
"name": "",
"props": [
{
"p": "payload"
},
{
"p": "topic",
"vt": "str"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "",
"payloadType": "date",
"x": 940,
"y": 740,
"wires": [
[
"7d3ae860.d8c9a8"
]
]
},
{
"id": "0b8cb92c042fe140",
"type": "inject",
"z": "866c75dd.edd9a8",
"name": "",
"props": [
{
"p": "payload"
},
{
"p": "topic",
"vt": "str"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "",
"payloadType": "date",
"x": 940,
"y": 800,
"wires": [
[
"6eebc52c.ee23dc"
]
]
},
{
"id": "ae4c2139b08aaa28",
"type": "inject",
"z": "866c75dd.edd9a8",
"name": "",
"props": [
{
"p": "payload"
},
{
"p": "topic",
"vt": "str"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "",
"payloadType": "date",
"x": 940,
"y": 860,
"wires": [
[
"84a1ae.74912e5"
]
]
},
{
"id": "dd23108ce63f456d",
"type": "get-monthlyreport",
"z": "866c75dd.edd9a8",
"name": "Get monthly report",
"bluelinky": "452a3304.58c8fc",
"x": 1130,
"y": 1280,
"wires": [
[
"e57eb97531129426"
]
]
},
{
"id": "a6e5e8deb52145f1",
"type": "inject",
"z": "866c75dd.edd9a8",
"name": "",
"props": [
{
"p": "payload"
},
{
"p": "topic",
"vt": "str"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "",
"payloadType": "date",
"x": 940,
"y": 1260,
"wires": [
[
"dd23108ce63f456d"
]
]
},
{
"id": "95f1b6f32aafd65b",
"type": "get-tripinfo",
"z": "866c75dd.edd9a8",
"name": "Tripinfo",
"bluelinky": "452a3304.58c8fc",
"x": 1100,
"y": 1220,
"wires": [
[
"e57eb97531129426"
]
]
},
{
"id": "fb2b99958bc48593",
"type": "json",
"z": "866c75dd.edd9a8",
"name": "",
"property": "payload",
"action": "",
"pretty": false,
"x": 750,
"y": 1220,
"wires": [
[
"95f1b6f32aafd65b"
]
]
},
{
"id": "5230ebe391325b17",
"type": "mqtt in",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "req/bluelinky/get_tripinfo",
"qos": "2",
"datatype": "auto",
"broker": "bb13a99d.68b8f8",
"nl": false,
"rap": true,
"rh": 0,
"inputs": 0,
"x": 270,
"y": 1220,
"wires": [
[
"fb2b99958bc48593"
]
]
},
{
"id": "e57eb97531129426",
"type": "debug",
"z": "866c75dd.edd9a8",
"name": "",
"active": false,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"statusVal": "",
"statusType": "auto",
"x": 1470,
"y": 1220,
"wires": []
},
{
"id": "4fdf3b1b7811c89f",
"type": "mqtt in",
"z": "866c75dd.edd9a8",
"name": "",
"topic": "req/bluelinky/get_tripinfo",
"qos": "2",
"datatype": "auto",
"broker": "bb13a99d.68b8f8",
"nl": false,
"rap": true,
"rh": 0,
"inputs": 0,
"x": 270,
"y": 1280,
"wires": [
[
"dd23108ce63f456d"
]
]
}
]
</syntaxhighlight>

=====Kia_eNiro_PV DOIF mit uiTable=====
Mit diesem DOIF Device werden folgende Funktionalitäten abgebildet:
Nun dann noch das DOIF mit dem uiTable für die Status Anzeige und die Steuerung über Pull Down Menüs.

- Status Abfrage
Status jede Stunde zwischen 6 und 23 Uhr (12V min 40%)
Status beim Laden alle 15 Minuten (12V min 40%)
Anzeige des Kilometerzählers
Status des Fahrzeuges zu Hause / unterwegs und beim Laden
Fahrzeug Auf/Zu

- Klimatisierung über das Pull Down Menü
unterschiedliche Temperaturen für Heizen und Kühlen
Aktuelle Temperatur
Heizen/Klima Ein/Aus
Timer für zeitgesteuertes Klimatisieren für den Resttag oder den Nächsten Tag (vor der aktuellen Zeit)
Klimatisierung über "Abfall" Kalender (es geht nur ein Termin pro Tag, dafür aber komfortabel über das Handy)

- Komfort
Reifen Überwachung
Türen / Motorhaube / Kofferraum Überwachung
12V Batterie anzeige, wenn der Ladezustand kleiner 40% ist erfolgt keine weitere Status Abfrage

- ACCU Steuerung
Setzen des Ziel SOC beim Standard Laden
Start/Stop Laden
Accu Stand und berechnete Restkilometer

- Für openWB integratin im uiTable
Wählen des Lademodus
Vorrang EV oder Bat
Sperren des Hausspeichers entweder manuell oder automatisch beim Laden. Der vorherige Zustand wird gespeichert
Die Freigabe erfolgt über die Wechselrichter Implementierung, siehe dort [[Kostal_Plenticore_10_Plus#Externe_Speichersteuerung_.28ExternControl.29|"Externe Speicher Steuerung"]]
Geschätzte Ladezeit
Status Ladepunkt (Plug und Laden)
Lade Status Phasen und Leistung

'''Achtung, die Kia connect Abfragen sind auf ca. 200 pro Tag von Kia limitiert! Durch die Stündliche Status Abfrage im DOIF kommt es natürlich zu Verzögerungen im FHEM Status. Dann einfach einmal manuell abfragen.'''

Die Kommunikation zum Kia BEV ist manchmal sehr träge, z.B. kann eine Status Abfrage auch mal 3 Minuten dauern, deshalb wurde eine Verriegelung implementiert. Es wird ein Status pending/idle angezeigt. Nur wenn der Zustand "idel" ist, können weitere Abfragen gestartet werden. Läuft z.B. die Status Abfrage kann man ein weiteres Kommando anstarten, es wird jedoch erst abgesetzt, wenn das vorherige Kommando fertig ist. Solange bleibt im Pull Down Menü das neue Kommando stehen.

RAW des DOIF
<syntaxhighlight lang="Perl">
defmod Kia_eNiro_PV DOIF ################################################################################################################\
## 1 Kia Connect Status Abfrage erfolgt mit MQTT2 ==> node-ret ==> Kia Connect\
##\
1_Status_getAll\
{if( !([$SELF:state] eq "off") ## DOIF enabled\
and [Kia_connect:req_active] eq "idle"\
and\
( ([+00:15] and ## alle 15 Minuten\
[Kia_connect:atHomeStanding] eq "true" and ## wenn das Auto zuhause ist\
[Kia_connect:charging] eq "true" or ## und es geladen wird\
[:58] and [05:00-23:00] ## ansonsten nur jede Stunde\
) and [Kia_connect:bat12v] > 40 ## aber die 12V Batterie sollte noch genügend Ladung haben\
or [$SELF:cmd_event] eq "set_cmd_1" ## Das reagiert auf den Aufruf mit "set <Device> cmd_*"\
or [$SELF:ui_command_1] eq "Status_getAll" ## Hier wird das uiTable select ausgewertet\
)\
) {\
if( [$SELF:ui_command_1] eq "Status_getAll" ) { ## Hier wurde manuell eingeschaltet\
set_Reading("ui_command_before_1",[$SELF:ui_command_1]);;\
}\
\
fhem_set("Kia_connect getAll");; ## beliebige Kommandos für diesen Block\
\
set_Reading("ui_command_1","---");; ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten\
## kann das Kommando nicht sofort wiederholt werden\
}\
}\
\
2_Klima\
{if( !([$SELF:state] eq "off") ## DOIF enabled\
and [Kia_connect:req_active] eq "idle"\
and\
( [$SELF:ui_command_2] eq "stopClimate" ## Hier wird das uiTable select ausgewertet\
or [$SELF:ui_command_2] eq "startHeating"\
or [$SELF:ui_command_2] eq "startCooling"\
)\
) {\
set_Reading("ui_command_before_2",[$SELF:ui_command_2]);;\
\
if ([$SELF:ui_command_2] eq "startHeating") {\
my $airTemp_value= [Kia_connect:status_airTemp_value_target_Winter];;\
fhem_set('Kia_connect startClimate {"defrost": true, "windscreenHeating": true, "temperature": '.$airTemp_value.' , "unit": "C"}');;\
if (AttrVal("$SELF","verbose",0) >= 0)\
{Log 3, "$SELF 2_Klima : startHeating"};;\
}\
if ([$SELF:ui_command_2] eq "startCooling") {\
my $airTemp_value = [Kia_connect:status_airTemp_value_target_Summer];;\
fhem_set('Kia_connect startClimate {"defrost": false, "windscreenHeating": false, "temperature": '.$airTemp_value.' , "unit": "C"}');;\
if (AttrVal("$SELF","verbose",0) >= 0)\
{Log 3, "$SELF 2_Klima : startCooling"};;\
}\
if ([$SELF:ui_command_2] eq "stopClimate") {\
fhem_set("Kia_connect ".[$SELF:ui_command_2]);;\
if (AttrVal("$SELF","verbose",0) >= 0)\
{Log 3, "$SELF 2_Klima : stopClimate"};;\
}\
fhem_set("Abfall update");;\
\
set_Reading("ui_command_2","---");; ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten\
## kann das Kommando nicht sofort wiederholt werden\
}\
}\
\
3_Laden\
{if( !([$SELF:state] eq "off") ## DOIF enabled\
and [Kia_connect:req_active] eq "idle"\
and\
( [$SELF:ui_command_3] eq "setChargeTargetSoc" ## Hier wird das uiTable select ausgewertet\
or [$SELF:ui_command_3] eq "startCharge"\
or [$SELF:ui_command_3] eq "stopCharge"\
)\
) {\
set_Reading("ui_command_before_3",[$SELF:ui_command_3]);;\
\
if ([$SELF:ui_command_3] eq "setChargeTargetSoc") {\
my $targetSOClist_1_targetSOClevel = [Kia_connect:status_evStatus_reservChargeInfos_targetSOClist_1_targetSOClevel_target];;\
my $targetSOClist_2_targetSOClevel = [Kia_connect:status_evStatus_reservChargeInfos_targetSOClist_2_targetSOClevel_target];;\
fhem_set("Kia_connect setChargeTargetSoc {\"fast\": ".$targetSOClist_1_targetSOClevel.", \"slow\": ".$targetSOClist_2_targetSOClevel."}");;\
} else {\
fhem_set("Kia_connect ".[$SELF:ui_command_3]);; ## beliebige Kommandos für diesen Block\
}\
\
set_Reading("ui_command_3","---");; ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten\
## kann das Kommando nicht sofort wiederholt werden\
}\
}\
\
4_Klima_timer_heizen\
{if( !([$SELF:state] eq "off") ## DOIF enabled\
and\
(\
( [[Abfall_Abfuhr:Kiaheizen_connect_time]] ## Prüfe den Kalender Eintrag\
and [Abfall_Abfuhr:Kiaheizen_connect_date] eq $ymd ## ist es heute?\
)\
or\
( [$SELF:ui_timer_mode] eq "heizen" ## Timer zum Heizen aktiv?\
and [[$SELF:ui_timer_Start]] ## ist es soweit?\
)\
)\
) {\
\
if (AttrVal("$SELF","verbose",0) >= 0)\
{Log 3, "$SELF 4_Klima_timer : startHeating"};;\
set_Reading("ui_timer_mode","Aus");; ## Schalte die Timer Funktion ab\
set_Reading("ui_command_2","startHeating");; ## Es soll geheizt werden\
fhem_set("$SELF 2_Klima");; ## Aktiviere das Heizen\
\
}\
}\
\
5_Klima_timer_kuehlen\
{if( !([$SELF:state] eq "off") ## DOIF enabled\
and\
(\
( [[Abfall_Abfuhr:Kiakuehlen_connect_time]] ## Prüfe den Kalender Eintrag\
and [Abfall_Abfuhr:Kiakuehlen_connect_date] eq $ymd ## ist es heute?\
)\
or\
( [$SELF:ui_timer_mode] eq "kuehlen" ## Timer zum Kühler aktiv?\
and [[$SELF:ui_timer_Start]] ## ist es soweit?\
)\
)\
) {\
\
if (AttrVal("$SELF","verbose",0) >= 0)\
{Log 3, "$SELF 4_Klima_timer : startCooling"};;\
set_Reading("ui_timer_mode","Aus");; ## Schalte die Timer Funktion ab\
set_Reading("ui_command_2","startCooling");; ## Es soll gekühlt werden\
fhem_set("$SELF 2_Klima");; ## Aktiviere das Kühlen\
\
}\
}\
\
6_Auf_Zu\
{if( !([$SELF:state] eq "off") ## DOIF enabled\
and [Kia_connect:req_active] eq "idle"\
and\
( [$SELF:ui_command_2] eq "car_lock" ## Hier wird das uiTable select ausgewertet\
or [$SELF:ui_command_2] eq "car_unlock"\
)\
) {\
set_Reading("ui_command_before_2",[$SELF:ui_command_2]);;\
\
fhem_set("Kia_connect ".[$SELF:ui_command_2]);;\
if (AttrVal("$SELF","verbose",0) >= 0)\
{Log 3, "$SELF 6_Auf_Zu : ".[$SELF:ui_command_2]};;\
\
set_Reading("ui_command_2","---");; ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten\
## kann das Kommando nicht sofort wiederholt werden\
}\
}\
\
7_WB_1_lp_1\
{if( !([$SELF:state] eq "off") ## DOIF enabled\
and\
( [$SELF:ui_command_4] eq "SofortLaden" ## Hier wird das uiTable select ausgewertet\
or [$SELF:ui_command_4] eq "Min+PV"\
or [$SELF:ui_command_4] eq "NurPV"\
or [$SELF:ui_command_4] eq "Stop"\
or [$SELF:ui_command_4] eq "Standby"\
or [$SELF:ui_command_4] eq "Vorrang_EV"\
or [$SELF:ui_command_4] eq "Vorrang_Bat"\
)\
) {\
set_Reading("ui_command_before_4",[$SELF:ui_command_4]);;\
\
if ([$SELF:ui_command_4] eq "Vorrang_Bat" OR [$SELF:ui_command_4] eq "Vorrang_EV") {\
if ([$SELF:ui_command_4] eq "Vorrang_EV") {\
fhem_set("WB_1 priorityModeEVBattery 1");;\
} else {\
fhem_set("WB_1 priorityModeEVBattery 0");;\
}\
if (AttrVal("$SELF","verbose",0) >= 0)\
{Log 3, "$SELF 7_WB_1_lp_1 : ".[$SELF:ui_command_4]};;\
} else {\
fhem_set("WB_1 Lademodus ".[$SELF:ui_command_4]);;\
if (AttrVal("$SELF","verbose",0) >= 0)\
{Log 3, "$SELF 7_WB_1_lp_1 : Lademodus ".[$SELF:ui_command_4]};;\
}\
\
set_Reading("ui_command_4","---");; ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten\
## kann das Kommando nicht sofort wiederholt werden\
}\
}\
\
8_Speicher_sperren\
{if( !([$SELF:state] eq "off") ## DOIF enabled\
and\
( [$SELF:ui_command_4] eq "Hausspeicher_Sperren" ## Hier wird das uiTable select ausgewertet\
or [WB_1:lp_1_ChargeStat] eq "loading" and\
[WB_1:lp_1_PlugStat] eq "Plugged in"\
)\
) {\
set_Reading("ui_command_before_4",[$SELF:ui_command_4]);;\
\
if([$SELF:WR_1_Speicher_1_ExternControl_smart_laden_before] eq "---") {\
\
if([$SELF:SpeicherExternTrigger] eq "gesperrt" and\
[WR_1_API:Battery_InternControl_MinHomeConsumption] eq "30000" ) {\
set_Reading("WR_1_Speicher_1_ExternControl_smart_laden_before","aktiv");;\
if (AttrVal("$SELF","verbose",0) >= 0)\
{Log 3, "$SELF 8_Speicher_sperren : smart_laden_before aktiv"};;\
} else {\
set_Reading("WR_1_Speicher_1_ExternControl_smart_laden_before","inaktiv");;\
if (AttrVal("$SELF","verbose",0) >= 0)\
{Log 3, "$SELF 8_Speicher_sperren : smart_laden_before inaktiv"};;\
}\
\
fhem_set("WR_1_Speicher_1_ExternControl cmd_2");;\
if (AttrVal("$SELF","verbose",0) >= 0)\
{Log 3, "$SELF 8_Speicher_sperren : smart_Laden startet"};;\
}\
\
set_Reading("ui_command_4","---");; ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten\
## kann das Kommando nicht sofort wiederholt werden\
}\
}\
\
9_WB_1_Zaehler_Statistiken\
{if( !([$SELF:state] eq "off") and ## DOIF enabled\
[00:01]\
) {\
fhem("setreading WB_1 lp_1_kWhCounter_init_Day ".[WB_1:lp_1_kWhCounter]);;\
fhem("setreading WB_1 lp_2_kWhCounter_init_Day ".[WB_1:lp_2_kWhCounter]);;\
\
if ($mday eq 1)\
{\
fhem("setreading WB_1 lp_1_kWhCounter_init_Month ".[WB_1:lp_1_kWhCounter]);;\
fhem("setreading WB_1 lp_2_kWhCounter_init_Month ".[WB_1:lp_2_kWhCounter]);;\
\
if ($yday eq 0)\
{\
fhem("setreading WB_1 lp_1_kWhCounter_init_Year ".[WB_1:lp_1_kWhCounter]);;\
fhem("setreading WB_1 lp_2_kWhCounter_init_Year ".[WB_1:lp_2_kWhCounter]);;\
}\
}\
}\
}
attr Kia_eNiro_PV DbLogExclude .*
attr Kia_eNiro_PV disable 0
attr Kia_eNiro_PV group PV Eigenverbrauch-Steuerung
attr Kia_eNiro_PV icon car
attr Kia_eNiro_PV room Strom->Photovoltaik
attr Kia_eNiro_PV sortby 401
attr Kia_eNiro_PV uiTable {\
package ui_Table;;\
## $TR{0} = "style='color:yellow;;text-align:left;;font-weight:bold;;font-size:18px'";; ## Reihe 0 für Überschrift\
$TABLE = "style='width:100%;;'";;\
\
$TD{0..9}{0} = "align='center' style='font-size:16px;;border-right-style:solid;;border-color:darkgreen;;border-right-width:2px;;width:26%'";;\
\
$TD{0..9}{1} = "style='border-top-style:solid;;border-bottom-style:solid;;border-right-style:solid;;border-color:darkgreen;;border-top-width:2px;;border-bottom-width:2px;;border-right-width:1px;;width:36%;;font-weight:bold;;'";;\
$TD{0..9}{2..4} = "style='border-top-style:solid;;border-bottom-style:solid;;border-right-style:solid;;border-color:darkgreen;;border-top-width:2px;;border-bottom-width:2px;;border-right-width:1px;;width:8%;;text-align:center;;'";;\
$TD{0..9}{5} = "style='border-top-style:solid;;border-bottom-style:solid;;border-right-style:solid;;border-color:darkgreen;;border-top-width:2px;;border-bottom-width:2px;;border-right-width:2px;;width:8%;;text-align:center;;'";;\
\
sub FUNC_batt {\
my($val)=@_;;\
my $ret="position:absolute;;left:".(90*$val/100)."px;;width:90px;;height:20px;;background:linear-gradient( to right,#F8F8E0 ".(90-(90*$val/100))."px,rgba(0,0,0,0) ".(90-(90*$val/100))."px);;";;\
return $ret;;\
}\
sub FUNC_Status {\
my($value, $min, $colorMin, $statusMin, $colorMiddel, $statusMiddle, $max, $colorMax, $statusMax)=@_;;\
my $ret = ($value < $min)? '<span style="color:'.$colorMin.'">'.$statusMin.'</span>' : ($value > $max)? '<span style="color:'.$colorMax.'">'.$statusMax.'</span>' : '<span style="color:'.$colorMiddel.'">'.$statusMiddle.'</span>';;\
return $ret;;\
}\
sub FUNC_Status_Laden {\
my($car)=@_;;\
my $charge = (::ReadingsVal($car,"charging","false") eq "true");;\
my $athome = (::ReadingsVal($car,"atHomeStanding","false") eq "true");;\
my $chargeathome = ($charge && $athome);;\
my $connectedathome = ($athome && ::ReadingsVal($car,"connected","false") eq "true");;\
\
my $ret = ($chargeathome ? "lädt zu Hause" : ($connectedathome ? "angeschlossen zu Hause" : ($athome ? "zu Hause" : ($charge ? "Lädt auswärts" : "unterwegs"))));;\
return $ret;;\
}\
sub FUNC_tire {\
my($car)=@_;;\
my $ret = '<span style="color:green">Reifendruck okay</span>';;\
\
if (::ReadingsVal($car,"status_tirePressureLamp_tirePressureLampAll","1") != 0) {\
my $VL = (::ReadingsVal($car,"status_tirePressureLamp_tirePressureLampFL","1") eq "0")?0:1;;\
my $HL = (::ReadingsVal($car,"status_tirePressureLamp_tirePressureLampRL","1") eq "0")?0:1;;\
my $VR = (::ReadingsVal($car,"status_tirePressureLamp_tirePressureLampFR","1") eq "0")?0:1;;\
my $HR = (::ReadingsVal($car,"status_tirePressureLamp_tirePressureLampRR","1") eq "0")?0:1;;\
$ret = '<span style="color:red">Reifen Störung<br>';;\
if ($VL == 1){$ret.=' /VL'};;\
if ($VR == 1){$ret.=' /VR'};;\
if ($HL == 1){$ret.=' /HL'};;\
if ($HR == 1){$ret.=' /HR'};;\
$ret = $ret.'</span>';;\
}\
return $ret;;\
}\
sub FUNC_door {\
my($car)=@_;;\
my $ret = '<span style="color:green">Türen okay<br></span>';;\
\
if (::ReadingsVal($car,"status_doorLock","false") ne "true") {\
my $VL = (::ReadingsVal($car,"status_doorOpen_frontLeft",1) == 0)?0:1;;\
my $HL = (::ReadingsVal($car,"status_doorOpen_backLeft",1) == 0)?0:1;;\
my $VR = (::ReadingsVal($car,"status_doorOpen_frontRight",1) == 0)?0:1;;\
my $HR = (::ReadingsVal($car,"status_doorOpen_backRight",1) == 0)?0:1;;\
$ret = '<span style="color:red">Tür offen<br>';;\
if ($VL == 1){$ret.=' /VL'};;\
if ($VR == 1){$ret.=' /VR'};;\
if ($HL == 1){$ret.=' /HL'};;\
if ($HR == 1){$ret.=' /HR'};;\
$ret = $ret.'</span>';;\
}\
if (::ReadingsVal($car,"status_trunkOpen","true") eq "true") {\
$ret.='<span style="color:red"> Kofferraum offen</span>';;\
}\
if (::ReadingsVal($car,"status_hoodOpen","true") eq "true") {\
$ret.='<span style="color:red"> Motorhaube offen</span>';;\
}\
return $ret;;\
}\
}\
\
"$SELF"|"Kommando ".::ReadingsTimestamp("Kia_connect","status_time","")."<dd>Auswahl / Kommunikation / Tacho / Info Status</dd>" | widget([$SELF:ui_command_1],"uzsuDropDown,---,Status_getAll,car_lock,car_unlock")|(([Kia_connect:req_active] eq "idle")?'<span style="color:green">idle</span>' : '<span style="color:red">'.[Kia_connect:req_active].'</span>') |::round([Kia_connect:odometer_value],0)." km"|FUNC_Status_Laden("Kia_connect")\
\
|"Accu<dd>Steuerung / Target Soc / Accu Status</dd>" |widget([$SELF:ui_command_3],"uzsuDropDown,---,setChargeTargetSoc,stopCharge,startCharge")|"Target SOC".widget([Kia_connect:status_evStatus_reservChargeInfos_targetSOClist_2_targetSOClevel_target],"selectnumbers,50,10,100,0,lin")." %"|""| FUNC_Status([Kia_connect:range],150,"red",[Kia_connect:range],"orange",[Kia_connect:range],250,"green",[Kia_connect:range])." km"."<div style='border-width:2px;;border-style:solid;;border-color:gray;;position:relative;;width:90px;;height:20px;;background:linear-gradient( to right, red 0px,yellow 30px,green 50px);;'>".STY(" ",FUNC_batt([Kia_connect:batSOC])).STY(::round([Kia_connect:batSOC],0)."%","font-size:16px;;position:absolute;;top:2px;;left:30px")."</div>"\
\
|"Komfort<dd>Timer / Klima / Reifen / Türen / Accu Status 12V</dd>" |widget([$SELF:ui_timer_mode],"uzsuDropDown,Aus,heizen,kuehlen").widget([$SELF:ui_timer_Start],"time")|\
((::ReadingsVal("Abfall_Abfuhr","Kiaheizen_days",0) != 0)?"Klimatisierung<br>".[Abfall_Abfuhr:Kiaheizen_connect_date]." ".[Abfall_Abfuhr:Kiaheizen_connect_time]:(([$SELF:ui_timer_mode] ne "Aus")?"Klimatisierung<br>".[$SELF:timer_04_c04]:""))|FUNC_tire("Kia_connect")."<br>".FUNC_door("Kia_connect")|\
"12 V<div style='border-width:2px;;border-style:solid;;border-color:gray;;position:relative;;width:90px;;height:20px;;background:linear-gradient( to right, red 0px,yellow 30px,green 50px);;'>".STY(" ",FUNC_batt([Kia_connect:bat12v])).STY(::round([Kia_connect:bat12v],0)."%","font-size:16px;;position:absolute;;top:2px;;left:30px")."</div>"\
\
|"<dd> Auswahl / Temperatur / Klima Status / Temperatur innen</dd>"| widget([$SELF:ui_command_2],"uzsuDropDown,---,stopClimate,startHeating,startCooling")|\
"Heat".widget([Kia_connect:status_airTemp_value_target_Winter],"selectnumbers,20,1,27,0,lin")."°C<br>Cool".widget([Kia_connect:status_airTemp_value_target_Sommer],"selectnumbers,16,1,25,0,lin")."°C"|(([Kia_connect:status_airCtrlOn] eq "true")?'<span style="color:red">Klima läuft</span>':'<span style="color:green">Klima aus</span>')."<br>".(([Kia_connect:status_defrost] eq "true")?'Defrost ein':'Defrost aus') |"Aktuell<br>".[Kia_connect:status_airTemp_value]."°C"\
\
|"WallBox (WB_1_lp1)<dd>Lademodus / Info Status / Ladezeit / Leistung</dd>"|[WB_1:ChargeMode]."<br>".widget([$SELF:ui_command_4],"uzsuDropDown,---,SofortLaden,Min+PV,NurPV,Stop,Standby,Vorrang_EV,Vorrang_Bat,Hausspeicher_Sperren")|[WB_1:lp_1_PlugStat]." ".[WB_1:lp_1_ChargeStat]|[WB_1:lp_1_TimeRemaining]|[WB_1:lp_1_countPhasesInUse]."P ".[WB_1:lp_1_AConfigured]."A<br>".[WB_1:lp_1_W]." W"

setstate Kia_eNiro_PV 2022-01-12 13:24:24 ui_command_1 ---
setstate Kia_eNiro_PV 2022-01-10 09:18:53 ui_command_2 ---
setstate Kia_eNiro_PV 2021-11-09 07:56:54 ui_command_3 ---
setstate Kia_eNiro_PV 2022-01-12 13:02:41 ui_command_4 ---
setstate Kia_eNiro_PV 2022-01-12 13:02:41 ui_command_before_4 ---
setstate Kia_eNiro_PV 2021-11-29 09:56:58 ui_timer_Start 10:30
setstate Kia_eNiro_PV 2021-12-02 07:00:00 ui_timer_mode Aus

</syntaxhighlight>

=====Kostal Plenticore mit Speicher=====
Zu diesem Thema gibt es noch eine andere Wiki Seite, die alles rund um den Wechselrichter und vieles mehr erklärt.
[[https://wiki.fhem.de/wiki/Kostal_Plenticore_10_Plus|Kostal Plenticore Plus]]
Die hier beschriebene openWB und Kia connect Anbindung bedient sich der Hausspeichersteuerung, um diesen beim Laden der BEV zu sperren.
Im DOIF kann an den entsprechenden Stellen natürlich auch ein anders Kommando zum Sperren verwendet werden.

== Weiterführende Links ==
* [https://openwb.de openWB Website]
* [https://github.com/snaptec/openWB/wiki openWB Wiki bei GitHub]
* [https://www.openwb.de/forum/viewtopic.php?f=6&t=4159 openWB Forum (Diskussion zu diesem Artikel)]
* [https://openwb.de/forum/viewtopic.php?t=577 openWB Forum (Liste der MQTT-Topics)]

[[Kategorie:Elektromobilität]]
[[Kategorie:HOWTOS]]

Einrichten der Bluetooth-Thermostate von eQ-3

2023-02-25T20:16:53Z

F Klee:

Die Firma eQ-3 stellt verschiedene elektronische Heizkörperthermostate her. Das Eqiva BLUETOOTH® Smart Heizkörperthermostat (CC-RT-BLE-EQ) kann auch von FHEM gesteuert werden. Voraussetzung ist natürlich ein Bluetooth-Empfänger (RasPi 3+4 oder Bluetooth-Dongle).
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth, die genau gleich aussehen. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}
== Bluetooth einrichten ==
Standardmäßig sollte Bluetooth auf dem Raspberry Pi schon eingerichtet sein. Nutzt man einen B+ mit Dongle (z.B. als Verlängerung), so müssen unter Umständen folgende Pakete installiert werden:
<pre>sudo apt-get install bluetooth, bluez</pre>
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre>

<pre><policy user="fhem">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.GattCharacteristic1"/>
<allow send_interface="org.bluez.GattDescriptor1"/>
<allow send_interface="org.freedesktop.DBus.ObjectManager"/>
<allow send_interface="org.freedesktop.DBus.Properties"/>
</policy></pre>
<pre>sudo systemctl restart dbus</pre>
Für den User pi muss natürlich fhem durch pi ersetzt werden.

== Thermostat in FHEM definieren ==
=== Pairing ===
Die Thermostate müssen mit dem RasPi gepaired werden. Drücke dazu das Rad am Thermostat bis „Pair“ im Display erscheint. Dann führe folgende Schritte aus:
<pre>
$ sudo bluetoothctl
[bluetooth]# power on
[bluetooth]# agent on
[bluetooth]# default-agent
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...
[bluetooth]# scan off
[bluetooth]# pair 00:1A:22:06:A7:83
[agent] Enter passkey (number in 0-999999): <enter pin>
[bluetooth]# trust 00:1A:22:06:A7:83
[bluetooth]# disconnect 00:1A:22:06:A7:83
[bluetooth]# exit

Optional steps:
[bluetooth]# devices - to list all bluetooth devices
[bluetooth]# info 00:1A:22:06:A7:83
Device 00:1A:22:06:A7:83 (public)
Name: CC-RT-BLE
Alias: CC-RT-BLE
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)
ManufacturerData Key: 0x0000
ManufacturerData Value:
00 00 00 00 00 00 00 00 00 .........</pre>
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).
Unter Umständen wird nicht nach <code>Enter passkey</code> gefragt. Wichtig ist die Erfolgsmeldung.<br>
Die Befehle bedeuten im Einzelnen:
<pre>$ sudo bluetoothctl</pre>
Startet das Bluetoothctl-Tool, das eine Befehlszeilenschnittstelle zu BlueZ ist. <code>sudo</code> ist häufig nicht erforderlich. Die Ausgabe sollte ähnlich der folgenden aussehen:
<pre>[CHG] Controller E4:5F:01:F0:0E:98 Pairable: yes
[bluetooth]#</pre>
Die Zeile „[CHG] Controller“ (oder auch [NEW]) zeigt die Informationen zu deinem Bluetooth-Chip an. Die letzte Zeile ist die Eingabeaufforderung von bluetoothctl.

Da der Kopplungsvorgang eine Authentifizierung per PIN beinhaltet, ist eine Registrierung bei einem Authentifizierungsagenten erforderlich. Der Agent bearbeitet die PIN-Abfrage. Gib dazu Folgendes ein:
<pre>[bluetooth]# agent on
Agent registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]#</pre>
Beachte, dass die Registrierung des Agenten während der Kopplung mit einem Gerät, das keine Benutzerbestätigung für den Kopplungsversuch erfordert, keine negativen Auswirkungen hat und sicher ist.<br>
An dieser Stelle kannst du mit der Suche nach entfernten Bluetooth-Geräten fortfahren:
<pre>[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...
[NEW] Device <bluetooth address> <name></pre>
Stoppt man den Scan mit <code>[bluetooth]# scan off</code>, so werden die Ergebnisse der Geräteerkennung nach einer gewissen Zeit ungültig.
<pre>[DEL] Device 00:1A:22:XX:XX:XX CC-RT-BLE</pre>
Vorher kann das Pairing gestartet werden:
<pre>[bluetooth]# pair 00:1A:22:06:A7:83</pre>
Nun einfach der Anzeige folgen. Am Ende sollte eine Erfolgsmeldung stehen. Falls nicht, die Prozedur ab <code>[bluetooth]# scan on</code> wiederholen. Danach muss das Gerät noch als Vertrauenswürdig deklariert
<pre>[bluetooth]# trust 00:1A:22:06:A7:83</pre>
und wieder getrennt werden
<pre>[bluetooth]# disconnect 00:1A:22:06:A7:83</pre>
Danach kannst du über
<pre>[bluetooth]# info 00:1A:22:06:A7:83</pre>
nachsehen, ob alles korrekt ist. Das Gerät kann nun in FHEM definiert werden.

=== Einrichten mit Perl-Modul 10_EQ3BT ===
Die eQ-3 Heizkörperthermostate können einfach über
define <name> EQ3BT <mac address>
eingebunden werden.
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}

=== Einrichten mit fhempy ===
fhempy ermöglicht das Schreiben von FHEM-Modulen in der Programmiersprache Python. Erforderlich ist Python 3.9 oder höher (NICHT 2!), weshalb Debian Bullseye erforderlich ist. Es ist auch möglich, fhempy auf Peers zu installieren, um dadurch die Bluetooth-Reichweite zu erhöhen. Dadurch ist eine komplette Abdeckung des Hauses möglich. Auf den Peers muss FHEM nicht installiert werden. Neben dem Raspberry Pi Zero eignet sich auch z.B. der Radxa Rock Pi Zero, getestet mit Armbian. Ein Radxa Pi S ist sehr verführerisch. Dabei ist aber auf den SoC zu achten. Der alte RK3308B (ohne S) läuft nur unter dem Radxa debos (buster) mit Bluetooth. Mit Armbian und einem Bluetooth-Dongle geht es aber auch. Die Peers können aus FHEM heraus verwaltet werden.

==== Installation auf FHEM-Server ====
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit

<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git libprotocol-websocket-perl</pre>

Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt
update</pre>
Ist das Update abgeschlossen, können wir fhempy einrichten:
<pre>define fhempy_local BindingsIo fhempy</pre>
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.

Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre>
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.

==== Installation des fhempy-Peer ====
fhempy läuft nicht nur lokal auf dem FHEM-Server. Zur Reichweitenerhöhung kann auch ein fhempy-Peer auf einem oder mehreren RasPi’s installiert und diese über die Wohnung verteilt werden. Geeignet ist natürlich auch ein RasPi, der zur Visualisierung dient.
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi
<pre>pip3 install --upgrade fhempy</pre>
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer
<pre>fhempy</pre>
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre>
fhempy läuft nun unter dem User pi. Möchtest du das ändern, so schau in die Datei <code>fhempy.service</code> im Verzeichnis <code>/etc/systemd/system/</code> Hinterher das sudo systemctl daemon-reload nicht vergessen.
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre>

== Bekannte Probleme ==
=== Fehlermeldung nach fhempy-Installation ===
Meldet pip3 folgendes
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre>
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen
<pre>export PATH=$PATH:/home/myname/.local/bin</pre>
also z.B.
<pre>export PATH=$PATH:/home/pi/.local/bin</pre>

=== Keine Reaktion auf Einstellen der Offset-Temperatur ===
Zur Zeit scheint es ein Softwareproblem beim Einstellen der Offset-Temperatur über Bluetooth zu geben (Version 146 oder kleiner). Die Einstellung wird übertragen, wirkt sich aber nicht auf das Thermostat aus. Erst wenn man die Einstellung über das Menü am Thermostat bestätigt (oder gleich dort einstellt), reagiert das Thermostat. Das Problem tritt auch bei der Bedienung über die App auf.

=== Pairing wird hartnäckig verweigert ===
Manchmal klappt das Pairing nicht, obwohl alles in Ordnung scheint. Ein <code>sudo hciconfig hci0 down</code>, gefolgt von einem <code>hciconfig hci0 up</code> eventuell mit einem <code>sudo hciconfig hci0 reset</code> dazwischen kann helfen.

== Links ==
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}

[[Kategorie:Heizungsventile]]
[[Kategorie:Bluetooth]]

Einrichten der Bluetooth-Thermostate von eQ-3

2023-02-25T20:15:15Z

F Klee: Beschreibung der Installation von fhempy auf Bullseye reduziert, Pairing ist immer erforderlich, deshalb an den Anfang verschoben.

Die Firma eQ-3 stellt verschiedene elektronische Heizkörperthermostate her. Das Eqiva BLUETOOTH® Smart Heizkörperthermostat (CC-RT-BLE-EQ) kann auch von FHEM gesteuert werden. Voraussetzung ist natürlich ein Bluetooth-Empfänger (RasPi 3+4 oder Bluetooth-Dongle).
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth, die genau gleich aussehen. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}
== Bluetooth einrichten ==
Standardmäßig sollte Bluetooth auf dem Raspberry Pi schon eingerichtet sein. Nutzt man einen B+ mit Dongle (z.B. als Verlängerung), so müssen unter Umständen folgende Pakete installiert werden:
<pre>sudo apt-get install bluetooth, bluez</pre>
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre>

<pre><policy user="fhem">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.GattCharacteristic1"/>
<allow send_interface="org.bluez.GattDescriptor1"/>
<allow send_interface="org.freedesktop.DBus.ObjectManager"/>
<allow send_interface="org.freedesktop.DBus.Properties"/>
</policy></pre>
<pre>sudo systemctl restart dbus</pre>
Für den User pi muss natürlich fhem durch pi ersetzt werden.

== Thermostat in FHEM definieren ==
=== Pairing ===
Die Thermostate müssen mit dem RasPi gepaired werden. Drücke dazu das Rad am Thermostat bis „Pair“ im Display erscheint. Dann führe folgende Schritte aus:
<pre>
$ sudo bluetoothctl
[bluetooth]# power on
[bluetooth]# agent on
[bluetooth]# default-agent
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...
[bluetooth]# scan off
[bluetooth]# pair 00:1A:22:06:A7:83
[agent] Enter passkey (number in 0-999999): <enter pin>
[bluetooth]# trust 00:1A:22:06:A7:83
[bluetooth]# disconnect 00:1A:22:06:A7:83
[bluetooth]# exit

Optional steps:
[bluetooth]# devices - to list all bluetooth devices
[bluetooth]# info 00:1A:22:06:A7:83
Device 00:1A:22:06:A7:83 (public)
Name: CC-RT-BLE
Alias: CC-RT-BLE
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)
ManufacturerData Key: 0x0000
ManufacturerData Value:
00 00 00 00 00 00 00 00 00 .........</pre>
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).
Unter Umständen wird nicht nach <code>Enter passkey</code> gefragt. Wichtig ist die Erfolgsmeldung.<br>
Die Befehle bedeuten im Einzelnen:
<pre>$ sudo bluetoothctl</pre>
Startet das Bluetoothctl-Tool, das eine Befehlszeilenschnittstelle zu BlueZ ist. <code>sudo</code> ist häufig nicht erforderlich. Die Ausgabe sollte ähnlich der folgenden aussehen:
<pre>[CHG] Controller E4:5F:01:F0:0E:98 Pairable: yes
[bluetooth]#</pre>
Die Zeile „[CHG] Controller“ (oder auch [NEW]) zeigt die Informationen zu deinem Bluetooth-Chip an. Die letzte Zeile ist die Eingabeaufforderung von bluetoothctl.

Da der Kopplungsvorgang eine Authentifizierung per PIN beinhaltet, ist eine Registrierung bei einem Authentifizierungsagenten erforderlich. Der Agent bearbeitet die PIN-Abfrage. Gib dazu Folgendes ein:
<pre>[bluetooth]# agent on
Agent registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]#</pre>
Beachte, dass die Registrierung des Agenten während der Kopplung mit einem Gerät, das keine Benutzerbestätigung für den Kopplungsversuch erfordert, keine negativen Auswirkungen hat und sicher ist.<br>
An dieser Stelle kannst du mit der Suche nach entfernten Bluetooth-Geräten fortfahren:
<pre>[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...
[NEW] Device <bluetooth address> <name></pre>
Stoppt man den Scan mit <code>[bluetooth]# scan off</code>, so werden die Ergebnisse der Geräteerkennung nach einer gewissen Zeit ungültig.
<pre>[DEL] Device 00:1A:22:XX:XX:XX CC-RT-BLE</pre>
Vorher kann das Pairing gestartet werden:
<pre>[bluetooth]# pair 00:1A:22:06:A7:83</pre>
Nun einfach der Anzeige folgen. Am Ende sollte eine Erfolgsmeldung stehen. Falls nicht, die Prozedur ab <code>[bluetooth]# scan on</code> wiederholen. Danach muss das Gerät noch als Vertrauenswürdig deklariert
<pre>[bluetooth]# trust 00:1A:22:06:A7:83</pre>
und wieder getrennt werden
<pre>[bluetooth]# disconnect 00:1A:22:06:A7:83</pre>
Danach kannst du über
<pre>[bluetooth]# info 00:1A:22:06:A7:83</pre>
nachsehen, ob alles korrekt ist. Das Gerät kann nun in FHEM definiert werden.

=== Einrichten mit Perl-Modul 10_EQ3BT ===
Die eQ-3 Heizkörperthermostate können einfach über
define <name> EQ3BT <mac address>
eingebunden werden.
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}

=== Einrichten mit fhempy ===
fhempy ermöglicht das Schreiben von FHEM-Modulen in der Programmiersprache Python. Erforderlich ist Python 3.9 oder höher (NICHT 2!), weshalb Debian Bullseye erforderlich ist. Es ist auch möglich, fhempy auf Peers zu installieren, um dadurch die Bluetooth-Reichweite zu erhöhen. Dadurch ist eine komplette Abdeckung des Hauses möglich. Auf den Peers muss FHEM nicht installiert werden. Neben dem Raspberry Pi Zero eignet sich auch z.B. der Radxa Rock Pi Zero, getestet mit Armbian. Ein Radxa Pi S ist sehr verführerisch. Dabei ist aber auf den SoC zu achten. Der alte RK3308B (ohne S) läuft nur unter dem Radxa debos (buster) mit Bluetooth. Mit Armbian und einem Bluetoothdongle geht es aber auch. Die Peers können aus FHEM heraus verwaltet werden.

==== Installation auf FHEM-Server ====
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit

<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git libprotocol-websocket-perl</pre>

Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt
update</pre>
Ist das Update abgeschlossen, können wir fhempy einrichten:
<pre>define fhempy_local BindingsIo fhempy</pre>
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.

Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre>
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.

==== Installation des fhempy-Peer ====
fhempy läuft nicht nur lokal auf dem FHEM-Server. Zur Reichweitenerhöhung kann auch ein fhempy-Peer auf einem oder mehreren RasPi’s installiert und diese über die Wohnung verteilt werden. Geeignet ist natürlich auch ein RasPi, der zur Visualisierung dient.
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi
<pre>pip3 install --upgrade fhempy</pre>
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer
<pre>fhempy</pre>
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre>
fhempy läuft nun unter dem User pi. Möchtest du das ändern, so schau in die Datei <code>fhempy.service</code> im Verzeichnis <code>/etc/systemd/system/</code> Hinterher das sudo systemctl daemon-reload nicht vergessen.
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre>

== Bekannte Probleme ==
=== Fehlermeldung nach fhempy-Installation ===
Meldet pip3 folgendes
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre>
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen
<pre>export PATH=$PATH:/home/myname/.local/bin</pre>
also z.B.
<pre>export PATH=$PATH:/home/pi/.local/bin</pre>

=== Keine Reaktion auf Einstellen der Offset-Temperatur ===
Zur Zeit scheint es ein Softwareproblem beim Einstellen der Offset-Temperatur über Bluetooth zu geben (Version 146 oder kleiner). Die Einstellung wird übertragen, wirkt sich aber nicht auf das Thermostat aus. Erst wenn man die Einstellung über das Menü am Thermostat bestätigt (oder gleich dort einstellt), reagiert das Thermostat. Das Problem tritt auch bei der Bedienung über die App auf.

=== Pairing wird hartnäckig verweigert ===
Manchmal klappt das Pairing nicht, obwohl alles in Ordnung scheint. Ein <code>sudo hciconfig hci0 down</code>, gefolgt von einem <code>hciconfig hci0 up</code> eventuell mit einem <code>sudo hciconfig hci0 reset</code> dazwischen kann helfen.

== Links ==
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}

[[Kategorie:Heizungsventile]]
[[Kategorie:Bluetooth]]

Einrichten der Bluetooth-Thermostate von eQ-3

2023-02-22T06:52:42Z

F Klee: Hinweis auf Python3.9 ergänzt

Die Firma eQ-3 stellt verschiedene elektronische Heizkörperthermostate her. Das Eqiva BLUETOOTH® Smart Heizkörperthermostat (CC-RT-BLE-EQ) kann auch von FHEM gesteuert werden. Voraussetzung ist natürlich ein Bluetooth-Empfänger (RasPi 3+4 oder Bluetooth-Dongle).
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth, die genau gleich aussehen. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}
== Bluetooth einrichten ==
Standardmäßig sollte Bluetooth auf dem Raspberry Pi schon eingerichtet sein. Nutzt man einen B+ mit Dongle (z.B. als Verlängerung), so müssen unter Umständen folgende Pakete installiert werden:
<pre>sudo apt-get install bluetooth, bluez</pre>
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre>

<pre><policy user="fhem">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.GattCharacteristic1"/>
<allow send_interface="org.bluez.GattDescriptor1"/>
<allow send_interface="org.freedesktop.DBus.ObjectManager"/>
<allow send_interface="org.freedesktop.DBus.Properties"/>
</policy></pre>
<pre>sudo systemctl restart dbus</pre>
Für den User pi muss natürlich fhem durch pi ersetzt werden.

== Thermostat in FHEM definieren ==
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:
<pre>pi@raspberrypi ~ $ bluetoothctl
[NEW] Controller 00:1A:7D:XX:XX:XX raspberrypi [default]
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...
[bluetooth]# scan off</pre>
Die Geräte tragen den Namen CC-RT-BLE.

=== Einrichten mit Perl-Modul 10_EQ3BT ===
Die eQ-3 Heizkörperthermostate können einfach über
define <name> EQ3BT <mac address>
eingebunden werden.
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}

=== Einrichten mit fhempy ===
fhempy ermöglicht das Schreiben von FHEM-Modulen in der Programmiersprache Python. Erforderlich ist Python 3.8 oder höher (NICHT 2!), weshalb Debian Bullseye empfehlenswert ist. Es ist auch möglich, fhempy auf Peers zu installieren, um dadurch die Bluetooth-Reichweite zu erhöhen. Dadurch ist eine komplette Abdeckung des Hauses möglich. Auf den Peers muss FHEM nicht installiert werden. Neben dem Raspberry Pi Zero eignet sich auch z.B. der Radxa Rock Pi Zero, getestet mit Armbian. Die Peers können aus FHEM heraus verwaltet werden.
==== Installation auf FHEM-Server ====
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit

[Debian 11 (Bullseye)]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git libprotocol-websocket-perl</pre>

{{Randnotiz|RNTyp=r|RNText=Inzwischen ist Python3.9 zwingend erforderlich.}}
[alle anderen]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git</pre>
und als nächstes
<pre>
sudo cpan Protocol::WebSocket</pre>

Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt
update</pre>
Ist das Update abgeschlossen, können wir fhempy einrichten:
<pre>define fhempy_local BindingsIo fhempy</pre>
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.

Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre>
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.

==== Installation des fhempy-Peer ====
fhempy läuft nicht nur lokal auf dem FHEM-Server. Zur Reichweitenerhöhung kann auch ein fhempy-Peer auf einem oder mehreren RasPi’s installiert und diese über die Wohnung verteilt werden. Geeignet ist natürlich auch ein RasPi, der zur Visualisierung dient.
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi
<pre>pip3 install --upgrade fhempy</pre>
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer
<pre>fhempy</pre>
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre>
fhempy läuft nun unter dem User pi. Möchtest du das ändern, so schau in die Datei <code>fhempy.service</code> im Verzeichnis <code>/etc/systemd/system/</code> Hinterher das sudo systemctl daemon-reload nicht vergessen.
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre>

== Pairing ==
Die Thermostate müssen mit dem RasPi gepaired werden. Drücke dazu das Rad am Thermostat bis „Pair“ im Display erscheint. Dann führe folgende Schritte aus:
<pre>
$ sudo bluetoothctl
[bluetooth]# power on
[bluetooth]# agent on
[bluetooth]# default-agent
[bluetooth]# scan on
[bluetooth]# scan off
[bluetooth]# pair 00:1A:22:06:A7:83
[agent] Enter passkey (number in 0-999999): <enter pin>
[bluetooth]# trust 00:1A:22:06:A7:83
[bluetooth]# disconnect 00:1A:22:06:A7:83
[bluetooth]# exit

Optional steps:
[bluetooth]# devices - to list all bluetooth devices
[bluetooth]# info 00:1A:22:06:A7:83
Device 00:1A:22:06:A7:83 (public)
Name: CC-RT-BLE
Alias: CC-RT-BLE
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)
ManufacturerData Key: 0x0000
ManufacturerData Value:
00 00 00 00 00 00 00 00 00 .........</pre>
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).
Unter Umständen wird nicht nach <code>Enter passkey</code> gefragt. Wichtig ist die Erfolgsmeldung.<br>
Die Befehle bedeuten im Einzelnen:
<pre>$ sudo bluetoothctl</pre>
Startet das Bluetoothctl-Tool, das eine Befehlszeilenschnittstelle zu BlueZ ist. <code>sudo</code> ist häufig nicht erforderlich. Die Ausgabe sollte ähnlich der folgenden aussehen:
<pre>[CHG] Controller E4:5F:01:F0:0E:98 Pairable: yes
[bluetooth]#</pre>
Die Zeile „[CHG] Controller“ (oder auch [NEW]) zeigt die Informationen zu deinem Bluetooth-Chip an. Die letzte Zeile ist die Eingabeaufforderung von bluetoothctl.

Da der Kopplungsvorgang eine Authentifizierung per PIN beinhaltet, ist eine Registrierung bei einem Authentifizierungsagenten erforderlich. Der Agent bearbeitet die PIN-Abfrage. Gib dazu Folgendes ein:
<pre>[bluetooth]# agent on
Agent registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]#</pre>
Beachte, dass die Registrierung des Agenten während der Kopplung mit einem Gerät, das keine Benutzerbestätigung für den Kopplungsversuch erfordert, keine negativen Auswirkungen hat und sicher ist.<br>
An dieser Stelle kannst du mit der Suche nach entfernten Bluetooth-Geräten fortfahren:
<pre>[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...
[NEW] Device <bluetooth address> <name></pre>
Stoppt man den Scan mit <code>[bluetooth]# scan off</code>, so werden die Ergebnisse der Geräteerkennung nach einer gewissen Zeit ungültig.
<pre>[DEL] Device 00:1A:22:XX:XX:XX CC-RT-BLE</pre>
Vorher kann das Pairing gestartet werden:
<pre>[bluetooth]# pair 00:1A:22:06:A7:83</pre>
Nun einfach der Anzeige folgen. Am Ende sollte eine Erfolgsmeldung stehen. Falls nicht, die Prozedur ab <code>[bluetooth]# scan on</code> wiederholen. Danach muss das Gerät noch als Vertrauenswürdig deklariert
<pre>[bluetooth]# trust 00:1A:22:06:A7:83</pre>
und wieder getrennt werden
<pre>[bluetooth]# disconnect 00:1A:22:06:A7:83</pre>
Danach kannst du über
<pre>[bluetooth]# info 00:1A:22:06:A7:83</pre>
nachsehen, ob alles korrekt ist. Das Gerät kann nun in FHEM definiert werden.

== Bekannte Probleme ==
=== Fehlermeldung nach fhempy-Installation ===
Meldet pip3 folgendes
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre>
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen
<pre>export PATH=$PATH:/home/myname/.local/bin</pre>
also z.B.
<pre>export PATH=$PATH:/home/pi/.local/bin</pre>

=== Keine Reaktion auf Einstellen der Offset-Temperatur ===
Zur Zeit scheint es ein Softwareproblem beim Einstellen der Offset-Temperatur über Bluetooth zu geben (Version 146 oder kleiner). Die Einstellung wird übertragen, wirkt sich aber nicht auf das Thermostat aus. Erst wenn man die Einstellung über das Menü am Thermostat bestätigt (oder gleich dort einstellt), reagiert das Thermostat. Das Problem tritt auch bei der Bedienung über die App auf.

== Links ==
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}

[[Kategorie:Heizungsventile]]
[[Kategorie:Bluetooth]]

Einrichten der Bluetooth-Thermostate von eQ-3

2023-02-07T15:55:30Z

F Klee: Einzelne Schritte des Pairing erläutert

Die Firma eQ-3 stellt verschiedene elektronische Heizkörperthermostate her. Das Eqiva BLUETOOTH® Smart Heizkörperthermostat (CC-RT-BLE-EQ) kann auch von FHEM gesteuert werden. Voraussetzung ist natürlich ein Bluetooth-Empfänger (RasPi 3+4 oder Bluetooth-Dongle).
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth, die genau gleich aussehen. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}
== Bluetooth einrichten ==
Standardmäßig sollte Bluetooth auf dem Raspberry Pi schon eingerichtet sein. Nutzt man einen B+ mit Dongle (z.B. als Verlängerung), so müssen unter Umständen folgende Pakete installiert werden:
<pre>sudo apt-get install bluetooth, bluez</pre>
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre>

<pre><policy user="fhem">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.GattCharacteristic1"/>
<allow send_interface="org.bluez.GattDescriptor1"/>
<allow send_interface="org.freedesktop.DBus.ObjectManager"/>
<allow send_interface="org.freedesktop.DBus.Properties"/>
</policy></pre>
<pre>sudo systemctl restart dbus</pre>
Für den User pi muss natürlich fhem durch pi ersetzt werden.

== Thermostat in FHEM definieren ==
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:
<pre>pi@raspberrypi ~ $ bluetoothctl
[NEW] Controller 00:1A:7D:XX:XX:XX raspberrypi [default]
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...
[bluetooth]# scan off</pre>
Die Geräte tragen den Namen CC-RT-BLE.

=== Einrichten mit Perl-Modul 10_EQ3BT ===
Die eQ-3 Heizkörperthermostate können einfach über
define <name> EQ3BT <mac address>
eingebunden werden.
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}

=== Einrichten mit fhempy ===
fhempy ermöglicht das Schreiben von FHEM-Modulen in der Programmiersprache Python. Erforderlich ist Python 3.8 oder höher (NICHT 2!), weshalb Debian Bullseye empfehlenswert ist. Es ist auch möglich, fhempy auf Peers zu installieren, um dadurch die Bluetooth-Reichweite zu erhöhen. Dadurch ist eine komplette Abdeckung des Hauses möglich. Auf den Peers muss FHEM nicht installiert werden. Neben dem Raspberry Pi Zero eignet sich auch z.B. der Radxa Rock Pi Zero, getestet mit Armbian. Die Peers können aus FHEM heraus verwaltet werden.
==== Installation auf FHEM-Server ====
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit

[Debian 11 (Bullseye)]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git libprotocol-websocket-perl</pre>

[alle anderen]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git</pre>
und als nächstes
<pre>
sudo cpan Protocol::WebSocket</pre>

Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt
update</pre>
Ist das Update abgeschlossen, können wir fhempy einrichten:
<pre>define fhempy_local BindingsIo fhempy</pre>
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.

Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre>
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.

==== Installation des fhempy-Peer ====
fhempy läuft nicht nur lokal auf dem FHEM-Server. Zur Reichweitenerhöhung kann auch ein fhempy-Peer auf einem oder mehreren RasPi’s installiert und diese über die Wohnung verteilt werden. Geeignet ist natürlich auch ein RasPi, der zur Visualisierung dient.
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi
<pre>pip3 install --upgrade fhempy</pre>
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer
<pre>fhempy</pre>
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre>
fhempy läuft nun unter dem User pi. Möchtest du das ändern, so schau in die Datei <code>fhempy.service</code> im Verzeichnis <code>/etc/systemd/system/</code> Hinterher das sudo systemctl daemon-reload nicht vergessen.
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre>

== Pairing ==
Die Thermostate müssen mit dem RasPi gepaired werden. Drücke dazu das Rad am Thermostat bis „Pair“ im Display erscheint. Dann führe folgende Schritte aus:
<pre>
$ sudo bluetoothctl
[bluetooth]# power on
[bluetooth]# agent on
[bluetooth]# default-agent
[bluetooth]# scan on
[bluetooth]# scan off
[bluetooth]# pair 00:1A:22:06:A7:83
[agent] Enter passkey (number in 0-999999): <enter pin>
[bluetooth]# trust 00:1A:22:06:A7:83
[bluetooth]# disconnect 00:1A:22:06:A7:83
[bluetooth]# exit

Optional steps:
[bluetooth]# devices - to list all bluetooth devices
[bluetooth]# info 00:1A:22:06:A7:83
Device 00:1A:22:06:A7:83 (public)
Name: CC-RT-BLE
Alias: CC-RT-BLE
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)
ManufacturerData Key: 0x0000
ManufacturerData Value:
00 00 00 00 00 00 00 00 00 .........</pre>
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).
Unter Umständen wird nicht nach <code>Enter passkey</code> gefragt. Wichtig ist die Erfolgsmeldung.<br>
Die Befehle bedeuten im Einzelnen:
<pre>$ sudo bluetoothctl</pre>
Startet das Bluetoothctl-Tool, das eine Befehlszeilenschnittstelle zu BlueZ ist. <code>sudo</code> ist häufig nicht erforderlich. Die Ausgabe sollte ähnlich der folgenden aussehen:
<pre>[CHG] Controller E4:5F:01:F0:0E:98 Pairable: yes
[bluetooth]#</pre>
Die Zeile „[CHG] Controller“ (oder auch [NEW]) zeigt die Informationen zu deinem Bluetooth-Chip an. Die letzte Zeile ist die Eingabeaufforderung von bluetoothctl.

Da der Kopplungsvorgang eine Authentifizierung per PIN beinhaltet, ist eine Registrierung bei einem Authentifizierungsagenten erforderlich. Der Agent bearbeitet die PIN-Abfrage. Gib dazu Folgendes ein:
<pre>[bluetooth]# agent on
Agent registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]#</pre>
Beachte, dass die Registrierung des Agenten während der Kopplung mit einem Gerät, das keine Benutzerbestätigung für den Kopplungsversuch erfordert, keine negativen Auswirkungen hat und sicher ist.<br>
An dieser Stelle kannst du mit der Suche nach entfernten Bluetooth-Geräten fortfahren:
<pre>[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...
[NEW] Device <bluetooth address> <name></pre>
Stoppt man den Scan mit <code>[bluetooth]# scan off</code>, so werden die Ergebnisse der Geräteerkennung nach einer gewissen Zeit ungültig.
<pre>[DEL] Device 00:1A:22:XX:XX:XX CC-RT-BLE</pre>
Vorher kann das Pairing gestartet werden:
<pre>[bluetooth]# pair 00:1A:22:06:A7:83</pre>
Nun einfach der Anzeige folgen. Am Ende sollte eine Erfolgsmeldung stehen. Falls nicht, die Prozedur ab <code>[bluetooth]# scan on</code> wiederholen. Danach muss das Gerät noch als Vertrauenswürdig deklariert
<pre>[bluetooth]# trust 00:1A:22:06:A7:83</pre>
und wieder getrennt werden
<pre>[bluetooth]# disconnect 00:1A:22:06:A7:83</pre>
Danach kannst du über
<pre>[bluetooth]# info 00:1A:22:06:A7:83</pre>
nachsehen, ob alles korrekt ist. Das Gerät kann nun in FHEM definiert werden.

== Bekannte Probleme ==
=== Fehlermeldung nach fhempy-Installation ===
Meldet pip3 folgendes
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre>
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen
<pre>export PATH=$PATH:/home/myname/.local/bin</pre>
also z.B.
<pre>export PATH=$PATH:/home/pi/.local/bin</pre>

=== Keine Reaktion auf Einstellen der Offset-Temperatur ===
Zur Zeit scheint es ein Softwareproblem beim Einstellen der Offset-Temperatur über Bluetooth zu geben (Version 146 oder kleiner). Die Einstellung wird übertragen, wirkt sich aber nicht auf das Thermostat aus. Erst wenn man die Einstellung über das Menü am Thermostat bestätigt (oder gleich dort einstellt), reagiert das Thermostat. Das Problem tritt auch bei der Bedienung über die App auf.

== Links ==
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}

[[Kategorie:Heizungsventile]]
[[Kategorie:Bluetooth]]

Knxd

2023-01-13T13:50:49Z

F Klee: /* Vorbereiten des Raspberry Pi für ROT oder PIGATOR */

== knxd mit einem IP Gateway einrichten ==
Damit FHEM auf den KNX Bus zugreifen kann, wird ein passendes Interface benötigt. Es gibt:
* RS232
* USB
* IP

Im Folgenden wird die Einrichtung von knxd mit einem IP Gateway auf einem Raspberry Pi2 mit Wheezy oder Jessie beschrieben.

=== Installation ===

==== Für Debian Jessie: ====
'''als erstes müssen folgende Pakete installiert werden (Referenz Debian Jessie):'''
<syntaxhighlight lang="bash">
sudo apt-get update
sudo apt-get install debhelper cdbs automake libtool libusb-1.0-0-dev git-core build-essential libsystemd-daemon-dev dh-systemd libev-dev cmake
</syntaxhighlight>

'''knxd herunterladen und installieren'''
Achtung: Wenn Abhängigkeiten fehlen, dann müssen diese nachinstalliert werden. Nicht einfach mittels "-d" diese übergehen!
<syntaxhighlight lang="bash">
git clone https://github.com/knxd/knxd.git
cd knxd
git checkout deb
dpkg-buildpackage -b -uc
cd ..
sudo dpkg -i knxd_*.deb knxd-tools_*.deb
</syntaxhighlight>

==== Ab Debian Stretch, Buster, ... ====
'''knxd ist in den Debian packages vorhanden, muss daher nicht compiliert werden.'''
<syntaxhighlight lang="bash">
sudo apt-get update
sudo apt-get install knxd knxd-tools

</syntaxhighlight>

Mit der Konfiguration '''mit Systemd weitermachen!'''
=== Konfiguration ===
'''1. Ohne systemd'''

Es muss als nächstes die Konfigurationsdatei editiert werden, das geht mit:
<syntaxhighlight lang="bash">
sudo nano /etc/default/knxd
</syntaxhighlight>
dann folgende Einträge anpassen:
<syntaxhighlight lang="bash">
DAEMON_ARGS="-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.188.XX"
</syntaxhighlight>
und
<syntaxhighlight lang="bash">
START_KNXD=YES
</syntaxhighlight>

'''2. Mit systemd z. B. für Debian Jessie'''

Die Konfigurationsdatei bei Jessie hat sich wegen der Nutzung von systemd geändert:
<syntaxhighlight lang="bash">
sudo nano /etc/knxd.conf
</syntaxhighlight>
dann folgende Einträge anpassen:
<syntaxhighlight lang="bash">
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b ipt:192.168.188.XX"

</syntaxhighlight>
=== knxd Status überprüfen ===
<syntaxhighlight lang="bash">
/etc/init.d/knxd status
</syntaxhighlight>

== knxd als IP-Gateway einrichten ==
Der knxd kann auch gleich als IP-Gateway eingerichtet und sowohl mit FHEM als auch parallel mit der ETS genutzt werden. Dazu ist, neben einem Raspberry Pi, ein Interface zum KNX-Bus erforderlich. Geeignet sind z.B.:
* ROT
* PIGATOR mit PIM-TPUART
* TUL
der Fa. [http://busware.de Busware]. Wer einen Rasperry Pi3 benutzen möchte, der sollte zum TUL greifen, da die serielle Schnittstelle UART0 das Bluetooth-Modul des Pi3 bedient und wieder auf die GPIO-Pins umgeleitet werden muss. Der TUL bringt seine eigene serielle Schnittstelle mit, so dass Bluetooth erhalten bleibt.

=== Vorbereiten des TUL ===
==== TUL flashen ====
Der TUL wird ohne Software geliefert und kann über den Raspberry Pi programmiert werden:
<syntaxhighlight lang="bash">
sudo apt-get install dfu-programmer
wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54
sudo dfu-programmer atmega32u4 erase
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex
sudo dfu-programmer atmega32u4 reset
sudo reboot
</syntaxhighlight>
Soll der TUL unter Windows programmiert werden, so geht das mit [https://www.microchip.com/developmenttools/ProductDetails/FLIP FLIP]. Die HEX-Datei kann [http://files.busware.de/TUL/Transparent/ hier] herunter geladen werden.
Der TUL hat an der Unterseite einen winzigen Button. Dieser muss gedrückt werden, während der TUL in die USB-Buchse gesteckt wird.
In FLIP nun als ''Device=>Select'' ATmega32U4 auswählen und über ''Settings=>Communication=>USB'' die Verbindung herstellen. *.hex-Datei laden und im Rahmen ''Operation-Flow'' auf ''Run'' klicken. Fertig.

==== TUL einen dauerhaften Namen geben ====
Linux bindet USB-Geräte beim Boot in einer eher zufälligen Reihenfolge ein. Werden mehrere USB-Geräte betrieben, so ist es sinnvoll, dem TUL einen festen Namen zuzuordnen. Dazu wird der TUL zunächst mit dem Befehl
<syntaxhighlight lang="bash">
ls -la /dev/serial/by-id/
</syntaxhighlight>
identifiziert. Das Ergebnis sollte ungefähr so aussehen
<syntaxhighlight lang="bash">
usb-busware.de_TPUART_8543934393935171B1C1-if00 -> ../../ttyACM0
</syntaxhighlight>
Die Seriennummer (8543934393935171B1C1) wird später benötigt. Der Befehl
<syntaxhighlight lang="bash">
lsusb
</syntaxhighlight>
sollte u.a. diese Zeile liefern
<syntaxhighlight lang="bash">
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
</syntaxhighlight>
03eb ist dabei die Herstellerkennung, 204b die Produktkennung. Nun muss die Datei /etc/udev/rules.d/99-usb-serial.rules
<syntaxhighlight lang="bash">
sudo nano /etc/udev/rules.d/99-usb-serial.rules
</syntaxhighlight>
erstellt oder erweitert werden mit der Zeile
<syntaxhighlight lang="bash">
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="8543934393935171B1C1", SYMLINK+="knx", OWNER="knxd"
</syntaxhighlight>
Der TUL wird dann unter /dev/knx erreichbar sein. Der knxd läuft als Benutzer knxd und hat damit die Berechtigung, auf den TUL zuzugreifen.

=== Vorbereiten des Raspberry Pi für ROT oder PIGATOR ===
Der Raspberry Pi nutzt standardmäßig die serielle Schnittstelle als Terminal. Dies muss deaktiviert werden:
<syntaxhighlight lang="bash">
sudo raspi-config
5 Interfaceoption
P6 Serial
</syntaxhighlight>
Der knxd arbeitet als Benutzer knxd. Nach der Installation von knxd muss dieser noch der Gruppe dialout zugeordnet werden, damit er auf ttyAMA0 zugreifen kann:
<syntaxhighlight lang="bash">
sudo usermod -aG dialout knxd
</syntaxhighlight>
Die Raspberry Pi 3 und 4 nutzen für die serielle Schnittstelle einen mini UART, der nicht mit dem knxd zusammenarbeitet. Der Hardware UART wird für Bluetooth verwendet. Bluetooth muss deaktiviert werden, damit der Hardware UART wieder unter ttyAMA0 zur Verfügung steht. In der /boot/config.txt muss die Zeile
<syntaxhighlight lang="bash">
dtoverlay=disable-bt
</syntaxhighlight>
am Ende eingefügt werden. Nun muss noch der Dienst hciuart deaktiviert werden (initialisiert das Bluetooth-Modem):
<syntaxhighlight lang="bash">
sudo systemctl disable hciuart
</syntaxhighlight>
Nach einem anschließenden Reboot ist der TPUART unter ttyAMA0 ansprechbar.

Nach dieser Prozedur ist natürlich die Benuzung des Bluetooth-Moduls nicht mehr möglich. Wer das Modul benötigt, findet die Anleitung hier:

[[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]

Der Raspberry Pi 4 besitzt weitere UARTs, die auch für den knxd genutzt werden können. Weitere Informationen dazu gibt es [https://gitlab.com/knx-makerstuff/knx_microbcu2/-/wikis/DualKNX-RaspiHat-Quick-Installation-Guide#uart-configuration hier].

=== Andere BCU's (BusCouplerUnit) ===
Natürlich sind auch andere BCU's geeignet. Wer weiß, an welchem Ende er einen Lötkolben anzufassen hat, ist mit der [https://knx-user-forum.de/forum/projektforen/konnekting/1045398-microbcu-sehr-kleiner-knx-transceiver MicroBCU] gut bedient. Sie kann z.B. über einen ADUM1201 mit dem UART des Raspberry Pi verbunden werden (Tx->Rx, Rx->Tx, Konfiguration wie unter [[Knxd#Vorbereiten_des_Raspberry_Pi_f.C3.BCr_ROT_oder_PIGATOR|ROT]] beschrieben) oder über einen USB2Seriell-Konverter (Konfiguration ähnlich [[Knxd#TUL_einen_dauerhaften_Namen_geben|TUL]]).{{Hinweis|Die MicroBCU wird vom Bus gespeist und liefert auch zwei Spannungen, wovon die 3,3V auch für den ADUM genutzt werden kann. Wer den Raspi aus dem KNX-Netzteil versorgen möchte, sollte sich [https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/knx-eib-forum/diy-do-it-yourself/1597469-dualknx-microbcu-hat-f%C3%BCr-raspberrypi-mit-dc-dc-netzteil das hier] mal ansehen.}}

=== Installieren des knxd ===
Die Installation erfolgt nun wie oben unter [[Knxd#Installation|Installation]] beschrieben. Hier noch mal der dringende Hinweis, fehlende Abhängigkeiten nicht mit -d zu überspringen. Jede Abhängigkeit, die als Fehlend moniert wird, nachinstallieren und Kompilierung neu starten. Prozedur notfalls mehrfach wiederholen. Das Kompilieren dauert und manchmal geht es scheinbar nicht weiter. Also Geduld.

=== Konfiguration ===
Die Konfiguration erfolgt wieder in der knxd.conf mit
<syntaxhighlight lang="bash">
sudo nano /etc/knxd.conf
</syntaxhighlight>
Nun die Konfiguarionszeile anpassen<br>
(serielle Schnittstelle)
<syntaxhighlight lang="bash">
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b tpuarts:/dev/ttyAMA0"
</syntaxhighlight>
(USB)
<syntaxhighlight lang="bash">
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b tpuarts:/dev/knx"
</syntaxhighlight>
Und dann noch
<syntaxhighlight lang="bash">
START_KNXD=YES
</syntaxhighlight>
um knxd beim Systemstart sofort zu starten.

-e definiert die physikalische Adresse des knxd, -E definiert einen Adressbereich für ETS5 etc. (hier einen Bereich aus acht Adressen). Diese Adressen müssen an das eigene Netz angepasst werden. In FHEM sieht das dann so aus
<syntaxhighlight lang="bash">
define myKNXGW KNXIO T 127.0.0.1:6720 1.2.203
</syntaxhighlight>
alternativ via Multicast: (siehe auch KNXIO-wiki):<syntaxhighlight lang="bash">
define myKNXGW KNXIO M 224.0.23.12:3671 1.2.203
</syntaxhighlight>
Spätestens jetzt sollte der KNX-Bus angeschlossen werden.{{Hinweis|Da der TPUART (wie auch andere BCU‘s) vom Bus gespeist wird, kann der knxd den TPUART nur initialisieren, wenn der Bus angeschaltet ist.}}
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)
<syntaxhighlight lang="bash">
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
"1" durch "0" ersetzen
</syntaxhighlight>
Nach einem
<syntaxhighlight lang="bash">
sudo reboot
</syntaxhighlight>
sollte der knxd dann laufen.
{{Hinweis|Manche KNX-Module bringen zusätzlich eine IP-Gateway-Funktion mit (z.B. sonnenKNX zur Verbindung der sonnenBatterie mit dem KNX-Bus). Hier führt die Option -R in der Konfigurationsdatei zu Problemen (KNX-IP Daten werden mehrfach auf den Bus gespiegelt). Daher muss die Option -R entfernt werden (-DTS), wenn ein solches Modul nachträglich in das System integriert wird.}}

== FAQ ==
'''Wie wird eibd vorher deinstalliert?'''
<syntaxhighlight lang="bash">
sudo rm -r /usr/local/bin/{eibd,knxtool,group*} /usr/local/lib/lib{eib,pthsem}*.so* /usr/local/include/pth*
</syntaxhighlight>

<u>'''Hinweis'''</u>: knxd unterstützt im Gegensatz zu eibd die Hilfsprogramme knxtools nur sehr eingeschränkt (Siehe dazu Hinweis unter https://github.com/knxd/knxd#migrating-to-012. "progmode" sowie alle mit "m" beginnenden Kommandos sind entgegen der Doku ab Version 0.12 nicht mehr funktionsfähig.

'''folgender Fehler: dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2'''
<syntaxhighlight lang="bash">
sudo apt-get install git-core build-essential
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
in der datei knxd/debian/rules die Zeile:
bash tools/test.sh auskommentieren
</syntaxhighlight>

'''Fehler: dpkg-buildpackage: error: fakeroot not found, either install the fakeroot <....> '''
<syntaxhighlight lang="bash">
sudo apt-get install fakeroot dpkg-dev
</syntaxhighlight>

== Links ==
* [[Benutzer:Marthinx]]
* [https://github.com/knxd/knxd Github knxd]
* [https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen Forums-Thread zu knxd. Sehr informativ.]

[[Kategorie:Examples]]
[[Kategorie:EIB/KNX]]

Knxd

2023-01-13T13:48:16Z

F Klee: Ergänzung für RasPi 4

== knxd mit einem IP Gateway einrichten ==
Damit FHEM auf den KNX Bus zugreifen kann, wird ein passendes Interface benötigt. Es gibt:
* RS232
* USB
* IP

Im Folgenden wird die Einrichtung von knxd mit einem IP Gateway auf einem Raspberry Pi2 mit Wheezy oder Jessie beschrieben.

=== Installation ===

==== Für Debian Jessie: ====
'''als erstes müssen folgende Pakete installiert werden (Referenz Debian Jessie):'''
<syntaxhighlight lang="bash">
sudo apt-get update
sudo apt-get install debhelper cdbs automake libtool libusb-1.0-0-dev git-core build-essential libsystemd-daemon-dev dh-systemd libev-dev cmake
</syntaxhighlight>

'''knxd herunterladen und installieren'''
Achtung: Wenn Abhängigkeiten fehlen, dann müssen diese nachinstalliert werden. Nicht einfach mittels "-d" diese übergehen!
<syntaxhighlight lang="bash">
git clone https://github.com/knxd/knxd.git
cd knxd
git checkout deb
dpkg-buildpackage -b -uc
cd ..
sudo dpkg -i knxd_*.deb knxd-tools_*.deb
</syntaxhighlight>

==== Ab Debian Stretch, Buster, ... ====
'''knxd ist in den Debian packages vorhanden, muss daher nicht compiliert werden.'''
<syntaxhighlight lang="bash">
sudo apt-get update
sudo apt-get install knxd knxd-tools

</syntaxhighlight>

Mit der Konfiguration '''mit Systemd weitermachen!'''
=== Konfiguration ===
'''1. Ohne systemd'''

Es muss als nächstes die Konfigurationsdatei editiert werden, das geht mit:
<syntaxhighlight lang="bash">
sudo nano /etc/default/knxd
</syntaxhighlight>
dann folgende Einträge anpassen:
<syntaxhighlight lang="bash">
DAEMON_ARGS="-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.188.XX"
</syntaxhighlight>
und
<syntaxhighlight lang="bash">
START_KNXD=YES
</syntaxhighlight>

'''2. Mit systemd z. B. für Debian Jessie'''

Die Konfigurationsdatei bei Jessie hat sich wegen der Nutzung von systemd geändert:
<syntaxhighlight lang="bash">
sudo nano /etc/knxd.conf
</syntaxhighlight>
dann folgende Einträge anpassen:
<syntaxhighlight lang="bash">
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b ipt:192.168.188.XX"

</syntaxhighlight>
=== knxd Status überprüfen ===
<syntaxhighlight lang="bash">
/etc/init.d/knxd status
</syntaxhighlight>

== knxd als IP-Gateway einrichten ==
Der knxd kann auch gleich als IP-Gateway eingerichtet und sowohl mit FHEM als auch parallel mit der ETS genutzt werden. Dazu ist, neben einem Raspberry Pi, ein Interface zum KNX-Bus erforderlich. Geeignet sind z.B.:
* ROT
* PIGATOR mit PIM-TPUART
* TUL
der Fa. [http://busware.de Busware]. Wer einen Rasperry Pi3 benutzen möchte, der sollte zum TUL greifen, da die serielle Schnittstelle UART0 das Bluetooth-Modul des Pi3 bedient und wieder auf die GPIO-Pins umgeleitet werden muss. Der TUL bringt seine eigene serielle Schnittstelle mit, so dass Bluetooth erhalten bleibt.

=== Vorbereiten des TUL ===
==== TUL flashen ====
Der TUL wird ohne Software geliefert und kann über den Raspberry Pi programmiert werden:
<syntaxhighlight lang="bash">
sudo apt-get install dfu-programmer
wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54
sudo dfu-programmer atmega32u4 erase
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex
sudo dfu-programmer atmega32u4 reset
sudo reboot
</syntaxhighlight>
Soll der TUL unter Windows programmiert werden, so geht das mit [https://www.microchip.com/developmenttools/ProductDetails/FLIP FLIP]. Die HEX-Datei kann [http://files.busware.de/TUL/Transparent/ hier] herunter geladen werden.
Der TUL hat an der Unterseite einen winzigen Button. Dieser muss gedrückt werden, während der TUL in die USB-Buchse gesteckt wird.
In FLIP nun als ''Device=>Select'' ATmega32U4 auswählen und über ''Settings=>Communication=>USB'' die Verbindung herstellen. *.hex-Datei laden und im Rahmen ''Operation-Flow'' auf ''Run'' klicken. Fertig.

==== TUL einen dauerhaften Namen geben ====
Linux bindet USB-Geräte beim Boot in einer eher zufälligen Reihenfolge ein. Werden mehrere USB-Geräte betrieben, so ist es sinnvoll, dem TUL einen festen Namen zuzuordnen. Dazu wird der TUL zunächst mit dem Befehl
<syntaxhighlight lang="bash">
ls -la /dev/serial/by-id/
</syntaxhighlight>
identifiziert. Das Ergebnis sollte ungefähr so aussehen
<syntaxhighlight lang="bash">
usb-busware.de_TPUART_8543934393935171B1C1-if00 -> ../../ttyACM0
</syntaxhighlight>
Die Seriennummer (8543934393935171B1C1) wird später benötigt. Der Befehl
<syntaxhighlight lang="bash">
lsusb
</syntaxhighlight>
sollte u.a. diese Zeile liefern
<syntaxhighlight lang="bash">
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
</syntaxhighlight>
03eb ist dabei die Herstellerkennung, 204b die Produktkennung. Nun muss die Datei /etc/udev/rules.d/99-usb-serial.rules
<syntaxhighlight lang="bash">
sudo nano /etc/udev/rules.d/99-usb-serial.rules
</syntaxhighlight>
erstellt oder erweitert werden mit der Zeile
<syntaxhighlight lang="bash">
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="8543934393935171B1C1", SYMLINK+="knx", OWNER="knxd"
</syntaxhighlight>
Der TUL wird dann unter /dev/knx erreichbar sein. Der knxd läuft als Benutzer knxd und hat damit die Berechtigung, auf den TUL zuzugreifen.

=== Vorbereiten des Raspberry Pi für ROT oder PIGATOR ===
Der Raspberry Pi nutzt standardmäßig die serielle Schnittstelle als Terminal. Dies muss deaktiviert werden:
<syntaxhighlight lang="bash">
sudo raspi-config
5 Interfaceoption
P6 Serial
</syntaxhighlight>
Der knxd arbeitet als Benutzer knxd. Nach der Installation von knxd muss dieser noch der Gruppe dialout zugeordnet werden, damit er auf ttyAMA0 zugreifen kann:
<syntaxhighlight lang="bash">
sudo usermod -aG dialout knxd
</syntaxhighlight>
Die Raspberry Pi 3 und 4 nutzen für die serielle Schnittstelle einen mini UART, der nicht mit dem knxd zusammenarbeitet. Der Hardware UART wird für Bluetooth verwendet. Bluetooth muss deaktiviert werden, damit der Hardware UART wieder unter ttyAMA0 zur Verfügung steht. In der /boot/config.txt muss die Zeile
<syntaxhighlight lang="bash">
dtoverlay=disable-bt
</syntaxhighlight>
am Ende eingefügt werden. Nun muss noch der Dienst hciuart deaktiviert werden (initialisiert das Bluetooth-Modem):
<syntaxhighlight lang="bash">
sudo systemctl disable hciuart
</syntaxhighlight>
Nach einem anschließenden Reboot ist der TPUART unter ttyAMA0 ansprechbar.

Nach dieser Prozedur ist natürlich die Benuzung des Bluetooth-Moduls nicht mehr möglich. Wer das Modul benötigt, findet die Anleitung hier:

[[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]

Der Raspberry Pi 4 besitzt weitere UARTs, die auch für den knxd genutzt werden können. Weitere Informationen dazu gibt es [https://gitlab.com/knx-makerstuff/knx_microbcu2/-/wikis/DualKNX-RaspiHat-Quick-Installation-Guide hier].

=== Andere BCU's (BusCouplerUnit) ===
Natürlich sind auch andere BCU's geeignet. Wer weiß, an welchem Ende er einen Lötkolben anzufassen hat, ist mit der [https://knx-user-forum.de/forum/projektforen/konnekting/1045398-microbcu-sehr-kleiner-knx-transceiver MicroBCU] gut bedient. Sie kann z.B. über einen ADUM1201 mit dem UART des Raspberry Pi verbunden werden (Tx->Rx, Rx->Tx, Konfiguration wie unter [[Knxd#Vorbereiten_des_Raspberry_Pi_f.C3.BCr_ROT_oder_PIGATOR|ROT]] beschrieben) oder über einen USB2Seriell-Konverter (Konfiguration ähnlich [[Knxd#TUL_einen_dauerhaften_Namen_geben|TUL]]).{{Hinweis|Die MicroBCU wird vom Bus gespeist und liefert auch zwei Spannungen, wovon die 3,3V auch für den ADUM genutzt werden kann. Wer den Raspi aus dem KNX-Netzteil versorgen möchte, sollte sich [https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/knx-eib-forum/diy-do-it-yourself/1597469-dualknx-microbcu-hat-f%C3%BCr-raspberrypi-mit-dc-dc-netzteil das hier] mal ansehen.}}

=== Installieren des knxd ===
Die Installation erfolgt nun wie oben unter [[Knxd#Installation|Installation]] beschrieben. Hier noch mal der dringende Hinweis, fehlende Abhängigkeiten nicht mit -d zu überspringen. Jede Abhängigkeit, die als Fehlend moniert wird, nachinstallieren und Kompilierung neu starten. Prozedur notfalls mehrfach wiederholen. Das Kompilieren dauert und manchmal geht es scheinbar nicht weiter. Also Geduld.

=== Konfiguration ===
Die Konfiguration erfolgt wieder in der knxd.conf mit
<syntaxhighlight lang="bash">
sudo nano /etc/knxd.conf
</syntaxhighlight>
Nun die Konfiguarionszeile anpassen<br>
(serielle Schnittstelle)
<syntaxhighlight lang="bash">
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b tpuarts:/dev/ttyAMA0"
</syntaxhighlight>
(USB)
<syntaxhighlight lang="bash">
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b tpuarts:/dev/knx"
</syntaxhighlight>
Und dann noch
<syntaxhighlight lang="bash">
START_KNXD=YES
</syntaxhighlight>
um knxd beim Systemstart sofort zu starten.

-e definiert die physikalische Adresse des knxd, -E definiert einen Adressbereich für ETS5 etc. (hier einen Bereich aus acht Adressen). Diese Adressen müssen an das eigene Netz angepasst werden. In FHEM sieht das dann so aus
<syntaxhighlight lang="bash">
define myKNXGW KNXIO T 127.0.0.1:6720 1.2.203
</syntaxhighlight>
alternativ via Multicast: (siehe auch KNXIO-wiki):<syntaxhighlight lang="bash">
define myKNXGW KNXIO M 224.0.23.12:3671 1.2.203
</syntaxhighlight>
Spätestens jetzt sollte der KNX-Bus angeschlossen werden.{{Hinweis|Da der TPUART (wie auch andere BCU‘s) vom Bus gespeist wird, kann der knxd den TPUART nur initialisieren, wenn der Bus angeschaltet ist.}}
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)
<syntaxhighlight lang="bash">
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
"1" durch "0" ersetzen
</syntaxhighlight>
Nach einem
<syntaxhighlight lang="bash">
sudo reboot
</syntaxhighlight>
sollte der knxd dann laufen.
{{Hinweis|Manche KNX-Module bringen zusätzlich eine IP-Gateway-Funktion mit (z.B. sonnenKNX zur Verbindung der sonnenBatterie mit dem KNX-Bus). Hier führt die Option -R in der Konfigurationsdatei zu Problemen (KNX-IP Daten werden mehrfach auf den Bus gespiegelt). Daher muss die Option -R entfernt werden (-DTS), wenn ein solches Modul nachträglich in das System integriert wird.}}

== FAQ ==
'''Wie wird eibd vorher deinstalliert?'''
<syntaxhighlight lang="bash">
sudo rm -r /usr/local/bin/{eibd,knxtool,group*} /usr/local/lib/lib{eib,pthsem}*.so* /usr/local/include/pth*
</syntaxhighlight>

<u>'''Hinweis'''</u>: knxd unterstützt im Gegensatz zu eibd die Hilfsprogramme knxtools nur sehr eingeschränkt (Siehe dazu Hinweis unter https://github.com/knxd/knxd#migrating-to-012. "progmode" sowie alle mit "m" beginnenden Kommandos sind entgegen der Doku ab Version 0.12 nicht mehr funktionsfähig.

'''folgender Fehler: dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2'''
<syntaxhighlight lang="bash">
sudo apt-get install git-core build-essential
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
in der datei knxd/debian/rules die Zeile:
bash tools/test.sh auskommentieren
</syntaxhighlight>

'''Fehler: dpkg-buildpackage: error: fakeroot not found, either install the fakeroot <....> '''
<syntaxhighlight lang="bash">
sudo apt-get install fakeroot dpkg-dev
</syntaxhighlight>

== Links ==
* [[Benutzer:Marthinx]]
* [https://github.com/knxd/knxd Github knxd]
* [https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen Forums-Thread zu knxd. Sehr informativ.]

[[Kategorie:Examples]]
[[Kategorie:EIB/KNX]]

Einrichten der Bluetooth-Thermostate von eQ-3

2023-01-07T14:11:48Z

F Klee: Genaue Typbezeichnung hinzu gefügt

Die Firma eQ-3 stellt verschiedene elektronische Heizkörperthermostate her. Das Eqiva BLUETOOTH® Smart Heizkörperthermostat (CC-RT-BLE-EQ) kann auch von FHEM gesteuert werden. Voraussetzung ist natürlich ein Bluetooth-Empfänger (RasPi 3+4 oder Bluetooth-Dongle).
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth, die genau gleich aussehen. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}
== Bluetooth einrichten ==
Standardmäßig sollte Bluetooth auf dem Raspberry Pi schon eingerichtet sein. Nutzt man einen B+ mit Dongle (z.B. als Verlängerung), so müssen unter Umständen folgende Pakete installiert werden:
<pre>sudo apt-get install bluetooth, bluez</pre>
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre>

<pre><policy user="fhem">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.GattCharacteristic1"/>
<allow send_interface="org.bluez.GattDescriptor1"/>
<allow send_interface="org.freedesktop.DBus.ObjectManager"/>
<allow send_interface="org.freedesktop.DBus.Properties"/>
</policy></pre>
<pre>sudo systemctl restart dbus</pre>
Für den User pi muss natürlich fhem durch pi ersetzt werden.

== Thermostat in FHEM definieren ==
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:
<pre>pi@raspberrypi ~ $ bluetoothctl
[NEW] Controller 00:1A:7D:XX:XX:XX raspberrypi [default]
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...
[bluetooth]# scan off</pre>
Die Geräte tragen den Namen CC-RT-BLE.

=== Einrichten mit Perl-Modul 10_EQ3BT ===
Die eQ-3 Heizkörperthermostate können einfach über
define <name> EQ3BT <mac address>
eingebunden werden.
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}

=== Einrichten mit fhempy ===
fhempy ermöglicht das Schreiben von FHEM-Modulen in der Programmiersprache Python. Erforderlich ist Python 3.8 oder höher (NICHT 2!), weshalb Debian Bullseye empfehlenswert ist. Es ist auch möglich, fhempy auf Peers zu installieren, um dadurch die Bluetooth-Reichweite zu erhöhen. Dadurch ist eine komplette Abdeckung des Hauses möglich. Auf den Peers muss FHEM nicht installiert werden. Neben dem Raspberry Pi Zero eignet sich auch z.B. der Radxa Rock Pi Zero, getestet mit Armbian. Die Peers können aus FHEM heraus verwaltet werden.
==== Installation auf FHEM-Server ====
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit

[Debian 11 (Bullseye)]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git libprotocol-websocket-perl</pre>

[alle anderen]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git</pre>
und als nächstes
<pre>
sudo cpan Protocol::WebSocket</pre>

Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt
update</pre>
Ist das Update abgeschlossen, können wir fhempy einrichten:
<pre>define fhempy_local BindingsIo fhempy</pre>
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.

Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre>
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.

==== Installation des fhempy-Peer ====
fhempy läuft nicht nur lokal auf dem FHEM-Server. Zur Reichweitenerhöhung kann auch ein fhempy-Peer auf einem oder mehreren RasPi’s installiert und diese über die Wohnung verteilt werden. Geeignet ist natürlich auch ein RasPi, der zur Visualisierung dient.
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi
<pre>pip3 install --upgrade fhempy</pre>
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer
<pre>fhempy</pre>
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre>
fhempy läuft nun unter dem User pi. Möchtest du das ändern, so schau in die Datei <code>fhempy.service</code> im Verzeichnis <code>/etc/systemd/system/</code> Hinterher das sudo systemctl daemon-reload nicht vergessen.
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre>

== Pairing ==
Die Thermostate mit einer Software größer 120 müssen mit dem RasPi gepaired werden. Drücke dazu das Rad am Thermostat bis „Pair“ im Display erscheint. Dann führe folgende Schritte aus:
<pre>
$ sudo bluetoothctl
[bluetooth]# power on
[bluetooth]# agent on
[bluetooth]# default-agent
[bluetooth]# scan on
[bluetooth]# scan off
[bluetooth]# pair 00:1A:22:06:A7:83
[agent] Enter passkey (number in 0-999999): <enter pin>
[bluetooth]# trust 00:1A:22:06:A7:83
[bluetooth]# disconnect 00:1A:22:06:A7:83
[bluetooth]# exit

Optional steps:
[bluetooth]# devices - to list all bluetooth devices
[bluetooth]# info 00:1A:22:06:A7:83
Device 00:1A:22:06:A7:83 (public)
Name: CC-RT-BLE
Alias: CC-RT-BLE
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)
ManufacturerData Key: 0x0000
ManufacturerData Value:
00 00 00 00 00 00 00 00 00 .........</pre>
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).

== Bekannte Probleme ==
=== Fehlermeldung nach fhempy-Installation ===
Meldet pip3 folgendes
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre>
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen
<pre>export PATH=$PATH:/home/myname/.local/bin</pre>
also z.B.
<pre>export PATH=$PATH:/home/pi/.local/bin</pre>

=== Keine Reaktion auf Einstellen der Offset-Temperatur ===
Zur Zeit scheint es ein Softwareproblem beim Einstellen der Offset-Temperatur über Bluetooth zu geben (Version 146 oder kleiner). Die Einstellung wird übertragen, wirkt sich aber nicht auf das Thermostat aus. Erst wenn man die Einstellung über das Menü am Thermostat bestätigt (oder gleich dort einstellt), reagiert das Thermostat. Das Problem tritt auch bei der Bedienung über die App auf.

== Links ==
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}

[[Kategorie:Heizungsventile]]
[[Kategorie:Bluetooth]]

Knxd

2023-01-02T11:56:06Z

F Klee: Info zum Parameter -R hinzu gefügt

== knxd mit einem IP Gateway einrichten ==
Damit FHEM auf den KNX Bus zugreifen kann, wird ein passendes Interface benötigt. Es gibt:
* RS232
* USB
* IP

Im Folgenden wird die Einrichtung von knxd mit einem IP Gateway auf einem Raspberry Pi2 mit Wheezy oder Jessie beschrieben.

=== Installation ===

==== Für Debian Jessie: ====
'''als erstes müssen folgende Pakete installiert werden (Referenz Debian Jessie):'''
<syntaxhighlight lang="bash">
sudo apt-get update
sudo apt-get install debhelper cdbs automake libtool libusb-1.0-0-dev git-core build-essential libsystemd-daemon-dev dh-systemd libev-dev cmake
</syntaxhighlight>

'''knxd herunterladen und installieren'''
Achtung: Wenn Abhängigkeiten fehlen, dann müssen diese nachinstalliert werden. Nicht einfach mittels "-d" diese übergehen!
<syntaxhighlight lang="bash">
git clone https://github.com/knxd/knxd.git
cd knxd
git checkout deb
dpkg-buildpackage -b -uc
cd ..
sudo dpkg -i knxd_*.deb knxd-tools_*.deb
</syntaxhighlight>

==== Ab Debian Stretch, Buster, ... ====
'''knxd ist in den Debian packages vorhanden, muss daher nicht compiliert werden.'''
<syntaxhighlight lang="bash">
sudo apt-get update
sudo apt-get install knxd knxd-tools

</syntaxhighlight>

Mit der Konfiguration '''mit Systemd weitermachen!'''
=== Konfiguration ===
'''1. Ohne systemd'''

Es muss als nächstes die Konfigurationsdatei editiert werden, das geht mit:
<syntaxhighlight lang="bash">
sudo nano /etc/default/knxd
</syntaxhighlight>
dann folgende Einträge anpassen:
<syntaxhighlight lang="bash">
DAEMON_ARGS="-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.188.XX"
</syntaxhighlight>
und
<syntaxhighlight lang="bash">
START_KNXD=YES
</syntaxhighlight>

'''2. Mit systemd z. B. für Debian Jessie'''

Die Konfigurationsdatei bei Jessie hat sich wegen der Nutzung von systemd geändert:
<syntaxhighlight lang="bash">
sudo nano /etc/knxd.conf
</syntaxhighlight>
dann folgende Einträge anpassen:
<syntaxhighlight lang="bash">
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b ipt:192.168.188.XX"

</syntaxhighlight>
=== knxd Status überprüfen ===
<syntaxhighlight lang="bash">
/etc/init.d/knxd status
</syntaxhighlight>

== knxd als IP-Gateway einrichten ==
Der knxd kann auch gleich als IP-Gateway eingerichtet und sowohl mit FHEM als auch parallel mit der ETS genutzt werden. Dazu ist, neben einem Raspberry Pi, ein Interface zum KNX-Bus erforderlich. Geeignet sind z.B.:
* ROT
* PIGATOR mit PIM-TPUART
* TUL
der Fa. [http://busware.de Busware]. Wer einen Rasperry Pi3 benutzen möchte, der sollte zum TUL greifen, da die serielle Schnittstelle UART0 das Bluetooth-Modul des Pi3 bedient und wieder auf die GPIO-Pins umgeleitet werden muss. Der TUL bringt seine eigene serielle Schnittstelle mit, so dass Bluetooth erhalten bleibt.

=== Vorbereiten des TUL ===
==== TUL flashen ====
Der TUL wird ohne Software geliefert und kann über den Raspberry Pi programmiert werden:
<syntaxhighlight lang="bash">
sudo apt-get install dfu-programmer
wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54
sudo dfu-programmer atmega32u4 erase
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex
sudo dfu-programmer atmega32u4 reset
sudo reboot
</syntaxhighlight>
Soll der TUL unter Windows programmiert werden, so geht das mit [https://www.microchip.com/developmenttools/ProductDetails/FLIP FLIP]. Die HEX-Datei kann [http://files.busware.de/TUL/Transparent/ hier] herunter geladen werden.
Der TUL hat an der Unterseite einen winzigen Button. Dieser muss gedrückt werden, während der TUL in die USB-Buchse gesteckt wird.
In FLIP nun als ''Device=>Select'' ATmega32U4 auswählen und über ''Settings=>Communication=>USB'' die Verbindung herstellen. *.hex-Datei laden und im Rahmen ''Operation-Flow'' auf ''Run'' klicken. Fertig.

==== TUL einen dauerhaften Namen geben ====
Linux bindet USB-Geräte beim Boot in einer eher zufälligen Reihenfolge ein. Werden mehrere USB-Geräte betrieben, so ist es sinnvoll, dem TUL einen festen Namen zuzuordnen. Dazu wird der TUL zunächst mit dem Befehl
<syntaxhighlight lang="bash">
ls -la /dev/serial/by-id/
</syntaxhighlight>
identifiziert. Das Ergebnis sollte ungefähr so aussehen
<syntaxhighlight lang="bash">
usb-busware.de_TPUART_8543934393935171B1C1-if00 -> ../../ttyACM0
</syntaxhighlight>
Die Seriennummer (8543934393935171B1C1) wird später benötigt. Der Befehl
<syntaxhighlight lang="bash">
lsusb
</syntaxhighlight>
sollte u.a. diese Zeile liefern
<syntaxhighlight lang="bash">
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
</syntaxhighlight>
03eb ist dabei die Herstellerkennung, 204b die Produktkennung. Nun muss die Datei /etc/udev/rules.d/99-usb-serial.rules
<syntaxhighlight lang="bash">
sudo nano /etc/udev/rules.d/99-usb-serial.rules
</syntaxhighlight>
erstellt oder erweitert werden mit der Zeile
<syntaxhighlight lang="bash">
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="8543934393935171B1C1", SYMLINK+="knx", OWNER="knxd"
</syntaxhighlight>
Der TUL wird dann unter /dev/knx erreichbar sein. Der knxd läuft als Benutzer knxd und hat damit die Berechtigung, auf den TUL zuzugreifen.

=== Vorbereiten des Raspberry Pi für ROT oder PIGATOR ===
Der Raspberry Pi nutzt standardmäßig die serielle Schnittstelle als Terminal. Dies muss deaktiviert werden:
<syntaxhighlight lang="bash">
sudo raspi-config
5 Interfaceoption
P6 Serial
</syntaxhighlight>
Der knxd arbeitet als Benutzer knxd. Nach der Installation von knxd muss dieser noch der Gruppe dialout zugeordnet werden, damit er auf ttyAMA0 zugreifen kann:
<syntaxhighlight lang="bash">
sudo usermod -aG dialout knxd
</syntaxhighlight>
Die Raspberry Pi 3 und 4 nutzen für die serielle Schnittstelle einen mini UART, der nicht mit dem knxd zusammenarbeitet. Der Hardware UART wird für Bluetooth verwendet. Bluetooth muss deaktiviert werden, damit der Hardware UART wieder unter ttyAMA0 zur Verfügung steht. In der /boot/config.txt muss die Zeile
<syntaxhighlight lang="bash">
dtoverlay=disable-bt
</syntaxhighlight>
am Ende eingefügt werden. Nun muss noch der Dienst hciuart deaktiviert werden (initialisiert das Bluetooth-Modem):
<syntaxhighlight lang="bash">
sudo systemctl disable hciuart
</syntaxhighlight>
Nach einem anschließenden Reboot ist der TPUART unter ttyAMA0 ansprechbar.

Nach dieser Prozedur ist natürlich die Benuzung des Bluetooth-Moduls nicht mehr möglich. Wer das Modul benötigt, findet die Anleitung hier:

[[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]

=== Andere BCU's (BusCouplerUnit) ===
Natürlich sind auch andere BCU's geeignet. Wer weiß, an welchem Ende er einen Lötkolben anzufassen hat, ist mit der [https://knx-user-forum.de/forum/projektforen/konnekting/1045398-microbcu-sehr-kleiner-knx-transceiver MicroBCU] gut bedient. Sie kann z.B. über einen ADUM1201 mit dem UART des Raspberry Pi verbunden werden (Tx->Rx, Rx->Tx, Konfiguration wie unter [[Knxd#Vorbereiten_des_Raspberry_Pi_f.C3.BCr_ROT_oder_PIGATOR|ROT]] beschrieben) oder über einen USB2Seriell-Konverter (Konfiguration ähnlich [[Knxd#TUL_einen_dauerhaften_Namen_geben|TUL]]).{{Hinweis|Die MicroBCU wird vom Bus gespeist und liefert auch zwei Spannungen, wovon die 3,3V auch für den ADUM genutzt werden kann. Wer den Raspi aus dem KNX-Netzteil versorgen möchte, sollte sich [https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/knx-eib-forum/diy-do-it-yourself/1597469-dualknx-microbcu-hat-f%C3%BCr-raspberrypi-mit-dc-dc-netzteil das hier] mal ansehen.}}

=== Installieren des knxd ===
Die Installation erfolgt nun wie oben unter [[Knxd#Installation|Installation]] beschrieben. Hier noch mal der dringende Hinweis, fehlende Abhängigkeiten nicht mit -d zu überspringen. Jede Abhängigkeit, die als Fehlend moniert wird, nachinstallieren und Kompilierung neu starten. Prozedur notfalls mehrfach wiederholen. Das Kompilieren dauert und manchmal geht es scheinbar nicht weiter. Also Geduld.

=== Konfiguration ===
Die Konfiguration erfolgt wieder in der knxd.conf mit
<syntaxhighlight lang="bash">
sudo nano /etc/knxd.conf
</syntaxhighlight>
Nun die Konfiguarionszeile anpassen<br>
(serielle Schnittstelle)
<syntaxhighlight lang="bash">
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b tpuarts:/dev/ttyAMA0"
</syntaxhighlight>
(USB)
<syntaxhighlight lang="bash">
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b tpuarts:/dev/knx"
</syntaxhighlight>
Und dann noch
<syntaxhighlight lang="bash">
START_KNXD=YES
</syntaxhighlight>
um knxd beim Systemstart sofort zu starten.

-e definiert die physikalische Adresse des knxd, -E definiert einen Adressbereich für ETS5 etc. (hier einen Bereich aus acht Adressen). Diese Adressen müssen an das eigene Netz angepasst werden. In FHEM sieht das dann so aus
<syntaxhighlight lang="bash">
define myKNXGW KNXIO T 127.0.0.1:6720 1.2.203
</syntaxhighlight>
alternativ via Multicast: (siehe auch KNXIO-wiki):<syntaxhighlight lang="bash">
define myKNXGW KNXIO M 224.0.23.12:3671 1.2.203
</syntaxhighlight>
Spätestens jetzt sollte der KNX-Bus angeschlossen werden.{{Hinweis|Da der TPUART (wie auch andere BCU‘s) vom Bus gespeist wird, kann der knxd den TPUART nur initialisieren, wenn der Bus angeschaltet ist.}}
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)
<syntaxhighlight lang="bash">
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
"1" durch "0" ersetzen
</syntaxhighlight>
Nach einem
<syntaxhighlight lang="bash">
sudo reboot
</syntaxhighlight>
sollte der knxd dann laufen.
{{Hinweis|Manche KNX-Module bringen zusätzlich eine IP-Gateway-Funktion mit (z.B. sonnenKNX zur Verbindung der sonnenBatterie mit dem KNX-Bus). Hier führt die Option -R in der Konfigurationsdatei zu Problemen (KNX-IP Daten werden mehrfach auf den Bus gespiegelt). Daher muss die Option -R entfernt werden (-DTS), wenn ein solches Modul nachträglich in das System integriert wird.}}

== FAQ ==
'''Wie wird eibd vorher deinstalliert?'''
<syntaxhighlight lang="bash">
sudo rm -r /usr/local/bin/{eibd,knxtool,group*} /usr/local/lib/lib{eib,pthsem}*.so* /usr/local/include/pth*
</syntaxhighlight>

<u>'''Hinweis'''</u>: knxd unterstützt im Gegensatz zu eibd die Hilfsprogramme knxtools nur sehr eingeschränkt (Siehe dazu Hinweis unter https://github.com/knxd/knxd#migrating-to-012. "progmode" sowie alle mit "m" beginnenden Kommandos sind entgegen der Doku ab Version 0.12 nicht mehr funktionsfähig.

'''folgender Fehler: dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2'''
<syntaxhighlight lang="bash">
sudo apt-get install git-core build-essential
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
in der datei knxd/debian/rules die Zeile:
bash tools/test.sh auskommentieren
</syntaxhighlight>

'''Fehler: dpkg-buildpackage: error: fakeroot not found, either install the fakeroot <....> '''
<syntaxhighlight lang="bash">
sudo apt-get install fakeroot dpkg-dev
</syntaxhighlight>

== Links ==
* [[Benutzer:Marthinx]]
* [https://github.com/knxd/knxd Github knxd]
* [https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen Forums-Thread zu knxd. Sehr informativ.]

[[Kategorie:Examples]]
[[Kategorie:EIB/KNX]]

Einrichten der Bluetooth-Thermostate von eQ-3

2022-12-28T16:50:53Z

F Klee: Keine Reaktion auf Einstellen der Offset-Temperatur hinzu gefügt

Die Firma eQ-3 stellt verschiedene elektronische Heizkörperthermostate her. Das Eqiva BLUETOOTH® Smart Heizkörperthermostat kann auch von FHEM gesteuert werden. Voraussetzung ist natürlich ein Bluetooth-Empfänger (RasPi 3+4 oder Bluetooth-Dongle).
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}
== Bluetooth einrichten ==
Standardmäßig sollte Bluetooth auf dem Raspberry Pi schon eingerichtet sein. Nutzt man einen B+ mit Dongle (z.B. als Verlängerung), so müssen unter Umständen folgende Pakete installiert werden:
<pre>sudo apt-get install bluetooth, bluez</pre>
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre>

<pre><policy user="fhem">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.GattCharacteristic1"/>
<allow send_interface="org.bluez.GattDescriptor1"/>
<allow send_interface="org.freedesktop.DBus.ObjectManager"/>
<allow send_interface="org.freedesktop.DBus.Properties"/>
</policy></pre>
<pre>sudo systemctl restart dbus</pre>
Für den User pi muss natürlich fhem durch pi ersetzt werden.

== Thermostat in FHEM definieren ==
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:
<pre>pi@raspberrypi ~ $ bluetoothctl
[NEW] Controller 00:1A:7D:XX:XX:XX raspberrypi [default]
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...
[bluetooth]# scan off</pre>
Die Geräte tragen den Namen CC-RT-BLE.

=== Einrichten mit Perl-Modul 10_EQ3BT ===
Die eQ-3 Heizkörperthermostate können einfach über
define <name> EQ3BT <mac address>
eingebunden werden.
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}

=== Einrichten mit fhempy ===
fhempy ermöglicht das Schreiben von FHEM-Modulen in der Programmiersprache Python. Erforderlich ist Python 3.8 oder höher (NICHT 2!), weshalb Debian Bullseye empfehlenswert ist. Es ist auch möglich, fhempy auf Peers zu installieren, um dadurch die Bluetooth-Reichweite zu erhöhen. Dadurch ist eine komplette Abdeckung des Hauses möglich. Auf den Peers muss FHEM nicht installiert werden. Neben dem Raspberry Pi Zero eignet sich auch z.B. der Radxa Rock Pi Zero, getestet mit Armbian. Die Peers können aus FHEM heraus verwaltet werden.
==== Installation auf FHEM-Server ====
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit

[Debian 11 (Bullseye)]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git libprotocol-websocket-perl</pre>

[alle anderen]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git</pre>
und als nächstes
<pre>
sudo cpan Protocol::WebSocket</pre>

Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt
update</pre>
Ist das Update abgeschlossen, können wir fhempy einrichten:
<pre>define fhempy_local BindingsIo fhempy</pre>
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.

Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre>
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.

==== Installation des fhempy-Peer ====
fhempy läuft nicht nur lokal auf dem FHEM-Server. Zur Reichweitenerhöhung kann auch ein fhempy-Peer auf einem oder mehreren RasPi’s installiert und diese über die Wohnung verteilt werden. Geeignet ist natürlich auch ein RasPi, der zur Visualisierung dient.
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi
<pre>pip3 install --upgrade fhempy</pre>
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer
<pre>fhempy</pre>
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre>
fhempy läuft nun unter dem User pi. Möchtest du das ändern, so schau in die Datei <code>fhempy.service</code> im Verzeichnis <code>/etc/systemd/system/</code> Hinterher das sudo systemctl daemon-reload nicht vergessen.
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre>

== Pairing ==
Die Thermostate mit einer Software größer 120 müssen mit dem RasPi gepaired werden. Drücke dazu das Rad am Thermostat bis „Pair“ im Display erscheint. Dann führe folgende Schritte aus:
<pre>
$ sudo bluetoothctl
[bluetooth]# power on
[bluetooth]# agent on
[bluetooth]# default-agent
[bluetooth]# scan on
[bluetooth]# scan off
[bluetooth]# pair 00:1A:22:06:A7:83
[agent] Enter passkey (number in 0-999999): <enter pin>
[bluetooth]# trust 00:1A:22:06:A7:83
[bluetooth]# disconnect 00:1A:22:06:A7:83
[bluetooth]# exit

Optional steps:
[bluetooth]# devices - to list all bluetooth devices
[bluetooth]# info 00:1A:22:06:A7:83
Device 00:1A:22:06:A7:83 (public)
Name: CC-RT-BLE
Alias: CC-RT-BLE
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)
ManufacturerData Key: 0x0000
ManufacturerData Value:
00 00 00 00 00 00 00 00 00 .........</pre>
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).

== Bekannte Probleme ==
=== Fehlermeldung nach fhempy-Installation ===
Meldet pip3 folgendes
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre>
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen
<pre>export PATH=$PATH:/home/myname/.local/bin</pre>
also z.B.
<pre>export PATH=$PATH:/home/pi/.local/bin</pre>

=== Keine Reaktion auf Einstellen der Offset-Temperatur ===
Zur Zeit scheint es ein Softwareproblem beim Einstellen der Offset-Temperatur über Bluetooth zu geben (Version 146 oder kleiner). Die Einstellung wird übertragen, wirkt sich aber nicht auf das Thermostat aus. Erst wenn man die Einstellung über das Menü am Thermostat bestätigt (oder gleich dort einstellt), reagiert das Thermostat. Das Problem tritt auch bei der Bedienung über die App auf.

== Links ==
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}

[[Kategorie:Heizungsventile]]
[[Kategorie:Bluetooth]]

Einrichten der Bluetooth-Thermostate von eQ-3

2022-12-26T18:41:34Z

F Klee: Ermitteln der MAC-Adresse erweitert

Die Firma eQ-3 stellt verschiedene elektronische Heizkörperthermostate her. Das Eqiva BLUETOOTH® Smart Heizkörperthermostat kann auch von FHEM gesteuert werden. Voraussetzung ist natürlich ein Bluetooth-Empfänger (RasPi 3+4 oder Bluetooth-Dongle).
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}
== Bluetooth einrichten ==
Standardmäßig sollte Bluetooth auf dem Raspberry Pi schon eingerichtet sein. Nutzt man einen B+ mit Dongle (z.B. als Verlängerung), so müssen unter Umständen folgende Pakete installiert werden:
<pre>sudo apt-get install bluetooth, bluez</pre>
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre>

<pre><policy user="fhem">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.GattCharacteristic1"/>
<allow send_interface="org.bluez.GattDescriptor1"/>
<allow send_interface="org.freedesktop.DBus.ObjectManager"/>
<allow send_interface="org.freedesktop.DBus.Properties"/>
</policy></pre>
<pre>sudo systemctl restart dbus</pre>
Für den User pi muss natürlich fhem durch pi ersetzt werden.

== Thermostat in FHEM definieren ==
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:
<pre>pi@raspberrypi ~ $ bluetoothctl
[NEW] Controller 00:1A:7D:XX:XX:XX raspberrypi [default]
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...
[bluetooth]# scan off</pre>
Die Geräte tragen den Namen CC-RT-BLE.

=== Einrichten mit Perl-Modul 10_EQ3BT ===
Die eQ-3 Heizkörperthermostate können einfach über
define <name> EQ3BT <mac address>
eingebunden werden.
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}

=== Einrichten mit fhempy ===
fhempy ermöglicht das Schreiben von FHEM-Modulen in der Programmiersprache Python. Erforderlich ist Python 3.8 oder höher (NICHT 2!), weshalb Debian Bullseye empfehlenswert ist. Es ist auch möglich, fhempy auf Peers zu installieren, um dadurch die Bluetooth-Reichweite zu erhöhen. Dadurch ist eine komplette Abdeckung des Hauses möglich. Auf den Peers muss FHEM nicht installiert werden. Neben dem Raspberry Pi Zero eignet sich auch z.B. der Radxa Rock Pi Zero, getestet mit Armbian. Die Peers können aus FHEM heraus verwaltet werden.
==== Installation auf FHEM-Server ====
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit

[Debian 11 (Bullseye)]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git libprotocol-websocket-perl</pre>

[alle anderen]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git</pre>
und als nächstes
<pre>
sudo cpan Protocol::WebSocket</pre>

Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt
update</pre>
Ist das Update abgeschlossen, können wir fhempy einrichten:
<pre>define fhempy_local BindingsIo fhempy</pre>
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.

Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre>
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.

==== Installation des fhempy-Peer ====
fhempy läuft nicht nur lokal auf dem FHEM-Server. Zur Reichweitenerhöhung kann auch ein fhempy-Peer auf einem oder mehreren RasPi’s installiert und diese über die Wohnung verteilt werden. Geeignet ist natürlich auch ein RasPi, der zur Visualisierung dient.
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi
<pre>pip3 install --upgrade fhempy</pre>
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer
<pre>fhempy</pre>
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre>
fhempy läuft nun unter dem User pi. Möchtest du das ändern, so schau in die Datei <code>fhempy.service</code> im Verzeichnis <code>/etc/systemd/system/</code> Hinterher das sudo systemctl daemon-reload nicht vergessen.
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre>

== Pairing ==
Die Thermostate mit einer Software größer 120 müssen mit dem RasPi gepaired werden. Drücke dazu das Rad am Thermostat bis „Pair“ im Display erscheint. Dann führe folgende Schritte aus:
<pre>
$ sudo bluetoothctl
[bluetooth]# power on
[bluetooth]# agent on
[bluetooth]# default-agent
[bluetooth]# scan on
[bluetooth]# scan off
[bluetooth]# pair 00:1A:22:06:A7:83
[agent] Enter passkey (number in 0-999999): <enter pin>
[bluetooth]# trust 00:1A:22:06:A7:83
[bluetooth]# disconnect 00:1A:22:06:A7:83
[bluetooth]# exit

Optional steps:
[bluetooth]# devices - to list all bluetooth devices
[bluetooth]# info 00:1A:22:06:A7:83
Device 00:1A:22:06:A7:83 (public)
Name: CC-RT-BLE
Alias: CC-RT-BLE
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)
ManufacturerData Key: 0x0000
ManufacturerData Value:
00 00 00 00 00 00 00 00 00 .........</pre>
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).

== Bekannte Probleme ==
=== Fehlermeldung nach fhempy-Installation ===
Meldet pip3 folgendes
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre>
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen
<pre>export PATH=$PATH:/home/myname/.local/bin</pre>
also z.B.
<pre>export PATH=$PATH:/home/pi/.local/bin</pre>

== Links ==
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}

[[Kategorie:Heizungsventile]]
[[Kategorie:Bluetooth]]

Einrichten der Bluetooth-Thermostate von eQ-3

2022-12-25T13:07:47Z

F Klee: /* Installation des fhempy-Peer */

Die Firma eQ-3 stellt verschiedene elektronische Heizkörperthermostate her. Das Eqiva BLUETOOTH® Smart Heizkörperthermostat kann auch von FHEM gesteuert werden. Voraussetzung ist natürlich ein Bluetooth-Empfänger (RasPi 3+4 oder Bluetooth-Dongle).
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}
== Bluetooth einrichten ==
Standardmäßig sollte Bluetooth auf dem Raspberry Pi schon eingerichtet sein. Nutzt man einen B+ mit Dongle (z.B. als Verlängerung), so müssen unter Umständen folgende Pakete installiert werden:
<pre>sudo apt-get install bluetooth, bluez</pre>
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre>

<pre><policy user="fhem">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.GattCharacteristic1"/>
<allow send_interface="org.bluez.GattDescriptor1"/>
<allow send_interface="org.freedesktop.DBus.ObjectManager"/>
<allow send_interface="org.freedesktop.DBus.Properties"/>
</policy></pre>
<pre>sudo systemctl restart dbus</pre>
Für den User pi muss natürlich fhem durch pi ersetzt werden.

== Thermostat in FHEM definieren ==
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:
<pre>sudo bluetoothctl
scan on</pre>
Die Geräte tragen den Namen CC-RT-BLE.

=== Einrichten mit Perl-Modul 10_EQ3BT ===
Die eQ-3 Heizkörperthermostate können einfach über
define <name> EQ3BT <mac address>
eingebunden werden.
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}

=== Einrichten mit fhempy ===
fhempy ermöglicht das Schreiben von FHEM-Modulen in der Programmiersprache Python. Erforderlich ist Python 3.8 oder höher (NICHT 2!), weshalb Debian Bullseye empfehlenswert ist. Es ist auch möglich, fhempy auf Peers zu installieren, um dadurch die Bluetooth-Reichweite zu erhöhen. Dadurch ist eine komplette Abdeckung des Hauses möglich. Auf den Peers muss FHEM nicht installiert werden. Neben dem Raspberry Pi Zero eignet sich auch z.B. der Radxa Rock Pi Zero, getestet mit Armbian. Die Peers können aus FHEM heraus verwaltet werden.
==== Installation auf FHEM-Server ====
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit

[Debian 11 (Bullseye)]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git libprotocol-websocket-perl</pre>

[alle anderen]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git</pre>
und als nächstes
<pre>
sudo cpan Protocol::WebSocket</pre>

Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt
update</pre>
Ist das Update abgeschlossen, können wir fhempy einrichten:
<pre>define fhempy_local BindingsIo fhempy</pre>
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.

Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre>
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.

==== Installation des fhempy-Peer ====
fhempy läuft nicht nur lokal auf dem FHEM-Server. Zur Reichweitenerhöhung kann auch ein fhempy-Peer auf einem oder mehreren RasPi’s installiert und diese über die Wohnung verteilt werden. Geeignet ist natürlich auch ein RasPi, der zur Visualisierung dient.
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi
<pre>pip3 install --upgrade fhempy</pre>
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer
<pre>fhempy</pre>
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre>
fhempy läuft nun unter dem User pi. Möchtest du das ändern, so schau in die Datei <code>fhempy.service</code> im Verzeichnis <code>/etc/systemd/system/</code> Hinterher das sudo systemctl daemon-reload nicht vergessen.
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre>

== Pairing ==
Die Thermostate mit einer Software größer 120 müssen mit dem RasPi gepaired werden. Drücke dazu das Rad am Thermostat bis „Pair“ im Display erscheint. Dann führe folgende Schritte aus:
<pre>
$ sudo bluetoothctl
[bluetooth]# power on
[bluetooth]# agent on
[bluetooth]# default-agent
[bluetooth]# scan on
[bluetooth]# scan off
[bluetooth]# pair 00:1A:22:06:A7:83
[agent] Enter passkey (number in 0-999999): <enter pin>
[bluetooth]# trust 00:1A:22:06:A7:83
[bluetooth]# disconnect 00:1A:22:06:A7:83
[bluetooth]# exit

Optional steps:
[bluetooth]# devices - to list all bluetooth devices
[bluetooth]# info 00:1A:22:06:A7:83
Device 00:1A:22:06:A7:83 (public)
Name: CC-RT-BLE
Alias: CC-RT-BLE
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)
ManufacturerData Key: 0x0000
ManufacturerData Value:
00 00 00 00 00 00 00 00 00 .........</pre>
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).

== Bekannte Probleme ==
=== Fehlermeldung nach fhempy-Installation ===
Meldet pip3 folgendes
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre>
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen
<pre>export PATH=$PATH:/home/myname/.local/bin</pre>
also z.B.
<pre>export PATH=$PATH:/home/pi/.local/bin</pre>

== Links ==
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}

[[Kategorie:Heizungsventile]]
[[Kategorie:Bluetooth]]

Einrichten der Bluetooth-Thermostate von eQ-3

2022-12-25T13:02:55Z

F Klee: /* Bluetooth einrichten */

Die Firma eQ-3 stellt verschiedene elektronische Heizkörperthermostate her. Das Eqiva BLUETOOTH® Smart Heizkörperthermostat kann auch von FHEM gesteuert werden. Voraussetzung ist natürlich ein Bluetooth-Empfänger (RasPi 3+4 oder Bluetooth-Dongle).
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}
== Bluetooth einrichten ==
Standardmäßig sollte Bluetooth auf dem Raspberry Pi schon eingerichtet sein. Nutzt man einen B+ mit Dongle (z.B. als Verlängerung), so müssen unter Umständen folgende Pakete installiert werden:
<pre>sudo apt-get install bluetooth, bluez</pre>
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre>

<pre><policy user="fhem">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.GattCharacteristic1"/>
<allow send_interface="org.bluez.GattDescriptor1"/>
<allow send_interface="org.freedesktop.DBus.ObjectManager"/>
<allow send_interface="org.freedesktop.DBus.Properties"/>
</policy></pre>
<pre>sudo systemctl restart dbus</pre>
Für den User pi muss natürlich fhem durch pi ersetzt werden.

== Thermostat in FHEM definieren ==
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:
<pre>sudo bluetoothctl
scan on</pre>
Die Geräte tragen den Namen CC-RT-BLE.

=== Einrichten mit Perl-Modul 10_EQ3BT ===
Die eQ-3 Heizkörperthermostate können einfach über
define <name> EQ3BT <mac address>
eingebunden werden.
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}

=== Einrichten mit fhempy ===
fhempy ermöglicht das Schreiben von FHEM-Modulen in der Programmiersprache Python. Erforderlich ist Python 3.8 oder höher (NICHT 2!), weshalb Debian Bullseye empfehlenswert ist. Es ist auch möglich, fhempy auf Peers zu installieren, um dadurch die Bluetooth-Reichweite zu erhöhen. Dadurch ist eine komplette Abdeckung des Hauses möglich. Auf den Peers muss FHEM nicht installiert werden. Neben dem Raspberry Pi Zero eignet sich auch z.B. der Radxa Rock Pi Zero, getestet mit Armbian. Die Peers können aus FHEM heraus verwaltet werden.
==== Installation auf FHEM-Server ====
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit

[Debian 11 (Bullseye)]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git libprotocol-websocket-perl</pre>

[alle anderen]
<pre>
sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git</pre>
und als nächstes
<pre>
sudo cpan Protocol::WebSocket</pre>

Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt
update</pre>
Ist das Update abgeschlossen, können wir fhempy einrichten:
<pre>define fhempy_local BindingsIo fhempy</pre>
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.

Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre>
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.

==== Installation des fhempy-Peer ====
Fhempy läuft nicht nur lokal auf dem FHEM-Server. Zur Reichweitenerhöhung kann auch ein fhempy-Peer auf einem oder mehreren RasPi’s installiert und diese über die Wohnung verteilt werden. Geeignet ist natürlich auch ein RasPi, der zur Visualisierung dient.
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi
<pre>pip3 install --upgrade fhempy</pre>
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer
<pre>fhempy</pre>
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre>
fhempy läuft nun unter dem User pi. Möchtest du das ändern, so schau in die Datei <code>fhempy.service</code> im Verzeichnis <code>/etc/systemd/system/</code> Hinterher das sudo systemctl daemon-reload nicht vergessen.
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre>

== Pairing ==
Die Thermostate mit einer Software größer 120 müssen mit dem RasPi gepaired werden. Drücke dazu das Rad am Thermostat bis „Pair“ im Display erscheint. Dann führe folgende Schritte aus:
<pre>
$ sudo bluetoothctl
[bluetooth]# power on
[bluetooth]# agent on
[bluetooth]# default-agent
[bluetooth]# scan on
[bluetooth]# scan off
[bluetooth]# pair 00:1A:22:06:A7:83
[agent] Enter passkey (number in 0-999999): <enter pin>
[bluetooth]# trust 00:1A:22:06:A7:83
[bluetooth]# disconnect 00:1A:22:06:A7:83
[bluetooth]# exit

Optional steps:
[bluetooth]# devices - to list all bluetooth devices
[bluetooth]# info 00:1A:22:06:A7:83
Device 00:1A:22:06:A7:83 (public)
Name: CC-RT-BLE
Alias: CC-RT-BLE
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)
ManufacturerData Key: 0x0000
ManufacturerData Value:
00 00 00 00 00 00 00 00 00 .........</pre>
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).

== Bekannte Probleme ==
=== Fehlermeldung nach fhempy-Installation ===
Meldet pip3 folgendes
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre>
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen
<pre>export PATH=$PATH:/home/myname/.local/bin</pre>
also z.B.
<pre>export PATH=$PATH:/home/pi/.local/bin</pre>

== Links ==
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}

[[Kategorie:Heizungsventile]]
[[Kategorie:Bluetooth]]