http://wiki.fhem.de/w/api.php?action=feedcontributions&user=F+Klee&feedformat=atomFHEMWiki - Benutzerbeiträge [de]2024-03-29T06:27:48ZBenutzerbeiträgeMediaWiki 1.39.3http://wiki.fhem.de/w/index.php?title=ABFALL&diff=39198ABFALL2024-03-23T15:35:03Z<p>F Klee: /* Voraussetzungen */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Filtern von (Abfall-)Terminen aus einem Calendar.<br />
|ModType=x<br />
|ModFTopic=48237<br />
|ModForumArea=Codeschnipsel<br />
|ModTechName=57_ABFALL.pm<br />
|ModOwner=Constantin / {{Link2FU|14026|uniqueck}}<br />
}}<br />
<br />
[[ABFALL]] ist ein (inoffizielles, nicht Bestandteil der Distribution) Hilfsmodul, das bestimmte Termine aus einem bestehenden Kalender des Moduls [[Calendar]] in Readings übernimmt. <br />
<br />
== Voraussetzungen ==<br />
Es muss ein [[Calendar]]-Objekt definiert sein. Der dabei benutzte Name muss in der Definition des ABFALL-Objekts spezifiziert werden.<br />
Es können auch mehrere Calendar Objekte übergeben werden.<br />
<br />
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.<br />
<br />
== Anwendung ==<br />
=== Installation ===<br />
Mit folgendem Befehl kann das Modul direkt in den Standard FHEM Update Prozess eingeklinkt werden.<br />
:<code>update add https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt</code><br />
Um es nur zu installieren, kann auch einfach nur das Command<br />
:<code>update all https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt</code><br />
eingegeben werden.<br />
<br />
=== Entwicklungsstrang ===<br />
:<code>update add https://raw.githubusercontent.com/uniqueck/fhem-abfall/develop/controls_fhemabfall.txt</code><br />
bzw.<br />
:<code>update all https://raw.githubusercontent.com/uniqueck/fhem-abfall/develop/controls_fhemabfall.txt</code><br />
<br />
=== Define ===<br />
:<code>define <Name> ABFALL <calendarname>,<calendarname2>,...</code><br />
<br />
Erläuterung der Parameter im '''define''':<br />
;<calendarname><br />
:Name des '''Calendar''' Kalenders <br />
<br />
Beispiel:<br />
:<code>define AbfallGoogleCalender Calendar ical url https://......</code><br />
:<code>define myABFALL ABFALL AbfallGoogleCalender</code><br />
<br />
=== Werte aktualisieren ===<br />
Die Werte aktualisieren sich abhängig vom [[notify]] der entsprechenden Calendar Instanz, welche im define angegeben wurde(n).<br />
<br />
=== Weitere Attribute ===<br />
<br />
{| class="wikitable"<br />
!Attribut<br />
!Werteliste<br />
!Beschreibung<br />
!Default Wert<br />
|-<br />
!align="right" |calendarname_praefix<br />
|0 und 1<br />
|soll der Kalendername als praefix dem Reading vorangestellt werden, sollte bei nur einem Kalender auf 0 gesetzt werden<br />
|1 - praefix wird vorangestellt, sofern mehrere Kalender angegeben wurden, ansonsten 0 - praefix wird nicht vorangestellt<br />
|-<br />
!align="right" |abfall_clear_reading_regex<br />
|<br />
|regex zum Entfernen von Anteilen aus dem Termin, dieser wird vor dem Entfernen von Sonderzeichen aus den Namen der Termine angewandt.<br />
|<br />
|-<br />
!align="right" |disable<br />
|0 und 1<br />
|deaktiviert das Modul<br />
|0<br />
|-<br />
!align="right" |weekday_mapping<br />
|<br />
|Mapping, wie die Readings der Tage angezeigt werden sollen, zum Beispiel So Mo Di Mi Do Fr Sa<br />
|Sonntag Montag Dienstag Mittwoch Donnerstag Freitag Samstag<br />
|-<br />
!align="right" |delimiter_text_reading<br />
|<br />
|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<br />
|und<br />
|-<br />
!align="right" |delimiter_reading<br />
|<br />
|wie attribute delimiter_text_reading, allerdings nur für die readings next und now<br />
|<br />
|-<br />
!align="right" |filter<br />
|<br />
|regex zum Filtern der Namen der Termine aus den Kalendern, so dass nur solche genutzt werden, welche diesem Filter entsprechen<br />
|<br />
|-<br />
|}<br />
<br />
== Anwendungsbeispiel(e) ==<br />
=== Einbindung ins Tablet UI ===<br />
<pre><div data-device="myABFALL" data-type="symbol" class="bigger warn wider" <br />
data-get="next" data-get-warn=".*(\d+).*" <br />
data-get-on='["Restmuell_.*","Wertstoff_.*"]'<br />
data-colors='["#000","#6EB54C"]' <br />
data-icons='["fa-trash-o","fa-trash-o"]'></div></pre><br />
<br />
=== Einbindung ins Tablet UI, erweitert ===<br />
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:<br />
* Anzeige unterschiedlicher Symbole bzw. Farben für Papiertonne, Restmülltonne, Biotonne und gelbe Säcke<br />
* Anzeige der verbleibenden Tage bis zur Leerung als "Warn"-Marker in Rot, aber nur, wenn die Leerung innerhalb der nächsten 2 Tage ist<br />
* Blinken des Symbols, wenn die nächste Leerung morgen ansteht<br />
* 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<br />
* Anzeige des Datums bzw. von "heute" oder "morgen" unter dem Symbol als Label<br />
<br />
Zur Datumsanzeige wird eine kleine Hilfsfunktion in die 99_myUtils eingebaut. <br />
<syntaxhighlight lang="perl"><br />
sub datumHeuteMorgen($){<br />
my $compareDate = shift;<br />
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);<br />
$year += 1900; $mon += 1; <br />
my $heute = sprintf('%02d.%02d.%04d', $mday, $mon, $year);<br />
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime(time+86400);<br />
$year += 1900; $mon += 1;<br />
my $morgen = sprintf('%02d.%02d.%04d', $mday, $mon, $year);<br />
return "heute" if $compareDate eq $heute;<br />
return "morgen" if $compareDate eq $morgen;<br />
return $compareDate;<br />
}<br />
</syntaxhighlight><br />
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.<br />
<br />
Folgende userReadings werden zum Abfallmodul hinzugefügt, welches in diesem Beispiel "myABFALL" genannt ist:<br />
<syntaxhighlight lang="perl"><br />
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";;}<br />
</syntaxhighlight><br />
Das Reading "ftui_next" bildet die Grundlage für das Symbol in TabletUI, das Reading "ftui_datum" wird für das Label genutzt. <br />
<br />
Somit lässt sich ganze in FTUI wie folgt darstellen:<br />
<syntaxhighlight lang="html"><br />
<div data-device="myABFALL" <br />
data-type="symbol"<br />
data-get="ftui_next"<br />
data-get-on='["Biotonne_0$","Biotonne_1$","Biotonne_.*","GelberSack_0$","GelberSack_1$","GelberSack_.*","Papiertonne_0$","Papiertonne_1$","Papiertonne_.*","Restmuelltonne_0$","Restmuelltonne_1$","Restmuelltonne_.*"]'<br />
data-get-warn=".*([0|1|2]).*"<br />
data-colors='["#8B4513","#8B4513","#8B4513","#f4e946","#f4e946","#f4e946","#2d9e1c","#2d9e1c","#2d9e1c","#696969","#696969","#696969"]'<br />
class="large warn"<br />
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"]'<br />
/><br />
<div data-device="myABFALL" data-get="ftui_datum" data-type="label"/><br />
</syntaxhighlight><br />
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.<br />
<br />
=== Benachrichtigung ===<br />
==== DOIF ====<br />
====== TelegramBot Beispiel ======<br />
<pre>[myABFALL:next_days] == 1) ( set fhemBot message 'Morgen wird [myABFALL:next_text] abgeholt')<br />
[myABFALL:now_text] ne "") ( set fhemBot message 'Heute wird [myABFALL:now_text] abgeholt')</pre><br />
<br />
====== Pushbullet Beispiel ======<br />
<br />
Die morgigen Leerungen per Push um 19:30 mittels [[Pushbullet]]:<br />
<br />
<code>define dAbfallmorgen doif ([19:30] and [myABFALL:next_days] == 1) ( msg |Morgen wird [myABFALL:next_text] abgeholt)<br />
<br />
attr dAbfallmorgen do always</code><br />
<br />
Die heutigen Leerungen per Push um 07:00 mittels Pushbullet:<br />
<br />
<code>define dAbfallheute doif ([07:00] and [myABFALL:now_text] ne "") ( msg |Heute wird [myABFALL:now_text] abgeholt)<br />
<br />
attr dAbfallheute do always</code><br />
<br />
=== Links ===<br />
* Forenthema {{Link2Forum|Topic=50177|LinkText=Abfall Visualisierung mit Bilderrahmen}}</div>F Kleehttp://wiki.fhem.de/w/index.php?title=At&diff=39179At2024-03-16T15:46:59Z<p>F Klee: /* at_ultimo */</p>
<hr />
<div>{{SEITENTITEL:at}}<br />
{{Infobox Modul<br />
|ModPurpose=Setzt einen Fhem-Befehl zu einem späteren Zeitpunkt ab.<br />
|ModType=h<br />
<!-- |ModCategory= (noch?) nicht verwendet --><br />
|ModCmdRef=at<br />
|ModTechName=90_at.pm<br />
|ModOwner={{Link2FU|8|rudolfkoenig}}<br />
}}<br />
<br />
[[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.<br />
<br />
== Voraussetzungen ==<br />
<!-- AUSKOMMENTIERT wegen derzeitiger Funktionsproblemen iZm codemirror {{Randnotiz|RNTyp=[g|Info|RNText=FHEM enthält für at eine eingebaute Perl-Syntax-Prüfung. Diese ist nach [http://fhem.de/commandref.html#perlSyntaxCheck Aktivierung] aber nur aktiv, wenn die [[Konfiguration]] -wie empfohlen- nicht direkt bearbeitet wird. ({{Link2Forum|Topic=51744}}) }} --><br />
Keine.<br />
<br />
== Anwendung ==<br />
=== Define ===<br />
<code>define <name> at <timespec|datespec> <command></code> <br />
<br />
=== Besonderheit ===<br />
*timespec - '''nur Zeit''' im Format HH:MM:SS '''kann eine''' Perlfunktion sein. <br />
*datespec - '''Datum und Zeit''' ISO 8601 oder "number of sec since 1970" '''darf keine''' Perlfunktion sein.<br />
Siehe {{Link2Forum|Topic=91625|Message=168475}} <br />
<br />
=== Beispiele ===<br />
*<code>define MeineAktion at 02:02:00 set lamp on</code> → das nächste Mal um zwei Minuten nach 2 Uhr "lamp" einschalten<br />
*<code>define MeineAktion at *02:02:00 set lamp on</code> → jeden Tag um zwei Minuten nach 2 Uhr "lamp" einschalten<br />
*<code>define MeineAktion at {ReadingsVal("Dummy","Zeit","")} set lamp on</code> → das nächste Mal um (Perlfunktion liest Zeit aus dem Dummy) "lamp" einschalten<br />
*<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)<br />
*<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)<br />
*<code>define MeineAktion at +02:02:00 set lamp on</code> → in zwei Stunden und 2 Minuten "lamp" einschalten<br />
*<code>define MeineAktion at +*02:02:00 set lamp on</code> → alle zwei Stunden und 2 Minuten "lamp" einschalten<br />
Um datespec auch variabel mit setzen zu können gibt es einen Workaround: Perlebene, Perlfunktion und Übergabe in Variable. <br />
<br />
Beispiele für "number of seconds since 1970"<br />
<syntaxhighlight lang="perl"><br />
{my $time=time_str2num("2019-09-14 23:00:00");;fhem("define MeineAktion at $time set lamp on")}<br />
{my $time=1568494800;;fhem("define MeineAktion at $time set lamp on")}<br />
</syntaxhighlight><br />
Beispiel im ISO 8601 Format<br />
<syntaxhighlight lang="perl">{my $time="2019-09-14T23:00:00";;fhem("define MeineAktion at $time set lamp on")}</syntaxhighlight><br />
<br />
=== Mehrere Aktionen ausführen ===<br />
Die Verwendung der Semikolon erfordert immer besondere Aufmerksamkeit!<br />
*<code>set lampe1 on ; set lampe2 on </code> → Schaltet sofort beide Lampen ein ( ein bisschen OT, weil kein at)<br />
*<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. <br />
*<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<br />
*<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<br />
<br />
=== at_ultimo ===<br />
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:<br />
<br />
<code><br />
define at_ultimo at *{at_ultimo()} set Lampe1 off<br />
</code><br />
<br />
Dadurch wird ein at-device erstellt, das am letzten Tag des Monats um 23:59:00 Uhr ausgeführt wird.<br />
<br />
at_ultimo() kann zusätzliche Parameter annehmen, um eine andere Zeit an diesem Tag anzugeben:<br />
<br />
<code><br />
define at_ultimo at *{at_ultimo(12,23,45)} set Lampe1 off<br />
</code><br />
<br />
Dadurch wird ein at-device erstellt, das am letzten Tag des Monats um 12:23:45 Uhr ausgeführt wird.<br />
<br />
=== Attribute ===<br />
...<br />
<br />
=== Testen ===<br />
{{Randnotiz|RNText='''Versionsspezifisch:''' Der Befehl ''execNow'' ist in FHEM 5.7/90_at.pm ab 30.4.2016 verfügbar.}}<br />
Mit dem Befehl <br />
:<code>set <devspec> execNow</code><br />
lässt sich eine ''at''-Definition (einmalig, beispielsweise zu Testzwecken) unabhängig vom Erreichen der angegebenen Zeitspezifikation ausführen.<br />
<br />
=== Ändern / Modifizieren ===<br />
Das Zeit-Attribut eines existierenden Timers sollte via <code>modifyTimeSpec</code> (Befehls-Syntax via Web-Interface ermitteln) geändert werden können.<br />
Details dazu in den Forenbeiträgen<br />
* {{Link2Forum|Topic=76227|LinkText=modifyTimeSpec fehlerhaft!?}}<br />
* {{Link2Forum|Topic=36326|LinkText=defmod}} <br />
<br />
== Anwendungsbeispiele ==<br />
* [[AT an einem bestimmten Wochentag ausführen|at an einem bestimmten Wochentag ausführen]]<br />
* [[AT um eine Temperaturabhängige Nachtabsenkung zu realisieren|at um eine Temperaturabhängige Nachtabsenkung zu realisieren]]<br />
* [[AT zu einem absoluten Datum ausführen|at zu einem absoluten Datum ausführen]]<br />
* [[SUNRISE_EL|at in Verbindung mit SUNRISE_EL]] <br />
<br />
== Links ==<br />
* Abfrage, ob at definiert ist: {{Link2Forum|Topic=23584|Message=841269}}</div>F Kleehttp://wiki.fhem.de/w/index.php?title=At&diff=39178At2024-03-16T15:42:15Z<p>F Klee: at_ultimo hinzu gefügt</p>
<hr />
<div>{{SEITENTITEL:at}}<br />
{{Infobox Modul<br />
|ModPurpose=Setzt einen Fhem-Befehl zu einem späteren Zeitpunkt ab.<br />
|ModType=h<br />
<!-- |ModCategory= (noch?) nicht verwendet --><br />
|ModCmdRef=at<br />
|ModTechName=90_at.pm<br />
|ModOwner={{Link2FU|8|rudolfkoenig}}<br />
}}<br />
<br />
[[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.<br />
<br />
== Voraussetzungen ==<br />
<!-- AUSKOMMENTIERT wegen derzeitiger Funktionsproblemen iZm codemirror {{Randnotiz|RNTyp=[g|Info|RNText=FHEM enthält für at eine eingebaute Perl-Syntax-Prüfung. Diese ist nach [http://fhem.de/commandref.html#perlSyntaxCheck Aktivierung] aber nur aktiv, wenn die [[Konfiguration]] -wie empfohlen- nicht direkt bearbeitet wird. ({{Link2Forum|Topic=51744}}) }} --><br />
Keine.<br />
<br />
== Anwendung ==<br />
=== Define ===<br />
<code>define <name> at <timespec|datespec> <command></code> <br />
<br />
=== Besonderheit ===<br />
*timespec - '''nur Zeit''' im Format HH:MM:SS '''kann eine''' Perlfunktion sein. <br />
*datespec - '''Datum und Zeit''' ISO 8601 oder "number of sec since 1970" '''darf keine''' Perlfunktion sein.<br />
Siehe {{Link2Forum|Topic=91625|Message=168475}} <br />
<br />
=== Beispiele ===<br />
*<code>define MeineAktion at 02:02:00 set lamp on</code> → das nächste Mal um zwei Minuten nach 2 Uhr "lamp" einschalten<br />
*<code>define MeineAktion at *02:02:00 set lamp on</code> → jeden Tag um zwei Minuten nach 2 Uhr "lamp" einschalten<br />
*<code>define MeineAktion at {ReadingsVal("Dummy","Zeit","")} set lamp on</code> → das nächste Mal um (Perlfunktion liest Zeit aus dem Dummy) "lamp" einschalten<br />
*<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)<br />
*<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)<br />
*<code>define MeineAktion at +02:02:00 set lamp on</code> → in zwei Stunden und 2 Minuten "lamp" einschalten<br />
*<code>define MeineAktion at +*02:02:00 set lamp on</code> → alle zwei Stunden und 2 Minuten "lamp" einschalten<br />
Um datespec auch variabel mit setzen zu können gibt es einen Workaround: Perlebene, Perlfunktion und Übergabe in Variable. <br />
<br />
Beispiele für "number of seconds since 1970"<br />
<syntaxhighlight lang="perl"><br />
{my $time=time_str2num("2019-09-14 23:00:00");;fhem("define MeineAktion at $time set lamp on")}<br />
{my $time=1568494800;;fhem("define MeineAktion at $time set lamp on")}<br />
</syntaxhighlight><br />
Beispiel im ISO 8601 Format<br />
<syntaxhighlight lang="perl">{my $time="2019-09-14T23:00:00";;fhem("define MeineAktion at $time set lamp on")}</syntaxhighlight><br />
<br />
=== Mehrere Aktionen ausführen ===<br />
Die Verwendung der Semikolon erfordert immer besondere Aufmerksamkeit!<br />
*<code>set lampe1 on ; set lampe2 on </code> → Schaltet sofort beide Lampen ein ( ein bisschen OT, weil kein at)<br />
*<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. <br />
*<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<br />
*<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<br />
<br />
=== at_ultimo ===<br />
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:<br />
<br />
<code><br />
define at_ultimo at *{at_ultimo()} set Lampe1 off<br />
</code><br />
<br />
Dadurch wird ein At-Gerät erstellt, das am letzten Tag des Monats um 23:59:00 Uhr ausgeführt wird.<br />
<br />
at_ultimo() kann zusätzliche Parameter annehmen, um eine andere Zeit an diesem Tag anzugeben:<br />
<br />
<code><br />
define at_ultimo at *{at_ultimo(12,23,45)} set Lampe1 off<br />
</code><br />
<br />
Dadurch wird ein AT-Gerät erstellt, das am letzten Tag des Monats um 12:23:45 Uhr ausgeführt wird.<br />
<br />
<br />
=== Attribute ===<br />
...<br />
<br />
=== Testen ===<br />
{{Randnotiz|RNText='''Versionsspezifisch:''' Der Befehl ''execNow'' ist in FHEM 5.7/90_at.pm ab 30.4.2016 verfügbar.}}<br />
Mit dem Befehl <br />
:<code>set <devspec> execNow</code><br />
lässt sich eine ''at''-Definition (einmalig, beispielsweise zu Testzwecken) unabhängig vom Erreichen der angegebenen Zeitspezifikation ausführen.<br />
<br />
=== Ändern / Modifizieren ===<br />
Das Zeit-Attribut eines existierenden Timers sollte via <code>modifyTimeSpec</code> (Befehls-Syntax via Web-Interface ermitteln) geändert werden können.<br />
Details dazu in den Forenbeiträgen<br />
* {{Link2Forum|Topic=76227|LinkText=modifyTimeSpec fehlerhaft!?}}<br />
* {{Link2Forum|Topic=36326|LinkText=defmod}} <br />
<br />
== Anwendungsbeispiele ==<br />
* [[AT an einem bestimmten Wochentag ausführen|at an einem bestimmten Wochentag ausführen]]<br />
* [[AT um eine Temperaturabhängige Nachtabsenkung zu realisieren|at um eine Temperaturabhängige Nachtabsenkung zu realisieren]]<br />
* [[AT zu einem absoluten Datum ausführen|at zu einem absoluten Datum ausführen]]<br />
* [[SUNRISE_EL|at in Verbindung mit SUNRISE_EL]] <br />
<br />
== Links ==<br />
* Abfrage, ob at definiert ist: {{Link2Forum|Topic=23584|Message=841269}}</div>F Kleehttp://wiki.fhem.de/w/index.php?title=AT_zu_einem_absoluten_Datum_ausf%C3%BChren&diff=38664AT zu einem absoluten Datum ausführen2023-11-03T15:30:59Z<p>F Klee: </p>
<hr />
<div>'''Achtung:''' der Befehl [[at]] kennt im Gegensatz zur Behauptung im Artikel unten durchaus Ausführungen zu einem bestimmten Datum.<br />
<br />
Das letztgenannte Beispiel kann z.b. mit<br />
<nowiki>define Licht_25_Januar_an at 2011-01-25T07:15:00 set Licht1 on</nowiki><br />
Realisiert werden, siehe auch Commandrefeintrag.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
________________________________________________________________________________________________<br />
<br />
<br />
<br />
Mit dem Befehl [[at]] können in FHEM Aktionen zu einem definierten Zeitpunkt ausgeführt werden:<br />
<br />
<nowiki>define morgens_Licht_an at *07:15:00 set Licht1 on</nowiki><br />
Es können nur relative und absolute Uhrzeiten, jedoch nicht ein bestimmtes Datum definiert werden.<br />
<br />
Allerdings kann die Ausführung an Bedingungen geknüpft sein, wie z.b. bestimmte Wochentage oder nur am Wochenende:<br />
<br />
<nowiki>define morgens_Licht_Wochenende at *07:15:00 {if (!($we)) {fhem("set Licht1 on")} }</nowiki><br />
Auf die selbe Art kann auch auf ein Ausführungsdatum geprüft werden.<br />
<br />
<nowiki>define Licht_25_Januar_an at *07:15:00 {if($year==2011 &amp;&amp; $month==1 &amp;&amp; $mday==25) {fhem("set Licht1 on")} }</nowiki><br />
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.<br />
<br />
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:<br />
<br />
<pre>define Licht_25_Januar_an at *07:15:00 {if($year==2011 &amp;&amp; $month==1 &amp;&amp; $mday==25) \<br />
{fhem ("set Licht1 on; delete Licht_25_Januar_an"} }</pre><br />
<br />
<br />
[[Kategorie:Code Snippets]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt&diff=38661MQTT2 DEVICE - Schritt für Schritt2023-10-28T16:20:31Z<p>F Klee: /* periodicCmd */</p>
<hr />
<div>== Einführung ==<br />
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.<br />
<br />
{{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.}}<br />
<br />
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.<br />
<br />
Ziel dieses Artikels ist die Darstellung der Schritte, die sich als zweckmäßig erwiesen haben zur Einrichtung von "guten" FHEM-Geräten.<br />
{{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:<br />
* standardisierte set- (und ggf. get-)-Kommandos, insbesondere unter Beachtung der [[DevelopmentGuidelinesReadings| Developer Guidelines für Readings]]<br />
* Schließen des Informationskreises von eventuellen Kommandos bis zur Rückmeldung des (externen) Gerätes oder Dienstes (im Folgenden: "Gegenstelle")<br />
* standardisierte Reading-Namen, damit möglichst Auswertungen nicht speziell an das jeweilige Gerät angepasst werden müssen<br />
* Reduzierung und Vermeidung von unnötigen Datenpunkten und Events<br />
* Einrichten von regelmäßigen Abfrage-Timern (falls erforderlich!).<br />
<br />
== Vorbereitung ==<br />
=== MQTT2_SERVER ===<br />
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.<br />
<br />
=== Begrifflichkeiten ===<br />
Ein typisches, von "autocreate" erstelltes Gerät sieht dann z.b. (mit autocreate = simple am MQTT2_SERVER) so aus:<br />
<syntaxhighlight lang="text"><br />
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD<br />
attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:tele/DVES_9B01BD/LWT:.* LWT\<br />
DVES_9B01BD:tele/DVES_9B01BD/UPTIME:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:tele/DVES_9B01BD/SENSOR:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:tele/DVES_9B01BD/INFO1:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:tele/DVES_9B01BD/INFO2:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:tele/DVES_9B01BD/INFO3:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:stat/DVES_9B01BD/RESULT:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:stat/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }<br />
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE<br />
</syntaxhighlight><br />
Wir unterscheiden bei jeder Zeile des readingList-Attributs vier Elemente, die ersten drei werden jeweils durch einen Doppelpunkt voneinander getrennt:<br />
==== CID ====<br />
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.<br />
==== Topic ====<br />
Datenpunkt, an den eine Information gesendet wird. Empfangsseitig sind dies hier z.B. ''tele/DVES_9B01BD/STATE'' oder ''tele/DVES_9B01BD/LWT''.<br />
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>,<br />
<br />
==== Payload ====<br />
Der jeweilige Nachrichteninhalt. Da dieser nicht im vorhinein bekannt ist, wird er in der readingList typischerweise als "beliebige Zeichenfolge" (".*") notiert.<br />
<br />
==== Auswertung ====<br />
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''.<br />
<br />
=== defaults ===<br />
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:<br />
* Änderungen der Topics und Topic-Sturkturen (ausgenommen den Fall, dass schon andere Gegenstellen im Einsatz sind, die identische Topics verwenden)<br />
* Vergabe von ''friendly names''<br />
<br />
== Bestandsaufnahme ==<br />
=== Projektseiten finden ===<br />
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.<br />
<br />
=== MQTT - Datenverkehr mitlesen ===<br />
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).<br />
<br />
=== readingList ===<br />
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.<br />
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:<br />
<syntaxhighlight lang="text"><br />
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD<br />
attr MQTT2_DVES_9B01BD readingList tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\<br />
tele/DVES_9B01BD/STATE:.* json_STATE\<br />
tele/DVES_9B01BD/LWT:.* LWT\<br />
[...]<br />
</syntaxhighlight><br />
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.<br />
<br />
=== ignoreRegexp ===<br />
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.<br />
<br />
Weiter ist zu empfehlen, in diese ignoreRegexp auch die Topics aufzunehmen, über die Gegenstellen typischerweise Kommandos entgegennehmen. Dies könnte z.B. so aussehen:<br />
<code>attr m2server ignoreRegexp shellies/[^/]+/command|cmnd/[^/]+/|homeassistant/.*/config|tasmota/discovery</code><br />
<br />
=== Viele Geräte? ===<br />
==== "split" ====<br />
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.<br />
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.<br />
<br />
==== bridgeRegexp ====<br />
{{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!}}<br />
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. <br />
<br />
== readingList optimieren==<br />
=== gute Reading-Namen - Klartext ===<br />
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:<br />
attr DEVICE readingList /dingtian/DEVNAME/out/lwt_availability:.* LWT<br />
<br />
=== Bedingte Hash-Rückgaben ===<br />
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:<br />
attr DEVICE readingList DEVNAME/relay/0:.* { $EVENT ? {state=>'on'} : {state=>'off'} }\<br />
DEVNAME/status:.* { $EVENT ? {LWT=>'Online'} : {LWT=>'Offline'} }<br />
Weiteres Beispiel: Der "state" kommt in Großschreibung und soll in Kleinschreibung geändert werden:<br />
attr DEVICE readingList switchbot/esp32_2/bot/switchbottwo/state:.* { { state => lc $EVENT } }<br />
<br />
=== json2nameValue() ===<br />
Mit Hilfe der Funktion json2nameValue() (in Verbindung mit dem attribut ''jsonMap'') lassen sich <br />
* "gute Reading-Namen" auch aus JSON-Payloads erzeugen (2. und 3. Argument)<br />
* unnötige Readings vorab ausfiltern (3., 4. und 5. Argument)<br />
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).<br />
Wird (übergangsweise!) ''autocreate'' in der ''complex''-Variante eingestellt, werden für alle (bisher nicht bekannten) Topics Einträge wie dieser erzeugt:<br />
attr MQTT2_DVES_9B01BD readingList tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT,'STATE_',$JSONMAP) }<br />
* 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.<br />
* 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. <br />
<br />
=== Auswertung unterbinden ===<br />
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:<br />
shellies/DEVNAME/temperature_f:.* {}<br />
<br />
Komplexer mit Auswertung der Payload:<br />
STATTOPIC/RESULT:.* { $EVENT =~ m{HSBColor...(\d+),(\d+),(\d+)} ? $2 eq ReadingsVal($NAME,'saturation','unknown') ? return : { saturation=>$2 } : return }<br />
<br />
=== Perl ===<br />
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.<br />
<br />
== Events optimieren==<br />
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.<br />
<br />
=== firmware-Einstellungen ===<br />
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?<br />
<br />
=== Auswertung unterbinden ===<br />
(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.<br />
Doppelungen sollten in jedem Fall vermieden werden!<br />
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.<br />
Für Daten aus JSON-Payloads besteht darüber hinaus die Möglichkeit, diese komplett auszufiltern (siehe jsonMap weiter oben)<br />
<br />
=== event-on-change-reading und Co. ===<br />
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:<br />
* [[Event-min-interval|event-min-interval]]<br />
* [[Event-on-update-reading|event-on-update-reading]]<br />
* timestamp-on-change-reading und<br />
* [[Event-aggregator|event-aggregator]]<br />
<br />
=== gute Reading-Namen - userReadings ===<br />
Manchmal werden per MQTT Werte übersendet, die so nicht direkt verwendbar sind. Beispiele hierfür wären:<br />
* Batteriespannungen in mV (z.B. bei zigbee2mqtt)<br />
* Farbwerte als Einzelreading (für die Anzeige in FHEM wird aber ein RGB-Wert benötigt)<br />
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!<br />
<br />
== setList ==<br />
<br />
=== Allgemeines ===<br />
Die setList ist dazu gedacht, Kommandos zu definieren, welche an die Gegenstelle gesendet werden können. <br />
<br />
=== Syntax ===<br />
In der Regel besteht jede Zeile aus folgenden, per Leerzeichen getrennten Argumenten: <br />
* einem setter-Namen, ggf. ergänzt durch ein widget (s.u.)<br />
* einem Topic, unter dem die Payload gesendet werden soll und<br />
* der Payload.<br />
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.<br />
<br />
=== on und off ===<br />
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.<br />
Hat ein Gerät mehrerer solcher "Hauptschalter", empfiehlt es sich, für jeden dieser Schalter eine eigene MQTT2_DEVICE-Instanz anzulegen.<br />
<br />
==== setStateList ====<br />
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.<br />
<br />
==== setExtensionsEvent ====<br />
Will man per SetExtensions realisierte laufende Timer visualisieren, empfiehlt es sich, dieses Attribut zu setzen. <br />
<br />
=== widgets ===<br />
In der setList können prinzipiell alle in [[FHEMWEB/Widgets|Widgets]] dargestellten Eingabemöglichkeiten verwendet werden.<br />
<br />
=== Perl-Kommandos ===<br />
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.<br />
<br />
== getList ==<br />
Die getList ist dazu gedacht, asynchrone Abfragen an die Gegenstelle zu ermöglichen. <br />
Die Syntax dabei ist<br />
* einem getter-Namen, ggf. ergänzt durch ein widget (s.u.)<br />
* Reading-Name, unter dem die Antwort erwartet wird<br />
* einem Topic, unter dem die Payload gesendet werden soll und<br />
* (optional) der Payload.<br />
Auch hier können diverse Variablen genutzt werden, und/oder das ganze für die Ausführung von Perl-Code genutzt werden.<br />
<br />
== periodicCmd ==<br />
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.<br />
<br />
== Abschließende Aufgaben ==<br />
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.<br />
<br />
== Hinweise ==<br />
<references /><br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:MQTT]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt&diff=38660MQTT2 DEVICE - Schritt für Schritt2023-10-28T16:03:05Z<p>F Klee: /* readingList */</p>
<hr />
<div>== Einführung ==<br />
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.<br />
<br />
{{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.}}<br />
<br />
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.<br />
<br />
Ziel dieses Artikels ist die Darstellung der Schritte, die sich als zweckmäßig erwiesen haben zur Einrichtung von "guten" FHEM-Geräten.<br />
{{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:<br />
* standardisierte set- (und ggf. get-)-Kommandos, insbesondere unter Beachtung der [[DevelopmentGuidelinesReadings| Developer Guidelines für Readings]]<br />
* Schließen des Informationskreises von eventuellen Kommandos bis zur Rückmeldung des (externen) Gerätes oder Dienstes (im Folgenden: "Gegenstelle")<br />
* standardisierte Reading-Namen, damit möglichst Auswertungen nicht speziell an das jeweilige Gerät angepasst werden müssen<br />
* Reduzierung und Vermeidung von unnötigen Datenpunkten und Events<br />
* Einrichten von regelmäßigen Abfrage-Timern (falls erforderlich!).<br />
<br />
== Vorbereitung ==<br />
=== MQTT2_SERVER ===<br />
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.<br />
<br />
=== Begrifflichkeiten ===<br />
Ein typisches, von "autocreate" erstelltes Gerät sieht dann z.b. (mit autocreate = simple am MQTT2_SERVER) so aus:<br />
<syntaxhighlight lang="text"><br />
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD<br />
attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:tele/DVES_9B01BD/LWT:.* LWT\<br />
DVES_9B01BD:tele/DVES_9B01BD/UPTIME:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:tele/DVES_9B01BD/SENSOR:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:tele/DVES_9B01BD/INFO1:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:tele/DVES_9B01BD/INFO2:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:tele/DVES_9B01BD/INFO3:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:stat/DVES_9B01BD/RESULT:.* { json2nameValue($EVENT) }\<br />
DVES_9B01BD:stat/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }<br />
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE<br />
</syntaxhighlight><br />
Wir unterscheiden bei jeder Zeile des readingList-Attributs vier Elemente, die ersten drei werden jeweils durch einen Doppelpunkt voneinander getrennt:<br />
==== CID ====<br />
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.<br />
==== Topic ====<br />
Datenpunkt, an den eine Information gesendet wird. Empfangsseitig sind dies hier z.B. ''tele/DVES_9B01BD/STATE'' oder ''tele/DVES_9B01BD/LWT''.<br />
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>,<br />
<br />
==== Payload ====<br />
Der jeweilige Nachrichteninhalt. Da dieser nicht im vorhinein bekannt ist, wird er in der readingList typischerweise als "beliebige Zeichenfolge" (".*") notiert.<br />
<br />
==== Auswertung ====<br />
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''.<br />
<br />
=== defaults ===<br />
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:<br />
* Änderungen der Topics und Topic-Sturkturen (ausgenommen den Fall, dass schon andere Gegenstellen im Einsatz sind, die identische Topics verwenden)<br />
* Vergabe von ''friendly names''<br />
<br />
== Bestandsaufnahme ==<br />
=== Projektseiten finden ===<br />
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.<br />
<br />
=== MQTT - Datenverkehr mitlesen ===<br />
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).<br />
<br />
=== readingList ===<br />
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.<br />
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:<br />
<syntaxhighlight lang="text"><br />
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD<br />
attr MQTT2_DVES_9B01BD readingList tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\<br />
tele/DVES_9B01BD/STATE:.* json_STATE\<br />
tele/DVES_9B01BD/LWT:.* LWT\<br />
[...]<br />
</syntaxhighlight><br />
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.<br />
<br />
=== ignoreRegexp ===<br />
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.<br />
<br />
Weiter ist zu empfehlen, in diese ignoreRegexp auch die Topics aufzunehmen, über die Gegenstellen typischerweise Kommandos entgegennehmen. Dies könnte z.B. so aussehen:<br />
<code>attr m2server ignoreRegexp shellies/[^/]+/command|cmnd/[^/]+/|homeassistant/.*/config|tasmota/discovery</code><br />
<br />
=== Viele Geräte? ===<br />
==== "split" ====<br />
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.<br />
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.<br />
<br />
==== bridgeRegexp ====<br />
{{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!}}<br />
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. <br />
<br />
== readingList optimieren==<br />
=== gute Reading-Namen - Klartext ===<br />
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:<br />
attr DEVICE readingList /dingtian/DEVNAME/out/lwt_availability:.* LWT<br />
<br />
=== Bedingte Hash-Rückgaben ===<br />
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:<br />
attr DEVICE readingList DEVNAME/relay/0:.* { $EVENT ? {state=>'on'} : {state=>'off'} }\<br />
DEVNAME/status:.* { $EVENT ? {LWT=>'Online'} : {LWT=>'Offline'} }<br />
Weiteres Beispiel: Der "state" kommt in Großschreibung und soll in Kleinschreibung geändert werden:<br />
attr DEVICE readingList switchbot/esp32_2/bot/switchbottwo/state:.* { { state => lc $EVENT } }<br />
<br />
=== json2nameValue() ===<br />
Mit Hilfe der Funktion json2nameValue() (in Verbindung mit dem attribut ''jsonMap'') lassen sich <br />
* "gute Reading-Namen" auch aus JSON-Payloads erzeugen (2. und 3. Argument)<br />
* unnötige Readings vorab ausfiltern (3., 4. und 5. Argument)<br />
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).<br />
Wird (übergangsweise!) ''autocreate'' in der ''complex''-Variante eingestellt, werden für alle (bisher nicht bekannten) Topics Einträge wie dieser erzeugt:<br />
attr MQTT2_DVES_9B01BD readingList tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT,'STATE_',$JSONMAP) }<br />
* 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.<br />
* 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. <br />
<br />
=== Auswertung unterbinden ===<br />
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:<br />
shellies/DEVNAME/temperature_f:.* {}<br />
<br />
Komplexer mit Auswertung der Payload:<br />
STATTOPIC/RESULT:.* { $EVENT =~ m{HSBColor...(\d+),(\d+),(\d+)} ? $2 eq ReadingsVal($NAME,'saturation','unknown') ? return : { saturation=>$2 } : return }<br />
<br />
=== Perl ===<br />
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.<br />
<br />
== Events optimieren==<br />
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.<br />
<br />
=== firmware-Einstellungen ===<br />
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?<br />
<br />
=== Auswertung unterbinden ===<br />
(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.<br />
Doppelungen sollten in jedem Fall vermieden werden!<br />
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.<br />
Für Daten aus JSON-Payloads besteht darüber hinaus die Möglichkeit, diese komplett auszufiltern (siehe jsonMap weiter oben)<br />
<br />
=== event-on-change-reading und Co. ===<br />
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:<br />
* [[Event-min-interval|event-min-interval]]<br />
* [[Event-on-update-reading|event-on-update-reading]]<br />
* timestamp-on-change-reading und<br />
* [[Event-aggregator|event-aggregator]]<br />
<br />
=== gute Reading-Namen - userReadings ===<br />
Manchmal werden per MQTT Werte übersendet, die so nicht direkt verwendbar sind. Beispiele hierfür wären:<br />
* Batteriespannungen in mV (z.B. bei zigbee2mqtt)<br />
* Farbwerte als Einzelreading (für die Anzeige in FHEM wird aber ein RGB-Wert benötigt)<br />
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!<br />
<br />
== setList ==<br />
<br />
=== Allgemeines ===<br />
Die setList ist dazu gedacht, Kommandos zu definieren, welche an die Gegenstelle gesendet werden können. <br />
<br />
=== Syntax ===<br />
In der Regel besteht jede Zeile aus folgenden, per Leerzeichen getrennten Argumenten: <br />
* einem setter-Namen, ggf. ergänzt durch ein widget (s.u.)<br />
* einem Topic, unter dem die Payload gesendet werden soll und<br />
* der Payload.<br />
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.<br />
<br />
=== on und off ===<br />
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.<br />
Hat ein Gerät mehrerer solcher "Hauptschalter", empfiehlt es sich, für jeden dieser Schalter eine eigene MQTT2_DEVICE-Instanz anzulegen.<br />
<br />
==== setStateList ====<br />
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.<br />
<br />
==== setExtensionsEvent ====<br />
Will man per SetExtensions realisierte laufende Timer visualisieren, empfiehlt es sich, dieses Attribut zu setzen. <br />
<br />
=== widgets ===<br />
In der setList können prinzipiell alle in [[FHEMWEB/Widgets|Widgets]] dargestellten Eingabemöglichkeiten verwendet werden.<br />
<br />
=== Perl-Kommandos ===<br />
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.<br />
<br />
== getList ==<br />
Die getList ist dazu gedacht, asynchrone Abfragen an die Gegenstelle zu ermöglichen. <br />
Die Syntax dabei ist<br />
* einem getter-Namen, ggf. ergänzt durch ein widget (s.u.)<br />
* Reading-Name, unter dem die Antwort erwartet wird<br />
* einem Topic, unter dem die Payload gesendet werden soll und<br />
* (optional) der Payload.<br />
Auch hier können diverse Variablen genutzt werden, und/oder das ganze für die Ausführung von Perl-Code genutzt werden.<br />
<br />
== periodicCmd ==<br />
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. <br />
<br />
== Abschließende Aufgaben ==<br />
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.<br />
<br />
== Hinweise ==<br />
<references /><br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:MQTT]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=SetList&diff=38659SetList2023-10-28T13:10:23Z<p>F Klee: /* Einschränkungen */</p>
<hr />
<div>{{SEITENTITEL:setList}} <!-- da richtige Schreibweise kleinen Anfangsbuchstaben hat --><br />
<!-- Infobox Attribut sinnvoll? --><br />
<br />
Das Attribut [[setList]] dient dazu, bei generischen Devices die Liste der möglichen set Kommandos zu spezifizieren. <br />
<br />
{{Todo|Bitte analog zu [[eventMap]] mit Inhalt füllen.}}<br />
<br />
== Syntax ==<br />
Das ''setList'' Attribut wird in der folgenden Weise spezifiziert:<br />
:<code><nowiki>attr <device> setList <Reading1>:⟨<Modifier1>,⟩<Value1>,<Value2>,<...> <Reading2>:⟨<Modifier2>,⟩<Value1>,<Value2>,<...> ...</nowiki></code><br />
Es ist auch möglich, zur Verbesserung der Übersichtlichkeit und Lesbarkeit, das setList Attribut mehrzeilig zu formulieren.<br />
<br />
== Einschränkungen == <br />
Dieses Attribut existiert nur bei [[DOIF]]-, [[dummy]]-, [[MSwitch]]- und [[readingsProxy]]-Devices.<br />
[[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.<br />
<br />
== Beispiele ==<br />
<br />
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.<br />
define Raumtemperatur dummy<br />
attr Raumtemperatur setList :slider,10,0.5,30<br />
<br />
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.<br />
define Wecker_Uhrzeit dummy<br />
attr Wecker_Uhrzeit setList :time<br />
<br />
Möchte man Farbwerte einstellen, kann man ''colorpicker'' verwenden. Damit kann dann auf einer Palette eine Farbe gewählt werden.<br />
define Farbe dummy<br />
attr Farbe setList :colorpicker<br />
<br />
<br />
define Wecker_Uhrzeit dummy<br />
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<br />
attr Wecker_Uhrzeit readingList state<br />
attr Wecker_Uhrzeit webCmd state<br />
<br />
define Beschattung_auto dummy<br />
attr Beschattung_auto setList state:aktiv,passiv<br />
attr Beschattung_auto readingList state<br />
attr Beschattung_auto webCmd state<br />
<br />
define Heizungsmodus dummy<br />
attr Heizungsmodus setList state:auto,FHEM,Frostschutz,AUS<br />
attr Heizungsmodus readingList state<br />
attr Heizungsmodus webCmd state<br />
<br />
define TV_ProgrammKanal dummy<br />
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<br />
attr TV_ProgrammKanal readingList state<br />
<br />
define benzinpreis dummy<br />
attr benzinpreis readingList SuperE5_2 SuperPlus_2<br />
attr benzinpreis setList SuperE5_2:slider,140,1,200 SuperPlus_2:slider,140,1,200<br />
attr benzinpreis stateFormat SuperE5, SuperPlus<br />
attr benzinpreis userReadings SuperE5 {(ReadingsVal("oil","SuperE5_2",0) / 100 )}, SuperPlus {(ReadingsVal("oil","SuperPlus_2",0) / 100 )}<br />
attr benzinpreis webCmd SuperE5_2:SuperPlus_2<br />
<br />
== Links ==<br />
* Ausführliche Beschreibung (mit Beispielen) zu [[eventMap]], [[devStateIcon]], setList und [[webCmd]] in {{Link2Forum|Topic=12080|LinkText=diesem Forenthread}}<br />
<br />
[[Kategorie:Attribut (allgemeingültig)]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=SetList&diff=38658SetList2023-10-28T13:03:50Z<p>F Klee: /* Syntax */</p>
<hr />
<div>{{SEITENTITEL:setList}} <!-- da richtige Schreibweise kleinen Anfangsbuchstaben hat --><br />
<!-- Infobox Attribut sinnvoll? --><br />
<br />
Das Attribut [[setList]] dient dazu, bei generischen Devices die Liste der möglichen set Kommandos zu spezifizieren. <br />
<br />
{{Todo|Bitte analog zu [[eventMap]] mit Inhalt füllen.}}<br />
<br />
== Syntax ==<br />
Das ''setList'' Attribut wird in der folgenden Weise spezifiziert:<br />
:<code><nowiki>attr <device> setList <Reading1>:⟨<Modifier1>,⟩<Value1>,<Value2>,<...> <Reading2>:⟨<Modifier2>,⟩<Value1>,<Value2>,<...> ...</nowiki></code><br />
Es ist auch möglich, zur Verbesserung der Übersichtlichkeit und Lesbarkeit, das setList Attribut mehrzeilig zu formulieren.<br />
<br />
== Einschränkungen == <br />
Dieses Attribut existiert nur bei [[DOIF]]-, [[dummy]]-, [[MSwitch]]- und [[readingsProxy]]-Devices.<br />
<br />
== Beispiele ==<br />
<br />
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.<br />
define Raumtemperatur dummy<br />
attr Raumtemperatur setList :slider,10,0.5,30<br />
<br />
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.<br />
define Wecker_Uhrzeit dummy<br />
attr Wecker_Uhrzeit setList :time<br />
<br />
Möchte man Farbwerte einstellen, kann man ''colorpicker'' verwenden. Damit kann dann auf einer Palette eine Farbe gewählt werden.<br />
define Farbe dummy<br />
attr Farbe setList :colorpicker<br />
<br />
<br />
define Wecker_Uhrzeit dummy<br />
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<br />
attr Wecker_Uhrzeit readingList state<br />
attr Wecker_Uhrzeit webCmd state<br />
<br />
define Beschattung_auto dummy<br />
attr Beschattung_auto setList state:aktiv,passiv<br />
attr Beschattung_auto readingList state<br />
attr Beschattung_auto webCmd state<br />
<br />
define Heizungsmodus dummy<br />
attr Heizungsmodus setList state:auto,FHEM,Frostschutz,AUS<br />
attr Heizungsmodus readingList state<br />
attr Heizungsmodus webCmd state<br />
<br />
define TV_ProgrammKanal dummy<br />
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<br />
attr TV_ProgrammKanal readingList state<br />
<br />
define benzinpreis dummy<br />
attr benzinpreis readingList SuperE5_2 SuperPlus_2<br />
attr benzinpreis setList SuperE5_2:slider,140,1,200 SuperPlus_2:slider,140,1,200<br />
attr benzinpreis stateFormat SuperE5, SuperPlus<br />
attr benzinpreis userReadings SuperE5 {(ReadingsVal("oil","SuperE5_2",0) / 100 )}, SuperPlus {(ReadingsVal("oil","SuperPlus_2",0) / 100 )}<br />
attr benzinpreis webCmd SuperE5_2:SuperPlus_2<br />
<br />
== Links ==<br />
* Ausführliche Beschreibung (mit Beispielen) zu [[eventMap]], [[devStateIcon]], setList und [[webCmd]] in {{Link2Forum|Topic=12080|LinkText=diesem Forenthread}}<br />
<br />
[[Kategorie:Attribut (allgemeingültig)]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=SetList&diff=38657SetList2023-10-28T12:59:57Z<p>F Klee: /* Syntax */</p>
<hr />
<div>{{SEITENTITEL:setList}} <!-- da richtige Schreibweise kleinen Anfangsbuchstaben hat --><br />
<!-- Infobox Attribut sinnvoll? --><br />
<br />
Das Attribut [[setList]] dient dazu, bei generischen Devices die Liste der möglichen set Kommandos zu spezifizieren. <br />
<br />
{{Todo|Bitte analog zu [[eventMap]] mit Inhalt füllen.}}<br />
<br />
== Syntax ==<br />
Das ''setList'' Attribut wird in der folgenden Weise spezifiziert:<br />
:<code><nowiki>attr <device> setList <Reading1>:⟨<Modifier1>,⟩<Value1>,<Value2>,<...> <Reading2>:⟨<Modifier2>,⟩<Value1>,<Value2>,<...> ...</nowiki></code><br />
<br />
== Einschränkungen == <br />
Dieses Attribut existiert nur bei [[DOIF]]-, [[dummy]]-, [[MSwitch]]- und [[readingsProxy]]-Devices.<br />
<br />
== Beispiele ==<br />
<br />
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.<br />
define Raumtemperatur dummy<br />
attr Raumtemperatur setList :slider,10,0.5,30<br />
<br />
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.<br />
define Wecker_Uhrzeit dummy<br />
attr Wecker_Uhrzeit setList :time<br />
<br />
Möchte man Farbwerte einstellen, kann man ''colorpicker'' verwenden. Damit kann dann auf einer Palette eine Farbe gewählt werden.<br />
define Farbe dummy<br />
attr Farbe setList :colorpicker<br />
<br />
<br />
define Wecker_Uhrzeit dummy<br />
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<br />
attr Wecker_Uhrzeit readingList state<br />
attr Wecker_Uhrzeit webCmd state<br />
<br />
define Beschattung_auto dummy<br />
attr Beschattung_auto setList state:aktiv,passiv<br />
attr Beschattung_auto readingList state<br />
attr Beschattung_auto webCmd state<br />
<br />
define Heizungsmodus dummy<br />
attr Heizungsmodus setList state:auto,FHEM,Frostschutz,AUS<br />
attr Heizungsmodus readingList state<br />
attr Heizungsmodus webCmd state<br />
<br />
define TV_ProgrammKanal dummy<br />
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<br />
attr TV_ProgrammKanal readingList state<br />
<br />
define benzinpreis dummy<br />
attr benzinpreis readingList SuperE5_2 SuperPlus_2<br />
attr benzinpreis setList SuperE5_2:slider,140,1,200 SuperPlus_2:slider,140,1,200<br />
attr benzinpreis stateFormat SuperE5, SuperPlus<br />
attr benzinpreis userReadings SuperE5 {(ReadingsVal("oil","SuperE5_2",0) / 100 )}, SuperPlus {(ReadingsVal("oil","SuperPlus_2",0) / 100 )}<br />
attr benzinpreis webCmd SuperE5_2:SuperPlus_2<br />
<br />
== Links ==<br />
* Ausführliche Beschreibung (mit Beispielen) zu [[eventMap]], [[devStateIcon]], setList und [[webCmd]] in {{Link2Forum|Topic=12080|LinkText=diesem Forenthread}}<br />
<br />
[[Kategorie:Attribut (allgemeingültig)]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=VALVES&diff=38371VALVES2023-05-20T14:23:19Z<p>F Klee: Link zum Support-Thread hinzu gefügt</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Durchschnitt mit individueller Gewichtung und Ignore<br />
<!-- |ModCategory= (noch?) nicht verwendet --><br />
|ModType=x<br />
<!-- |ModCmdRef= ---- noch nicht Teil von FHEM --><br />
|ModForumArea=codeschnipsel<br />
|ModTechName=39_VALVES.pm<br />
|ModOwner=epsrw1,cwagner}}<br />
[[VALVES]] bietet eine einfache Möglichkeit, den nach flexibel konfigurierbaren Regeln gewichteten Durchschnittswert einer Gruppe von Werten zu berechnen.<br />
<br />
== Features ==<br />
<u>Diese Wiki-Seite beschreibt den Versionsstand 1.0 des VALVES-Moduls.</u> <br />
<br />
Die Namensgebung beruht auf der primären Anwendung des Moduls auf Valve-Position-Readings von Heizungsthermostaten.<br />
<br />
Thread im Forum:{{Link2Forum|Topic=24658|Message=177528}}<br />
<br />
== Beschreibung ==<br />
[[Datei:dok39_VALVES.jpg|mini|Funktionsweise]]<br />
<br />
VALVES bietet als kleines Helferlein die Möglichkeit, einen halbwegs sinnvollen und individuell gewichteten Durchschnittswert der Readings mehrerer verschiedener Devices zu berechnen.<br />
<br />
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.<br />
<br />
''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.''<br />
<br />
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.<br />
<br />
Für die Beeinflussung des Durchschnittes hat man folgende Attribute:<br />
<br />
* ignoriere niedrigste 0...3 Positionen<br />
<br />
* ignoriere höchste 0...3 Positionen<br />
<br />
* ignoriere namentlich genannte Devices<br />
<br />
* priority-device Liste (zählen doppelt)<br />
<br />
* 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.<br />
<br />
== Define ==<br />
:<code>define <name> VALVES </code><br />
<br />
== Attribute ==<br />
Alle Attribute sind auch in FHEM durch das Kommando get attrHelp <varname> erklärt, fürs "schnelle Nachschauen zwischendurch".<br />
<br />
valvesInitialDelay -> Startverzögerung<br />
<br />
valvesPollInterval -> Berechnungsfrequenz<br />
<br />
valvesDeviceList -> '''Pflicht-Attr''', Liste Thermostate mit valve-pos Readings<br />
<br />
valvesDeviceReading -> '''Pflicht-Attr''', Bezeichnung valve-pos Reading<br />
<br />
valvesIgnoreLowest -> Niedrigste N Werte ignorieren<br />
<br />
valvesIgnoreHighest -> Höchste N Werte ignorieren<br />
<br />
valvesIgnoreDeviceList -> Device(s) die komplett ignoriert werden, z.B. temporärer Eintrag für Gästezimmer<br />
<br />
valvesPriorityDeviceList -> Devices, die doppelt gezählt werden<br />
<br />
valves<Devicename> Gewichtung -> Faktor für einzelnes Device für individuelle Gewichtung<br />
<br />
== Settings ==<br />
reset -> Alle Readings zurücksetzen<br />
<br />
== Readings ==<br />
state -> Fehlermeldung oder Mittelwert nach oben beschriebener Berechnung<br />
<br />
valve_<Devicename> -> Berechnete virtuelle Ventilstellung pro Gerät<br />
<br />
valveDetail_<Devicename> -> Debug-Info mit Details<br />
<br />
raw_average -> Simpler Mittelwert ohne Berücksichtigung der Gewichtungen (ignores werden auch hier ignoriert)<br />
<br />
valve_average -> Mittelwert nach oben beschriebener Berechnung<br />
<br />
valve_max -> Größte aktuelle Ventilöffnung seit letztem Reset<br />
<br />
valve_min -> Kleinste aktuelle Ventilöffnung seit letztem Reset<br />
<br />
== Weblinks ==<br />
* {{Link2Forum|Topic=24658|Message=177528}} Thread im Forum, in dem dieses Modul vorgestellt wurde<br />
* {{Link2Forum|Topic=131849|Message=0}} Support-Thread<br />
* ...<br />
<br />
[[Kategorie:Regelungstechnik]]<br />
[[Kategorie:Heizungssteuerung]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=OpenWB&diff=38244OpenWB2023-04-05T06:40:56Z<p>F Klee: Zur Kategorie "HOWTOS" hinzu gefügt</p>
<hr />
<div>== Integration der openWB in FHEM - Ladeleistung anzeigen und Umschalten des Lademodus ==<br />
Ausgangssituation ist ein funktionierendes FHEM, ohne weitere Vorbedingungen.<syntaxhighlight lang="perl"><br />
defmod openwb MQTT <openWBip>:1883<br />
attr openwb room Auto,MQTT<br />
<br />
</syntaxhighlight>Dadurch wird der MQTT-Server der openWB angesprochen, FHEM ist der Client.<br />
<br />
Ein Ladepunkt wird als MQTT_Device angelegt:<syntaxhighlight lang="perl"><br />
defmod lp1 MQTT_DEVICE<br />
attr lp1 IODev openwb<br />
attr lp1 publishSet_chargeMode openWB/set/ChargeMode<br />
attr lp1 room Auto,Dashboard,MQTT<br />
attr lp1 stateFormat power<br />
attr lp1 subscribeReading_chargeMode openWB/global/ChargeMode<br />
attr lp1 subscribeReading_plugStat openWB/lp/1/boolPlugStat<br />
attr lp1 subscribeReading_power openWB/lp/1/W<br />
</syntaxhighlight>Die Umsetzung basiert auf openWB 1.9.x, der Lademodus "ChargeMode" gilt hier noch global für alle Ladepunkte.<br />
<br />
Beispielhaft die Definition des zweiten Ladepunktes, eine zweite openWB, die als "nur Ladepunkt" mit der angesprochenen openWB verbunden ist.<br />
<br />
Eine openWB kann derzeit 8 Ladepunkte verwalten, die Nummern müssen entsprechend inkrementiert werden.<syntaxhighlight lang="perl"><br />
defmod lp2 MQTT_DEVICE<br />
attr lp2 IODev openwb<br />
attr lp2 publishSet_chargeMode openWB/set/ChargeMode<br />
attr lp2 room Auto,Dashboard,MQTT<br />
attr lp2 stateFormat power<br />
attr lp2 subscribeReading_chargeMode openWB/global/ChargeMode<br />
attr lp2 subscribeReading_plugStat openWB/lp/2/boolPlugStat<br />
attr lp2 subscribeReading_power openWB/lp/2/W<br />
</syntaxhighlight>Die MQTT-Topics zum Lesen und Schreiben von Werten sind ganz unten auf dieser Wiki-Seite zu finden.<br />
<br />
Die Einbindung in die TabletUI sieht bei mir so aus:<br />
[[Datei:Ladepunkte in TabletUI.png|alternativtext=Darstellung der openWB Ladepunkte in der TabletUI|mini|488x488px|Beispielhafte Darstellung in der TabletUI]]<br />
[[Datei:Auswahl des Lademodus.png|alternativtext=Darstellung der openWB Ladepunkte in der TabletUI - Auswahl des Lademodus|mini|486x486px|Auswahl des Lademodus per CircleMenu]]<br />
<syntaxhighlight lang="html"><br />
<div class="cell-60 left-space right-space"><br />
<div data-type="symbol" data-icon="fa-car" class="tall compressed" data-color="lightgray"><br />
<div data-type="circlemenu" data-direction="full" class="mini" style="top: -0.5em;"><br />
<ul class="mini"><br />
<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><br />
<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><br />
<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><br />
<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><br />
<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><br />
<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><br />
</ul><br />
</div><br />
<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><br />
<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><br />
</div><br />
</div><br />
<br />
</syntaxhighlight><br />
<br />
==Integration OpenWB in FHEM - Übertragung von EVU, PV und Batteriewerten an openWB==<br />
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.<br />
<br />
=== Datenquellen ===<br />
Die OpenWB erwartet 1-3 Typen von Datenquellen in dieser Konstellation:<br />
* 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)<br />
* Die ''PV-''Schnittstelle, die ebenfalls primär visualisierende Bedeutung hat.<br />
* Die ''Batteriespeicher-''Schnittstelle<br />
OpenWB kann auch z.B. rein mit einer PV-Schnittstelle betrieben werden, in diesem Fall wird ein konstanter Leistungswert für den Hausbezug angenommen.<br />
<br />
=== Kommunikationsprotokoll ===<br />
Zur Kommunikation mit FHEM bieten sich 2 Methoden an:<br />
* '''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<br />
* '''MQTT'''-Push durch FHEM zur OpenWB Diese Methode erscheint mir vorteilhafter, weil auf einer stehenden TCP-Verbindung lediglich Meßwerte gepusht werden.<br />
<br />
=== Implementierung ===<br />
<br />
==== Vorbereitung ====<br />
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!<br />
<br />
==== Definition der OpenWB als MQTT-Target ====<br />
defmod openwb_mqtt MQTT2_CLIENT <ip-der-openwb>:1883<br />
attr openwb_mqtt autocreate simple<br />
attr openwb_mqtt subscriptions openWB/lp/1/#<br />
<br />
==== Übertragung der EVU-Meßwerte ====<br />
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:<br />
defmod openwb_evu_cons notify MT175:total_consumption:.* { fhem("set openwb_mqtt publish openWB/set/evu/WhImported " . $EVTPART1); }<br />
defmod openwb_evu_feed notify MT175:total_feed:.* { fhem("set openwb_mqtt publish openWB/set/evu/WhExported " . $EVTPART1); }<br />
defmod openwb_evu_w notify MT175:power:.* { fhem("set openwb_mqtt publish openWB/set/evu/W " . int($EVTPART1)); }<br />
<br />
==== Übertragung der PV-Meßwerte ====<br />
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:<br />
* Für den Momentan-Leistungswert <code>openWB/set/pv/1/W</code><br />
* Für den Zählerstand <code>openWB/set/pv/1/WhCounter</code><br />
Dabei muss beachtet werden, dass - wie bei der EVU-Schnittstelle - nur Integerwerte für die Momentanleistung übertragen werden dürfen.<br />
<br />
==== Anbindung an Alexa ====<br />
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:<br />
* ''"Alexa, schalte Überschussladen ein"''<br />
* ''"Alexa, schalte Überschussladen aus"''<br />
* ''"Alexa, schalte Überschussladen auf 6 (Prozent)"''<br />
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.<br />
define openwb_ueberschuss dummy<br />
attr openwb_ueberschuss alexaName Überschussladen<br />
attr openwb_ueberschuss genericDeviceType light<br />
attr openwb_ueberschuss readingList pct<br />
attr openwb_ueberschuss setList on off pct<br />
define openwb_ueberschuss_on notify openwb_ueberschuss:on set openwb_mqtt publish openWB/set/ChargeMode 2<br />
define openwb_ueberschuss_off notify openwb_ueberschuss:off set openwb_mqtt publish openWB/set/ChargeMode 3<br />
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<br />
<br />
==Anwendungs Beispiele==<br />
===Komplexe Anbindung===<br />
[[Bild:Kia.PNG|mini|700px|rechts|WallBox mit Kia Fahrzeug]]<br />
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.<br />
[[Bild:WB_1.PNG|mini|700px|rechts|openWB mit Statistiken]]<br />
[[Bild:Kostal Flow.PNG|mini|700px|rechts|Sowas könnte am Schluss, inklusive Wechselrichter, raus kommen. Die openWBs sind unten links.]]<br />
====Verwendete Schnittstellen / Devices====<br />
=====openWB MQTT=====<br />
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.<br />
<br />
RAW des MQTT Device<br />
<syntaxhighlight lang="Perl"><br />
defmod WB_1 MQTT2_DEVICE WB_1_MQTT2<br />
attr WB_1 DbLogExclude .*<br />
attr WB_1 DbLogInclude lp_1_.*,.*AllChargePoints.*,ChargeMode<br />
attr WB_1 IODev WB_1_MQTT2<br />
attr WB_1 alias WB_1<br />
attr WB_1 autocreate 0<br />
attr WB_1 comment Die openWB besteht aus zwei Ladepunkten.<br />
attr WB_1 devicetopic openWB<br />
attr WB_1 disable 0<br />
attr WB_1 event-on-change-reading lp_1_.*,.*AllChargePoints.*,ChargeMode<br />
attr WB_1 group PV Eigenverbrauch<br />
attr WB_1 icon fuel<br />
attr WB_1 readingList $DEVICETOPIC/global/WHouseConsumption:.* WHouseConsumption\<br />
$DEVICETOPIC/global/WAllChargePoints:.* WAllChargePoints\<br />
$DEVICETOPIC/global/ChargeMode:.* {my %h=(0=>'SofortLaden',1=>'MinPV',2=>'NurPV',3=>'Stop',4=>'Standby');; return {ChargeMode=>$h{$EVENT}}}\<br />
\<br />
$DEVICETOPIC/global/awattar/boolAwattarEnabled:.* boolAwattarEnabled\<br />
$DEVICETOPIC/global/awattar/ActualPriceForCharging:.* ActualPriceForCharging\<br />
$DEVICETOPIC/global/awattar/MaxPriceForCharging:.* MaxPriceForCharging\<br />
$DEVICETOPIC/global/boolRse:.* boolRse\<br />
$DEVICETOPIC/global/DailyYieldAllChargePointsKwh:.* DailyYieldAllChargePointsKwh\<br />
$DEVICETOPIC/global/rfidConfigured:.* rfidConfigured\<br />
$DEVICETOPIC/global/kWhCounterAllChargePoints:.* kWhCounterAllChargePoints\<br />
$DEVICETOPIC/global/strLastmanagementActive:.* strLastmanagementActive\<br />
$DEVICETOPIC/global/ETProvider/modulePath:.* modulePath\<br />
$DEVICETOPIC/global/cpuTemp:.* cpuTemp\<br />
\<br />
$DEVICETOPIC/system/Uptime:.* Uptime\<br />
$DEVICETOPIC/system/Date:.* Date\<br />
$DEVICETOPIC/system/Timestamp:.* Timestamp\<br />
$DEVICETOPIC/system/Version:.* Version\<br />
$DEVICETOPIC/system/IpAddress:.* IpAddress\<br />
$DEVICETOPIC/system/lastRfId:.* lastRfId\<br />
$DEVICETOPIC/system/updateInProgress:.* updateInProgress\<br />
$DEVICETOPIC/system/ConfiguredChargePoints:.* ConfiguredChargePoints\<br />
$DEVICETOPIC/system/lastlivevalues:.* lastlivevalues\<br />
$DEVICETOPIC/system/randomSleep:.* randomSleep\<br />
$DEVICETOPIC/system/wizzardDone:.* wizzardDone\<br />
$DEVICETOPIC/system/priceForKWh:.* priceForKWh\<br />
$DEVICETOPIC/system/reloadDisplay:.* reloadDisplay\<br />
\<br />
$DEVICETOPIC/evu/ASchieflast:.* ASchieflast\<br />
\<br />
$DEVICETOPIC/lp/1/P%Soc:.* lp_1_Pct_Soc\<br />
$DEVICETOPIC/lp/1/%Soc:.* lp_1_current_Soc\<br />
$DEVICETOPIC/lp/1/\x25Soc:.* lp_1__Soc\<br />
\<br />
$DEVICETOPIC/lp/1/countPhasesInUse:.* lp_1_countPhasesInUse\<br />
$DEVICETOPIC/lp/1/ChargePointEnabled:.* lp_1_ChargePointEnabled\<br />
$DEVICETOPIC/lp/1/ChargeStatus:.* lp_1_ChargeStatus\<br />
\<br />
$DEVICETOPIC/lp/1/kWhDailyCharged:.* lp_1_kWhDailyCharged\<br />
$DEVICETOPIC/lp/1/kWhCounter:.* lp_1_kWhCounter\<br />
$DEVICETOPIC/lp/1/kWhActualCharged:.* lp_1_kWhActualCharged\<br />
$DEVICETOPIC/lp/1/kWhChargedSincePlugged:.* lp_1_kWhChargedSincePlugged\<br />
$DEVICETOPIC/lp/1/energyConsumptionPer100km:.* lp_1_energyConsumptionPer100km\<br />
$DEVICETOPIC/lp/1/kmCharged:.* lp_1_kmCharged\<br />
\<br />
$DEVICETOPIC/lp/1/strChargePointName:.* lp_1_strChargePointName\<br />
$DEVICETOPIC/lp/1/TimeRemaining:.* lp_1_TimeRemaining\<br />
\<br />
$DEVICETOPIC/lp/1/PfPhase2:.* lp_1_PfPhase2\<br />
$DEVICETOPIC/lp/1/PfPhase3:.* lp_1_PfPhase3\<br />
$DEVICETOPIC/lp/1/PfPhase1:.* lp_1_PfPhase1\<br />
$DEVICETOPIC/lp/1/W:.* lp_1_W\<br />
\<br />
$DEVICETOPIC/lp/1/boolPlugStat:.* {my %h=(0=>'no Plug',1=>'Plugged in');; return {lp_1_PlugStat=>$h{$EVENT}}}\<br />
$DEVICETOPIC/lp/1/boolChargeStat:.* {my %h=(0=>'not loading',1=>'loading');; return {lp_1_ChargeStat=>$h{$EVENT}}}\<br />
$DEVICETOPIC/lp/1/AConfigured:.* lp_1_AConfigured\<br />
\<br />
$DEVICETOPIC/lp/1/boolChargePointConfigured:.* lp_1_boolChargePointConfigured\<br />
$DEVICETOPIC/lp/1/boolSocConfigured:.* lp_1_boolSocConfigured\<br />
$DEVICETOPIC/lp/1/boolDirectModeChargekWh:.* lp_1_boolDirectModeChargekWh\<br />
$DEVICETOPIC/lp/1/boolDirectChargeModeSoc:.* lp_1_boolDirectChargeModeSoc\<br />
$DEVICETOPIC/lp/1/boolFinishAtTimeChargeActive:.* lp_1_boolFinishAtTimeChargeActive\<br />
$DEVICETOPIC/lp/1/boolChargeAtNight:.* lp_1_boolChargeAtNight\<br />
$DEVICETOPIC/lp/1/boolSocManual:.* lp_1_boolSocManual\<br />
\<br />
$DEVICETOPIC/lp/1/AutolockStatus:.* lp_1_AutolockStatus\<br />
$DEVICETOPIC/lp/1/AutolockConfigured:.* lp_1_AutolockConfigured\<br />
\<br />
$DEVICETOPIC/lp/1/lastRfId:.* lp_1_lastRfId\<br />
$DEVICETOPIC/lp/1/pluggedladungakt:.* lp_1_pluggedladungakt\<br />
$DEVICETOPIC/lp/1/plugStartkWh:.* lp_1_plugStartkWh\<br />
$DEVICETOPIC/lp/1/MeterSerialNumber:.* lp_1_MeterSerialNumber\<br />
\<br />
\<br />
$DEVICETOPIC/lp/2/P%Soc:.* lp_2_Pct_Soc\<br />
$DEVICETOPIC/lp/2/%Soc:.* lp_2_current_Soc\<br />
$DEVICETOPIC/lp/2/\x25Soc:.* lp_2__Soc\<br />
\<br />
$DEVICETOPIC/lp/2/countPhasesInUse:.* lp_2_countPhasesInUse\<br />
$DEVICETOPIC/lp/2/ChargePointEnabled:.* lp_2_ChargePointEnabled\<br />
$DEVICETOPIC/lp/2/ChargeStatus:.* lp_2_ChargeStatus\<br />
\<br />
$DEVICETOPIC/lp/2/kWhDailyCharged:.* lp_2_kWhDailyCharged\<br />
$DEVICETOPIC/lp/2/kWhCounter:.* lp_2_kWhCounter\<br />
$DEVICETOPIC/lp/2/kWhActualCharged:.* lp_2_kWhActualCharged\<br />
$DEVICETOPIC/lp/2/kWhChargedSincePlugged:.* lp_2_kWhChargedSincePlugged\<br />
$DEVICETOPIC/lp/2/energyConsumptionPer100km:.* lp_2_energyConsumptionPer100km\<br />
$DEVICETOPIC/lp/2/kmCharged:.* lp_2_kmCharged\<br />
\<br />
$DEVICETOPIC/lp/2/strChargePointName:.* lp_2_strChargePointName\<br />
$DEVICETOPIC/lp/2/TimeRemaining:.* lp_2_TimeRemaining\<br />
\<br />
$DEVICETOPIC/lp/2/W:.* lp_2_W\<br />
\<br />
$DEVICETOPIC/lp/2/boolPlugStat:.* {my %h=(0=>'no Plug',1=>'Plugged in');; return {lp_2_PlugStat=>$h{$EVENT}}}\<br />
$DEVICETOPIC/lp/2/boolChargeStat:.* {my %h=(0=>'not loading',1=>'loading');; return {lp_2_ChargeStat=>$h{$EVENT}}}\<br />
$DEVICETOPIC/lp/2/AConfigured:.* lp_2_AConfigured\<br />
\<br />
$DEVICETOPIC/lp/2/boolChargePointConfigured:.* lp_2_boolChargePointConfigured\<br />
$DEVICETOPIC/lp/2/boolSocConfigured:.* lp_2_boolSocConfigured\<br />
$DEVICETOPIC/lp/2/boolDirectModeChargekWh:.* lp_2_boolDirectModeChargekWh\<br />
$DEVICETOPIC/lp/2/boolDirectChargeModeSoc:.* lp_2_boolDirectChargeModeSoc\<br />
$DEVICETOPIC/lp/2/boolFinishAtTimeChargeActive:.* lp_2_boolFinishAtTimeChargeActive\<br />
$DEVICETOPIC/lp/2/boolChargeAtNight:.* lp_2_boolChargeAtNight\<br />
$DEVICETOPIC/lp/2/boolSocManual:.* lp_2_boolSocManual\<br />
\<br />
$DEVICETOPIC/lp/2/AutolockStatus:.* lp_2_AutolockStatus\<br />
$DEVICETOPIC/lp/2/AutolockConfigured:.* lp_2_AutolockConfigured\<br />
\<br />
$DEVICETOPIC/lp/2/lastRfId:.* lp_2_lastRfId\<br />
$DEVICETOPIC/lp/2/pluggedladungakt:.* lp_2_pluggedladungakt\<br />
$DEVICETOPIC/lp/2/plugStartkWh:.* lp_2_plugStartkWh\<br />
$DEVICETOPIC/lp/2/MeterSerialNumber:.* lp_2_MeterSerialNumber\<br />
\<br />
\<br />
$DEVICETOPIC/boolChargeAtNight_direct:.* boolChargeAtNight_direct\<br />
$DEVICETOPIC/boolChargeAtNight_nurpv:.* boolChargeAtNight_nurpv\<br />
$DEVICETOPIC/boolChargeAtNight_minpv:.* boolChargeAtNight_minpv\<br />
$DEVICETOPIC/boolDisplayHouseConsumption:.* boolDisplayHouseConsumption\<br />
$DEVICETOPIC/boolDisplayDailyCharged:.* boolDisplayDailyCharged\<br />
$DEVICETOPIC/boolEvuSmoothedActive:.* boolEvuSmoothedActive\<br />
$DEVICETOPIC/pv/bool70PVDynActive:.* bool70PVDynActive\<br />
$DEVICETOPIC/pv/W70PVDyn:.* W70PVDyn\<br />
$DEVICETOPIC/pv/bool70PVDynStatus:.* bool70PVDynStatus\<br />
$DEVICETOPIC/pv/CounterTillStartPvCharging:.* CounterTillStartPvCharging\<br />
$DEVICETOPIC/pv/W:.* W\<br />
$DEVICETOPIC/config/get/pv/nurpv70dynact:.* nurpv70dynact\<br />
$DEVICETOPIC/config/get/pv/nurpv70dynw:.* nurpv70dynw\<br />
$DEVICETOPIC/config/get/pv/priorityModeEVBattery:.* priorityModeEVBattery\<br />
$DEVICETOPIC/config/get/pv/lp/1/minSocAlwaysToChargeTo:.* lp_1_minSocAlwaysToChargeTo\<br />
$DEVICETOPIC/config/get/pv/lp/1/maxSoc:.* lp_1_maxSoc\<br />
$DEVICETOPIC/config/get/pv/lp/1/minSocAlwaysToChargeToCurrent:.* lp_1_minSocAlwaysToChargeToCurrent\<br />
$DEVICETOPIC/config/get/pv/lp/1/maxSocToChargeTo:.* lp_1_maxSocToChargeTo\<br />
$DEVICETOPIC/config/get/pv/lp/1/minCurrent:.* lp_1_minCurrent\<br />
$DEVICETOPIC/config/get/pv/lp/1/socLimitation:.* lp_1_socLimitation\<br />
$DEVICETOPIC/config/get/pv/lp/2/minCurrent:.* lp_2_minCurrent\<br />
$DEVICETOPIC/config/get/pv/lp/2/maxSoc:.* lp_2_maxSoc\<br />
$DEVICETOPIC/config/get/pv/lp/2/socLimitation:.* lp_2_socLimitation\<br />
$DEVICETOPIC/config/get/pv/socStopChargeAtMinPv:.* socStopChargeAtMinPv\<br />
$DEVICETOPIC/config/get/pv/regulationPoint:.* regulationPoint\<br />
$DEVICETOPIC/config/get/pv/minBatteryDischargeSocAtBattPriority:.* minBatteryDischargeSocAtBattPriority\<br />
$DEVICETOPIC/config/get/pv/minBatteryChargePowerAtEvPriority:.* minBatteryChargePowerAtEvPriority\<br />
$DEVICETOPIC/config/get/pv/minFeedinPowerBeforeStart:.* minFeedinPowerBeforeStart\<br />
$DEVICETOPIC/config/get/pv/boolAdaptiveCharging:.* boolAdaptiveCharging\<br />
$DEVICETOPIC/config/get/pv/adaptiveChargingFactor:.* adaptiveChargingFactor\<br />
$DEVICETOPIC/config/get/pv/batteryDischargePowerAtBattPriority:.* batteryDischargePowerAtBattPriority\<br />
$DEVICETOPIC/config/get/pv/boolShowPriorityIconInTheme:.* boolShowPriorityIconInTheme\<br />
$DEVICETOPIC/config/get/pv/maxPowerConsumptionBeforeStop:.* maxPowerConsumptionBeforeStop\<br />
$DEVICETOPIC/config/get/pv/stopDelay:.* stopDelay\<br />
$DEVICETOPIC/config/get/pv/chargeSubmode:.* chargeSubmode\<br />
$DEVICETOPIC/config/get/pv/minCurrentMinPv:.* minCurrentMinPv\<br />
$DEVICETOPIC/config/get/pv/socStartChargeAtMinPv:.* socStartChargeAtMinPv\<br />
$DEVICETOPIC/config/get/pv/startDelay:.* startDelay\<br />
$DEVICETOPIC/config/get/sofort/lp/2/energyToCharge:.* lp_2_energyToCharge\<br />
$DEVICETOPIC/config/get/sofort/lp/2/chargeLimitation:.* lp_2_chargeLimitation\<br />
$DEVICETOPIC/config/get/sofort/lp/2/socToChargeTo:.* lp_2_socToChargeTo\<br />
$DEVICETOPIC/config/get/sofort/lp/2/current:.* lp_2_current\<br />
\<br />
$DEVICETOPIC/config/get/sofort/lp/1/socToChargeTo:.* lp_1_socToChargeTo\<br />
\<br />
$DEVICETOPIC/config/get/sofort/lp/1/energyToCharge:.* lp_1_energyToCharge\<br />
$DEVICETOPIC/config/get/sofort/lp/1/chargeLimitation:.* lp_1_chargeLimitation\<br />
$DEVICETOPIC/config/get/sofort/lp/1/current:.* lp_1_current\<br />
$DEVICETOPIC/config/get/global/minEVSECurrentAllowed:.* minEVSECurrentAllowed\<br />
$DEVICETOPIC/config/get/global/maxEVSECurrentAllowed:.* maxEVSECurrentAllowed\<br />
$DEVICETOPIC/config/get/global/dataProtectionAcknoledged:.* dataProtectionAcknoledged\<br />
$DEVICETOPIC/config/get/global/slaveMode:.* slaveMode\<br />
$DEVICETOPIC/config/get/u1p3p/standbyPhases:.* standbyPhases\<br />
$DEVICETOPIC/config/get/u1p3p/sofortPhases:.* sofortPhases\<br />
$DEVICETOPIC/config/get/u1p3p/nachtPhases:.* nachtPhases\<br />
$DEVICETOPIC/config/get/u1p3p/minundpvPhases:.* minundpvPhases\<br />
$DEVICETOPIC/config/get/u1p3p/nurpvPhases:.* nurpvPhases\<br />
$DEVICETOPIC/config/get/u1p3p/isConfigured:.* isConfigured\<br />
$DEVICETOPIC/boolChargeAtNight_standby:.* boolChargeAtNight_standby\<br />
$DEVICETOPIC/set/system/reloadDisplay:.* reloadDisplay\<br />
$DEVICETOPIC/set/system/topicSender:.* topicSender\<br />
$DEVICETOPIC/set/lp/2/faultState:.* lp_2_faultState\<br />
$DEVICETOPIC/set/lp/2/faultStr:.* lp_2_faultStr\<br />
$DEVICETOPIC/set/lp/2/ChargePointEnabled:.* lp_2_ChargePointEnabled<br />
attr WB_1 room MQTT2_DEVICE,Strom->Photovoltaik<br />
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}) }\<br />
DirectChargeSubMode:Aus,kWh_Laden,SoC_Laden { my %h=(Aus=>'0',kWh_Laden=>'1',SoC_Laden=>'2');;qq($DEVICETOPIC/set/lp1/DirectChargeSubMode $h{$EVTPART1}) }\<br />
lp_1_socToChargeTo:50,60,70,80,90,100 { qq($DEVICETOPIC/config/set/sofort/lp/1/socToChargeTo $EVTPART1) }<br />
attr WB_1 sortby 311<br />
attr WB_1 stateFormat {\<br />
my $YearBefore='LogDBRep_Statistic_previous_Year';;\<br />
my $DUMMY = "";;\<br />
my $date = POSIX::strftime("%Y-%m-%d",localtime(time_str2num(ReadingsTimestamp($name, "lastlivevalues",0))));;\<br />
\<br />
my $ChargeMode = ReadingsVal($name,"ChargeMode","n/a");;\<br />
$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;;\<br />
\<br />
my $lp_1_Name = ReadingsVal($name,"lp_1_strChargePointName","n/a");;\<br />
my $lp_1_Power = ReadingsVal($name,"lp_1_W",0)." W";;\<br />
my $lp_1_Power_1 = ReadingsVal($name,"lp_1_countPhasesInUse",0)."P ".ReadingsVal($name,"lp_1_AConfigured",0)."A";;\<br />
my $lp_1_Status_1 = ReadingsVal($name,"lp_1_PlugStat","n/a")."<br>".ReadingsVal($name,"lp_1_ChargeStat","n/a");;\<br />
my $lp_1_Status_2 = ReadingsVal($name,"lp_1_TimeRemaining","n/a");;\<br />
\<br />
my $lp_1_Power_d = ReadingsVal($name,"lp_1_kWhDailyCharged",0)." kWh";;\<br />
my $lp_1_Power_m = round(ReadingsVal($name,"lp_1_kWhCounter_Month",0),0)." kWh";;\<br />
my $lp_1_Power_j = sprintf("%04d / %04d",ReadingsVal($name,"lp_1_kWhCounter_Year",0),ReadingsVal($YearBefore,"lp_1_kWhCounter_Year",0));;\<br />
my $lp_1_Power_t = round(ReadingsVal($name,"lp_1_kWhCounter",0),0)." kWh";;\<br />
\<br />
my $lp_2_Name = ReadingsVal($name,"lp_2_strChargePointName","n/a");;\<br />
my $lp_2_Power = ReadingsVal($name,"lp_2_W",0)." W";;\<br />
my $lp_2_Power_1 = ReadingsVal($name,"lp_2_countPhasesInUse",0)."P ".ReadingsVal($name,"lp_2_AConfigured",0)."A";;\<br />
my $lp_2_Status_1 = ReadingsVal($name,"lp_2_PlugStat","n/a")."<br>".ReadingsVal($name,"lp_2_ChargeStat","n/a");;\<br />
my $lp_2_Status_2 = "<br>".ReadingsVal($name,"lp_2_TimeRemaining","n/a");;\<br />
\<br />
my $lp_2_Power_d = ReadingsVal($name,"lp_2_kWhDailyCharged",0)." kWh";;\<br />
my $lp_2_Power_m = round(ReadingsVal($name,"lp_2_kWhCounter_Month",0),0)." kWh";;\<br />
my $lp_2_Power_j = sprintf("%04d / %04d",ReadingsVal($name,"lp_2_kWhCounter_Year",0),ReadingsVal($YearBefore,"lp_2_kWhCounter_Year",0));;\<br />
my $lp_2_Power_t = round(ReadingsVal($name,"lp_2_kWhCounter",0),0)." kWh";;\<br />
\<br />
"<html><table border=2 bordercolor='darkgreen' cellspacing=0 style='width: 100%'>\<br />
<colgroup>\<br />
<col span='1' style='width: 52%;;'>\<br />
<col span='1' style='width: 12%;;'>\<br />
<col span='1' style='width: 12%;;'>\<br />
<col span='1' style='width: 12%;;'>\<br />
<col span='1' style='width: 12%;;'>\<br />
</colgroup>\<br />
<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>\<br />
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>&nbsp;;&nbsp;;".$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>\<br />
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>&nbsp;;&nbsp;;".$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>\<br />
<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>\<br />
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>&nbsp;;&nbsp;;".$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>\<br />
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>&nbsp;;&nbsp;;".$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>\<br />
</table>\<br />
</html>"\<br />
}<br />
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) },\<br />
lp_1_kWhCounter_Year:lp_1_kWhCounter.* { round(ReadingsVal("$NAME","lp_1_kWhCounter",0) - ReadingsVal("$NAME","lp_1_kWhCounter_init_Year",0),0) },\<br />
\<br />
lp_2_kWhCounter_Month:lp_2_kWhCounter.* { round(ReadingsVal("$NAME","lp_2_kWhCounter",0) - ReadingsVal("$NAME","lp_2_kWhCounter_init_Month",0),0) },\<br />
lp_2_kWhCounter_Year:lp_2_kWhCounter.* { round(ReadingsVal("$NAME","lp_2_kWhCounter",0) - ReadingsVal("$NAME","lp_2_kWhCounter_init_Year",0),0) }<br />
</syntaxhighlight><br />
<br />
=====Kia connect MQTT=====<br />
Das Kia_connect Device empfängt und sendet die MQTT Nachrichten zum Node-red Flow für das Kia BEV.<br />
<br />
RAW des Kia connect<br />
<syntaxhighlight lang="Perl"><br />
defmod Kia_connect MQTT2_DEVICE<br />
attr Kia_connect DbLogExclude .*<br />
attr Kia_connect DbLogInclude .*<br />
attr Kia_connect IODev MQTT2_FHEM_Server<br />
attr Kia_connect alias Kia_connect<br />
attr Kia_connect autocreate 1<br />
attr Kia_connect devicetopic bluelinky<br />
attr Kia_connect group PV Eigenverbrauch-Steuerung<br />
attr Kia_connect icon car<br />
attr Kia_connect readingList $DEVICETOPIC/status:.* { json2nameValue($EVENT) }\<br />
$DEVICETOPIC/location.* { json2nameValue($EVENT) }\<br />
$DEVICETOPIC/odometer:.* { json2nameValue($EVENT) }\<br />
$DEVICETOPIC/req_received:.* req_received\<br />
$DEVICETOPIC/req_active:.* req_active<br />
attr Kia_connect room MQTT2_DEVICE,Strom->Photovoltaik<br />
attr Kia_connect setList getOdometer req/$DEVICETOPIC/get_odometer get_odometer\<br />
getStatus req/$DEVICETOPIC/get_status get_status\<br />
getLocation req/$DEVICETOPIC/get_location get_location\<br />
getTripinfo req/$DEVICETOPIC/get_tripinfo\<br />
getAll req/$DEVICETOPIC/get_all get_all\<br />
setChargeTargetSoc req/$DEVICETOPIC/set_chargetargets\<br />
startCharge req/$DEVICETOPIC/start_charging start_charging\<br />
stopCharge req/$DEVICETOPIC/stop_charging stop_charging\<br />
stopClimate req/$DEVICETOPIC/stop_climate stop_climate\<br />
startClimate req/$DEVICETOPIC/start_climate<br />
attr Kia_connect sortby 402<br />
attr Kia_connect stateFormat req_active<br />
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';;;; },\<br />
batSOC:status.* { ReadingsVal($NAME,"status_evStatus_batteryStatus",0);;;;},\<br />
connected:status.* { (ReadingsVal($NAME,"status_evStatus_batteryPlugin",0) != 0) ? 'true' : 'false';;;;},\<br />
charging:status.* { ReadingsVal($NAME,"status_evStatus_batteryCharge",'false');;;;},\<br />
targetSOC:status.* { ReadingsVal($NAME,"status_evStatus_reservChargeInfos_targetSOClist_2_targetSOClevel",0);;;;},\<br />
time2targetSOC:status.* { my $t = ReadingsVal($NAME,"status_evStatus_remainTime2_atc_value",1);;;; sprintf("%02d:%02d", $t/60%60, $t%60);;},\<br />
range:status.* { ReadingsVal($NAME,"status_evStatus_drvDistance_1_rangeByFuel_totalAvailableRange_value",0);;;;},\<br />
bat12v:status.* { ReadingsVal($NAME,"status_battery_batSoc",0);;;;}<br />
</syntaxhighlight><br />
<br />
=====Node-red=====<br />
[[Bild:Kia Flow.PNG|mini|900px|rechts|Node-red Kia Flow]]<br />
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.<br />
<br />
docker-compose .yml Eintrag<br />
<syntaxhighlight lang="Perl"><br />
node-red:<br />
image: nodered/node-red:latest<br />
restart: always<br />
environment:<br />
- TZ=Europe/Berlin<br />
ports:<br />
- 1880:1880<br />
volumes:<br />
- ./node-red/data:/data<br />
</syntaxhighlight><br />
<br />
Danach fehlt im Container noch folgende Erweiterung für den Node-red Flow<br />
<syntaxhighlight lang="Perl"><br />
npm install node-red-contrib-bluelinky<br />
</syntaxhighlight><br />
<br />
=====Kia Connect=====<br />
<pre><br />
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.<br />
Mit Node-red und BlueLinky wird die Schnittstelle bedient.<br />
Der Flow ist nicht ursprünglich von mir, wurde jedoch noch erweitert.<br />
Vor dem Laden des Flows sind noch die persönlichen Verbindungsdaten im JSON einzutragen.<br />
<br />
Nach dem Laden ist ein Test mit den Inject Symbolen und der Debug Funktionalität möglich und auch sinnvoll.<br />
Unterhalb der MQTT - und BlueLinky Symbole sollte "Verbunden" oder "Ready" erscheinen.<br />
</pre><br />
'''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.<br />
<br />
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.<br />
<br />
Node-red JSON Import<br />
<syntaxhighlight lang="json"><br />
[ {<br />
"id": "866c75dd.edd9a8",<br />
"type": "tab",<br />
"label": "Kia e-Niro",<br />
"disabled": false,<br />
"info": ""<br />
},<br />
{<br />
"id": "bb13a99d.68b8f8",<br />
"type": "mqtt-broker",<br />
"name": "mqtt_Server",<br />
"broker": "<FHEM MQTT IP Adresse>",<br />
"port": "1883",<br />
"clientid": "",<br />
"autoConnect": true,<br />
"usetls": false,<br />
"compatmode": false,<br />
"protocolVersion": "4",<br />
"keepalive": "60",<br />
"cleansession": true,<br />
"birthTopic": "",<br />
"birthQos": "0",<br />
"birthPayload": "",<br />
"birthMsg": {},<br />
"closeTopic": "",<br />
"closeQos": "0",<br />
"closePayload": "",<br />
"closeMsg": {},<br />
"willTopic": "",<br />
"willQos": "0",<br />
"willPayload": "",<br />
"willMsg": {},<br />
"sessionExpiry": ""<br />
},<br />
{<br />
"id": "452a3304.58c8fc",<br />
"type": "bluelinky",<br />
"username": "<Mail Adresse bei Kia>",<br />
"password": "<Passwort>",<br />
"region": "EU",<br />
"pin": "<Pin>",<br />
"vin": "<VIN>",<br />
"brand": "kia"<br />
},<br />
{<br />
"id": "91a345fa.5757a8",<br />
"type": "mqtt in",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "req/bluelinky/get_status",<br />
"qos": "0",<br />
"datatype": "auto",<br />
"broker": "bb13a99d.68b8f8",<br />
"inputs": 0,<br />
"x": 260,<br />
"y": 280,<br />
"wires": [<br />
[<br />
"15dfb508.c6497b",<br />
"ce62ba4f.d86548",<br />
"3f82a275.5a0b6e",<br />
"24d5e0b.3aafc2"<br />
]<br />
]<br />
},<br />
{<br />
"id": "5ad085b9.05739c",<br />
"type": "mqtt in",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "req/bluelinky/start_climate",<br />
"qos": "0",<br />
"datatype": "auto",<br />
"broker": "bb13a99d.68b8f8",<br />
"nl": false,<br />
"rap": false,<br />
"inputs": 0,<br />
"x": 270,<br />
"y": 680,<br />
"wires": [<br />
[<br />
"b27d74de.38c808",<br />
"33b1bc85.662694",<br />
"ce62ba4f.d86548",<br />
"24d5e0b.3aafc2"<br />
]<br />
]<br />
},<br />
{<br />
"id": "15dfb508.c6497b",<br />
"type": "car-status",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Get status",<br />
"dorefresh": true,<br />
"parsed": false,<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1110,<br />
"y": 280,<br />
"wires": [<br />
[<br />
"cccc9476.d56dd8",<br />
"226ed925.607bb6"<br />
]<br />
]<br />
},<br />
{<br />
"id": "87abdd88.8ff4d",<br />
"type": "car-odometer",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Get car odometer",<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1130,<br />
"y": 200,<br />
"wires": [<br />
[<br />
"40d2361c.579588",<br />
"226ed925.607bb6"<br />
]<br />
]<br />
},<br />
{<br />
"id": "31100f9a.40008",<br />
"type": "function",<br />
"z": "866c75dd.edd9a8",<br />
"name": "locationWrapper",<br />
"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}",<br />
"outputs": 1,<br />
"noerr": 0,<br />
"initialize": "",<br />
"finalize": "",<br />
"libs": [],<br />
"x": 1490,<br />
"y": 120,<br />
"wires": [<br />
[<br />
"85a07155.a0f9f",<br />
"262df5dc.57916a",<br />
"f487d6d6.a4d568"<br />
]<br />
]<br />
},<br />
{<br />
"id": "bea1d927.0f3908",<br />
"type": "car-location",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Get car location",<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1120,<br />
"y": 120,<br />
"wires": [<br />
[<br />
"31100f9a.40008",<br />
"226ed925.607bb6"<br />
]<br />
]<br />
},<br />
{<br />
"id": "3c949d67.0d83b2",<br />
"type": "mqtt in",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "req/bluelinky/get_location",<br />
"qos": "0",<br />
"datatype": "auto",<br />
"broker": "bb13a99d.68b8f8",<br />
"nl": false,<br />
"rap": false,<br />
"inputs": 0,<br />
"x": 270,<br />
"y": 120,<br />
"wires": [<br />
[<br />
"bea1d927.0f3908",<br />
"ce62ba4f.d86548",<br />
"3f82a275.5a0b6e",<br />
"24d5e0b.3aafc2"<br />
]<br />
]<br />
},<br />
{<br />
"id": "cccc9476.d56dd8",<br />
"type": "function",<br />
"z": "866c75dd.edd9a8",<br />
"name": "analyseStatus",<br />
"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}",<br />
"outputs": 1,<br />
"noerr": 0,<br />
"initialize": "",<br />
"finalize": "",<br />
"x": 1480,<br />
"y": 280,<br />
"wires": [<br />
[<br />
"3efceea0.c81b12",<br />
"262df5dc.57916a",<br />
"f487d6d6.a4d568"<br />
]<br />
]<br />
},<br />
{<br />
"id": "85a07155.a0f9f",<br />
"type": "mqtt out",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "bluelinky/location",<br />
"qos": "",<br />
"retain": "",<br />
"broker": "bb13a99d.68b8f8",<br />
"x": 1910,<br />
"y": 120,<br />
"wires": []<br />
},<br />
{<br />
"id": "3efceea0.c81b12",<br />
"type": "mqtt out",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "bluelinky/status",<br />
"qos": "",<br />
"retain": "",<br />
"broker": "bb13a99d.68b8f8",<br />
"x": 1900,<br />
"y": 280,<br />
"wires": []<br />
},<br />
{<br />
"id": "327104fc.71e1bc",<br />
"type": "mqtt out",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "bluelinky/odometer",<br />
"qos": "",<br />
"retain": "",<br />
"broker": "bb13a99d.68b8f8",<br />
"x": 1910,<br />
"y": 200,<br />
"wires": []<br />
},<br />
{<br />
"id": "844a32f4.2e029",<br />
"type": "mqtt in",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "req/bluelinky/stop_climate",<br />
"qos": "0",<br />
"datatype": "auto",<br />
"broker": "bb13a99d.68b8f8",<br />
"inputs": 0,<br />
"x": 270,<br />
"y": 760,<br />
"wires": [<br />
[<br />
"7d3ae860.d8c9a8",<br />
"33b1bc85.662694",<br />
"ce62ba4f.d86548",<br />
"24d5e0b.3aafc2"<br />
]<br />
]<br />
},<br />
{<br />
"id": "57d91e50.7e96",<br />
"type": "mqtt in",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "req/bluelinky/start_charging",<br />
"qos": "0",<br />
"datatype": "auto",<br />
"broker": "bb13a99d.68b8f8",<br />
"inputs": 0,<br />
"x": 280,<br />
"y": 820,<br />
"wires": [<br />
[<br />
"6eebc52c.ee23dc",<br />
"33b1bc85.662694",<br />
"ce62ba4f.d86548",<br />
"24d5e0b.3aafc2"<br />
]<br />
]<br />
},<br />
{<br />
"id": "6029f0a0.b73e",<br />
"type": "mqtt in",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "req/bluelinky/stop_charging",<br />
"qos": "0",<br />
"datatype": "auto",<br />
"broker": "bb13a99d.68b8f8",<br />
"nl": false,<br />
"rap": false,<br />
"inputs": 0,<br />
"x": 280,<br />
"y": 880,<br />
"wires": [<br />
[<br />
"84a1ae.74912e5",<br />
"33b1bc85.662694",<br />
"ce62ba4f.d86548",<br />
"24d5e0b.3aafc2"<br />
]<br />
]<br />
},<br />
{<br />
"id": "c5ecf76c.e753c8",<br />
"type": "start-car",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Start car",<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1100,<br />
"y": 680,<br />
"wires": [<br />
[<br />
"811aa567.e89f98",<br />
"f487d6d6.a4d568"<br />
]<br />
]<br />
},<br />
{<br />
"id": "6eebc52c.ee23dc",<br />
"type": "start-charge",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Start Charging",<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1120,<br />
"y": 820,<br />
"wires": [<br />
[<br />
"811aa567.e89f98",<br />
"f487d6d6.a4d568"<br />
]<br />
]<br />
},<br />
{<br />
"id": "84a1ae.74912e5",<br />
"type": "stop-charge",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Stop Charging",<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1120,<br />
"y": 880,<br />
"wires": [<br />
[<br />
"811aa567.e89f98",<br />
"f487d6d6.a4d568"<br />
]<br />
]<br />
},<br />
{<br />
"id": "7d3ae860.d8c9a8",<br />
"type": "stop-car",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Stop car",<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1100,<br />
"y": 760,<br />
"wires": [<br />
[<br />
"811aa567.e89f98",<br />
"f487d6d6.a4d568"<br />
]<br />
]<br />
},<br />
{<br />
"id": "b27d74de.38c808",<br />
"type": "json",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"property": "payload",<br />
"action": "obj",<br />
"pretty": false,<br />
"x": 750,<br />
"y": 680,<br />
"wires": [<br />
[<br />
"c5ecf76c.e753c8",<br />
"33b1bc85.662694"<br />
]<br />
]<br />
},<br />
{<br />
"id": "45a6a8e6.2abfd8",<br />
"type": "mqtt in",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "req/bluelinky/get_odometer",<br />
"qos": "0",<br />
"datatype": "auto",<br />
"broker": "bb13a99d.68b8f8",<br />
"inputs": 0,<br />
"x": 280,<br />
"y": 200,<br />
"wires": [<br />
[<br />
"87abdd88.8ff4d",<br />
"ce62ba4f.d86548",<br />
"3f82a275.5a0b6e",<br />
"24d5e0b.3aafc2"<br />
]<br />
]<br />
},<br />
{<br />
"id": "33b1bc85.662694",<br />
"type": "debug",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"active": false,<br />
"tosidebar": true,<br />
"console": false,<br />
"tostatus": false,<br />
"complete": "payload",<br />
"targetType": "msg",<br />
"statusVal": "",<br />
"statusType": "auto",<br />
"x": 930,<br />
"y": 920,<br />
"wires": []<br />
},<br />
{<br />
"id": "ce62ba4f.d86548",<br />
"type": "mqtt out",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "bluelinky/req_received",<br />
"qos": "",<br />
"retain": "",<br />
"broker": "bb13a99d.68b8f8",<br />
"x": 860,<br />
"y": 480,<br />
"wires": []<br />
},<br />
{<br />
"id": "1babee6c.1c2982",<br />
"type": "mqtt in",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "req/bluelinky/get_all",<br />
"qos": "0",<br />
"datatype": "auto",<br />
"broker": "bb13a99d.68b8f8",<br />
"inputs": 0,<br />
"x": 250,<br />
"y": 360,<br />
"wires": [<br />
[<br />
"ce62ba4f.d86548",<br />
"3f82a275.5a0b6e",<br />
"24d5e0b.3aafc2",<br />
"4375fbb9.00fb44"<br />
]<br />
]<br />
},<br />
{<br />
"id": "262df5dc.57916a",<br />
"type": "debug",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"active": false,<br />
"tosidebar": true,<br />
"console": false,<br />
"tostatus": false,<br />
"complete": "payload",<br />
"targetType": "msg",<br />
"statusVal": "",<br />
"statusType": "auto",<br />
"x": 1850,<br />
"y": 80,<br />
"wires": []<br />
},<br />
{<br />
"id": "811aa567.e89f98",<br />
"type": "debug",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"active": false,<br />
"tosidebar": true,<br />
"console": false,<br />
"tostatus": false,<br />
"complete": "payload",<br />
"targetType": "msg",<br />
"statusVal": "",<br />
"statusType": "auto",<br />
"x": 1470,<br />
"y": 1040,<br />
"wires": []<br />
},<br />
{<br />
"id": "3f82a275.5a0b6e",<br />
"type": "debug",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"active": false,<br />
"tosidebar": true,<br />
"console": false,<br />
"tostatus": false,<br />
"complete": "payload",<br />
"targetType": "msg",<br />
"statusVal": "",<br />
"statusType": "auto",<br />
"x": 930,<br />
"y": 80,<br />
"wires": []<br />
},<br />
{<br />
"id": "24d5e0b.3aafc2",<br />
"type": "change",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"rules": [<br />
{<br />
"t": "set",<br />
"p": "payload",<br />
"pt": "msg",<br />
"to": "pending",<br />
"tot": "str"<br />
}<br />
],<br />
"action": "",<br />
"property": "",<br />
"from": "",<br />
"to": "",<br />
"reg": false,<br />
"x": 790,<br />
"y": 1140,<br />
"wires": [<br />
[<br />
"4dd1ea4a.52f144",<br />
"fecad185.324f8"<br />
]<br />
]<br />
},<br />
{<br />
"id": "f487d6d6.a4d568",<br />
"type": "change",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"rules": [<br />
{<br />
"t": "set",<br />
"p": "payload",<br />
"pt": "msg",<br />
"to": "idle",<br />
"tot": "str"<br />
}<br />
],<br />
"action": "",<br />
"property": "",<br />
"from": "",<br />
"to": "",<br />
"reg": false,<br />
"x": 1910,<br />
"y": 760,<br />
"wires": [<br />
[<br />
"4dd1ea4a.52f144",<br />
"fecad185.324f8"<br />
]<br />
]<br />
},<br />
{<br />
"id": "4dd1ea4a.52f144",<br />
"type": "mqtt out",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "bluelinky/req_active",<br />
"qos": "",<br />
"retain": "",<br />
"broker": "bb13a99d.68b8f8",<br />
"x": 2140,<br />
"y": 1100,<br />
"wires": []<br />
},<br />
{<br />
"id": "fecad185.324f8",<br />
"type": "debug",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"active": false,<br />
"tosidebar": true,<br />
"console": false,<br />
"tostatus": false,<br />
"complete": "false",<br />
"statusVal": "",<br />
"statusType": "auto",<br />
"x": 2110,<br />
"y": 1160,<br />
"wires": []<br />
},<br />
{<br />
"id": "40d2361c.579588",<br />
"type": "function",<br />
"z": "866c75dd.edd9a8",<br />
"name": "odometerWrapper",<br />
"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}",<br />
"outputs": 1,<br />
"noerr": 0,<br />
"initialize": "",<br />
"finalize": "",<br />
"libs": [],<br />
"x": 1490,<br />
"y": 200,<br />
"wires": [<br />
[<br />
"327104fc.71e1bc",<br />
"262df5dc.57916a",<br />
"f487d6d6.a4d568"<br />
]<br />
]<br />
},<br />
{<br />
"id": "226ed925.607bb6",<br />
"type": "debug",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"active": true,<br />
"tosidebar": true,<br />
"console": false,<br />
"tostatus": false,<br />
"complete": "payload",<br />
"targetType": "msg",<br />
"statusVal": "",<br />
"statusType": "auto",<br />
"x": 1430,<br />
"y": 80,<br />
"wires": []<br />
},<br />
{<br />
"id": "4375fbb9.00fb44",<br />
"type": "car-fullstatus",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Get full status",<br />
"dorefresh": true,<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1120,<br />
"y": 360,<br />
"wires": [<br />
[<br />
"226ed925.607bb6",<br />
"69b6c4df.ea6bcc",<br />
"89681a97.9e24d8",<br />
"92dc3ff4.1d6e3"<br />
]<br />
]<br />
},<br />
{<br />
"id": "69b6c4df.ea6bcc",<br />
"type": "function",<br />
"z": "866c75dd.edd9a8",<br />
"name": "locationFromFullstatus",<br />
"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",<br />
"outputs": 1,<br />
"noerr": 0,<br />
"initialize": "",<br />
"finalize": "",<br />
"x": 1500,<br />
"y": 360,<br />
"wires": [<br />
[<br />
"85a07155.a0f9f",<br />
"331e5860.907808"<br />
]<br />
]<br />
},<br />
{<br />
"id": "92dc3ff4.1d6e3",<br />
"type": "function",<br />
"z": "866c75dd.edd9a8",<br />
"name": "statusFromFullstatus",<br />
"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",<br />
"outputs": 1,<br />
"noerr": 0,<br />
"initialize": "",<br />
"finalize": "",<br />
"x": 1500,<br />
"y": 480,<br />
"wires": [<br />
[<br />
"3efceea0.c81b12",<br />
"f487d6d6.a4d568",<br />
"331e5860.907808"<br />
]<br />
]<br />
},<br />
{<br />
"id": "89681a97.9e24d8",<br />
"type": "function",<br />
"z": "866c75dd.edd9a8",<br />
"name": "odometerFromFullstatus",<br />
"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",<br />
"outputs": 1,<br />
"noerr": 0,<br />
"initialize": "",<br />
"finalize": "",<br />
"x": 1510,<br />
"y": 420,<br />
"wires": [<br />
[<br />
"327104fc.71e1bc",<br />
"331e5860.907808"<br />
]<br />
]<br />
},<br />
{<br />
"id": "331e5860.907808",<br />
"type": "debug",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"active": true,<br />
"tosidebar": true,<br />
"console": false,<br />
"tostatus": false,<br />
"complete": "payload",<br />
"targetType": "msg",<br />
"statusVal": "",<br />
"statusType": "auto",<br />
"x": 1850,<br />
"y": 520,<br />
"wires": []<br />
},<br />
{<br />
"id": "aa4d220b.f7e19",<br />
"type": "set-chargetargets",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Set charge targets",<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1130,<br />
"y": 960,<br />
"wires": [<br />
[<br />
"811aa567.e89f98",<br />
"f487d6d6.a4d568"<br />
]<br />
]<br />
},<br />
{<br />
"id": "4c03338d.2f15ec",<br />
"type": "login",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Login",<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1090,<br />
"y": 1040,<br />
"wires": [<br />
[<br />
"811aa567.e89f98"<br />
]<br />
]<br />
},<br />
{<br />
"id": "28b868f5.16cb48",<br />
"type": "inject",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"props": [<br />
{<br />
"p": "payload"<br />
},<br />
{<br />
"p": "topic",<br />
"vt": "str"<br />
}<br />
],<br />
"repeat": "43200",<br />
"crontab": "",<br />
"once": true,<br />
"onceDelay": "12",<br />
"topic": "",<br />
"payloadType": "date",<br />
"x": 950,<br />
"y": 1040,<br />
"wires": [<br />
[<br />
"4c03338d.2f15ec"<br />
]<br />
]<br />
},<br />
{<br />
"id": "db9ecdb5.a9683",<br />
"type": "mqtt in",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "req/bluelinky/set_chargetargets",<br />
"qos": "0",<br />
"datatype": "auto",<br />
"broker": "bb13a99d.68b8f8",<br />
"nl": false,<br />
"rap": false,<br />
"inputs": 0,<br />
"x": 290,<br />
"y": 960,<br />
"wires": [<br />
[<br />
"7064a8d53256b646",<br />
"ce62ba4f.d86548",<br />
"24d5e0b.3aafc2"<br />
]<br />
]<br />
},<br />
{<br />
"id": "44155ad70c47b0dd",<br />
"type": "inject",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"props": [<br />
{<br />
"p": "payload"<br />
},<br />
{<br />
"p": "topic",<br />
"vt": "str"<br />
}<br />
],<br />
"repeat": "",<br />
"crontab": "",<br />
"once": false,<br />
"onceDelay": 0.1,<br />
"topic": "",<br />
"payload": "",<br />
"payloadType": "date",<br />
"x": 940,<br />
"y": 260,<br />
"wires": [<br />
[<br />
"15dfb508.c6497b"<br />
]<br />
]<br />
},<br />
{<br />
"id": "7064a8d53256b646",<br />
"type": "json",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"property": "payload",<br />
"action": "obj",<br />
"pretty": false,<br />
"x": 750,<br />
"y": 960,<br />
"wires": [<br />
[<br />
"33b1bc85.662694",<br />
"aa4d220b.f7e19"<br />
]<br />
]<br />
},<br />
{<br />
"id": "7064395e56292844",<br />
"type": "inject",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"props": [<br />
{<br />
"p": "payload"<br />
},<br />
{<br />
"p": "topic",<br />
"vt": "str"<br />
}<br />
],<br />
"repeat": "",<br />
"crontab": "",<br />
"once": false,<br />
"onceDelay": 0.1,<br />
"topic": "",<br />
"payload": "",<br />
"payloadType": "date",<br />
"x": 940,<br />
"y": 340,<br />
"wires": [<br />
[<br />
"4375fbb9.00fb44"<br />
]<br />
]<br />
},<br />
{<br />
"id": "5f9ff828080f5fe6",<br />
"type": "lock-car",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Lock car",<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1100,<br />
"y": 560,<br />
"wires": [<br />
[<br />
"811aa567.e89f98",<br />
"f487d6d6.a4d568"<br />
]<br />
]<br />
},<br />
{<br />
"id": "492f5b94a865e47b",<br />
"type": "inject",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"props": [<br />
{<br />
"p": "payload"<br />
},<br />
{<br />
"p": "topic",<br />
"vt": "str"<br />
}<br />
],<br />
"repeat": "",<br />
"crontab": "",<br />
"once": false,<br />
"onceDelay": 0.1,<br />
"topic": "",<br />
"payload": "",<br />
"payloadType": "date",<br />
"x": 940,<br />
"y": 540,<br />
"wires": [<br />
[<br />
"5f9ff828080f5fe6"<br />
]<br />
]<br />
},<br />
{<br />
"id": "d6f3f148e765caf9",<br />
"type": "mqtt in",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "req/bluelinky/car_lock",<br />
"qos": "0",<br />
"datatype": "auto",<br />
"broker": "bb13a99d.68b8f8",<br />
"nl": false,<br />
"rap": false,<br />
"inputs": 0,<br />
"x": 260,<br />
"y": 560,<br />
"wires": [<br />
[<br />
"5f9ff828080f5fe6",<br />
"ce62ba4f.d86548"<br />
]<br />
]<br />
},<br />
{<br />
"id": "cdc13a486db22b8e",<br />
"type": "mqtt in",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "req/bluelinky/car_unlock",<br />
"qos": "0",<br />
"datatype": "auto",<br />
"broker": "bb13a99d.68b8f8",<br />
"nl": false,<br />
"rap": false,<br />
"inputs": 0,<br />
"x": 270,<br />
"y": 620,<br />
"wires": [<br />
[<br />
"99f5c3a41ac3e754",<br />
"ce62ba4f.d86548"<br />
]<br />
]<br />
},<br />
{<br />
"id": "99f5c3a41ac3e754",<br />
"type": "unlock-car",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Unlock car",<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1110,<br />
"y": 620,<br />
"wires": [<br />
[<br />
"f487d6d6.a4d568",<br />
"811aa567.e89f98"<br />
]<br />
]<br />
},<br />
{<br />
"id": "ab557a0ea621403a",<br />
"type": "inject",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"props": [<br />
{<br />
"p": "payload"<br />
},<br />
{<br />
"p": "topic",<br />
"vt": "str"<br />
}<br />
],<br />
"repeat": "",<br />
"crontab": "",<br />
"once": false,<br />
"onceDelay": 0.1,<br />
"topic": "",<br />
"payload": "",<br />
"payloadType": "date",<br />
"x": 940,<br />
"y": 600,<br />
"wires": [<br />
[<br />
"99f5c3a41ac3e754"<br />
]<br />
]<br />
},<br />
{<br />
"id": "a525de86e4374518",<br />
"type": "inject",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"props": [<br />
{<br />
"p": "payload"<br />
},<br />
{<br />
"p": "topic",<br />
"vt": "str"<br />
}<br />
],<br />
"repeat": "",<br />
"crontab": "",<br />
"once": false,<br />
"onceDelay": 0.1,<br />
"topic": "",<br />
"payload": "",<br />
"payloadType": "date",<br />
"x": 940,<br />
"y": 740,<br />
"wires": [<br />
[<br />
"7d3ae860.d8c9a8"<br />
]<br />
]<br />
},<br />
{<br />
"id": "0b8cb92c042fe140",<br />
"type": "inject",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"props": [<br />
{<br />
"p": "payload"<br />
},<br />
{<br />
"p": "topic",<br />
"vt": "str"<br />
}<br />
],<br />
"repeat": "",<br />
"crontab": "",<br />
"once": false,<br />
"onceDelay": 0.1,<br />
"topic": "",<br />
"payload": "",<br />
"payloadType": "date",<br />
"x": 940,<br />
"y": 800,<br />
"wires": [<br />
[<br />
"6eebc52c.ee23dc"<br />
]<br />
]<br />
},<br />
{<br />
"id": "ae4c2139b08aaa28",<br />
"type": "inject",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"props": [<br />
{<br />
"p": "payload"<br />
},<br />
{<br />
"p": "topic",<br />
"vt": "str"<br />
}<br />
],<br />
"repeat": "",<br />
"crontab": "",<br />
"once": false,<br />
"onceDelay": 0.1,<br />
"topic": "",<br />
"payload": "",<br />
"payloadType": "date",<br />
"x": 940,<br />
"y": 860,<br />
"wires": [<br />
[<br />
"84a1ae.74912e5"<br />
]<br />
]<br />
},<br />
{<br />
"id": "dd23108ce63f456d",<br />
"type": "get-monthlyreport",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Get monthly report",<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1130,<br />
"y": 1280,<br />
"wires": [<br />
[<br />
"e57eb97531129426"<br />
]<br />
]<br />
},<br />
{<br />
"id": "a6e5e8deb52145f1",<br />
"type": "inject",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"props": [<br />
{<br />
"p": "payload"<br />
},<br />
{<br />
"p": "topic",<br />
"vt": "str"<br />
}<br />
],<br />
"repeat": "",<br />
"crontab": "",<br />
"once": false,<br />
"onceDelay": 0.1,<br />
"topic": "",<br />
"payload": "",<br />
"payloadType": "date",<br />
"x": 940,<br />
"y": 1260,<br />
"wires": [<br />
[<br />
"dd23108ce63f456d"<br />
]<br />
]<br />
},<br />
{<br />
"id": "95f1b6f32aafd65b",<br />
"type": "get-tripinfo",<br />
"z": "866c75dd.edd9a8",<br />
"name": "Tripinfo",<br />
"bluelinky": "452a3304.58c8fc",<br />
"x": 1100,<br />
"y": 1220,<br />
"wires": [<br />
[<br />
"e57eb97531129426"<br />
]<br />
]<br />
},<br />
{<br />
"id": "fb2b99958bc48593",<br />
"type": "json",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"property": "payload",<br />
"action": "",<br />
"pretty": false,<br />
"x": 750,<br />
"y": 1220,<br />
"wires": [<br />
[<br />
"95f1b6f32aafd65b"<br />
]<br />
]<br />
},<br />
{<br />
"id": "5230ebe391325b17",<br />
"type": "mqtt in",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "req/bluelinky/get_tripinfo",<br />
"qos": "2",<br />
"datatype": "auto",<br />
"broker": "bb13a99d.68b8f8",<br />
"nl": false,<br />
"rap": true,<br />
"rh": 0,<br />
"inputs": 0,<br />
"x": 270,<br />
"y": 1220,<br />
"wires": [<br />
[<br />
"fb2b99958bc48593"<br />
]<br />
]<br />
},<br />
{<br />
"id": "e57eb97531129426",<br />
"type": "debug",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"active": false,<br />
"tosidebar": true,<br />
"console": false,<br />
"tostatus": false,<br />
"complete": "payload",<br />
"targetType": "msg",<br />
"statusVal": "",<br />
"statusType": "auto",<br />
"x": 1470,<br />
"y": 1220,<br />
"wires": []<br />
},<br />
{<br />
"id": "4fdf3b1b7811c89f",<br />
"type": "mqtt in",<br />
"z": "866c75dd.edd9a8",<br />
"name": "",<br />
"topic": "req/bluelinky/get_tripinfo",<br />
"qos": "2",<br />
"datatype": "auto",<br />
"broker": "bb13a99d.68b8f8",<br />
"nl": false,<br />
"rap": true,<br />
"rh": 0,<br />
"inputs": 0,<br />
"x": 270,<br />
"y": 1280,<br />
"wires": [<br />
[<br />
"dd23108ce63f456d"<br />
]<br />
]<br />
}<br />
]<br />
</syntaxhighlight><br />
<br />
=====Kia_eNiro_PV DOIF mit uiTable=====<br />
Mit diesem DOIF Device werden folgende Funktionalitäten abgebildet:<br />
Nun dann noch das DOIF mit dem uiTable für die Status Anzeige und die Steuerung über Pull Down Menüs.<br />
<br />
- Status Abfrage<br />
Status jede Stunde zwischen 6 und 23 Uhr (12V min 40%)<br />
Status beim Laden alle 15 Minuten (12V min 40%)<br />
Anzeige des Kilometerzählers<br />
Status des Fahrzeuges zu Hause / unterwegs und beim Laden<br />
Fahrzeug Auf/Zu<br />
<br />
- Klimatisierung über das Pull Down Menü<br />
unterschiedliche Temperaturen für Heizen und Kühlen<br />
Aktuelle Temperatur<br />
Heizen/Klima Ein/Aus<br />
Timer für zeitgesteuertes Klimatisieren für den Resttag oder den Nächsten Tag (vor der aktuellen Zeit)<br />
Klimatisierung über "Abfall" Kalender (es geht nur ein Termin pro Tag, dafür aber komfortabel über das Handy)<br />
<br />
- Komfort<br />
Reifen Überwachung<br />
Türen / Motorhaube / Kofferraum Überwachung<br />
12V Batterie anzeige, wenn der Ladezustand kleiner 40% ist erfolgt keine weitere Status Abfrage<br />
<br />
- ACCU Steuerung<br />
Setzen des Ziel SOC beim Standard Laden<br />
Start/Stop Laden<br />
Accu Stand und berechnete Restkilometer<br />
<br />
- Für openWB integratin im uiTable<br />
Wählen des Lademodus<br />
Vorrang EV oder Bat<br />
Sperren des Hausspeichers entweder manuell oder automatisch beim Laden. Der vorherige Zustand wird gespeichert<br />
Die Freigabe erfolgt über die Wechselrichter Implementierung, siehe dort [[Kostal_Plenticore_10_Plus#Externe_Speichersteuerung_.28ExternControl.29|"Externe Speicher Steuerung"]]<br />
Geschätzte Ladezeit<br />
Status Ladepunkt (Plug und Laden)<br />
Lade Status Phasen und Leistung <br />
<br />
'''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.'''<br />
<br />
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.<br />
<br />
RAW des DOIF<br />
<syntaxhighlight lang="Perl"><br />
defmod Kia_eNiro_PV DOIF ################################################################################################################\<br />
## 1 Kia Connect Status Abfrage erfolgt mit MQTT2 ==> node-ret ==> Kia Connect\<br />
##\<br />
1_Status_getAll\<br />
{if( !([$SELF:state] eq "off") ## DOIF enabled\<br />
and [Kia_connect:req_active] eq "idle"\<br />
and\<br />
( ([+00:15] and ## alle 15 Minuten\<br />
[Kia_connect:atHomeStanding] eq "true" and ## wenn das Auto zuhause ist\<br />
[Kia_connect:charging] eq "true" or ## und es geladen wird\<br />
[:58] and [05:00-23:00] ## ansonsten nur jede Stunde\<br />
) and [Kia_connect:bat12v] > 40 ## aber die 12V Batterie sollte noch genügend Ladung haben\<br />
or [$SELF:cmd_event] eq "set_cmd_1" ## Das reagiert auf den Aufruf mit "set <Device> cmd_*"\<br />
or [$SELF:ui_command_1] eq "Status_getAll" ## Hier wird das uiTable select ausgewertet\<br />
)\<br />
) {\<br />
if( [$SELF:ui_command_1] eq "Status_getAll" ) { ## Hier wurde manuell eingeschaltet\<br />
set_Reading("ui_command_before_1",[$SELF:ui_command_1]);;\<br />
}\<br />
\<br />
fhem_set("Kia_connect getAll");; ## beliebige Kommandos für diesen Block\<br />
\<br />
set_Reading("ui_command_1","---");; ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten\<br />
## kann das Kommando nicht sofort wiederholt werden\<br />
}\<br />
}\<br />
\<br />
2_Klima\<br />
{if( !([$SELF:state] eq "off") ## DOIF enabled\<br />
and [Kia_connect:req_active] eq "idle"\<br />
and\<br />
( [$SELF:ui_command_2] eq "stopClimate" ## Hier wird das uiTable select ausgewertet\<br />
or [$SELF:ui_command_2] eq "startHeating"\<br />
or [$SELF:ui_command_2] eq "startCooling"\<br />
)\<br />
) {\<br />
set_Reading("ui_command_before_2",[$SELF:ui_command_2]);;\<br />
\<br />
if ([$SELF:ui_command_2] eq "startHeating") {\<br />
my $airTemp_value= [Kia_connect:status_airTemp_value_target_Winter];;\<br />
fhem_set('Kia_connect startClimate {"defrost": true, "windscreenHeating": true, "temperature": '.$airTemp_value.' , "unit": "C"}');;\<br />
if (AttrVal("$SELF","verbose",0) >= 0)\<br />
{Log 3, "$SELF 2_Klima : startHeating"};;\<br />
}\<br />
if ([$SELF:ui_command_2] eq "startCooling") {\<br />
my $airTemp_value = [Kia_connect:status_airTemp_value_target_Summer];;\<br />
fhem_set('Kia_connect startClimate {"defrost": false, "windscreenHeating": false, "temperature": '.$airTemp_value.' , "unit": "C"}');;\<br />
if (AttrVal("$SELF","verbose",0) >= 0)\<br />
{Log 3, "$SELF 2_Klima : startCooling"};;\<br />
}\<br />
if ([$SELF:ui_command_2] eq "stopClimate") {\<br />
fhem_set("Kia_connect ".[$SELF:ui_command_2]);;\<br />
if (AttrVal("$SELF","verbose",0) >= 0)\<br />
{Log 3, "$SELF 2_Klima : stopClimate"};;\<br />
}\<br />
fhem_set("Abfall update");;\<br />
\<br />
set_Reading("ui_command_2","---");; ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten\<br />
## kann das Kommando nicht sofort wiederholt werden\<br />
}\<br />
}\<br />
\<br />
3_Laden\<br />
{if( !([$SELF:state] eq "off") ## DOIF enabled\<br />
and [Kia_connect:req_active] eq "idle"\<br />
and\<br />
( [$SELF:ui_command_3] eq "setChargeTargetSoc" ## Hier wird das uiTable select ausgewertet\<br />
or [$SELF:ui_command_3] eq "startCharge"\<br />
or [$SELF:ui_command_3] eq "stopCharge"\<br />
)\<br />
) {\<br />
set_Reading("ui_command_before_3",[$SELF:ui_command_3]);;\<br />
\<br />
if ([$SELF:ui_command_3] eq "setChargeTargetSoc") {\<br />
my $targetSOClist_1_targetSOClevel = [Kia_connect:status_evStatus_reservChargeInfos_targetSOClist_1_targetSOClevel_target];;\<br />
my $targetSOClist_2_targetSOClevel = [Kia_connect:status_evStatus_reservChargeInfos_targetSOClist_2_targetSOClevel_target];;\<br />
fhem_set("Kia_connect setChargeTargetSoc {\"fast\": ".$targetSOClist_1_targetSOClevel.", \"slow\": ".$targetSOClist_2_targetSOClevel."}");;\<br />
} else {\<br />
fhem_set("Kia_connect ".[$SELF:ui_command_3]);; ## beliebige Kommandos für diesen Block\<br />
}\<br />
\<br />
set_Reading("ui_command_3","---");; ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten\<br />
## kann das Kommando nicht sofort wiederholt werden\<br />
}\<br />
}\<br />
\<br />
4_Klima_timer_heizen\<br />
{if( !([$SELF:state] eq "off") ## DOIF enabled\<br />
and\<br />
(\<br />
( [[Abfall_Abfuhr:Kiaheizen_connect_time]] ## Prüfe den Kalender Eintrag\<br />
and [Abfall_Abfuhr:Kiaheizen_connect_date] eq $ymd ## ist es heute?\<br />
)\<br />
or\<br />
( [$SELF:ui_timer_mode] eq "heizen" ## Timer zum Heizen aktiv?\<br />
and [[$SELF:ui_timer_Start]] ## ist es soweit?\<br />
)\<br />
)\<br />
) {\<br />
\<br />
if (AttrVal("$SELF","verbose",0) >= 0)\<br />
{Log 3, "$SELF 4_Klima_timer : startHeating"};;\<br />
set_Reading("ui_timer_mode","Aus");; ## Schalte die Timer Funktion ab\<br />
set_Reading("ui_command_2","startHeating");; ## Es soll geheizt werden\<br />
fhem_set("$SELF 2_Klima");; ## Aktiviere das Heizen\<br />
\<br />
}\<br />
}\<br />
\<br />
5_Klima_timer_kuehlen\<br />
{if( !([$SELF:state] eq "off") ## DOIF enabled\<br />
and\<br />
(\<br />
( [[Abfall_Abfuhr:Kiakuehlen_connect_time]] ## Prüfe den Kalender Eintrag\<br />
and [Abfall_Abfuhr:Kiakuehlen_connect_date] eq $ymd ## ist es heute?\<br />
)\<br />
or\<br />
( [$SELF:ui_timer_mode] eq "kuehlen" ## Timer zum Kühler aktiv?\<br />
and [[$SELF:ui_timer_Start]] ## ist es soweit?\<br />
)\<br />
)\<br />
) {\<br />
\<br />
if (AttrVal("$SELF","verbose",0) >= 0)\<br />
{Log 3, "$SELF 4_Klima_timer : startCooling"};;\<br />
set_Reading("ui_timer_mode","Aus");; ## Schalte die Timer Funktion ab\<br />
set_Reading("ui_command_2","startCooling");; ## Es soll gekühlt werden\<br />
fhem_set("$SELF 2_Klima");; ## Aktiviere das Kühlen\<br />
\<br />
}\<br />
}\<br />
\<br />
6_Auf_Zu\<br />
{if( !([$SELF:state] eq "off") ## DOIF enabled\<br />
and [Kia_connect:req_active] eq "idle"\<br />
and\<br />
( [$SELF:ui_command_2] eq "car_lock" ## Hier wird das uiTable select ausgewertet\<br />
or [$SELF:ui_command_2] eq "car_unlock"\<br />
)\<br />
) {\<br />
set_Reading("ui_command_before_2",[$SELF:ui_command_2]);;\<br />
\<br />
fhem_set("Kia_connect ".[$SELF:ui_command_2]);;\<br />
if (AttrVal("$SELF","verbose",0) >= 0)\<br />
{Log 3, "$SELF 6_Auf_Zu : ".[$SELF:ui_command_2]};;\<br />
\<br />
set_Reading("ui_command_2","---");; ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten\<br />
## kann das Kommando nicht sofort wiederholt werden\<br />
}\<br />
}\<br />
\<br />
7_WB_1_lp_1\<br />
{if( !([$SELF:state] eq "off") ## DOIF enabled\<br />
and\<br />
( [$SELF:ui_command_4] eq "SofortLaden" ## Hier wird das uiTable select ausgewertet\<br />
or [$SELF:ui_command_4] eq "Min+PV"\<br />
or [$SELF:ui_command_4] eq "NurPV"\<br />
or [$SELF:ui_command_4] eq "Stop"\<br />
or [$SELF:ui_command_4] eq "Standby"\<br />
or [$SELF:ui_command_4] eq "Vorrang_EV"\<br />
or [$SELF:ui_command_4] eq "Vorrang_Bat"\<br />
)\<br />
) {\<br />
set_Reading("ui_command_before_4",[$SELF:ui_command_4]);;\<br />
\<br />
if ([$SELF:ui_command_4] eq "Vorrang_Bat" OR [$SELF:ui_command_4] eq "Vorrang_EV") {\<br />
if ([$SELF:ui_command_4] eq "Vorrang_EV") {\<br />
fhem_set("WB_1 priorityModeEVBattery 1");;\<br />
} else {\<br />
fhem_set("WB_1 priorityModeEVBattery 0");;\<br />
}\<br />
if (AttrVal("$SELF","verbose",0) >= 0)\<br />
{Log 3, "$SELF 7_WB_1_lp_1 : ".[$SELF:ui_command_4]};;\<br />
} else {\<br />
fhem_set("WB_1 Lademodus ".[$SELF:ui_command_4]);;\<br />
if (AttrVal("$SELF","verbose",0) >= 0)\<br />
{Log 3, "$SELF 7_WB_1_lp_1 : Lademodus ".[$SELF:ui_command_4]};;\<br />
}\<br />
\<br />
set_Reading("ui_command_4","---");; ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten\<br />
## kann das Kommando nicht sofort wiederholt werden\<br />
}\<br />
}\<br />
\<br />
8_Speicher_sperren\<br />
{if( !([$SELF:state] eq "off") ## DOIF enabled\<br />
and\<br />
( [$SELF:ui_command_4] eq "Hausspeicher_Sperren" ## Hier wird das uiTable select ausgewertet\<br />
or [WB_1:lp_1_ChargeStat] eq "loading" and\<br />
[WB_1:lp_1_PlugStat] eq "Plugged in"\<br />
)\<br />
) {\<br />
set_Reading("ui_command_before_4",[$SELF:ui_command_4]);;\<br />
\<br />
if([$SELF:WR_1_Speicher_1_ExternControl_smart_laden_before] eq "---") {\<br />
\<br />
if([$SELF:SpeicherExternTrigger] eq "gesperrt" and\<br />
[WR_1_API:Battery_InternControl_MinHomeConsumption] eq "30000" ) {\<br />
set_Reading("WR_1_Speicher_1_ExternControl_smart_laden_before","aktiv");;\<br />
if (AttrVal("$SELF","verbose",0) >= 0)\<br />
{Log 3, "$SELF 8_Speicher_sperren : smart_laden_before aktiv"};;\<br />
} else {\<br />
set_Reading("WR_1_Speicher_1_ExternControl_smart_laden_before","inaktiv");;\<br />
if (AttrVal("$SELF","verbose",0) >= 0)\<br />
{Log 3, "$SELF 8_Speicher_sperren : smart_laden_before inaktiv"};;\<br />
}\<br />
\<br />
fhem_set("WR_1_Speicher_1_ExternControl cmd_2");;\<br />
if (AttrVal("$SELF","verbose",0) >= 0)\<br />
{Log 3, "$SELF 8_Speicher_sperren : smart_Laden startet"};;\<br />
}\<br />
\<br />
set_Reading("ui_command_4","---");; ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten\<br />
## kann das Kommando nicht sofort wiederholt werden\<br />
}\<br />
}\<br />
\<br />
9_WB_1_Zaehler_Statistiken\<br />
{if( !([$SELF:state] eq "off") and ## DOIF enabled\<br />
[00:01]\<br />
) {\<br />
fhem("setreading WB_1 lp_1_kWhCounter_init_Day ".[WB_1:lp_1_kWhCounter]);;\<br />
fhem("setreading WB_1 lp_2_kWhCounter_init_Day ".[WB_1:lp_2_kWhCounter]);;\<br />
\<br />
if ($mday eq 1)\<br />
{\<br />
fhem("setreading WB_1 lp_1_kWhCounter_init_Month ".[WB_1:lp_1_kWhCounter]);;\<br />
fhem("setreading WB_1 lp_2_kWhCounter_init_Month ".[WB_1:lp_2_kWhCounter]);;\<br />
\<br />
if ($yday eq 0)\<br />
{\<br />
fhem("setreading WB_1 lp_1_kWhCounter_init_Year ".[WB_1:lp_1_kWhCounter]);;\<br />
fhem("setreading WB_1 lp_2_kWhCounter_init_Year ".[WB_1:lp_2_kWhCounter]);;\<br />
}\<br />
}\<br />
}\<br />
}<br />
attr Kia_eNiro_PV DbLogExclude .*<br />
attr Kia_eNiro_PV disable 0<br />
attr Kia_eNiro_PV group PV Eigenverbrauch-Steuerung<br />
attr Kia_eNiro_PV icon car<br />
attr Kia_eNiro_PV room Strom->Photovoltaik<br />
attr Kia_eNiro_PV sortby 401<br />
attr Kia_eNiro_PV uiTable {\<br />
package ui_Table;;\<br />
## $TR{0} = "style='color:yellow;;text-align:left;;font-weight:bold;;font-size:18px'";; ## Reihe 0 für Überschrift\<br />
$TABLE = "style='width:100%;;'";;\<br />
\<br />
$TD{0..9}{0} = "align='center' style='font-size:16px;;border-right-style:solid;;border-color:darkgreen;;border-right-width:2px;;width:26%'";;\<br />
\<br />
$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;;'";;\<br />
$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;;'";;\<br />
$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;;'";;\<br />
\<br />
sub FUNC_batt {\<br />
my($val)=@_;;\<br />
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);;";;\<br />
return $ret;;\<br />
}\<br />
sub FUNC_Status {\<br />
my($value, $min, $colorMin, $statusMin, $colorMiddel, $statusMiddle, $max, $colorMax, $statusMax)=@_;;\<br />
my $ret = ($value < $min)? '<span style="color:'.$colorMin.'">'.$statusMin.'</span>' : ($value > $max)? '<span style="color:'.$colorMax.'">'.$statusMax.'</span>' : '<span style="color:'.$colorMiddel.'">'.$statusMiddle.'</span>';;\<br />
return $ret;;\<br />
}\<br />
sub FUNC_Status_Laden {\<br />
my($car)=@_;;\<br />
my $charge = (::ReadingsVal($car,"charging","false") eq "true");;\<br />
my $athome = (::ReadingsVal($car,"atHomeStanding","false") eq "true");;\<br />
my $chargeathome = ($charge && $athome);;\<br />
my $connectedathome = ($athome && ::ReadingsVal($car,"connected","false") eq "true");;\<br />
\<br />
my $ret = ($chargeathome ? "lädt zu Hause" : ($connectedathome ? "angeschlossen zu Hause" : ($athome ? "zu Hause" : ($charge ? "Lädt auswärts" : "unterwegs"))));;\<br />
return $ret;;\<br />
}\<br />
sub FUNC_tire {\<br />
my($car)=@_;;\<br />
my $ret = '<span style="color:green">Reifendruck okay</span>';;\<br />
\<br />
if (::ReadingsVal($car,"status_tirePressureLamp_tirePressureLampAll","1") != 0) {\<br />
my $VL = (::ReadingsVal($car,"status_tirePressureLamp_tirePressureLampFL","1") eq "0")?0:1;;\<br />
my $HL = (::ReadingsVal($car,"status_tirePressureLamp_tirePressureLampRL","1") eq "0")?0:1;;\<br />
my $VR = (::ReadingsVal($car,"status_tirePressureLamp_tirePressureLampFR","1") eq "0")?0:1;;\<br />
my $HR = (::ReadingsVal($car,"status_tirePressureLamp_tirePressureLampRR","1") eq "0")?0:1;;\<br />
$ret = '<span style="color:red">Reifen Störung<br>';;\<br />
if ($VL == 1){$ret.=' /VL'};;\<br />
if ($VR == 1){$ret.=' /VR'};;\<br />
if ($HL == 1){$ret.=' /HL'};;\<br />
if ($HR == 1){$ret.=' /HR'};;\<br />
$ret = $ret.'</span>';;\<br />
}\<br />
return $ret;;\<br />
}\<br />
sub FUNC_door {\<br />
my($car)=@_;;\<br />
my $ret = '<span style="color:green">Türen okay<br></span>';;\<br />
\<br />
if (::ReadingsVal($car,"status_doorLock","false") ne "true") {\<br />
my $VL = (::ReadingsVal($car,"status_doorOpen_frontLeft",1) == 0)?0:1;;\<br />
my $HL = (::ReadingsVal($car,"status_doorOpen_backLeft",1) == 0)?0:1;;\<br />
my $VR = (::ReadingsVal($car,"status_doorOpen_frontRight",1) == 0)?0:1;;\<br />
my $HR = (::ReadingsVal($car,"status_doorOpen_backRight",1) == 0)?0:1;;\<br />
$ret = '<span style="color:red">Tür offen<br>';;\<br />
if ($VL == 1){$ret.=' /VL'};;\<br />
if ($VR == 1){$ret.=' /VR'};;\<br />
if ($HL == 1){$ret.=' /HL'};;\<br />
if ($HR == 1){$ret.=' /HR'};;\<br />
$ret = $ret.'</span>';;\<br />
}\<br />
if (::ReadingsVal($car,"status_trunkOpen","true") eq "true") {\<br />
$ret.='<span style="color:red"> Kofferraum offen</span>';;\<br />
}\<br />
if (::ReadingsVal($car,"status_hoodOpen","true") eq "true") {\<br />
$ret.='<span style="color:red"> Motorhaube offen</span>';;\<br />
}\<br />
return $ret;;\<br />
}\<br />
}\<br />
\<br />
"$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")\<br />
\<br />
|"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>"\<br />
\<br />
|"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")|\<br />
((::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")|\<br />
"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>"\<br />
\<br />
|"<dd> Auswahl / Temperatur / Klima Status / Temperatur innen</dd>"| widget([$SELF:ui_command_2],"uzsuDropDown,---,stopClimate,startHeating,startCooling")|\<br />
"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"\<br />
\<br />
|"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"<br />
<br />
setstate Kia_eNiro_PV 2022-01-12 13:24:24 ui_command_1 ---<br />
setstate Kia_eNiro_PV 2022-01-10 09:18:53 ui_command_2 ---<br />
setstate Kia_eNiro_PV 2021-11-09 07:56:54 ui_command_3 ---<br />
setstate Kia_eNiro_PV 2022-01-12 13:02:41 ui_command_4 ---<br />
setstate Kia_eNiro_PV 2022-01-12 13:02:41 ui_command_before_4 ---<br />
setstate Kia_eNiro_PV 2021-11-29 09:56:58 ui_timer_Start 10:30<br />
setstate Kia_eNiro_PV 2021-12-02 07:00:00 ui_timer_mode Aus<br />
<br />
</syntaxhighlight><br />
<br />
=====Kostal Plenticore mit Speicher=====<br />
Zu diesem Thema gibt es noch eine andere Wiki Seite, die alles rund um den Wechselrichter und vieles mehr erklärt.<br />
[[https://wiki.fhem.de/wiki/Kostal_Plenticore_10_Plus|Kostal Plenticore Plus]]<br />
Die hier beschriebene openWB und Kia connect Anbindung bedient sich der Hausspeichersteuerung, um diesen beim Laden der BEV zu sperren.<br />
Im DOIF kann an den entsprechenden Stellen natürlich auch ein anders Kommando zum Sperren verwendet werden.<br />
<br />
== Weiterführende Links ==<br />
* [https://openwb.de openWB Website]<br />
* [https://github.com/snaptec/openWB/wiki openWB Wiki bei GitHub]<br />
* [https://www.openwb.de/forum/viewtopic.php?f=6&t=4159 openWB Forum (Diskussion zu diesem Artikel)]<br />
* [https://openwb.de/forum/viewtopic.php?t=577 openWB Forum (Liste der MQTT-Topics)]<br />
<br />
[[Kategorie:Elektromobilität]]<br />
[[Kategorie:HOWTOS]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=38170Einrichten der Bluetooth-Thermostate von eQ-32023-02-25T20:16:53Z<p>F Klee: </p>
<hr />
<div>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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth, die genau gleich aussehen. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
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:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
<br />
== Thermostat in FHEM definieren ==<br />
=== Pairing ===<br />
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:<br />
<pre><br />
$ sudo bluetoothctl<br />
[bluetooth]# power on<br />
[bluetooth]# agent on<br />
[bluetooth]# default-agent<br />
[bluetooth]# scan on<br />
Discovery started<br />
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes<br />
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70<br />
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...<br />
[bluetooth]# scan off<br />
[bluetooth]# pair 00:1A:22:06:A7:83<br />
[agent] Enter passkey (number in 0-999999): <enter pin><br />
[bluetooth]# trust 00:1A:22:06:A7:83<br />
[bluetooth]# disconnect 00:1A:22:06:A7:83<br />
[bluetooth]# exit<br />
<br />
Optional steps:<br />
[bluetooth]# devices - to list all bluetooth devices<br />
[bluetooth]# info 00:1A:22:06:A7:83<br />
Device 00:1A:22:06:A7:83 (public)<br />
Name: CC-RT-BLE<br />
Alias: CC-RT-BLE<br />
Paired: yes<br />
Trusted: yes<br />
Blocked: no<br />
Connected: no<br />
LegacyPairing: no<br />
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)<br />
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)<br />
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)<br />
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)<br />
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)<br />
ManufacturerData Key: 0x0000<br />
ManufacturerData Value:<br />
00 00 00 00 00 00 00 00 00 .........</pre><br />
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).<br />
Unter Umständen wird nicht nach <code>Enter passkey</code> gefragt. Wichtig ist die Erfolgsmeldung.<br><br />
Die Befehle bedeuten im Einzelnen:<br />
<pre>$ sudo bluetoothctl</pre><br />
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:<br />
<pre>[CHG] Controller E4:5F:01:F0:0E:98 Pairable: yes<br />
[bluetooth]#</pre><br />
Die Zeile „[CHG] Controller“ (oder auch [NEW]) zeigt die Informationen zu deinem Bluetooth-Chip an. Die letzte Zeile ist die Eingabeaufforderung von bluetoothctl.<br />
<br />
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:<br />
<pre>[bluetooth]# agent on<br />
Agent registered <br />
[bluetooth]# default-agent <br />
Default agent request successful <br />
[bluetooth]#</pre><br />
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><br />
An dieser Stelle kannst du mit der Suche nach entfernten Bluetooth-Geräten fortfahren:<br />
<pre>[bluetooth]# scan on<br />
Discovery started<br />
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes<br />
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70<br />
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...<br />
[NEW] Device <bluetooth address> <name></pre><br />
Stoppt man den Scan mit <code>[bluetooth]# scan off</code>, so werden die Ergebnisse der Geräteerkennung nach einer gewissen Zeit ungültig.<br />
<pre>[DEL] Device 00:1A:22:XX:XX:XX CC-RT-BLE</pre><br />
Vorher kann das Pairing gestartet werden:<br />
<pre>[bluetooth]# pair 00:1A:22:06:A7:83</pre><br />
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<br />
<pre>[bluetooth]# trust 00:1A:22:06:A7:83</pre><br />
und wieder getrennt werden<br />
<pre>[bluetooth]# disconnect 00:1A:22:06:A7:83</pre><br />
Danach kannst du über<br />
<pre>[bluetooth]# info 00:1A:22:06:A7:83</pre><br />
nachsehen, ob alles korrekt ist. Das Gerät kann nun in FHEM definiert werden.<br />
<br />
=== Einrichten mit Perl-Modul 10_EQ3BT ===<br />
Die eQ-3 Heizkörperthermostate können einfach über<br />
define <name> EQ3BT <mac address> <br />
eingebunden werden.<br />
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}<br />
<br />
=== Einrichten mit fhempy ===<br />
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.<br />
<br />
==== Installation auf FHEM-Server ====<br />
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.<br />
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit<br />
<br />
<pre><br />
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><br />
<br />
Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.<br />
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:<br />
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt<br />
update</pre><br />
Ist das Update abgeschlossen, können wir fhempy einrichten:<br />
<pre>define fhempy_local BindingsIo fhempy</pre><br />
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.<br />
<br />
Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit<br />
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre><br />
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.<br />
<br />
==== Installation des fhempy-Peer ====<br />
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.<br />
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}<br />
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi<br />
<pre>pip3 install --upgrade fhempy</pre><br />
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer<br />
<pre>fhempy</pre><br />
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.<br />
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird<br />
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre><br />
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.<br />
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden<br />
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre><br />
<br />
<br />
== Bekannte Probleme ==<br />
=== Fehlermeldung nach fhempy-Installation ===<br />
Meldet pip3 folgendes<br />
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.<br />
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre><br />
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen<br />
<pre>export PATH=$PATH:/home/myname/.local/bin</pre><br />
also z.B.<br />
<pre>export PATH=$PATH:/home/pi/.local/bin</pre><br />
<br />
=== Keine Reaktion auf Einstellen der Offset-Temperatur ===<br />
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.<br />
<br />
=== Pairing wird hartnäckig verweigert ===<br />
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.<br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]<br />
[[Kategorie:Bluetooth]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=38169Einrichten der Bluetooth-Thermostate von eQ-32023-02-25T20:15:15Z<p>F Klee: Beschreibung der Installation von fhempy auf Bullseye reduziert, Pairing ist immer erforderlich, deshalb an den Anfang verschoben.</p>
<hr />
<div>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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth, die genau gleich aussehen. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
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:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
<br />
== Thermostat in FHEM definieren ==<br />
=== Pairing ===<br />
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:<br />
<pre><br />
$ sudo bluetoothctl<br />
[bluetooth]# power on<br />
[bluetooth]# agent on<br />
[bluetooth]# default-agent<br />
[bluetooth]# scan on<br />
Discovery started<br />
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes<br />
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70<br />
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...<br />
[bluetooth]# scan off<br />
[bluetooth]# pair 00:1A:22:06:A7:83<br />
[agent] Enter passkey (number in 0-999999): <enter pin><br />
[bluetooth]# trust 00:1A:22:06:A7:83<br />
[bluetooth]# disconnect 00:1A:22:06:A7:83<br />
[bluetooth]# exit<br />
<br />
Optional steps:<br />
[bluetooth]# devices - to list all bluetooth devices<br />
[bluetooth]# info 00:1A:22:06:A7:83<br />
Device 00:1A:22:06:A7:83 (public)<br />
Name: CC-RT-BLE<br />
Alias: CC-RT-BLE<br />
Paired: yes<br />
Trusted: yes<br />
Blocked: no<br />
Connected: no<br />
LegacyPairing: no<br />
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)<br />
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)<br />
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)<br />
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)<br />
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)<br />
ManufacturerData Key: 0x0000<br />
ManufacturerData Value:<br />
00 00 00 00 00 00 00 00 00 .........</pre><br />
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).<br />
Unter Umständen wird nicht nach <code>Enter passkey</code> gefragt. Wichtig ist die Erfolgsmeldung.<br><br />
Die Befehle bedeuten im Einzelnen:<br />
<pre>$ sudo bluetoothctl</pre><br />
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:<br />
<pre>[CHG] Controller E4:5F:01:F0:0E:98 Pairable: yes<br />
[bluetooth]#</pre><br />
Die Zeile „[CHG] Controller“ (oder auch [NEW]) zeigt die Informationen zu deinem Bluetooth-Chip an. Die letzte Zeile ist die Eingabeaufforderung von bluetoothctl.<br />
<br />
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:<br />
<pre>[bluetooth]# agent on<br />
Agent registered <br />
[bluetooth]# default-agent <br />
Default agent request successful <br />
[bluetooth]#</pre><br />
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><br />
An dieser Stelle kannst du mit der Suche nach entfernten Bluetooth-Geräten fortfahren:<br />
<pre>[bluetooth]# scan on<br />
Discovery started<br />
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes<br />
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70<br />
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...<br />
[NEW] Device <bluetooth address> <name></pre><br />
Stoppt man den Scan mit <code>[bluetooth]# scan off</code>, so werden die Ergebnisse der Geräteerkennung nach einer gewissen Zeit ungültig.<br />
<pre>[DEL] Device 00:1A:22:XX:XX:XX CC-RT-BLE</pre><br />
Vorher kann das Pairing gestartet werden:<br />
<pre>[bluetooth]# pair 00:1A:22:06:A7:83</pre><br />
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<br />
<pre>[bluetooth]# trust 00:1A:22:06:A7:83</pre><br />
und wieder getrennt werden<br />
<pre>[bluetooth]# disconnect 00:1A:22:06:A7:83</pre><br />
Danach kannst du über<br />
<pre>[bluetooth]# info 00:1A:22:06:A7:83</pre><br />
nachsehen, ob alles korrekt ist. Das Gerät kann nun in FHEM definiert werden.<br />
<br />
=== Einrichten mit Perl-Modul 10_EQ3BT ===<br />
Die eQ-3 Heizkörperthermostate können einfach über<br />
define <name> EQ3BT <mac address> <br />
eingebunden werden.<br />
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}<br />
<br />
=== Einrichten mit fhempy ===<br />
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.<br />
<br />
==== Installation auf FHEM-Server ====<br />
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.<br />
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit<br />
<br />
<pre><br />
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><br />
<br />
Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.<br />
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:<br />
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt<br />
update</pre><br />
Ist das Update abgeschlossen, können wir fhempy einrichten:<br />
<pre>define fhempy_local BindingsIo fhempy</pre><br />
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.<br />
<br />
Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit<br />
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre><br />
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.<br />
<br />
==== Installation des fhempy-Peer ====<br />
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.<br />
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}<br />
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi<br />
<pre>pip3 install --upgrade fhempy</pre><br />
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer<br />
<pre>fhempy</pre><br />
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.<br />
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird<br />
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre><br />
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.<br />
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden<br />
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre><br />
<br />
<br />
== Bekannte Probleme ==<br />
=== Fehlermeldung nach fhempy-Installation ===<br />
Meldet pip3 folgendes<br />
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.<br />
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre><br />
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen<br />
<pre>export PATH=$PATH:/home/myname/.local/bin</pre><br />
also z.B.<br />
<pre>export PATH=$PATH:/home/pi/.local/bin</pre><br />
<br />
=== Keine Reaktion auf Einstellen der Offset-Temperatur ===<br />
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.<br />
<br />
=== Pairing wird hartnäckig verweigert ===<br />
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.<br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]<br />
[[Kategorie:Bluetooth]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=38156Einrichten der Bluetooth-Thermostate von eQ-32023-02-22T06:52:42Z<p>F Klee: Hinweis auf Python3.9 ergänzt</p>
<hr />
<div>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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth, die genau gleich aussehen. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
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:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
<br />
== Thermostat in FHEM definieren ==<br />
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:<br />
<pre>pi@raspberrypi ~ $ bluetoothctl<br />
[NEW] Controller 00:1A:7D:XX:XX:XX raspberrypi [default]<br />
[bluetooth]# scan on<br />
Discovery started<br />
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes<br />
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70<br />
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...<br />
[bluetooth]# scan off</pre><br />
Die Geräte tragen den Namen CC-RT-BLE.<br />
<br />
=== Einrichten mit Perl-Modul 10_EQ3BT ===<br />
Die eQ-3 Heizkörperthermostate können einfach über<br />
define <name> EQ3BT <mac address> <br />
eingebunden werden.<br />
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}<br />
<br />
=== Einrichten mit fhempy ===<br />
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.<br />
==== Installation auf FHEM-Server ====<br />
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.<br />
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit<br />
<br />
[Debian 11 (Bullseye)]<br />
<pre><br />
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><br />
<br />
{{Randnotiz|RNTyp=r|RNText=Inzwischen ist Python3.9 zwingend erforderlich.}}<br />
[alle anderen]<br />
<pre><br />
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><br />
und als nächstes<br />
<pre><br />
sudo cpan Protocol::WebSocket</pre><br />
<br />
<br />
Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.<br />
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:<br />
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt<br />
update</pre><br />
Ist das Update abgeschlossen, können wir fhempy einrichten:<br />
<pre>define fhempy_local BindingsIo fhempy</pre><br />
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.<br />
<br />
Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit<br />
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre><br />
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.<br />
<br />
==== Installation des fhempy-Peer ====<br />
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.<br />
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}<br />
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi<br />
<pre>pip3 install --upgrade fhempy</pre><br />
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer<br />
<pre>fhempy</pre><br />
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.<br />
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird<br />
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre><br />
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.<br />
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden<br />
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre><br />
<br />
== Pairing ==<br />
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:<br />
<pre><br />
$ sudo bluetoothctl<br />
[bluetooth]# power on<br />
[bluetooth]# agent on<br />
[bluetooth]# default-agent<br />
[bluetooth]# scan on<br />
[bluetooth]# scan off<br />
[bluetooth]# pair 00:1A:22:06:A7:83<br />
[agent] Enter passkey (number in 0-999999): <enter pin><br />
[bluetooth]# trust 00:1A:22:06:A7:83<br />
[bluetooth]# disconnect 00:1A:22:06:A7:83<br />
[bluetooth]# exit<br />
<br />
Optional steps:<br />
[bluetooth]# devices - to list all bluetooth devices<br />
[bluetooth]# info 00:1A:22:06:A7:83<br />
Device 00:1A:22:06:A7:83 (public)<br />
Name: CC-RT-BLE<br />
Alias: CC-RT-BLE<br />
Paired: yes<br />
Trusted: yes<br />
Blocked: no<br />
Connected: no<br />
LegacyPairing: no<br />
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)<br />
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)<br />
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)<br />
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)<br />
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)<br />
ManufacturerData Key: 0x0000<br />
ManufacturerData Value:<br />
00 00 00 00 00 00 00 00 00 .........</pre><br />
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).<br />
Unter Umständen wird nicht nach <code>Enter passkey</code> gefragt. Wichtig ist die Erfolgsmeldung.<br><br />
Die Befehle bedeuten im Einzelnen:<br />
<pre>$ sudo bluetoothctl</pre><br />
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:<br />
<pre>[CHG] Controller E4:5F:01:F0:0E:98 Pairable: yes<br />
[bluetooth]#</pre><br />
Die Zeile „[CHG] Controller“ (oder auch [NEW]) zeigt die Informationen zu deinem Bluetooth-Chip an. Die letzte Zeile ist die Eingabeaufforderung von bluetoothctl.<br />
<br />
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:<br />
<pre>[bluetooth]# agent on<br />
Agent registered <br />
[bluetooth]# default-agent <br />
Default agent request successful <br />
[bluetooth]#</pre><br />
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><br />
An dieser Stelle kannst du mit der Suche nach entfernten Bluetooth-Geräten fortfahren:<br />
<pre>[bluetooth]# scan on<br />
Discovery started<br />
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes<br />
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70<br />
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...<br />
[NEW] Device <bluetooth address> <name></pre><br />
Stoppt man den Scan mit <code>[bluetooth]# scan off</code>, so werden die Ergebnisse der Geräteerkennung nach einer gewissen Zeit ungültig.<br />
<pre>[DEL] Device 00:1A:22:XX:XX:XX CC-RT-BLE</pre><br />
Vorher kann das Pairing gestartet werden:<br />
<pre>[bluetooth]# pair 00:1A:22:06:A7:83</pre><br />
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<br />
<pre>[bluetooth]# trust 00:1A:22:06:A7:83</pre><br />
und wieder getrennt werden<br />
<pre>[bluetooth]# disconnect 00:1A:22:06:A7:83</pre><br />
Danach kannst du über<br />
<pre>[bluetooth]# info 00:1A:22:06:A7:83</pre><br />
nachsehen, ob alles korrekt ist. Das Gerät kann nun in FHEM definiert werden.<br />
<br />
== Bekannte Probleme ==<br />
=== Fehlermeldung nach fhempy-Installation ===<br />
Meldet pip3 folgendes<br />
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.<br />
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre><br />
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen<br />
<pre>export PATH=$PATH:/home/myname/.local/bin</pre><br />
also z.B.<br />
<pre>export PATH=$PATH:/home/pi/.local/bin</pre><br />
<br />
=== Keine Reaktion auf Einstellen der Offset-Temperatur ===<br />
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.<br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]<br />
[[Kategorie:Bluetooth]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=38053Einrichten der Bluetooth-Thermostate von eQ-32023-02-07T15:55:30Z<p>F Klee: Einzelne Schritte des Pairing erläutert</p>
<hr />
<div>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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth, die genau gleich aussehen. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
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:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
<br />
== Thermostat in FHEM definieren ==<br />
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:<br />
<pre>pi@raspberrypi ~ $ bluetoothctl<br />
[NEW] Controller 00:1A:7D:XX:XX:XX raspberrypi [default]<br />
[bluetooth]# scan on<br />
Discovery started<br />
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes<br />
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70<br />
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...<br />
[bluetooth]# scan off</pre><br />
Die Geräte tragen den Namen CC-RT-BLE.<br />
<br />
=== Einrichten mit Perl-Modul 10_EQ3BT ===<br />
Die eQ-3 Heizkörperthermostate können einfach über<br />
define <name> EQ3BT <mac address> <br />
eingebunden werden.<br />
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}<br />
<br />
=== Einrichten mit fhempy ===<br />
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.<br />
==== Installation auf FHEM-Server ====<br />
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.<br />
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit<br />
<br />
[Debian 11 (Bullseye)]<br />
<pre><br />
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><br />
<br />
[alle anderen]<br />
<pre><br />
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><br />
und als nächstes<br />
<pre><br />
sudo cpan Protocol::WebSocket</pre><br />
<br />
<br />
Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.<br />
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:<br />
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt<br />
update</pre><br />
Ist das Update abgeschlossen, können wir fhempy einrichten:<br />
<pre>define fhempy_local BindingsIo fhempy</pre><br />
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.<br />
<br />
Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit<br />
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre><br />
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.<br />
<br />
==== Installation des fhempy-Peer ====<br />
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.<br />
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}<br />
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi<br />
<pre>pip3 install --upgrade fhempy</pre><br />
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer<br />
<pre>fhempy</pre><br />
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.<br />
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird<br />
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre><br />
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.<br />
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden<br />
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre><br />
<br />
== Pairing ==<br />
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:<br />
<pre><br />
$ sudo bluetoothctl<br />
[bluetooth]# power on<br />
[bluetooth]# agent on<br />
[bluetooth]# default-agent<br />
[bluetooth]# scan on<br />
[bluetooth]# scan off<br />
[bluetooth]# pair 00:1A:22:06:A7:83<br />
[agent] Enter passkey (number in 0-999999): <enter pin><br />
[bluetooth]# trust 00:1A:22:06:A7:83<br />
[bluetooth]# disconnect 00:1A:22:06:A7:83<br />
[bluetooth]# exit<br />
<br />
Optional steps:<br />
[bluetooth]# devices - to list all bluetooth devices<br />
[bluetooth]# info 00:1A:22:06:A7:83<br />
Device 00:1A:22:06:A7:83 (public)<br />
Name: CC-RT-BLE<br />
Alias: CC-RT-BLE<br />
Paired: yes<br />
Trusted: yes<br />
Blocked: no<br />
Connected: no<br />
LegacyPairing: no<br />
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)<br />
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)<br />
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)<br />
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)<br />
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)<br />
ManufacturerData Key: 0x0000<br />
ManufacturerData Value:<br />
00 00 00 00 00 00 00 00 00 .........</pre><br />
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).<br />
Unter Umständen wird nicht nach <code>Enter passkey</code> gefragt. Wichtig ist die Erfolgsmeldung.<br><br />
Die Befehle bedeuten im Einzelnen:<br />
<pre>$ sudo bluetoothctl</pre><br />
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:<br />
<pre>[CHG] Controller E4:5F:01:F0:0E:98 Pairable: yes<br />
[bluetooth]#</pre><br />
Die Zeile „[CHG] Controller“ (oder auch [NEW]) zeigt die Informationen zu deinem Bluetooth-Chip an. Die letzte Zeile ist die Eingabeaufforderung von bluetoothctl.<br />
<br />
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:<br />
<pre>[bluetooth]# agent on<br />
Agent registered <br />
[bluetooth]# default-agent <br />
Default agent request successful <br />
[bluetooth]#</pre><br />
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><br />
An dieser Stelle kannst du mit der Suche nach entfernten Bluetooth-Geräten fortfahren:<br />
<pre>[bluetooth]# scan on<br />
Discovery started<br />
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes<br />
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70<br />
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...<br />
[NEW] Device <bluetooth address> <name></pre><br />
Stoppt man den Scan mit <code>[bluetooth]# scan off</code>, so werden die Ergebnisse der Geräteerkennung nach einer gewissen Zeit ungültig.<br />
<pre>[DEL] Device 00:1A:22:XX:XX:XX CC-RT-BLE</pre><br />
Vorher kann das Pairing gestartet werden:<br />
<pre>[bluetooth]# pair 00:1A:22:06:A7:83</pre><br />
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<br />
<pre>[bluetooth]# trust 00:1A:22:06:A7:83</pre><br />
und wieder getrennt werden<br />
<pre>[bluetooth]# disconnect 00:1A:22:06:A7:83</pre><br />
Danach kannst du über<br />
<pre>[bluetooth]# info 00:1A:22:06:A7:83</pre><br />
nachsehen, ob alles korrekt ist. Das Gerät kann nun in FHEM definiert werden.<br />
<br />
== Bekannte Probleme ==<br />
=== Fehlermeldung nach fhempy-Installation ===<br />
Meldet pip3 folgendes<br />
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.<br />
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre><br />
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen<br />
<pre>export PATH=$PATH:/home/myname/.local/bin</pre><br />
also z.B.<br />
<pre>export PATH=$PATH:/home/pi/.local/bin</pre><br />
<br />
=== Keine Reaktion auf Einstellen der Offset-Temperatur ===<br />
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.<br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]<br />
[[Kategorie:Bluetooth]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Knxd&diff=37941Knxd2023-01-13T13:50:49Z<p>F Klee: /* Vorbereiten des Raspberry Pi für ROT oder PIGATOR */</p>
<hr />
<div>== knxd mit einem IP Gateway einrichten ==<br />
Damit FHEM auf den KNX Bus zugreifen kann, wird ein passendes Interface benötigt. Es gibt:<br />
* RS232<br />
* USB<br />
* IP<br />
<br />
Im Folgenden wird die Einrichtung von knxd mit einem IP Gateway auf einem Raspberry Pi2 mit Wheezy oder Jessie beschrieben.<br />
<br />
=== Installation ===<br />
<br />
==== Für Debian Jessie: ====<br />
'''als erstes müssen folgende Pakete installiert werden (Referenz Debian Jessie):'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
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<br />
</syntaxhighlight><br />
<br />
'''knxd herunterladen und installieren'''<br />
Achtung: Wenn Abhängigkeiten fehlen, dann müssen diese nachinstalliert werden. Nicht einfach mittels "-d" diese übergehen!<br />
<syntaxhighlight lang="bash"><br />
git clone https://github.com/knxd/knxd.git<br />
cd knxd<br />
git checkout deb<br />
dpkg-buildpackage -b -uc<br />
cd ..<br />
sudo dpkg -i knxd_*.deb knxd-tools_*.deb<br />
</syntaxhighlight><br />
<br />
==== Ab Debian Stretch, Buster, ... ====<br />
'''knxd ist in den Debian packages vorhanden, muss daher nicht compiliert werden.'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install knxd knxd-tools<br />
<br />
</syntaxhighlight><br />
<br />
Mit der Konfiguration '''mit Systemd weitermachen!''' <br />
=== Konfiguration ===<br />
'''1. Ohne systemd'''<br />
<br />
Es muss als nächstes die Konfigurationsdatei editiert werden, das geht mit:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/default/knxd <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
DAEMON_ARGS="-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.188.XX"<br />
</syntaxhighlight><br />
und<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
<br />
'''2. Mit systemd z. B. für Debian Jessie'''<br />
<br />
Die Konfigurationsdatei bei Jessie hat sich wegen der Nutzung von systemd geändert:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b ipt:192.168.188.XX"<br />
<br />
</syntaxhighlight><br />
=== knxd Status überprüfen ===<br />
<syntaxhighlight lang="bash"><br />
/etc/init.d/knxd status<br />
</syntaxhighlight><br />
<br />
== knxd als IP-Gateway einrichten ==<br />
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.:<br />
* ROT<br />
* PIGATOR mit PIM-TPUART<br />
* TUL<br />
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.<br />
<br />
=== Vorbereiten des TUL ===<br />
==== TUL flashen ====<br />
Der TUL wird ohne Software geliefert und kann über den Raspberry Pi programmiert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install dfu-programmer<br />
wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54<br />
sudo dfu-programmer atmega32u4 erase<br />
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex<br />
sudo dfu-programmer atmega32u4 reset<br />
sudo reboot<br />
</syntaxhighlight><br />
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.<br />
Der TUL hat an der Unterseite einen winzigen Button. Dieser muss gedrückt werden, während der TUL in die USB-Buchse gesteckt wird.<br />
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.<br />
<br />
==== TUL einen dauerhaften Namen geben ====<br />
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<br />
<syntaxhighlight lang="bash"><br />
ls -la /dev/serial/by-id/<br />
</syntaxhighlight><br />
identifiziert. Das Ergebnis sollte ungefähr so aussehen<br />
<syntaxhighlight lang="bash"><br />
usb-busware.de_TPUART_8543934393935171B1C1-if00 -> ../../ttyACM0<br />
</syntaxhighlight><br />
Die Seriennummer (8543934393935171B1C1) wird später benötigt. Der Befehl<br />
<syntaxhighlight lang="bash"><br />
lsusb<br />
</syntaxhighlight><br />
sollte u.a. diese Zeile liefern<br />
<syntaxhighlight lang="bash"><br />
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project<br />
</syntaxhighlight><br />
03eb ist dabei die Herstellerkennung, 204b die Produktkennung. Nun muss die Datei /etc/udev/rules.d/99-usb-serial.rules<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/udev/rules.d/99-usb-serial.rules<br />
</syntaxhighlight><br />
erstellt oder erweitert werden mit der Zeile<br />
<syntaxhighlight lang="bash"><br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="8543934393935171B1C1", SYMLINK+="knx", OWNER="knxd"<br />
</syntaxhighlight><br />
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.<br />
<br />
=== Vorbereiten des Raspberry Pi für ROT oder PIGATOR ===<br />
Der Raspberry Pi nutzt standardmäßig die serielle Schnittstelle als Terminal. Dies muss deaktiviert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo raspi-config<br />
5 Interfaceoption<br />
P6 Serial<br />
</syntaxhighlight><br />
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:<br />
<syntaxhighlight lang="bash"><br />
sudo usermod -aG dialout knxd<br />
</syntaxhighlight><br />
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<br />
<syntaxhighlight lang="bash"><br />
dtoverlay=disable-bt<br />
</syntaxhighlight><br />
am Ende eingefügt werden. Nun muss noch der Dienst hciuart deaktiviert werden (initialisiert das Bluetooth-Modem):<br />
<syntaxhighlight lang="bash"><br />
sudo systemctl disable hciuart<br />
</syntaxhighlight><br />
Nach einem anschließenden Reboot ist der TPUART unter ttyAMA0 ansprechbar.<br />
<br />
Nach dieser Prozedur ist natürlich die Benuzung des Bluetooth-Moduls nicht mehr möglich. Wer das Modul benötigt, findet die Anleitung hier:<br />
<br />
[[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]<br />
<br />
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].<br />
<br />
=== Andere BCU's (BusCouplerUnit) ===<br />
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.}}<br />
<br />
=== Installieren des knxd ===<br />
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.<br />
<br />
=== Konfiguration ===<br />
Die Konfiguration erfolgt wieder in der knxd.conf mit<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf<br />
</syntaxhighlight><br />
Nun die Konfiguarionszeile anpassen<br><br />
(serielle Schnittstelle)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b tpuarts:/dev/ttyAMA0"<br />
</syntaxhighlight><br />
(USB)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b tpuarts:/dev/knx"<br />
</syntaxhighlight><br />
Und dann noch<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
um knxd beim Systemstart sofort zu starten.<br />
<br />
-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 <br />
<syntaxhighlight lang="bash"><br />
define myKNXGW KNXIO T 127.0.0.1:6720 1.2.203<br />
</syntaxhighlight><br />
alternativ via Multicast: (siehe auch KNXIO-wiki):<syntaxhighlight lang="bash"><br />
define myKNXGW KNXIO M 224.0.23.12:3671 1.2.203<br />
</syntaxhighlight><br />
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.}}<br />
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)<br />
<syntaxhighlight lang="bash"><br />
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts<br />
"1" durch "0" ersetzen<br />
</syntaxhighlight><br />
Nach einem<br />
<syntaxhighlight lang="bash"><br />
sudo reboot<br />
</syntaxhighlight><br />
sollte der knxd dann laufen.<br />
{{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.}}<br />
<br />
== FAQ ==<br />
'''Wie wird eibd vorher deinstalliert?'''<br />
<syntaxhighlight lang="bash"><br />
sudo rm -r /usr/local/bin/{eibd,knxtool,group*} /usr/local/lib/lib{eib,pthsem}*.so* /usr/local/include/pth*<br />
</syntaxhighlight><br />
<br />
<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. <br />
<br />
'''folgender Fehler: dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install git-core build-essential<br />
</syntaxhighlight><br />
<br />
oder<br />
<br />
<syntaxhighlight lang="bash"><br />
in der datei knxd/debian/rules die Zeile:<br />
bash tools/test.sh auskommentieren<br />
</syntaxhighlight><br />
<br />
'''Fehler: dpkg-buildpackage: error: fakeroot not found, either install the fakeroot <....> '''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install fakeroot dpkg-dev<br />
</syntaxhighlight><br />
<br />
== Links ==<br />
* [[Benutzer:Marthinx]]<br />
* [https://github.com/knxd/knxd Github knxd]<br />
* [https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen Forums-Thread zu knxd. Sehr informativ.]<br />
<br />
[[Kategorie:Examples]]<br />
[[Kategorie:EIB/KNX]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Knxd&diff=37940Knxd2023-01-13T13:48:16Z<p>F Klee: Ergänzung für RasPi 4</p>
<hr />
<div>== knxd mit einem IP Gateway einrichten ==<br />
Damit FHEM auf den KNX Bus zugreifen kann, wird ein passendes Interface benötigt. Es gibt:<br />
* RS232<br />
* USB<br />
* IP<br />
<br />
Im Folgenden wird die Einrichtung von knxd mit einem IP Gateway auf einem Raspberry Pi2 mit Wheezy oder Jessie beschrieben.<br />
<br />
=== Installation ===<br />
<br />
==== Für Debian Jessie: ====<br />
'''als erstes müssen folgende Pakete installiert werden (Referenz Debian Jessie):'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
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<br />
</syntaxhighlight><br />
<br />
'''knxd herunterladen und installieren'''<br />
Achtung: Wenn Abhängigkeiten fehlen, dann müssen diese nachinstalliert werden. Nicht einfach mittels "-d" diese übergehen!<br />
<syntaxhighlight lang="bash"><br />
git clone https://github.com/knxd/knxd.git<br />
cd knxd<br />
git checkout deb<br />
dpkg-buildpackage -b -uc<br />
cd ..<br />
sudo dpkg -i knxd_*.deb knxd-tools_*.deb<br />
</syntaxhighlight><br />
<br />
==== Ab Debian Stretch, Buster, ... ====<br />
'''knxd ist in den Debian packages vorhanden, muss daher nicht compiliert werden.'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install knxd knxd-tools<br />
<br />
</syntaxhighlight><br />
<br />
Mit der Konfiguration '''mit Systemd weitermachen!''' <br />
=== Konfiguration ===<br />
'''1. Ohne systemd'''<br />
<br />
Es muss als nächstes die Konfigurationsdatei editiert werden, das geht mit:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/default/knxd <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
DAEMON_ARGS="-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.188.XX"<br />
</syntaxhighlight><br />
und<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
<br />
'''2. Mit systemd z. B. für Debian Jessie'''<br />
<br />
Die Konfigurationsdatei bei Jessie hat sich wegen der Nutzung von systemd geändert:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b ipt:192.168.188.XX"<br />
<br />
</syntaxhighlight><br />
=== knxd Status überprüfen ===<br />
<syntaxhighlight lang="bash"><br />
/etc/init.d/knxd status<br />
</syntaxhighlight><br />
<br />
== knxd als IP-Gateway einrichten ==<br />
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.:<br />
* ROT<br />
* PIGATOR mit PIM-TPUART<br />
* TUL<br />
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.<br />
<br />
=== Vorbereiten des TUL ===<br />
==== TUL flashen ====<br />
Der TUL wird ohne Software geliefert und kann über den Raspberry Pi programmiert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install dfu-programmer<br />
wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54<br />
sudo dfu-programmer atmega32u4 erase<br />
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex<br />
sudo dfu-programmer atmega32u4 reset<br />
sudo reboot<br />
</syntaxhighlight><br />
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.<br />
Der TUL hat an der Unterseite einen winzigen Button. Dieser muss gedrückt werden, während der TUL in die USB-Buchse gesteckt wird.<br />
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.<br />
<br />
==== TUL einen dauerhaften Namen geben ====<br />
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<br />
<syntaxhighlight lang="bash"><br />
ls -la /dev/serial/by-id/<br />
</syntaxhighlight><br />
identifiziert. Das Ergebnis sollte ungefähr so aussehen<br />
<syntaxhighlight lang="bash"><br />
usb-busware.de_TPUART_8543934393935171B1C1-if00 -> ../../ttyACM0<br />
</syntaxhighlight><br />
Die Seriennummer (8543934393935171B1C1) wird später benötigt. Der Befehl<br />
<syntaxhighlight lang="bash"><br />
lsusb<br />
</syntaxhighlight><br />
sollte u.a. diese Zeile liefern<br />
<syntaxhighlight lang="bash"><br />
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project<br />
</syntaxhighlight><br />
03eb ist dabei die Herstellerkennung, 204b die Produktkennung. Nun muss die Datei /etc/udev/rules.d/99-usb-serial.rules<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/udev/rules.d/99-usb-serial.rules<br />
</syntaxhighlight><br />
erstellt oder erweitert werden mit der Zeile<br />
<syntaxhighlight lang="bash"><br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="8543934393935171B1C1", SYMLINK+="knx", OWNER="knxd"<br />
</syntaxhighlight><br />
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.<br />
<br />
=== Vorbereiten des Raspberry Pi für ROT oder PIGATOR ===<br />
Der Raspberry Pi nutzt standardmäßig die serielle Schnittstelle als Terminal. Dies muss deaktiviert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo raspi-config<br />
5 Interfaceoption<br />
P6 Serial<br />
</syntaxhighlight><br />
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:<br />
<syntaxhighlight lang="bash"><br />
sudo usermod -aG dialout knxd<br />
</syntaxhighlight><br />
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<br />
<syntaxhighlight lang="bash"><br />
dtoverlay=disable-bt<br />
</syntaxhighlight><br />
am Ende eingefügt werden. Nun muss noch der Dienst hciuart deaktiviert werden (initialisiert das Bluetooth-Modem):<br />
<syntaxhighlight lang="bash"><br />
sudo systemctl disable hciuart<br />
</syntaxhighlight><br />
Nach einem anschließenden Reboot ist der TPUART unter ttyAMA0 ansprechbar.<br />
<br />
Nach dieser Prozedur ist natürlich die Benuzung des Bluetooth-Moduls nicht mehr möglich. Wer das Modul benötigt, findet die Anleitung hier:<br />
<br />
[[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]<br />
<br />
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].<br />
<br />
=== Andere BCU's (BusCouplerUnit) ===<br />
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.}}<br />
<br />
=== Installieren des knxd ===<br />
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.<br />
<br />
=== Konfiguration ===<br />
Die Konfiguration erfolgt wieder in der knxd.conf mit<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf<br />
</syntaxhighlight><br />
Nun die Konfiguarionszeile anpassen<br><br />
(serielle Schnittstelle)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b tpuarts:/dev/ttyAMA0"<br />
</syntaxhighlight><br />
(USB)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b tpuarts:/dev/knx"<br />
</syntaxhighlight><br />
Und dann noch<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
um knxd beim Systemstart sofort zu starten.<br />
<br />
-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 <br />
<syntaxhighlight lang="bash"><br />
define myKNXGW KNXIO T 127.0.0.1:6720 1.2.203<br />
</syntaxhighlight><br />
alternativ via Multicast: (siehe auch KNXIO-wiki):<syntaxhighlight lang="bash"><br />
define myKNXGW KNXIO M 224.0.23.12:3671 1.2.203<br />
</syntaxhighlight><br />
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.}}<br />
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)<br />
<syntaxhighlight lang="bash"><br />
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts<br />
"1" durch "0" ersetzen<br />
</syntaxhighlight><br />
Nach einem<br />
<syntaxhighlight lang="bash"><br />
sudo reboot<br />
</syntaxhighlight><br />
sollte der knxd dann laufen.<br />
{{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.}}<br />
<br />
== FAQ ==<br />
'''Wie wird eibd vorher deinstalliert?'''<br />
<syntaxhighlight lang="bash"><br />
sudo rm -r /usr/local/bin/{eibd,knxtool,group*} /usr/local/lib/lib{eib,pthsem}*.so* /usr/local/include/pth*<br />
</syntaxhighlight><br />
<br />
<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. <br />
<br />
'''folgender Fehler: dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install git-core build-essential<br />
</syntaxhighlight><br />
<br />
oder<br />
<br />
<syntaxhighlight lang="bash"><br />
in der datei knxd/debian/rules die Zeile:<br />
bash tools/test.sh auskommentieren<br />
</syntaxhighlight><br />
<br />
'''Fehler: dpkg-buildpackage: error: fakeroot not found, either install the fakeroot <....> '''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install fakeroot dpkg-dev<br />
</syntaxhighlight><br />
<br />
== Links ==<br />
* [[Benutzer:Marthinx]]<br />
* [https://github.com/knxd/knxd Github knxd]<br />
* [https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen Forums-Thread zu knxd. Sehr informativ.]<br />
<br />
[[Kategorie:Examples]]<br />
[[Kategorie:EIB/KNX]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=37923Einrichten der Bluetooth-Thermostate von eQ-32023-01-07T14:11:48Z<p>F Klee: Genaue Typbezeichnung hinzu gefügt</p>
<hr />
<div>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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth, die genau gleich aussehen. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
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:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
<br />
== Thermostat in FHEM definieren ==<br />
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:<br />
<pre>pi@raspberrypi ~ $ bluetoothctl<br />
[NEW] Controller 00:1A:7D:XX:XX:XX raspberrypi [default]<br />
[bluetooth]# scan on<br />
Discovery started<br />
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes<br />
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70<br />
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...<br />
[bluetooth]# scan off</pre><br />
Die Geräte tragen den Namen CC-RT-BLE.<br />
<br />
=== Einrichten mit Perl-Modul 10_EQ3BT ===<br />
Die eQ-3 Heizkörperthermostate können einfach über<br />
define <name> EQ3BT <mac address> <br />
eingebunden werden.<br />
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}<br />
<br />
=== Einrichten mit fhempy ===<br />
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.<br />
==== Installation auf FHEM-Server ====<br />
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.<br />
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit<br />
<br />
[Debian 11 (Bullseye)]<br />
<pre><br />
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><br />
<br />
[alle anderen]<br />
<pre><br />
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><br />
und als nächstes<br />
<pre><br />
sudo cpan Protocol::WebSocket</pre><br />
<br />
<br />
Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.<br />
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:<br />
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt<br />
update</pre><br />
Ist das Update abgeschlossen, können wir fhempy einrichten:<br />
<pre>define fhempy_local BindingsIo fhempy</pre><br />
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.<br />
<br />
Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit<br />
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre><br />
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.<br />
<br />
==== Installation des fhempy-Peer ====<br />
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.<br />
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}<br />
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi<br />
<pre>pip3 install --upgrade fhempy</pre><br />
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer<br />
<pre>fhempy</pre><br />
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.<br />
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird<br />
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre><br />
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.<br />
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden<br />
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre><br />
<br />
== Pairing ==<br />
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:<br />
<pre><br />
$ sudo bluetoothctl<br />
[bluetooth]# power on<br />
[bluetooth]# agent on<br />
[bluetooth]# default-agent<br />
[bluetooth]# scan on<br />
[bluetooth]# scan off<br />
[bluetooth]# pair 00:1A:22:06:A7:83<br />
[agent] Enter passkey (number in 0-999999): <enter pin><br />
[bluetooth]# trust 00:1A:22:06:A7:83<br />
[bluetooth]# disconnect 00:1A:22:06:A7:83<br />
[bluetooth]# exit<br />
<br />
Optional steps:<br />
[bluetooth]# devices - to list all bluetooth devices<br />
[bluetooth]# info 00:1A:22:06:A7:83<br />
Device 00:1A:22:06:A7:83 (public)<br />
Name: CC-RT-BLE<br />
Alias: CC-RT-BLE<br />
Paired: yes<br />
Trusted: yes<br />
Blocked: no<br />
Connected: no<br />
LegacyPairing: no<br />
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)<br />
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)<br />
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)<br />
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)<br />
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)<br />
ManufacturerData Key: 0x0000<br />
ManufacturerData Value:<br />
00 00 00 00 00 00 00 00 00 .........</pre><br />
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).<br />
<br />
== Bekannte Probleme ==<br />
=== Fehlermeldung nach fhempy-Installation ===<br />
Meldet pip3 folgendes<br />
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.<br />
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre><br />
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen<br />
<pre>export PATH=$PATH:/home/myname/.local/bin</pre><br />
also z.B.<br />
<pre>export PATH=$PATH:/home/pi/.local/bin</pre><br />
<br />
=== Keine Reaktion auf Einstellen der Offset-Temperatur ===<br />
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.<br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]<br />
[[Kategorie:Bluetooth]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Knxd&diff=37902Knxd2023-01-02T11:56:06Z<p>F Klee: Info zum Parameter -R hinzu gefügt</p>
<hr />
<div>== knxd mit einem IP Gateway einrichten ==<br />
Damit FHEM auf den KNX Bus zugreifen kann, wird ein passendes Interface benötigt. Es gibt:<br />
* RS232<br />
* USB<br />
* IP<br />
<br />
Im Folgenden wird die Einrichtung von knxd mit einem IP Gateway auf einem Raspberry Pi2 mit Wheezy oder Jessie beschrieben.<br />
<br />
=== Installation ===<br />
<br />
==== Für Debian Jessie: ====<br />
'''als erstes müssen folgende Pakete installiert werden (Referenz Debian Jessie):'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
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<br />
</syntaxhighlight><br />
<br />
'''knxd herunterladen und installieren'''<br />
Achtung: Wenn Abhängigkeiten fehlen, dann müssen diese nachinstalliert werden. Nicht einfach mittels "-d" diese übergehen!<br />
<syntaxhighlight lang="bash"><br />
git clone https://github.com/knxd/knxd.git<br />
cd knxd<br />
git checkout deb<br />
dpkg-buildpackage -b -uc<br />
cd ..<br />
sudo dpkg -i knxd_*.deb knxd-tools_*.deb<br />
</syntaxhighlight><br />
<br />
==== Ab Debian Stretch, Buster, ... ====<br />
'''knxd ist in den Debian packages vorhanden, muss daher nicht compiliert werden.'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install knxd knxd-tools<br />
<br />
</syntaxhighlight><br />
<br />
Mit der Konfiguration '''mit Systemd weitermachen!''' <br />
=== Konfiguration ===<br />
'''1. Ohne systemd'''<br />
<br />
Es muss als nächstes die Konfigurationsdatei editiert werden, das geht mit:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/default/knxd <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
DAEMON_ARGS="-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.188.XX"<br />
</syntaxhighlight><br />
und<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
<br />
'''2. Mit systemd z. B. für Debian Jessie'''<br />
<br />
Die Konfigurationsdatei bei Jessie hat sich wegen der Nutzung von systemd geändert:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b ipt:192.168.188.XX"<br />
<br />
</syntaxhighlight><br />
=== knxd Status überprüfen ===<br />
<syntaxhighlight lang="bash"><br />
/etc/init.d/knxd status<br />
</syntaxhighlight><br />
<br />
== knxd als IP-Gateway einrichten ==<br />
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.:<br />
* ROT<br />
* PIGATOR mit PIM-TPUART<br />
* TUL<br />
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.<br />
<br />
=== Vorbereiten des TUL ===<br />
==== TUL flashen ====<br />
Der TUL wird ohne Software geliefert und kann über den Raspberry Pi programmiert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install dfu-programmer<br />
wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54<br />
sudo dfu-programmer atmega32u4 erase<br />
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex<br />
sudo dfu-programmer atmega32u4 reset<br />
sudo reboot<br />
</syntaxhighlight><br />
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.<br />
Der TUL hat an der Unterseite einen winzigen Button. Dieser muss gedrückt werden, während der TUL in die USB-Buchse gesteckt wird.<br />
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.<br />
<br />
==== TUL einen dauerhaften Namen geben ====<br />
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<br />
<syntaxhighlight lang="bash"><br />
ls -la /dev/serial/by-id/<br />
</syntaxhighlight><br />
identifiziert. Das Ergebnis sollte ungefähr so aussehen<br />
<syntaxhighlight lang="bash"><br />
usb-busware.de_TPUART_8543934393935171B1C1-if00 -> ../../ttyACM0<br />
</syntaxhighlight><br />
Die Seriennummer (8543934393935171B1C1) wird später benötigt. Der Befehl<br />
<syntaxhighlight lang="bash"><br />
lsusb<br />
</syntaxhighlight><br />
sollte u.a. diese Zeile liefern<br />
<syntaxhighlight lang="bash"><br />
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project<br />
</syntaxhighlight><br />
03eb ist dabei die Herstellerkennung, 204b die Produktkennung. Nun muss die Datei /etc/udev/rules.d/99-usb-serial.rules<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/udev/rules.d/99-usb-serial.rules<br />
</syntaxhighlight><br />
erstellt oder erweitert werden mit der Zeile<br />
<syntaxhighlight lang="bash"><br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="8543934393935171B1C1", SYMLINK+="knx", OWNER="knxd"<br />
</syntaxhighlight><br />
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.<br />
<br />
=== Vorbereiten des Raspberry Pi für ROT oder PIGATOR ===<br />
Der Raspberry Pi nutzt standardmäßig die serielle Schnittstelle als Terminal. Dies muss deaktiviert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo raspi-config<br />
5 Interfaceoption<br />
P6 Serial<br />
</syntaxhighlight><br />
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:<br />
<syntaxhighlight lang="bash"><br />
sudo usermod -aG dialout knxd<br />
</syntaxhighlight><br />
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<br />
<syntaxhighlight lang="bash"><br />
dtoverlay=disable-bt<br />
</syntaxhighlight><br />
am Ende eingefügt werden. Nun muss noch der Dienst hciuart deaktiviert werden (initialisiert das Bluetooth-Modem):<br />
<syntaxhighlight lang="bash"><br />
sudo systemctl disable hciuart<br />
</syntaxhighlight><br />
Nach einem anschließenden Reboot ist der TPUART unter ttyAMA0 ansprechbar.<br />
<br />
Nach dieser Prozedur ist natürlich die Benuzung des Bluetooth-Moduls nicht mehr möglich. Wer das Modul benötigt, findet die Anleitung hier:<br />
<br />
[[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]<br />
<br />
=== Andere BCU's (BusCouplerUnit) ===<br />
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.}}<br />
<br />
=== Installieren des knxd ===<br />
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.<br />
<br />
=== Konfiguration ===<br />
Die Konfiguration erfolgt wieder in der knxd.conf mit<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf<br />
</syntaxhighlight><br />
Nun die Konfiguarionszeile anpassen<br><br />
(serielle Schnittstelle)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b tpuarts:/dev/ttyAMA0"<br />
</syntaxhighlight><br />
(USB)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b tpuarts:/dev/knx"<br />
</syntaxhighlight><br />
Und dann noch<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
um knxd beim Systemstart sofort zu starten.<br />
<br />
-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 <br />
<syntaxhighlight lang="bash"><br />
define myKNXGW KNXIO T 127.0.0.1:6720 1.2.203<br />
</syntaxhighlight><br />
alternativ via Multicast: (siehe auch KNXIO-wiki):<syntaxhighlight lang="bash"><br />
define myKNXGW KNXIO M 224.0.23.12:3671 1.2.203<br />
</syntaxhighlight><br />
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.}}<br />
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)<br />
<syntaxhighlight lang="bash"><br />
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts<br />
"1" durch "0" ersetzen<br />
</syntaxhighlight><br />
Nach einem<br />
<syntaxhighlight lang="bash"><br />
sudo reboot<br />
</syntaxhighlight><br />
sollte der knxd dann laufen.<br />
{{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.}}<br />
<br />
== FAQ ==<br />
'''Wie wird eibd vorher deinstalliert?'''<br />
<syntaxhighlight lang="bash"><br />
sudo rm -r /usr/local/bin/{eibd,knxtool,group*} /usr/local/lib/lib{eib,pthsem}*.so* /usr/local/include/pth*<br />
</syntaxhighlight><br />
<br />
<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. <br />
<br />
'''folgender Fehler: dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install git-core build-essential<br />
</syntaxhighlight><br />
<br />
oder<br />
<br />
<syntaxhighlight lang="bash"><br />
in der datei knxd/debian/rules die Zeile:<br />
bash tools/test.sh auskommentieren<br />
</syntaxhighlight><br />
<br />
'''Fehler: dpkg-buildpackage: error: fakeroot not found, either install the fakeroot <....> '''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install fakeroot dpkg-dev<br />
</syntaxhighlight><br />
<br />
== Links ==<br />
* [[Benutzer:Marthinx]]<br />
* [https://github.com/knxd/knxd Github knxd]<br />
* [https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen Forums-Thread zu knxd. Sehr informativ.]<br />
<br />
[[Kategorie:Examples]]<br />
[[Kategorie:EIB/KNX]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=37880Einrichten der Bluetooth-Thermostate von eQ-32022-12-28T16:50:53Z<p>F Klee: Keine Reaktion auf Einstellen der Offset-Temperatur hinzu gefügt</p>
<hr />
<div>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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
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:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
<br />
== Thermostat in FHEM definieren ==<br />
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:<br />
<pre>pi@raspberrypi ~ $ bluetoothctl<br />
[NEW] Controller 00:1A:7D:XX:XX:XX raspberrypi [default]<br />
[bluetooth]# scan on<br />
Discovery started<br />
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes<br />
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70<br />
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...<br />
[bluetooth]# scan off</pre><br />
Die Geräte tragen den Namen CC-RT-BLE.<br />
<br />
=== Einrichten mit Perl-Modul 10_EQ3BT ===<br />
Die eQ-3 Heizkörperthermostate können einfach über<br />
define <name> EQ3BT <mac address> <br />
eingebunden werden.<br />
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}<br />
<br />
=== Einrichten mit fhempy ===<br />
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.<br />
==== Installation auf FHEM-Server ====<br />
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.<br />
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit<br />
<br />
[Debian 11 (Bullseye)]<br />
<pre><br />
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><br />
<br />
[alle anderen]<br />
<pre><br />
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><br />
und als nächstes<br />
<pre><br />
sudo cpan Protocol::WebSocket</pre><br />
<br />
<br />
Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.<br />
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:<br />
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt<br />
update</pre><br />
Ist das Update abgeschlossen, können wir fhempy einrichten:<br />
<pre>define fhempy_local BindingsIo fhempy</pre><br />
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.<br />
<br />
Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit<br />
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre><br />
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.<br />
<br />
==== Installation des fhempy-Peer ====<br />
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.<br />
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}<br />
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi<br />
<pre>pip3 install --upgrade fhempy</pre><br />
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer<br />
<pre>fhempy</pre><br />
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.<br />
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird<br />
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre><br />
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.<br />
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden<br />
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre><br />
<br />
== Pairing ==<br />
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:<br />
<pre><br />
$ sudo bluetoothctl<br />
[bluetooth]# power on<br />
[bluetooth]# agent on<br />
[bluetooth]# default-agent<br />
[bluetooth]# scan on<br />
[bluetooth]# scan off<br />
[bluetooth]# pair 00:1A:22:06:A7:83<br />
[agent] Enter passkey (number in 0-999999): <enter pin><br />
[bluetooth]# trust 00:1A:22:06:A7:83<br />
[bluetooth]# disconnect 00:1A:22:06:A7:83<br />
[bluetooth]# exit<br />
<br />
Optional steps:<br />
[bluetooth]# devices - to list all bluetooth devices<br />
[bluetooth]# info 00:1A:22:06:A7:83<br />
Device 00:1A:22:06:A7:83 (public)<br />
Name: CC-RT-BLE<br />
Alias: CC-RT-BLE<br />
Paired: yes<br />
Trusted: yes<br />
Blocked: no<br />
Connected: no<br />
LegacyPairing: no<br />
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)<br />
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)<br />
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)<br />
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)<br />
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)<br />
ManufacturerData Key: 0x0000<br />
ManufacturerData Value:<br />
00 00 00 00 00 00 00 00 00 .........</pre><br />
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).<br />
<br />
== Bekannte Probleme ==<br />
=== Fehlermeldung nach fhempy-Installation ===<br />
Meldet pip3 folgendes<br />
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.<br />
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre><br />
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen<br />
<pre>export PATH=$PATH:/home/myname/.local/bin</pre><br />
also z.B.<br />
<pre>export PATH=$PATH:/home/pi/.local/bin</pre><br />
<br />
=== Keine Reaktion auf Einstellen der Offset-Temperatur ===<br />
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.<br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]<br />
[[Kategorie:Bluetooth]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=37874Einrichten der Bluetooth-Thermostate von eQ-32022-12-26T18:41:34Z<p>F Klee: Ermitteln der MAC-Adresse erweitert</p>
<hr />
<div>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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
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:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
<br />
== Thermostat in FHEM definieren ==<br />
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:<br />
<pre>pi@raspberrypi ~ $ bluetoothctl<br />
[NEW] Controller 00:1A:7D:XX:XX:XX raspberrypi [default]<br />
[bluetooth]# scan on<br />
Discovery started<br />
[CHG] Controller 00:1A:7D:XX:XX:XX Discovering: yes<br />
[NEW] Device 41:86:FB:XX:XX:XX 41-86-FB-...<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -56<br />
[NEW] Device 00:1A:22:XX:XX:XX CC-RT-BLE <== EQ3 Device, erkennbar an CC-RT-BLE<br />
[CHG] Device 41:86:FB:XX:XX:XX RSSI: -70<br />
[NEW] Device 5A:64:25:XX:XX:XX 5A-64-25-...<br />
[bluetooth]# scan off</pre><br />
Die Geräte tragen den Namen CC-RT-BLE.<br />
<br />
=== Einrichten mit Perl-Modul 10_EQ3BT ===<br />
Die eQ-3 Heizkörperthermostate können einfach über<br />
define <name> EQ3BT <mac address> <br />
eingebunden werden.<br />
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}<br />
<br />
=== Einrichten mit fhempy ===<br />
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.<br />
==== Installation auf FHEM-Server ====<br />
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.<br />
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit<br />
<br />
[Debian 11 (Bullseye)]<br />
<pre><br />
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><br />
<br />
[alle anderen]<br />
<pre><br />
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><br />
und als nächstes<br />
<pre><br />
sudo cpan Protocol::WebSocket</pre><br />
<br />
<br />
Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.<br />
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:<br />
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt<br />
update</pre><br />
Ist das Update abgeschlossen, können wir fhempy einrichten:<br />
<pre>define fhempy_local BindingsIo fhempy</pre><br />
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.<br />
<br />
Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit<br />
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre><br />
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.<br />
<br />
==== Installation des fhempy-Peer ====<br />
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.<br />
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}<br />
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi<br />
<pre>pip3 install --upgrade fhempy</pre><br />
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer<br />
<pre>fhempy</pre><br />
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.<br />
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird<br />
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre><br />
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.<br />
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden<br />
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre><br />
<br />
== Pairing ==<br />
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:<br />
<pre><br />
$ sudo bluetoothctl<br />
[bluetooth]# power on<br />
[bluetooth]# agent on<br />
[bluetooth]# default-agent<br />
[bluetooth]# scan on<br />
[bluetooth]# scan off<br />
[bluetooth]# pair 00:1A:22:06:A7:83<br />
[agent] Enter passkey (number in 0-999999): <enter pin><br />
[bluetooth]# trust 00:1A:22:06:A7:83<br />
[bluetooth]# disconnect 00:1A:22:06:A7:83<br />
[bluetooth]# exit<br />
<br />
Optional steps:<br />
[bluetooth]# devices - to list all bluetooth devices<br />
[bluetooth]# info 00:1A:22:06:A7:83<br />
Device 00:1A:22:06:A7:83 (public)<br />
Name: CC-RT-BLE<br />
Alias: CC-RT-BLE<br />
Paired: yes<br />
Trusted: yes<br />
Blocked: no<br />
Connected: no<br />
LegacyPairing: no<br />
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)<br />
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)<br />
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)<br />
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)<br />
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)<br />
ManufacturerData Key: 0x0000<br />
ManufacturerData Value:<br />
00 00 00 00 00 00 00 00 00 .........</pre><br />
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).<br />
<br />
== Bekannte Probleme ==<br />
=== Fehlermeldung nach fhempy-Installation ===<br />
Meldet pip3 folgendes<br />
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.<br />
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre><br />
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen<br />
<pre>export PATH=$PATH:/home/myname/.local/bin</pre><br />
also z.B.<br />
<pre>export PATH=$PATH:/home/pi/.local/bin</pre><br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]<br />
[[Kategorie:Bluetooth]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=37850Einrichten der Bluetooth-Thermostate von eQ-32022-12-25T13:07:47Z<p>F Klee: /* Installation des fhempy-Peer */</p>
<hr />
<div>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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
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:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
<br />
== Thermostat in FHEM definieren ==<br />
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:<br />
<pre>sudo bluetoothctl<br />
scan on</pre><br />
Die Geräte tragen den Namen CC-RT-BLE.<br />
<br />
=== Einrichten mit Perl-Modul 10_EQ3BT ===<br />
Die eQ-3 Heizkörperthermostate können einfach über<br />
define <name> EQ3BT <mac address> <br />
eingebunden werden.<br />
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}<br />
<br />
=== Einrichten mit fhempy ===<br />
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.<br />
==== Installation auf FHEM-Server ====<br />
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.<br />
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit<br />
<br />
[Debian 11 (Bullseye)]<br />
<pre><br />
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><br />
<br />
[alle anderen]<br />
<pre><br />
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><br />
und als nächstes<br />
<pre><br />
sudo cpan Protocol::WebSocket</pre><br />
<br />
<br />
Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.<br />
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:<br />
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt<br />
update</pre><br />
Ist das Update abgeschlossen, können wir fhempy einrichten:<br />
<pre>define fhempy_local BindingsIo fhempy</pre><br />
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.<br />
<br />
Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit<br />
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre><br />
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.<br />
<br />
==== Installation des fhempy-Peer ====<br />
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.<br />
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}<br />
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi<br />
<pre>pip3 install --upgrade fhempy</pre><br />
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer<br />
<pre>fhempy</pre><br />
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.<br />
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird<br />
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre><br />
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.<br />
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden<br />
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre><br />
<br />
== Pairing ==<br />
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:<br />
<pre><br />
$ sudo bluetoothctl<br />
[bluetooth]# power on<br />
[bluetooth]# agent on<br />
[bluetooth]# default-agent<br />
[bluetooth]# scan on<br />
[bluetooth]# scan off<br />
[bluetooth]# pair 00:1A:22:06:A7:83<br />
[agent] Enter passkey (number in 0-999999): <enter pin><br />
[bluetooth]# trust 00:1A:22:06:A7:83<br />
[bluetooth]# disconnect 00:1A:22:06:A7:83<br />
[bluetooth]# exit<br />
<br />
Optional steps:<br />
[bluetooth]# devices - to list all bluetooth devices<br />
[bluetooth]# info 00:1A:22:06:A7:83<br />
Device 00:1A:22:06:A7:83 (public)<br />
Name: CC-RT-BLE<br />
Alias: CC-RT-BLE<br />
Paired: yes<br />
Trusted: yes<br />
Blocked: no<br />
Connected: no<br />
LegacyPairing: no<br />
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)<br />
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)<br />
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)<br />
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)<br />
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)<br />
ManufacturerData Key: 0x0000<br />
ManufacturerData Value:<br />
00 00 00 00 00 00 00 00 00 .........</pre><br />
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).<br />
<br />
== Bekannte Probleme ==<br />
=== Fehlermeldung nach fhempy-Installation ===<br />
Meldet pip3 folgendes<br />
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.<br />
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre><br />
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen<br />
<pre>export PATH=$PATH:/home/myname/.local/bin</pre><br />
also z.B.<br />
<pre>export PATH=$PATH:/home/pi/.local/bin</pre><br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]<br />
[[Kategorie:Bluetooth]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=37849Einrichten der Bluetooth-Thermostate von eQ-32022-12-25T13:02:55Z<p>F Klee: /* Bluetooth einrichten */</p>
<hr />
<div>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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
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:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
<br />
== Thermostat in FHEM definieren ==<br />
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:<br />
<pre>sudo bluetoothctl<br />
scan on</pre><br />
Die Geräte tragen den Namen CC-RT-BLE.<br />
<br />
=== Einrichten mit Perl-Modul 10_EQ3BT ===<br />
Die eQ-3 Heizkörperthermostate können einfach über<br />
define <name> EQ3BT <mac address> <br />
eingebunden werden.<br />
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}<br />
<br />
=== Einrichten mit fhempy ===<br />
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.<br />
==== Installation auf FHEM-Server ====<br />
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.<br />
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit<br />
<br />
[Debian 11 (Bullseye)]<br />
<pre><br />
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><br />
<br />
[alle anderen]<br />
<pre><br />
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><br />
und als nächstes<br />
<pre><br />
sudo cpan Protocol::WebSocket</pre><br />
<br />
<br />
Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.<br />
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:<br />
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt<br />
update</pre><br />
Ist das Update abgeschlossen, können wir fhempy einrichten:<br />
<pre>define fhempy_local BindingsIo fhempy</pre><br />
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.<br />
<br />
Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit<br />
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre><br />
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.<br />
<br />
==== Installation des fhempy-Peer ====<br />
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.<br />
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}<br />
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi<br />
<pre>pip3 install --upgrade fhempy</pre><br />
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer<br />
<pre>fhempy</pre><br />
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.<br />
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird<br />
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre><br />
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.<br />
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden<br />
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre><br />
<br />
== Pairing ==<br />
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:<br />
<pre><br />
$ sudo bluetoothctl<br />
[bluetooth]# power on<br />
[bluetooth]# agent on<br />
[bluetooth]# default-agent<br />
[bluetooth]# scan on<br />
[bluetooth]# scan off<br />
[bluetooth]# pair 00:1A:22:06:A7:83<br />
[agent] Enter passkey (number in 0-999999): <enter pin><br />
[bluetooth]# trust 00:1A:22:06:A7:83<br />
[bluetooth]# disconnect 00:1A:22:06:A7:83<br />
[bluetooth]# exit<br />
<br />
Optional steps:<br />
[bluetooth]# devices - to list all bluetooth devices<br />
[bluetooth]# info 00:1A:22:06:A7:83<br />
Device 00:1A:22:06:A7:83 (public)<br />
Name: CC-RT-BLE<br />
Alias: CC-RT-BLE<br />
Paired: yes<br />
Trusted: yes<br />
Blocked: no<br />
Connected: no<br />
LegacyPairing: no<br />
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)<br />
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)<br />
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)<br />
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)<br />
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)<br />
ManufacturerData Key: 0x0000<br />
ManufacturerData Value:<br />
00 00 00 00 00 00 00 00 00 .........</pre><br />
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).<br />
<br />
== Bekannte Probleme ==<br />
=== Fehlermeldung nach fhempy-Installation ===<br />
Meldet pip3 folgendes<br />
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.<br />
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre><br />
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen<br />
<pre>export PATH=$PATH:/home/myname/.local/bin</pre><br />
also z.B.<br />
<pre>export PATH=$PATH:/home/pi/.local/bin</pre><br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]<br />
[[Kategorie:Bluetooth]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=37848Einrichten der Bluetooth-Thermostate von eQ-32022-12-25T12:56:10Z<p>F Klee: </p>
<hr />
<div>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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
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:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
<br />
== Thermostat in FHEM definieren ==<br />
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:<br />
<pre>sudo bluetoothctl<br />
scan on</pre><br />
Die Geräte tragen den Namen CC-RT-BLE.<br />
<br />
=== Einrichten mit Perl-Modul 10_EQ3BT ===<br />
Die eQ-3 Heizkörperthermostate können einfach über<br />
define <name> EQ3BT <mac address> <br />
eingebunden werden.<br />
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}<br />
<br />
=== Einrichten mit fhempy ===<br />
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.<br />
==== Installation auf FHEM-Server ====<br />
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.<br />
Nach dem obligatorischen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit<br />
<br />
[Debian 11 (Bullseye)]<br />
<pre><br />
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><br />
<br />
[alle anderen]<br />
<pre><br />
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><br />
und als nächstes<br />
<pre><br />
sudo cpan Protocol::WebSocket</pre><br />
<br />
<br />
Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.<br />
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:<br />
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt<br />
update</pre><br />
Ist das Update abgeschlossen, können wir fhempy einrichten:<br />
<pre>define fhempy_local BindingsIo fhempy</pre><br />
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.<br />
<br />
Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit<br />
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre><br />
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.<br />
<br />
==== Installation des fhempy-Peer ====<br />
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.<br />
{{Hinweis|WICHTIG!! Die folgenden Befehle dürfen nur auf dem Remote-RasPi und nicht auf der FHEM-Instanz ausgeführt werden.}}<br />
Zunächst müssen die benötigten Python-Pakete wie oben beschrieben installiert werden. Installiere nun fhempy als User pi<br />
<pre>pip3 install --upgrade fhempy</pre><br />
Überprüfe, ob die Hauptinstanz auf dem FHEM-Server läuft und starte dann fhempy als User pi auf dem Peer<br />
<pre>fhempy</pre><br />
Nach kurzer Zeit siehst du die ankommende FHEM-Verbindung.<br />
Nun noch die systemd-Konfiguration, damit fhempy automatisch gestartet wird<br />
<pre>curl -sL https://raw.githubusercontent.com/fhempy/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -</pre><br />
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.<br />
Der Peer sollte in FHEM automatisch erkannt werden (beruht auf Zeroconf). Sollte das nicht der Fall sein, kann der Peer auch manuell definiert werden<br />
<pre>define fhempy_peer_IP BindingsIo IP:15733 fhempy</pre><br />
<br />
== Pairing ==<br />
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:<br />
<pre><br />
$ sudo bluetoothctl<br />
[bluetooth]# power on<br />
[bluetooth]# agent on<br />
[bluetooth]# default-agent<br />
[bluetooth]# scan on<br />
[bluetooth]# scan off<br />
[bluetooth]# pair 00:1A:22:06:A7:83<br />
[agent] Enter passkey (number in 0-999999): <enter pin><br />
[bluetooth]# trust 00:1A:22:06:A7:83<br />
[bluetooth]# disconnect 00:1A:22:06:A7:83<br />
[bluetooth]# exit<br />
<br />
Optional steps:<br />
[bluetooth]# devices - to list all bluetooth devices<br />
[bluetooth]# info 00:1A:22:06:A7:83<br />
Device 00:1A:22:06:A7:83 (public)<br />
Name: CC-RT-BLE<br />
Alias: CC-RT-BLE<br />
Paired: yes<br />
Trusted: yes<br />
Blocked: no<br />
Connected: no<br />
LegacyPairing: no<br />
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)<br />
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)<br />
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)<br />
UUID: Vendor specific (3e135142-654f-9090-134a-a6ff5bb77046)<br />
UUID: Vendor specific (9e5d1e47-5c13-43a0-8635-82ad38a1386f)<br />
ManufacturerData Key: 0x0000<br />
ManufacturerData Value:<br />
00 00 00 00 00 00 00 00 00 .........</pre><br />
Dadurch ist das Thermostat nicht mehr mit der calor BT-App steuerbar (und umgekehrt).<br />
<br />
== Bekannte Probleme ==<br />
=== Fehlermeldung nach fhempy-Installation ===<br />
Meldet pip3 folgendes<br />
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.<br />
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre><br />
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen<br />
<pre>export PATH=$PATH:/home/myname/.local/bin</pre><br />
also z.B.<br />
<pre>export PATH=$PATH:/home/pi/.local/bin</pre><br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]<br />
[[Kategorie:Bluetooth]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=37847Einrichten der Bluetooth-Thermostate von eQ-32022-12-25T11:09:12Z<p>F Klee: </p>
<hr />
<div>{{Baustelle}} <br />
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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
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:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
<br />
== Thermostat in FHEM definieren ==<br />
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:<br />
<pre>sudo bluetoothctl<br />
scan on</pre><br />
Die Geräte tragen den Namen CC-RT-BLE.<br />
<br />
=== Einrichten mit Perl-Modul 10_EQ3BT ===<br />
Die eQ-3 Heizkörperthermostate können einfach über<br />
define <name> EQ3BT <mac address> <br />
eingebunden werden.<br />
{{Hinweis|Mittlerweile wird nur noch das fhempy-Modul empfohlen}}<br />
<br />
=== Einrichten mit fhempy ===<br />
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.<br />
==== Installation auf FHEM-Server ====<br />
Um die Heizkörperthermostate unter fhempy einzurichten, sind zunächst einige Vorarbeiten erforderlich. Das Einrichten geht dann genau so simpel.<br />
Nach dem üblichen <code>sudo apt-get update && sudo apt-get upgrade</code> werden die benötigten Python-Pakete mit<br />
<br />
[Debian 11 (Bullseye)]<br />
<pre><br />
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><br />
<br />
[alle anderen]<br />
<pre><br />
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><br />
und als nächstes<br />
<pre><br />
sudo cpan Protocol::WebSocket</pre><br />
<br />
<br />
Das dauert eine Weile. Ich empfehle eine Tasse koffeinhaltiges Heißgetränk.<br />
Ist die Installation abgeschlossen, geht es an die Konfiguration von FHEM. Zunächst laden wir per Update die benötigten Dateien herunter:<br />
<pre>update add https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt<br />
update</pre><br />
Ist das Update abgeschlossen, können wir fhempy einrichten:<br />
<pre>define fhempy_local BindingsIo fhempy</pre><br />
Es wird automatisch '''fhempyserver''' und '''fhempy_local''' eingerichtet. Auch hier gilt: nicht nervös werden, wenn fhempy_local nicht sofort ''connected'' anzeigt.<br />
<br />
Hiermit sind die Vorbereitungen abgeschlossen. Das Thermostat kann nun mit<br />
<pre>define <name> fhempy eq3bt <MAC-Adresse></pre><br />
eingebunden werden. Die benötigten Module werden automatisch nachgeladen.<br />
<br />
==== Installation Remote-Peer ====<br />
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.<br />
<br />
== Bekannte Probleme ==<br />
=== Fehlermeldung nach fhempy-Installation ===<br />
Meldet pip3 folgendes<br />
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.<br />
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre><br />
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen<br />
<pre>export PATH=$PATH:/home/myname/.local/bin</pre><br />
also z.B.<br />
<pre>export PATH=$PATH:/home/pi/.local/bin</pre><br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]<br />
[[Kategorie:Bluetooth]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=37846Einrichten der Bluetooth-Thermostate von eQ-32022-12-24T19:25:20Z<p>F Klee: </p>
<hr />
<div>{{Baustelle}} <br />
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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
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:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
<br />
== Thermostat in FHEM definieren ==<br />
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:<br />
<pre>sudo bluetoothctl<br />
scan on</pre><br />
Die Geräte tragen den Namen CC-RT-BLE.<br />
<br />
== Einrichten mit fhempy ==<br />
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.<br />
=== Installation auf FHEM-Server ===<br />
<br />
<br />
== Bekannte Probleme ==<br />
=== Fehlermeldung nach fhempy-Installation ===<br />
Meldet pip3 folgendes<br />
<pre> WARNING: The script normalizer is installed in '/home/myname/.local/bin' which is not on PATH.<br />
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.</pre><br />
so fehlt der Pfad zu fhempy und fhempy kann nicht aufgerufen werden. Es ist folgender Befehl aufzurufen<br />
<pre>export PATH=$PATH:/home/myname/.local/bin</pre><br />
also z.B.<br />
<pre>export PATH=$PATH:/home/pi/.local/bin</pre><br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]<br />
[[Kategorie:Bluetooth]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=37845Einrichten der Bluetooth-Thermostate von eQ-32022-12-24T19:00:47Z<p>F Klee: /* Bluetooth einrichten */</p>
<hr />
<div>{{Baustelle}} <br />
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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
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:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
<br />
== Thermostat in FHEM definieren ==<br />
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:<br />
<pre>sudo bluetoothctl<br />
scan on</pre><br />
Die Geräte tragen den Namen CC-RT-BLE.<br />
<br />
<br />
<br />
== Bekannte Probleme ==<br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=37844Einrichten der Bluetooth-Thermostate von eQ-32022-12-24T18:55:34Z<p>F Klee: </p>
<hr />
<div>{{Baustelle}} <br />
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).<br />
{{Randnotiz|RNText=Hinweis: Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.|RNTyp=Warn|style=}}<br />
== Bluetooth einrichten ==<br />
Standardmäßig sollte Bluetooth auf dem Raspberry Pi schon eingerichtet sein. Nutzt man einen B+ als Verlängerung, so müssen unter Umständen folgende Pakete installiert werden:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein <code>sudo reboot</code>. Ein <code>sudo service bluetooth status</code> sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
== Thermostat in FHEM definieren ==<br />
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:<br />
<pre>sudo bluetoothctl<br />
scan on</pre><br />
Die Geräte tragen den Namen CC-RT-BLE.<br />
<br />
<br />
<br />
== Bekannte Probleme ==<br />
<br />
== Links ==<br />
* [https://github.com/fhempy/fhempy fhempy-Projekt auf Github]<br />
* [https://github.com/rytilahti/python-eq3bt#pairing Pairing der Thermostate]<br />
* {{Link2Forum|Topic=60595|LinkText=Forums-Beitrag}}<br />
<br />
[[Kategorie:Heizungsventile]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Einrichten_der_Bluetooth-Thermostate_von_eQ-3&diff=37843Einrichten der Bluetooth-Thermostate von eQ-32022-12-24T17:58:35Z<p>F Klee: Seite erstellt</p>
<hr />
<div>{{Baustelle}} <br />
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).<br />
ACHTUNG! Es gibt auch Versionen ohne Bluetooth. Bei der Bestellung bitte aufpassen.<br />
== Bluetooth einrichten ==<br />
Standardmäßig sollte Bluetooth auf dem Raspberry Pi schon eingerichtet sein. Nutzt man einen B+ als Verlängerung, so müssen unter Umständen folgende Pakete installiert werden:<br />
<pre>sudo apt-get install bluetooth, bluez</pre><br />
Danach ein<br />
<pre>sudo reboot</pre><br />
Ein<br />
<pre>sudo service bluetooth status</pre><br />
sollte zeigen, dass der Daemon läuft.<br />
Damit der user fhem bzw. pi auf bluetooth zugreifen kann, muss in bluetooth.conf noch folgendes eingetragen werden:<br />
<pre>sudo nano /etc/dbus-1/system.d/bluetooth.conf</pre><br />
<br />
<pre><policy user="fhem"><br />
<allow own="org.bluez"/><br />
<allow send_destination="org.bluez"/><br />
<allow send_interface="org.bluez.GattCharacteristic1"/><br />
<allow send_interface="org.bluez.GattDescriptor1"/><br />
<allow send_interface="org.freedesktop.DBus.ObjectManager"/><br />
<allow send_interface="org.freedesktop.DBus.Properties"/><br />
</policy></pre><br />
<pre>sudo systemctl restart dbus</pre><br />
Für den User pi muss natürlich fhem durch pi ersetzt werden.<br />
== Thermostat in FHEM definieren ==<br />
Bevor das Thermostat in FHEM eingebunden werden kann, muss die MAC-Adresse ermittelt werden:<br />
<pre>sudo bluetoothctl<br />
scan on</pre><br />
Die Geräte tragen den Namen CC-RT-BLE.</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Knxd&diff=37512Knxd2022-08-01T11:35:10Z<p>F Klee: /* Vorbereiten des Raspberry Pi für ROT oder PIGATOR */</p>
<hr />
<div>== knxd mit einem IP Gateway einrichten ==<br />
Damit FHEM auf den KNX Bus zugreifen kann, wird ein passendes Interface benötigt. Es gibt:<br />
* RS232<br />
* USB<br />
* IP<br />
<br />
Im Folgenden wird die Einrichtung von knxd mit einem IP Gateway auf einem Raspberry Pi2 mit Wheezy oder Jessie beschrieben.<br />
<br />
=== Installation ===<br />
<br />
==== Für Debian Jessie: ====<br />
'''als erstes müssen folgende Pakete installiert werden (Referenz Debian Jessie):'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
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<br />
</syntaxhighlight><br />
<br />
'''knxd herunterladen und installieren'''<br />
Achtung: Wenn Abhängigkeiten fehlen, dann müssen diese nachinstalliert werden. Nicht einfach mittels "-d" diese übergehen!<br />
<syntaxhighlight lang="bash"><br />
git clone https://github.com/knxd/knxd.git<br />
cd knxd<br />
git checkout deb<br />
dpkg-buildpackage -b -uc<br />
cd ..<br />
sudo dpkg -i knxd_*.deb knxd-tools_*.deb<br />
</syntaxhighlight><br />
<br />
==== Ab Debian Stretch, Buster, ... ====<br />
'''knxd ist in den Debian packages vorhanden, muss daher nicht compiliert werden.'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install knxd knxd-tools<br />
<br />
</syntaxhighlight><br />
<br />
Mit der Konfiguration '''mit Systemd weitermachen!''' <br />
=== Konfiguration ===<br />
'''1. Ohne systemd'''<br />
<br />
Es muss als nächstes die Konfigurationsdatei editiert werden, das geht mit:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/default/knxd <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
DAEMON_ARGS="-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.188.XX"<br />
</syntaxhighlight><br />
und<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
<br />
'''2. Mit systemd z. B. für Debian Jessie'''<br />
<br />
Die Konfigurationsdatei bei Jessie hat sich wegen der Nutzung von systemd geändert:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b ipt:192.168.188.XX"<br />
<br />
</syntaxhighlight><br />
=== knxd Status überprüfen ===<br />
<syntaxhighlight lang="bash"><br />
/etc/init.d/knxd status<br />
</syntaxhighlight><br />
<br />
== knxd als IP-Gateway einrichten ==<br />
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.:<br />
* ROT<br />
* PIGATOR mit PIM-TPUART<br />
* TUL<br />
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.<br />
<br />
=== Vorbereiten des TUL ===<br />
==== TUL flashen ====<br />
Der TUL wird ohne Software geliefert und kann über den Raspberry Pi programmiert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install dfu-programmer<br />
wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54<br />
sudo dfu-programmer atmega32u4 erase<br />
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex<br />
sudo dfu-programmer atmega32u4 reset<br />
sudo reboot<br />
</syntaxhighlight><br />
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.<br />
Der TUL hat an der Unterseite einen winzigen Button. Dieser muss gedrückt werden, während der TUL in die USB-Buchse gesteckt wird.<br />
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.<br />
<br />
==== TUL einen dauerhaften Namen geben ====<br />
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<br />
<syntaxhighlight lang="bash"><br />
ls -la /dev/serial/by-id/<br />
</syntaxhighlight><br />
identifiziert. Das Ergebnis sollte ungefähr so aussehen<br />
<syntaxhighlight lang="bash"><br />
usb-busware.de_TPUART_8543934393935171B1C1-if00 -> ../../ttyACM0<br />
</syntaxhighlight><br />
Die Seriennummer (8543934393935171B1C1) wird später benötigt. Der Befehl<br />
<syntaxhighlight lang="bash"><br />
lsusb<br />
</syntaxhighlight><br />
sollte u.a. diese Zeile liefern<br />
<syntaxhighlight lang="bash"><br />
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project<br />
</syntaxhighlight><br />
03eb ist dabei die Herstellerkennung, 204b die Produktkennung. Nun muss die Datei /etc/udev/rules.d/99-usb-serial.rules<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/udev/rules.d/99-usb-serial.rules<br />
</syntaxhighlight><br />
erstellt oder erweitert werden mit der Zeile<br />
<syntaxhighlight lang="bash"><br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="8543934393935171B1C1", SYMLINK+="knx", OWNER="knxd"<br />
</syntaxhighlight><br />
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.<br />
<br />
=== Vorbereiten des Raspberry Pi für ROT oder PIGATOR ===<br />
Der Raspberry Pi nutzt standardmäßig die serielle Schnittstelle als Terminal. Dies muss deaktiviert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo raspi-config<br />
5 Interfaceoption<br />
P6 Serial<br />
</syntaxhighlight><br />
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:<br />
<syntaxhighlight lang="bash"><br />
sudo usermod -aG dialout knxd<br />
</syntaxhighlight><br />
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<br />
<syntaxhighlight lang="bash"><br />
dtoverlay=disable-bt<br />
</syntaxhighlight><br />
am Ende eingefügt werden. Nun muss noch der Dienst hciuart deaktiviert werden (initialisiert das Bluetooth-Modem):<br />
<syntaxhighlight lang="bash"><br />
sudo systemctl disable hciuart<br />
</syntaxhighlight><br />
Nach einem anschließenden Reboot ist der TPUART unter ttyAMA0 ansprechbar.<br />
<br />
Nach dieser Prozedur ist natürlich die Benuzung des Bluetooth-Moduls nicht mehr möglich. Wer das Modul benötigt, findet die Anleitung hier:<br />
<br />
[[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]<br />
<br />
=== Andere BCU's (BusCouplerUnit) ===<br />
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.}}<br />
<br />
=== Installieren des knxd ===<br />
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.<br />
<br />
=== Konfiguration ===<br />
Die Konfiguration erfolgt wieder in der knxd.conf mit<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf<br />
</syntaxhighlight><br />
Nun die Konfiguarionszeile anpassen<br><br />
(serielle Schnittstelle)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/ttyAMA0"<br />
</syntaxhighlight><br />
(USB)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/knx"<br />
</syntaxhighlight><br />
Und dann noch<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
um knxd beim Systemstart sofort zu starten.<br />
<br />
-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 <br />
<syntaxhighlight lang="bash"><br />
define KNX TUL eibd:127.0.0.1 1.2.203<br />
</syntaxhighlight><br />
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.}}<br />
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)<br />
<syntaxhighlight lang="bash"><br />
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts<br />
"1" durch "0" ersetzen<br />
</syntaxhighlight><br />
Nach einem<br />
<syntaxhighlight lang="bash"><br />
sudo reboot<br />
</syntaxhighlight><br />
sollte der knxd dann laufen.<br />
<br />
== FAQ ==<br />
'''Wie wird eibd vorher deinstalliert?'''<br />
<syntaxhighlight lang="bash"><br />
sudo rm -r /usr/local/bin/{eibd,knxtool,group*} /usr/local/lib/lib{eib,pthsem}*.so* /usr/local/include/pth*<br />
</syntaxhighlight><br />
<br />
<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. <br />
<br />
'''folgender Fehler: dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install git-core build-essential<br />
</syntaxhighlight><br />
<br />
oder<br />
<br />
<syntaxhighlight lang="bash"><br />
in der datei knxd/debian/rules die Zeile:<br />
bash tools/test.sh auskommentieren<br />
</syntaxhighlight><br />
<br />
'''Fehler: dpkg-buildpackage: error: fakeroot not found, either install the fakeroot <....> '''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install fakeroot dpkg-dev<br />
</syntaxhighlight><br />
<br />
== Links ==<br />
* [[Benutzer:Marthinx]]<br />
* [https://github.com/knxd/knxd Github knxd]<br />
* [https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen Forums-Thread zu knxd. Sehr informativ.]<br />
<br />
[[Kategorie:Examples]]<br />
[[Kategorie:EIB/KNX]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Sonnenspeicher&diff=37507Sonnenspeicher2022-07-19T09:40:54Z<p>F Klee: /* Statusabfrage API-V2 mit Token */</p>
<hr />
<div>== Hinweise zur Einbindung des Speichersystems von sonnen (https://sonnen.de/stromspeicher/) per HTTPMOD ==<br />
<br />
Der Batteriespeicher von sonnen besitzt ein API. Auch ohne den Token lässt sich der Status abfragen.<br />
<br />
=== Statusabfrage API-V1 ===<br />
<pre><br />
define sonnenbatterie HTTPMOD http://x.x.x.x:8080/api/v1/status 60<br />
attr sonnenbatterie extractAllJSON 1<br />
attr sonnenbatterie stateFormat {sprintf("Verbrauch %d W: %d W aus PV + %d W %s Speicher + %d W %s Grid, SOC %d%%", <br />
ReadingsVal($name,"Consumption_W",0),<br />
ReadingsVal($name,"Production_W",0),<br />
abs(ReadingsVal($name,"Pac_total_W",0)),<br />
ReadingsVal($name,"FlowConsumptionBattery",1) !=0 ? "aus" : "in",<br />
abs(ReadingsVal($name,"GridFeedIn_W",0)),<br />
ReadingsVal($name,"FlowConsumptionGrid",1) !=0 ? "aus" : "in",<br />
ReadingsVal($name,"RSOC","-1")<br />
)}<br />
</pre><br />
<br />
=== Statusabfrage API-V2 ===<br />
Die Statusabfrage mit API-V2 arbeitet grundsätzlich genau so wie bei V1, nur der Aufruf hat sich ein wenig geändert:<br />
define sonnenbatterie HTTPMOD <nowiki>http://x.x.x.x/api/v2/status</nowiki> 60<br />
<br />
=== Statusabfrage API-V2 mit Token ===<br />
Weitere Informationen lassen sich über die API-Funktion "latestdata" abrufen. Das geht aber nur mit einem Token, den ihr im Dashboard unter Softwareintegration findet. Hier ein Beispiel, um den Zustand der Eclipse darzustellen:<br />
<pre><br />
define solar_status HTTPMOD http://192.168.x.xxx:80/api/v2/latestdata 900<br />
<br />
attr solar_status alias sonnenBatterie Zustand<br />
attr solar_status devStateIcon 1000:sonnen_icon@green 0100:sonnen_icon@orange 0010:sonnen_icon@white 0001:sonnen_icon@red<br />
attr solar_status enableControlSet 1<br />
attr solar_status extractAllJSON 1<br />
attr solar_status get01Header01 Auth-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx<br />
attr solar_status get01Name LatestData<br />
attr solar_status get01URL http://192.168.x.xxx:80/api/v2/latestdata<br />
attr solar_status group Strom<br />
attr solar_status httpVersion 1.1<br />
attr solar_status icon sonnen_logo<br />
attr solar_status requestHeader01 Auth-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx<br />
attr solar_status room Solar<br />
attr solar_status showError 1<br />
attr solar_status stateFormat {sprintf("%d%d%d%d", ReadingsVal($name,"ic_status_Eclipse_Led_Pulsing_Green",0), ReadingsVal($name,"ic_status_Eclipse_Led_Pulsing_Orange",0), ReadingsVal($name,"ic_status_Eclipse_Led_Pulsing_White",0), ReadingsVal($name,"ic_status_Eclipse_Led_Solid_Red",0))}<br />
</pre><br />
Die Icon findet ihr im [https://forum.fhem.de/index.php?topic=118416.0 Forum] incl. weiterer Informationen. Das Dashboard enthält eine Kurzanleitung des API. Der User-Zugang muss über das Initialpasswort auf dem Typenschild aktiviert werden. Vor dem Einbau evtl. abfotografieren ;)<br />
<br />
[[Kategorie:Examples]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Sonnenspeicher&diff=37506Sonnenspeicher2022-07-19T09:37:49Z<p>F Klee: /* Hinweise zur Einbindung des Speichersystems von sonnen (https://sonnen.de/stromspeicher/) per HTTPMOD */</p>
<hr />
<div>== Hinweise zur Einbindung des Speichersystems von sonnen (https://sonnen.de/stromspeicher/) per HTTPMOD ==<br />
<br />
Der Batteriespeicher von sonnen besitzt ein API. Auch ohne den Token lässt sich der Status abfragen.<br />
<br />
=== Statusabfrage API-V1 ===<br />
<pre><br />
define sonnenbatterie HTTPMOD http://x.x.x.x:8080/api/v1/status 60<br />
attr sonnenbatterie extractAllJSON 1<br />
attr sonnenbatterie stateFormat {sprintf("Verbrauch %d W: %d W aus PV + %d W %s Speicher + %d W %s Grid, SOC %d%%", <br />
ReadingsVal($name,"Consumption_W",0),<br />
ReadingsVal($name,"Production_W",0),<br />
abs(ReadingsVal($name,"Pac_total_W",0)),<br />
ReadingsVal($name,"FlowConsumptionBattery",1) !=0 ? "aus" : "in",<br />
abs(ReadingsVal($name,"GridFeedIn_W",0)),<br />
ReadingsVal($name,"FlowConsumptionGrid",1) !=0 ? "aus" : "in",<br />
ReadingsVal($name,"RSOC","-1")<br />
)}<br />
</pre><br />
<br />
=== Statusabfrage API-V2 ===<br />
Die Statusabfrage mit API-V2 arbeitet grundsätzlich genau so wie bei V1, nur der Aufruf hat sich ein wenig geändert:<br />
define sonnenbatterie HTTPMOD <nowiki>http://x.x.x.x/api/v2/status</nowiki> 60<br />
<br />
=== Statusabfrage API-V2 mit Token ===<br />
Weitere Informationen lassen sich über die API-Funktion "latestdata" abrufen. Das geht aber nur mit einem Token, den ihr im Dashboard unter Softwareintegration findet. Hier ein Beispiel, um den Zustand der Eclipse darzustellen:<br />
<pre><br />
define solar_status HTTPMOD http://192.168.x.xxx:80/api/v2/latestdata 900<br />
<br />
attr solar_status alias sonnenBatterie Zustand<br />
attr solar_status devStateIcon 1000:sonnen_icon@green 0100:sonnen_icon@orange 0010:sonnen_icon@white 0001:sonnen_icon@red<br />
attr solar_status enableControlSet 1<br />
attr solar_status extractAllJSON 1<br />
attr solar_status get01Header01 Auth-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx<br />
attr solar_status get01Name LatestData<br />
attr solar_status get01URL http://192.168.x.xxx:80/api/v2/latestdata<br />
attr solar_status group Strom<br />
attr solar_status httpVersion 1.1<br />
attr solar_status icon sonnen_logo<br />
attr solar_status requestHeader01 Auth-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx<br />
attr solar_status room Solar<br />
attr solar_status showError 1<br />
attr solar_status stateFormat {sprintf("%d%d%d%d", ReadingsVal($name,"ic_status_Eclipse_Led_Pulsing_Green",0), ReadingsVal($name,"ic_status_Eclipse_Led_Pulsing_Orange",0), ReadingsVal($name,"ic_status_Eclipse_Led_Pulsing_White",0), ReadingsVal($name,"ic_status_Eclipse_Led_Solid_Red",0))}<br />
</pre><br />
Die Icon findet ihr im Forum incl. weiterer Informationen. Das Dashboard enthält eine Kurzanleitung des API. Der User-Zugang muss über das Initialpasswort auf dem Typenschild aktiviert werden. Vor dem Einbau evtl. abfotografieren ;)<br />
<br />
[[Kategorie:Examples]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Sonnenspeicher&diff=37487Sonnenspeicher2022-07-04T05:05:35Z<p>F Klee: /* Hinweise zur Einbindung des Speichersystems von sonnen (https://sonnen.de/stromspeicher/) per HTTPMOD */</p>
<hr />
<div>== Hinweise zur Einbindung des Speichersystems von sonnen (https://sonnen.de/stromspeicher/) per HTTPMOD ==<br />
<br />
Der Batteriespeicher von sonnen besitzt ein API. Auch ohne den Token lässt sich der Status abfragen.<br />
<br />
=== Statusabfrage API-V1 ===<br />
<pre><br />
define sonnenbatterie HTTPMOD http://x.x.x.x:8080/api/v1/status 60<br />
attr sonnenbatterie extractAllJSON 1<br />
attr sonnenbatterie stateFormat {sprintf("Verbrauch %d W: %d W aus PV + %d W %s Speicher + %d W %s Grid, SOC %d%%", <br />
ReadingsVal($name,"Consumption_W",0),<br />
ReadingsVal($name,"Production_W",0),<br />
abs(ReadingsVal($name,"Pac_total_W",0)),<br />
ReadingsVal($name,"FlowConsumptionBattery",1) !=0 ? "aus" : "in",<br />
abs(ReadingsVal($name,"GridFeedIn_W",0)),<br />
ReadingsVal($name,"FlowConsumptionGrid",1) !=0 ? "aus" : "in",<br />
ReadingsVal($name,"RSOC","-1")<br />
)}<br />
</pre><br />
<br />
=== Statusabfrage API-V2 ===<br />
Die Statusabfrage mit API-V2 arbeitet grundsätzlich genau so wie bei V1, nur der Aufruf hat sich ein wenig geändert:<br />
define sonnenbatterie HTTPMOD <nowiki>http://x.x.x.x/api/v2/status</nowiki> 60<br />
[[Kategorie:Examples]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Webserver_auf_Raspberry&diff=37335Webserver auf Raspberry2022-03-20T10:36:29Z<p>F Klee: </p>
<hr />
<div>Auf Raspberry-Systemen benötigt man oft einen Webserver. Zwar gibt es bereits Lösungen wie Apache2 oder Nginx, allerdings sind diese rechenzeit- und speicherintensiv. Oft wird auf kleinen Systemen wie dem RaspberryPi Zero eine Lösung gesucht, die ohne viel Ressourcen beispielsweise nur den Inhalt einer Datei via http ausliefert. Da bietet sich Gatling von Fefe an; diese Lösung soll hier vorgestellt werden.<br />
<br />
==Installation==<br />
<syntaxhighlight lang="bash"><br />
apt install gatling<br />
</syntaxhighlight><br />
<br />
Es muss sodann /lib/systemd/system/gatling.service erstellt werden:<br />
<syntaxhighlight lang="html"><br />
#!/bin/sh<br />
<br />
[Unit]<br />
Description=Control gatling webserver<br />
After=network.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/gatling -u www-data -V -F -S -D -c /var/www/<br />
ExecReload=/bin/kill $MAINPID && /usr/bin/gatling -u www-data -V -F -S -D -c /var/www/<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</syntaxhighlight><br />
<br />
Danach muss diese Datei noch verlinkt werden:<br />
<syntaxhighlight lang="bash"><br />
cd /etc/systemd/system/multi-user.target.wants/<br />
ln -s /lib/systemd/system/gatling.service gatling.service<br />
</syntaxhighlight><br />
<br />
In /etc/default/gatling müssen die Kommentarzeichen vor den Zeilen<br />
<syntaxhighlight lang="bash"><br />
START_DAEMON="YES"<br />
DAEMON="gatling"<br />
</syntaxhighlight><br />
entfernt werden.<br />
<br />
Und nun starten:<br />
<syntaxhighlight lang="bash"><br />
# systemctl unmask gatling<br />
# systemctl restart gatling<br />
# systemctl enable gatling<br />
</syntaxhighlight><br />
<br />
(Der Autor hat Zugriffsrechte nicht geprüft. Idealerweise sollten nun Dateien aus /var/www/ ausgeliefert werden.)<br />
<br />
==Alternativen==<br />
Im Forum wurden in {{Link2Forum|Topic=98295|LinkText=diesem Thread}} eine Vielzahl an Alternativen für kleine, leichtgewichtige Webserver genannt. Insbesondere sei auf die Listen unter https://gist.github.com/willurd/5720255 sowie https://www.pcsuggest.com/best-lightweight-web-server-linux/ verwiesen.<br />
<br />
[[Kategorie:Raspberry Pi]]<br />
[[Kategorie:HOWTOS]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=CALVIEW&diff=37214CALVIEW2022-02-11T18:11:28Z<p>F Klee: /* Attribute */</p>
<hr />
<div>{{Todo|Dieser Artikel ist veraltet. Insbesondere stimmt die Definition (define) nicht mit der derzeit gültigen (siehe commandref) überein. Mitautoren gesucht! Dieser Artikel muss dringend überarbeitet werden!}}<br />
<br />
{{Infobox Modul<br />
|ModPurpose=Legt ein Device an, das alle Termine aus einem [[Calendar]] als Reading anzeigt.<br />
|ModType=d<br />
|ModFTopic=19922<br />
|ModForumArea=Unterstützende Dienste/Kalendermodule<br />
|ModTechName=57_CALVIEW.pm<br />
|ModOwner=Christian / {{Link2FU|5217|Chris1284}}<br />
}}<br />
<br />
[[CALVIEW]] ist ein Hilfsmodul, das alle Termine aus einem bestehenden Kalender des Moduls [[Calendar]] in Readings übernimmt. <br />
<br />
== Voraussetzungen ==<br />
Es muss ein [[Calendar]]-Objekt definiert sein. Der dabei benutzte Name muss in der Definition des CALVIEW-Objekts spezifiziert werden.<br />
<br />
== Anwendung ==<br />
=== Define ===<br />
:<code>define <Name> CALVIEW <calendarname>[,<calendarname2>,...] <modus> [<updateintervall>]</code><br />
<br />
Erläuterung der Parameter im '''define''':<br />
;<calendarname> <br />
:Name des '''Calendar''' Kalenders. Mehrere '''Calendar'''-Namen durch Komma getrennt. <br />
;<modus><br />
:'''0'''&nbsp;&nbsp;für "modeStarted" Termine <br />'''1'''&nbsp;&nbsp;für "modeStarted";"modeUpcoming" Termine <br />'''2'''&nbsp;&nbsp;für "all" Termine<br />
<br />
;<updateintervall><br />
:Updateintervall in sec (default 43200). Nicht erforderlich, da ein Calendar-Update ein Calview-Update triggert.<br />
Beispiel:<br />
:<code>define myCalView CALVIEW Googlecalendar 1</code><br />
<br />
=== Werte aktualisieren ===<br />
[[datei:CALVIEW_Readingsgroup.png|mini|400px|CALVIEW in einer [[ReadingsGroup]] ]]<br />
:<code>set <Name> update</code><br />
Beispiel:<br />
:<code>set myCalView update</code><br />
<br />
=== Aktualisierungsintervall festlegen ===<br />
:<del><code><nowiki>set <Name> intervall <time></nowiki></code></del><br />
<br />
Das Aktualisierungsintervall wird (in den neueren Versionen - ab Mai 2015 - des Moduls) nur noch über das DEF verändert.<br />
<br />
=== Weitere Attribute ===Internet of Things.<br />
<br />
=== Attribute ===<br />
;maxreadings<br />
:Anzahl der angezeigten Termine festlegen<br />
Beispiel:<br />
:<code>attr myCalView maxreadings 10</code><br />
;sourcecolor<br />
:Hiermit können die Farben der einzelnen Kalender definiert werden. Diese können dann z.B. im Tablet UI Calview-Widget genutzt werden.<br />
Beispiel:<br />
:<code>attr myCalView sourcecolor Kalender1:green,Kalender2:yellow</code><br />
<br />
== Anwendungsbeispiel(e) ==<br />
<pre><br />
define kalenderTermine readingsGroup <%time_calendar>,<Text>,<Zuletzt erfasst> myView<br />
attr kalenderTermine alias Termine<br />
attr kalenderTermine group _KalenderView_<br />
attr kalenderTermine mapping %READING<br />
attr kalenderTermine room Kalender<br />
</pre><br />
<br />
== Links ==<br />
* Ein komplettes Beispiel ist im ersten Beitrag {{Link2Forum|Topic=19922|LinkText=dieser Diskussion}} im FHEM Forum enthalten</div>F Kleehttp://wiki.fhem.de/w/index.php?title=CALVIEW&diff=37213CALVIEW2022-02-11T18:08:54Z<p>F Klee: Attribut sourcecolor hinzu gefügt</p>
<hr />
<div>{{Todo|Dieser Artikel ist veraltet. Insbesondere stimmt die Definition (define) nicht mit der derzeit gültigen (siehe commandref) überein. Mitautoren gesucht! Dieser Artikel muss dringend überarbeitet werden!}}<br />
<br />
{{Infobox Modul<br />
|ModPurpose=Legt ein Device an, das alle Termine aus einem [[Calendar]] als Reading anzeigt.<br />
|ModType=d<br />
|ModFTopic=19922<br />
|ModForumArea=Unterstützende Dienste/Kalendermodule<br />
|ModTechName=57_CALVIEW.pm<br />
|ModOwner=Christian / {{Link2FU|5217|Chris1284}}<br />
}}<br />
<br />
[[CALVIEW]] ist ein Hilfsmodul, das alle Termine aus einem bestehenden Kalender des Moduls [[Calendar]] in Readings übernimmt. <br />
<br />
== Voraussetzungen ==<br />
Es muss ein [[Calendar]]-Objekt definiert sein. Der dabei benutzte Name muss in der Definition des CALVIEW-Objekts spezifiziert werden.<br />
<br />
== Anwendung ==<br />
=== Define ===<br />
:<code>define <Name> CALVIEW <calendarname>[,<calendarname2>,...] <modus> [<updateintervall>]</code><br />
<br />
Erläuterung der Parameter im '''define''':<br />
;<calendarname> <br />
:Name des '''Calendar''' Kalenders. Mehrere '''Calendar'''-Namen durch Komma getrennt. <br />
;<modus><br />
:'''0'''&nbsp;&nbsp;für "modeStarted" Termine <br />'''1'''&nbsp;&nbsp;für "modeStarted";"modeUpcoming" Termine <br />'''2'''&nbsp;&nbsp;für "all" Termine<br />
<br />
;<updateintervall><br />
:Updateintervall in sec (default 43200). Nicht erforderlich, da ein Calendar-Update ein Calview-Update triggert.<br />
Beispiel:<br />
:<code>define myCalView CALVIEW Googlecalendar 1</code><br />
<br />
=== Werte aktualisieren ===<br />
[[datei:CALVIEW_Readingsgroup.png|mini|400px|CALVIEW in einer [[ReadingsGroup]] ]]<br />
:<code>set <Name> update</code><br />
Beispiel:<br />
:<code>set myCalView update</code><br />
<br />
=== Aktualisierungsintervall festlegen ===<br />
:<del><code><nowiki>set <Name> intervall <time></nowiki></code></del><br />
<br />
Das Aktualisierungsintervall wird (in den neueren Versionen - ab Mai 2015 - des Moduls) nur noch über das DEF verändert.<br />
<br />
=== Weitere Attribute ===Internet of Things.<br />
<br />
=== Attribute ===<br />
;maxreadings<br />
:Anzahl der angezeigten Termine festlegen<br />
Beispiel:<br />
:<code>attr myCalView maxreadings 10</code><br />
'''sourcecolor'''<br />
<br />
Hiermit können die Farben der einzelnen Kalender definiert werden. Diese können dann z.B. im Tablet UI Calview-Widget genutzt werden.<br />
<br />
Beispiel:<br />
<br />
<code>attr myCalView sourcecolor Kalender1:green,Kalender2:yellow</code><br />
<br />
== Anwendungsbeispiel(e) ==<br />
<pre><br />
define kalenderTermine readingsGroup <%time_calendar>,<Text>,<Zuletzt erfasst> myView<br />
attr kalenderTermine alias Termine<br />
attr kalenderTermine group _KalenderView_<br />
attr kalenderTermine mapping %READING<br />
attr kalenderTermine room Kalender<br />
</pre><br />
<br />
== Links ==<br />
* Ein komplettes Beispiel ist im ersten Beitrag {{Link2Forum|Topic=19922|LinkText=dieser Diskussion}} im FHEM Forum enthalten</div>F Kleehttp://wiki.fhem.de/w/index.php?title=CALVIEW&diff=37212CALVIEW2022-02-11T17:43:37Z<p>F Klee: /* Define */</p>
<hr />
<div>{{Todo|Dieser Artikel ist veraltet. Insbesondere stimmt die Definition (define) nicht mit der derzeit gültigen (siehe commandref) überein. Mitautoren gesucht! Dieser Artikel muss dringend überarbeitet werden!}}<br />
<br />
{{Infobox Modul<br />
|ModPurpose=Legt ein Device an, das alle Termine aus einem [[Calendar]] als Reading anzeigt.<br />
|ModType=d<br />
|ModFTopic=19922<br />
|ModForumArea=Unterstützende Dienste/Kalendermodule<br />
|ModTechName=57_CALVIEW.pm<br />
|ModOwner=Christian / {{Link2FU|5217|Chris1284}}<br />
}}<br />
<br />
[[CALVIEW]] ist ein Hilfsmodul, das alle Termine aus einem bestehenden Kalender des Moduls [[Calendar]] in Readings übernimmt. <br />
<br />
== Voraussetzungen ==<br />
Es muss ein [[Calendar]]-Objekt definiert sein. Der dabei benutzte Name muss in der Definition des CALVIEW-Objekts spezifiziert werden.<br />
<br />
== Anwendung ==<br />
=== Define ===<br />
:<code>define <Name> CALVIEW <calendarname>[,<calendarname2>,...] <modus> [<updateintervall>]</code><br />
<br />
Erläuterung der Parameter im '''define''':<br />
;<calendarname> <br />
:Name des '''Calendar''' Kalenders. Mehrere '''Calendar'''-Namen durch Komma getrennt. <br />
;<modus><br />
:'''0'''&nbsp;&nbsp;für "modeStarted" Termine <br />'''1'''&nbsp;&nbsp;für "modeStarted";"modeUpcoming" Termine <br />'''2'''&nbsp;&nbsp;für "all" Termine<br />
<br />
;<updateintervall><br />
:Updateintervall in sec (default 43200). Nicht erforderlich, da ein Calendar-Update ein Calview-Update triggert.<br />
Beispiel:<br />
:<code>define myCalView CALVIEW Googlecalendar 1</code><br />
<br />
=== Werte aktualisieren ===<br />
[[datei:CALVIEW_Readingsgroup.png|mini|400px|CALVIEW in einer [[ReadingsGroup]] ]]<br />
:<code>set <Name> update</code><br />
Beispiel:<br />
:<code>set myCalView update</code><br />
<br />
=== Aktualisierungsintervall festlegen ===<br />
:<del><code><nowiki>set <Name> intervall <time></nowiki></code></del><br />
<br />
Das Aktualisierungsintervall wird (in den neueren Versionen - ab Mai 2015 - des Moduls) nur noch über das DEF verändert.<br />
<br />
=== Weitere Attribute ===Internet of Things.<br />
;maxreadings<br />
:Anzahl der angezeigten Termine festlegen<br />
Beispiel:<br />
:<code>attr myCalView maxreadings 10</code><br />
<br />
== Anwendungsbeispiel(e) ==<br />
<pre><br />
define kalenderTermine readingsGroup <%time_calendar>,<Text>,<Zuletzt erfasst> myView<br />
attr kalenderTermine alias Termine<br />
attr kalenderTermine group _KalenderView_<br />
attr kalenderTermine mapping %READING<br />
attr kalenderTermine room Kalender<br />
</pre><br />
<br />
== Links ==<br />
* Ein komplettes Beispiel ist im ersten Beitrag {{Link2Forum|Topic=19922|LinkText=dieser Diskussion}} im FHEM Forum enthalten</div>F Kleehttp://wiki.fhem.de/w/index.php?title=CALVIEW&diff=37211CALVIEW2022-02-11T17:41:13Z<p>F Klee: /* Define */</p>
<hr />
<div>{{Todo|Dieser Artikel ist veraltet. Insbesondere stimmt die Definition (define) nicht mit der derzeit gültigen (siehe commandref) überein. Mitautoren gesucht! Dieser Artikel muss dringend überarbeitet werden!}}<br />
<br />
{{Infobox Modul<br />
|ModPurpose=Legt ein Device an, das alle Termine aus einem [[Calendar]] als Reading anzeigt.<br />
|ModType=d<br />
|ModFTopic=19922<br />
|ModForumArea=Unterstützende Dienste/Kalendermodule<br />
|ModTechName=57_CALVIEW.pm<br />
|ModOwner=Christian / {{Link2FU|5217|Chris1284}}<br />
}}<br />
<br />
[[CALVIEW]] ist ein Hilfsmodul, das alle Termine aus einem bestehenden Kalender des Moduls [[Calendar]] in Readings übernimmt. <br />
<br />
== Voraussetzungen ==<br />
Es muss ein [[Calendar]]-Objekt definiert sein. Der dabei benutzte Name muss in der Definition des CALVIEW-Objekts spezifiziert werden.<br />
<br />
== Anwendung ==<br />
=== Define ===<br />
:<code>define <Name> CALVIEW <calendarname>[,<calendarname2>,...] <modus> [<updateintervall>]</code><br />
<br />
Erläuterung der Parameter im '''define''':<br />
;<calendarname> <br />
:Name des '''Calendar''' Kalenders. Mehrere '''Calendar'''-Namen durch Komma getrennt. <br />
;<modus><br />
:'''0'''&nbsp;&nbsp;für "modeStarted" Termine <br />'''1'''&nbsp;&nbsp;für "modeStarted";"modeUpcoming" Termine <br />'''2'''&nbsp;&nbsp;für "all" Termine<br />
<br />
;<updateintervall><br />
:Updateintervall in sec (default 43200). Nicht erforderlich.<br />
Beispiel:<br />
:<code>define myCalView CALVIEW Googlecalendar 1</code><br />
<br />
=== Werte aktualisieren ===<br />
[[datei:CALVIEW_Readingsgroup.png|mini|400px|CALVIEW in einer [[ReadingsGroup]] ]]<br />
:<code>set <Name> update</code><br />
Beispiel:<br />
:<code>set myCalView update</code><br />
<br />
=== Aktualisierungsintervall festlegen ===<br />
:<del><code><nowiki>set <Name> intervall <time></nowiki></code></del><br />
<br />
Das Aktualisierungsintervall wird (in den neueren Versionen - ab Mai 2015 - des Moduls) nur noch über das DEF verändert.<br />
<br />
=== Weitere Attribute ===Internet of Things.<br />
;maxreadings<br />
:Anzahl der angezeigten Termine festlegen<br />
Beispiel:<br />
:<code>attr myCalView maxreadings 10</code><br />
<br />
== Anwendungsbeispiel(e) ==<br />
<pre><br />
define kalenderTermine readingsGroup <%time_calendar>,<Text>,<Zuletzt erfasst> myView<br />
attr kalenderTermine alias Termine<br />
attr kalenderTermine group _KalenderView_<br />
attr kalenderTermine mapping %READING<br />
attr kalenderTermine room Kalender<br />
</pre><br />
<br />
== Links ==<br />
* Ein komplettes Beispiel ist im ersten Beitrag {{Link2Forum|Topic=19922|LinkText=dieser Diskussion}} im FHEM Forum enthalten</div>F Kleehttp://wiki.fhem.de/w/index.php?title=CALVIEW&diff=37210CALVIEW2022-02-11T17:38:53Z<p>F Klee: Define ergänzt</p>
<hr />
<div>{{Todo|Dieser Artikel ist veraltet. Insbesondere stimmt die Definition (define) nicht mit der derzeit gültigen (siehe commandref) überein. Mitautoren gesucht! Dieser Artikel muss dringend überarbeitet werden!}}<br />
<br />
{{Infobox Modul<br />
|ModPurpose=Legt ein Device an, das alle Termine aus einem [[Calendar]] als Reading anzeigt.<br />
|ModType=d<br />
|ModFTopic=19922<br />
|ModForumArea=Unterstützende Dienste/Kalendermodule<br />
|ModTechName=57_CALVIEW.pm<br />
|ModOwner=Christian / {{Link2FU|5217|Chris1284}}<br />
}}<br />
<br />
[[CALVIEW]] ist ein Hilfsmodul, das alle Termine aus einem bestehenden Kalender des Moduls [[Calendar]] in Readings übernimmt. <br />
<br />
== Voraussetzungen ==<br />
Es muss ein [[Calendar]]-Objekt definiert sein. Der dabei benutzte Name muss in der Definition des CALVIEW-Objekts spezifiziert werden.<br />
<br />
== Anwendung ==<br />
=== Define ===<br />
:<code>define <Name> CALVIEW <calendarname>[,<calendarname2>] <modus> [<updateintervall>]</code><br />
<br />
Erläuterung der Parameter im '''define''':<br />
;<calendarname> <br />
:Name des '''Calendar''' Kalenders. Mehrere '''Calendar'''-Namen durch Komma getrennt. <br />
;<modus><br />
:'''0'''&nbsp;&nbsp;für "modeStarted" Termine <br />'''1'''&nbsp;&nbsp;für "modeStarted";"modeUpcoming" Termine <br />'''2'''&nbsp;&nbsp;für "all" Termine<br />
<br />
;<updateintervall><br />
:Updateintervall in sec (default 43200). Nicht erforderlich.<br />
Beispiel:<br />
:<code>define myCalView CALVIEW Googlecalendar 1</code><br />
<br />
=== Werte aktualisieren ===<br />
[[datei:CALVIEW_Readingsgroup.png|mini|400px|CALVIEW in einer [[ReadingsGroup]] ]]<br />
:<code>set <Name> update</code><br />
Beispiel:<br />
:<code>set myCalView update</code><br />
<br />
=== Aktualisierungsintervall festlegen ===<br />
:<del><code><nowiki>set <Name> intervall <time></nowiki></code></del><br />
<br />
Das Aktualisierungsintervall wird (in den neueren Versionen - ab Mai 2015 - des Moduls) nur noch über das DEF verändert.<br />
<br />
=== Weitere Attribute ===Internet of Things.<br />
;maxreadings<br />
:Anzahl der angezeigten Termine festlegen<br />
Beispiel:<br />
:<code>attr myCalView maxreadings 10</code><br />
<br />
== Anwendungsbeispiel(e) ==<br />
<pre><br />
define kalenderTermine readingsGroup <%time_calendar>,<Text>,<Zuletzt erfasst> myView<br />
attr kalenderTermine alias Termine<br />
attr kalenderTermine group _KalenderView_<br />
attr kalenderTermine mapping %READING<br />
attr kalenderTermine room Kalender<br />
</pre><br />
<br />
== Links ==<br />
* Ein komplettes Beispiel ist im ersten Beitrag {{Link2Forum|Topic=19922|LinkText=dieser Diskussion}} im FHEM Forum enthalten</div>F Kleehttp://wiki.fhem.de/w/index.php?title=FTUI_Widget_Chart&diff=37164FTUI Widget Chart2022-01-28T16:26:36Z<p>F Klee: /* Fadenkreuz-Cursor */</p>
<hr />
<div>Das [[{{PAGENAME}}|Chart Widget]] ist ein Widget für [[FHEM Tablet UI]], mit dem sich verschiedenste Diagramme darstellen lassen. Die Aneinanderreihung mehrerer Werte eines Device-Readings zu einem zeitlichen Verlauf wird dabei als Graph bezeichnet.<br />
<br />
Es können beliebige Werte dargestellt und entsprechend der Sinnhaftigkeit, oder persönlichem Geschmack, formatiert werden. Farbe und Form der Linien sind je Graph einstellbar, auch wenn mehrere gleichzeitig in einem Diagramm angezeigt werden.<br />
<br />
Jedes Diagramm kann zwei Y-Achsen besitzen. Die primäre Y-Achse (primary) wird auf der linken Seite angezeigt, die sekundäre Y-Achse (secondary) auf der rechten Seite. Beide Achsen können unterschiedlich formatiert werden.<br />
<br />
<gallery><br />
File:Chart_tabletUI.png<br />
Datei:FTUI Widget Chart Stacked.png<br />
Datei:FTUI Widget Chart-fc-Proplanta.png<br />
Datei:Wetterchart2.png<br />
Datei:PieChart.png<br />
</gallery><br />
<br />
==Attribute==<br />
{| class="wikitable"<br />
! style="width:150px" |Attribut<br />
!Beschreibung<br />
!Standard-Wert<br />
!Beispiel<br />
|-<br />
|'''data-device'''||Name des FHEM-Device, das die Aktualisierung des Charts triggert||||data-device="WohnzimmerHeizung"<br />
|-<br />
|'''data-get'''||Reading, das das Update des Diagramms triggert||'STATE'||<br />
|-<br />
|'''data-logdevice'''||Name des Log-Device, das dargestellt werden soll, oder ein Array, um mehrere Werte in einem Diagramm darzustellen||||data-logdevice="FileLog_WohnzimmerHeizung"<br />
|-<br />
|'''data-logfile'''|| Name des Log-Files, aus dem die Daten entnommen werden sollen (oder Array)||'-' = aktuelle Datei||data-logfile="WohnzimmerHeizung-2015.log"<br>Beachte: Der Wert "CURRENT" ermöglicht die Navigation auch zu älterne Logfiles (Jahreswechsel)<br />
|-<br />
|'''data-columnspec'''||Ermittelt den Wert aus dem Log-File, der angezeigt werden soll (oder Array)||||data-columnspec="4:meas.*"<br />
|-<br />
|'''data-style'''||Stil, wie die Graph-Linien dargestellt werden sollen (z.B. 'SVGplot l0' oder 'ftui l0dash'), oder ein Array, wenn mehrere Linien unterschiedlich dargestellt werden sollen (siehe [[#Aussehen_der_Linien|Hinweise]])||||<br />
|-<br />
|'''data-ptype'''||Form, wie die Graphen dargestellt werden sollen (z.B. 'lines', 'cubic' oder 'fa-cog'), oder ein Array (siehe [[#Form_der_Linien|Hinweise]])||'lines'||<br />
|-<br />
|'''data-uaxis'''||Name der Achse, die verwendet werden soll ('primary' = links, oder 'secondary' = rechts), oder ein Array||'primary'||<br />
|-<br />
|'''data-legend'''||Bezeichnung des Graphen (wird in Legende und am Cursor angezeigt), oder ein Array||||<br />
|-<br />
|'''data-minvalue'''||Minimaler Wert, der auf der linken Y-Achse ('primary') angezeigt werden soll. 'auto' = automatische Berechnung||'10'||<br />
|-<br />
|'''data-maxvalue'''||Maximaler Wert, der auf der linken Y-Achse ('primary') angezeigt werden soll. 'auto' = automatische Berechnung||'30'||<br />
|-<br />
|'''data-minvalue_sec'''||Minimaler Wert, der auf der rechten Y-Achse ('secondary') angezeigt werden soll. 'auto' = automatische Berechnung||'auto'||<br />
|-<br />
|'''data-maxvalue_sec'''||Maximaler Wert, der auf der rechten Y-Achse ('secondary') angezeigt werden soll. 'auto' = automatische Berechnung||'auto'||<br />
|-<br />
|'''data-xticks'''||Abstand zwischen den vertikalen Hilfslinien (bezogen auf die X-Achse) in Minuten. 'auto' = automatische Berechnung||'auto'||<br />
|-<br />
|'''data-yticks'''||Abstand zwischen den horizontalen Hilfslinien (bezogen auf die linke Y-Achse). Kann auch ein Array mit Werte-Paaren enthalten, um die Linien mit Text zu beschriften.||'auto'||data-yticks='[[0,"open"],[1,"closed"]]'<br />
|-<br />
|'''data-yticks_format'''||Dient zur Formatierung der Ticks der Y-Achse. Die Formatierung geschieht über Platzhalter, Trenner und einen beliebigen durch ' ' getrennten Text. Als Platzhalter dient ein oder mehrere '#', als Trenner können '.', ',' und ':' verwendet werden. Ist ein Trenner enthalten (z.B. '#.##') dann bedeutet das in dem Beispiel, dass der Ytick mit 2 Nachkommastellen versehen wird und vorne Platz für eine Stelle vor dem Komma vorgehalten wird (führende Nullen werden nicht dargestellt, aber de Platz wird reserviert so dass das ganze rechtsbündig immer passt). Ist kein Trenner vorhanden, dann wird der Ytick auf die Summe der Platzhalter mit einer festen Gesamtbreite gesetzt (#### würde also bedeuten, dass immer 4 Stellen (ohne Trenner) verwendet werden. aus 0.4 würde 0.400 aus 10.437 würde 10.44). Als Trenner kann man z.B. für Zeiten auch einen ':' verwenden und dadurch auch so etwas wie "12:00 Uhr" realisieren (in dem Beispiel wäre data-yticks_format="##:## Uhr" und kein data-yunit oder data-yticks="##:##" und data-yunit="Uhr").||||data-yticks_format="#.##"<br />
|-<br />
|'''data-yticks_sec'''||Abstand zwischen den horizontalen Hilfslinien (bezogen auf die rechte Y-Achse). Kann auch ein Array mit Werte-Paaren enthalten, um die Linien mit Text zu beschriften.||'auto'||data-yticks='[[0,"open"],[1,"closed"]]'<br />
|-<br />
|'''data-yticks_format_sec'''||Dient zur Formatierung der Ticks der Y-Achse. Die Formatierung geschieht über Platzhalter, Trenner und einen beliebigen durch ' ' getrennten Text. Als Platzhalter dient ein oder mehrere '#', als Trenner können '.', ',' und ':' verwendet werden. Ist ein Trenner enthalten (z.B. '#.##') dann bedeutet das in dem Beispiel, dass der Ytick mit 2 Nachkommastellen versehen wird und vorne Platz für eine Stelle vor dem Komma vorgehalten wird (führende Nullen werden nicht dargestellt, aber de Platz wird reserviert so dass das ganze rechtsbündig immer passt). Ist kein Trenner vorhanden, dann wird der Ytick auf die Summe der Platzhalter mit einer festen Gesamtbreite gesetzt (#### würde also bedeuten, dass immer 4 Stellen (ohne Trenner) verwendet werden. aus 0.4 würde 0.400 aus 10.437 würde 10.44). Als Trenner kann man z.B. für Zeiten auch einen ':' verwenden und dadurch auch so etwas wie "12:00 Uhr" realisieren (in dem Beispiel wäre data-yticks_format="##:## Uhr" und kein data-yunit oder data-yticks="##:##" und data-yunit="Uhr").||||data-yticks_format_sec="#.##"<br />
|-<br />
|'''data-yticks_prio'''||Legt fest, ob die horizontalen Hilfslinien der linken (primary) oder der rechten (secondary) Y-Achse zugeordnet werden sollen||||data-yticks_prio='secondary'<br />
|-<br />
|'''data-ytype'''||Legt fest, ob die primäre y Achse logarithmisch sein soll (wert "log")||||data-ytype="log"<br />
|-<br />
|'''data-ytype_sec'''||Legt fest, ob die sekundäre y Achse logarithmisch sein soll (wert "log")||||data-ytype_sec="log"<br />
|-<br />
|'''data-margin'''|||Abstand zwischen Buttons und Chart (Einheit Pixel). ||"0"|||data-margin="10"<br />
|-<br />
|'''data-y_margin'''|||Gibt die Möglichkeit, Abstände zwischen den Graphen und dem oberen Rand des Plots zu definieren (Einheit Pixel). Falls der Wert skalar ist, werden oben und unten die gleichen Abstände eingehalten. Falls ein 2D Array angegeben wird, können die Werte unten (erster Wert im Array) und oben (zweiter Wert im Array) getrennt festgelegt werden||"0"|||data-y_margin='["10","20"]'<br />
|-<br />
|'''data-y_margin_sec'''|||Gibt die Möglichkeit, Abstände zwischen den Graphen und dem oberen Rand des Plots zu definieren (Einheit Pixel). Falls der Wert skalar ist, werden oben und unten die gleichen Abstände eingehalten. Falls ein 2D Array angegeben wird, können die Werte unten (erster Wert im Array) und oben (zweiter Wert im Array) getrennt festgelegt werden||"0"|||data-y_margin='["10","20"]'<br />
|-<br />
|'''data-daysago_start'''||Anzahl der vergangenen Tage, wo das Diagramm beginnen soll. '0' = Beginn heute 0:00 Uhr. (siehe [[#Zeitstrahl_.2F_Start_.26_Ende_auf_der_X-Achse|Hinweise]])||'0'||<br />
|-<br />
|'''data-daysago_end'''||Anzahl der vergangenen Tage, wo das Diagramm enden soll. '-1' = Ende heute 24:00 Uhr. (siehe [[#Zeitstrahl_.2F_Start_.26_Ende_auf_der_X-Achse|Hinweise]])||'-1'||<br />
|-<br />
|'''data-xticks_round'''||Wenn vorhanden und entweder 'h', 'd', 'w', wird auf Stunde, Tag oder Woche bei den xticks gerundet (also die Tickmarks und die Gridlines bei den entsprechend gerundeten Zeiten gesetzt). Es kann auch 'auto' angegeben werden, um eine autmoatische Rundung durchzuführen||||<br />
|-<br />
|'''data-nofulldays'''||Aktiviert/deaktiviert die Rundung der X-Achse auf ganze Tage. Binärwert ('true' oder 'false')||'false'||<br />
|-<br />
|'''data-timeformat'''||Zeitformat für die Anzeige an der X-Achse (siehe [[#Zeitformat_der_X-Achse|Hinweise]])||||<br />
|-<br />
|'''data-timeranges'''||Hierdurch können vordefinierte Zeiträume für die X-Achse festgelegt werden, die dann durch eine pulldown menu (neuer Button oben neben dem "-" Button) direkt ausgewählt werden können. Der Parameter ist ein Array aus Array Einträgen, welche jeweils [<Name>,<daysago_start>,<daysago_end>] enthalten)||<br />
||data-timeranges='[<br><br />
["Actual Year","0Y","-1Y"],<br><br />
["Last Year","1Y","0Y"],<br><br />
["Actual Month","0M","-1M"],<br><br />
["Last Month","1M","0M"],<br><br />
["Actual Week","0W","-1W"],<br><br />
["Last Week","1W","0W"],<br><br />
["Today","0D","-1D"],<br><br />
["Yesterday","1D","0D"]<br><br />
]'<br />
|-<br />
|'''data-ytext'''||Text, der neben der linken Y-Achse angezeigt wird||||<br />
|-<br />
|'''data-ytext_sec'''||Text, der neben der rechten Y-Achse angezeigt wird||||<br />
|-<br />
|'''data-yunit'''||Einheit, die an der linken Y-Achse angezeigt wird||||<br />
|-<br />
|'''data-yunit_sec'''||Einheit, die an der rechten Y-Achse angezeigt wird||||<br />
|-<br />
|'''data-show_both_axes'''||Legt fest ob beide Y-Achsen Linien gezeichnet werden sollen||false||<br />
|-<br />
|'''data-crosshair'''||Aktiviert/deaktiviert den Fadenkreuz-Cursor. Binärwert ('true' oder 'false')||'false'||<br />
|-<br />
|'''data-cursorgroup'''||Zahl zur Gruppierung der Werte am Fadenkreuz-Cursor ([[#Fadenkreuz-Cursor|Hinweise]])||||<br />
|-<br />
|'''data-scrollgroup'''||Zahl zur Gruppierung der Graphen beim Bewegen und Zoomen. Alle Linien mit der selben Zahl werden miteinander gekoppelt und bewegen sich gemeinsam.||||<br />
|-<br />
|'''data-showlegend'''||Aktiviert/deaktiviert die Anzeige der Legene. Binärwert ('true' oder 'false')||'false'||<br />
|-<br />
|'''data-legendpos'''||Array von zwei Werten, die die horizontale und vertikale Position der Legende festlegen ([[#Legende|Hinweise]])||'["right","top"]'||<br />
|-<br />
|'''data-legend_horiz'''||legt fest, dass die Legendeneinträge horizontal angeordnet sind (anstatt vertikal wie im default Fall)||false||data-legend_horiz="true"<br />
|-<br />
|'''data-width'''||Breite des Diagramms (in % oder px)||||<br />
|-<br />
|'''data-height'''||Höhe des Diagramms (in % oder px)||||<br />
|-<br />
|'''data-graphsshown'''||Aktiviert/deaktiviert die initiale Anzeige von Graphen. Binärwert ('true' oder 'false'). Array, wenn mehrere Linien angezeigt werden sollen.||||data-graphsshown='[true,false,true]'<br />
|-<br />
|'''data-ddd'''||Einstellung für die 3D-Drehung ([[#3-dimensionale_Drehung|Hinweise]])||||data-ddd='["40","60","0"]'<br />
|-<br />
|'''data-dddspace'''||Abstand zwischen zwei Graphen, wenn die 3D-Anzeige aktiviert wurde (px)||'15'||<br />
|-<br />
|'''data-dddwidth'''||Breite, bzw. Tiefe der Graphen, wenn diese 3-dimensional angezeigt werden (px)||'10'||<br />
|-<br />
|'''data-title'''||Titel, der über dem Diagramm angezeigt werden soll. Der Inhalt kann auch dynamisch erzeugt werden ([[#Diagrammtitel|Hinweise]])||||<br />
|-<br />
|'''data-title_class'''||Klassenname für die Formatierung des Titels. Die Eigenschaften müssen dann entsprechend in einem CSS File angegeben werden (z.B. in fhem-tablet-ui-user.css)||||<br />
|-<br />
|'''data-prefetch'''||Legt fest, ob zusätzliche Daten rechts und links des Plots im Hintergrund vom Server geholt werden sollen||false||data-prefetch="true"<br />
|}<br />
Einige Parameter (style, maxvalue, minvalue, maxvalue_sec, minvalue_sec) können auch aus Readings dynamisch gesetzt werden wenn "<device>:<reading>" als Parameter gesetzt wird. Damit kann man z.B. in FHEM über notify etc. die Linientypen dynamisch anpassen (z.B. wenn der Wert eines Devices in einem bestimmten Bereich liegt, ändert sich die Farbe des Graphen).<br />
<br />
==CSS Klassen==<br />
{| class="wikitable"<br />
!Klasse!!Beschreibung<br />
{{FTUI Klasse|fullsize}}{{FTUI Klasse|noticks}}{{FTUI Klasse|nobuttons}}{{FTUI Klasse|small}}{{FTUI Klasse|normal}}{{FTUI Klasse|big}}<br />
|}<br />
<br />
Folgende Widget-spezifsche Klassen können zusätzlich in einer eigenen CSS-Datei definiert werden:<br />
<br />
{| class="wikitable"<br />
!Klasse<br />
!Beschreibung<br />
|-<br />
|'''chart-background'''||Hintergrundfarbe des Diagramms<br />
|-<br />
|'''buttons'''||Größe und Farbe der Buttons<br />
|-<br />
|'''text.axes'''||Generelle Schriftart und Farbe der Achsen<br />
|-<br />
|'''gridlines'''||Generelle Farbe und Größe der Gitternetzlinien<br />
|-<br />
|'''xaxis'''||Schriftart, Größe und Farbe der X-Achse<br />
|-<br />
|'''yaxis'''||Schriftart, Größe und Farbe der Y-Achse<br />
|-<br />
|'''xticks'''||Schriftart, Größe und Farbe der X-Achse (Zwischenlinien)<br />
|-<br />
|'''yticks'''||Schriftart, Größe und Farbe der Y-Achse (Zwischenlinien)<br />
|-<br />
|'''crosshair'''||Schriftart, Größe und Vordergrund/Hintergrundfarbe der Momentanwerte am Fadenkreuzcursor<br />
|-<br />
|'''caption'''||Schriftart, Größe und Farbe der Text-Buttons für Legende und Cursor<br />
|-<br />
|'''legend'''||Schriftart, Größe und Farbe der Legende<br />
|}<br />
<br />
Die Standardwerte sind in der Datei <code>css/ftui_chart.css</code> zu finden.<br />
<br />
==Datenquellen==<br />
Beim Chart-Widget können die gleichen Datenquellen genutzt werden, die auch für SVG-Plots verwendet werden können:<br />
# [[FileLog]]: Verlaufsdaten einer Textdatei entnehmen<br />
# [[DbLog]]: Verlaufsdaten einer Datenbank entnehmen<br />
# [[LogProxy]]: Daten dynamisch berechnet<br />
<br />
===FileLog===<br />
Um [[FileLog]] zu nutzen, wird als '''data-logdevice''' das FHEM-Device für das FileLog angegeben. In der Regel entstehen hier im Laufe der Zeit mehrere Log-Dateien. Name und Anzahl sind von der Definition abhängig - meist wird jeden Monat oder jedes Jahr eine neue Datei angelegt. Die gewünschte Datei kann mit '''data-logfile''' ausgewählt werden. Möchte man stets die aktuelle Datei verwenden (macht vor allem dann Sinn, wenn man die neusten Daten anzeigen will), kann das Attribut weggelassen, oder explizit <code>-</code> eingetragen werden. Zuletzt wird '''data-columnspec''' benötigt, um die gewünschten Daten zu in der Logdatei zu identifizieren. Hier wird die Spalte, in der die Daten stehen, gefolgt von Doppelpunkt und Readingname angegeben.<br />
<br />
Für ein Heizungsthermostat von Homematic mit dem Namen ''DG.wz.HZ.Heizungsventil'' ergibt sich somit beispielhaft folgende Definition, um gemessene Temperatur, Sollwert und Ventilstellung im Diagramm darzustellen:<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="DG.wz.HZ.Heizungsventil"<br />
data-logdevice="FileLog_DG.wz.HZ.Heizungsventil"<br />
data-logfile="-"<br />
data-columnspec='["4:measured-temp","4:desired-temp","4:actuator"]'<br />
...><br />
</div><br />
</syntaxhighlight><br />
<br />
Sollen Daten von unterschiedlichen Geräten in einem Diagramm angezeigt werden, muss '''data-logdevice''' als Array nach dem Schema <code>data-logdevice='["<Logdatei_1>","<Logdatei_2>","<Logdatei_3>"]'</code> definiert werden. Für jeden Eintrag in '''data-columnspec''' muss es auch den passenden Eintrag in '''data-logdevice''' geben (auch die Reihenfolge ist relevant).<br />
<br />
===DbLog===<br />
Um die Daten aus [[DbLog]] anzeigen zu können, werden die gleichen Attribute verwendet und mit für die Datenbank angepassten Werten beschrieben. Bei '''data-logdevice''' das FHEM-Device für die Datenbank angegeben. Im nachfolgenden Beispiel heißt diese <code>logdb</code> und besitzt wie üblich zwei Tabellen: <code>current</code> und <code>history</code> (der zeitliche Verlauf liegt in letzterer). Der Tabellenname wird bei '''data-logfile''' eingetragen. Da die Daten in der Datenbank etwas anders abgelegt werden, muss auch '''data-columnspec''' entsprechend angepasst werden. Statt der Spalte wird hier das FHEM-Device, gefolgt von Doppelpunkt und Readingname angegeben.<br />
<br />
Für das oben beschriebene Homematic-Heizungsthermostat ergibt sich dann folgende Definition, um die gleichen Daten aus einer Datenbank, statt einem LogFile zu lesen:<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="DG.wz.HZ.Heizungsventil"<br />
data-get="measured-temp"<br />
data-style='["ftui l0"]'<br />
data-logdevice="logdb"<br />
data-logfile="HISTORY"<br />
data-columnspec='["DG.wz.HZ.Heizungsventil:measured-temp","DG.wz.HZ.Heizungsventil:desired-temp","DG.wz.HZ.Heizungsventil:actuator"]'<br />
...><br />
</div><br />
</syntaxhighlight><br />
<br />
Für die Anzeige von unterschiedlichen Geräten in einem Diagramm, muss nur '''data-columnspec''' entsprechend angepasst werden, solange sich alle Daten in der Datenbank befinden.<br />
<br />
===LogProxy===<br />
Um die Daten mittels [[LogProxy]] berechnen und anzeigen zu können, muss in FHEM ein LogProxy-Device definiert sein:<br />
<br />
<pre><br />
define myLogProxy logProxy<br />
</pre><br />
<br />
Weitere Einstellungen am LogProxy sind nicht nötig, die bloße Existenz reicht.<br />
<br />
Bei '''data-logdevice''' wird das FHEM-Device für den LogProxy angegeben. Im nachfolgenden Beispiel heißt dieses <code>myLogProxy</code>. Das Attribut '''data-logfile''' wird für LogProxy nicht benötigt. Befinden sich nur LogProxy-Werte im Diagramm kann das Attribut komplett entfallen. Sollen weitere Werte angezeigt werden, bleibt die Definition im Array einfach leer.<br />
<br />
Im Attribut '''data-columnspec''' wird eine Formel angegeben, wie die Werte berechnet werden sollen. Hier können die Formeln 1:1 von einem eventuell vorhandenen SVG-Plot übernommen werden. '''Dabei gibt es jedoch folgendes zu beachten:''' Befindet sich die Formel in einem Array, dürfen die Formeln keine Anführungszeichen (<code>"</code>) beinhalten. Stattdessen müssen sie als escapter Ascii-Code (<code>\\x22</code>) eingefügt werden.<br />
<br />
Das nachfolgende Beispiel zeigt, wie Vorhersagewerte aus einem FHEM-Device vom Typ Proplanta (Name hier <code>AU.xx.WE.Proplanta</code>) angezeigt werden können.<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="AU.xx.WE.Proplanta"<br />
data-logdevice='[<br />
"myLogProxy",<br />
"myLogProxy",<br />
"myLogProxy",<br />
"myLogProxy"<br />
]'<br />
data-columnspec='[<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22temp_\\x22,$from,$to,12,\\x22day\\x22)",<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22rain_\\x22,$from,$to,12,\\x22day\\x22)",<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22chOfRain_\\x22,$from,$to,12,\\x22day\\x22)",<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22cloud_\\x22,$from,$to,12,\\x22day\\x22)"<br />
]'<br />
...><br />
</div><br />
</syntaxhighlight><br />
<br />
'''Auch alle anderen Funktionen, die [[LogProxy]] bietet, können hier angewendet werden.'''<br />
<br />
==Hinweise==<br />
===Aktualisierung des Charts===<br />
Damit der Refresh des Charts funktioniert, muss auch ein Device angegeben werden, der das Refresh triggert. Das Diagramm wird immer dann aktualisiert, wenn sich der Inhalt von '''data-get''' ändert.<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="WohnzimmerHeizung"<br />
data-logdevice="FileLog_WohnzimmerHeizung"<br />
...><br />
</div><br />
</syntaxhighlight><br />
<br />
===Aussehen der Linien===<br />
Mit dem Attribut '''data-style''' kann das Aussehen der Linien des jeweiligen Graphen verändert werden. Hierfür können die Standard-FHEM-Styles verwendet werden. Dazu wird das Attribut mit <code>SVGplot</code>, gefolgt von einem Leerzeichen und der gewünschten Farbe/Stil befüllt. Es existieren jedoch auch noch weitere, an FTUI angepasste Styles, zu finden in der CSS-Datei <code>css/ftui_chart.css</code>. Um diese zu verwenden, wird das Attribut mit <code>ftui</code>, gefolgt von einem Leerzeichen und der gewünschten Farbe/Stil befüllt. Eigene Styles können zum Beispiel in der Datei <code>css/fhem-table-ui-user.css</code> definiert werden.<br />
<br />
Folgende Übersicht zeigt die im Standard verfügbaren '''Farben''', alle Abbildungen sind mit im FTUI-Style entstanden:<br />
<div><ul> <br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f0.png|thumb|none|150px|Farbe "l0"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f1.png|thumb|none|150px|Farbe "l1"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f2.png|thumb|none|150px|Farbe "l2"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f3.png|thumb|none|150px|Farbe "l3"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f4.png|thumb|none|150px|Farbe "l4"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f5.png|thumb|none|150px|Farbe "l5"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f6.png|thumb|none|150px|Farbe "l6"]] </li><br />
</ul></div><br />
<br />
Die Angabe zur Farbe kann dann mit der Linienart kombiniert werden. Dazu stehen folgende '''Stile''' zur Verfügung:<br />
<div><ul> <br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-2D-normal.png|thumb|none|225px|Darstellung in 2D: Stil "normal"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-2D-dot.png|thumb|none|225px|Darstellung in 2D: Stil "dot"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-2D-dash.png|thumb|none|225px|Darstellung in 2D: Stil "dash"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-2D-fill.png|thumb|none|225px|Darstellung in 2D: Stil "fill"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-2D-sym.png|thumb|none|225px|Darstellung in 2D: Stil "sym"]] </li><br />
</ul></div><br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-3D-normal.png|thumb|none|225px|Darstellung in 3D: Stil "normal"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-3D-dot.png|thumb|none|225px|Darstellung in 3D: Stil "dot"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-3D-dash.png|thumb|none|225px|Darstellung in 3D: Stil "dash"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-3D-fill.png|thumb|none|225px|Darstellung in 3D: Stil "fill"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-3D-sym.png|thumb|none|225px|Darstellung in 3D: Stil "sym"]] </li><br />
</ul></div><br />
<br />
Farbe und Stil werden kombiniert (zusammengeschrieben) beim Attribut '''data-style''' angegeben, sodass sich beispielsweise für eine graue Punktlinie folgendes ergibt: <code>data-style="ftui l1dot"</code>.<br />
Um die Darstellung als normale Linie zu erhalten, darf im Gegensatz zu den anderen Linienformen der Stil <code>normal</code> nicht angegeben werden. Für eine einfache graue Linie ist also die Angabe <code>data-style="ftui l1"</code> korrekt, wohingegen <code>data-style="ftui l1normal"</code> zu einer fehlerhaften Anzeige führt.<br />
<br />
'''Hinweis:''' Der Stil ''sym'' ist speziell dafür geeignet, Symbole statt Linien zu zeichnen. Dazu kann beim Attribut '''data-ptype''' als Linienform ein beliebiges Font-Awsome-, oder Open Automation-Icon angegeben werden. Alle in diesem Abschnitt enthaltenen Abbildungen sind mit <code>data-ptype="lines"</code> entstanden.<br />
<br />
'''Übergänge mit datenabhängigen Grenzen:''' Plotstile (data-style) können auch direkt als Gradienten auf Basis von Plot-Datenwerten definiert werden. Dazu muss der Plotstil als Array angegeben werden. Der erste Wert des Arrays gibt an, ob nur die Linie gezeichnet werden soll (Zahl angeben, die die Dicke der Linie definiert) oder gefüllt ("fill" eintragen). Alle danach folgenden Array Elemente sind beliebig viele Stopp Punkte für die Farbübergänge, welche wiederum aus Arrays mit 3 Parametern bestehen. Für jeden Stopp Punkt werden der Datenwert, die Farbe und die Durchsichtigkeit gesetzt. Hierdurch lassen sich z.B. Einfärbungen setzen, die für Temperaturplots immer negative Werte blau einfärben und positive Werte rot. Zwischen den Stop Punkten wird die Farbe interpoliert, also ein weicher Übergang generiert. Will man harte Übergänge muss man Zwei Stopp Punkte mit unterschiedlichen Farbwerten aber dem gleichen Datenwert erzeugen.<br><br />
Beispiel 1 für einen weichen Gradienten, der bei 0 von blau nach rot übergeht, bei diesem Übergang durchsichtig ist und von dort nach negativen bzw. positiven Werden immer deckender wird:<br><br />
<code>data-style='["fill",["-20","#0000ff","0.7"],["0","#0000ff","0"],["0","#ff0000","0"],["302","#ff0000","0.7"]]'</code><br><br />
Beispiel 2 mit einem harten Übergang von blau nach rot bei 0:<br><br />
<code>data-style='["fill",["-20","#0000ff","0.7"],["0","#0000ff","0.7"],["0","#ff0000","0.7"],["50","#ff0000","0.7"]]'</code><br />
Es gibt auch die Möglichkeit den Bereich zwischen zwei Graphen einzufärben. Dazu muss ein Wert in Columnspec als Array angegeben werden. Ist dies der Fall, dann wird der zweite Graph umgekehrt an den ersten angehängt.<br><br />
Beispiel:<br />
<syntaxhighlight lang="html"><br />
data-columnspec='[<br />
"Func:logProxy_proplanta2Plot(\\x22AgroWeather\\x22,\\x22weatherIcon\\x22,$from,$to,12)",<br />
[<br />
"Func:logProxy_proplanta2Plot(\\x22AgroWeather\\x22,\\x22tempMax\\x22,$from,$to,12)",<br />
"Func:logProxy_proplanta2Plot(\\x22AgroWeather\\x22,\\x22tempMin\\x22,$from,$to,12)"<br />
],<br />
"Func:logProxy_proplanta2Plot(\\x22AgroWeather\\x22,\\x22rain\\x22,$from,$to,0,\\x22day\\x22)"<br />
]'<br />
</syntaxhighlight><br />
[[Datei:FTUI Widget Chart DynamicStyles.png|thumb|none|500px|dynamischer Übergang]]<br />
<br />
===Form der Linien===<br />
Das Attribut '''data-ptype''' beeinflusst die Form der Linien. Hier sind folgende Werte möglich (in den Bildern sind zur Info zusätzlich auch immer points dargestellt):<br />
<div><ul><br />
<li style="display: inline-block;"> [[File:Llines.png|thumb|none|350px|Darstellung in 2D: Stil "lines"]] </li><br />
<li style="display: inline-block;"> [[File:Points.png|thumb|none|350px|Darstellung in 2D: Stil "points"]] </li><br />
<li style="display: inline-block;"> [[File:Steps.png|thumb|none|350px|Darstellung in 2D: Stil "steps"]] </li><br />
<li style="display: inline-block;"> [[File:Fsteps.png|thumb|none|350px|Darstellung in 2D: Stil "fsteps"]] </li><br />
<li style="display: inline-block;"> [[File:Histeps.png|thumb|none|350px|Darstellung in 2D: Stil "histeps"]] </li><br />
<li style="display: inline-block;"> [[File:Bars.png|thumb|none|350px|Darstellung in 2D: Stil "bars"]] </li><br />
<li style="display: inline-block;"> [[File:Ibars.png|thumb|none|350px|Darstellung in 2D: Stil "ibars"]] </li><br />
<li style="display: inline-block;"> [[File:Cubic.png|thumb|none|350px|Darstellung in 2D: Stil "cubic"]] </li><br />
<li style="display: inline-block;"> [[File:Quadratic.png|thumb|none|350px|Darstellung in 2D: Stil "quadratic"]] </li><br />
<li style="display: inline-block;"> [[File:QuadraticSmooth.png|thumb|none|350px|Darstellung in 2D: Stil "quadraticSmooth"]] </li><br />
</div><br />
<br />
Zusätzlich ist es möglich, Symbole anzeigen zu lassen. Unterstützt werden Font-Awesome ('fa-...'), Open Automation ('oa-...') und FHEM-Symbole ('fs-...')). Damit die Symbole korrekt angezeigt werden, muss im Attribut '''data-style''' der Stil <code>sym</code> gewählt werden, da sonst nur Punkte, statt der Symbole gezeichnet werden.<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="DG.wz.HZ.Heizungsventil"<br />
data-logdevice="FileLog_DG.wz.HZ.Heizungsventil"<br />
...<br />
data-style="ftui l1sym"<br />
data-ptype="fa-cloud"<br />
...><br />
</div><br />
</syntaxhighlight><br />
<li style="display: inline-block;"> [[File:Ssymbols.png|thumb|none|500px|Darstellung in 2D: Stil "symbol fa-cloud"]] </li><br />
<br />
Die Größe der Symbole ist in der Datei <code>css/ftui_chart.css</code> auf 12px festgelegt. Dieser Wert kann in einer eigenen CSS-Datei durch Anpassung von <code>stroke-width</code> überschrieben werden.<br />
<br />
<syntaxhighlight lang="css"><br />
.ftui.l0sym { stroke:#DDA400; stroke-width:12px; fill:none; }<br />
.ftui.l1sym { stroke:#BBBBBB; stroke-width:12px; fill:none; }<br />
.ftui.l2sym { stroke:#CC0000; stroke-width:12px; fill:none; }<br />
.ftui.l3sym { stroke:#CCCC00; stroke-width:12px; fill:none; }<br />
.ftui.l4sym { stroke:#33CC33; stroke-width:12px; fill:none; }<br />
.ftui.l5sym { stroke:#33CCCC; stroke-width:12px; fill:none; }<br />
.ftui.l6sym { stroke:#3333CC; stroke-width:12px; fill:none; }<br />
</syntaxhighlight><br />
<br />
'''data-ptype''' kann auch Inhalt im Format <code>'icon:1'</code> verarbeiten. Dann muss der zugehörige Wert in '''data-columnspec''' den Pfad zu einem Icon (z.B. für Wettervorhersagen) beinhalten. Der Y-Wert wird dann vom ersten Graphen übernommen. Weitere Ausführungen hierzu im Beispiel [[#Darstellung der Wetter Icons im Diagramm]].<br />
<li style="display: inline-block;"> [[File:Wetterchart2.png|thumb|none|500px|Darstellung in 2D: Stil "Beispiel mit icons aus Readings"]] </li><br />
<br />
<br />
===Stapeln von Linien===<br />
Über '''data-ptype''' kann zusätzlich festgelegt werden, ob Graphen übereinander gestapelt werden sollen. <code>data-ptype='lines:1'</code> bedeutet, dass der zugehörige Graph auf den Graph mit der Nummer 1 gestapelt werden soll. So etwas kann z.B. Sinn machen, wenn man den Stromverbrauch einzelner Devices darstellen und zusätzlich sehen will, wie hoch die Summe ist. Beispiel siehe unten.<br />
<br />
[[Datei:FTUI Widget Chart Stacked.png]]<br />
<br />
===Zeitstrahl / Start & Ende auf der X-Achse===<br />
Die Attribute '''data-daysago_start''' und '''data-daysago_end''' dienen der Definition von Anfang und Ende der X-Achse. Im einfachsten Fall wird eine Anzahl an Tagen eingegeben, die sich auf das aktuelle Datum beziehen. Dabei gilt es zu beachten, dass es sich um ''vergangene Tage'' handelt. Das bedeutet, dass Tage in der Vergangenheit als positive Zahl angegeben werden, Tage in der Zukunft hingegen als negative Zahl. Es kann jeweils auch ein fixes Datum (z.B. '2013-10-23') angegeben werden. Uhrzeitangaben werden nur berücksichtigt, wenn '''data-nofulldays='true' ''' verwendet wird.<br />
<br />
'''Relative Zeitangabe in Stunden/Tagen/Wochen/Monaten/Jahren'''<br /><br />
Zur Ausgabe einer Anzahl an zurückliegenden Stunden bis zum aktuellen Zeitpunkt wird als Startzeitpunkt die Anzahl der Stunden/Tage/Wochen/Monate/Jahre angegeben, die angezeigt werden sollen, gefolgt vom Kleinbuchstaben '''h''' für Stunden, '''d''' für Tage, '''w''' für Wochen, '''m''' für Monate, '''y''' für Jahre, . Als Endzeitpunkt wird '''now''' gewählt.<br /><br />
Das nachfolgende Beispiel zeigt die Werte der vergangenen 3 Stunden an:<br />
<syntaxhighlight lang="html"><br />
data-nofulldays="true"<br />
data-daysago_start="3h"<br />
data-daysago_end="now"<br />
</syntaxhighlight><br />
<br />
'''Fester Zeitbereich des heutigen Tages (Stunden/Tage/Wochen/Monate/Jahre)'''<br /><br />
Um ein festes Stunden/Tages/Wochen/Monats/Jahresfenster anzuzeigen, werden die absoluten Stunden/Tages/Wochen/Monats/Jahreszahlen mit negativem Vorzeichen, gefolgt vom Großbuchstaben '''H''' (entsprechend D/W/M/Y für Tage/Wochen/Monate/Jahre) angegeben. Wird '''data-daysago_start''' als positiver Wert angegeben, wird die Anzahl der Stunden/Tage/Wochen/Monate/Jahre von heute 0:00 Uhr subtrahiert (siehe Rechenweg weiter unten).<br /><br />
Das Beispiel zeigt den Zeitbereich von heute 5:00 Uhr bis heute 22:00 Uhr:<br />
<syntaxhighlight lang="html"><br />
data-nofulldays="true"<br />
data-daysago_start="-5H"<br />
data-daysago_end="-22H"<br />
</syntaxhighlight><br />
<br />
'''Fester Zeitbereich Tage-übergreifend'''<br /><br />
Die Zeit in Tagen kann als Gleitkommazahl angegeben werden. Damit ist es möglich, Tage und Uhrzeiten zu kombinieren. Die Werte sind dann als Teil eines ganzen Tages, bezogen auf heute 0:00 Uhr zu errechnen und mit <code>.</code> als Teiler anzugeben.<br /><br />
Das nachfolgende Beispiel zeigt einen Zeitbereich von '''gestern 15:00 Uhr''' bis '''morgen 3:00 Uhr'''.<br />
<syntaxhighlight lang="html"><br />
data-nofulldays="true"<br />
data-daysago_start="0.375"<br />
data-daysago_end="-1.125"<br />
</syntaxhighlight><br />
<br />
Für die nachfolgenden Rechenwege sind die Einheiten nur zur Verdeutlichung angegeben. Die Einheiten werden im Attribut nicht angegeben.<br />
<br />
Der Wert für '''GESTERN''' wird wie folgt ermittelt:<br /><br />
Ausgangspunkt ist heute 0:00 Uhr, gestern 15:00 Uhr liegt also 9 Stunden davor. Diese 9 Stunden sind ein <code>9/24 Tag</code> und errechnet sich so:<br />
<pre><br />
1d / 24h = 0.0416666...d/h<br />
0.0416d/h * 9h = 0.375d<br />
</pre><br />
<br />
Der Wert für '''MORGEN''' wird wie folgt ermittelt:<br /><br />
Ausgangspunkt ist wieder heute 0:00 Uhr, morgen 3:00 Uhr liegt dann 27 Stunden dahinter. Der Einfachheit halber werden hier nur die 3 Stunden errechnet und dann ein ganzer Tag addiert:<br />
<pre><br />
1d / 24h = 0.0416666...d/h<br />
0.0416d/h * 3h = 0.125d<br />
<br />
0.125d + 1d = 1.125d<br />
</pre><br />
Da das Attribut Tage in der Vergangenheit erwartet, muss für einen Wert in der Zukunft wieder eine negative Zahl angegeben werden.<br />
<br />
===Zeitformat der X-Achse===<br />
Die Zeitanzeige auf der X-Achse kann sehr flexibel eingestellt werden. Dafür stehen verschiedene Platzhalter zur Verfügung, die durch spezielle Zeichen (<code>-</code>, <code>.</code>, <code>/</code>, <code> </code> (Leerzeichen), <code>:</code>, <code>,</code>, <code>\</code>) getrennt werden. Alle Zeichen werden trotz Escape-Zeichen (<code>\</code>) in der Ausgabe angezeigt.<br />
<br />
Folgende Platzhalter werden unterstützt:<br />
*<code>'mm'</code>: Minuten als zweistellige Zahl<br />
*<code>'hh'</code>: Stunden als zweistellige Zahl<br />
*<code>'dd'</code>: Tag als zweistellige Zahl (Kalenderdatum)<br />
*<code>'MM'</code>: Monat als zweistellige Zahl (z.B. 02 für Februar)<br />
*<code>'MMM'</code>: Monat als dreistellige Abkürzung (z.B. Dec für Dezember)<br />
*<code>'MMMM'</code>: Langname des Monats (z.B. March)<br />
*<code>'ee'</code>: Wochentag als zweistellige Zahl (z.B. 00 für Sonntag)<br />
*<code>'eee'</code>: Wochentag als dreistellige Abkürzung (z.B. Mon für Montag)<br />
*<code>'eeee'</code>: Langname des Wochentags (z.B. Tuesday)<br />
*<code>'yy'</code>: Jahr als zweistellige Zahl (z.B. 16 für 2016)<br />
*<code>'yyyy'</code>: Jahr als vierstellige Zahl (z.B. 2016)<br />
*<code>'LF'</code>: Fügt einen Zeilenumbruch hinzu<br />
<br />
Beispiel: Der String <code>'MMM\LF\yyyy'</code> zeigt <code>'Jan'</code> in der ersten, und <code>'2016'</code> in der zweiten Zeile. <code>'MM.dd 2016'</code> wird zu <code>'03.05 2016'</code>.<br />
<br />
===Fadenkreuz-Cursor===<br />
Der Fadenkreuz-Cursor zeigt die Momentanwerte, indem man ihn über die Graphen bewegt. In Desktop-Browsern reicht einfaches Bewegen der Maus. Unter iOS und Android wird der Cursor durch einfaches Tippen auf die neue Position bewegt.<br />
<br />
Mit dem Attribut '''data-cursorgroup''' können Graphen gruppiert werden. Am Cursor werden dann die Momentanwerte aller Graphen gleichzeitig angezeigt, die die selbe Zahl besitzen, sobald man die Maus über einen aus der Gruppe bewegt.<br />
<br />
===Legende===<br />
Mit dem Attribut '''data-legendpos''' kann die Position der Legende innerhalb des Diagramms festgelegt werden. Die Position wird mit einem Array, bestehend aus zwei Werten im Format <code>'["<horizontal>","<vertikal>"]'</code> angegeben. Für die horizontale Positionierung sind <code>'left'</code>, <code>'right'</code>, <code>'before'</code>, und <code>'behind'</code>, die vertikale Positionierung <code>'top'</code>, <code>'bottom'</code>, <code>'above'</code>, <code>'below'</code> erlaubt (der Unterschied zwischen <code>'left'</code> und <code>'before'</code> liegt darin, dass im zweiten Fall die Legende nicht in den Zeichenbereich gesetzt wird sondern vor das ganze Chart (entsprechend für <code>'after'</code>, <code>'above'</code> und <code>'below'</code>). Alternativ können auch Zahlen verwendet werden, die die Position in Prozent angeben. Durch verschieben mit der Maus oder durch verschieben mit dem Finger oder Stift auf Touch Devices kann die Legende auch an eine andere Position verschoben werden.<br />
<br />
Wenn die Legende eingeblendet ist, kann mittels Klick auf einen Legendeneintrag der zugehörige Graph ein- und ausgeblendet werden.<br />
<br />
===3-dimensionale Drehung===<br />
'''data-ddd''' ermöglicht, den Graphen 3-dimensional zu drehen. Als Wert wird ein Array mit den 3 Winkeln für x, y und z erwartet, wobei z selbst bisher nicht unterstützt wird.<br />
<br />
Beispiel: <code>data-ddd='["40","60","0"]'</code>. <br />
<br />
Wenn der 3D Modus aktiv ist ('''data-ddd''' gesetzt) sind 2 zusätzliche Parameter verfügbar um das Aussehen der Graphen zu beeinflussen. '''data-dddspace''' gibt an, wie viele pixel der Raum zwischen den einzelnen in z-Richtung hintereinander angeordneten Graphen betragen soll.<br />
'''data-dddwidth''' legt fest, wie viele pixel die einzelnen Graphen tief (oder dick) sein sollen.<br />
<br />
Wenn das Array angegeben wird, erscheinen zwei zusätzliche Buttons im Diagramm, mit denen die Drehung in X- und Y-Richtung verändert werden kann.<br />
<br />
===Diagrammtitel===<br />
Mit dem Attribut '''data-title''' kann dem Diagramm, ähnlich wie in FHEM-SVG-Plots, ein Titel hinzugefügt werden.<br />
<br />
Folgende Platzhalter werden unterstützt:<br />
*<code>'min1'</code>: Minimaler Y-Wert des ersten Graphs<br />
*<code>'max1'</code>: Maximaler Y-Wert des ersten Graphs<br />
*<code>'avg1'</code>: Mittlerer Y-Wert des ersten Graphs<br />
*<code>'cnt1'</code>: Anzahl der dargestellten Einzelwerte im ersten Graph<br />
*<code>'currval1'</code>: Letzter, bzw. aktuellster Y-Wert des ersten Graphs<br />
*<code>'mindate1'</code>: Niedrigster Wert auf der X-Achse des ersten Graphs<br />
*<code>'maxdate1'</code>: Höchster Wert auf der X-Achse vom ersten Graphs<br />
*<code>'currdate1'</code>: Letzter, bzw. aktuellster Wert auf der X-Achse des ersten Graphs<br />
<br />
Durch Einsetzen einer anderen Zahl statt '1' können auch die Werte der anderen Graphen angezeigt werden. Das Weglassen der Zahl bewirkt, dass der jeweils zutreffende Wert automatisch ermittelt wird. Bedeutet: <code>max</code> führt dazu, dass der höchste Wert aller angezeigter Graphen verwendet wird.<br />
Zusätzlich ist es möglich durch "$eval(<regexp>)" regular Expressions auszuwerten (also z.B. Berechnungen durchzuführen). In <regexp> können auch "$data()" vorkommen.<br />
<br />
Beispiel: <code>data-title="Klima Wohnzimmer Average: $eval(parseInt($data{avg1}*10)/10)°C / Max: $eval(parseInt($data{max1}*10)/10)°C"</code><br />
<br />
===Buttons im Diagramm===<br />
Es gibt mehrere Buttons, mit denen sich die Anzeige des Diagramms verändern lässt. <code><-</code> und <code>-></code> bewegen die Graphen nach links und rechts. <code>+</code> und <code>-</code> zoomen die Anzeige. <code>legend</code> und <code>cursor</code> schalten die zugehörigen Anzeigen ein und aus. Falls der 3D Modus eingeschaltet ist, gibt es Buttons zum Drehen der Darstellung um die X- und Y-Achse. Falls <code>data-timeranges</code> gesetzt ist, wird ein Pulldown Menü dargestellt, welches die Auswahl von dort definierten Zeiträumen für die X-Achse erlaubt.<br />
<br />
==Beispiele==<br />
===Einfaches Diagramm===<br />
Das Beispiel zeigt ein einfaches Diagramm mit 4 unterschiedlich formatierten Graphen, Legende und Momentanwerten am Fadenkreuz-Cursor.<br />
<br />
[[File:Chart_tabletUI.png]]<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-logdevice='["Log.Garden","Log.Garden","Log.Garden","Log.Predicted"]'<br />
data-columnspec='["4:Garden.T:15:","10:Garden.T:0:delta-h","10:Garden.T:0:delta-d","4:predicted.*:15:"]'<br />
data-style='["ftui l0fill","ftui l1fill","ftui l2","ftui l3dot"]'<br />
data-ptype='["lines","histeps","histeps","cubic"]'<br />
data-uaxis='["primary","secondary","secondary","primary"]'<br />
data-legend='["Temperature","Rain/hour","Rain/day","Predicted Temp."]'<br />
data-yunit="°C"<br />
data-ytext="Temperature"<br />
data-minvalue="auto"<br />
data-maxvalue="auto"<br />
data-yunit_sec="mm"<br />
data-ytext_sec="Rain (mm)"<br />
data-height="250"<br />
data-yticks="auto"<br />
data-minvalue_sec="auto"<br />
data-maxvalue_sec="auto"<br />
data-nofulldays="true"<br />
data-daysago_start="2013-08-13T00:00:00"<br />
data-daysago_end="2013-08-14T00:00:00"<br />
data-cursorgroup="1"<br />
data-scrollgroup="1"<br />
data-xticks="auto"><br />
</div><br />
</syntaxhighlight><br />
<br />
===7-Tage-Wettervorhersage mit Proplanta===<br />
In diesem Beispiel wird gezeigt, wie die Vorhersagewerte von [[PROPLANTA]] in einem Diagramm dargestellt werden können. Da die Werte nicht in einer Datenbank oder einem FileLog vorliegen, müssen sie über [[LogProxy]] verarbeitet werden. Dafür sind einige Vorbereitungen in FHEM nötig.<br />
<br />
[[File:FTUI_Widget_Chart-fc-Proplanta.png|941px]]<br />
<br />
'''1.''' Ein LogProxy-Device muss vorhanden sein:<br />
<pre><br />
define myLogProxy logProxy<br />
</pre><br />
<br />
'''2.''' In der Datei <code>99_myUtils.pm</code> muss folgende Routine hinzugefügt werden, die die Daten bereitstellt:<br />
<syntaxhighlight lang="perl"><br />
#---------------------------------------<br />
# Proplanta LogProxy-Funktion<br />
#---------------------------------------<br />
sub logProxy_proplanta2Plot($$$$;$$) {<br />
my ($device, $fcValue, $from, $to, $fcHour, $expMode) = @_;<br />
my $regex;<br />
my @rl;<br />
<br />
return undef if(!$device);<br />
<br />
if($fcValue =~ s/_$//) {<br />
$regex = "^fc[\\d]+_".$fcValue."[\\d]{2}\$";<br />
}<br />
else {<br />
$regex = "^fc[\\d]+_".$fcValue."\$";<br />
}<br />
<br />
$fcHour = 12 if(!defined $fcHour);<br />
$expMode = "point" if(!defined $expMode);<br />
<br />
if( defined($defs{$device}) ) {<br />
if( $defs{$device}{TYPE} eq "PROPLANTA" ) {<br />
@rl = sort{<br />
my ($an) = ($a =~ m/fc(\d+)_.*/);<br />
my ($bn) = ($b =~ m/fc(\d+)_.*/);<br />
$an <=> $bn or $a cmp $b;<br />
}( grep /${regex}/,keys %{$defs{$device}{READINGS}} );<br />
return undef if( !@rl );<br />
} else {<br />
Log3 undef, 2, "logProxy_proplanta2Plot: $device is not a PROPLANTA device";<br />
return undef;<br />
}<br />
}<br />
<br />
my $fromsec = SVG_time_to_sec($from);<br />
my $tosec = SVG_time_to_sec($to);<br />
my $sec = $fromsec;<br />
my ($h,$fcDay,$mday,$mon,$year);<br />
my $timestamp;<br />
<br />
my $reading;<br />
my $value;<br />
my $prev_value;<br />
my $min = 999999;<br />
my $max = -999999;<br />
my $ret = "";<br />
<br />
# while not end of plot range reached<br />
while(($sec < $tosec) && @rl) {<br />
#remember previous value for start of plot range<br />
$prev_value = $value;<br />
<br />
$reading = shift @rl;<br />
($fcDay) = $reading =~ m/^fc(\d+).*/;<br />
$h = ($reading =~ m/.*(\d\d)$/)?$1:$fcHour;<br />
$value = ReadingsVal($device,$reading,undef);<br />
<br />
($mday,$mon,$year) = split('\.',ReadingsVal($device,"fc".$fcDay."_date",undef));<br />
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, $h, 0, 0);<br />
$sec = SVG_time_to_sec($timestamp);<br />
<br />
# skip all values before start of plot range<br />
next if( SVG_time_to_sec($timestamp) < $fromsec );<br />
<br />
# add first value at start of plot range<br />
if( !$ret && $prev_value ) {<br />
$min = $prev_value if( (looks_like_number($prev_value) && ($prev_value < $min)) || ($prev_value lt $min) );<br />
$max = $prev_value if( (looks_like_number($prev_value) && ($prev_value > $max)) || ($prev_value gt $max) );<br />
$ret .= "$from $prev_value\n";<br />
}<br />
<br />
# done if after end of plot range<br />
last if($sec > $tosec);<br />
<br />
$min = $value if( (looks_like_number($value) && ($value < $min )) || ($value lt $min) );<br />
$max = $value if( (looks_like_number($value) && ($value > $max )) || ($value gt $max) );<br />
<br />
# add actual controll point<br />
$ret .= "$timestamp $value\n";<br />
<br />
# Log 1, "$timestamp $value -0- $reading";<br />
}<br />
if(($sec < $tosec) && !@rl && ($expMode eq "day")) {<br />
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, 23, 59, 59);<br />
if(SVG_time_to_sec($timestamp) < $tosec) {<br />
$ret .= "$timestamp $value\n";<br />
}<br />
else {<br />
$ret .= "$to $value\n";<br />
}<br />
}<br />
elsif(($sec > $tosec) && ($expMode eq "day")) {<br />
$value = $prev_value + ($value - $prev_value)*(86400 + ($tosec - $sec))/86400;<br />
$ret .= "$to $value\n";<br />
}<br />
return ($ret,$min,$max,$prev_value);<br />
}<br />
</syntaxhighlight><br />
<br />
Anschließend können die Daten im Chart-Widget angezeigt werden. Der Device-Name von Proplanta heißt hier im Beispiel <code>AU.xx.WE.Proplanta</code>.<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="AU.xx.WE.Proplanta"<br />
data-logdevice='[<br />
"myLogProxy",<br />
"myLogProxy",<br />
"myLogProxy"<br />
]'<br />
data-columnspec='[<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22rain_\\x22,$from,$to,12,\\x22day\\x22)",<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22chOfRain_\\x22,$from,$to,12,\\x22day\\x22)",<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22cloud_\\x22,$from,$to,12,\\x22day\\x22)"<br />
]'<br />
data-style='[<br />
"ftui l6fill",<br />
"ftui l5fill",<br />
"ftui l1fill"<br />
]'<br />
data-ptype='[<br />
"steps",<br />
"quadraticSmooth",<br />
"quadraticSmooth"<br />
]'<br />
data-uaxis='[<br />
"primary",<br />
"secondary",<br />
"secondary"<br />
]'<br />
data-legend='[<br />
"Regen",<br />
"Regenwahrscheinlichkeit",<br />
"Wolken"<br />
]'<br />
data-yunit="mm"<br />
data-ytext="Regen"<br />
data-yunit_sec="%"<br />
data-ytext_sec="Chance auf Regen / Wolken"<br />
data-timeformat="eeee"<br />
data-minvalue="auto"<br />
data-maxvalue="auto"<br />
data-minvalue_sec="auto"<br />
data-maxvalue_sec="auto"<br />
data-daysago_start = "0"<br />
data-daysago_end = "-7"<br />
data-xticks="1440"<br />
data-yticks="auto"<br />
data-title="7-Tage-Wettervorhersage"<br />
data-showlegend="true"<br />
class="nobuttons fullsize"><br />
</div><br />
</syntaxhighlight><br />
<br />
'''Hilfreiche Links und Quellen zu diesem Beispiel:'''<br />
*[[LogProxy|LogProxy im FHEM-Wiki]]<br />
*{{Link2Forum|Topic=22967|Message=246973|LinkText=Stundengenaue Wettervorhersage (#1) im FHEM-Forum}}<br />
*{{Link2Forum|Topic=22967|Message=334713|LinkText=Stundengenaue Wettervorhersage (#2) im FHEM-Forum}}<br />
<br />
===Darstellung der Wetter Icons im Diagramm===<br />
<br />
[[File:Wetterchart2.png]]<br />
<br />
Wie oben bereits beschrieben, gibt es beim Chart grundsätzlich die Möglichkeit, Icons, welche in Form von URLs in den Logs abgelegt sind oder welche per logProxy generiert werden, darzustellen. Die Icons werden auf genau dem gleichen Weg von FHEM gelesen, wie alle anderen Datenpunkte. Im Folgenden wird ein Beispiel gezeigt, mit dem die im Proplanta Modul als Readings abgelegten Icons per logProxy Funktion gelesen und in ein Chart eingebaut werden könnnen.<br />
Da es beim Proplanta Modul für die ersten 7 Tage nicht das Reading <code>fc#_weatherIcon</code> gibt, sondern mehrere Readings für unterschiedliche Tageszeiten wogegen für die zweiten 7 Tage ausschließlich das Reading <code>fc#_weatherIcon</code> vorhanden ist, sollte per <code>attr device userReading</code> mit folgendem Eintrag dafür gesorgt werden, dass für alle Tage ein Reading <code>fc#_weatherIcon</code> vorhanden ist (alternativ könnten auch 2 Graphen gezeichnet werden, wobei der erste dann nur die ersten 7 Tage enthält und der zweite die letzen 7 Tage, will man nur die ersten 7 Tage darstellen braucht man das userReading nicht unbedingt).<br />
<syntaxhighlight lang="perl"><br />
fc0_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc0_weatherDayIcon","");},<br />
fc1_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc1_weatherDayIcon","");},<br />
fc2_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc2_weatherDayIcon","");},<br />
fc3_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc3_weatherDayIcon","");},<br />
fc4_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc4_weatherDayIcon","");},<br />
fc5_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc5_weatherDayIcon","");},<br />
fc6_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc6_weatherDayIcon","");}<br />
</syntaxhighlight><br />
Um die Icons darzustellen muss ein zusätzlicher Graph definiert werden. Dieser nutzt neben der Columnspec, die die URLs abruft den Parameter <code>data-ptype="icons:#"</code> (# ist eine Zahl und steht für die Nummer, beginnend bei 0 des Graphen, welcher für die y-Position der Icons verwendet werden soll) und den Stil <code>sym</code>. Der Wert für die Symbolgröße sollte z.B. durch eine zusätzliche Definition im File fhem-tablet-ui-user.css in der Form:<br />
<syntaxhighlight lang="css"><br />
/* icon lines */<br />
.ftui.l99icon { stroke:#DDA400; stroke-width:48px; fill:none; }<br />
</syntaxhighlight><br />
angepasst werden.<br />
<br />
Im folgenden ein Beispiel, welches eine Linie für die Maximale Tagestemperatur zeichnet und auf dieser Linie die Wetter Icons darstellt.<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="AU.xx.WE.Proplanta"<br />
data-logdevice='[<br />
"myLogProxy",<br />
"myLogProxy"<br />
]'<br />
data-columnspec='[<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22weatherIcon\\x22,$from,$to,12,\\x22day\\x22)",<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22tempMax\\x22,$from,$to,12,\\x22day\\x22)"<br />
]'<br />
data-style='[<br />
"ftui l99icon",<br />
"ftui l1fill"<br />
]'<br />
data-ptype='[<br />
"icons:1",<br />
"quadraticSmooth"<br />
]'<br />
data-uaxis='[<br />
"primary",<br />
"primary"<br />
]'<br />
data-legend='[<br />
"Wetterbedingung",<br />
"Max. Temperature"<br />
]'<br />
data-yunit="°C"<br />
data-ytext="Temperature (°C)"<br />
data-timeformat="ee\LF\dd.MM"<br />
data-minvalue="auto"<br />
data-maxvalue="auto"<br />
data-minvalue_sec="auto"<br />
data-maxvalue_sec="auto"<br />
data-daysago_start="-1w"<br />
data-y_margin="20"<br />
data-daysago_end="-3w"<br />
data-xticks="1440"<br />
data-yticks="auto"<br />
data-title="14-Tage-Wettervorhersage"<br />
data-showlegend="true"<br />
class="nobuttons fullsize"><br />
</div><br />
</syntaxhighlight><br />
<br />
===Kuchendiagramme===<br />
In folgendem Beispiel wird gezeigt, wie man ein "Kuchendiagramm" darstellen kann.<br />
<br />
[[File:PieChart.png]]<br />
<br />
Ähnlich wie bei den Beispielen für die Wetter Darstellungen wird hierzu auch wieder logProxy benötigt. Zunächst muss die folgende zusätzliche Funktion in <code>99_myUtils.pm</code> einfügen.<br />
<syntaxhighlight lang="perl"><br />
#---------------------------------------<br />
# Funktion zum Erzeugen der Inputs für Kuchendiagramme<br />
#---------------------------------------<br />
sub logProxy_values2PieChart($$$$;$$) {<br />
my ($device, $reading, $angle_start, $angle_dif, $inner_rad, $show_text) = @_;<br />
Log3 undef, 1, "$device, $reading, $angle_start, $angle_dif, $inner_rad, $show_text\n";<br />
<br />
use constant PI => 4 * atan2(1,1);<br />
<br />
my $value=ReadingsVal($device,$reading,0);<br />
<br />
my $angle_delta = $value/100*360;<br />
$angle_start = $angle_start/100*360;<br />
<br />
my $rad=10;<br />
my $irad=0;<br />
if ($inner_rad) {<br />
$irad = $rad*$inner_rad;<br />
}<br />
my $angle=$angle_start/360*2.0*PI;<br />
my $x=$irad*sin($angle);<br />
my $y=$irad*cos($angle);<br />
my $ret .= ";p ".$x." ".$y."\n"; # add segment at angle $angle<br />
<br />
for (my $i=$angle_start; $i<=$angle_start+$angle_delta; $i+=$angle_dif) {<br />
$angle = $i/360*2.0*PI;<br />
$x = $rad*sin($angle);<br />
$y = $rad*cos($angle);<br />
$ret .= ";p ".$x." ".$y."\n"; # add segment at angle $angle<br />
}<br />
<br />
$angle = ($angle_start+$angle_delta)/360*2.0*PI; # add last segment <br />
$ret .= ";p ".$rad*sin($angle)." ".$rad*cos($angle)."\n";<br />
<br />
if ($inner_rad) {<br />
for (my $i=$angle_start; $i<$angle_start+$angle_delta; $i+=$angle_dif) {<br />
$angle = ($angle_start+$angle_start+$angle_delta-$i)/360*2.0*PI;<br />
$x = $irad*sin($angle);<br />
$y = $irad*cos($angle);<br />
$ret .= ";p ".$x." ".$y."\n"; # add segment at angle $angle<br />
}<br />
}<br />
<br />
$angle = ($angle_start)/360*2.0*PI; # add last segment <br />
$ret .= ";p ".$irad*sin($angle)." ".$irad*cos($angle)."\n";<br />
<br />
if ($show_text) { # show text values<br />
$x = ($rad+$irad)/2*sin((2*$angle_start+$angle_delta)/2/360*2.0*PI);<br />
$y = ($rad+$irad)/2*cos((2*$angle_start+$angle_delta)/2/360*2.0*PI);<br />
<br />
$ret .= ";t ".$x." ".$y." middle ".$show_text.":".$value."%\n";<br />
}<br />
<br />
return($ret);<br />
}<br />
</syntaxhighlight><br />
In FHEM braucht man Readings, welche eine Zahl enthalten, die als Prozentwert interpretiert wird. Für jeden Prozentwert (also für jedes Reading) generiert die o.a. Funktion nun den Chart Input für ein Kuchenstück und liefert diesen als Antwort auf das GET, welches das Chart Widget auslöst. Dazu braucht die Funktion folgende Parameter: (Name des FHEM Devices, Name des Readings, Start Winkel des Kuchenstücks (Mathematisch gegen den Uhrzeigersinn in Grad), Delta Winkel zum Zeichnen (legt fest in welchen Schritten der Teilkreis des Kuchenstücks gezeichnet wird), Skalierungsfaktor für inneren Ring wenn ein Ring gezeichtnet werden soll (0 bedeutet komplette Kuchenstücke), optionaler Text der ins Kuchenstück vor die Prozentzahl geschrieben wird).<br />
Im Folgenden eine Beispielkonfiguration für die Darstellung als Kuchendiagramm, die Readings heißen hier dPer1 bis dPer4. Der Startwinkel wird duch Aufsummierung der jeweils vorher schon gezeichneten Kuchenstücke gebildet, dadurch entstehen aneinander hängende Stücke.<br />
<syntaxhighlight lang="html"><br />
[[Datei:[[Datei:Beispiel.jpg]]]]<div class="normal noaxes nobuttons"<br />
data-type="chart"<br />
data-logdevice='["lp"]'<br />
data-logfile="CURRENT"<br />
data-columnspec='[<br />
"Func:logProxy_values2PieChart(\"dPer1\",\"state\",ReadingsVal(\"dPer4\",\"state\",0)+ReadingsVal(\"dPer3\",\"state\",0),5,0,\"first\")",<br />
"Func:logProxy_values2PieChart(\"dPer2\",\"state\",ReadingsVal(\"dPer4\",\"state\",0)+ReadingsVal(\"dPer3\",\"state\",0)+ReadingsVal(\"dPer1\",\"state\",0),5,0,\"second\")",<br />
"Func:logProxy_values2PieChart(\"dPer3\",\"state\",ReadingsVal(\"dPer4\",\"state\",0),5,0,\"third\")",<br />
"Func:logProxy_values2PieChart(\"dPer4\",\"state\",0,5,0,\"fourth\")"<br />
]'<br />
data-style='["ftui l0fill","ftui l1fill","ftui l2fill","ftui l3fill"]'<br />
data-ptype='["lines"]'<br />
data-uaxis='["primary"]'<br />
data-legend='["First","Second","Third","Fourth"]'<br />
data-legendpos='["left","top"]'<br />
data-yunit=""<br />
data-height="300"<br />
data-width="300"<br />
data-ddd='["-40","0","0"]'<br />
data-dddspace='["-10"]'<br />
data-dddwidth='["10"]'<br />
data-showlegend="true"<br />
data-legend_horiz="true"<br />
data-xticks="auto"><br />
</div><br />
</syntaxhighlight><br />
<br />
===Fensterstatus offen/geschlossen===<br />
Dieses Beispiel zeigt, wie ein Fensterkontakt, dessen Reading die Werte <code>closed</code> und <code>open</code> einnimmt, als Graph gezeichnet werden kann. Technisch gesehen werden hier die Werte <code>0</code> und <code>1</code> gezeichnet, indem über das Attribut '''data-columnspec''' dem Zustand <code>open</code> der Wert <code>1</code> und allen anderen Zuständen der Wert <code>0</code> zugeordnet wird. Über das Attribut '''data-yticks''' wird die Beschriftung an der Y-Achse (<code>0</code> und <code>1</code>) gegen einen frei definierbaren Text ausgetauscht.<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="wz_fensterstatus"<br />
data-logdevice='["myDbLog"]'<br />
data-logfile='["HISTORY"]'<br />
data-columnspec='["wz_fensterstatus:state:0::$val=($val=~\\x22open\\x22?1:0)"]'<br />
data-style='["ftui l4fill"]'<br />
data-ptype='["steps"]'<br />
data-height="290"<br />
data-yticks='[[0,"geschlossen"],[1,"offen"]]'<br />
data-minvalue="0"<br />
data-maxvalue="1.1"<br />
data-nofulldays="true"<br />
data-daysago_start="1"<br />
data-daysago_end="-1"<br />
data-cursorgroup="1"<br />
data-scrollgroup="1"><br />
</div><br />
</syntaxhighlight><br />
<br />
'''Hinweis:''' Das Beispiel funktioniert nur mit DbLog. Falls Logfiles verwendet werden muss statt '$val' '$fld[''num'']' verwendet werden. Hierbei steht ''num'' für die Spalte (beginnend bei 0) in der die Daten stehen.<br />
<br />
==Links==<br />
{{Link2Forum|Topic= 48450 |Message=401006|LinkText=Thread im FHEM-Forum}}<br />
<br />
[[Kategorie:FHEM Tablet UI|Chart]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=FTUI_Widget_Chart&diff=37163FTUI Widget Chart2022-01-28T16:25:26Z<p>F Klee: /* Fadenkreuz-Cursor */</p>
<hr />
<div>Das [[{{PAGENAME}}|Chart Widget]] ist ein Widget für [[FHEM Tablet UI]], mit dem sich verschiedenste Diagramme darstellen lassen. Die Aneinanderreihung mehrerer Werte eines Device-Readings zu einem zeitlichen Verlauf wird dabei als Graph bezeichnet.<br />
<br />
Es können beliebige Werte dargestellt und entsprechend der Sinnhaftigkeit, oder persönlichem Geschmack, formatiert werden. Farbe und Form der Linien sind je Graph einstellbar, auch wenn mehrere gleichzeitig in einem Diagramm angezeigt werden.<br />
<br />
Jedes Diagramm kann zwei Y-Achsen besitzen. Die primäre Y-Achse (primary) wird auf der linken Seite angezeigt, die sekundäre Y-Achse (secondary) auf der rechten Seite. Beide Achsen können unterschiedlich formatiert werden.<br />
<br />
<gallery><br />
File:Chart_tabletUI.png<br />
Datei:FTUI Widget Chart Stacked.png<br />
Datei:FTUI Widget Chart-fc-Proplanta.png<br />
Datei:Wetterchart2.png<br />
Datei:PieChart.png<br />
</gallery><br />
<br />
==Attribute==<br />
{| class="wikitable"<br />
! style="width:150px" |Attribut<br />
!Beschreibung<br />
!Standard-Wert<br />
!Beispiel<br />
|-<br />
|'''data-device'''||Name des FHEM-Device, das die Aktualisierung des Charts triggert||||data-device="WohnzimmerHeizung"<br />
|-<br />
|'''data-get'''||Reading, das das Update des Diagramms triggert||'STATE'||<br />
|-<br />
|'''data-logdevice'''||Name des Log-Device, das dargestellt werden soll, oder ein Array, um mehrere Werte in einem Diagramm darzustellen||||data-logdevice="FileLog_WohnzimmerHeizung"<br />
|-<br />
|'''data-logfile'''|| Name des Log-Files, aus dem die Daten entnommen werden sollen (oder Array)||'-' = aktuelle Datei||data-logfile="WohnzimmerHeizung-2015.log"<br>Beachte: Der Wert "CURRENT" ermöglicht die Navigation auch zu älterne Logfiles (Jahreswechsel)<br />
|-<br />
|'''data-columnspec'''||Ermittelt den Wert aus dem Log-File, der angezeigt werden soll (oder Array)||||data-columnspec="4:meas.*"<br />
|-<br />
|'''data-style'''||Stil, wie die Graph-Linien dargestellt werden sollen (z.B. 'SVGplot l0' oder 'ftui l0dash'), oder ein Array, wenn mehrere Linien unterschiedlich dargestellt werden sollen (siehe [[#Aussehen_der_Linien|Hinweise]])||||<br />
|-<br />
|'''data-ptype'''||Form, wie die Graphen dargestellt werden sollen (z.B. 'lines', 'cubic' oder 'fa-cog'), oder ein Array (siehe [[#Form_der_Linien|Hinweise]])||'lines'||<br />
|-<br />
|'''data-uaxis'''||Name der Achse, die verwendet werden soll ('primary' = links, oder 'secondary' = rechts), oder ein Array||'primary'||<br />
|-<br />
|'''data-legend'''||Bezeichnung des Graphen (wird in Legende und am Cursor angezeigt), oder ein Array||||<br />
|-<br />
|'''data-minvalue'''||Minimaler Wert, der auf der linken Y-Achse ('primary') angezeigt werden soll. 'auto' = automatische Berechnung||'10'||<br />
|-<br />
|'''data-maxvalue'''||Maximaler Wert, der auf der linken Y-Achse ('primary') angezeigt werden soll. 'auto' = automatische Berechnung||'30'||<br />
|-<br />
|'''data-minvalue_sec'''||Minimaler Wert, der auf der rechten Y-Achse ('secondary') angezeigt werden soll. 'auto' = automatische Berechnung||'auto'||<br />
|-<br />
|'''data-maxvalue_sec'''||Maximaler Wert, der auf der rechten Y-Achse ('secondary') angezeigt werden soll. 'auto' = automatische Berechnung||'auto'||<br />
|-<br />
|'''data-xticks'''||Abstand zwischen den vertikalen Hilfslinien (bezogen auf die X-Achse) in Minuten. 'auto' = automatische Berechnung||'auto'||<br />
|-<br />
|'''data-yticks'''||Abstand zwischen den horizontalen Hilfslinien (bezogen auf die linke Y-Achse). Kann auch ein Array mit Werte-Paaren enthalten, um die Linien mit Text zu beschriften.||'auto'||data-yticks='[[0,"open"],[1,"closed"]]'<br />
|-<br />
|'''data-yticks_format'''||Dient zur Formatierung der Ticks der Y-Achse. Die Formatierung geschieht über Platzhalter, Trenner und einen beliebigen durch ' ' getrennten Text. Als Platzhalter dient ein oder mehrere '#', als Trenner können '.', ',' und ':' verwendet werden. Ist ein Trenner enthalten (z.B. '#.##') dann bedeutet das in dem Beispiel, dass der Ytick mit 2 Nachkommastellen versehen wird und vorne Platz für eine Stelle vor dem Komma vorgehalten wird (führende Nullen werden nicht dargestellt, aber de Platz wird reserviert so dass das ganze rechtsbündig immer passt). Ist kein Trenner vorhanden, dann wird der Ytick auf die Summe der Platzhalter mit einer festen Gesamtbreite gesetzt (#### würde also bedeuten, dass immer 4 Stellen (ohne Trenner) verwendet werden. aus 0.4 würde 0.400 aus 10.437 würde 10.44). Als Trenner kann man z.B. für Zeiten auch einen ':' verwenden und dadurch auch so etwas wie "12:00 Uhr" realisieren (in dem Beispiel wäre data-yticks_format="##:## Uhr" und kein data-yunit oder data-yticks="##:##" und data-yunit="Uhr").||||data-yticks_format="#.##"<br />
|-<br />
|'''data-yticks_sec'''||Abstand zwischen den horizontalen Hilfslinien (bezogen auf die rechte Y-Achse). Kann auch ein Array mit Werte-Paaren enthalten, um die Linien mit Text zu beschriften.||'auto'||data-yticks='[[0,"open"],[1,"closed"]]'<br />
|-<br />
|'''data-yticks_format_sec'''||Dient zur Formatierung der Ticks der Y-Achse. Die Formatierung geschieht über Platzhalter, Trenner und einen beliebigen durch ' ' getrennten Text. Als Platzhalter dient ein oder mehrere '#', als Trenner können '.', ',' und ':' verwendet werden. Ist ein Trenner enthalten (z.B. '#.##') dann bedeutet das in dem Beispiel, dass der Ytick mit 2 Nachkommastellen versehen wird und vorne Platz für eine Stelle vor dem Komma vorgehalten wird (führende Nullen werden nicht dargestellt, aber de Platz wird reserviert so dass das ganze rechtsbündig immer passt). Ist kein Trenner vorhanden, dann wird der Ytick auf die Summe der Platzhalter mit einer festen Gesamtbreite gesetzt (#### würde also bedeuten, dass immer 4 Stellen (ohne Trenner) verwendet werden. aus 0.4 würde 0.400 aus 10.437 würde 10.44). Als Trenner kann man z.B. für Zeiten auch einen ':' verwenden und dadurch auch so etwas wie "12:00 Uhr" realisieren (in dem Beispiel wäre data-yticks_format="##:## Uhr" und kein data-yunit oder data-yticks="##:##" und data-yunit="Uhr").||||data-yticks_format_sec="#.##"<br />
|-<br />
|'''data-yticks_prio'''||Legt fest, ob die horizontalen Hilfslinien der linken (primary) oder der rechten (secondary) Y-Achse zugeordnet werden sollen||||data-yticks_prio='secondary'<br />
|-<br />
|'''data-ytype'''||Legt fest, ob die primäre y Achse logarithmisch sein soll (wert "log")||||data-ytype="log"<br />
|-<br />
|'''data-ytype_sec'''||Legt fest, ob die sekundäre y Achse logarithmisch sein soll (wert "log")||||data-ytype_sec="log"<br />
|-<br />
|'''data-margin'''|||Abstand zwischen Buttons und Chart (Einheit Pixel). ||"0"|||data-margin="10"<br />
|-<br />
|'''data-y_margin'''|||Gibt die Möglichkeit, Abstände zwischen den Graphen und dem oberen Rand des Plots zu definieren (Einheit Pixel). Falls der Wert skalar ist, werden oben und unten die gleichen Abstände eingehalten. Falls ein 2D Array angegeben wird, können die Werte unten (erster Wert im Array) und oben (zweiter Wert im Array) getrennt festgelegt werden||"0"|||data-y_margin='["10","20"]'<br />
|-<br />
|'''data-y_margin_sec'''|||Gibt die Möglichkeit, Abstände zwischen den Graphen und dem oberen Rand des Plots zu definieren (Einheit Pixel). Falls der Wert skalar ist, werden oben und unten die gleichen Abstände eingehalten. Falls ein 2D Array angegeben wird, können die Werte unten (erster Wert im Array) und oben (zweiter Wert im Array) getrennt festgelegt werden||"0"|||data-y_margin='["10","20"]'<br />
|-<br />
|'''data-daysago_start'''||Anzahl der vergangenen Tage, wo das Diagramm beginnen soll. '0' = Beginn heute 0:00 Uhr. (siehe [[#Zeitstrahl_.2F_Start_.26_Ende_auf_der_X-Achse|Hinweise]])||'0'||<br />
|-<br />
|'''data-daysago_end'''||Anzahl der vergangenen Tage, wo das Diagramm enden soll. '-1' = Ende heute 24:00 Uhr. (siehe [[#Zeitstrahl_.2F_Start_.26_Ende_auf_der_X-Achse|Hinweise]])||'-1'||<br />
|-<br />
|'''data-xticks_round'''||Wenn vorhanden und entweder 'h', 'd', 'w', wird auf Stunde, Tag oder Woche bei den xticks gerundet (also die Tickmarks und die Gridlines bei den entsprechend gerundeten Zeiten gesetzt). Es kann auch 'auto' angegeben werden, um eine autmoatische Rundung durchzuführen||||<br />
|-<br />
|'''data-nofulldays'''||Aktiviert/deaktiviert die Rundung der X-Achse auf ganze Tage. Binärwert ('true' oder 'false')||'false'||<br />
|-<br />
|'''data-timeformat'''||Zeitformat für die Anzeige an der X-Achse (siehe [[#Zeitformat_der_X-Achse|Hinweise]])||||<br />
|-<br />
|'''data-timeranges'''||Hierdurch können vordefinierte Zeiträume für die X-Achse festgelegt werden, die dann durch eine pulldown menu (neuer Button oben neben dem "-" Button) direkt ausgewählt werden können. Der Parameter ist ein Array aus Array Einträgen, welche jeweils [<Name>,<daysago_start>,<daysago_end>] enthalten)||<br />
||data-timeranges='[<br><br />
["Actual Year","0Y","-1Y"],<br><br />
["Last Year","1Y","0Y"],<br><br />
["Actual Month","0M","-1M"],<br><br />
["Last Month","1M","0M"],<br><br />
["Actual Week","0W","-1W"],<br><br />
["Last Week","1W","0W"],<br><br />
["Today","0D","-1D"],<br><br />
["Yesterday","1D","0D"]<br><br />
]'<br />
|-<br />
|'''data-ytext'''||Text, der neben der linken Y-Achse angezeigt wird||||<br />
|-<br />
|'''data-ytext_sec'''||Text, der neben der rechten Y-Achse angezeigt wird||||<br />
|-<br />
|'''data-yunit'''||Einheit, die an der linken Y-Achse angezeigt wird||||<br />
|-<br />
|'''data-yunit_sec'''||Einheit, die an der rechten Y-Achse angezeigt wird||||<br />
|-<br />
|'''data-show_both_axes'''||Legt fest ob beide Y-Achsen Linien gezeichnet werden sollen||false||<br />
|-<br />
|'''data-crosshair'''||Aktiviert/deaktiviert den Fadenkreuz-Cursor. Binärwert ('true' oder 'false')||'false'||<br />
|-<br />
|'''data-cursorgroup'''||Zahl zur Gruppierung der Werte am Fadenkreuz-Cursor ([[#Fadenkreuz-Cursor|Hinweise]])||||<br />
|-<br />
|'''data-scrollgroup'''||Zahl zur Gruppierung der Graphen beim Bewegen und Zoomen. Alle Linien mit der selben Zahl werden miteinander gekoppelt und bewegen sich gemeinsam.||||<br />
|-<br />
|'''data-showlegend'''||Aktiviert/deaktiviert die Anzeige der Legene. Binärwert ('true' oder 'false')||'false'||<br />
|-<br />
|'''data-legendpos'''||Array von zwei Werten, die die horizontale und vertikale Position der Legende festlegen ([[#Legende|Hinweise]])||'["right","top"]'||<br />
|-<br />
|'''data-legend_horiz'''||legt fest, dass die Legendeneinträge horizontal angeordnet sind (anstatt vertikal wie im default Fall)||false||data-legend_horiz="true"<br />
|-<br />
|'''data-width'''||Breite des Diagramms (in % oder px)||||<br />
|-<br />
|'''data-height'''||Höhe des Diagramms (in % oder px)||||<br />
|-<br />
|'''data-graphsshown'''||Aktiviert/deaktiviert die initiale Anzeige von Graphen. Binärwert ('true' oder 'false'). Array, wenn mehrere Linien angezeigt werden sollen.||||data-graphsshown='[true,false,true]'<br />
|-<br />
|'''data-ddd'''||Einstellung für die 3D-Drehung ([[#3-dimensionale_Drehung|Hinweise]])||||data-ddd='["40","60","0"]'<br />
|-<br />
|'''data-dddspace'''||Abstand zwischen zwei Graphen, wenn die 3D-Anzeige aktiviert wurde (px)||'15'||<br />
|-<br />
|'''data-dddwidth'''||Breite, bzw. Tiefe der Graphen, wenn diese 3-dimensional angezeigt werden (px)||'10'||<br />
|-<br />
|'''data-title'''||Titel, der über dem Diagramm angezeigt werden soll. Der Inhalt kann auch dynamisch erzeugt werden ([[#Diagrammtitel|Hinweise]])||||<br />
|-<br />
|'''data-title_class'''||Klassenname für die Formatierung des Titels. Die Eigenschaften müssen dann entsprechend in einem CSS File angegeben werden (z.B. in fhem-tablet-ui-user.css)||||<br />
|-<br />
|'''data-prefetch'''||Legt fest, ob zusätzliche Daten rechts und links des Plots im Hintergrund vom Server geholt werden sollen||false||data-prefetch="true"<br />
|}<br />
Einige Parameter (style, maxvalue, minvalue, maxvalue_sec, minvalue_sec) können auch aus Readings dynamisch gesetzt werden wenn "<device>:<reading>" als Parameter gesetzt wird. Damit kann man z.B. in FHEM über notify etc. die Linientypen dynamisch anpassen (z.B. wenn der Wert eines Devices in einem bestimmten Bereich liegt, ändert sich die Farbe des Graphen).<br />
<br />
==CSS Klassen==<br />
{| class="wikitable"<br />
!Klasse!!Beschreibung<br />
{{FTUI Klasse|fullsize}}{{FTUI Klasse|noticks}}{{FTUI Klasse|nobuttons}}{{FTUI Klasse|small}}{{FTUI Klasse|normal}}{{FTUI Klasse|big}}<br />
|}<br />
<br />
Folgende Widget-spezifsche Klassen können zusätzlich in einer eigenen CSS-Datei definiert werden:<br />
<br />
{| class="wikitable"<br />
!Klasse<br />
!Beschreibung<br />
|-<br />
|'''chart-background'''||Hintergrundfarbe des Diagramms<br />
|-<br />
|'''buttons'''||Größe und Farbe der Buttons<br />
|-<br />
|'''text.axes'''||Generelle Schriftart und Farbe der Achsen<br />
|-<br />
|'''gridlines'''||Generelle Farbe und Größe der Gitternetzlinien<br />
|-<br />
|'''xaxis'''||Schriftart, Größe und Farbe der X-Achse<br />
|-<br />
|'''yaxis'''||Schriftart, Größe und Farbe der Y-Achse<br />
|-<br />
|'''xticks'''||Schriftart, Größe und Farbe der X-Achse (Zwischenlinien)<br />
|-<br />
|'''yticks'''||Schriftart, Größe und Farbe der Y-Achse (Zwischenlinien)<br />
|-<br />
|'''crosshair'''||Schriftart, Größe und Vordergrund/Hintergrundfarbe der Momentanwerte am Fadenkreuzcursor<br />
|-<br />
|'''caption'''||Schriftart, Größe und Farbe der Text-Buttons für Legende und Cursor<br />
|-<br />
|'''legend'''||Schriftart, Größe und Farbe der Legende<br />
|}<br />
<br />
Die Standardwerte sind in der Datei <code>css/ftui_chart.css</code> zu finden.<br />
<br />
==Datenquellen==<br />
Beim Chart-Widget können die gleichen Datenquellen genutzt werden, die auch für SVG-Plots verwendet werden können:<br />
# [[FileLog]]: Verlaufsdaten einer Textdatei entnehmen<br />
# [[DbLog]]: Verlaufsdaten einer Datenbank entnehmen<br />
# [[LogProxy]]: Daten dynamisch berechnet<br />
<br />
===FileLog===<br />
Um [[FileLog]] zu nutzen, wird als '''data-logdevice''' das FHEM-Device für das FileLog angegeben. In der Regel entstehen hier im Laufe der Zeit mehrere Log-Dateien. Name und Anzahl sind von der Definition abhängig - meist wird jeden Monat oder jedes Jahr eine neue Datei angelegt. Die gewünschte Datei kann mit '''data-logfile''' ausgewählt werden. Möchte man stets die aktuelle Datei verwenden (macht vor allem dann Sinn, wenn man die neusten Daten anzeigen will), kann das Attribut weggelassen, oder explizit <code>-</code> eingetragen werden. Zuletzt wird '''data-columnspec''' benötigt, um die gewünschten Daten zu in der Logdatei zu identifizieren. Hier wird die Spalte, in der die Daten stehen, gefolgt von Doppelpunkt und Readingname angegeben.<br />
<br />
Für ein Heizungsthermostat von Homematic mit dem Namen ''DG.wz.HZ.Heizungsventil'' ergibt sich somit beispielhaft folgende Definition, um gemessene Temperatur, Sollwert und Ventilstellung im Diagramm darzustellen:<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="DG.wz.HZ.Heizungsventil"<br />
data-logdevice="FileLog_DG.wz.HZ.Heizungsventil"<br />
data-logfile="-"<br />
data-columnspec='["4:measured-temp","4:desired-temp","4:actuator"]'<br />
...><br />
</div><br />
</syntaxhighlight><br />
<br />
Sollen Daten von unterschiedlichen Geräten in einem Diagramm angezeigt werden, muss '''data-logdevice''' als Array nach dem Schema <code>data-logdevice='["<Logdatei_1>","<Logdatei_2>","<Logdatei_3>"]'</code> definiert werden. Für jeden Eintrag in '''data-columnspec''' muss es auch den passenden Eintrag in '''data-logdevice''' geben (auch die Reihenfolge ist relevant).<br />
<br />
===DbLog===<br />
Um die Daten aus [[DbLog]] anzeigen zu können, werden die gleichen Attribute verwendet und mit für die Datenbank angepassten Werten beschrieben. Bei '''data-logdevice''' das FHEM-Device für die Datenbank angegeben. Im nachfolgenden Beispiel heißt diese <code>logdb</code> und besitzt wie üblich zwei Tabellen: <code>current</code> und <code>history</code> (der zeitliche Verlauf liegt in letzterer). Der Tabellenname wird bei '''data-logfile''' eingetragen. Da die Daten in der Datenbank etwas anders abgelegt werden, muss auch '''data-columnspec''' entsprechend angepasst werden. Statt der Spalte wird hier das FHEM-Device, gefolgt von Doppelpunkt und Readingname angegeben.<br />
<br />
Für das oben beschriebene Homematic-Heizungsthermostat ergibt sich dann folgende Definition, um die gleichen Daten aus einer Datenbank, statt einem LogFile zu lesen:<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="DG.wz.HZ.Heizungsventil"<br />
data-get="measured-temp"<br />
data-style='["ftui l0"]'<br />
data-logdevice="logdb"<br />
data-logfile="HISTORY"<br />
data-columnspec='["DG.wz.HZ.Heizungsventil:measured-temp","DG.wz.HZ.Heizungsventil:desired-temp","DG.wz.HZ.Heizungsventil:actuator"]'<br />
...><br />
</div><br />
</syntaxhighlight><br />
<br />
Für die Anzeige von unterschiedlichen Geräten in einem Diagramm, muss nur '''data-columnspec''' entsprechend angepasst werden, solange sich alle Daten in der Datenbank befinden.<br />
<br />
===LogProxy===<br />
Um die Daten mittels [[LogProxy]] berechnen und anzeigen zu können, muss in FHEM ein LogProxy-Device definiert sein:<br />
<br />
<pre><br />
define myLogProxy logProxy<br />
</pre><br />
<br />
Weitere Einstellungen am LogProxy sind nicht nötig, die bloße Existenz reicht.<br />
<br />
Bei '''data-logdevice''' wird das FHEM-Device für den LogProxy angegeben. Im nachfolgenden Beispiel heißt dieses <code>myLogProxy</code>. Das Attribut '''data-logfile''' wird für LogProxy nicht benötigt. Befinden sich nur LogProxy-Werte im Diagramm kann das Attribut komplett entfallen. Sollen weitere Werte angezeigt werden, bleibt die Definition im Array einfach leer.<br />
<br />
Im Attribut '''data-columnspec''' wird eine Formel angegeben, wie die Werte berechnet werden sollen. Hier können die Formeln 1:1 von einem eventuell vorhandenen SVG-Plot übernommen werden. '''Dabei gibt es jedoch folgendes zu beachten:''' Befindet sich die Formel in einem Array, dürfen die Formeln keine Anführungszeichen (<code>"</code>) beinhalten. Stattdessen müssen sie als escapter Ascii-Code (<code>\\x22</code>) eingefügt werden.<br />
<br />
Das nachfolgende Beispiel zeigt, wie Vorhersagewerte aus einem FHEM-Device vom Typ Proplanta (Name hier <code>AU.xx.WE.Proplanta</code>) angezeigt werden können.<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="AU.xx.WE.Proplanta"<br />
data-logdevice='[<br />
"myLogProxy",<br />
"myLogProxy",<br />
"myLogProxy",<br />
"myLogProxy"<br />
]'<br />
data-columnspec='[<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22temp_\\x22,$from,$to,12,\\x22day\\x22)",<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22rain_\\x22,$from,$to,12,\\x22day\\x22)",<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22chOfRain_\\x22,$from,$to,12,\\x22day\\x22)",<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22cloud_\\x22,$from,$to,12,\\x22day\\x22)"<br />
]'<br />
...><br />
</div><br />
</syntaxhighlight><br />
<br />
'''Auch alle anderen Funktionen, die [[LogProxy]] bietet, können hier angewendet werden.'''<br />
<br />
==Hinweise==<br />
===Aktualisierung des Charts===<br />
Damit der Refresh des Charts funktioniert, muss auch ein Device angegeben werden, der das Refresh triggert. Das Diagramm wird immer dann aktualisiert, wenn sich der Inhalt von '''data-get''' ändert.<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="WohnzimmerHeizung"<br />
data-logdevice="FileLog_WohnzimmerHeizung"<br />
...><br />
</div><br />
</syntaxhighlight><br />
<br />
===Aussehen der Linien===<br />
Mit dem Attribut '''data-style''' kann das Aussehen der Linien des jeweiligen Graphen verändert werden. Hierfür können die Standard-FHEM-Styles verwendet werden. Dazu wird das Attribut mit <code>SVGplot</code>, gefolgt von einem Leerzeichen und der gewünschten Farbe/Stil befüllt. Es existieren jedoch auch noch weitere, an FTUI angepasste Styles, zu finden in der CSS-Datei <code>css/ftui_chart.css</code>. Um diese zu verwenden, wird das Attribut mit <code>ftui</code>, gefolgt von einem Leerzeichen und der gewünschten Farbe/Stil befüllt. Eigene Styles können zum Beispiel in der Datei <code>css/fhem-table-ui-user.css</code> definiert werden.<br />
<br />
Folgende Übersicht zeigt die im Standard verfügbaren '''Farben''', alle Abbildungen sind mit im FTUI-Style entstanden:<br />
<div><ul> <br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f0.png|thumb|none|150px|Farbe "l0"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f1.png|thumb|none|150px|Farbe "l1"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f2.png|thumb|none|150px|Farbe "l2"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f3.png|thumb|none|150px|Farbe "l3"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f4.png|thumb|none|150px|Farbe "l4"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f5.png|thumb|none|150px|Farbe "l5"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Farbe-f6.png|thumb|none|150px|Farbe "l6"]] </li><br />
</ul></div><br />
<br />
Die Angabe zur Farbe kann dann mit der Linienart kombiniert werden. Dazu stehen folgende '''Stile''' zur Verfügung:<br />
<div><ul> <br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-2D-normal.png|thumb|none|225px|Darstellung in 2D: Stil "normal"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-2D-dot.png|thumb|none|225px|Darstellung in 2D: Stil "dot"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-2D-dash.png|thumb|none|225px|Darstellung in 2D: Stil "dash"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-2D-fill.png|thumb|none|225px|Darstellung in 2D: Stil "fill"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-2D-sym.png|thumb|none|225px|Darstellung in 2D: Stil "sym"]] </li><br />
</ul></div><br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-3D-normal.png|thumb|none|225px|Darstellung in 3D: Stil "normal"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-3D-dot.png|thumb|none|225px|Darstellung in 3D: Stil "dot"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-3D-dash.png|thumb|none|225px|Darstellung in 3D: Stil "dash"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-3D-fill.png|thumb|none|225px|Darstellung in 3D: Stil "fill"]] </li><br />
<li style="display: inline-block;"> [[File:FTUI_Widget_Chart_Form-3D-sym.png|thumb|none|225px|Darstellung in 3D: Stil "sym"]] </li><br />
</ul></div><br />
<br />
Farbe und Stil werden kombiniert (zusammengeschrieben) beim Attribut '''data-style''' angegeben, sodass sich beispielsweise für eine graue Punktlinie folgendes ergibt: <code>data-style="ftui l1dot"</code>.<br />
Um die Darstellung als normale Linie zu erhalten, darf im Gegensatz zu den anderen Linienformen der Stil <code>normal</code> nicht angegeben werden. Für eine einfache graue Linie ist also die Angabe <code>data-style="ftui l1"</code> korrekt, wohingegen <code>data-style="ftui l1normal"</code> zu einer fehlerhaften Anzeige führt.<br />
<br />
'''Hinweis:''' Der Stil ''sym'' ist speziell dafür geeignet, Symbole statt Linien zu zeichnen. Dazu kann beim Attribut '''data-ptype''' als Linienform ein beliebiges Font-Awsome-, oder Open Automation-Icon angegeben werden. Alle in diesem Abschnitt enthaltenen Abbildungen sind mit <code>data-ptype="lines"</code> entstanden.<br />
<br />
'''Übergänge mit datenabhängigen Grenzen:''' Plotstile (data-style) können auch direkt als Gradienten auf Basis von Plot-Datenwerten definiert werden. Dazu muss der Plotstil als Array angegeben werden. Der erste Wert des Arrays gibt an, ob nur die Linie gezeichnet werden soll (Zahl angeben, die die Dicke der Linie definiert) oder gefüllt ("fill" eintragen). Alle danach folgenden Array Elemente sind beliebig viele Stopp Punkte für die Farbübergänge, welche wiederum aus Arrays mit 3 Parametern bestehen. Für jeden Stopp Punkt werden der Datenwert, die Farbe und die Durchsichtigkeit gesetzt. Hierdurch lassen sich z.B. Einfärbungen setzen, die für Temperaturplots immer negative Werte blau einfärben und positive Werte rot. Zwischen den Stop Punkten wird die Farbe interpoliert, also ein weicher Übergang generiert. Will man harte Übergänge muss man Zwei Stopp Punkte mit unterschiedlichen Farbwerten aber dem gleichen Datenwert erzeugen.<br><br />
Beispiel 1 für einen weichen Gradienten, der bei 0 von blau nach rot übergeht, bei diesem Übergang durchsichtig ist und von dort nach negativen bzw. positiven Werden immer deckender wird:<br><br />
<code>data-style='["fill",["-20","#0000ff","0.7"],["0","#0000ff","0"],["0","#ff0000","0"],["302","#ff0000","0.7"]]'</code><br><br />
Beispiel 2 mit einem harten Übergang von blau nach rot bei 0:<br><br />
<code>data-style='["fill",["-20","#0000ff","0.7"],["0","#0000ff","0.7"],["0","#ff0000","0.7"],["50","#ff0000","0.7"]]'</code><br />
Es gibt auch die Möglichkeit den Bereich zwischen zwei Graphen einzufärben. Dazu muss ein Wert in Columnspec als Array angegeben werden. Ist dies der Fall, dann wird der zweite Graph umgekehrt an den ersten angehängt.<br><br />
Beispiel:<br />
<syntaxhighlight lang="html"><br />
data-columnspec='[<br />
"Func:logProxy_proplanta2Plot(\\x22AgroWeather\\x22,\\x22weatherIcon\\x22,$from,$to,12)",<br />
[<br />
"Func:logProxy_proplanta2Plot(\\x22AgroWeather\\x22,\\x22tempMax\\x22,$from,$to,12)",<br />
"Func:logProxy_proplanta2Plot(\\x22AgroWeather\\x22,\\x22tempMin\\x22,$from,$to,12)"<br />
],<br />
"Func:logProxy_proplanta2Plot(\\x22AgroWeather\\x22,\\x22rain\\x22,$from,$to,0,\\x22day\\x22)"<br />
]'<br />
</syntaxhighlight><br />
[[Datei:FTUI Widget Chart DynamicStyles.png|thumb|none|500px|dynamischer Übergang]]<br />
<br />
===Form der Linien===<br />
Das Attribut '''data-ptype''' beeinflusst die Form der Linien. Hier sind folgende Werte möglich (in den Bildern sind zur Info zusätzlich auch immer points dargestellt):<br />
<div><ul><br />
<li style="display: inline-block;"> [[File:Llines.png|thumb|none|350px|Darstellung in 2D: Stil "lines"]] </li><br />
<li style="display: inline-block;"> [[File:Points.png|thumb|none|350px|Darstellung in 2D: Stil "points"]] </li><br />
<li style="display: inline-block;"> [[File:Steps.png|thumb|none|350px|Darstellung in 2D: Stil "steps"]] </li><br />
<li style="display: inline-block;"> [[File:Fsteps.png|thumb|none|350px|Darstellung in 2D: Stil "fsteps"]] </li><br />
<li style="display: inline-block;"> [[File:Histeps.png|thumb|none|350px|Darstellung in 2D: Stil "histeps"]] </li><br />
<li style="display: inline-block;"> [[File:Bars.png|thumb|none|350px|Darstellung in 2D: Stil "bars"]] </li><br />
<li style="display: inline-block;"> [[File:Ibars.png|thumb|none|350px|Darstellung in 2D: Stil "ibars"]] </li><br />
<li style="display: inline-block;"> [[File:Cubic.png|thumb|none|350px|Darstellung in 2D: Stil "cubic"]] </li><br />
<li style="display: inline-block;"> [[File:Quadratic.png|thumb|none|350px|Darstellung in 2D: Stil "quadratic"]] </li><br />
<li style="display: inline-block;"> [[File:QuadraticSmooth.png|thumb|none|350px|Darstellung in 2D: Stil "quadraticSmooth"]] </li><br />
</div><br />
<br />
Zusätzlich ist es möglich, Symbole anzeigen zu lassen. Unterstützt werden Font-Awesome ('fa-...'), Open Automation ('oa-...') und FHEM-Symbole ('fs-...')). Damit die Symbole korrekt angezeigt werden, muss im Attribut '''data-style''' der Stil <code>sym</code> gewählt werden, da sonst nur Punkte, statt der Symbole gezeichnet werden.<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="DG.wz.HZ.Heizungsventil"<br />
data-logdevice="FileLog_DG.wz.HZ.Heizungsventil"<br />
...<br />
data-style="ftui l1sym"<br />
data-ptype="fa-cloud"<br />
...><br />
</div><br />
</syntaxhighlight><br />
<li style="display: inline-block;"> [[File:Ssymbols.png|thumb|none|500px|Darstellung in 2D: Stil "symbol fa-cloud"]] </li><br />
<br />
Die Größe der Symbole ist in der Datei <code>css/ftui_chart.css</code> auf 12px festgelegt. Dieser Wert kann in einer eigenen CSS-Datei durch Anpassung von <code>stroke-width</code> überschrieben werden.<br />
<br />
<syntaxhighlight lang="css"><br />
.ftui.l0sym { stroke:#DDA400; stroke-width:12px; fill:none; }<br />
.ftui.l1sym { stroke:#BBBBBB; stroke-width:12px; fill:none; }<br />
.ftui.l2sym { stroke:#CC0000; stroke-width:12px; fill:none; }<br />
.ftui.l3sym { stroke:#CCCC00; stroke-width:12px; fill:none; }<br />
.ftui.l4sym { stroke:#33CC33; stroke-width:12px; fill:none; }<br />
.ftui.l5sym { stroke:#33CCCC; stroke-width:12px; fill:none; }<br />
.ftui.l6sym { stroke:#3333CC; stroke-width:12px; fill:none; }<br />
</syntaxhighlight><br />
<br />
'''data-ptype''' kann auch Inhalt im Format <code>'icon:1'</code> verarbeiten. Dann muss der zugehörige Wert in '''data-columnspec''' den Pfad zu einem Icon (z.B. für Wettervorhersagen) beinhalten. Der Y-Wert wird dann vom ersten Graphen übernommen. Weitere Ausführungen hierzu im Beispiel [[#Darstellung der Wetter Icons im Diagramm]].<br />
<li style="display: inline-block;"> [[File:Wetterchart2.png|thumb|none|500px|Darstellung in 2D: Stil "Beispiel mit icons aus Readings"]] </li><br />
<br />
<br />
===Stapeln von Linien===<br />
Über '''data-ptype''' kann zusätzlich festgelegt werden, ob Graphen übereinander gestapelt werden sollen. <code>data-ptype='lines:1'</code> bedeutet, dass der zugehörige Graph auf den Graph mit der Nummer 1 gestapelt werden soll. So etwas kann z.B. Sinn machen, wenn man den Stromverbrauch einzelner Devices darstellen und zusätzlich sehen will, wie hoch die Summe ist. Beispiel siehe unten.<br />
<br />
[[Datei:FTUI Widget Chart Stacked.png]]<br />
<br />
===Zeitstrahl / Start & Ende auf der X-Achse===<br />
Die Attribute '''data-daysago_start''' und '''data-daysago_end''' dienen der Definition von Anfang und Ende der X-Achse. Im einfachsten Fall wird eine Anzahl an Tagen eingegeben, die sich auf das aktuelle Datum beziehen. Dabei gilt es zu beachten, dass es sich um ''vergangene Tage'' handelt. Das bedeutet, dass Tage in der Vergangenheit als positive Zahl angegeben werden, Tage in der Zukunft hingegen als negative Zahl. Es kann jeweils auch ein fixes Datum (z.B. '2013-10-23') angegeben werden. Uhrzeitangaben werden nur berücksichtigt, wenn '''data-nofulldays='true' ''' verwendet wird.<br />
<br />
'''Relative Zeitangabe in Stunden/Tagen/Wochen/Monaten/Jahren'''<br /><br />
Zur Ausgabe einer Anzahl an zurückliegenden Stunden bis zum aktuellen Zeitpunkt wird als Startzeitpunkt die Anzahl der Stunden/Tage/Wochen/Monate/Jahre angegeben, die angezeigt werden sollen, gefolgt vom Kleinbuchstaben '''h''' für Stunden, '''d''' für Tage, '''w''' für Wochen, '''m''' für Monate, '''y''' für Jahre, . Als Endzeitpunkt wird '''now''' gewählt.<br /><br />
Das nachfolgende Beispiel zeigt die Werte der vergangenen 3 Stunden an:<br />
<syntaxhighlight lang="html"><br />
data-nofulldays="true"<br />
data-daysago_start="3h"<br />
data-daysago_end="now"<br />
</syntaxhighlight><br />
<br />
'''Fester Zeitbereich des heutigen Tages (Stunden/Tage/Wochen/Monate/Jahre)'''<br /><br />
Um ein festes Stunden/Tages/Wochen/Monats/Jahresfenster anzuzeigen, werden die absoluten Stunden/Tages/Wochen/Monats/Jahreszahlen mit negativem Vorzeichen, gefolgt vom Großbuchstaben '''H''' (entsprechend D/W/M/Y für Tage/Wochen/Monate/Jahre) angegeben. Wird '''data-daysago_start''' als positiver Wert angegeben, wird die Anzahl der Stunden/Tage/Wochen/Monate/Jahre von heute 0:00 Uhr subtrahiert (siehe Rechenweg weiter unten).<br /><br />
Das Beispiel zeigt den Zeitbereich von heute 5:00 Uhr bis heute 22:00 Uhr:<br />
<syntaxhighlight lang="html"><br />
data-nofulldays="true"<br />
data-daysago_start="-5H"<br />
data-daysago_end="-22H"<br />
</syntaxhighlight><br />
<br />
'''Fester Zeitbereich Tage-übergreifend'''<br /><br />
Die Zeit in Tagen kann als Gleitkommazahl angegeben werden. Damit ist es möglich, Tage und Uhrzeiten zu kombinieren. Die Werte sind dann als Teil eines ganzen Tages, bezogen auf heute 0:00 Uhr zu errechnen und mit <code>.</code> als Teiler anzugeben.<br /><br />
Das nachfolgende Beispiel zeigt einen Zeitbereich von '''gestern 15:00 Uhr''' bis '''morgen 3:00 Uhr'''.<br />
<syntaxhighlight lang="html"><br />
data-nofulldays="true"<br />
data-daysago_start="0.375"<br />
data-daysago_end="-1.125"<br />
</syntaxhighlight><br />
<br />
Für die nachfolgenden Rechenwege sind die Einheiten nur zur Verdeutlichung angegeben. Die Einheiten werden im Attribut nicht angegeben.<br />
<br />
Der Wert für '''GESTERN''' wird wie folgt ermittelt:<br /><br />
Ausgangspunkt ist heute 0:00 Uhr, gestern 15:00 Uhr liegt also 9 Stunden davor. Diese 9 Stunden sind ein <code>9/24 Tag</code> und errechnet sich so:<br />
<pre><br />
1d / 24h = 0.0416666...d/h<br />
0.0416d/h * 9h = 0.375d<br />
</pre><br />
<br />
Der Wert für '''MORGEN''' wird wie folgt ermittelt:<br /><br />
Ausgangspunkt ist wieder heute 0:00 Uhr, morgen 3:00 Uhr liegt dann 27 Stunden dahinter. Der Einfachheit halber werden hier nur die 3 Stunden errechnet und dann ein ganzer Tag addiert:<br />
<pre><br />
1d / 24h = 0.0416666...d/h<br />
0.0416d/h * 3h = 0.125d<br />
<br />
0.125d + 1d = 1.125d<br />
</pre><br />
Da das Attribut Tage in der Vergangenheit erwartet, muss für einen Wert in der Zukunft wieder eine negative Zahl angegeben werden.<br />
<br />
===Zeitformat der X-Achse===<br />
Die Zeitanzeige auf der X-Achse kann sehr flexibel eingestellt werden. Dafür stehen verschiedene Platzhalter zur Verfügung, die durch spezielle Zeichen (<code>-</code>, <code>.</code>, <code>/</code>, <code> </code> (Leerzeichen), <code>:</code>, <code>,</code>, <code>\</code>) getrennt werden. Alle Zeichen werden trotz Escape-Zeichen (<code>\</code>) in der Ausgabe angezeigt.<br />
<br />
Folgende Platzhalter werden unterstützt:<br />
*<code>'mm'</code>: Minuten als zweistellige Zahl<br />
*<code>'hh'</code>: Stunden als zweistellige Zahl<br />
*<code>'dd'</code>: Tag als zweistellige Zahl (Kalenderdatum)<br />
*<code>'MM'</code>: Monat als zweistellige Zahl (z.B. 02 für Februar)<br />
*<code>'MMM'</code>: Monat als dreistellige Abkürzung (z.B. Dec für Dezember)<br />
*<code>'MMMM'</code>: Langname des Monats (z.B. March)<br />
*<code>'ee'</code>: Wochentag als zweistellige Zahl (z.B. 00 für Sonntag)<br />
*<code>'eee'</code>: Wochentag als dreistellige Abkürzung (z.B. Mon für Montag)<br />
*<code>'eeee'</code>: Langname des Wochentags (z.B. Tuesday)<br />
*<code>'yy'</code>: Jahr als zweistellige Zahl (z.B. 16 für 2016)<br />
*<code>'yyyy'</code>: Jahr als vierstellige Zahl (z.B. 2016)<br />
*<code>'LF'</code>: Fügt einen Zeilenumbruch hinzu<br />
<br />
Beispiel: Der String <code>'MMM\LF\yyyy'</code> zeigt <code>'Jan'</code> in der ersten, und <code>'2016'</code> in der zweiten Zeile. <code>'MM.dd 2016'</code> wird zu <code>'03.05 2016'</code>.<br />
<br />
===Fadenkreuz-Cursor===<br />
Der Fadenkreuz-Cursor zeigt die Momentanwerte, indem man ihn über die Graphen bewegt. In Desktop-Browsern reicht einfaches Bewegen des Maus. Unter iOS und Android wird der Cursor durch einfaches Tippen auf die neue Position bewegt.<br />
<br />
Mit dem Attribut '''data-cursorgroup''' können Graphen gruppiert werden. Am Cursor werden dann die Momentanwerte aller Graphen gleichzeitig angezeigt, die die selbe Zahl besitzen, sobald man die Maus über einen aus der Gruppe bewegt.<br />
<br />
===Legende===<br />
Mit dem Attribut '''data-legendpos''' kann die Position der Legende innerhalb des Diagramms festgelegt werden. Die Position wird mit einem Array, bestehend aus zwei Werten im Format <code>'["<horizontal>","<vertikal>"]'</code> angegeben. Für die horizontale Positionierung sind <code>'left'</code>, <code>'right'</code>, <code>'before'</code>, und <code>'behind'</code>, die vertikale Positionierung <code>'top'</code>, <code>'bottom'</code>, <code>'above'</code>, <code>'below'</code> erlaubt (der Unterschied zwischen <code>'left'</code> und <code>'before'</code> liegt darin, dass im zweiten Fall die Legende nicht in den Zeichenbereich gesetzt wird sondern vor das ganze Chart (entsprechend für <code>'after'</code>, <code>'above'</code> und <code>'below'</code>). Alternativ können auch Zahlen verwendet werden, die die Position in Prozent angeben. Durch verschieben mit der Maus oder durch verschieben mit dem Finger oder Stift auf Touch Devices kann die Legende auch an eine andere Position verschoben werden.<br />
<br />
Wenn die Legende eingeblendet ist, kann mittels Klick auf einen Legendeneintrag der zugehörige Graph ein- und ausgeblendet werden.<br />
<br />
===3-dimensionale Drehung===<br />
'''data-ddd''' ermöglicht, den Graphen 3-dimensional zu drehen. Als Wert wird ein Array mit den 3 Winkeln für x, y und z erwartet, wobei z selbst bisher nicht unterstützt wird.<br />
<br />
Beispiel: <code>data-ddd='["40","60","0"]'</code>. <br />
<br />
Wenn der 3D Modus aktiv ist ('''data-ddd''' gesetzt) sind 2 zusätzliche Parameter verfügbar um das Aussehen der Graphen zu beeinflussen. '''data-dddspace''' gibt an, wie viele pixel der Raum zwischen den einzelnen in z-Richtung hintereinander angeordneten Graphen betragen soll.<br />
'''data-dddwidth''' legt fest, wie viele pixel die einzelnen Graphen tief (oder dick) sein sollen.<br />
<br />
Wenn das Array angegeben wird, erscheinen zwei zusätzliche Buttons im Diagramm, mit denen die Drehung in X- und Y-Richtung verändert werden kann.<br />
<br />
===Diagrammtitel===<br />
Mit dem Attribut '''data-title''' kann dem Diagramm, ähnlich wie in FHEM-SVG-Plots, ein Titel hinzugefügt werden.<br />
<br />
Folgende Platzhalter werden unterstützt:<br />
*<code>'min1'</code>: Minimaler Y-Wert des ersten Graphs<br />
*<code>'max1'</code>: Maximaler Y-Wert des ersten Graphs<br />
*<code>'avg1'</code>: Mittlerer Y-Wert des ersten Graphs<br />
*<code>'cnt1'</code>: Anzahl der dargestellten Einzelwerte im ersten Graph<br />
*<code>'currval1'</code>: Letzter, bzw. aktuellster Y-Wert des ersten Graphs<br />
*<code>'mindate1'</code>: Niedrigster Wert auf der X-Achse des ersten Graphs<br />
*<code>'maxdate1'</code>: Höchster Wert auf der X-Achse vom ersten Graphs<br />
*<code>'currdate1'</code>: Letzter, bzw. aktuellster Wert auf der X-Achse des ersten Graphs<br />
<br />
Durch Einsetzen einer anderen Zahl statt '1' können auch die Werte der anderen Graphen angezeigt werden. Das Weglassen der Zahl bewirkt, dass der jeweils zutreffende Wert automatisch ermittelt wird. Bedeutet: <code>max</code> führt dazu, dass der höchste Wert aller angezeigter Graphen verwendet wird.<br />
Zusätzlich ist es möglich durch "$eval(<regexp>)" regular Expressions auszuwerten (also z.B. Berechnungen durchzuführen). In <regexp> können auch "$data()" vorkommen.<br />
<br />
Beispiel: <code>data-title="Klima Wohnzimmer Average: $eval(parseInt($data{avg1}*10)/10)°C / Max: $eval(parseInt($data{max1}*10)/10)°C"</code><br />
<br />
===Buttons im Diagramm===<br />
Es gibt mehrere Buttons, mit denen sich die Anzeige des Diagramms verändern lässt. <code><-</code> und <code>-></code> bewegen die Graphen nach links und rechts. <code>+</code> und <code>-</code> zoomen die Anzeige. <code>legend</code> und <code>cursor</code> schalten die zugehörigen Anzeigen ein und aus. Falls der 3D Modus eingeschaltet ist, gibt es Buttons zum Drehen der Darstellung um die X- und Y-Achse. Falls <code>data-timeranges</code> gesetzt ist, wird ein Pulldown Menü dargestellt, welches die Auswahl von dort definierten Zeiträumen für die X-Achse erlaubt.<br />
<br />
==Beispiele==<br />
===Einfaches Diagramm===<br />
Das Beispiel zeigt ein einfaches Diagramm mit 4 unterschiedlich formatierten Graphen, Legende und Momentanwerten am Fadenkreuz-Cursor.<br />
<br />
[[File:Chart_tabletUI.png]]<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-logdevice='["Log.Garden","Log.Garden","Log.Garden","Log.Predicted"]'<br />
data-columnspec='["4:Garden.T:15:","10:Garden.T:0:delta-h","10:Garden.T:0:delta-d","4:predicted.*:15:"]'<br />
data-style='["ftui l0fill","ftui l1fill","ftui l2","ftui l3dot"]'<br />
data-ptype='["lines","histeps","histeps","cubic"]'<br />
data-uaxis='["primary","secondary","secondary","primary"]'<br />
data-legend='["Temperature","Rain/hour","Rain/day","Predicted Temp."]'<br />
data-yunit="°C"<br />
data-ytext="Temperature"<br />
data-minvalue="auto"<br />
data-maxvalue="auto"<br />
data-yunit_sec="mm"<br />
data-ytext_sec="Rain (mm)"<br />
data-height="250"<br />
data-yticks="auto"<br />
data-minvalue_sec="auto"<br />
data-maxvalue_sec="auto"<br />
data-nofulldays="true"<br />
data-daysago_start="2013-08-13T00:00:00"<br />
data-daysago_end="2013-08-14T00:00:00"<br />
data-cursorgroup="1"<br />
data-scrollgroup="1"<br />
data-xticks="auto"><br />
</div><br />
</syntaxhighlight><br />
<br />
===7-Tage-Wettervorhersage mit Proplanta===<br />
In diesem Beispiel wird gezeigt, wie die Vorhersagewerte von [[PROPLANTA]] in einem Diagramm dargestellt werden können. Da die Werte nicht in einer Datenbank oder einem FileLog vorliegen, müssen sie über [[LogProxy]] verarbeitet werden. Dafür sind einige Vorbereitungen in FHEM nötig.<br />
<br />
[[File:FTUI_Widget_Chart-fc-Proplanta.png|941px]]<br />
<br />
'''1.''' Ein LogProxy-Device muss vorhanden sein:<br />
<pre><br />
define myLogProxy logProxy<br />
</pre><br />
<br />
'''2.''' In der Datei <code>99_myUtils.pm</code> muss folgende Routine hinzugefügt werden, die die Daten bereitstellt:<br />
<syntaxhighlight lang="perl"><br />
#---------------------------------------<br />
# Proplanta LogProxy-Funktion<br />
#---------------------------------------<br />
sub logProxy_proplanta2Plot($$$$;$$) {<br />
my ($device, $fcValue, $from, $to, $fcHour, $expMode) = @_;<br />
my $regex;<br />
my @rl;<br />
<br />
return undef if(!$device);<br />
<br />
if($fcValue =~ s/_$//) {<br />
$regex = "^fc[\\d]+_".$fcValue."[\\d]{2}\$";<br />
}<br />
else {<br />
$regex = "^fc[\\d]+_".$fcValue."\$";<br />
}<br />
<br />
$fcHour = 12 if(!defined $fcHour);<br />
$expMode = "point" if(!defined $expMode);<br />
<br />
if( defined($defs{$device}) ) {<br />
if( $defs{$device}{TYPE} eq "PROPLANTA" ) {<br />
@rl = sort{<br />
my ($an) = ($a =~ m/fc(\d+)_.*/);<br />
my ($bn) = ($b =~ m/fc(\d+)_.*/);<br />
$an <=> $bn or $a cmp $b;<br />
}( grep /${regex}/,keys %{$defs{$device}{READINGS}} );<br />
return undef if( !@rl );<br />
} else {<br />
Log3 undef, 2, "logProxy_proplanta2Plot: $device is not a PROPLANTA device";<br />
return undef;<br />
}<br />
}<br />
<br />
my $fromsec = SVG_time_to_sec($from);<br />
my $tosec = SVG_time_to_sec($to);<br />
my $sec = $fromsec;<br />
my ($h,$fcDay,$mday,$mon,$year);<br />
my $timestamp;<br />
<br />
my $reading;<br />
my $value;<br />
my $prev_value;<br />
my $min = 999999;<br />
my $max = -999999;<br />
my $ret = "";<br />
<br />
# while not end of plot range reached<br />
while(($sec < $tosec) && @rl) {<br />
#remember previous value for start of plot range<br />
$prev_value = $value;<br />
<br />
$reading = shift @rl;<br />
($fcDay) = $reading =~ m/^fc(\d+).*/;<br />
$h = ($reading =~ m/.*(\d\d)$/)?$1:$fcHour;<br />
$value = ReadingsVal($device,$reading,undef);<br />
<br />
($mday,$mon,$year) = split('\.',ReadingsVal($device,"fc".$fcDay."_date",undef));<br />
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, $h, 0, 0);<br />
$sec = SVG_time_to_sec($timestamp);<br />
<br />
# skip all values before start of plot range<br />
next if( SVG_time_to_sec($timestamp) < $fromsec );<br />
<br />
# add first value at start of plot range<br />
if( !$ret && $prev_value ) {<br />
$min = $prev_value if( (looks_like_number($prev_value) && ($prev_value < $min)) || ($prev_value lt $min) );<br />
$max = $prev_value if( (looks_like_number($prev_value) && ($prev_value > $max)) || ($prev_value gt $max) );<br />
$ret .= "$from $prev_value\n";<br />
}<br />
<br />
# done if after end of plot range<br />
last if($sec > $tosec);<br />
<br />
$min = $value if( (looks_like_number($value) && ($value < $min )) || ($value lt $min) );<br />
$max = $value if( (looks_like_number($value) && ($value > $max )) || ($value gt $max) );<br />
<br />
# add actual controll point<br />
$ret .= "$timestamp $value\n";<br />
<br />
# Log 1, "$timestamp $value -0- $reading";<br />
}<br />
if(($sec < $tosec) && !@rl && ($expMode eq "day")) {<br />
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, 23, 59, 59);<br />
if(SVG_time_to_sec($timestamp) < $tosec) {<br />
$ret .= "$timestamp $value\n";<br />
}<br />
else {<br />
$ret .= "$to $value\n";<br />
}<br />
}<br />
elsif(($sec > $tosec) && ($expMode eq "day")) {<br />
$value = $prev_value + ($value - $prev_value)*(86400 + ($tosec - $sec))/86400;<br />
$ret .= "$to $value\n";<br />
}<br />
return ($ret,$min,$max,$prev_value);<br />
}<br />
</syntaxhighlight><br />
<br />
Anschließend können die Daten im Chart-Widget angezeigt werden. Der Device-Name von Proplanta heißt hier im Beispiel <code>AU.xx.WE.Proplanta</code>.<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="AU.xx.WE.Proplanta"<br />
data-logdevice='[<br />
"myLogProxy",<br />
"myLogProxy",<br />
"myLogProxy"<br />
]'<br />
data-columnspec='[<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22rain_\\x22,$from,$to,12,\\x22day\\x22)",<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22chOfRain_\\x22,$from,$to,12,\\x22day\\x22)",<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22cloud_\\x22,$from,$to,12,\\x22day\\x22)"<br />
]'<br />
data-style='[<br />
"ftui l6fill",<br />
"ftui l5fill",<br />
"ftui l1fill"<br />
]'<br />
data-ptype='[<br />
"steps",<br />
"quadraticSmooth",<br />
"quadraticSmooth"<br />
]'<br />
data-uaxis='[<br />
"primary",<br />
"secondary",<br />
"secondary"<br />
]'<br />
data-legend='[<br />
"Regen",<br />
"Regenwahrscheinlichkeit",<br />
"Wolken"<br />
]'<br />
data-yunit="mm"<br />
data-ytext="Regen"<br />
data-yunit_sec="%"<br />
data-ytext_sec="Chance auf Regen / Wolken"<br />
data-timeformat="eeee"<br />
data-minvalue="auto"<br />
data-maxvalue="auto"<br />
data-minvalue_sec="auto"<br />
data-maxvalue_sec="auto"<br />
data-daysago_start = "0"<br />
data-daysago_end = "-7"<br />
data-xticks="1440"<br />
data-yticks="auto"<br />
data-title="7-Tage-Wettervorhersage"<br />
data-showlegend="true"<br />
class="nobuttons fullsize"><br />
</div><br />
</syntaxhighlight><br />
<br />
'''Hilfreiche Links und Quellen zu diesem Beispiel:'''<br />
*[[LogProxy|LogProxy im FHEM-Wiki]]<br />
*{{Link2Forum|Topic=22967|Message=246973|LinkText=Stundengenaue Wettervorhersage (#1) im FHEM-Forum}}<br />
*{{Link2Forum|Topic=22967|Message=334713|LinkText=Stundengenaue Wettervorhersage (#2) im FHEM-Forum}}<br />
<br />
===Darstellung der Wetter Icons im Diagramm===<br />
<br />
[[File:Wetterchart2.png]]<br />
<br />
Wie oben bereits beschrieben, gibt es beim Chart grundsätzlich die Möglichkeit, Icons, welche in Form von URLs in den Logs abgelegt sind oder welche per logProxy generiert werden, darzustellen. Die Icons werden auf genau dem gleichen Weg von FHEM gelesen, wie alle anderen Datenpunkte. Im Folgenden wird ein Beispiel gezeigt, mit dem die im Proplanta Modul als Readings abgelegten Icons per logProxy Funktion gelesen und in ein Chart eingebaut werden könnnen.<br />
Da es beim Proplanta Modul für die ersten 7 Tage nicht das Reading <code>fc#_weatherIcon</code> gibt, sondern mehrere Readings für unterschiedliche Tageszeiten wogegen für die zweiten 7 Tage ausschließlich das Reading <code>fc#_weatherIcon</code> vorhanden ist, sollte per <code>attr device userReading</code> mit folgendem Eintrag dafür gesorgt werden, dass für alle Tage ein Reading <code>fc#_weatherIcon</code> vorhanden ist (alternativ könnten auch 2 Graphen gezeichnet werden, wobei der erste dann nur die ersten 7 Tage enthält und der zweite die letzen 7 Tage, will man nur die ersten 7 Tage darstellen braucht man das userReading nicht unbedingt).<br />
<syntaxhighlight lang="perl"><br />
fc0_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc0_weatherDayIcon","");},<br />
fc1_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc1_weatherDayIcon","");},<br />
fc2_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc2_weatherDayIcon","");},<br />
fc3_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc3_weatherDayIcon","");},<br />
fc4_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc4_weatherDayIcon","");},<br />
fc5_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc5_weatherDayIcon","");},<br />
fc6_weatherIcon {ReadingsVal("AU.xx.WE.Proplanta","fc6_weatherDayIcon","");}<br />
</syntaxhighlight><br />
Um die Icons darzustellen muss ein zusätzlicher Graph definiert werden. Dieser nutzt neben der Columnspec, die die URLs abruft den Parameter <code>data-ptype="icons:#"</code> (# ist eine Zahl und steht für die Nummer, beginnend bei 0 des Graphen, welcher für die y-Position der Icons verwendet werden soll) und den Stil <code>sym</code>. Der Wert für die Symbolgröße sollte z.B. durch eine zusätzliche Definition im File fhem-tablet-ui-user.css in der Form:<br />
<syntaxhighlight lang="css"><br />
/* icon lines */<br />
.ftui.l99icon { stroke:#DDA400; stroke-width:48px; fill:none; }<br />
</syntaxhighlight><br />
angepasst werden.<br />
<br />
Im folgenden ein Beispiel, welches eine Linie für die Maximale Tagestemperatur zeichnet und auf dieser Linie die Wetter Icons darstellt.<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="AU.xx.WE.Proplanta"<br />
data-logdevice='[<br />
"myLogProxy",<br />
"myLogProxy"<br />
]'<br />
data-columnspec='[<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22weatherIcon\\x22,$from,$to,12,\\x22day\\x22)",<br />
"Func:logProxy_proplanta2Plot(\\x22AU.xx.WE.Proplanta\\x22,\\x22tempMax\\x22,$from,$to,12,\\x22day\\x22)"<br />
]'<br />
data-style='[<br />
"ftui l99icon",<br />
"ftui l1fill"<br />
]'<br />
data-ptype='[<br />
"icons:1",<br />
"quadraticSmooth"<br />
]'<br />
data-uaxis='[<br />
"primary",<br />
"primary"<br />
]'<br />
data-legend='[<br />
"Wetterbedingung",<br />
"Max. Temperature"<br />
]'<br />
data-yunit="°C"<br />
data-ytext="Temperature (°C)"<br />
data-timeformat="ee\LF\dd.MM"<br />
data-minvalue="auto"<br />
data-maxvalue="auto"<br />
data-minvalue_sec="auto"<br />
data-maxvalue_sec="auto"<br />
data-daysago_start="-1w"<br />
data-y_margin="20"<br />
data-daysago_end="-3w"<br />
data-xticks="1440"<br />
data-yticks="auto"<br />
data-title="14-Tage-Wettervorhersage"<br />
data-showlegend="true"<br />
class="nobuttons fullsize"><br />
</div><br />
</syntaxhighlight><br />
<br />
===Kuchendiagramme===<br />
In folgendem Beispiel wird gezeigt, wie man ein "Kuchendiagramm" darstellen kann.<br />
<br />
[[File:PieChart.png]]<br />
<br />
Ähnlich wie bei den Beispielen für die Wetter Darstellungen wird hierzu auch wieder logProxy benötigt. Zunächst muss die folgende zusätzliche Funktion in <code>99_myUtils.pm</code> einfügen.<br />
<syntaxhighlight lang="perl"><br />
#---------------------------------------<br />
# Funktion zum Erzeugen der Inputs für Kuchendiagramme<br />
#---------------------------------------<br />
sub logProxy_values2PieChart($$$$;$$) {<br />
my ($device, $reading, $angle_start, $angle_dif, $inner_rad, $show_text) = @_;<br />
Log3 undef, 1, "$device, $reading, $angle_start, $angle_dif, $inner_rad, $show_text\n";<br />
<br />
use constant PI => 4 * atan2(1,1);<br />
<br />
my $value=ReadingsVal($device,$reading,0);<br />
<br />
my $angle_delta = $value/100*360;<br />
$angle_start = $angle_start/100*360;<br />
<br />
my $rad=10;<br />
my $irad=0;<br />
if ($inner_rad) {<br />
$irad = $rad*$inner_rad;<br />
}<br />
my $angle=$angle_start/360*2.0*PI;<br />
my $x=$irad*sin($angle);<br />
my $y=$irad*cos($angle);<br />
my $ret .= ";p ".$x." ".$y."\n"; # add segment at angle $angle<br />
<br />
for (my $i=$angle_start; $i<=$angle_start+$angle_delta; $i+=$angle_dif) {<br />
$angle = $i/360*2.0*PI;<br />
$x = $rad*sin($angle);<br />
$y = $rad*cos($angle);<br />
$ret .= ";p ".$x." ".$y."\n"; # add segment at angle $angle<br />
}<br />
<br />
$angle = ($angle_start+$angle_delta)/360*2.0*PI; # add last segment <br />
$ret .= ";p ".$rad*sin($angle)." ".$rad*cos($angle)."\n";<br />
<br />
if ($inner_rad) {<br />
for (my $i=$angle_start; $i<$angle_start+$angle_delta; $i+=$angle_dif) {<br />
$angle = ($angle_start+$angle_start+$angle_delta-$i)/360*2.0*PI;<br />
$x = $irad*sin($angle);<br />
$y = $irad*cos($angle);<br />
$ret .= ";p ".$x." ".$y."\n"; # add segment at angle $angle<br />
}<br />
}<br />
<br />
$angle = ($angle_start)/360*2.0*PI; # add last segment <br />
$ret .= ";p ".$irad*sin($angle)." ".$irad*cos($angle)."\n";<br />
<br />
if ($show_text) { # show text values<br />
$x = ($rad+$irad)/2*sin((2*$angle_start+$angle_delta)/2/360*2.0*PI);<br />
$y = ($rad+$irad)/2*cos((2*$angle_start+$angle_delta)/2/360*2.0*PI);<br />
<br />
$ret .= ";t ".$x." ".$y." middle ".$show_text.":".$value."%\n";<br />
}<br />
<br />
return($ret);<br />
}<br />
</syntaxhighlight><br />
In FHEM braucht man Readings, welche eine Zahl enthalten, die als Prozentwert interpretiert wird. Für jeden Prozentwert (also für jedes Reading) generiert die o.a. Funktion nun den Chart Input für ein Kuchenstück und liefert diesen als Antwort auf das GET, welches das Chart Widget auslöst. Dazu braucht die Funktion folgende Parameter: (Name des FHEM Devices, Name des Readings, Start Winkel des Kuchenstücks (Mathematisch gegen den Uhrzeigersinn in Grad), Delta Winkel zum Zeichnen (legt fest in welchen Schritten der Teilkreis des Kuchenstücks gezeichnet wird), Skalierungsfaktor für inneren Ring wenn ein Ring gezeichtnet werden soll (0 bedeutet komplette Kuchenstücke), optionaler Text der ins Kuchenstück vor die Prozentzahl geschrieben wird).<br />
Im Folgenden eine Beispielkonfiguration für die Darstellung als Kuchendiagramm, die Readings heißen hier dPer1 bis dPer4. Der Startwinkel wird duch Aufsummierung der jeweils vorher schon gezeichneten Kuchenstücke gebildet, dadurch entstehen aneinander hängende Stücke.<br />
<syntaxhighlight lang="html"><br />
[[Datei:[[Datei:Beispiel.jpg]]]]<div class="normal noaxes nobuttons"<br />
data-type="chart"<br />
data-logdevice='["lp"]'<br />
data-logfile="CURRENT"<br />
data-columnspec='[<br />
"Func:logProxy_values2PieChart(\"dPer1\",\"state\",ReadingsVal(\"dPer4\",\"state\",0)+ReadingsVal(\"dPer3\",\"state\",0),5,0,\"first\")",<br />
"Func:logProxy_values2PieChart(\"dPer2\",\"state\",ReadingsVal(\"dPer4\",\"state\",0)+ReadingsVal(\"dPer3\",\"state\",0)+ReadingsVal(\"dPer1\",\"state\",0),5,0,\"second\")",<br />
"Func:logProxy_values2PieChart(\"dPer3\",\"state\",ReadingsVal(\"dPer4\",\"state\",0),5,0,\"third\")",<br />
"Func:logProxy_values2PieChart(\"dPer4\",\"state\",0,5,0,\"fourth\")"<br />
]'<br />
data-style='["ftui l0fill","ftui l1fill","ftui l2fill","ftui l3fill"]'<br />
data-ptype='["lines"]'<br />
data-uaxis='["primary"]'<br />
data-legend='["First","Second","Third","Fourth"]'<br />
data-legendpos='["left","top"]'<br />
data-yunit=""<br />
data-height="300"<br />
data-width="300"<br />
data-ddd='["-40","0","0"]'<br />
data-dddspace='["-10"]'<br />
data-dddwidth='["10"]'<br />
data-showlegend="true"<br />
data-legend_horiz="true"<br />
data-xticks="auto"><br />
</div><br />
</syntaxhighlight><br />
<br />
===Fensterstatus offen/geschlossen===<br />
Dieses Beispiel zeigt, wie ein Fensterkontakt, dessen Reading die Werte <code>closed</code> und <code>open</code> einnimmt, als Graph gezeichnet werden kann. Technisch gesehen werden hier die Werte <code>0</code> und <code>1</code> gezeichnet, indem über das Attribut '''data-columnspec''' dem Zustand <code>open</code> der Wert <code>1</code> und allen anderen Zuständen der Wert <code>0</code> zugeordnet wird. Über das Attribut '''data-yticks''' wird die Beschriftung an der Y-Achse (<code>0</code> und <code>1</code>) gegen einen frei definierbaren Text ausgetauscht.<br />
<br />
<syntaxhighlight lang="html"><br />
<div data-type="chart"<br />
data-device="wz_fensterstatus"<br />
data-logdevice='["myDbLog"]'<br />
data-logfile='["HISTORY"]'<br />
data-columnspec='["wz_fensterstatus:state:0::$val=($val=~\\x22open\\x22?1:0)"]'<br />
data-style='["ftui l4fill"]'<br />
data-ptype='["steps"]'<br />
data-height="290"<br />
data-yticks='[[0,"geschlossen"],[1,"offen"]]'<br />
data-minvalue="0"<br />
data-maxvalue="1.1"<br />
data-nofulldays="true"<br />
data-daysago_start="1"<br />
data-daysago_end="-1"<br />
data-cursorgroup="1"<br />
data-scrollgroup="1"><br />
</div><br />
</syntaxhighlight><br />
<br />
'''Hinweis:''' Das Beispiel funktioniert nur mit DbLog. Falls Logfiles verwendet werden muss statt '$val' '$fld[''num'']' verwendet werden. Hierbei steht ''num'' für die Spalte (beginnend bei 0) in der die Daten stehen.<br />
<br />
==Links==<br />
{{Link2Forum|Topic= 48450 |Message=401006|LinkText=Thread im FHEM-Forum}}<br />
<br />
[[Kategorie:FHEM Tablet UI|Chart]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=FTUI_Snippets&diff=37160FTUI Snippets2022-01-26T19:03:55Z<p>F Klee: /* Rollladen Circle Menu */</p>
<hr />
<div><br />
== Spezialfälle für Switch Widget ==<br />
<br />
=== Vier Buttons für HomeStatus ===<br />
[[Datei:Ftui_homestatus_buttons.png|mini|rechts]]<br />
<br />
<syntaxhighlight lang="html4strict"><br />
<li data-row="1" data-col="9" data-sizex="2" data-sizey="3"><br />
<header>HOMESTATUS</header><br />
<div><br />
<div data-type="switch" data-device="dummy1"<br />
data-get-on="Wert1" data-get-off="!on"<br />
data-set-off="" class="green"<br />
data-icon="fa-home" data-background-icon="fa-square" ></div><br />
<div class="inline w1x">Home</div><br />
</div><br />
<div><br />
<div data-type="switch" data-device="dummy1"<br />
data-get-on="Wert2" data-get-off="!on"<br />
data-set-off="" class="blue"<br />
data-icon="fa-bed" data-background-icon="fa-square" ></div><br />
<div class="inline w1x">Night</div><br />
</div><br />
<div><br />
<div data-type="switch" data-device="dummy1"<br />
data-get-on="Wert3" data-get-off="!on"<br />
data-set-off="" class="orange"<br />
data-icon="fa-car" data-background-icon="fa-square" ></div><br />
<div class="inline w1x">Away</div><br />
</div><br />
<div><br />
<div data-type="switch" data-device="dummy1"<br />
data-get-on="Wert4" data-get-off="!on"<br />
data-set-off="" class="red"<br />
data-icon="fa-suitcase" data-background-icon="fa-square" ></div><br />
<div class="inline w1x">Holiday</div><br />
</div><br />
</li><br />
</syntaxhighlight><br />
<br />
=== Switch funktioniert wie ein Push Widget, aber zeigt auch Status an, wie ein Symbol Widget ===<br />
[[Datei:FTUI_Taster-mit-Switch.png|mini|rechts]]<br />
<syntaxhighlight lang="html4strict"><br />
<div data-type="switch" data-device="dummy1"<br />
data-get-on="auf"<br />
data-get-off="!on"<br />
data-set-on="auf"<br />
data-set-off=""<br />
data-on-background-color="#ad3333"<br />
data-off-background-color="#32a054"<br />
data-icon="fa-arrow-up"><br />
</div><br />
<div data-type="switch" data-device="dummy1"<br />
data-get-on="zu"<br />
data-get-off="!on"<br />
data-set-on="zu"<br />
data-set-off=""<br />
data-on-background-color="#ad3333"<br />
data-off-background-color="#32a054"<br />
data-icon="fa-arrow-down"><br />
</div><br />
</syntaxhighlight><br />
<br />
=== Variante 2 (Mehrfach Auslösen möglich) ===<br />
<syntaxhighlight lang="html4strict"><br />
<div data-type="switch" data-device="dummy1"<br />
data-states='["zu","mittel","auf"]'<br />
data-background-colors='["green", "gray", "red"]'<br />
data-fhem-cmd="set dummy1 auf"<br />
data-icon="fa-arrow-up"><br />
</div><br />
<div data-type="switch" data-device="dummy1"<br />
data-states='["zu","mittel","auf"]'<br />
data-background-colors='["red", "gray", "green"]'<br />
data-fhem-cmd="set dummy1 zu"<br />
data-icon="fa-arrow-down"><br />
</div><br />
</syntaxhighlight><br />
<br />
== Beschriftungen von Buttons ==<br />
=== Doublebox-v Beschriftung rechts ===<br />
[[Datei:FTUI_doublebox.png|mini|rechts]]<br />
<syntaxhighlight lang="html4strict"><br />
<div><br />
<div class="doublebox-v inline"><br />
<div data-type="push" data-device="Rollo"<br />
data-icon="fa-chevron-up" data-background-icon="fa-square-o"<br />
data-set-on="up"><br />
</div><br />
<div data-type="push" data-device="Rollo"<br />
data-icon="fa-chevron-down" data-background-icon="fa-square-o"<br />
data-set-on="down"><br />
</div><br />
</div><br />
<div class="inline"><br />
<div class="bottom-space-2x">up</div><br />
<div class="top-space">down</div><br />
</div><br />
</div><br />
</syntaxhighlight><br />
<br />
=== Triplebox-v Beschriftung rechts ===<br />
[[Datei:FTUI_triplebox.png|mini|rechts]]<br />
<syntaxhighlight lang="html4strict"><br />
<div class="cell"><br />
<div class="triplebox-v inline"><br />
<div data-type="push" data-device="Rollo"<br />
data-icon="fa-chevron-up" data-background-icon="fa-square-o"<br />
data-set-on="up"><br />
</div><br />
<div data-type="push" data-device="Rollo"<br />
data-icon="fa-minus" data-background-icon="fa-square-o"<br />
data-set-on="stop"><br />
</div><br />
<div data-type="push" data-device="Rollo"<br />
data-icon="fa-chevron-down" data-background-icon="fa-square-o"<br />
data-set-on="down"><br />
</div><br />
</div><br />
<div class="inline"><br />
<div class="bottom-space-2x">up</div><br />
<div class="bottom-space-2x">stop</div><br />
<div class="top-space">down</div><br />
</div><br />
</div><br />
</syntaxhighlight><br />
== Rollladen Circle Menu ==<br />
[[Datei:RollladenCircleMenu.png|mini|rechts]]<br />
Dieses Beispiel bringt ein [[FHEM_Tablet_UI#circlemenu|Circle Menü]], dass<br />
* den Status des Rollladens als Icon anzeigt<br />
** bestätigt offen (grün, offener Rollladen)<br />
** bestätigt geschlossen (grün, geschlossener Rolladen)<br />
** der Rolladen steht zwischen offen und geschlossen<br />
*** graues Rollladensymbol abhängig von der Rollladenposition (0-100)<br />
** Rollladen bewegt sich nach oben (gelb, Rolladen mit Pfeil nach oben)<br />
** Rollladen bewegt sich nach unten (gelb, Rolladen mit Pfeil nach unten)<br />
* Buttons für die Bedienung des Rollladens anbietet<br />
** Icon Pfeil nach unten zum Schließen des Rollladens<br />
** Icon Pfeil nach oben zum Öffnen des Rollladens<br />
** Quadratischer Icon zum Stoppen des Rollladens<br />
* Switch zum Ein-/Ausschalten der Rollladenautomatik<br />
<br />
EnOcean Devices für Rollläden (z.B. [[EnOcean-FSB61-Aktor-Beschattungselemente-Rollladen|Eltako FSB61]]) können in FHEM folgende Stati annehmen:<br />
* up<br />
* down<br />
* open_ack<br />
* closed<br />
* stop<br />
und werden mit folgenden "set" Befehlen gesteuert:<br />
* closes<br />
* stop<br />
* opens<br />
Zusätzlich gibt es noch das Reading "position", dass mit einer Zahl zwischen 0 und 100 angibt, wie weit der Rolladen geschlossen ist.<br />
<br />
Um möglichst viel Information im Rollladen Circle Menü anzuzeigen, werden die beiden Werte (Status und Reading "position") mit dem Attribut userReadings im FHEM Rollladen-Device (in diesem Beispiel: "st6.kueche.rollladen") zu einem neuen Reading "statePosition" zusammengefasst:<br />
<pre><br />
attr st6.kueche.rollladen userReadings statePosition {<br />
if(ReadingsVal($name,"state","0") eq "up"<br />
or ReadingsVal($name,"state","0") eq "down"<br />
or ReadingsVal($name,"state","0") eq "closed"<br />
or ReadingsVal($name,"state","0") eq "open_ack") <br />
{ReadingsVal($name,"state",0)}<br />
else {ReadingsVal($name,"position",0)};;}<br />
</pre><br />
<br />
Hier der Code für TabletUI, der kommt z.B. in die index.html <br />
<syntaxhighlight lang="html4strict"><br />
<div class="container"><br />
<div data-type="circlemenu" class="cell circlemenu"><br />
<ul class="menu"><br />
<li><div data-type="symbol" <br />
data-device="st6.kueche.rollladen" <br />
data-get="statePosition" <br />
data-states='["up","down","open_ack","closed","[0-9]","1[0-9]","2[0-9]","3[0-9]","4[0-9]","5[0-9]","6[0-9]","7[0-9]","8[0-9]","9[0-9]","100"]'<br />
data-icons='["oa-fts_shutter_up","oa-fts_shutter_down","oa-fts_window_2w","oa-fts_shutter_100","oa-fts_shutter","oa-fts_shutter_10","oa-fts_shutter_20","oa-fts_shutter_30","oa-fts_shutter_40","oa-fts_shutter_50","oa-fts_shutter_60","oa-fts_shutter_70","oa-fts_shutter_80","oa-fts_shutter_90","oa-fts_shutter_100"]'<br />
data-colors='["yellow","yellow","green","green","#505050","#505050","#505050","#505050","#505050","#505050","#505050","#505050","#505050","#505050","#505050"]'<br />
></div></li><br />
<li><div data-type="switch"<br />
data-device="sw_rollladenAutomatik"<br />
data-icon="oa-fts_shutter_automatic"></div><br />
<li><div data-type="push" <br />
data-device="st6.kueche.rollladen" <br />
data-set-on="closes" <br />
data-icon="fa-angle-down"></div></li><br />
<li><div data-type="push" <br />
data-device="st6.kueche.rollladen" <br />
data-set-on="stop" <br />
data-icon="oa-audio_stop"></div></li><br />
<li><div data-type="push" <br />
data-device="st6.kueche.rollladen" <br />
data-set-on="opens"<br />
data-icon="fa-angle-up"></div></li><br />
</ul><br />
</div><br />
<div data-type="label">Rollladen</div><br />
</syntaxhighlight><br />
<br />
Hier noch ein Beispiel zur Darstellung eines via [[Velux KLF200]] eingebundenen Rollladens. Als Statusattribut wird STATE verwendet, das ensprechend der [[Velux KLF200#Vorschl.C3.A4ge_zur_sch.C3.B6neren_Darstellung|Vorschläge zur schöneren Darstellung]] über das Attribut stateFormat befüllt wird.<br />
:<code>attr VeluxKLF200_0 stateFormat pct execution</code><br />
<br />
<syntaxhighlight lang="html4strict"><br />
<div data-type="circlemenu" class="circlemenu"><br />
<ul class="menu"><br />
<li><div data-type="symbol" <br />
data-device="VeluxKLF200_0" <br />
data-states='[".*up",".*down","0.stop","\\d.stop","1\\d.stop","2\\d.stop","3\\d.stop","4\\d.stop","5\\d.stop","6\\d.stop","7\\d.stop","8\\d.stop","9\\d.stop","100.stop"]'<br />
data-icons='["oa-fts_shutter_up","oa-fts_shutter_down","oa-fts_shutter_100","oa-fts_shutter_90","oa-fts_shutter_90","oa-fts_shutter_80","oa-fts_shutter_70","oa-fts_shutter_60","oa-fts_shutter_50","oa-fts_shutter_40","oa-fts_shutter_30","oa-fts_shutter_20","oa-fts_shutter_10","oa-fts_window_2w"]'<br />
data-colors='["yellow","yellow","white","#505050","#505050","#505050","#505050","#505050","#505050","#505050","#505050","#505050","#505050","green"]'<br />
></div></li><br />
<li><div class="smaller" data-type="switch"<br />
data-device="VeluxKLF200_0"<br />
data-icon="oa-fts_shutter_automatic"></div><br />
<li><div data-type="push" <br />
data-device="VeluxKLF200_0" <br />
data-set-on="down" <br />
data-icon="fa-angle-down"></div></li><br />
<li><div data-type="push" <br />
data-device="VeluxKLF200_0" <br />
data-set-on="stop" <br />
data-icon="oa-audio_stop"></div></li><br />
<li><div data-type="push" <br />
data-device="VeluxKLF200_0" <br />
data-set-on="up"<br />
data-icon="fa-angle-up"></div></li><br />
</ul><br />
</div> <br />
<div data-type="label">Rollladen</div> <br />
</syntaxhighlight><br />
<br />
== Dachfenster Circle Menu ==<br />
Analog zum Rolladen hier das passende Widget für ein Dachfenster via [[Velux KLF200|KLF200]]:<br />
<br />
:<code>attr VeluxKLF200_1 stateFormat pct (limitationMin - limitationMax) execution</code><br />
<br />
<syntaxhighlight lang="html4strict"><br />
<div data-type="circlemenu" class="circlemenu"><br />
<ul class="menu"><br />
<li><div data-type="symbol" <br />
data-device="VeluxKLF200_1" <br />
data-states='[".*up", ".*down", ".*-.7\\).*", "0.*", "\\d.\\(.*", "[1-5]\\d.\\(.*", "[6-9]\\d.\\(.*", "100.\\(.*"]'<br />
data-icons='["oa-control_arrow_up","oa-control_arrow_down","oa-weather_rain","oa-fts_window_roof","oa-window_roof_open_1","oa-window_roof_open_1","oa-fts_window_roof_open_2","oa-fts_window_roof_open_2"]'<br />
data-colors='["yellow","yellow","blue","white","orange","orange","orange","orange"]'<br />
></div></li><br />
<li><div class="smaller" data-type="switch"<br />
data-device="VeluxKLF200_1"<br />
data-icon="oa-fts_window_roof"></div><br />
<li><div data-type="push" <br />
data-device="VeluxKLF200_1" <br />
data-set-on="down" <br />
data-icon="fa-angle-down"></div></li><br />
<li><div data-type="push" <br />
data-device="VeluxKLF200_1" <br />
data-set-on="stop" <br />
data-icon="oa-audio_stop"></div></li><br />
<li><div data-type="push" <br />
data-device="VeluxKLF200_1" <br />
data-set-on="up"<br />
data-icon="fa-angle-up"></div></li><br />
</ul><br />
</div> <br />
<div data-type="label">Fenster</div> <br />
</syntaxhighlight><br />
<br />
[[Kategorie:Code Snippets]]<br />
[[Kategorie:FHEM Tablet UI|Snippets]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=FTUI_Widget_Analogclock&diff=37159FTUI Widget Analogclock2022-01-26T13:11:08Z<p>F Klee: </p>
<hr />
<div>Das [[{{PAGENAME}}|Analogclock Widget]] ist ein Widget für [[FHEM Tablet UI]], welches eine analoge Uhr darstellt.<br />
<br />
<gallery><br />
File:FTUI_Analoguhr_1.png<br />
File:FTUI_Analoguhr_2.png<br />
File:FTUI_Analoguhr_3.png<br />
File:FTUI_Analoguhr_4.png<br />
</gallery><br />
<br />
Die Uhr basiert auf der "Bahnhofsuhr" von Rüdiger Appel, vgl. [[#Links|Links]].<br />
<br />
Die notwendigen Dateien können von [https://github.com/roman1528/ftui_analogclock Github] herunter geladen und dann in die Verzeichnisse ./lib und ./js kopiert werden.<br />
<br />
Weitere Informationen gibt es im [https://forum.fhem.de/index.php/topic,50821.0.html Forenbeitrag].<br />
<br />
==Attribute==<br />
{|class="wikitable"<br />
!Attribut<br />
!Beschreibung<br />
!Optionen<br />
!Standard-Wert<br />
|-<br />
|'''data-size'''||Größe der Uhr in Pixel||||100<br />
|-<br />
|'''data-body'''||Äußere Gestalt||<br />
* none = transparenter Hintergrund<br />
* round = rundes, schwarzes Gehäuse<br />
* small = runder, weißer Hintergrund<br />
* green = rundes, grünes Gehäuse (Österreich)<br />
* square = quadratisches, blaues Gehäuse (Deutsche Bahn)<br />
* vienna = Wiener Würfeluhr<br />
|round<br />
|-<br />
|'''data-body-color'''||Hintergrundfarbe des Ziffernblatts||||#FFFFFF<br />
|-<br />
|'''data-stroke-color'''||"Gehäusefarbe" bei data-body="round" bzw. den Standardwerten||||#000000<br />
|-<br />
|'''data-dial'''||Darstellung des Ziffernblatts||<br />
* none = Ohne Zifferblatt<br />
* hour = mit Stundenstrichen (DIN 41091, Teil 3)<br />
* full = mit Minuten- und Stundenstrichen (DIN 41091, Teil 1)<br />
* austria = mit Minuten- und Stundenstrichen (Österreich)<br />
* swiss = mit Minuten- und Stundenstrichen (Schweiz/Bauhaus)<br />
* vienna = mit Minuten- und Stundenstrichen (Wiener Würfeluhr)<br />
|full<br />
|-<br />
|'''data-dial-color'''||Farbe der Stunden- und Minutenstriche||||#3C3C3C<br />
|-<br />
|'''data-hour'''||Aussehen des Stundenzeigers||<br />
* pointed = spitzer Balkenzeiger (DIN 41092, Teil 3)<br />
* bar = stumpfer Balkenzeiger (Deutsche Bahn)<br />
* swiss = stumpfer, keilförmiger Zeiger (Schweiz/Bauhaus)<br />
* vienna = Wiener Würfeluhr<br />
|pointed<br />
|-<br />
|'''data-hour-color'''||Farbe des Stundenzeigers||||#000000<br />
|-<br />
|'''data-minute'''||Aussehen des Minutenzeigers||<br />
* pointed = spitzer Balkenzeiger (DIN 41092, Teil 3) STANDARD<br />
* bar = stumpfer Balkenzeiger (Deutsche Bahn)<br />
* swiss = stumpfer, keilförmiger Zeiger (Schweiz/Bauhaus)<br />
* vienna = Wiener Würfeluhr<br />
|pointed<br />
|-<br />
|'''data-minute-color'''||Farbe des Minutenzeigers||||#000000<br />
|-<br />
|'''data-second'''||Aussehen des Sekundenzeigers||<br />
* none = ohne Sekundenzeiger<br />
* hole = Loch-Zeiger (DIN 41071, Teil 2)<br />
* bar = Keil-Zeiger (DIN 41071, Teil 1)<br />
* swiss = Kellen-Zeiger (Schweiz)<br />
* longhole = Loch-Zeiger (Deutsche Bahn)<br />
|bar<br />
|-<br />
|'''data-second-color'''||Farbe des Sekundenzeigers||||#C80000<br />
|-<br />
|'''data-boss'''||Aussehen des Mittelpunktes, d.h. der Achsabdeckung||<br />
* small = kleiner Mittelpunkt<br />
* medium = mittelgroßer Mittelpunkt<br />
* big = großer Mittelpunkt<br />
* none = kein Mittelpunkt<br />
|none<br />
|-<br />
|'''data-boss-color'''||Farbe des Mittelpunktes, d.h. der Achsabdeckung||||#000000<br />
|-<br />
|'''data-mbehave'''||Verhalten des Minutenzeigers||<br />
* bounce = springender Minutenzeiger<br />
* ebounce = springender und federnder Minutenzeiger<br />
* creep = schleichender Minutenzeiger<br />
|bounce<br />
|-<br />
|'''data-sbehave'''||Verhalten des Sekundenzeigers||<br />
* bounce = springender Sekundenzeiger<br />
* ebounce = springender und federnder Sekundenzeiger<br />
* creep = schleichender Sekundenzeiger<br />
* hasty = 58,5s je Umdrehung; anschließend kurze Wartezeit<br />
|bounce<br />
|-<br />
|'''data-date-color'''||Aktuelles Datum im Ziffernblatt, Zeiger liegen im Hintergrund.||Ohne ''data-date-color'' wird kein Datum dargestellt!||<br />
|}<br />
<br />
==Hinweise==<br />
* ''Analogclock'' kann nur einmal innerhalb einer FTUI-Instanz verwendet werden.<br />
<br />
==Beispiele==<br />
<syntaxhighlight lang="html"><br />
<div data-type="analogclock"><br />
</div><br />
</syntaxhighlight><br />
<br />
==Links== <br />
[https://forum.fhem.de/index.php/topic,50821.0.html Vorstellung im Forum]<br />
<br />
[http://www.3quarks.com/de/SVGUhr/index.html Bahnhofsuhr von Rüdiger Appel]<br />
<br />
[https://de.wikipedia.org/wiki/Bahnhofsuhr Wiki zu Bahnhofsuhren]<br />
<br />
<br />
<br />
[[Kategorie:FHEM Tablet UI|Analogclock]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=FTUI_Widget_Analogclock&diff=37158FTUI Widget Analogclock2022-01-26T13:08:26Z<p>F Klee: Download-Link hinzu gefügt.</p>
<hr />
<div>Das [[{{PAGENAME}}|Analogclock Widget]] ist ein Widget für [[FHEM Tablet UI]], welches eine analoge Uhr darstellt.<br />
<br />
<gallery><br />
File:FTUI_Analoguhr_1.png<br />
File:FTUI_Analoguhr_2.png<br />
File:FTUI_Analoguhr_3.png<br />
File:FTUI_Analoguhr_4.png<br />
</gallery><br />
<br />
Die Uhr basiert auf der "Bahnhofsuhr" von Rüdiger Appel, vgl. [[#Links|Links]].<br />
<br />
Die notwendigen Dateien können von [https://github.com/roman1528/ftui_analogclock Github] herunter geladen und dann in die Verzeichnisse ./lib und ./js kopiert werden.<br />
<br />
Weitere Informationen gibt es im [https://forum.fhem.de/index.php/topic,50821.msg642752.html#msg642752 Forenbeitrag].<br />
<br />
==Attribute==<br />
{|class="wikitable"<br />
!Attribut<br />
!Beschreibung<br />
!Optionen<br />
!Standard-Wert<br />
|-<br />
|'''data-size'''||Größe der Uhr in Pixel||||100<br />
|-<br />
|'''data-body'''||Äußere Gestalt||<br />
* none = transparenter Hintergrund<br />
* round = rundes, schwarzes Gehäuse<br />
* small = runder, weißer Hintergrund<br />
* green = rundes, grünes Gehäuse (Österreich)<br />
* square = quadratisches, blaues Gehäuse (Deutsche Bahn)<br />
* vienna = Wiener Würfeluhr<br />
|round<br />
|-<br />
|'''data-body-color'''||Hintergrundfarbe des Ziffernblatts||||#FFFFFF<br />
|-<br />
|'''data-stroke-color'''||"Gehäusefarbe" bei data-body="round" bzw. den Standardwerten||||#000000<br />
|-<br />
|'''data-dial'''||Darstellung des Ziffernblatts||<br />
* none = Ohne Zifferblatt<br />
* hour = mit Stundenstrichen (DIN 41091, Teil 3)<br />
* full = mit Minuten- und Stundenstrichen (DIN 41091, Teil 1)<br />
* austria = mit Minuten- und Stundenstrichen (Österreich)<br />
* swiss = mit Minuten- und Stundenstrichen (Schweiz/Bauhaus)<br />
* vienna = mit Minuten- und Stundenstrichen (Wiener Würfeluhr)<br />
|full<br />
|-<br />
|'''data-dial-color'''||Farbe der Stunden- und Minutenstriche||||#3C3C3C<br />
|-<br />
|'''data-hour'''||Aussehen des Stundenzeigers||<br />
* pointed = spitzer Balkenzeiger (DIN 41092, Teil 3)<br />
* bar = stumpfer Balkenzeiger (Deutsche Bahn)<br />
* swiss = stumpfer, keilförmiger Zeiger (Schweiz/Bauhaus)<br />
* vienna = Wiener Würfeluhr<br />
|pointed<br />
|-<br />
|'''data-hour-color'''||Farbe des Stundenzeigers||||#000000<br />
|-<br />
|'''data-minute'''||Aussehen des Minutenzeigers||<br />
* pointed = spitzer Balkenzeiger (DIN 41092, Teil 3) STANDARD<br />
* bar = stumpfer Balkenzeiger (Deutsche Bahn)<br />
* swiss = stumpfer, keilförmiger Zeiger (Schweiz/Bauhaus)<br />
* vienna = Wiener Würfeluhr<br />
|pointed<br />
|-<br />
|'''data-minute-color'''||Farbe des Minutenzeigers||||#000000<br />
|-<br />
|'''data-second'''||Aussehen des Sekundenzeigers||<br />
* none = ohne Sekundenzeiger<br />
* hole = Loch-Zeiger (DIN 41071, Teil 2)<br />
* bar = Keil-Zeiger (DIN 41071, Teil 1)<br />
* swiss = Kellen-Zeiger (Schweiz)<br />
* longhole = Loch-Zeiger (Deutsche Bahn)<br />
|bar<br />
|-<br />
|'''data-second-color'''||Farbe des Sekundenzeigers||||#C80000<br />
|-<br />
|'''data-boss'''||Aussehen des Mittelpunktes, d.h. der Achsabdeckung||<br />
* small = kleiner Mittelpunkt<br />
* medium = mittelgroßer Mittelpunkt<br />
* big = großer Mittelpunkt<br />
* none = kein Mittelpunkt<br />
|none<br />
|-<br />
|'''data-boss-color'''||Farbe des Mittelpunktes, d.h. der Achsabdeckung||||#000000<br />
|-<br />
|'''data-mbehave'''||Verhalten des Minutenzeigers||<br />
* bounce = springender Minutenzeiger<br />
* ebounce = springender und federnder Minutenzeiger<br />
* creep = schleichender Minutenzeiger<br />
|bounce<br />
|-<br />
|'''data-sbehave'''||Verhalten des Sekundenzeigers||<br />
* bounce = springender Sekundenzeiger<br />
* ebounce = springender und federnder Sekundenzeiger<br />
* creep = schleichender Sekundenzeiger<br />
* hasty = 58,5s je Umdrehung; anschließend kurze Wartezeit<br />
|bounce<br />
|-<br />
|'''data-date-color'''||Aktuelles Datum im Ziffernblatt, Zeiger liegen im Hintergrund.||Ohne ''data-date-color'' wird kein Datum dargestellt!||<br />
|}<br />
<br />
==Hinweise==<br />
* ''Analogclock'' kann nur einmal innerhalb einer FTUI-Instanz verwendet werden.<br />
<br />
==Beispiele==<br />
<syntaxhighlight lang="html"><br />
<div data-type="analogclock"><br />
</div><br />
</syntaxhighlight><br />
<br />
==Links== <br />
[https://forum.fhem.de/index.php/topic,50821.0.html Vorstellung im Forum]<br />
<br />
[http://www.3quarks.com/de/SVGUhr/index.html Bahnhofsuhr von Rüdiger Appel]<br />
<br />
[https://de.wikipedia.org/wiki/Bahnhofsuhr Wiki zu Bahnhofsuhren]<br />
<br />
<br />
<br />
[[Kategorie:FHEM Tablet UI|Analogclock]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Knxd&diff=37078Knxd2022-01-11T14:32:26Z<p>F Klee: /* Vorbereiten des Raspberry Pi für ROT oder PIGATOR */</p>
<hr />
<div>== knxd mit einem IP Gateway einrichten ==<br />
Damit FHEM auf den KNX Bus zugreifen kann, wird ein passendes Interface benötigt. Es gibt:<br />
* RS232<br />
* USB<br />
* IP<br />
<br />
Im Folgenden wird die Einrichtung von knxd mit einem IP Gateway auf einem Raspberry Pi2 mit Wheezy oder Jessie beschrieben.<br />
<br />
=== Installation ===<br />
<br />
==== Für Debian Jessie: ====<br />
'''als erstes müssen folgende Pakete installiert werden (Referenz Debian Jessie):'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
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<br />
</syntaxhighlight><br />
<br />
'''knxd herunterladen und installieren'''<br />
Achtung: Wenn Abhängigkeiten fehlen, dann müssen diese nachinstalliert werden. Nicht einfach mittels "-d" diese übergehen!<br />
<syntaxhighlight lang="bash"><br />
git clone https://github.com/knxd/knxd.git<br />
cd knxd<br />
git checkout deb<br />
dpkg-buildpackage -b -uc<br />
cd ..<br />
sudo dpkg -i knxd_*.deb knxd-tools_*.deb<br />
</syntaxhighlight><br />
<br />
==== Ab Debian Stretch, Buster, ... ====<br />
'''knxd ist in den Debian packages vorhanden, muss daher nicht compiliert werden.'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install knxd knxd-tools<br />
<br />
</syntaxhighlight><br />
<br />
Mit der Konfiguration '''mit Systemd weitermachen!''' <br />
=== Konfiguration ===<br />
'''1. Ohne systemd'''<br />
<br />
Es muss als nächstes die Konfigurationsdatei editiert werden, das geht mit:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/default/knxd <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
DAEMON_ARGS="-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.188.XX"<br />
</syntaxhighlight><br />
und<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
<br />
'''2. Mit systemd z. B. für Debian Jessie'''<br />
<br />
Die Konfigurationsdatei bei Jessie hat sich wegen der Nutzung von systemd geändert:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b ipt:192.168.188.XX"<br />
<br />
</syntaxhighlight><br />
=== knxd Status überprüfen ===<br />
<syntaxhighlight lang="bash"><br />
/etc/init.d/knxd status<br />
</syntaxhighlight><br />
<br />
== knxd als IP-Gateway einrichten ==<br />
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.:<br />
* ROT<br />
* PIGATOR mit PIM-TPUART<br />
* TUL<br />
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.<br />
<br />
=== Vorbereiten des TUL ===<br />
==== TUL flashen ====<br />
Der TUL wird ohne Software geliefert und kann über den Raspberry Pi programmiert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install dfu-programmer<br />
wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54<br />
sudo dfu-programmer atmega32u4 erase<br />
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex<br />
sudo dfu-programmer atmega32u4 reset<br />
sudo reboot<br />
</syntaxhighlight><br />
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.<br />
Der TUL hat an der Unterseite einen winzigen Button. Dieser muss gedrückt werden, während der TUL in die USB-Buchse gesteckt wird.<br />
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.<br />
<br />
==== TUL einen dauerhaften Namen geben ====<br />
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<br />
<syntaxhighlight lang="bash"><br />
ls -la /dev/serial/by-id/<br />
</syntaxhighlight><br />
identifiziert. Das Ergebnis sollte ungefähr so aussehen<br />
<syntaxhighlight lang="bash"><br />
usb-busware.de_TPUART_8543934393935171B1C1-if00 -> ../../ttyACM0<br />
</syntaxhighlight><br />
Die Seriennummer (8543934393935171B1C1) wird später benötigt. Der Befehl<br />
<syntaxhighlight lang="bash"><br />
lsusb<br />
</syntaxhighlight><br />
sollte u.a. diese Zeile liefern<br />
<syntaxhighlight lang="bash"><br />
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project<br />
</syntaxhighlight><br />
03eb ist dabei die Herstellerkennung, 204b die Produktkennung. Nun muss die Datei /etc/udev/rules.d/99-usb-serial.rules<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/udev/rules.d/99-usb-serial.rules<br />
</syntaxhighlight><br />
erstellt oder erweitert werden mit der Zeile<br />
<syntaxhighlight lang="bash"><br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="8543934393935171B1C1", SYMLINK+="knx", OWNER="knxd"<br />
</syntaxhighlight><br />
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.<br />
<br />
=== Vorbereiten des Raspberry Pi für ROT oder PIGATOR ===<br />
Der Raspberry Pi nutzt standardmäßig die serielle Schnittstelle als Terminal. Dies muss deaktiviert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo raspi-config<br />
5 Interfaceoption<br />
P6 Serial<br />
</syntaxhighlight><br />
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:<br />
<syntaxhighlight lang="bash"><br />
sudo usermod -aG dialout knxd<br />
</syntaxhighlight><br />
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<br />
<syntaxhighlight lang="bash"><br />
dtoverlay=disable-bt<br />
</syntaxhighlight><br />
am Ende eingefügt werden. Nun muss noch der Dienst hciuart deaktiviert werden (initialisiert das Bluetooth-Modem):<br />
<syntaxhighlight lang="bash"><br />
sudo systemctl disable hciuart<br />
</syntaxhighlight><br />
Nach einem anschließenden Reboot ist der TPUART unter ttyAMA0 ansprechbar.<br />
<br />
=== Andere BCU's (BusCouplerUnit) ===<br />
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.}}<br />
<br />
=== Installieren des knxd ===<br />
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.<br />
<br />
=== Konfiguration ===<br />
Die Konfiguration erfolgt wieder in der knxd.conf mit<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf<br />
</syntaxhighlight><br />
Nun die Konfiguarionszeile anpassen<br><br />
(serielle Schnittstelle)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/ttyAMA0"<br />
</syntaxhighlight><br />
(USB)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/knx"<br />
</syntaxhighlight><br />
Und dann noch<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
um knxd beim Systemstart sofort zu starten.<br />
<br />
-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 <br />
<syntaxhighlight lang="bash"><br />
define KNX TUL eibd:127.0.0.1 1.2.203<br />
</syntaxhighlight><br />
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.}}<br />
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)<br />
<syntaxhighlight lang="bash"><br />
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts<br />
"1" durch "0" ersetzen<br />
</syntaxhighlight><br />
Nach einem<br />
<syntaxhighlight lang="bash"><br />
sudo reboot<br />
</syntaxhighlight><br />
sollte der knxd dann laufen.<br />
<br />
== FAQ ==<br />
'''Wie wird eibd vorher deinstalliert?'''<br />
<syntaxhighlight lang="bash"><br />
sudo rm -r /usr/local/bin/{eibd,knxtool,group*} /usr/local/lib/lib{eib,pthsem}*.so* /usr/local/include/pth*<br />
</syntaxhighlight><br />
<br />
<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. <br />
<br />
'''folgender Fehler: dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install git-core build-essential<br />
</syntaxhighlight><br />
<br />
oder<br />
<br />
<syntaxhighlight lang="bash"><br />
in der datei knxd/debian/rules die Zeile:<br />
bash tools/test.sh auskommentieren<br />
</syntaxhighlight><br />
<br />
'''Fehler: dpkg-buildpackage: error: fakeroot not found, either install the fakeroot <....> '''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install fakeroot dpkg-dev<br />
</syntaxhighlight><br />
<br />
== Links ==<br />
* [[Benutzer:Marthinx]]<br />
* [https://github.com/knxd/knxd Github knxd]<br />
* [https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen Forums-Thread zu knxd. Sehr informativ.]<br />
<br />
[[Kategorie:Examples]]<br />
[[Kategorie:EIB/KNX]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Knxd&diff=37077Knxd2022-01-11T14:31:46Z<p>F Klee: /* Vorbereiten des Raspberry Pi für ROT oder PIGATOR */</p>
<hr />
<div>== knxd mit einem IP Gateway einrichten ==<br />
Damit FHEM auf den KNX Bus zugreifen kann, wird ein passendes Interface benötigt. Es gibt:<br />
* RS232<br />
* USB<br />
* IP<br />
<br />
Im Folgenden wird die Einrichtung von knxd mit einem IP Gateway auf einem Raspberry Pi2 mit Wheezy oder Jessie beschrieben.<br />
<br />
=== Installation ===<br />
<br />
==== Für Debian Jessie: ====<br />
'''als erstes müssen folgende Pakete installiert werden (Referenz Debian Jessie):'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
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<br />
</syntaxhighlight><br />
<br />
'''knxd herunterladen und installieren'''<br />
Achtung: Wenn Abhängigkeiten fehlen, dann müssen diese nachinstalliert werden. Nicht einfach mittels "-d" diese übergehen!<br />
<syntaxhighlight lang="bash"><br />
git clone https://github.com/knxd/knxd.git<br />
cd knxd<br />
git checkout deb<br />
dpkg-buildpackage -b -uc<br />
cd ..<br />
sudo dpkg -i knxd_*.deb knxd-tools_*.deb<br />
</syntaxhighlight><br />
<br />
==== Ab Debian Stretch, Buster, ... ====<br />
'''knxd ist in den Debian packages vorhanden, muss daher nicht compiliert werden.'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install knxd knxd-tools<br />
<br />
</syntaxhighlight><br />
<br />
Mit der Konfiguration '''mit Systemd weitermachen!''' <br />
=== Konfiguration ===<br />
'''1. Ohne systemd'''<br />
<br />
Es muss als nächstes die Konfigurationsdatei editiert werden, das geht mit:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/default/knxd <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
DAEMON_ARGS="-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.188.XX"<br />
</syntaxhighlight><br />
und<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
<br />
'''2. Mit systemd z. B. für Debian Jessie'''<br />
<br />
Die Konfigurationsdatei bei Jessie hat sich wegen der Nutzung von systemd geändert:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b ipt:192.168.188.XX"<br />
<br />
</syntaxhighlight><br />
=== knxd Status überprüfen ===<br />
<syntaxhighlight lang="bash"><br />
/etc/init.d/knxd status<br />
</syntaxhighlight><br />
<br />
== knxd als IP-Gateway einrichten ==<br />
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.:<br />
* ROT<br />
* PIGATOR mit PIM-TPUART<br />
* TUL<br />
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.<br />
<br />
=== Vorbereiten des TUL ===<br />
==== TUL flashen ====<br />
Der TUL wird ohne Software geliefert und kann über den Raspberry Pi programmiert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install dfu-programmer<br />
wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54<br />
sudo dfu-programmer atmega32u4 erase<br />
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex<br />
sudo dfu-programmer atmega32u4 reset<br />
sudo reboot<br />
</syntaxhighlight><br />
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.<br />
Der TUL hat an der Unterseite einen winzigen Button. Dieser muss gedrückt werden, während der TUL in die USB-Buchse gesteckt wird.<br />
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.<br />
<br />
==== TUL einen dauerhaften Namen geben ====<br />
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<br />
<syntaxhighlight lang="bash"><br />
ls -la /dev/serial/by-id/<br />
</syntaxhighlight><br />
identifiziert. Das Ergebnis sollte ungefähr so aussehen<br />
<syntaxhighlight lang="bash"><br />
usb-busware.de_TPUART_8543934393935171B1C1-if00 -> ../../ttyACM0<br />
</syntaxhighlight><br />
Die Seriennummer (8543934393935171B1C1) wird später benötigt. Der Befehl<br />
<syntaxhighlight lang="bash"><br />
lsusb<br />
</syntaxhighlight><br />
sollte u.a. diese Zeile liefern<br />
<syntaxhighlight lang="bash"><br />
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project<br />
</syntaxhighlight><br />
03eb ist dabei die Herstellerkennung, 204b die Produktkennung. Nun muss die Datei /etc/udev/rules.d/99-usb-serial.rules<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/udev/rules.d/99-usb-serial.rules<br />
</syntaxhighlight><br />
erstellt oder erweitert werden mit der Zeile<br />
<syntaxhighlight lang="bash"><br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="8543934393935171B1C1", SYMLINK+="knx", OWNER="knxd"<br />
</syntaxhighlight><br />
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.<br />
<br />
=== Vorbereiten des Raspberry Pi für ROT oder PIGATOR ===<br />
Der Raspberry Pi nutzt standardmäßig die serielle Schnittstelle als Terminal. Dies muss deaktiviert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo raspi-config<br />
5 Interfaceoption<br />
P6 Serial<br />
</syntaxhighlight><br />
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:<br />
<syntaxhighlight lang="bash"><br />
sudo usermod -aG dialout knxd<br />
</syntaxhighlight><br />
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<br />
<syntaxhighlight lang="bash"><br />
dtoverlay=disable-bt<br />
</syntaxhighlight><br />
am Ende eingefügt werden. Nun muss noch der Dienst hciuart deaktiviert werden (initialisiert das Bluetooth-Modem):<br />
<syntaxhighlight lang="bash"><br />
sudo systemctl disable hciuart<br />
</syntaxhighlight><br />
Nach einem anschließenden Reboot ist der TPUART unter ttyAMA0 ansprechbar.<br />
<br />
=== Andere BCU's (BusCouplerUnit) ===<br />
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.}}<br />
<br />
=== Installieren des knxd ===<br />
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.<br />
<br />
=== Konfiguration ===<br />
Die Konfiguration erfolgt wieder in der knxd.conf mit<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf<br />
</syntaxhighlight><br />
Nun die Konfiguarionszeile anpassen<br><br />
(serielle Schnittstelle)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/ttyAMA0"<br />
</syntaxhighlight><br />
(USB)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/knx"<br />
</syntaxhighlight><br />
Und dann noch<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
um knxd beim Systemstart sofort zu starten.<br />
<br />
-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 <br />
<syntaxhighlight lang="bash"><br />
define KNX TUL eibd:127.0.0.1 1.2.203<br />
</syntaxhighlight><br />
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.}}<br />
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)<br />
<syntaxhighlight lang="bash"><br />
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts<br />
"1" durch "0" ersetzen<br />
</syntaxhighlight><br />
Nach einem<br />
<syntaxhighlight lang="bash"><br />
sudo reboot<br />
</syntaxhighlight><br />
sollte der knxd dann laufen.<br />
<br />
== FAQ ==<br />
'''Wie wird eibd vorher deinstalliert?'''<br />
<syntaxhighlight lang="bash"><br />
sudo rm -r /usr/local/bin/{eibd,knxtool,group*} /usr/local/lib/lib{eib,pthsem}*.so* /usr/local/include/pth*<br />
</syntaxhighlight><br />
<br />
<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. <br />
<br />
'''folgender Fehler: dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install git-core build-essential<br />
</syntaxhighlight><br />
<br />
oder<br />
<br />
<syntaxhighlight lang="bash"><br />
in der datei knxd/debian/rules die Zeile:<br />
bash tools/test.sh auskommentieren<br />
</syntaxhighlight><br />
<br />
'''Fehler: dpkg-buildpackage: error: fakeroot not found, either install the fakeroot <....> '''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install fakeroot dpkg-dev<br />
</syntaxhighlight><br />
<br />
== Links ==<br />
* [[Benutzer:Marthinx]]<br />
* [https://github.com/knxd/knxd Github knxd]<br />
* [https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen Forums-Thread zu knxd. Sehr informativ.]<br />
<br />
[[Kategorie:Examples]]<br />
[[Kategorie:EIB/KNX]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Knxd&diff=37076Knxd2022-01-11T14:29:15Z<p>F Klee: /* Konfiguration */</p>
<hr />
<div>== knxd mit einem IP Gateway einrichten ==<br />
Damit FHEM auf den KNX Bus zugreifen kann, wird ein passendes Interface benötigt. Es gibt:<br />
* RS232<br />
* USB<br />
* IP<br />
<br />
Im Folgenden wird die Einrichtung von knxd mit einem IP Gateway auf einem Raspberry Pi2 mit Wheezy oder Jessie beschrieben.<br />
<br />
=== Installation ===<br />
<br />
==== Für Debian Jessie: ====<br />
'''als erstes müssen folgende Pakete installiert werden (Referenz Debian Jessie):'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
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<br />
</syntaxhighlight><br />
<br />
'''knxd herunterladen und installieren'''<br />
Achtung: Wenn Abhängigkeiten fehlen, dann müssen diese nachinstalliert werden. Nicht einfach mittels "-d" diese übergehen!<br />
<syntaxhighlight lang="bash"><br />
git clone https://github.com/knxd/knxd.git<br />
cd knxd<br />
git checkout deb<br />
dpkg-buildpackage -b -uc<br />
cd ..<br />
sudo dpkg -i knxd_*.deb knxd-tools_*.deb<br />
</syntaxhighlight><br />
<br />
==== Ab Debian Stretch, Buster, ... ====<br />
'''knxd ist in den Debian packages vorhanden, muss daher nicht compiliert werden.'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install knxd knxd-tools<br />
<br />
</syntaxhighlight><br />
<br />
Mit der Konfiguration '''mit Systemd weitermachen!''' <br />
=== Konfiguration ===<br />
'''1. Ohne systemd'''<br />
<br />
Es muss als nächstes die Konfigurationsdatei editiert werden, das geht mit:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/default/knxd <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
DAEMON_ARGS="-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.188.XX"<br />
</syntaxhighlight><br />
und<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
<br />
'''2. Mit systemd z. B. für Debian Jessie'''<br />
<br />
Die Konfigurationsdatei bei Jessie hat sich wegen der Nutzung von systemd geändert:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b ipt:192.168.188.XX"<br />
<br />
</syntaxhighlight><br />
=== knxd Status überprüfen ===<br />
<syntaxhighlight lang="bash"><br />
/etc/init.d/knxd status<br />
</syntaxhighlight><br />
<br />
== knxd als IP-Gateway einrichten ==<br />
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.:<br />
* ROT<br />
* PIGATOR mit PIM-TPUART<br />
* TUL<br />
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.<br />
<br />
=== Vorbereiten des TUL ===<br />
==== TUL flashen ====<br />
Der TUL wird ohne Software geliefert und kann über den Raspberry Pi programmiert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install dfu-programmer<br />
wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54<br />
sudo dfu-programmer atmega32u4 erase<br />
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex<br />
sudo dfu-programmer atmega32u4 reset<br />
sudo reboot<br />
</syntaxhighlight><br />
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.<br />
Der TUL hat an der Unterseite einen winzigen Button. Dieser muss gedrückt werden, während der TUL in die USB-Buchse gesteckt wird.<br />
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.<br />
<br />
==== TUL einen dauerhaften Namen geben ====<br />
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<br />
<syntaxhighlight lang="bash"><br />
ls -la /dev/serial/by-id/<br />
</syntaxhighlight><br />
identifiziert. Das Ergebnis sollte ungefähr so aussehen<br />
<syntaxhighlight lang="bash"><br />
usb-busware.de_TPUART_8543934393935171B1C1-if00 -> ../../ttyACM0<br />
</syntaxhighlight><br />
Die Seriennummer (8543934393935171B1C1) wird später benötigt. Der Befehl<br />
<syntaxhighlight lang="bash"><br />
lsusb<br />
</syntaxhighlight><br />
sollte u.a. diese Zeile liefern<br />
<syntaxhighlight lang="bash"><br />
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project<br />
</syntaxhighlight><br />
03eb ist dabei die Herstellerkennung, 204b die Produktkennung. Nun muss die Datei /etc/udev/rules.d/99-usb-serial.rules<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/udev/rules.d/99-usb-serial.rules<br />
</syntaxhighlight><br />
erstellt oder erweitert werden mit der Zeile<br />
<syntaxhighlight lang="bash"><br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="8543934393935171B1C1", SYMLINK+="knx", OWNER="knxd"<br />
</syntaxhighlight><br />
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.<br />
<br />
=== Vorbereiten des Raspberry Pi für ROT oder PIGATOR ===<br />
Der Raspberry Pi nutzt standardmäßig die serielle Schnittstelle als Terminal. Dies muss deaktiviert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo raspi-config<br />
5 Interfaceoption<br />
P6 Serial<br />
</syntaxhighlight><br />
Der knxd arbeitet als Benutzer knxd. Dieser muss noch der Gruppe dialout zugeordnet werden, damit er auf ttyAMA0 zugreifen kann:<br />
<syntaxhighlight lang="bash"><br />
sudo usermod -aG dialout knxd<br />
</syntaxhighlight><br />
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<br />
<syntaxhighlight lang="bash"><br />
dtoverlay=disable-bt<br />
</syntaxhighlight><br />
am Ende eingefügt werden. Nun muss noch der Dienst hciuart deaktiviert werden (initialisiert das Bluetooth-Modem):<br />
<syntaxhighlight lang="bash"><br />
sudo systemctl disable hciuart<br />
</syntaxhighlight><br />
Nach einem anschließenden Reboot ist der TPUART unter ttyAMA0 ansprechbar.<br />
<br />
=== Andere BCU's (BusCouplerUnit) ===<br />
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.}}<br />
<br />
=== Installieren des knxd ===<br />
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.<br />
<br />
=== Konfiguration ===<br />
Die Konfiguration erfolgt wieder in der knxd.conf mit<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf<br />
</syntaxhighlight><br />
Nun die Konfiguarionszeile anpassen<br><br />
(serielle Schnittstelle)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/ttyAMA0"<br />
</syntaxhighlight><br />
(USB)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/knx"<br />
</syntaxhighlight><br />
Und dann noch<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
um knxd beim Systemstart sofort zu starten.<br />
<br />
-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 <br />
<syntaxhighlight lang="bash"><br />
define KNX TUL eibd:127.0.0.1 1.2.203<br />
</syntaxhighlight><br />
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.}}<br />
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)<br />
<syntaxhighlight lang="bash"><br />
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts<br />
"1" durch "0" ersetzen<br />
</syntaxhighlight><br />
Nach einem<br />
<syntaxhighlight lang="bash"><br />
sudo reboot<br />
</syntaxhighlight><br />
sollte der knxd dann laufen.<br />
<br />
== FAQ ==<br />
'''Wie wird eibd vorher deinstalliert?'''<br />
<syntaxhighlight lang="bash"><br />
sudo rm -r /usr/local/bin/{eibd,knxtool,group*} /usr/local/lib/lib{eib,pthsem}*.so* /usr/local/include/pth*<br />
</syntaxhighlight><br />
<br />
<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. <br />
<br />
'''folgender Fehler: dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install git-core build-essential<br />
</syntaxhighlight><br />
<br />
oder<br />
<br />
<syntaxhighlight lang="bash"><br />
in der datei knxd/debian/rules die Zeile:<br />
bash tools/test.sh auskommentieren<br />
</syntaxhighlight><br />
<br />
'''Fehler: dpkg-buildpackage: error: fakeroot not found, either install the fakeroot <....> '''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install fakeroot dpkg-dev<br />
</syntaxhighlight><br />
<br />
== Links ==<br />
* [[Benutzer:Marthinx]]<br />
* [https://github.com/knxd/knxd Github knxd]<br />
* [https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen Forums-Thread zu knxd. Sehr informativ.]<br />
<br />
[[Kategorie:Examples]]<br />
[[Kategorie:EIB/KNX]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Knxd&diff=37075Knxd2022-01-11T14:24:23Z<p>F Klee: /* Vorbereiten des Raspberry Pi für ROT oder PIGATOR */</p>
<hr />
<div>== knxd mit einem IP Gateway einrichten ==<br />
Damit FHEM auf den KNX Bus zugreifen kann, wird ein passendes Interface benötigt. Es gibt:<br />
* RS232<br />
* USB<br />
* IP<br />
<br />
Im Folgenden wird die Einrichtung von knxd mit einem IP Gateway auf einem Raspberry Pi2 mit Wheezy oder Jessie beschrieben.<br />
<br />
=== Installation ===<br />
<br />
==== Für Debian Jessie: ====<br />
'''als erstes müssen folgende Pakete installiert werden (Referenz Debian Jessie):'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
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<br />
</syntaxhighlight><br />
<br />
'''knxd herunterladen und installieren'''<br />
Achtung: Wenn Abhängigkeiten fehlen, dann müssen diese nachinstalliert werden. Nicht einfach mittels "-d" diese übergehen!<br />
<syntaxhighlight lang="bash"><br />
git clone https://github.com/knxd/knxd.git<br />
cd knxd<br />
git checkout deb<br />
dpkg-buildpackage -b -uc<br />
cd ..<br />
sudo dpkg -i knxd_*.deb knxd-tools_*.deb<br />
</syntaxhighlight><br />
<br />
==== Ab Debian Stretch, Buster, ... ====<br />
'''knxd ist in den Debian packages vorhanden, muss daher nicht compiliert werden.'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install knxd knxd-tools<br />
<br />
</syntaxhighlight><br />
<br />
Mit der Konfiguration '''mit Systemd weitermachen!''' <br />
=== Konfiguration ===<br />
'''1. Ohne systemd'''<br />
<br />
Es muss als nächstes die Konfigurationsdatei editiert werden, das geht mit:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/default/knxd <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
DAEMON_ARGS="-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.188.XX"<br />
</syntaxhighlight><br />
und<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
<br />
'''2. Mit systemd z. B. für Debian Jessie'''<br />
<br />
Die Konfigurationsdatei bei Jessie hat sich wegen der Nutzung von systemd geändert:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b ipt:192.168.188.XX"<br />
<br />
</syntaxhighlight><br />
=== knxd Status überprüfen ===<br />
<syntaxhighlight lang="bash"><br />
/etc/init.d/knxd status<br />
</syntaxhighlight><br />
<br />
== knxd als IP-Gateway einrichten ==<br />
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.:<br />
* ROT<br />
* PIGATOR mit PIM-TPUART<br />
* TUL<br />
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.<br />
<br />
=== Vorbereiten des TUL ===<br />
==== TUL flashen ====<br />
Der TUL wird ohne Software geliefert und kann über den Raspberry Pi programmiert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install dfu-programmer<br />
wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54<br />
sudo dfu-programmer atmega32u4 erase<br />
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex<br />
sudo dfu-programmer atmega32u4 reset<br />
sudo reboot<br />
</syntaxhighlight><br />
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.<br />
Der TUL hat an der Unterseite einen winzigen Button. Dieser muss gedrückt werden, während der TUL in die USB-Buchse gesteckt wird.<br />
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.<br />
<br />
==== TUL einen dauerhaften Namen geben ====<br />
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<br />
<syntaxhighlight lang="bash"><br />
ls -la /dev/serial/by-id/<br />
</syntaxhighlight><br />
identifiziert. Das Ergebnis sollte ungefähr so aussehen<br />
<syntaxhighlight lang="bash"><br />
usb-busware.de_TPUART_8543934393935171B1C1-if00 -> ../../ttyACM0<br />
</syntaxhighlight><br />
Die Seriennummer (8543934393935171B1C1) wird später benötigt. Der Befehl<br />
<syntaxhighlight lang="bash"><br />
lsusb<br />
</syntaxhighlight><br />
sollte u.a. diese Zeile liefern<br />
<syntaxhighlight lang="bash"><br />
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project<br />
</syntaxhighlight><br />
03eb ist dabei die Herstellerkennung, 204b die Produktkennung. Nun muss die Datei /etc/udev/rules.d/99-usb-serial.rules<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/udev/rules.d/99-usb-serial.rules<br />
</syntaxhighlight><br />
erstellt oder erweitert werden mit der Zeile<br />
<syntaxhighlight lang="bash"><br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="8543934393935171B1C1", SYMLINK+="knx", OWNER="knxd"<br />
</syntaxhighlight><br />
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.<br />
<br />
=== Vorbereiten des Raspberry Pi für ROT oder PIGATOR ===<br />
Der Raspberry Pi nutzt standardmäßig die serielle Schnittstelle als Terminal. Dies muss deaktiviert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo raspi-config<br />
5 Interfaceoption<br />
P6 Serial<br />
</syntaxhighlight><br />
Der knxd arbeitet als Benutzer knxd. Dieser muss noch der Gruppe dialout zugeordnet werden, damit er auf ttyAMA0 zugreifen kann:<br />
<syntaxhighlight lang="bash"><br />
sudo usermod -aG dialout knxd<br />
</syntaxhighlight><br />
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<br />
<syntaxhighlight lang="bash"><br />
dtoverlay=disable-bt<br />
</syntaxhighlight><br />
am Ende eingefügt werden. Nun muss noch der Dienst hciuart deaktiviert werden (initialisiert das Bluetooth-Modem):<br />
<syntaxhighlight lang="bash"><br />
sudo systemctl disable hciuart<br />
</syntaxhighlight><br />
Nach einem anschließenden Reboot ist der TPUART unter ttyAMA0 ansprechbar.<br />
<br />
=== Andere BCU's (BusCouplerUnit) ===<br />
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.}}<br />
<br />
=== Installieren des knxd ===<br />
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.<br />
<br />
=== Konfiguration ===<br />
Die Konfiguration erfolgt wieder in der knxd.conf mit<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf<br />
</syntaxhighlight><br />
Nun die Konfiguarionszeile anpassen<br><br />
(serielle Schnittstelle)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/ttyAMA0"<br />
</syntaxhighlight><br />
(USB)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/knx"<br />
</syntaxhighlight><br />
Und dann noch<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
um knxd beim Systemstart sofort zu starten.<br />
<br />
-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 <br />
<syntaxhighlight lang="bash"><br />
define KNX TUL eibd:127.0.0.1 1.2.203<br />
</syntaxhighlight><br />
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.}}<br />
Wurde die BCU über die serielle Schnittstelle angeschaltet, so muss der knxd noch die Berechtigung bekommen, auf diese zuzugreifen. Dazu fügen wir den Benutzer knxd der Gruppe dialout hinzu.<br />
<syntaxhighlight lang="bash"><br />
sudo usermod -aG dialout knxd<br />
</syntaxhighlight><br />
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)<br />
<syntaxhighlight lang="bash"><br />
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts<br />
"1" durch "0" ersetzen<br />
</syntaxhighlight><br />
Nach einem<br />
<syntaxhighlight lang="bash"><br />
sudo reboot<br />
</syntaxhighlight><br />
sollte der knxd dann laufen.<br />
<br />
== FAQ ==<br />
'''Wie wird eibd vorher deinstalliert?'''<br />
<syntaxhighlight lang="bash"><br />
sudo rm -r /usr/local/bin/{eibd,knxtool,group*} /usr/local/lib/lib{eib,pthsem}*.so* /usr/local/include/pth*<br />
</syntaxhighlight><br />
<br />
<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. <br />
<br />
'''folgender Fehler: dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install git-core build-essential<br />
</syntaxhighlight><br />
<br />
oder<br />
<br />
<syntaxhighlight lang="bash"><br />
in der datei knxd/debian/rules die Zeile:<br />
bash tools/test.sh auskommentieren<br />
</syntaxhighlight><br />
<br />
'''Fehler: dpkg-buildpackage: error: fakeroot not found, either install the fakeroot <....> '''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install fakeroot dpkg-dev<br />
</syntaxhighlight><br />
<br />
== Links ==<br />
* [[Benutzer:Marthinx]]<br />
* [https://github.com/knxd/knxd Github knxd]<br />
* [https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen Forums-Thread zu knxd. Sehr informativ.]<br />
<br />
[[Kategorie:Examples]]<br />
[[Kategorie:EIB/KNX]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Knxd&diff=37074Knxd2022-01-11T14:22:12Z<p>F Klee: /* Vorbereiten des Raspberry Pi für ROT oder PIGATOR */</p>
<hr />
<div>== knxd mit einem IP Gateway einrichten ==<br />
Damit FHEM auf den KNX Bus zugreifen kann, wird ein passendes Interface benötigt. Es gibt:<br />
* RS232<br />
* USB<br />
* IP<br />
<br />
Im Folgenden wird die Einrichtung von knxd mit einem IP Gateway auf einem Raspberry Pi2 mit Wheezy oder Jessie beschrieben.<br />
<br />
=== Installation ===<br />
<br />
==== Für Debian Jessie: ====<br />
'''als erstes müssen folgende Pakete installiert werden (Referenz Debian Jessie):'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
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<br />
</syntaxhighlight><br />
<br />
'''knxd herunterladen und installieren'''<br />
Achtung: Wenn Abhängigkeiten fehlen, dann müssen diese nachinstalliert werden. Nicht einfach mittels "-d" diese übergehen!<br />
<syntaxhighlight lang="bash"><br />
git clone https://github.com/knxd/knxd.git<br />
cd knxd<br />
git checkout deb<br />
dpkg-buildpackage -b -uc<br />
cd ..<br />
sudo dpkg -i knxd_*.deb knxd-tools_*.deb<br />
</syntaxhighlight><br />
<br />
==== Ab Debian Stretch, Buster, ... ====<br />
'''knxd ist in den Debian packages vorhanden, muss daher nicht compiliert werden.'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install knxd knxd-tools<br />
<br />
</syntaxhighlight><br />
<br />
Mit der Konfiguration '''mit Systemd weitermachen!''' <br />
=== Konfiguration ===<br />
'''1. Ohne systemd'''<br />
<br />
Es muss als nächstes die Konfigurationsdatei editiert werden, das geht mit:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/default/knxd <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
DAEMON_ARGS="-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.188.XX"<br />
</syntaxhighlight><br />
und<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
<br />
'''2. Mit systemd z. B. für Debian Jessie'''<br />
<br />
Die Konfigurationsdatei bei Jessie hat sich wegen der Nutzung von systemd geändert:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b ipt:192.168.188.XX"<br />
<br />
</syntaxhighlight><br />
=== knxd Status überprüfen ===<br />
<syntaxhighlight lang="bash"><br />
/etc/init.d/knxd status<br />
</syntaxhighlight><br />
<br />
== knxd als IP-Gateway einrichten ==<br />
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.:<br />
* ROT<br />
* PIGATOR mit PIM-TPUART<br />
* TUL<br />
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.<br />
<br />
=== Vorbereiten des TUL ===<br />
==== TUL flashen ====<br />
Der TUL wird ohne Software geliefert und kann über den Raspberry Pi programmiert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install dfu-programmer<br />
wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54<br />
sudo dfu-programmer atmega32u4 erase<br />
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex<br />
sudo dfu-programmer atmega32u4 reset<br />
sudo reboot<br />
</syntaxhighlight><br />
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.<br />
Der TUL hat an der Unterseite einen winzigen Button. Dieser muss gedrückt werden, während der TUL in die USB-Buchse gesteckt wird.<br />
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.<br />
<br />
==== TUL einen dauerhaften Namen geben ====<br />
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<br />
<syntaxhighlight lang="bash"><br />
ls -la /dev/serial/by-id/<br />
</syntaxhighlight><br />
identifiziert. Das Ergebnis sollte ungefähr so aussehen<br />
<syntaxhighlight lang="bash"><br />
usb-busware.de_TPUART_8543934393935171B1C1-if00 -> ../../ttyACM0<br />
</syntaxhighlight><br />
Die Seriennummer (8543934393935171B1C1) wird später benötigt. Der Befehl<br />
<syntaxhighlight lang="bash"><br />
lsusb<br />
</syntaxhighlight><br />
sollte u.a. diese Zeile liefern<br />
<syntaxhighlight lang="bash"><br />
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project<br />
</syntaxhighlight><br />
03eb ist dabei die Herstellerkennung, 204b die Produktkennung. Nun muss die Datei /etc/udev/rules.d/99-usb-serial.rules<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/udev/rules.d/99-usb-serial.rules<br />
</syntaxhighlight><br />
erstellt oder erweitert werden mit der Zeile<br />
<syntaxhighlight lang="bash"><br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="8543934393935171B1C1", SYMLINK+="knx", OWNER="knxd"<br />
</syntaxhighlight><br />
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.<br />
<br />
=== Vorbereiten des Raspberry Pi für ROT oder PIGATOR ===<br />
Der Raspberry Pi nutzt standardmäßig die serielle Schnittstelle als Terminal. Dies muss deaktiviert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo raspi-config<br />
5 Interfaceoption<br />
P6 Serial<br />
</syntaxhighlight><br />
Der knxd arbeitet als Benutzer knxd. Dieser muss noch der Gruppe dialout zugeordnet werden, damit er auf ttyAMA0 zugreifen kann:<br />
<syntaxhighlight lang="bash"><br />
usermod -aG dialout knxd<br />
</syntaxhighlight><br />
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<br />
<syntaxhighlight lang="bash"><br />
dtoverlay=disable-bt<br />
</syntaxhighlight><br />
am Ende eingefügt werden. Nun muss noch der Dienst hciuart deaktiviert werden (initialisiert das Bluetooth-Modem):<br />
<syntaxhighlight lang="bash"><br />
sudo systemctl disable hciuart<br />
</syntaxhighlight><br />
Nach einem anschließenden Reboot ist der TPUART unter ttyAMA0 ansprechbar.<br />
<br />
=== Andere BCU's (BusCouplerUnit) ===<br />
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.}}<br />
<br />
=== Installieren des knxd ===<br />
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.<br />
<br />
=== Konfiguration ===<br />
Die Konfiguration erfolgt wieder in der knxd.conf mit<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf<br />
</syntaxhighlight><br />
Nun die Konfiguarionszeile anpassen<br><br />
(serielle Schnittstelle)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/ttyAMA0"<br />
</syntaxhighlight><br />
(USB)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/knx"<br />
</syntaxhighlight><br />
Und dann noch<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
um knxd beim Systemstart sofort zu starten.<br />
<br />
-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 <br />
<syntaxhighlight lang="bash"><br />
define KNX TUL eibd:127.0.0.1 1.2.203<br />
</syntaxhighlight><br />
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.}}<br />
Wurde die BCU über die serielle Schnittstelle angeschaltet, so muss der knxd noch die Berechtigung bekommen, auf diese zuzugreifen. Dazu fügen wir den Benutzer knxd der Gruppe dialout hinzu.<br />
<syntaxhighlight lang="bash"><br />
sudo usermod -aG dialout knxd<br />
</syntaxhighlight><br />
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)<br />
<syntaxhighlight lang="bash"><br />
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts<br />
"1" durch "0" ersetzen<br />
</syntaxhighlight><br />
Nach einem<br />
<syntaxhighlight lang="bash"><br />
sudo reboot<br />
</syntaxhighlight><br />
sollte der knxd dann laufen.<br />
<br />
== FAQ ==<br />
'''Wie wird eibd vorher deinstalliert?'''<br />
<syntaxhighlight lang="bash"><br />
sudo rm -r /usr/local/bin/{eibd,knxtool,group*} /usr/local/lib/lib{eib,pthsem}*.so* /usr/local/include/pth*<br />
</syntaxhighlight><br />
<br />
<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. <br />
<br />
'''folgender Fehler: dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install git-core build-essential<br />
</syntaxhighlight><br />
<br />
oder<br />
<br />
<syntaxhighlight lang="bash"><br />
in der datei knxd/debian/rules die Zeile:<br />
bash tools/test.sh auskommentieren<br />
</syntaxhighlight><br />
<br />
'''Fehler: dpkg-buildpackage: error: fakeroot not found, either install the fakeroot <....> '''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install fakeroot dpkg-dev<br />
</syntaxhighlight><br />
<br />
== Links ==<br />
* [[Benutzer:Marthinx]]<br />
* [https://github.com/knxd/knxd Github knxd]<br />
* [https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen Forums-Thread zu knxd. Sehr informativ.]<br />
<br />
[[Kategorie:Examples]]<br />
[[Kategorie:EIB/KNX]]</div>F Kleehttp://wiki.fhem.de/w/index.php?title=Knxd&diff=37073Knxd2022-01-11T14:21:06Z<p>F Klee: /* Vorbereiten des Raspberry Pi für ROT oder PIGATOR */</p>
<hr />
<div>== knxd mit einem IP Gateway einrichten ==<br />
Damit FHEM auf den KNX Bus zugreifen kann, wird ein passendes Interface benötigt. Es gibt:<br />
* RS232<br />
* USB<br />
* IP<br />
<br />
Im Folgenden wird die Einrichtung von knxd mit einem IP Gateway auf einem Raspberry Pi2 mit Wheezy oder Jessie beschrieben.<br />
<br />
=== Installation ===<br />
<br />
==== Für Debian Jessie: ====<br />
'''als erstes müssen folgende Pakete installiert werden (Referenz Debian Jessie):'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
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<br />
</syntaxhighlight><br />
<br />
'''knxd herunterladen und installieren'''<br />
Achtung: Wenn Abhängigkeiten fehlen, dann müssen diese nachinstalliert werden. Nicht einfach mittels "-d" diese übergehen!<br />
<syntaxhighlight lang="bash"><br />
git clone https://github.com/knxd/knxd.git<br />
cd knxd<br />
git checkout deb<br />
dpkg-buildpackage -b -uc<br />
cd ..<br />
sudo dpkg -i knxd_*.deb knxd-tools_*.deb<br />
</syntaxhighlight><br />
<br />
==== Ab Debian Stretch, Buster, ... ====<br />
'''knxd ist in den Debian packages vorhanden, muss daher nicht compiliert werden.'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install knxd knxd-tools<br />
<br />
</syntaxhighlight><br />
<br />
Mit der Konfiguration '''mit Systemd weitermachen!''' <br />
=== Konfiguration ===<br />
'''1. Ohne systemd'''<br />
<br />
Es muss als nächstes die Konfigurationsdatei editiert werden, das geht mit:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/default/knxd <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
DAEMON_ARGS="-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.188.XX"<br />
</syntaxhighlight><br />
und<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
<br />
'''2. Mit systemd z. B. für Debian Jessie'''<br />
<br />
Die Konfigurationsdatei bei Jessie hat sich wegen der Nutzung von systemd geändert:<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf <br />
</syntaxhighlight><br />
dann folgende Einträge anpassen:<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -c -DTRS -b ipt:192.168.188.XX"<br />
<br />
</syntaxhighlight><br />
=== knxd Status überprüfen ===<br />
<syntaxhighlight lang="bash"><br />
/etc/init.d/knxd status<br />
</syntaxhighlight><br />
<br />
== knxd als IP-Gateway einrichten ==<br />
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.:<br />
* ROT<br />
* PIGATOR mit PIM-TPUART<br />
* TUL<br />
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.<br />
<br />
=== Vorbereiten des TUL ===<br />
==== TUL flashen ====<br />
Der TUL wird ohne Software geliefert und kann über den Raspberry Pi programmiert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install dfu-programmer<br />
wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54<br />
sudo dfu-programmer atmega32u4 erase<br />
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex<br />
sudo dfu-programmer atmega32u4 reset<br />
sudo reboot<br />
</syntaxhighlight><br />
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.<br />
Der TUL hat an der Unterseite einen winzigen Button. Dieser muss gedrückt werden, während der TUL in die USB-Buchse gesteckt wird.<br />
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.<br />
<br />
==== TUL einen dauerhaften Namen geben ====<br />
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<br />
<syntaxhighlight lang="bash"><br />
ls -la /dev/serial/by-id/<br />
</syntaxhighlight><br />
identifiziert. Das Ergebnis sollte ungefähr so aussehen<br />
<syntaxhighlight lang="bash"><br />
usb-busware.de_TPUART_8543934393935171B1C1-if00 -> ../../ttyACM0<br />
</syntaxhighlight><br />
Die Seriennummer (8543934393935171B1C1) wird später benötigt. Der Befehl<br />
<syntaxhighlight lang="bash"><br />
lsusb<br />
</syntaxhighlight><br />
sollte u.a. diese Zeile liefern<br />
<syntaxhighlight lang="bash"><br />
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project<br />
</syntaxhighlight><br />
03eb ist dabei die Herstellerkennung, 204b die Produktkennung. Nun muss die Datei /etc/udev/rules.d/99-usb-serial.rules<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/udev/rules.d/99-usb-serial.rules<br />
</syntaxhighlight><br />
erstellt oder erweitert werden mit der Zeile<br />
<syntaxhighlight lang="bash"><br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="8543934393935171B1C1", SYMLINK+="knx", OWNER="knxd"<br />
</syntaxhighlight><br />
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.<br />
<br />
=== Vorbereiten des Raspberry Pi für ROT oder PIGATOR ===<br />
Der Raspberry Pi nutzt standardmäßig die serielle Schnittstelle als Terminal. Dies muss deaktiviert werden:<br />
<syntaxhighlight lang="bash"><br />
sudo raspi-config<br />
5 Interfaceoption<br />
P6 Serial<br />
</syntaxhighlight><br />
Der knxd arbeitet als Benutzer knxd. Dieser muss noch der Gruppe dialout zugeordnet werden:<br />
<syntaxhighlight lang="bash"><br />
usermod -aG dialout knxd<br />
</syntaxhighlight><br />
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<br />
<syntaxhighlight lang="bash"><br />
dtoverlay=disable-bt<br />
</syntaxhighlight><br />
am Ende eingefügt werden. Nun muss noch der Dienst hciuart deaktiviert werden (initialisiert das Bluetooth-Modem):<br />
<syntaxhighlight lang="bash"><br />
sudo systemctl disable hciuart<br />
</syntaxhighlight><br />
Nach einem anschließenden Reboot ist der TPUART unter ttyAMA0 ansprechbar.<br />
<br />
=== Andere BCU's (BusCouplerUnit) ===<br />
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.}}<br />
<br />
=== Installieren des knxd ===<br />
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.<br />
<br />
=== Konfiguration ===<br />
Die Konfiguration erfolgt wieder in der knxd.conf mit<br />
<syntaxhighlight lang="bash"><br />
sudo nano /etc/knxd.conf<br />
</syntaxhighlight><br />
Nun die Konfiguarionszeile anpassen<br><br />
(serielle Schnittstelle)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/ttyAMA0"<br />
</syntaxhighlight><br />
(USB)<br />
<syntaxhighlight lang="bash"><br />
KNXD_OPTS="-e 1.2.202 -E 1.2.203:8 -u /tmp/eib -c -DTRS -b tpuarts:/dev/knx"<br />
</syntaxhighlight><br />
Und dann noch<br />
<syntaxhighlight lang="bash"><br />
START_KNXD=YES<br />
</syntaxhighlight><br />
um knxd beim Systemstart sofort zu starten.<br />
<br />
-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 <br />
<syntaxhighlight lang="bash"><br />
define KNX TUL eibd:127.0.0.1 1.2.203<br />
</syntaxhighlight><br />
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.}}<br />
Wurde die BCU über die serielle Schnittstelle angeschaltet, so muss der knxd noch die Berechtigung bekommen, auf diese zuzugreifen. Dazu fügen wir den Benutzer knxd der Gruppe dialout hinzu.<br />
<syntaxhighlight lang="bash"><br />
sudo usermod -aG dialout knxd<br />
</syntaxhighlight><br />
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)<br />
<syntaxhighlight lang="bash"><br />
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts<br />
"1" durch "0" ersetzen<br />
</syntaxhighlight><br />
Nach einem<br />
<syntaxhighlight lang="bash"><br />
sudo reboot<br />
</syntaxhighlight><br />
sollte der knxd dann laufen.<br />
<br />
== FAQ ==<br />
'''Wie wird eibd vorher deinstalliert?'''<br />
<syntaxhighlight lang="bash"><br />
sudo rm -r /usr/local/bin/{eibd,knxtool,group*} /usr/local/lib/lib{eib,pthsem}*.so* /usr/local/include/pth*<br />
</syntaxhighlight><br />
<br />
<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. <br />
<br />
'''folgender Fehler: dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2'''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install git-core build-essential<br />
</syntaxhighlight><br />
<br />
oder<br />
<br />
<syntaxhighlight lang="bash"><br />
in der datei knxd/debian/rules die Zeile:<br />
bash tools/test.sh auskommentieren<br />
</syntaxhighlight><br />
<br />
'''Fehler: dpkg-buildpackage: error: fakeroot not found, either install the fakeroot <....> '''<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install fakeroot dpkg-dev<br />
</syntaxhighlight><br />
<br />
== Links ==<br />
* [[Benutzer:Marthinx]]<br />
* [https://github.com/knxd/knxd Github knxd]<br />
* [https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen Forums-Thread zu knxd. Sehr informativ.]<br />
<br />
[[Kategorie:Examples]]<br />
[[Kategorie:EIB/KNX]]</div>F Klee