FHEMWiki - Benutzerbeiträge [de]

Solar-/PV-Übersicht

2023-03-25T08:10:36Z

Plin53177: /* Angrenzende Themen */

<div style="float:right;margin-left:10px">__TOC__</div>
Die Seite [[Solar-/PV-Übersicht]] soll einen schnellen Einstieg in die für Solar-/Photovoltaik-Betreiber relevanten Seiten und Threads ermöglichen. Bitte bei Bedarf selbständig ergänzen.

==Forum==
Der Forenbereich {{Link2Forum|Area=Solaranlagen}} enthält Themen rund um Solaranlagen zur Wärme- oder Stromgewinnung.

Unter der Überschrift {{Link2Forum|Topic=116747|LinkText="Frevel: Die Idee einheitlicher Devicenamen und Readings"}} findet gerade eine Diskussion zum Thema Namenskonventionen für Readings statt.

== Allgemein ==
* [[Fotovoltaikanlage]]
* Viele Seiten der Kategorie [[:Kategorie:Energieerzeugungsmessung|Energieerzeugungsmessung]]

==Wechselrichter==
===Kostal===
* [[KostalPiko]]
* [[Kostal Plenticore 10 Plus]]

===SMA===
* [[SMAWechselrichter]]

===Solar Edge===
* [[SolarEdge SE10k]]

===Sunways===
* [[NT5000]]

==Speicher==
* [[Sonnenspeicher]]

==Monitoring/Auswertung==
* [[Enecsys Monitoring System]]
* [[SunnyHomeManager]]
* [[Datenbankgestützte Erstellung der Energiebilanz einer SMA PV-Anlage mit Überschusseinspeisung]]
* [[SolarLog]]
* [[SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung]]

==Angrenzende Themen==
Verwandte Themen, "gern verwendete" oder erforderliche Module, etc.:
* [[ModbusAttr]]
* [[SMLUSB]]
* [[EBUS-ECMD]]
* [[Stromzähler auslesen]]
* Externer Link [https://www.photovoltaikforum.com/ Photovoltaik-Forum]

[[Kategorie:Energieerzeugungsmessung]]

Solar-/PV-Übersicht

2023-03-25T08:05:38Z

Plin53177: /* Monitoring/Auswertung */

<div style="float:right;margin-left:10px">__TOC__</div>
Die Seite [[Solar-/PV-Übersicht]] soll einen schnellen Einstieg in die für Solar-/Photovoltaik-Betreiber relevanten Seiten und Threads ermöglichen. Bitte bei Bedarf selbständig ergänzen.

==Forum==
Der Forenbereich {{Link2Forum|Area=Solaranlagen}} enthält Themen rund um Solaranlagen zur Wärme- oder Stromgewinnung.

Unter der Überschrift {{Link2Forum|Topic=116747|LinkText="Frevel: Die Idee einheitlicher Devicenamen und Readings"}} findet gerade eine Diskussion zum Thema Namenskonventionen für Readings statt.

== Allgemein ==
* [[Fotovoltaikanlage]]
* Viele Seiten der Kategorie [[:Kategorie:Energieerzeugungsmessung|Energieerzeugungsmessung]]

==Wechselrichter==
===Kostal===
* [[KostalPiko]]
* [[Kostal Plenticore 10 Plus]]

===SMA===
* [[SMAWechselrichter]]

===Solar Edge===
* [[SolarEdge SE10k]]

===Sunways===
* [[NT5000]]

==Speicher==
* [[Sonnenspeicher]]

==Monitoring/Auswertung==
* [[Enecsys Monitoring System]]
* [[SunnyHomeManager]]
* [[Datenbankgestützte Erstellung der Energiebilanz einer SMA PV-Anlage mit Überschusseinspeisung]]
* [[SolarLog]]
* [[SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung]]

==Angrenzende Themen==
Verwandte Themen, "gern verwendete" oder erforderliche Module, etc.:
* [[ModbusAttr]]
* [[SMLUSB]]
* Externer Link [https://www.photovoltaikforum.com/ Photovoltaik-Forum]

[[Kategorie:Energieerzeugungsmessung]]

Wertpapieranzeige

2021-06-17T08:45:48Z

Plin53177: /* Voraussetzungen */

Der [[{{PAGENAME}}|Artikel "Wertpapieranzeige"]] beschreibt das Vorgehen zur Erzeugung einer komfortablen Anzeige verschiedener Wertpapiere in einer Liste auf Basis des Modules 98_STOCKQUOTES.pm
== Ergebnis ==
''Natürlich'' habe ich hier die wirklichen Zahlen unkenntlich gemacht (pah, 9.1.2021)

[[File:Depot.png|800px]]

==Voraussetzungen==
Die Einrichtung eines Depots mit dem Modul 98 STOCKQUOTES wird hier [[STOCKQUOTES]] beschrieben.

Für das folgende nehmen wir an, dass in dem Depot verschiedene Teildepots mit unterschiedlichen Währungen vorhanden sind, z.B. ''Depot2_EUR'' für Euro, ''Depot2_GBP'' für britische Pfund.

Für jede Fremdwährung (z.B. GBP) muss ferner irgendein Device existieren (z.B. als Dummy), in welchem der Umrechnungskurs steht und per Perl-Funktion
Value("EUR_GBP")
(bzw. entsprechend für andere Währungen) abgefragt werden kann. Diese Abfrage wird für die Formatierung benötigt und muss ggf. angepasst werden.

== readingsGroup ==
Zunächst wird die readingsGroup definiert, dabei gibt es zwei(!) Zeilen für jedes Teildepot in einer anderen Währung:
define Depot2_Detail readingsgroup < >,<Symbol>,<Stock>,<Value>,<Change_Rel>,<Change_Abs>,<Trend>,<Rate>,<Count>,<Cur>
Depot2_EUR:depot_cur_value_total,depot_p_change_total,depot_value_diff_total,depot_buy_value_total:t
Depot2_EUR:@2,<#1>,(.*)_name,#1_d_cur_value_total,#1_d_p_change_total,#1_d_value_diff_total,#1_close,#1_last,#1_d_stockcount
Depot2_USD:depot_cur_value_total,depot_p_change_total,depot_value_diff_total,depot_buy_value_total:t
Depot2_USD:@2,<#1>,(.*)_name,#1_d_cur_value_total,#1_d_p_change_total,#1_d_value_diff_total,#1_close,#1_last,#1_d_stockcount,#1_currency
Depot2_SEK:depot_cur_value_total,depot_p_change_total,depot_value_diff_total,depot_buy_value_total:t
Depot2_SEK:@2,<#1>,(.*)_name,#1_d_cur_value_total,#1_d_p_change_total,#1_d_value_diff_total,#1_close,#1_last,#1_d_stockcount,#1_currency
Depot2_GBP:depot_cur_value_total,depot_p_change_total,depot_value_diff_total,depot_buy_value_total:t
Depot2_GBP:@2,<#1>,(.*)_name,#1_d_cur_value_total,#1_d_p_change_total,#1_d_value_diff_total,#1_close,#1_last,#1_d_stockcount,#1_currency
Die Kopfzeilen und -spalten werden mit breiteren Tabellenspalten versehen und hervorgehoben:
attr Depot2_Detail valueColumns { 'depot_cur_value_total' => 'colspan="2"','depot_buy_value_total' => 'colspan="4"'}
attr Depot2_Detail nameStyle style="font-weight:bold"
=== Formatierungen ===
Als Nächstes werden die Einzelwerte formatiert und bei Fremdwährungen umgerechnet. Dabei kann man auf spezielle Eigenschaften der Teildepots eingehen - beispielsweise wird im Nachfolgenden der ''_close''-Wert durch den Kursprovider nicht für eine Aktie, sondern für 100 Aktien angegeben und muss entsprechend herunterskaliert werden.
attr Depot2_Detail valueFormat
{if($READING =~ /.*name/){$VALUE=~/.*$(.*)$.*/;;$VALUE=$1}
elsif($READING =~ /.*((cur_value_total)|(value_diff_total))/ && $DEVICE eq "Depot2_EUR"){$VALUE.="€"}
elsif($READING =~ /.*((cur_value_total)|(value_diff_total))/ && $DEVICE =~ /Depot2_(.*)/ ){$VALUE=(int($VALUE/Value("EUR_".$1)*100)/100)."€"}
elsif($READING =~ /.*p_change_total/){$VALUE=(int($VALUE*10)/10)."%"}
elsif($READING =~ /(.*)_close/ && $DEVICE eq "Depot2_GBP"){my $tr=(100*ReadingsVal("$DEVICE",$1."_last",1)/ReadingsVal("$DEVICE",$1."_close",1)-1);(int(1000*$tr)/10)."%% ".(($tr>0.01)?"🢁":(($tr>0.001)?"🢅":(($tr>-0.001)?"🢂":(($tr>-0.01)?"🢆":"🢃")))) }
elsif($READING =~ /(.*)_close/){my $tr=(ReadingsVal("$DEVICE",$1."_last",1)/ReadingsVal("$DEVICE",$1."_close",1)-1);(int(1000*$tr)/10)."%% ".(($tr>0.01)?"🢁":(($tr>0.001)?"🢅":(($tr>-0.001)?"🢂":(($tr>-0.01)?"🢆":"🢃")))) }}
=== Farben ===
Im letzten Schritt werden jetzt noch Farben hinzugegeben
attr Depot_Detail valueStyle
{if($READING =~ /depot.*/ ){'style="background-color:#aaaaff;font-weight:bold;text-align:right"'}
elsif($READING =~ /.*cur_value_total/){'style="text-align:right"'}
elsif($READING =~ /.*((p_change_total)|(d_value_diff_total))/ && $VALUE<0){'style="color:red;text-align:right"'}
elsif($READING =~ /.*((p_change_total)|(d_value_diff_total))/ && $VALUE>0){'style="color:green;text-align:right"'}
elsif($READING =~ /(.*)_close/ && $DEVICE eq "Depot2_GBP"){my $tr=(100*ReadingsVal("$DEVICE",$1."_last",1)/ReadingsVal("$DEVICE",$1."_close",1)-1);'style="text-align:right;color:'. (($tr>0.01)?'green"':(($tr>0.001)?'#aaff44"':(($tr>-0.001)?'black"':(($tr>-0.01)?'#ffdd88"':'red"')))) }
elsif($READING =~ /(.*)_close/){my $tr=(ReadingsVal("$DEVICE",$1."_last",1)/ReadingsVal("$DEVICE",$1."_close",1)-1);'style="text-align:right;color:'.(($tr>0.01)?'green"':(($tr>0.001)?'#aaff44"':(($tr>-0.001)?'black"':(($tr>-0.01)?'#ffdd88"':'red"')))) }}

[[Kategorie:Code Snippets]]

Solar-/PV-Übersicht

2020-12-22T20:01:26Z

Plin53177: /* Forum */

<div style="float:right;margin-left:10px">__TOC__</div>
Die Seite [[Solar-/PV-Übersicht]] soll einen schnellen Einstieg in die für Solar-/Photovoltaik-Betreiber relevanten Seiten und Threads ermöglichen. Bitte bei Bedarf selbständig ergänzen.

==Forum==
Der Forenbereich {{Link2Forum|Area=Solaranlagen}} enthält Themen rund um Solaranlagen zur Wärme- oder Stromgewinnung

Unter "[https://forum.fhem.de/index.php/topic,116747.0.html Frevel: Die Idee einheitlicher Devicenamen und Readings]" findet gerade eine Diskussion zum Thema Namenskonventionen für Readings statt ..

== Allgemein ==
* [[Fotovoltaikanlage]]
* Viele Seiten der Kategorie [[:Kategorie:Energieerzeugungsmessung|Energieerzeugungsmessung]]

==Wechselrichter==
===Kostal===
* [[KostalPiko]]
* [[Kostal Plenticore 10 Plus]]

===SMA===
* [[SMAWechselrichter]]

===Solar Edge===
* [[SolarEdge SE10k]]

===Sunways===
* [[NT5000]]

==Speicher==
* [[Sonnenspeicher]]

==Monitoring/Auswertung==
* [[Enecsys Monitoring System]]
* [[SunnyHomeManager]]
* [[Datenbankgestützte Erstellung der Energiebilanz einer SMA PV-Anlage mit Überschusseinspeisung]]
* [[SolarLog]]

==Angrenzende Themen==
Verwandte Themen, "gern verwendete" oder erforderliche Module, etc.:
* [[ModbusAttr]]
* [[SMLUSB]]
* Externer Link [https://www.photovoltaikforum.com/ Photovoltaik-Forum]

[[Kategorie:Energieerzeugungsmessung]]

Grafana

2020-12-18T13:54:39Z

Plin53177: /* MySQL-Queries */

{{Randnotiz|RNText=Grafana beschreibt sich als "The open platform for beautiful analytics and monitoring".
Eine Live Demo zum Erkunden findet man im Internet unter [http://play.grafana.org play.grafana.org]}}

== Einführung ==
Die [[Grafana]]-Software stellt einen Server zur Verfügung, mit dem Zeitreihen von Zahlenwerten auf sehr handliche Weise dargestellt und manipuliert werden können. Die Auswahl bestimmter Zeitfenster, das Anlegen von Dashboards und die Gestaltung der Achsen (Minimum. Maximum) ist so sehr einfach möglich. Zudem gibt es verschiedene Paneltypen, die neben dem klassischen Chart (Line / Bar / Point) auch Pie Charts oder Tabellen beinhalten. Seit November 2017 kann Grafana mit MySQL umgehen, was eine Einbindung in FHEM (via DBLog) ermöglicht. Die Benutzeroberfläche lädt sehr schnell und ist auf vielen Geräten flüssig und einfach zu bedienen.

== Installation ==
Hier sind mehrere Schritte (einmalig) durchzuführen. Für Grafana muss ein eigener Server installiert werden und für die Grafiken müssen MySQL-Queries angelegt werden.

=== Installation und Einrichtung einer DBLog Instanz mit MySQL ===
Details sind auf der Seite [[DbLog#Beispiel:_Anlegen_und_Nutzung_einer_Mysql-Datenbank|Anlegen einer MySQL_Datenbank]] beschrieben.

Wenn schon eine Datenbank angelegt wurde und man Daten umziehen muss, helfen andere Einträge weiter.
Sollen zum Beispiel Altdaten aus SQLite gesichert und wieder in MySQL eingespielt werden, [[DbRep - Reporting und Management von DbLog-Datenbankinhalten#Datensätze (Devices) von einer Datenbank in eine andere umziehen (Export/Import)|hilft dieser Eintrag]]. Dieses Beispiel sichert nur Logdaten für ein einzelnes Gerät und nicht für alles aus der DB. Das lässt sich aber problemlos anpassen, indem man das Attribut device in der DBRep Instanz nicht belegt.

Ein Umstieg von Filelog auf DBLog geht ebenfalls. Sollen Altdaten aus den Filelogs übertragen werden, {{Link2Forum|Topic=66383|LinkText=hilft dieser Thread}}.

=== Installation des Grafana Servers ===
Es gibt [https://grafana.com/grafana/download einen offiziellen Download]. Der ist nicht ganz unproblematisch, und will man auf einem Raspberry Pi installieren, sollten eher vorkompilierte Pakete genutzt werden. Sie sind [https://github.com/fg2it/grafana-on-raspberry/releases unter diesem Link] zu finden.

Damit Grafana automatisch mit dem System startet, muss der Grafana Server noch aktiviert werden. Bei Verwendung von Systemd wäre das mit folgendem Befehl zu erledigen:
<syntaxhighlight lang="bash">
sudo /bin/systemctl enable grafana-server
</syntaxhighlight>
Im Grafana Webinterface muss dann eine neue Datasource vom Typ MySQL angelegt werden. Die Daten der FHEM-MYSQL Datenbank eintragen (Port/User/Passwort).

Grafana lauscht per default auf Port 3000. Dies kann ein Problem sein, falls man Alexa mit Custom Skill nutzt. Dieser Dienst belegt ebenfalls schon Port 3000.
In dem Fall mit
<syntaxhighlight lang="bash">
sudo nano /etc/grafana/grafana.ini
</syntaxhighlight>
und die Konfiguration anpassen:
:<code>;http_port = 3000</code>
Hier den führenden Semicolon entfernen und den Port entsprechend abändern. Zuletzt ist die Datenbank auszuwählen, in der die Daten von FHEM abgelegt sind (grafana greift standardmäßig auf eine Datenbank mit dem Namen grafana zurück).

== Erstellen von Grafiken ==
=== MySQL-Queries ===
Zeitreihen werden in Grafana durch MySQL-Queries angelegt. Jede Zeitreihe benötigt dabei einen eigenen Query. Grafana legt dabei einen Musterquery an, bei dem drei Werte geändert werden müssen.
[[Datei:Grafana_Query_anlegen.png|200px|thumb|right|Query anlegen]]

Man klickt im Dashboard von Grafana auf AddRow. Durch einen Klick auf den Titel der neuen Grafik erscheint ein Menü ("View", "Edit", "Share") und wählt Edit. Dann wählt man die FHEM-Datenbank aus, siehe Screenshot. Eine Musterabfrage sieht wie folgt aus:
<syntaxhighlight lang="SQL">
SELECT
UNIX_TIMESTAMP(< time >) as time_sec,
< column > as value,
< name > as metric
FROM < table name >
WHERE $__timeFilter(time_column)
ORDER BY < time > ASC
</syntaxhighlight>

Grafana benötigt in diesem Query mindestens drei Spalten mit der richtigen Benennung, die durch <>-Klammern vorgezeichnet sind.
* time_sec muss Zeitwerte im UNIX-Timestamp Format (Sekunden seit 01.01.1970) enthalten. Meist wählt man für < time > daher den TIMESTAMP Eintrag aus der Datenbank.
* value muss Werte für die Y-Achse liefern, welche den Zeitstempeln aus time_sec zuzuordnen sind. Meist wählt man für < column > daher den VALUE Eintrag aus der Datenbank.
* metric ist der Text, der für die Kurve in der Legende angezeigt wird. Daher ist < name > frei wählbar.

Die Namen der einzelnen Spalten werden durch FHEM selbst vergeben. Man muss also bei der Verwendung der Queries herausfinden, wie die Werte intern gespeichert werden. Das klingt schwerer als es ist, weil sich FHEM dabei an Konventionen hält, die leicht geraten werden können. Der nebenstehende Screenshot zeigt einen typischen Eintrag in der DBLog von FHEM.
[[Datei:TypischerQuery.png |200px|thumb|right|Typischer Eintrag in der DBLog]]

Beim den VALUE Einträgen von FHEM muss man beachten, dass diese (da sie auch Text beinhalten können) nicht numerisch sind. Soll schon intern im SELECT eine Berechnung durchgeführt werden wie AVG oder MIN/MAX, dann muss man hier CONVERT(VALUE, DOUBLE) oder CONVERT(VALUE, INTEGER) verwenden.

Ein Beispieleintrag sieht wie folgt aus
<syntaxhighlight lang="SQL">
SELECT
UNIX_TIMESTAMP(TIMESTAMP) as time_sec,
VALUE as value, "Kurvenbezeichnung" as metric
FROM history WHERE READING="state" AND DEVICE="MyDummy" AND $__timeFilter( TIMESTAMP )
</syntaxhighlight>

Solltet Ihr numerische Werte in einer Grafik ausgeben wollen, müsst Ihr das Text-Feld VALUE mittels '''cast(VALUE as signed)''' konvertieren
<syntaxhighlight lang="SQL">
SELECT
UNIX_TIMESTAMP(TIMESTAMP) as time_sec,
cast(VALUE as signed) as value, "Kurvenbezeichnung" as metric
FROM history WHERE READING="state" AND DEVICE="MyDummy" AND $__timeFilter( TIMESTAMP )
</syntaxhighlight>

=== Macros ===
Grafana bietet ein paar Macros die man in den MySQL Selects verwenden kann, um die zu ladenden Daten auf den angezeigten Zeitraum zu begrenzen.
* $__timeFilter(TIMESTAMP) liefert eine Überprüfung auf einen Zeitraum zurück, die man in der WHERE Bedingung verwenden kann (siehe obiges Beispiel)
* $__timeFrom() liefert den Startzeitpunkt des angezeigten Zeitraums als "YYYY-MM-DD HH:MM:SS" zurück.
* $__timeTo() liefert den Endzeitpunkt des angezeigten Zeitraums als "YYYY-MM-DD HH:MM:SS" zurück (so loggt auch DBLog in die Datenbank).
* $__unixEpochFrom() liefert den Startzeitpunkt des angezeigten Zeitraums als UNIX-Timestamp Format (Sekunden seit 01.01.1970) zurück.
* $__unixEpochTo liefert den Endzeitpunkt des angezeigten Zeitraums als UNIX-Timestamp Format (Sekunden seit 01.01.1970) zurück.

=== Beispiele ===
Sehr viele Beispiele hat Thyraz in diesem {{Link2Forum|Topic=77724|LinkText=Foreneintrag}} bereitgestellt. Eine ausführliche Erläuterung zu einen Anzeige von Differenzwerten finden sich in diesem [https://forum.fhem.de/index.php/topic,77724.msg1023943.html#msg1023943 Foreneintrag].

=== Einbindung in FHEM (und andere Seiten) ===
Die Grafiken können mit einem URL einfach in FHEM und andere Seiten eingebunden werden. Die entsprechende Adresse lautet dann
http://<URL-Grafana-Server>:3000/render/dashboard/db/<Name-des-Dashboards>?orgId=2&from=now%2Fd&to=now&panelId=1&width=750&height=300&tz=UTC%2B02%3A00
Dabei ist der Teil der URL from=now%2Fd&to=now individuell veränderbar. Standardmäßig sind das fixe Zeitpunkte (wie im Beispiel mit 1507705926296). Mit "Now" etc. kann man das dynamisch gestalten und so einen alternativen, dynamischen Plot im FHEM darstellen:
* from=now%2Fd&to=now: Today so far
* from=now-30d&to=now: Die letzten 30 Tage
* from=now-395d&to=now-365d: Die letzten 30 Tage vor einem Jahr (Temperaturvergleich zum Vorjahr z.B.)

Das entsprechende device, das in FHEMWEB die Grafik zur Verfügung stellt, ist dann weblink:
defmod <device_name> weblink image <HTTP-Adresse>:3000/render/dashboard-solo/db/<Datenbankname>?orgId=2&from=now%2Fd&to=now&panelId=1&width=750&height=300&tz=UTC%2B02%3A00

Entsprechende Attribute sind auch möglich:
attr <device-name> htmlattr width="750" height="300" frameborder="0" title="Aktueller Verlauf"

Bei FTUI würde man das Image Widget verwenden. Will man die Grafiken mit iframe einbinden, so muss zuerst in Grafana eine Sicherheitseinstellung verändert werden, die eigentlich eine solche iframe-Einbindung verhindert. Dazu fügt man im Security-Abschnitt der grafana.ini folgende Zeile ein
[security]
allow_embedding = true
und startet danach den grafana-server neu.

=== Speichern und Senden von Grafiken (z.B. mit Telegram) ===
Will man Grafiken von Grafana mit Telegram oder anderen Messenger-Programmen versenden, sind mehrere Schritte notwendig. Zuerst muss die Datei "gerendert" und lokal gespeichert werden, danach kann man sie versenden. Da das Rendern ''mehrere Sekunden'' dauern kann, sollte dieser Vorgang entweder nonblocking oder sogar außerhalb von FHEM erfolgen.

==== Erster Schritt: Rendern ====
Grafana verwendet eine Authentifizierungsmethode, die beim Rendern zu berücksichtigen ist. Tut man das nicht, so erhält man keine Grafik, sondern nur eine HTML-Datei die eben anzeigt, dass der Zugriff nicht authentifiziert erfolgte. Um sich zu authentifizieren, muss man einen neuen Nutzer anlegen und einen API-Key anfordern.

[[Datei:GrafanaAPIKey.png|200px|thumb|right|Auswahl des API-Key im Grafana-Menü]]
Im Hauptmenü von Grafana wählt man links oben unter "admin" den Eintrag API-Key aus. Dort legt man einen neuen Benutzer an und notiert sich den Schlüssel (er wird nur einmal angezeigt). Dieser Schlüssel ist eine sehr lange Zeichenkette, beispielsweise "0NWcWRCVjZtSkd81NG1EOEprdVYxRUJtZWZeyJrIjoidUNycWRCVjZtSkd0NW81NGX0=". Im Folgenden möge die Zeichenkette mit <Schluessel> bezeichnet werden.

Mit dieser Authentifizierungsschlüssel kann man nun auf Grafana zugreifen. Beispielsweise möchte man ein dashboard, das mehrere Temperaturen enthält, rendern. Dazu benötigt man nun die Zugriffsadresse dieses Dashboards. Man klickt auf die Überschrift des Boards und wählt "Share" aus. Es erscheint ein Share Panel, so wie im Screenshot angezeigt.
[[Datei:GrafanaSharePanel.png|200px|thumb|right|Grafana Share Panel]]
Unten im Panel ist ein Link mit den Worten "Direct link rendered image" zu sehen. Diesen Link notiert man. Im folgenden möge der Link mit <Link> bezeichnet werden.

Auf der Shell-Ebene würde nun der folgende Befehl das Dashboard rendern und speichern
curl -H "Authorization: Bearer <Schluessel>" "<Link>" <Dateiname>

Da in der neuen Grafana-Version das Rendern ''auf einem Raspberry Pi'' nicht ohne Weiteres unterstützt wird, kann es sein, dass die oben genannten Versuche fehlschlagen. Hier bietet sich eine andere Lösung an, die zwar nicht so elegant wie die obige ist, aber dafür funktioniert: Man installiert Firefox auf dem Raspberry und lässt ihn "headless" einen Screenshot erstellen. Dieses kann man dann weiterverarbeiten. Diese Lösung hat den Nachteil, dass dann nur die Auflösung des Raspberry erreicht wird. Dazu sind folgende Schritte noztwendig. Zuerst Firefox installieren
sudo apt install firefox-esr
danach ein neues Profil in Firefox erstellen (sonst stürzt Firefox ab), das ist sehr umständlich: Auf Hilfe gehen, dann steht dort irgendwo "install new profile" und dieses Profil beispielsweise headless_profil nennen und zuletzt kann dann endlich mit einem Terminal-Befehl ein Screenshot erstellt werden
/pfad/zu/firefox -P headless_profile -headless --screenshot <hier die www-Adresse der Webseite angeben>
Mehr dazu auf [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Headless_mode dieser Webseite]

==== Zweiter Schritt: Senden mit Telegram ====
Im zweiten Schritt soll nun die Datei gesendet werden. Dazu kann man etwa den [[TelegramBot|Telegram-Bot]] verwenden. Der Sendebefehl lautet
set <TelegramBotDevice-Name> sendImage <Dateiname>
Dabei ist der Dateiname des Bild (png-Format) anzugeben.

[[Kategorie:HOWTOS]]

Kostal Plenticore 10 Plus

2020-11-01T20:23:27Z

Plin53177: /* Passworte */

{{Infobox Hardware
|Bild=Kostal_Plenticore_10_Plus.jpg
|Bildbeschreibung=Kostal Plenticore 10 Plus
|HWProtocol=IP und RS485
|HWType=Hybrid Wechselrichter
|HWCategory=Wechselrichter
|HWComm=n/a
|HWChannels=n/a
|HWVoltage=400 V
|HWPowerConsumption=
|HWPoweredBy=3P AC
|HWSize=56,3x40,5x23,3 cm (BxHxT)
|HWDeviceFHEM=[[HTTPMOD]], [[Modbus]], [[Python3]]

|HWManufacturer=KOSTAL Solar Electric GmbH
}}
[[Bild:Plenticore FHEM 1.png|mini|900px|rechts|Die Diagramme im Überblick]]
[[Bild:Plenticore FHEM 2.png|mini|900px|rechts|Geräte Überblick mit manueller Schaltmöglichkeit]]
[[Bild:Plenticore FHEM 3.png|mini|900px|rechts|Steuerungsgeräte für die Schaltlogik]]
[[Bild:Plenticore FHEM 4.png|mini|900px|rechts|ReadingsGroup für die schnelle Parametereinstellung]]

Ein Hinweis allgemeiner Art: Die hier abgebildeten Code Stücke sind nicht ausschließlich durch mich entstanden. Ich bedanke mich für die Unterstützung und Bereitstellung vieler Einzelkomponenten durch Dritte. Der Einsatz ist auf eigene Gefahr und für etwaige Schäden wird keinerlei Haftung übernommen. Bitte beachtet bei der Hardware die Gewährleistungsbestimmungen und Vorgaben der Hersteller.

Der [[Kostal Plenticore 10 Plus]] [https://www.kostal-solar-electric.com/de-de/produkte/hybrid-wechselrichter/ Hersteller Link] ist ein Hybrid Wechselrichter mit IP-Konnektivität.

Er verfügt über einen LAN-Anschluss und ist auf die Steuerung via WebGUI des Herstellers ausgelegt. Weiterhin kann eine Abfrage mit Modbus/TCP oder auch über eine undokumentierte API erfolgen. Für die API bietet der Hersteller keinerlei Support!

== Voraussetzungen Energietechnik ==

Der Wechselrichter, der Speicher und der KSEM wurden durch einen Fachbetrieb installiert und konfiguriert. Die gesamte Anlage läuft fehlerfrei und wurde durch den Fachbetrieb abgenommen, sowie beim Netzbetreiber angemeldet.

== Geräte-Registrierung ==

Hierfür ist die Dokumentation des Herstellers heranzuziehen. Für eine Verlängerung der Gewährleistungszeit kann man den Plenticore im Herstellerportal registrieren. Dies ist jedoch für die Anbindung an FHEM nicht notwendig.

== Hersteller Dokumentation ==

Für Links auf dieser Wiki Seite wird keine Haftung übernommen. Die Inhalte unterliegen der Verantwortung der Firma Kostal.
* [https://www.kostal-solar-electric.com/de-de/service-und-support/smart-warranty/ Plenticore Plus - Verlängerung der Gewährleistungszeit]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/06/15/11/40/plenticore-plus_ba_de.pdf/ Plenticore Plus - Betriebsanleitung]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/04/12/08/26/plenticore-plus_kba.pdf/ Plenticore Plus - Kurzanleitung]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/04/12/08/26/db_plenticore-plus_de.pdf/ Plenticore Plus - Datenblatt]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/03/12/07/13/kostal_update_plenticore_piko_iq_011504581.swu/ Plenticore Plus - Software Update UI: 01.15.04581 FW: 01.43]

* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/08/30/08/53/ba_kostal_interface_modbus-tcp_sunspec.pdf/ Plenticore - Modbus\/ Sunspec]

* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/03/06/13/17/ksem-ba_de.pdf/ KSEM - Betriebsanleitung]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/03/06/13/17/ksem-db_de.pdf/ KSEM - Datenblatt]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2020/06/09/11/49/kostal_update_ksem_1_2_1.zip/ KSEM - Software Update - 1.2.1]

* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/05/09/13/57/ba_kostal_interface_ksem---201911.pdf/ KSEM - Modbus\/ Sunspec]

* [https://www.kostal-solar-electric.com/de-de/service-und-support/kontakt/ Kostal - Service Kontakt]

== Einbindung in das Netzwerk ==

Als Grundlage ist der Plenticore mit dem LAN zu verbinden, wodurch er eine TCP/IP Adresse per DHCP bekommt. Diese ist dann entweder am Display des Plenticore abzulesen, oder über die Oberfläche des Routers zu ermitteln.

Das gleiche gilt für den BYD Speicher, der jedoch zusätzlich auch über WLAN verfügt. Eine Netzwerkanbindung des Speichers ist beim Plenticore nicht zwingend notwendig, da der Plenticore mit dem Speicher über eine RS-485 Schnittstelle kommuniziert. Bei dieser Anbindung werden jedoch noch nicht alle möglichen Werte aus dem Speicher ausgelesen. Später wird hierzu jedoch noch mehr geschrieben, um alle Möglichkeiten offen zu halten.

Der KSEM kann ebenfalls auch direkt per LAN ausgelesen werden, was jedoch ebenfalls nicht zwingend notwendig ist. Eine Kommunikation des KSEM mit dem Plenticore erfolgt über zwei mögliche Wege. Beim Betrieb mit Speicher ist zwingend die RS485 Schnittstelle erforderlich, über die auch der Plenticore alle Werte übermittelt bekommt. Auch diese sind dann am Plenticore abfragbar. Der zweite Weg wäre dann über die LAN Verbindung, bei der jedoch kein Speicher am Plenticore konfigurierbar ist.

== Voraussetzungen FHEM Umfeld ==

=== Alle Geräte müssen mit TCP/IP erreichbar sein ===

=== Alle Module sollten auf einem aktuellen Stand sein ===

=== Python ===

==== Ein Python 3 sollte vorhanden sein ====
Wenn man die erweiterten Funktionalitäten, wie Statistiken, Speicher auslesen und später auch das Setzen von Werten im Plenticore, verwenden möchte.

==== Es müssen folgende Python Module vorhanden sein ====
<syntaxhighlight lang="Perl">
python3-pip

pip3 install pycryptodome
pip3 install -U fhem
</syntaxhighlight>
=== Eine LogDB/LogDBRep sollte bereits vorhanden sein, was hier nicht weiter erklärt wird. ===

=== Verwendete Module ===
<pre>
- Modbus
- HTTPMOD
- expandJSON
- DbLog
- DbRep
- dummy
- Shelly
- HourCounter
- readingsGroup
</pre>

== Einbindung in FHEM: Überblick ==

=== Hardware Anbindung (alles über LAN) ===

==== Kostal Plenticore Plus ====
===== Kostal Plenticore Plus die Basis information (Modbus/TCP) =====
Der Kostal Plenticore wird mittels des Moduls MODBUS eingebunden. Dazu gilt zunächst die folgende Konfiguration als Basis, die am Display des Plenticore oder auch in der Kostal Dokumentation zu entnehmen ist.
====== Plenticore Modbus Definition ======
<pre>
GeräteId : 71
IP-Adresse: <IP-Adresse>
Port : 1502
</pre>

====== Modbus Timing ======
Das Gerät aktualisiert sich im Abstand von 60 Sekunden durch den stetigen Modbus/TCP Datenstrom. Der Plenticore ist als Modbus Master implementiert und sendet somit alle Daten permanent ins Netzwerk.

Die Zeit kann auch verändert werden, jedoch sollte sie nicht zu kurz gewählt sein.

====== RAW Definition PV_Anlage_1_config ======
Diese Dummy soll alle Konfigurationsparameter halten, auf die dann die anderen Geräte Definitionen zentral zugreifen. Hier können auch default Namen und Vorschläge für Werte in Form von Slidern und Auswahllisten hinterlegt werden.
<syntaxhighlight lang="Perl">
defmod PV_Anlage_1_config dummy
attr PV_Anlage_1_config DbLogExclude .*
attr PV_Anlage_1_config alias PV_Anlage_1_config
attr PV_Anlage_1_config comment Steht das reading module_*_count auf 0 wird diese Ausrichtung nicht berücksichtigt\
Passworte zu dieser Konfiguration liegen im Dateiverzeichnis ~./python/pwd_*.json\
\
Korrekturkurven:\
Steilheit Parallel\
verschiebung\
tempk -0.39 25\
cloudk -0.65 0\
raink -0.30 0\
Der Slider für die Steilheit wird mit - k/100 umgerechnet. 39 ==> -0.39
attr PV_Anlage_1_config event-on-change-reading .*
attr PV_Anlage_1_config group PV Eigenverbrauch
attr PV_Anlage_1_config icon solar_icon
attr PV_Anlage_1_config readingList IP-Address_Plenticore IP-Address_BYD IP-Address_KSEM IP-Address_FHEM module_1_active module_2_active module_3_active module_1_name module_2_name module_3_name module_1_direction module_2_direction module_3_direction module_1_count module_2_count module_3_count module_1_power module_2_power module_3_power module_1_plain module_2_plain module_3_plain forecast_cloudk forecast_cloudk_base forecast_raink forecast_raink_base forecast_tempk forecast_tempk_base forecast_factor Forecast_Station Battery_Total_Power
attr PV_Anlage_1_config room Strom->Photovoltaik
attr PV_Anlage_1_config setList IP-Address_Plenticore IP-Address_BYD IP-Address_KSEM IP-Address_FHEM module_1_name:East,SouthEast,South,SouthWest,West,Garage,CarPort module_2_name:East,SouthEast,South,SouthWest,West module_3_name:East,SouthEast,South,SouthWest,West module_1_direction:slider,-90,5,+90 module_2_direction:slider,-90,5,90 module_3_direction:slider,-90,5,90 module_1_count:slider,0,1,40 module_2_count:slider,0,1,40 module_3_count:slider,0,1,40 module_1_power:slider,250,10,400 module_2_power:slider,250,10,400 module_3_power:slider,250,10,400 module_1_plain:slider,15,1,45 module_2_plain:slider,15,1,45 module_3_plain:slider,15,1,45 forecast_cloudk:slider,0,1,100 forecast_cloudk_base:slider,0,1,10 forecast_raink:slider,0,1,100 forecast_raink_base:slider,0,1,10 forecast_tempk:slider,0,1,100 forecast_tempk_base:slider,10,1,30 forecast_factor:1,1.5,2,2.5,3,3.5,4,4.5,5 Forecast_Station Battery_Total_Power
attr PV_Anlage_1_config sortby 04
attr PV_Anlage_1_config verbose 0

setstate PV_Anlage_1_config state
setstate PV_Anlage_1_config 2020-09-11 07:12:49 Battery_Total_Power 8960
setstate PV_Anlage_1_config 2020-09-11 07:36:39 Forecast_Station <Station>
setstate PV_Anlage_1_config 2020-08-31 12:44:46 IP-Address_BYD 192.168.178.10
setstate PV_Anlage_1_config 2020-08-31 12:39:26 IP-Address_FHEM 192.168.178.11
setstate PV_Anlage_1_config 2020-08-31 12:43:27 IP-Address_KSEM 192.168.178.12
setstate PV_Anlage_1_config 2020-08-31 12:39:44 IP-Address_Plenticore 192.168.178.13
setstate PV_Anlage_1_config 2020-09-02 18:39:15 forecast_cloudk 20
setstate PV_Anlage_1_config 2020-09-03 11:43:57 forecast_cloudk_base 0
setstate PV_Anlage_1_config 2020-09-02 18:40:29 forecast_raink 20
setstate PV_Anlage_1_config 2020-09-01 12:52:40 forecast_raink_base 0
setstate PV_Anlage_1_config 2020-09-01 12:46:57 forecast_tempk 39
setstate PV_Anlage_1_config 2020-09-01 12:50:06 forecast_tempk_base 25
setstate PV_Anlage_1_config 2020-08-31 12:27:30 module_1_count 0
setstate PV_Anlage_1_config 2020-08-31 12:27:38 module_1_direction -90
setstate PV_Anlage_1_config 2020-08-31 12:27:48 module_1_name East
setstate PV_Anlage_1_config 2020-08-31 12:29:42 module_1_plain 40
setstate PV_Anlage_1_config 2020-08-31 12:31:09 module_1_power 300
setstate PV_Anlage_1_config 2020-08-31 12:31:21 module_2_count 0
setstate PV_Anlage_1_config 2020-08-31 12:33:55 module_2_direction 0
setstate PV_Anlage_1_config 2020-08-31 12:34:03 module_2_name South
setstate PV_Anlage_1_config 2020-08-31 12:34:14 module_2_plain 40
setstate PV_Anlage_1_config 2020-08-31 12:34:25 module_2_power 300
setstate PV_Anlage_1_config 2020-08-31 12:34:42 module_3_count 0
setstate PV_Anlage_1_config 2020-08-31 12:34:50 module_3_direction 90
setstate PV_Anlage_1_config 2020-08-31 12:35:00 module_3_name West
setstate PV_Anlage_1_config 2020-08-31 12:35:08 module_3_plain 40
setstate PV_Anlage_1_config 2020-08-31 12:35:16 module_3_power 300
</syntaxhighlight>

====== RAW Definition PV_Anlage_1 ======
Für den Zugriff auf die Plenticore ModBus/TCP Daten wird dieses Device verwendet.
<syntaxhighlight lang="Perl">
defmod PV_Anlage_1 ModbusAttr 71 60 <IP-Address_Plenticore>:1502 TCP
attr PV_Anlage_1 DbLogExclude .*
attr PV_Anlage_1 DbLogInclude Act_state_of_charge,Actual_battery_charge_-minus_or_discharge_-plus_Power,Actual_battery_charge_usable_Power,Battery_temperature,Home_own_consumption_from_PV,Home_own_consumption_from_battery,Home_own_consumption_from_grid,Inverter_state,Power_DC1,Power_DC2,Power_DC_Sum,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Voltage_DC1,Voltage_DC2
attr PV_Anlage_1 alias PV_Einspeisung
attr PV_Anlage_1 comment Kostal Plenticore 10 Plus mit BYD Speicher
attr PV_Anlage_1 dev-h-defFormat %.2f
attr PV_Anlage_1 dev-h-defLen 2
attr PV_Anlage_1 dev-h-defPoll 1
attr PV_Anlage_1 dev-h-defRevRegs 1
attr PV_Anlage_1 dev-h-defUnpack f>
attr PV_Anlage_1 dev-type-STR-format %s
attr PV_Anlage_1 dev-type-STR-len 8
attr PV_Anlage_1 dev-type-STR-revRegs 0
attr PV_Anlage_1 dev-type-STR-unpack a*
attr PV_Anlage_1 event-on-change-reading Act_state_of_charge,Actual_battery_charge_.*,Battery_temperature,Home_own_consumption_from_.*,Inverter_state,Power_DC1,Power_DC2,Power_DC_Sum,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Voltage_DC1,Voltage_DC2,.*_yield,Solar_.*
attr PV_Anlage_1 group PV Eigenverbrauch
attr PV_Anlage_1 icon sani_solar
attr PV_Anlage_1 obj-h100-reading Total_DC_Power
attr PV_Anlage_1 obj-h104-format %s
attr PV_Anlage_1 obj-h104-reading State_of_energy_manager
attr PV_Anlage_1 obj-h104-revRegs 0
attr PV_Anlage_1 obj-h104-unpack N
attr PV_Anlage_1 obj-h106-reading Home_own_consumption_from_battery
attr PV_Anlage_1 obj-h108-reading Home_own_consumption_from_grid
attr PV_Anlage_1 obj-h110-reading Total_home_consumption_Battery
attr PV_Anlage_1 obj-h112-reading Total_home_consumption_Grid
attr PV_Anlage_1 obj-h114-reading Total_home_consumption_PV
attr PV_Anlage_1 obj-h116-reading Home_own_consumption_from_PV
attr PV_Anlage_1 obj-h118-reading Total_home_consumption
attr PV_Anlage_1 obj-h120-reading Isolation_resistance
attr PV_Anlage_1 obj-h122-reading Power_limit_from_EVU
attr PV_Anlage_1 obj-h124-reading Total_home_consumption_rate
attr PV_Anlage_1 obj-h14-reading Inverter_serial_number
attr PV_Anlage_1 obj-h14-type STR
attr PV_Anlage_1 obj-h144-reading Worktime
attr PV_Anlage_1 obj-h150-reading Actual_cos_phi
attr PV_Anlage_1 obj-h152-reading Grid_frequency
attr PV_Anlage_1 obj-h154-reading Current_Phase_1
attr PV_Anlage_1 obj-h156-reading Active_power_Phase_1
attr PV_Anlage_1 obj-h158-reading Voltage_Phase_1
attr PV_Anlage_1 obj-h160-reading Current_Phase_2
attr PV_Anlage_1 obj-h162-reading Active_power_Phase_2
attr PV_Anlage_1 obj-h164-reading Voltage_Phase_2
attr PV_Anlage_1 obj-h166-reading Current_Phase_3
attr PV_Anlage_1 obj-h168-reading Active_power_Phase_3
attr PV_Anlage_1 obj-h170-reading Voltage_Phase_3
attr PV_Anlage_1 obj-h172-reading Total_AC_active_power
attr PV_Anlage_1 obj-h174-reading Total_AC_reactive_power
attr PV_Anlage_1 obj-h178-reading Total_AC_apparent_power
attr PV_Anlage_1 obj-h190-reading Battery_charge_current
attr PV_Anlage_1 obj-h194-format %.0f
attr PV_Anlage_1 obj-h194-reading Number_of_battery_cycles
attr PV_Anlage_1 obj-h200-reading Actual_battery_charge_-minus_or_discharge_-plus_current
attr PV_Anlage_1 obj-h202-reading PSSB_fuse_state
attr PV_Anlage_1 obj-h208-format %.0f
attr PV_Anlage_1 obj-h208-reading Battery_ready_flag
attr PV_Anlage_1 obj-h210-reading Act_state_of_charge
attr PV_Anlage_1 obj-h212-reading Battery_state
attr PV_Anlage_1 obj-h214-reading Battery_temperature
attr PV_Anlage_1 obj-h216-reading Battery_voltage
attr PV_Anlage_1 obj-h218-reading Cos_phi_(powermeter)
attr PV_Anlage_1 obj-h220-reading Frequency_(powermeter)
attr PV_Anlage_1 obj-h222-reading Current_phase_1_(powermeter)
attr PV_Anlage_1 obj-h224-reading Active_power_phase_1_(powermeter)
attr PV_Anlage_1 obj-h226-reading Reactive_power_phase_1_(powermeter)
attr PV_Anlage_1 obj-h228-reading Apparent_power_phase_1_(powermeter)
attr PV_Anlage_1 obj-h230-reading Voltage_phase_1_(powermeter)
attr PV_Anlage_1 obj-h232-reading Current_phase_2_(powermeter)
attr PV_Anlage_1 obj-h234-reading Active_power_phase_2_(powermeter)
attr PV_Anlage_1 obj-h236-reading Reactive_power_phase_2_(powermeter)
attr PV_Anlage_1 obj-h238-reading Apparent_power_phase_2_(powermeter)
attr PV_Anlage_1 obj-h240-reading Voltage_phase_2_(powermeter)
attr PV_Anlage_1 obj-h242-reading Current_phase_3_(powermeter)
attr PV_Anlage_1 obj-h244-reading Active_power_phase_3_(powermeter)
attr PV_Anlage_1 obj-h246-reading Reactive_power_phase_3_(powermeter)
attr PV_Anlage_1 obj-h248-reading Apparent_power_phase_3_(powermeter)
attr PV_Anlage_1 obj-h250-reading Voltage_phase_3_(powermeter)
attr PV_Anlage_1 obj-h252-reading Total_active_power_(powermeter)
attr PV_Anlage_1 obj-h254-reading Total_reactive_power_(powermeter)
attr PV_Anlage_1 obj-h256-reading Total_apparent_power_(powermeter)
attr PV_Anlage_1 obj-h258-reading Current_DC1
attr PV_Anlage_1 obj-h260-reading Power_DC1
attr PV_Anlage_1 obj-h266-reading Voltage_DC1
attr PV_Anlage_1 obj-h268-reading Current_DC2
attr PV_Anlage_1 obj-h270-reading Power_DC2
attr PV_Anlage_1 obj-h276-reading Voltage_DC2
attr PV_Anlage_1 obj-h278-reading Current_DC3
attr PV_Anlage_1 obj-h280-reading Power_DC3
attr PV_Anlage_1 obj-h286-reading Voltage_DC3
attr PV_Anlage_1 obj-h320-reading Total_yield
attr PV_Anlage_1 obj-h322-reading Daily_yield
attr PV_Anlage_1 obj-h324-reading Yearly_yield
attr PV_Anlage_1 obj-h326-reading Monthly_yield
attr PV_Anlage_1 obj-h38-reading Software-Version_Maincontroller_(MC)
attr PV_Anlage_1 obj-h38-type STR
attr PV_Anlage_1 obj-h384-len 16
attr PV_Anlage_1 obj-h384-reading Inverter_network_name
attr PV_Anlage_1 obj-h384-type STR
attr PV_Anlage_1 obj-h420-reading IP-address
attr PV_Anlage_1 obj-h420-type STR
attr PV_Anlage_1 obj-h428-reading IP-subnetmask
attr PV_Anlage_1 obj-h428-type STR
attr PV_Anlage_1 obj-h436-reading IP-gateway
attr PV_Anlage_1 obj-h436-type STR
attr PV_Anlage_1 obj-h446-reading IP-DNS1
attr PV_Anlage_1 obj-h446-type STR
attr PV_Anlage_1 obj-h454-reading IP-DNS2
attr PV_Anlage_1 obj-h454-type STR
attr PV_Anlage_1 obj-h46-reading Software-Version_IO-Controller_(IOC)
attr PV_Anlage_1 obj-h46-type STR
attr PV_Anlage_1 obj-h514-len 1
attr PV_Anlage_1 obj-h514-reading Battery_actual_SOC
attr PV_Anlage_1 obj-h517-reading Battery_Manufacturer
attr PV_Anlage_1 obj-h517-type STR
attr PV_Anlage_1 obj-h525-format %c
attr PV_Anlage_1 obj-h525-reading Battery_Model_ID
attr PV_Anlage_1 obj-h525-unpack N
attr PV_Anlage_1 obj-h527-format %c
attr PV_Anlage_1 obj-h527-reading Battery_Serial_Number
attr PV_Anlage_1 obj-h529-len 4
attr PV_Anlage_1 obj-h529-reading Work_Capacity
attr PV_Anlage_1 obj-h529-unpack N
attr PV_Anlage_1 obj-h531-format %.0f
attr PV_Anlage_1 obj-h531-reading Inverter_Max_Power
attr PV_Anlage_1 obj-h531-unpack N
attr PV_Anlage_1 obj-h535-revRegs 0
attr PV_Anlage_1 obj-h535-unpack n
attr PV_Anlage_1 obj-h551-revRegs 0
attr PV_Anlage_1 obj-h559-revRegs 0
attr PV_Anlage_1 obj-h56-format %.0f
attr PV_Anlage_1 obj-h56-reading Inverter_state
attr PV_Anlage_1 obj-h56-unpack N
attr PV_Anlage_1 obj-h575-len 1
attr PV_Anlage_1 obj-h575-reading Inverter_Generation_Power_(actual)
attr PV_Anlage_1 obj-h577-len 2
attr PV_Anlage_1 obj-h577-reading Generation_Energy
attr PV_Anlage_1 obj-h577-unpack N
attr PV_Anlage_1 obj-h578-reading Total_energy
attr PV_Anlage_1 obj-h582-reading Actual_battery_charge-discharge_power
attr PV_Anlage_1 obj-h586-format %s
attr PV_Anlage_1 obj-h586-reading Battery_Firmware
attr PV_Anlage_1 obj-h586-unpack N
attr PV_Anlage_1 obj-h588-format %s
attr PV_Anlage_1 obj-h588-len 1
attr PV_Anlage_1 obj-h588-reading Battery_Type
attr PV_Anlage_1 obj-h588-unpack N
attr PV_Anlage_1 obj-h6-reading Inverter_article_number
attr PV_Anlage_1 obj-h6-type STR
attr PV_Anlage_1 obj-h768-len 32
attr PV_Anlage_1 obj-h768-reading Productname
attr PV_Anlage_1 obj-h768-type STR
attr PV_Anlage_1 obj-h800-len 32
attr PV_Anlage_1 obj-h800-reading Power_class
attr PV_Anlage_1 obj-h800-type STR
attr PV_Anlage_1 room Strom->Photovoltaik
attr PV_Anlage_1 sortby 01
attr PV_Anlage_1 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TH ALIGN=\"MIDDLE\" WIDTH=\"20\">Batterie %s</TH>\
<TH ALIGN=\"MIDDLE\" WIDTH=\"20\">aktuell</TH>\
<TH ALIGN=\"RIGHT\" WIDTH=\"20\">Hausverbrauch</TH>\
<TH ALIGN=\"MIDDLE\" WIDTH=\"20\">Erträge</TH>\
</TR>\
\
<TR>\
<TD ALIGN=\"MIDDLE\" WIDTH=\"20\">\
Leistung: %04d W<br>\
Temp.: %02.1f °C<br>\
Ladung total: %2d %%<br>\
Ladung Res.: %04d Wh\
</TD>\
\
<TD ALIGN=\"RIGHT\" WIDTH=\"20\">\
DC total: %05d W<br>\
<br>\
<br>\
PV reserve: %05d W\
</TD>\
\
<TD ALIGN=\"RIGHT\" WIDTH=\"20\">\
von PV: %05d W <br>\
von Batterie: %05d W<br>\
vom Netz: %05d W<br>\
ins Haus: %05d W<br>\
Netz: %05d W\
</TD>\
\
<TD ALIGN=\"RIGHT\" WIDTH=\"20\">\
Tag: %05d KWh <br>\
Monat: %05d KWh<br>\
Jahr: %05d KWh<br>\
Total: %05d KWh\
</TD>\
</TR>\
\
</TABLE>\
" , \
(ReadingsVal($name,"Actual_battery_charge_-minus_or_discharge_-plus_Power",0) lt 0) ? "<span style='color:#00FF00'>Laden</span>":"<span style='color:#FF0000'>Entladen</span>" ,\
\
ReadingsVal($name,"Actual_battery_charge_-minus_or_discharge_-plus_Power",0),\
ReadingsVal($name,"Battery_temperature",0) ,\
ReadingsVal($name,"Act_state_of_charge",0) ,\
ReadingsVal($name,"Actual_battery_charge_usable_Power",0) ,\
\
ReadingsVal($name,"Power_DC_Sum","0"),\
ReadingsVal($name,"Total_PV_Power_reserve","0"),\
\
ReadingsVal($name,"Home_own_consumption_from_PV",0) ,\
ReadingsVal($name,"Home_own_consumption_from_battery",0) ,\
ReadingsVal($name,"Home_own_consumption_from_grid",0),\
ReadingsVal($name,"Home_own_consumption_from_PV",0) +ReadingsVal($name,"Home_own_consumption_from_battery",0)+ReadingsVal($name,"Home_own_consumption_from_grid",0),\
ReadingsVal($name,"Total_active_power_(powermeter)",0),\
\
round(ReadingsVal($name,"Daily_yield",0)/1000 ,0),\
round(ReadingsVal($name,"Monthly_yield",0)/1000 ,0) ,\
round(ReadingsVal($name,"Yearly_yield",0)/1000 ,0) ,\
round(ReadingsVal($name,"Total_yield",0)/1000 ,0)\
)}
attr PV_Anlage_1 userReadings Power_DC_Sum:Total_DC_Power.* { ReadingsVal($NAME,"Power_DC1","0")+ReadingsVal($NAME,"Power_DC2","0") },\
\
Total_PV_Power_reserve:Total_DC_Power.* {my $reserve = ReadingsVal($NAME,"Power_DC_Sum","0") * 0.90 - ReadingsVal($NAME,"Home_own_consumption_from_PV","0");;;; ($reserve lt 0)?0:round($reserve,3) },\
\
Total_DC_Power_Max:Total_DC_Power.* { my $Bat_out = (ReadingsVal($NAME,"Actual_battery_charge_-minus_or_discharge_-plus_current","0")*ReadingsVal($NAME,"Battery_voltage","0"));;;; ($Bat_out gt 0)?ReadingsVal($NAME,"Power_DC_Sum","0") + $Bat_out :ReadingsVal($NAME,"Power_DC_Sum","0") },\
\
Actual_battery_charge_-minus_or_discharge_-plus_Power:Actual_battery_charge_-minus_or_discharge_-plus_current.* {round((ReadingsVal($NAME,"Actual_battery_charge_-minus_or_discharge_-plus_current","0")*ReadingsVal($NAME,"Battery_voltage","0")),0)},\
\
Actual_battery_charge_usable_Power:Act_state_of_charge.* {my $x = (ReadingsVal($NAME."_config","Battery_Total_Power","0")*(ReadingsVal($NAME,"Act_state_of_charge","0")-10)/100);; ($x lt 0)?0:round($x,0) }
attr PV_Anlage_1 verbose 0
</syntaxhighlight>

====== Userreadings ======
Um später einige Abfragen und Diagramme einfacher zu erstellen wurden einige userreadings erstellt, die bereits bei der RAW Definition mit vorhanden sind. Während der Integration in FHEM und der Konfiguration kann es hierdurch jedoch noch Fehlermeldungen im FHEM Log geben, da noch nicht alle Werte vorhanden sind. Dies betrifft insbesondere die Statistics_* readings, die durch ein Python Skript später erzeugt werden.

Power_DC_Sum
Trigger: Total_DC_Power.*
Dies berechnet direkt die Summe der DC-Leistung. Wenn der Plenticore einen Speicher hat, wird dieser am String 3 angeschlossen,
sollte also kein Speicher vorhanden sein muss man hier den dritten String auch noch addieren.
Total_PV_Power_reserve
Trigger: Total_DC_Power.*
Hier wird ein reading erstellt, dass als Information über die verwendbare Reserve dient. Die Leistung, die in den Speicher geht
sollte man nämlich besser sofort verbrauchen, anstatt es erst zu speicher. Die 0.90 ist ein circa Wirkungsgrad, um von DC- auf AC-Leistung zu kommen.
Der Total_PV_Power_reserve Wert kann gerne nach eigenen Belangen kalkuliert werden.
Total_DC_Power_Max
Trigger: Total_DC_Power.*
Um die Batterieleistung mit zu berücksichtigen wird dieser Momentan Wert ermittelt.
Actual_battery_charge_-minus_or_discharge_-plus_Power
Trigger: Actual_battery_charge_-minus_or_discharge_-plus_current.*
Berechnung der Batterie Leistung aus Spannung und Strom , der wert kann positiv oder negativ sein, je nach dem ob geladen oder entladen wird.
Actual_battery_charge_usable_Power
Trigger: Act_state_of_charge.*
Dieser Wert gibt an, wieviel Leistung im Speicher vorhanden ist, reduziert um 10% Verluste. An dieser Stelle muss die Nennleistung des Speichers über das PV_Anlage_1_config Gerät
eingetragen werden, da diese noch nicht ausgelesen werden kann. Obwohl es im "Battery_Type 892941625" stecken könnte. 8929 >> 8.93 KW ???

===== Kostal Plenticore Plus die API (über HTTPMOD mit Python Skript Authentifizierung) =====
Der Plenticore erstellt intern noch diverse Statistiken, die auch über das WebGUI angesehen werden können. Diese werden jedoch nicht über MODBUS/TCP ausgegeben, aber zum Kostal Portal übermittelt, wo man dann bereits in Form von Diagrammen einen schönen Überblick bekommt. Das Ziel ist jedoch die Statistiken lokal im FHEM abzulegen, sie lassen sich nur über die API des Plenticore abfragen.
Für diesen API Zugang über HTTP steht nun ein neues Gerät zur Verfügung, dass mit HTTPMOD und Python Authentifizierungsskripten die mehrstufige Anmeldung durchführt. Das ganze soll in Zukunft den starren Zugriff auf die Statistiken ablösen und eine Erweiterung zum setzen von Parametern im Plenticore bieten.

====== Umstellungsaufwand, falls jemand früher eingestiegen ist. ======
Die erste Folge für den Umstieg ist, dass die Statistiken nicht mehr im PV_Anlage_1 Gerät abgelegt werden, da diese ja teil der API Abfrage sind. Das muss dann in der Bilanz berücksichtigt werden, da die Einträge dann unter dem neuen PV_Anlage_1_API Gerät abgelegt werden.

2020.09.06 Die Umstellung auf das Plenticore API Gerät hat begonnen

- Die Bilanz RAW Definition wurde aktualisiert

- In der PV_Schedule Definition wurde das Kommando für die Aktualisierung der Statistik auf PV_Anlage_1_API umgestellt

- Das Logging von Dum.Energy läuft wie gehabt weiter

- Die Statistic_* readings aus dem PV_Anlage_1 Gerät können in der SQL Datenbank zum neuen PV_Anlage_1_API Gerät verschoben werden.
<syntaxhighlight lang="SQL">
## Bitte zuerst den Zeitraum, in dem die Statistikeinträge in die Datenbank geschrieben wurden feststellen.
MySQL [fhem]> SELECT TIMESTAMP,DEVICE,READING,VALUE FROM history WHERE DEVICE='PV_Anlage_1_API' AND READING LIKE 'Statistic_%' AND TIMESTAMP > '2020-07-01 00:00:00' ORDER BY TIMESTAMP LIMIT 500;
## Für den Update dann din Zeitraum so weit es geht einschränken, damit die Laufzeit in der Datenbank nicht so hoch wird.
MySQL [fhem]> UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API' WHERE DEVICE='PV_Anlage_1' AND READING LIKE 'Statistic_%' AND TIMESTAMP > '2020-07-01 00:00:00';
</syntaxhighlight>
- Die alten Statistic_* readings können nun aus dem PV_Anlage_1 Gerät entfernt werden
<syntaxhighlight lang="Perl">
deletereading PV_Anlage_1 Statistic_.*
deletereading PV_Anlage_1 statistics_.*
</syntaxhighlight>
- Für das Logging kann nun im Attribut "DbLogInclude" ebenfalls "Statistic_.*" entfernt werden

- Beim Attribut "event-on-change-reading" sind auch "statistics_.*,Statistic_.*" zu entfernen

- Das userreading im PV_Anlage_1 kann ebenfalls geändert werden und um diese Zeile verkürzt werden.
<syntaxhighlight lang="Perl">
statistics_clean:statistics_output.* { my $x = ReadingsVal($NAME,"statistics_output",0);; $x =~ s/"moduleid": "scb:statistic:EnergyFlow", |, "moduleid": "scb:statistic:EnergyFlow"|"processdata": \[//g;; $x =~ s/id": "|, "unit": "", "value"|^\[|\]\}\]$//g;; $x =~ s/moduleid/statistics_00_moduleid/g;; $x =~ s/processdata/statistics/g;; $x =~ s/\}\, \{/\, /g;; $x =~ s/\{\{/\{/g;; return $x }
</syntaxhighlight>
- Nun noch das Gerät Plenticore_Statistics für das expandJSON löschen
<syntaxhighlight lang="Perl">
delete Plenticore_Statistics
</syntaxhighlight>
Das sollten nun alle erforderlichen Bereinigungen für den Wechsel auf das PV_Anlage_1_API Gerät sein.

====== Plenticore API ======
<syntaxhighlight lang="Perl">
http://<IP-Address_Plenticore>/api/v1
</syntaxhighlight>

====== Dateiverzeichnis ======
<pre>
/opt/fhem
/opt/fhem/python/pwd_fhem.json
/opt/fhem/python/pwd_plenticore.json
/opt/fhem/python/bin
/opt/fhem/python/bin/plenticore_auth_finish.py
/opt/fhem/python/bin/plenticore_auth_session.py
</pre>

====== Python 3 ======
<pre>
fhem@raspberrypi:~/python/bin$ which python3
/usr/bin/python3
fhem@raspberrypi:~/python/bin$ python3 --version
Python 3.7.3
</pre>

====== Passworte ======
Die Passworte für den Plenticore und den FHEM Zugang liegen in einzelnen JSON Dateien.
Für den Plenticore wird das Passwort für den Benutzer "Anlagenbetreiber" verwendet, der bei der API als Benutzer "user" bezeichnet wird.
Im einfachsten Fall steht das Passwort auf dem Gehäuse, sofern es der Installateur nicht neu gesetzt hat. Testet es einfach mit einem Login im Web Interface des Plenticore.

Für die Verbindung zum Fhem wird ein Python Modul verwendet, das einen Login mit http auf den Fhem Web Zugang macht.
Für eine passwortlose Verbindung werden username und password mit "" angegeben.

fhem@raspberrypi:~/python$ cat pwd_plenticore.json
<pre>
{
"username": "user",
"password": "<Steht auf dem Gehäuse>"
}
</pre>

fhem@raspberrypi:~/python$ cat pwd_fhem.json
<pre>
{
"username": "<Ein Fhem Web User>",
"password": "<Das Passwort des Users>"
}
</pre>

====== plenticore_auth_* Erläuterung ======
Die folgenden beiden Skripte sind ein Extrakt aus den bisherigen Skripten, ohne die HTTP Aufrufe. Sie dienen nur noch der Generierung von Authentifizierungsschlüsseln. Optimaler Weise müssten sie auch noch nach Perl konvertiert werden, was für später geplant ist.
Als Übergabeparameter werden aus dem PV_Anlage_1_API Gerät Rückgabewerte der HTTP Aufrufe verwendet.

====== plenticore_auth_finish ======
fhem@raspberrypi:~/python/bin$ cat plenticore_auth_finish.py
<syntaxhighlight lang="Python">
import string
import base64
import hashlib
import hmac
from Crypto.Cipher import AES
import binascii

import sys
import json
import fhem

web = sys.argv[1]
randomString = sys.argv[2]
nonce = sys.argv[3]
salt = sys.argv[4]
rounds = sys.argv[5]

try:
with open('/opt/fhem/python/pwd_plenticore.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

PASSWD = credentials["password"]

u = randomString

#u = base64.b64encode(u.encode('utf-8')).decode('utf-8')
#print("randomString: ",u)

i = nonce
o = int(rounds)
a = salt
bitSalt = base64.b64decode(a)

#print("nonce : ",i)
#print("salt : ",a)
#print("rounds : ",o)

def getPBKDF2Hash(password, bytedSalt, rounds):
return hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), bytedSalt, rounds)

r = getPBKDF2Hash(PASSWD,bitSalt,o)
s = hmac.new(r, "Client Key".encode('utf-8'), hashlib.sha256).digest()
c = hmac.new(r, "Server Key".encode('utf-8'), hashlib.sha256).digest()
_ = hashlib.sha256(s).digest()
d = "n=user,r="+u+",r="+i+",s="+a+",i="+str(o)+",c=biws,r="+i
g = hmac.new(_, d.encode('utf-8'), hashlib.sha256).digest()
p = hmac.new(c, d.encode('utf-8'), hashlib.sha256).digest()
f = bytes(a ^ b for (a, b) in zip(s, g))
proof = base64.b64encode(f).decode('utf-8')

try:
with open('/opt/fhem/python/pwd_fhem.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

fh = fhem.Fhem(web, protocol="http", port=8083, username=credentials["username"], password=credentials["password"])

fh.send_cmd("setreading PV_Anlage_1_API auth_proof " + proof)

#print("proof : ",proof)
</syntaxhighlight>
====== plenticore_auth_session ======
fhem@raspberrypi:~/python/bin$ cat plenticore_auth_session.py
<syntaxhighlight lang="Python">
import string
import base64
import hashlib
import os
import hmac
from Crypto.Cipher import AES
import binascii

import sys
import json
import fhem

web = sys.argv[1]
randomString = sys.argv[2]
nonce = sys.argv[3]
salt = sys.argv[4]
rounds = sys.argv[5]
token = sys.argv[6]

try:
with open('/opt/fhem/python/pwd_plenticore.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

PASSWD = credentials["password"]

u = randomString
i = nonce
o = int(rounds)
a = salt
bitSalt = base64.b64decode(a)

def getPBKDF2Hash(password, bytedSalt, rounds):
return hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), bytedSalt, rounds)

r = getPBKDF2Hash(PASSWD,bitSalt,o)

#print("randomString: ",u)
#print("nonce : ",i)
#print("salt : ",a)
#print("rounds : ",o)
#print("token : ",token)

s = hmac.new(r, "Client Key".encode('utf-8'), hashlib.sha256).digest()
_ = hashlib.sha256(s).digest()
d = "n=user,r="+u+",r="+i+",s="+a+",i="+str(o)+",c=biws,r="+i

y = hmac.new(_, "Session Key".encode('utf-8'), hashlib.sha256)
y.update(d.encode('utf-8'))
y.update(s)
P = y.digest()
protocol_key = P
t = os.urandom(16)

e2 = AES.new(protocol_key,AES.MODE_GCM,t)
e2, authtag = e2.encrypt_and_digest(token.encode('utf-8'))

iv = base64.b64encode(t).decode('utf-8')
authtag = base64.b64encode(authtag).decode("utf-8")
payload = base64.b64encode(e2).decode('utf-8')

try:
with open('/opt/fhem/python/pwd_fhem.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

fh = fhem.Fhem(web, protocol="http", port=8083, username=credentials["username"], password=credentials["password"])

fh.send_cmd("setreading PV_Anlage_1_API auth_iv " + iv)
fh.send_cmd("setreading PV_Anlage_1_API auth_authtag " + authtag)
fh.send_cmd("setreading PV_Anlage_1_API auth_payload " + payload)

#print("iv : ",iv)
#print("authtag : ",authtag)
#print("payload : ",payload)
</syntaxhighlight>

====== Ablaufbeschreibung PV_Anlage_1_API ======
Hier soll ein kurzer Überblick für den Anmeldeablauf geschaffen werden.
======Automatischer Login mit Sessionaufbau======
Der Ablauf startet mit dem ersten Aufruf und läuft dann vollautomatisch bis zur Rückgabe der auth_sessionId
1. get PV_Anlage_1_API 01/auth/start
* auth_randomString64 - wird generiert
* /api/v1/auth/start - HTTP request erfolgt
* auth_nonce, auth_salt, auth_rounds werden empfangen
2. auth_Step1_Message:auth_nonce.* wird getriggert
* plenticore_auth_finish.py wird ausgeführt
* auth_proof - wird berechnet
3. auth_Step2_Message:auth_proof.* wird getriggert
* Start von 02_/auth/finish
4. get PV_Anlage_1_API 02_/auth/finish
* /api/v1/auth/finish - HTTP request erfolgt
* auth_signature, auth_token werden empfangen
5. auth_Step3_Message:auth_token.* wird getriggert
* plenticore_auth_session.py wird ausgeführt
* auth_iv, auth_authtag, auth_payload - wird berechnet
6. auth_Step4_Message:auth_payload.* wird getriggert
* Start von 03_/auth/session
7. get PV_Anlage_1_API 03_/auth/session
* /api/v1/auth/session - HTTP request erfolgt
* auth_sessionId wird empfangen

Bei allen folgenden HTTP requests wird nun die erhaltene auth_sessenId übermittelt.

Bereits Implementierte Abfragen:

get:

start, finish, create_session werden für den Login benötigt und arbeiten über userreadings mit zwei Python Skripten zusammen

01_/auth/start

02_/auth/finish

03_/auth/create_session

Auskunft über den Anmeldezustand, es muss aber kurz vorher abgefragt werden

04_/auth/me

Informationen zum Plenticore

05_/info/version

Abfrage der Statistiken

20_/processdata/scb_statistic_EnergyFlow

Liste aller Plenticore Module. Es werden keine readings erzeugt. Das Ergebnis steht im httpbody, der mit attr <Device> showBody 1 angezeigt werden kann.

21_/modules_list

Hier gibt es viele technische Loggings. Sollte es Probleme beim Abholen der Daten geben kann es am timeout liegen

24_/logdata/download

Speicher Typen wurden folgende ermittelt 0=keine , 4=BYD

Diese Abfragewerte können auch gesetzt werden, siehe set Befehle

31_Battery_Type

32_Battery_MinHomeComsumption

33_Battery_Strategy

34_Battery_MinSoc

35_Battery_SmartBatteryControl_Enable

36_Battery_DynamicSoc_Enable

Das zeigt den FW Update Status beim FW Laden an. Die Rückmeldung ist im httpbody zu sehen, es werden keine readings erzeugt.

41_/update/status

set:

Eine bestehende Session wird abgemeldet

06_/auth/logout

Die letzten Events können in deutsch oder englisch abgeholt werden

23_/events/latest_5 [en-gb,de-de]

Batterie Einstellungen können verändert werden. Es werden einige Werte vorgeschlagen. Bitte vorher immer den aktuellen Wert abfragen und besser aufschreiben!

Hier sollte nur etwas gesetzt werden, wenn man sich sicher ist, was man tut.

31_Battery_Type [0,4]

32_Battery_MinHomeComsumption

33_Battery_Strategy

34_Battery_MinSoc

35_Battery_SmartBatteryControl_Enable

36_Battery_DynamicSoc_Enable

Der Reboot läuft noch nicht. Da ist die API ziemlich zickig. Ich habe jedoch bereits ein Skript, womit es geht :-)

51_/system/reboot

Sollte die Session abgelaufen, oder noch kein Login vollzogen worden sein, so wird automatisch eine Login mit Sessionaufbau durchgeführt.

====== RAW Definition des PV_Anlage_1_API ======
<syntaxhighlight lang="Perl">
defmod PV_Anlage_1_API HTTPMOD http://%IP-Address_Plenticore%/api/v1/auth/me 0

attr PV_Anlage_1_API DbLogExclude .*
attr PV_Anlage_1_API DbLogInclude Statistic_Autarky.*,Statistic_Energy.*,Statistic_Own.*,Statistic_Total.*,Statistic_Yield.*,Statistic_PV.*,Statistic_Grid.*
attr PV_Anlage_1_API comment Version 2020.10.23 11:03
attr PV_Anlage_1_API enableControlSet 0
attr PV_Anlage_1_API enableCookies 1
attr PV_Anlage_1_API get01Data {"nonce": "%randomString64%","username": "user"}
attr PV_Anlage_1_API get01Name 01_/auth/start
attr PV_Anlage_1_API get01URL http://%IP-Address_Plenticore%/api/v1/auth/start
attr PV_Anlage_1_API get02-1Name auth_signature
attr PV_Anlage_1_API get02-2Name auth_token
attr PV_Anlage_1_API get02Data {"transactionId": "%auth_transactionId%", "proof": "%auth_proof%"}
attr PV_Anlage_1_API get02JSON .
attr PV_Anlage_1_API get02Name 02_/auth/finish
attr PV_Anlage_1_API get02URL http://%IP-Address_Plenticore%/api/v1/auth/finish
attr PV_Anlage_1_API get03Data {"transactionId": "%auth_transactionId%", "iv": "%auth_iv%", "tag": "%auth_authtag%", "payload": "%auth_payload%"}
attr PV_Anlage_1_API get03Name 03_/auth/create_session
attr PV_Anlage_1_API get03URL http://%IP-Address_Plenticore%/api/v1/auth/create_session
attr PV_Anlage_1_API get04-1Name auth_me_active
attr PV_Anlage_1_API get04-2Name auth_me_locked
attr PV_Anlage_1_API get04-3Name auth_me_authenticated
attr PV_Anlage_1_API get04-4Name auth_me_anonymous
attr PV_Anlage_1_API get04-5Name auth_me_role
attr PV_Anlage_1_API get04-6Name auth_me_permissions
attr PV_Anlage_1_API get04Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get04JSON .
attr PV_Anlage_1_API get04Name 04_/auth/me
attr PV_Anlage_1_API get04URL http://%IP-Address_Plenticore%/api/v1/auth/me
attr PV_Anlage_1_API get05-1Name info_name
attr PV_Anlage_1_API get05-2Name info_api_version
attr PV_Anlage_1_API get05-3Name info_sw_version
attr PV_Anlage_1_API get05-4Name info_hostname
attr PV_Anlage_1_API get05JSON .
attr PV_Anlage_1_API get05Name 05_/info/version
attr PV_Anlage_1_API get05URL http://%IP-Address_Plenticore%/api/v1/info/version
attr PV_Anlage_1_API get20-10Name Statistic_EnergyHome_Month
attr PV_Anlage_1_API get20-11Name Statistic_EnergyHome_Total
attr PV_Anlage_1_API get20-12Name Statistic_EnergyHome_Year
attr PV_Anlage_1_API get20-13Name Statistic_EnergyHomeBat_Day
attr PV_Anlage_1_API get20-14Name Statistic_EnergyHomeBat_Month
attr PV_Anlage_1_API get20-15Name Statistic_EnergyHomeBat_Total
attr PV_Anlage_1_API get20-16Name Statistic_EnergyHomeBat_Year
attr PV_Anlage_1_API get20-17Name Statistic_EnergyHomeGrid_Day
attr PV_Anlage_1_API get20-18Name Statistic_EnergyHomeGrid_Month
attr PV_Anlage_1_API get20-19Name Statistic_EnergyHomeGrid_Total
attr PV_Anlage_1_API get20-1Name Statistic_Autarky_Day
attr PV_Anlage_1_API get20-20Name Statistic_EnergyHomeGrid_Year
attr PV_Anlage_1_API get20-21Name Statistic_EnergyHomePv_Day
attr PV_Anlage_1_API get20-22Name Statistic_EnergyHomePv_Month
attr PV_Anlage_1_API get20-23Name Statistic_EnergyHomePv_Total
attr PV_Anlage_1_API get20-24Name Statistic_EnergyHomePv_Year
attr PV_Anlage_1_API get20-25Name Statistic_OwnConsumptionRate_Day
attr PV_Anlage_1_API get20-26Name Statistic_OwnConsumptionRate_Month
attr PV_Anlage_1_API get20-27Name Statistic_OwnConsumptionRate_Total
attr PV_Anlage_1_API get20-28Name Statistic_OwnConsumptionRate_Year
attr PV_Anlage_1_API get20-29Name Statistic_Yield_Day
attr PV_Anlage_1_API get20-2Name Statistic_Autarky_Month
attr PV_Anlage_1_API get20-30Name Statistic_Yield_Month
attr PV_Anlage_1_API get20-31Name Statistic_Yield_Total
attr PV_Anlage_1_API get20-32Name Statistic_Yield_Year
attr PV_Anlage_1_API get20-3Name Statistic_Autarky_Total
attr PV_Anlage_1_API get20-4Name Statistic_Autarky_Year
attr PV_Anlage_1_API get20-5Name Statistic_CO2Saving_Day
attr PV_Anlage_1_API get20-6Name Statistic_CO2Saving_Month
attr PV_Anlage_1_API get20-7Name Statistic_CO2Saving_Total
attr PV_Anlage_1_API get20-8Name Statistic_CO2Saving_Year
attr PV_Anlage_1_API get20-9Name Statistic_EnergyHome_Day
attr PV_Anlage_1_API get20Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get20JSON 01_processdata_.._value
attr PV_Anlage_1_API get20Name 20_/processdata/scb_statistic_EnergyFlow
attr PV_Anlage_1_API get20URL http://%IP-Address_Plenticore%/api/v1/processdata/scb:statistic:EnergyFlow
attr PV_Anlage_1_API get21Name 21_/modules_list
attr PV_Anlage_1_API get21URL http://%IP-Address_Plenticore%/api/v1/modules
attr PV_Anlage_1_API get24Data {"end":"%end_date%","begin":"%begin_date%"}
attr PV_Anlage_1_API get24Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get24Header02 Content-type: application/json, Accept: application/json, Connection: keep-alive
attr PV_Anlage_1_API get24Name 24_/logdata/download
attr PV_Anlage_1_API get24URL http://%IP-Address_Plenticore%/api/v1/logdata/download
attr PV_Anlage_1_API get31-1Name Battery_Type
attr PV_Anlage_1_API get31-2Name Battery_Type
attr PV_Anlage_1_API get31Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get31Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get31JSON .
attr PV_Anlage_1_API get31Name 31_Battery_Type
attr PV_Anlage_1_API get31URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:Type
attr PV_Anlage_1_API get32-1Name Battery_MinHomeComsumption
attr PV_Anlage_1_API get32-2Name Battery_MinHomeComsumption
attr PV_Anlage_1_API get32Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get32Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get32JSON .
attr PV_Anlage_1_API get32Name 32_Battery_MinHomeComsumption
attr PV_Anlage_1_API get32URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:MinHomeComsumption
attr PV_Anlage_1_API get33-1Name Battery_Strategy
attr PV_Anlage_1_API get33-2Name Battery_Strategy
attr PV_Anlage_1_API get33Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get33Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get33JSON .
attr PV_Anlage_1_API get33Name 33_Battery_Strategy
attr PV_Anlage_1_API get33URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:Strategy
attr PV_Anlage_1_API get34-1Name Battery_MinSoc
attr PV_Anlage_1_API get34-2Name Battery_MinSoc
attr PV_Anlage_1_API get34Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get34Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get34JSON .
attr PV_Anlage_1_API get34Name 34_Battery_MinSoc
attr PV_Anlage_1_API get34URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:MinSoc
attr PV_Anlage_1_API get35-1Name Battery_SmartBatteryControl_Enable
attr PV_Anlage_1_API get35-2Name Battery_SmartBatteryControl_Enable
attr PV_Anlage_1_API get35Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get35Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get35JSON .
attr PV_Anlage_1_API get35Name 35_Battery_SmartBatteryControl_Enable
attr PV_Anlage_1_API get35URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:SmartBatteryControl:Enable
attr PV_Anlage_1_API get36-1Name Battery_DynamicSoc_Enable
attr PV_Anlage_1_API get36-2Name Battery_DynamicSoc_Enable
attr PV_Anlage_1_API get36Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get36Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get36JSON .
attr PV_Anlage_1_API get36Name 36_Battery_DynamicSoc_Enable
attr PV_Anlage_1_API get36URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:DynamicSoc:Enable
attr PV_Anlage_1_API get41Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get41Name 41_/update/status
attr PV_Anlage_1_API get41URL http://%IP-Address_Plenticore%/api/v1/update/status
attr PV_Anlage_1_API getHeader01 Accept-Encoding: gzip,deflate
attr PV_Anlage_1_API getHeader02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API group PV Eigenverbrauch
attr PV_Anlage_1_API icon sani_solar
attr PV_Anlage_1_API reading01-1Name auth_nonce
attr PV_Anlage_1_API reading01-2Name auth_rounds
attr PV_Anlage_1_API reading01-3Name auth_salt
attr PV_Anlage_1_API reading01-4Name auth_transactionId
attr PV_Anlage_1_API reading01JSON .
attr PV_Anlage_1_API reading02JSON sessionId
attr PV_Anlage_1_API reading02Name auth_sessionId
attr PV_Anlage_1_API reading0301JSON message
attr PV_Anlage_1_API reading0301Name info_message
attr PV_Anlage_1_API reading0302JSON error
attr PV_Anlage_1_API reading0302Name info_error
attr PV_Anlage_1_API replacement01Mode expression
attr PV_Anlage_1_API replacement01Regex %IP-Address_Plenticore%
attr PV_Anlage_1_API replacement01Value {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")}
attr PV_Anlage_1_API replacement02Mode reading
attr PV_Anlage_1_API replacement02Regex %auth_transactionId%
attr PV_Anlage_1_API replacement02Value auth_transactionId
attr PV_Anlage_1_API replacement03Mode reading
attr PV_Anlage_1_API replacement03Regex %auth_proof%
attr PV_Anlage_1_API replacement03Value auth_proof
attr PV_Anlage_1_API replacement04Mode expression
attr PV_Anlage_1_API replacement04Regex %randomString64%
attr PV_Anlage_1_API replacement04Value {my $NAME = "PV_Anlage_1_API" ;;;;fhem("deletereading ".$NAME." message");;;;fhem("deletereading ".$NAME." auth.*");;;;my @chars=('a'..'z','A'..'Z','0'..'9');; my $r;; foreach(1..16) {$r.=$chars[rand @chars];;};;;; fhem("setreading ".$NAME." auth_randomString64 ".$r);;;; $r;;;;}
attr PV_Anlage_1_API replacement05Mode reading
attr PV_Anlage_1_API replacement05Regex %auth_randomString64%
attr PV_Anlage_1_API replacement05Value auth_randomString64
attr PV_Anlage_1_API replacement06Mode reading
attr PV_Anlage_1_API replacement06Regex %auth_token%
attr PV_Anlage_1_API replacement06Value auth_token
attr PV_Anlage_1_API replacement07Mode reading
attr PV_Anlage_1_API replacement07Regex %auth_signature%
attr PV_Anlage_1_API replacement07Value auth_signature
attr PV_Anlage_1_API replacement08Mode reading
attr PV_Anlage_1_API replacement08Regex %auth_authtag%
attr PV_Anlage_1_API replacement08Value auth_authtag
attr PV_Anlage_1_API replacement09Mode reading
attr PV_Anlage_1_API replacement09Regex %auth_payload%
attr PV_Anlage_1_API replacement09Value auth_payload
attr PV_Anlage_1_API replacement10Mode reading
attr PV_Anlage_1_API replacement10Regex %auth_iv%
attr PV_Anlage_1_API replacement10Value auth_iv
attr PV_Anlage_1_API replacement11Mode reading
attr PV_Anlage_1_API replacement11Regex %auth_sessionId%
attr PV_Anlage_1_API replacement11Value auth_sessionId
attr PV_Anlage_1_API replacement12Mode expression
attr PV_Anlage_1_API replacement12Regex %begin_date%
attr PV_Anlage_1_API replacement12Value {POSIX::strftime("%Y-%m-%d",localtime(time))}
attr PV_Anlage_1_API replacement13Mode expression
attr PV_Anlage_1_API replacement13Regex %end_date%
attr PV_Anlage_1_API replacement13Value {POSIX::strftime("%Y-%m-%d",localtime(time))}
attr PV_Anlage_1_API room Strom->Energie,Strom->Photovoltaik
attr PV_Anlage_1_API set06Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set06Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set06Method POST
attr PV_Anlage_1_API set06Name 06_/auth/logout
attr PV_Anlage_1_API set06NoArg 1
attr PV_Anlage_1_API set06URL http://%IP-Address_Plenticore%/api/v1/auth/logout
attr PV_Anlage_1_API set23-10Name Event_02_code
attr PV_Anlage_1_API set23-11Name Event_02_description
attr PV_Anlage_1_API set23-12Name Event_02_end_time
attr PV_Anlage_1_API set23-13Name Event_02_group
attr PV_Anlage_1_API set23-14Name Event_02_is_active
attr PV_Anlage_1_API set23-15Name Event_02_long_description
attr PV_Anlage_1_API set23-16Name Event_02_start_time
attr PV_Anlage_1_API set23-17Name Event_03_category
attr PV_Anlage_1_API set23-18Name Event_03_code
attr PV_Anlage_1_API set23-19Name Event_03_description
attr PV_Anlage_1_API set23-1Name Event_01_category
attr PV_Anlage_1_API set23-20Name Event_03_end_time
attr PV_Anlage_1_API set23-21Name Event_03_group
attr PV_Anlage_1_API set23-22Name Event_03_is_active
attr PV_Anlage_1_API set23-23Name Event_03_long_description
attr PV_Anlage_1_API set23-24Name Event_03_start_time
attr PV_Anlage_1_API set23-25Name Event_04_category
attr PV_Anlage_1_API set23-26Name Event_04_code
attr PV_Anlage_1_API set23-27Name Event_04_description
attr PV_Anlage_1_API set23-28Name Event_04_end_time
attr PV_Anlage_1_API set23-29Name Event_04_group
attr PV_Anlage_1_API set23-2Name Event_01_code
attr PV_Anlage_1_API set23-30Name Event_04_is_active
attr PV_Anlage_1_API set23-31Name Event_04_long_description
attr PV_Anlage_1_API set23-32Name Event_04_start_time
attr PV_Anlage_1_API set23-33Name Event_05_category
attr PV_Anlage_1_API set23-34Name Event_05_code
attr PV_Anlage_1_API set23-35Name Event_05_description
attr PV_Anlage_1_API set23-36Name Event_05_end_time
attr PV_Anlage_1_API set23-37Name Event_05_group
attr PV_Anlage_1_API set23-38Name Event_05_is_active
attr PV_Anlage_1_API set23-39Name Event_05_long_description
attr PV_Anlage_1_API set23-3Name Event_01_description
attr PV_Anlage_1_API set23-40Name Event_05_start_time
attr PV_Anlage_1_API set23-4Name Event_01_end_time
attr PV_Anlage_1_API set23-5Name Event_01_group
attr PV_Anlage_1_API set23-6Name Event_01_is_active
attr PV_Anlage_1_API set23-7Name Event_01_long_description
attr PV_Anlage_1_API set23-8Name Event_01_start_time
attr PV_Anlage_1_API set23-9Name Event_02_category
attr PV_Anlage_1_API set23Data {"max":5,"language":"$val"}
attr PV_Anlage_1_API set23Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set23Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set23Hint en-gb,de-de
attr PV_Anlage_1_API set23JSON .
attr PV_Anlage_1_API set23Name 23_/events/latest_5
attr PV_Anlage_1_API set23ParseResponse 1
attr PV_Anlage_1_API set23TextArg 1
attr PV_Anlage_1_API set23URL http://%IP-Address_Plenticore%/api/v1/events/latest
attr PV_Anlage_1_API set31Data [{"moduleid":"devices:local","settings":[{"id":"Battery:Type","value":"$val"}]}]
attr PV_Anlage_1_API set31Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set31Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set31Hint 0,4
attr PV_Anlage_1_API set31Method PUT
attr PV_Anlage_1_API set31Name 31_Battery_Type
attr PV_Anlage_1_API set31URL http://%IP-Address_Plenticore%/api/v1/settings
attr PV_Anlage_1_API set33Data [{"moduleid":"devices:local","settings":[{"id":"Battery:Strategy","value":"$val"}]}]
attr PV_Anlage_1_API set33Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set33Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set33Hint 1,2
attr PV_Anlage_1_API set33Method PUT
attr PV_Anlage_1_API set33Name 31_Battery_Strategy
attr PV_Anlage_1_API set33URL http://%IP-Address_Plenticore%/api/v1/settings
attr PV_Anlage_1_API set34Data [{"moduleid":"devices:local","settings":[{"id":"Battery:MinSoc","value":"$val"}]}]
attr PV_Anlage_1_API set34Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set34Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set34Hint slider,10,5,100
attr PV_Anlage_1_API set34Method PUT
attr PV_Anlage_1_API set34Name 34_Battery_MinSoc
attr PV_Anlage_1_API set34URL http://%IP-Address_Plenticore%/api/v1/settings
attr PV_Anlage_1_API set35Data [{"moduleid":"devices:local","settings":[{"id":"Battery:SmartBatteryControl:Enable","value":"$val"}]}]
attr PV_Anlage_1_API set35Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set35Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set35Hint 0,1
attr PV_Anlage_1_API set35Method PUT
attr PV_Anlage_1_API set35Name 35_SmartBatteryControl_Enable
attr PV_Anlage_1_API set35URL http://%IP-Address_Plenticore%/api/v1/settings
attr PV_Anlage_1_API set51Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set51Header02 Accept: application/json, Connection: keep-alive, Content-type: application/json
attr PV_Anlage_1_API set51Method Post
attr PV_Anlage_1_API set51Name 51_/system/reboot
attr PV_Anlage_1_API set51NoArg 1
attr PV_Anlage_1_API set51URL http://%IP-Address_Plenticore%/api/v1/system/reboot
attr PV_Anlage_1_API showBody 1
attr PV_Anlage_1_API showError 1
attr PV_Anlage_1_API sortby 02
attr PV_Anlage_1_API stateFormat {\
my $calcVal=0;;\
\
my $pvt = sprintf("%04d W",ReadingsVal("PV_Anlage_1","Total_AC_active_power","") );;\
my $pvtd = sprintf("%05.2f kWh",ReadingsVal("$name","Statistic_Yield_Day", "")/1000 );;\
my $pvtm = sprintf("%06.2f kWh",ReadingsVal("$name","Statistic_Yield_Month", "")/1000 );;\
my $pvty = sprintf("%08.2f kWh",ReadingsVal("$name","Statistic_Yield_Year", "")/1000 );;\
\
my $pv = sprintf("%04d W",ReadingsVal("PV_Anlage_1","Home_own_consumption_from_battery", "")+ReadingsVal("PV_Anlage_1","Home_own_consumption_from_PV", "") );;\
my $pvd = sprintf("%05.2f kWh",ReadingsVal("$name","Statistic_EnergyHomePvSum_Day", "")/1000 );;\
my $pvm = sprintf("%06.2f kWh",ReadingsVal("$name","Statistic_EnergyHomePvSum_Month", "")/1000 );;\
my $pvy = sprintf("%08.2f kWh",ReadingsVal("$name","Statistic_EnergyHomePvSum_Year", "")/1000 );;\
\
my $gfi = sprintf("%04d W",(ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0)<=0 ? abs(round(ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0),0)): 0) );;\
my $gfid = sprintf("%05.2f kWh",ReadingsVal("$name","Statistic_EnergyFeedInGrid_Day", "")/1000 );;\
my $gfim = sprintf("%06.2f kWh",ReadingsVal("$name","Statistic_EnergyFeedInGrid_Month", "")/1000 );;\
my $gfiy = sprintf("%08.2f kWh",ReadingsVal("$name","Statistic_EnergyFeedInGrid_Year", "")/1000 );;\
\
my $eb = sprintf("%04d W",(ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0)>=0 ? round(ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0),0) : 0) );;\
my $ebd = sprintf("%05.2f kWh",ReadingsVal("$name","Statistic_EnergyHomeGrid_Day", "")/1000 );;\
my $ebm = sprintf("%06.2f kWh",ReadingsVal("$name","Statistic_EnergyHomeGrid_Month", "")/1000 );;\
my $eby = sprintf("%08.2f kWh",ReadingsVal("$name","Statistic_EnergyHomeGrid_Year", "")/1000 );;\
\
my $et = sprintf("%04d W",(ReadingsVal("PV_Anlage_1","Home_own_consumption_from_PV","")+ReadingsVal("PV_Anlage_1","Home_own_consumption_from_battery","")+ReadingsVal("PV_Anlage_1","Home_own_consumption_from_grid","")) );;\
my $etd = sprintf("%05.2f kWh",ReadingsVal("$name","Statistic_TotalConsumption_Day", "")/1000 );;\
my $etm = sprintf("%06.2f kWh",ReadingsVal("$name","Statistic_TotalConsumption_Month", "")/1000 );;\
my $ety = sprintf("%08.2f kWh",ReadingsVal("$name","Statistic_TotalConsumption_Year", "")/1000 );;\
\
my $valA = ReadingsVal("PV_Anlage_1", "Total_AC_active_power","")-ReadingsVal("PV_Anlage_1", "Home_own_consumption_from_grid","");;\
$calcVal = ($valA > 0) ? round($valA /($valA + ReadingsVal("PV_Anlage_1", "Home_own_consumption_from_grid",""))*100 ,0) : 0;;\
my $aq = sprintf("%3.0f %%",(($calcVal > 100) ? 100 : $calcVal) );;\
\
my $aqd = sprintf("%3.0f %%",ReadingsVal("$name","Statistic_Autarky_Day", "") );;\
my $aqm = sprintf("%3.0f %%",ReadingsVal("$name","Statistic_Autarky_Month", "") );;\
my $aqy = sprintf("%3.0f %%",ReadingsVal("$name","Statistic_Autarky_Year", "") );;\
\
my $valS = ReadingsVal("PV_Anlage_1","Total_AC_active_power", 0);;\
$calcVal = ($valS > 0) ? round((ReadingsVal("PV_Anlage_1","Home_own_consumption_from_PV", "0") + ReadingsVal("PV_Anlage_1","Home_own_consumption_from_battery","0")) / $valS * 100 ,0) : 0;;\
my $sq = sprintf("%3.0f %%",(($calcVal > 100) ? 100 : $calcVal) );;\
\
my $sqd = sprintf("%3.0f %%",ReadingsVal("$name","Statistic_OwnConsumptionRate_Day", "") );;\
my $sqm = sprintf("%3.0f %%",ReadingsVal("$name","Statistic_OwnConsumptionRate_Month", "") );;\
my $sqy = sprintf("%3.0f %%",ReadingsVal("$name","Statistic_OwnConsumptionRate_Year", "") );;\
\
my $md = ReadingsTimestamp("$name", "auth_me_authenticated", "");;\
my $cd = ReadingsTimestamp("$name", "Statistic_Autarky_Day", "");;\
my $cm = ReadingsTimestamp("$name", "Statistic_Autarky_Month", "");;\
my $cy = ReadingsTimestamp("$name", "Statistic_Autarky_Year", "");;\
\
"<html><table border=2 bordercolor='darkgreen' cellspacing=0>\
<tr><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'> </td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>aktueller Wert</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>Heute</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>dieser Monat</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>dieses Jahr</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>PV-Erzeugung-Total</td><td style='padding-right:5px;;padding-left:5px'>".$pvt."</td><td style='padding-right:5px;;padding-left:5px'>".$pvtd."</td><td style='padding-right:5px;;padding-left:5px'>".$pvtm."</td><td style='padding-right:5px;;padding-left:5px'>".$pvty."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>PV-Einspeisung</td><td style='padding-right:5px;;padding-left:5px'>".$gfi."</td><td style='padding-right:5px;;padding-left:5px'>".$gfid."</td><td style='padding-right:5px;;padding-left:5px'>".$gfim."</td><td style='padding-right:5px;;padding-left:5px'>".$gfiy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Netz-Bezug</td><td style='padding-right:5px;;padding-left:5px'>".$eb."</td><td style='padding-right:5px;;padding-left:5px'>".$ebd."</td><td style='padding-right:5px;;padding-left:5px'>".$ebm."</td><td style='padding-right:5px;;padding-left:5px'>".$eby."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>PV-Bezug</td><td style='padding-right:5px;;padding-left:5px'>".$pv."</td><td style='padding-right:5px;;padding-left:5px'>".$pvd."</td><td style='padding-right:5px;;padding-left:5px'>".$pvm."</td><td style='padding-right:5px;;padding-left:5px'>".$pvy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Energieverbrauch</td><td style='padding-right:5px;;padding-left:5px'>".$et."</td><td style='padding-right:5px;;padding-left:5px'>".$etd."</td><td style='padding-right:5px;;padding-left:5px'>".$etm."</td><td style='padding-right:5px;;padding-left:5px'>".$ety."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Autarkiequote</td><td style='padding-right:5px;;padding-left:5px'>".$aq."</td><td style='padding-right:5px;;padding-left:5px'>".$aqd."</td><td style='padding-right:5px;;padding-left:5px'>".$aqm."</td><td style='padding-right:5px;;padding-left:5px'>".$aqy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Eigenverbrauchsquote</td><td style='padding-right:5px;;padding-left:5px'>".$sq."</td><td style='padding-right:5px;;padding-left:5px'>".$sqd."</td><td style='padding-right:5px;;padding-left:5px'>".$sqm."</td><td style='padding-right:5px;;padding-left:5px'>".$sqy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Berechnung am</td><td style='padding-right:5px;;padding-left:5px'>".$md."</td><td style='padding-right:5px;;padding-left:5px'>".$cd."</td><td style='padding-right:5px;;padding-left:5px'>".$cm."</td><td style='padding-right:5px;;padding-left:5px'>".$cy."</td></tr>\
</table></html>"\
}
attr PV_Anlage_1_API timeout 7
attr PV_Anlage_1_API userReadings auth_first_called:auth_randomString64.* {my $first_called = InternalVal("$NAME","path","n.a");;;; $first_called =~ s/:/_/g;;;;$first_called ;;;;$first_called =~ s/\/api\/v1//g;;;; my %replace = ("/auth/me" => "04_/auth/me","/info/version" => "05_/info/version","/processdata/scb_statistic_EnergyFlow" => "20_/processdata/scb_statistic_EnergyFlow","/modules_list" => "21_/modules_list","/logdata/download" => "24_/logdata/download","/update/status" => "41_/update/status","/system/reboot" => "04_/auth/me",);;;; $replace{$first_called};;;;},\
\
auth_Step1_Message:auth_transactionId.* {system("/usr/bin/python3 /opt/fhem/python/bin/plenticore_auth_finish.py ".ReadingsVal("PV_Anlage_1_config","IP-Address_FHEM","")." ".ReadingsVal("$NAME","auth_randomString64","")." ".ReadingsVal("$NAME","auth_nonce","")." ".ReadingsVal("$NAME","auth_salt","")." ".ReadingsVal("$NAME","auth_rounds","29000")." &");;;; "Prepare auth_finish started with auth_nonce ".ReadingsVal("$NAME","auth_nonce","")},\
\
auth_Step2_Message:auth_proof.* { fhem("get ".$NAME." 02_/auth/finish") ;;;; "HTTP Request 02_/auth/finish with auth_proof ".ReadingsVal("$NAME","auth_proof","")},\
\
auth_Step3_Message:auth_token.* {system("/usr/bin/python3 /opt/fhem/python/bin/plenticore_auth_session.py ".ReadingsVal("PV_Anlage_1_config","IP-Address_FHEM","")." ".ReadingsVal("$NAME","auth_randomString64","")." ".ReadingsVal("$NAME","auth_nonce","")." ".ReadingsVal("$NAME","auth_salt","")." ".ReadingsVal("$NAME","auth_rounds","")." ".ReadingsVal("$NAME","auth_token","")." &");;;; "Prepare auth_session started with auth_token ".ReadingsVal("$NAME","auth_token","")},\
\
auth_Step4_Message:auth_payload.* { fhem("get ".$NAME." 03_/auth/create_session") ;;;; "HTTP Request 03_/auth/create_session with auth_authtag ".ReadingsVal("$NAME","auth_authtag","")},\
\
auth_Step5_Message:auth_sessionId.* {my $restack = ReadingsVal("$NAME","auth_first_called","") ;;;; ($restack ne "")?fhem("get ".$NAME." ".$restack):"No further HTTP request";;;;},\
\
\
Statistic_EnergyHomePvSum_Day:Statistic_EnergyHomePv_Day.* {round( (ReadingsVal("$NAME","Statistic_EnergyHomeBat_Day", "0")+ReadingsVal("$NAME","Statistic_EnergyHomePv_Day", "")) ,2)},\
\
Statistic_EnergyHomePvSum_Month:Statistic_EnergyHomePv_Month.* {round( (ReadingsVal("$NAME","Statistic_EnergyHomeBat_Month", "0")+ReadingsVal("$NAME","Statistic_EnergyHomePv_Month", "")) ,2)},\
\
Statistic_EnergyHomePvSum_Year:Statistic_EnergyHomePv_Year.* {round( (ReadingsVal("$NAME","Statistic_EnergyHomeBat_Year", "0")+ReadingsVal("$NAME","Statistic_EnergyHomePv_Year", "")) ,2)},\
\
\
Statistic_EnergyFeedInGrid_Day:Statistic_Yield_Day.* {round((ReadingsVal("$NAME","Statistic_Yield_Day", "")-ReadingsVal("$NAME","Statistic_EnergyHomeBat_Day", "0")-ReadingsVal("$NAME","Statistic_EnergyHomePv_Day", "")),2)},\
\
Statistic_EnergyFeedInGrid_Month:Statistic_Yield_Month.* {round((ReadingsVal("$NAME","Statistic_Yield_Month", "")-ReadingsVal("$NAME","Statistic_EnergyHomeBat_Month", "0")-ReadingsVal("$NAME","Statistic_EnergyHomePv_Month", "")),2)},\
\
Statistic_EnergyFeedInGrid_Year:Statistic_Yield_Year.* {round((ReadingsVal("$NAME","Statistic_Yield_Year", "")-ReadingsVal("$NAME","Statistic_EnergyHomeBat_Year", "0")-ReadingsVal("$NAME","Statistic_EnergyHomePv_Year", "")),2)},\
\
\
Statistic_TotalConsumption_Day:Statistic_EnergyHomePv_Day.* {round( (ReadingsVal("$NAME","Statistic_EnergyHomePv_Day","")+ReadingsVal("$NAME","Statistic_EnergyHomeBat_Day","0")+ReadingsVal("$NAME","Statistic_EnergyHomeGrid_Day","") ) ,2)},\
\
Statistic_TotalConsumption_Month:Statistic_EnergyHomePv_Month.* {round( (ReadingsVal("$NAME","Statistic_EnergyHomePv_Month","")+ReadingsVal("$NAME","Statistic_EnergyHomeBat_Month","0")+ReadingsVal("$NAME","Statistic_EnergyHomeGrid_Month","") ) ,2)},\
\
Statistic_TotalConsumption_Year:Statistic_EnergyHomePv_Year.* {round( (ReadingsVal("$NAME","Statistic_EnergyHomePv_Year","")+ReadingsVal("$NAME","Statistic_EnergyHomeBat_Year","0")+ReadingsVal("$NAME","Statistic_EnergyHomeGrid_Year","") ),2)},\
\
\
Statistic_Yield_NoBat_Day:Statistic_Yield_Day.* {round((ReadingsVal("$NAME","Statistic_Yield_Day", "")-ReadingsVal("$NAME","Statistic_EnergyHomeBat_Day", "0")),2)},\
\
Statistic_Yield_NoBat_Month:Statistic_Yield_Month.* {round((ReadingsVal("$NAME","Statistic_Yield_Month", "")-ReadingsVal("$NAME","Statistic_EnergyHomeBat_Month", "0")),2)},\
\
Statistic_Yield_NoBat_Year:Statistic_Yield_Year.* {round((ReadingsVal("$NAME","Statistic_Yield_Year", "")-ReadingsVal("$NAME","Statistic_EnergyHomeBat_Year", "0")),2)}
attr PV_Anlage_1_API verbose 5
</syntaxhighlight>

=== Kostal Smart Energy Manager (KSEM) (Modbus/TCP) ===
Diese Einbindung ist nicht zwingend notwendig, jedoch weil es möglich ist hier beschrieben.
Das Gerät ist hier mit "disable 1" konfiguriert, um es zu verwenden muss das Attribut auf 0 gesetzt oder einfach gelöscht werden.

Auch hier ist ein Interval von 60 Sekunden gesetzt worden. Das Logging ist noch komplett deaktiviert, weshalb man seine Werte noch selber definieren muss.

==== RAW Definition des KSEM ====
Zun Thema KSEM bestand direkter Kontakt mit dem Kostal Service. Der KSEM ermittelt nicht alle Werte, welche in der SunSpec spezifiziert sind. Alle nicht unterstützen Werte sind in den Registern mit 0x8000 gekennzeichnet. Für die nicht unterstützten Zählerstände wird 0x800000000 ausgegeben.
Der Summenstrom M_AC_Current (sum of active phases) kann aber durch den Endanwender selber aus der Summe der Einzelwerte (Phase A AC current, Phase B AC current Phase C AC current) berechnet werden. Die einzelnen Spannungen zwischen den Phasen können nicht gemessen werden und werden deshalb nicht ausgegeben.
<syntaxhighlight lang="Perl">
defmod PV_KSEM ModbusAttr 1 60 <IP-Address_KSEM>:502 TCP
attr PV_KSEM DbLogExclude .*
attr PV_KSEM alias PV_Energy_Manager
attr PV_KSEM dev-h-defPoll 1
attr PV_KSEM dev-type-INT16-len 1
attr PV_KSEM dev-type-INT16-unpack s>
attr PV_KSEM dev-type-INT16_Current-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Current_SF",0))
attr PV_KSEM dev-type-INT16_Current-format %.2f
attr PV_KSEM dev-type-INT16_Current-len 1
attr PV_KSEM dev-type-INT16_Current-unpack s>
attr PV_KSEM dev-type-INT16_Freq-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Freq_SF",0))
attr PV_KSEM dev-type-INT16_Freq-format %.2f
attr PV_KSEM dev-type-INT16_Freq-len 1
attr PV_KSEM dev-type-INT16_Freq-unpack s>
attr PV_KSEM dev-type-INT16_PF-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_PF_SF",0))
attr PV_KSEM dev-type-INT16_PF-format %.2f
attr PV_KSEM dev-type-INT16_PF-len 1
attr PV_KSEM dev-type-INT16_PF-unpack s>
attr PV_KSEM dev-type-INT16_Power-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Power_SF",0))
attr PV_KSEM dev-type-INT16_Power-format %.2f
attr PV_KSEM dev-type-INT16_Power-len 1
attr PV_KSEM dev-type-INT16_Power-unpack s>
attr PV_KSEM dev-type-INT16_VA-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_VA_SF",0))
attr PV_KSEM dev-type-INT16_VA-format %.2f
attr PV_KSEM dev-type-INT16_VA-len 1
attr PV_KSEM dev-type-INT16_VA-unpack s>
attr PV_KSEM dev-type-INT16_VAR-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_VAR_SF",0))
attr PV_KSEM dev-type-INT16_VAR-format %.2f
attr PV_KSEM dev-type-INT16_VAR-len 1
attr PV_KSEM dev-type-INT16_VAR-unpack s>
attr PV_KSEM dev-type-INT16_Voltage-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Voltage_SF",0))
attr PV_KSEM dev-type-INT16_Voltage-format %.2f
attr PV_KSEM dev-type-INT16_Voltage-len 1
attr PV_KSEM dev-type-INT16_Voltage-unpack s>
attr PV_KSEM dev-type-STR32-expr $val =~ s/[\00]+//gr
attr PV_KSEM dev-type-STR32-format %s
attr PV_KSEM dev-type-STR32-len 16
attr PV_KSEM dev-type-STR32-unpack a*
attr PV_KSEM dev-type-UINT16-format %s
attr PV_KSEM dev-type-UINT16-len 1
attr PV_KSEM dev-type-UINT32-format %s
attr PV_KSEM dev-type-UINT32-len 2
attr PV_KSEM dev-type-UINT64-expr $val/10000
attr PV_KSEM dev-type-UINT64-format %s
attr PV_KSEM dev-type-UINT64-len 4
attr PV_KSEM dev-type-UINT64-unpack Q>
attr PV_KSEM disable 1
attr PV_KSEM group PV Eigenverbrauch
attr PV_KSEM icon measure_power
attr PV_KSEM obj-h40072-reading M_AC_Current_A
attr PV_KSEM obj-h40072-type INT16_Current
attr PV_KSEM obj-h40073-reading M_AC_Current_B
attr PV_KSEM obj-h40073-type INT16_Current
attr PV_KSEM obj-h40074-reading M_AC_Current_C
attr PV_KSEM obj-h40074-type INT16_Current
attr PV_KSEM obj-h40075-reading M_AC_Current_SF
attr PV_KSEM obj-h40075-type INT16
attr PV_KSEM obj-h40077-reading M_AC_Voltage_AN
attr PV_KSEM obj-h40077-type INT16_Voltage
attr PV_KSEM obj-h40078-reading M_AC_Voltage_BN
attr PV_KSEM obj-h40078-type INT16_Voltage
attr PV_KSEM obj-h40079-reading M_AC_Voltage_CN
attr PV_KSEM obj-h40079-type INT16_Voltage
attr PV_KSEM obj-h40084-reading M_AC_Voltage_SF
attr PV_KSEM obj-h40084-type INT16
attr PV_KSEM obj-h40085-reading M_AC_Freq
attr PV_KSEM obj-h40085-type INT16_Freq
attr PV_KSEM obj-h40086-reading M_AC_Freq_SF
attr PV_KSEM obj-h40086-type INT16
attr PV_KSEM obj-h40087-reading M_AC_Power
attr PV_KSEM obj-h40087-type INT16_Power
attr PV_KSEM obj-h40088-reading M_AC_Power_A
attr PV_KSEM obj-h40088-type INT16_Power
attr PV_KSEM obj-h40089-reading M_AC_Power_B
attr PV_KSEM obj-h40089-type INT16_Power
attr PV_KSEM obj-h40090-reading M_AC_Power_C
attr PV_KSEM obj-h40090-type INT16_Power
attr PV_KSEM obj-h40091-reading M_AC_Power_SF
attr PV_KSEM obj-h40091-type INT16
attr PV_KSEM obj-h40092-reading M_AC_VA
attr PV_KSEM obj-h40092-type INT16_VA
attr PV_KSEM obj-h40093-reading M_AC_VA_A
attr PV_KSEM obj-h40093-type INT16_VA
attr PV_KSEM obj-h40094-reading M_AC_VA_B
attr PV_KSEM obj-h40094-type INT16_VA
attr PV_KSEM obj-h40095-reading M_AC_VA_C
attr PV_KSEM obj-h40095-type INT16_VA
attr PV_KSEM obj-h40096-reading M_AC_VA_SF
attr PV_KSEM obj-h40096-type INT16
attr PV_KSEM obj-h40097-reading M_AC_VAR
attr PV_KSEM obj-h40097-type INT16_VAR
attr PV_KSEM obj-h40098-reading M_AC_VAR_A
attr PV_KSEM obj-h40098-type INT16_VAR
attr PV_KSEM obj-h40099-reading M_AC_VAR_B
attr PV_KSEM obj-h40099-type INT16_VAR
attr PV_KSEM obj-h40100-reading M_AC_VAR_C
attr PV_KSEM obj-h40100-type INT16_VAR
attr PV_KSEM obj-h40101-reading M_AC_VAR_SF
attr PV_KSEM obj-h40101-type INT16
attr PV_KSEM obj-h40102-reading M_AC_PF
attr PV_KSEM obj-h40102-type INT16_PF
attr PV_KSEM obj-h40103-reading M_AC_PF_A
attr PV_KSEM obj-h40103-type INT16_PF
attr PV_KSEM obj-h40104-reading M_AC_PF_B
attr PV_KSEM obj-h40104-type INT16_PF
attr PV_KSEM obj-h40105-reading M_AC_PF_C
attr PV_KSEM obj-h40105-type INT16_PF
attr PV_KSEM obj-h40106-reading M_AC_PF_SF
attr PV_KSEM obj-h40106-type INT16
attr PV_KSEM obj-h40108-reading M_Exported
attr PV_KSEM obj-h40108-type UINT32
attr PV_KSEM obj-h40110-reading M_Exported_A
attr PV_KSEM obj-h40110-type UINT32
attr PV_KSEM obj-h40112-reading M_Exported_B
attr PV_KSEM obj-h40112-type UINT32
attr PV_KSEM obj-h40114-reading M_Exported_C
attr PV_KSEM obj-h40114-type UINT32
attr PV_KSEM obj-h40116-reading M_Imported
attr PV_KSEM obj-h40116-type UINT32
attr PV_KSEM obj-h40118-reading M_Imported_A
attr PV_KSEM obj-h40118-type UINT32
attr PV_KSEM obj-h40120-reading M_Imported_B
attr PV_KSEM obj-h40120-type UINT32
attr PV_KSEM obj-h40122-reading M_Imported_C
attr PV_KSEM obj-h40122-type UINT32
attr PV_KSEM obj-h40125-reading M_Exported_VA
attr PV_KSEM obj-h40125-type UINT32
attr PV_KSEM obj-h40127-reading M_Exported_VA_A
attr PV_KSEM obj-h40127-type UINT32
attr PV_KSEM obj-h40129-reading M_Exported_VA_B
attr PV_KSEM obj-h40129-type UINT32
attr PV_KSEM obj-h40131-reading M_Exported_VA_C
attr PV_KSEM obj-h40131-type UINT32
attr PV_KSEM obj-h40133-reading M_Imported_VA
attr PV_KSEM obj-h40133-type UINT32
attr PV_KSEM obj-h40135-reading M_Imported_VA_A
attr PV_KSEM obj-h40135-type UINT32
attr PV_KSEM obj-h40137-reading M_Imported_VA_B
attr PV_KSEM obj-h40137-type UINT32
attr PV_KSEM obj-h40139-reading M_Imported_VA_C
attr PV_KSEM obj-h40139-type UINT32
attr PV_KSEM obj-h512-reading Active_energy+
attr PV_KSEM obj-h512-type UINT64
attr PV_KSEM obj-h516-reading Active_energy-
attr PV_KSEM obj-h516-type UINT64
attr PV_KSEM obj-h8192-reading ManufacturerID
attr PV_KSEM obj-h8192-type UINT16
attr PV_KSEM obj-h8193-reading ProductID
attr PV_KSEM obj-h8193-type UINT16
attr PV_KSEM obj-h8194-reading ProductVersion
attr PV_KSEM obj-h8194-type UINT16
attr PV_KSEM obj-h8195-reading FirmwareVersion
attr PV_KSEM obj-h8195-type UINT16
attr PV_KSEM obj-h8196-reading VendorName
attr PV_KSEM obj-h8196-type STR32
attr PV_KSEM obj-h8212-reading Productname
attr PV_KSEM obj-h8212-type STR32
attr PV_KSEM obj-h8228-reading SerialNumber
attr PV_KSEM obj-h8228-type STR32
attr PV_KSEM obj-h8244-reading MeasuringInterval
attr PV_KSEM obj-h8244-type UINT16
attr PV_KSEM room Strom->Photovoltaik
attr PV_KSEM sortby 05
attr PV_KSEM userReadings M_AC_Current:M_AC_Current_.* { ReadingsVal($NAME,"M_AC_Current_A",0) + ReadingsVal($NAME,"M_AC_Current_B",0) + ReadingsVal($NAME,"M_AC_Current_C",0) }
attr PV_KSEM verbose 0
</syntaxhighlight>

=== BYD Speicher (mit HTTPMOD) ===
Diese Einbindung ist nicht zwingend notwendig.
Das Passwort steht momentan noch im userreading.
Durch einen Test von einem anderen Mitstreiter hat sich herausgestellt, dass BYD nun die neue Version des Speichers BYD_HVS ausliefert. Dieser neue Speicher hat anscheinend noch kein WebGui und wird nur über eine Handy App Konfiguriert. Leider kann man den somit nicht mit dieser Lösung abfragen.
Diese Speicher wird über das HTTPMOD Modul angesprochen, ist jedoch noch nicht bis in die letzten Tiefen abfragbar.
Der Begriff "Array" bezeichnet einen Speicher mit mehreren Modulen, die mit dem Series_Battery_Counts angegeben werden.
Eine Battery hat dabei ca. 1.28 KW

Folge Besonderheiten bestehen noch bei dieser Implementierung:
- Die Digest Key Erstellung erfolgt über userreading, die entsprechend der Reihenfolge getriggert werden.
- Ein Login erfolgt nicht mit sid Definitionen
- Um eine erstmalige Anmeldung durchzuführen, oder auch zwischendurch mal ein neues Login zu machen, löscht man die "auth_.*" readings.
<pre>
deletereading BYD_Status auth_.*
</pre>
- Für die Anmeldung ruft man einfach mehrfach eine get Abfrage auf.
* Beim ersten Aufruf sind die auth_* readings noch nicht vorhanden, oder auch eventuell falsch, wenn sie nicht gelöscht wurden.
* Der zweite Aufruf aktualisiert dann nochmals die Digest Keys
* Mit dem dritten Aufruf sind dann alle Keys ausgetauscht und die Anfrage wird bereits mit den Daten beantwortet
- Für alle weiteren Abfragen besteht dann eine autorisierte Session mit der alle get Anfragen beantwortet werden.
- Die Abfrage von RunData liefert im Standard Fall immer "Array Num 1" mit "Series Battery Num 1". Dies kann leider noch nicht zur
Abfrage der weiteren "Series Battery Num" umgeschaltet werden.
- Achtung, die Abfrage von "StatisticInformation" ruft eine Tabelle mit 500 Ereignissen ab, von denen jedoch nur die aktuellsten 5
als readings verarbeitet werden. Da aber alle 500 gelesen und verarbeitet werden müssen ist eine längere Laufzeit zu beachten.
Aus diesem Grund sollte die "StatisticInformation" nicht in einem kurzen Zyklus erfolgen!
Implementiert sind derzeit:
RunData
InstallationConfig
DeviceInformation
BatteryInformation
StatisticInformation

userreading:
InstallationConfig_Array_Power Gibt die Nennleistung des Arrays aus der Anzahl der einzelnen Batterien an. Es wurde eine Leistung von 1.28 KW pro Batterie als Basis angenommen
==== RAW Definition BYD_Status ====
<syntaxhighlight lang="Perl">
attr BYD_Status DbLogExclude .*
attr BYD_Status devStateIcon 100:measure_battery_100 \d:measure_battery_0 1\d.*:measure_battery_25 2\d.*:measure_battery_25 3\d.*:measure_battery_25 4\d.*:measure_battery_50 5\d.*:measure_battery_50 6\d.*:measure_battery_50 7\d.*:measure_battery_75 8\d.*:measure_battery_75 9\d.*:measure_battery_100
attr BYD_Status enableControlSet 0
attr BYD_Status enableCookies 1
attr BYD_Status get01-101Name Array_Series_Battery_CellVol_02
attr BYD_Status get01-106Name Array_Series_Battery_CellVol_03
attr BYD_Status get01-111Name Array_Series_Battery_CellVol_04
attr BYD_Status get01-116Name Array_Series_Battery_CellVol_05
attr BYD_Status get01-11Name Array_Main_PackVoltage
attr BYD_Status get01-121Name Array_Series_Battery_CellVol_06
attr BYD_Status get01-126Name Array_Series_Battery_CellVol_07
attr BYD_Status get01-131Name Array_Series_Battery_CellVol_08
attr BYD_Status get01-136Name Array_Series_Battery_CellVol_09
attr BYD_Status get01-141Name Array_Series_Battery_CellVol_10
attr BYD_Status get01-146Name Array_Series_Battery_CellVol_11
attr BYD_Status get01-151Name Array_Series_Battery_CellVol_12
attr BYD_Status get01-156Name Array_Series_Battery_CellVol_13
attr BYD_Status get01-161Name Array_Series_Battery_CellVol_14
attr BYD_Status get01-166Name Array_Series_Battery_CellVol_15
attr BYD_Status get01-16Name Array_Main_Current
attr BYD_Status get01-171Name Array_Series_Battery_CellVol_16
attr BYD_Status get01-176Name Array_Series_Battery_CellVolMax
attr BYD_Status get01-181Name Array_Series_Battery_CellVolMin
attr BYD_Status get01-186Name Array_Series_Battery_CellTemp_1
attr BYD_Status get01-191Name Array_Series_Battery_CellTemp_2
attr BYD_Status get01-196Name Array_Series_Battery_CellTemp_3
attr BYD_Status get01-201Name Array_Series_Battery_CellTemp_4
attr BYD_Status get01-22Name Array_Main_SOC
attr BYD_Status get01-26Name Array_Main_SysTemp
attr BYD_Status get01-31Name Array_Main_MaxCellVol
attr BYD_Status get01-36Name Array_Main_MinCellVol
attr BYD_Status get01-41Name Array_Main_MaxCellTemp
attr BYD_Status get01-46Name Array_Main_MinCellTemp
attr BYD_Status get01-53Name Array_Main_MaxVolPos
attr BYD_Status get01-56Name Array_Series_Battery_SerialNumber
attr BYD_Status get01-58Name Array_Main_MinVolPos
attr BYD_Status get01-5Name Array_Main_ArrayNum
attr BYD_Status get01-63Name Array_Main_MaxTempPos
attr BYD_Status get01-68Name Array_Main_MinTempPos
attr BYD_Status get01-6Name Array_Main_ArrayVoltage
attr BYD_Status get01-73Name Array_Main_Power
attr BYD_Status get01-80Name Array_Series_Battery
attr BYD_Status get01-84Name Array_Series_Battery_SerialNumber
attr BYD_Status get01-86Name Array_Series_Battery_BattVol
attr BYD_Status get01-91Name Array_Series_Battery_CellVolDiff
attr BYD_Status get01-96Name Array_Series_Battery_CellVol_01
attr BYD_Status get01MaxAge 900
attr BYD_Status get01MaxAgeReplacementMode delete
attr BYD_Status get01Name RunData
attr BYD_Status get01RegOpt g
attr BYD_Status get01Regex value=([+|-]{0,1}\d+.\d+)>|value=(\d+.\d+)%>|value=(\d)>|value=(.*-\d+\s+.*\d)>|selected="selected">(\d)<
attr BYD_Status get01URL http://%IP-Address_BYD%/asp/RunData.asp
attr BYD_Status get02-101Name Statistic_SpecificInformation_03_StartTime
attr BYD_Status get02-105Name Statistic_SpecificInformation_03_EndTime
attr BYD_Status get02-10Name Statistic_SpecificInformation_02_Type
attr BYD_Status get02-113Name Statistic_SpecificInformation_04_Type
attr BYD_Status get02-117Name Statistic_SpecificInformation_04_Ah
attr BYD_Status get02-11Name Statistic_SpecificInformation_02_Ah
attr BYD_Status get02-121Name Statistic_SpecificInformation_04_KWh
attr BYD_Status get02-125Name Statistic_SpecificInformation_04_EnvTemp
attr BYD_Status get02-129Name Statistic_SpecificInformation_04_BatTemp
attr BYD_Status get02-12Name Statistic_GeneralInformation_Total_Cycle_Counts
attr BYD_Status get02-133Name Statistic_SpecificInformation_04_StartTime
attr BYD_Status get02-137Name Statistic_SpecificInformation_04_EndTime
attr BYD_Status get02-13Name Statistic_SpecificInformation_02_EnvTemp
attr BYD_Status get02-145Name Statistic_SpecificInformation_05_Type
attr BYD_Status get02-149Name Statistic_SpecificInformation_05_Ah
attr BYD_Status get02-14Name Statistic_SpecificInformation_02_BatTemp
attr BYD_Status get02-153Name Statistic_SpecificInformation_05_KWh
attr BYD_Status get02-157Name Statistic_SpecificInformation_05_EnvTemp
attr BYD_Status get02-15Name Statistic_SpecificInformation_02_StartTime
attr BYD_Status get02-161Name Statistic_SpecificInformation_05_BatTemp
attr BYD_Status get02-165Name Statistic_SpecificInformation_05_StartTime
attr BYD_Status get02-169Name Statistic_SpecificInformation_05_EndTime
attr BYD_Status get02-16Name Statistic_SpecificInformation_02_EndTime
attr BYD_Status get02-17Name Statistic_SpecificInformation_01_Type
attr BYD_Status get02-18Name Statistic_SpecificInformation_03_Type
attr BYD_Status get02-19Name Statistic_SpecificInformation_03_Ah
attr BYD_Status get02-20Name Statistic_SpecificInformation_03_KWh
attr BYD_Status get02-21Name Statistic_SpecificInformation_01_Ah
attr BYD_Status get02-22Name Statistic_SpecificInformation_03_BatTemp
attr BYD_Status get02-23Name Statistic_SpecificInformation_03_StartTime
attr BYD_Status get02-24Name Statistic_SpecificInformation_03_EndTime
attr BYD_Status get02-25Name Statistic_SpecificInformation_01_KWh
attr BYD_Status get02-26Name Statistic_SpecificInformation_04_Type
attr BYD_Status get02-27Name Statistic_SpecificInformation_04_Ah
attr BYD_Status get02-28Name Statistic_SpecificInformation_04_KWh
attr BYD_Status get02-29Name Statistic_SpecificInformation_01_EnvTemp
attr BYD_Status get02-2Name Statistic_GeneralInformation_Total_Charge_Energy
attr BYD_Status get02-30Name Statistic_SpecificInformation_04_BatTemp
attr BYD_Status get02-31Name Statistic_SpecificInformation_04_StartTime
attr BYD_Status get02-32Name Statistic_SpecificInformation_04_EndTime
attr BYD_Status get02-33Name Statistic_SpecificInformation_01_BatTemp
attr BYD_Status get02-34Name Statistic_SpecificInformation_05_Type
attr BYD_Status get02-35Name Statistic_SpecificInformation_05_Ah
attr BYD_Status get02-36Name Statistic_SpecificInformation_05_KWh
attr BYD_Status get02-37Name Statistic_SpecificInformation_01_StartTime
attr BYD_Status get02-38Name Statistic_SpecificInformation_05_BatTemp
attr BYD_Status get02-39Name Statistic_SpecificInformation_05_StartTime
attr BYD_Status get02-3Name Statistic_SpecificInformation_01_Ah
attr BYD_Status get02-40Name Statistic_SpecificInformation_05_EndTime
attr BYD_Status get02-41Name Statistic_SpecificInformation_01_EndTime
attr BYD_Status get02-49Name Statistic_SpecificInformation_02_Type
attr BYD_Status get02-4Name Statistic_SpecificInformation_01_KWh
attr BYD_Status get02-53Name Statistic_SpecificInformation_02_Ah
attr BYD_Status get02-57Name Statistic_SpecificInformation_02_KWh
attr BYD_Status get02-5Name Statistic_SpecificInformation_01_EnvTemp
attr BYD_Status get02-61Name Statistic_SpecificInformation_02_EnvTemp
attr BYD_Status get02-65Name Statistic_SpecificInformation_02_BatTemp
attr BYD_Status get02-69Name Statistic_SpecificInformation_02_StartTime
attr BYD_Status get02-6Name Statistic_SpecificInformation_01_BatTemp
attr BYD_Status get02-73Name Statistic_SpecificInformation_02_EndTime
attr BYD_Status get02-7Name Statistic_GeneralInformation_Total_Discharge_Energy
attr BYD_Status get02-81Name Statistic_SpecificInformation_03_Type
attr BYD_Status get02-85Name Statistic_SpecificInformation_03_Ah
attr BYD_Status get02-89Name Statistic_SpecificInformation_03_KWh
attr BYD_Status get02-8Name Statistic_SpecificInformation_01_EndTime
attr BYD_Status get02-93Name Statistic_SpecificInformation_03_EnvTemp
attr BYD_Status get02-97Name Statistic_SpecificInformation_03_BatTemp
attr BYD_Status get02MaxAge 900
attr BYD_Status get02MaxAgeReplacementMode delete
attr BYD_Status get02Name StatisticInformation
attr BYD_Status get02RegOpt g
attr BYD_Status get02Regex <td class="text_l">(.*)<\/td>\n|Charge Energy:<\/td>\n.*>(\d+.\d+)|Discharge Energy:<\/td>\n.*>(\d+.\d+)|Cycle Counts:<\/td>\n.*>(\d+)
attr BYD_Status get02URL http://%IP-Address_BYD%/asp/StatisticInformation.asp
attr BYD_Status get03-10Name DeviceInformation_Machine_Version
attr BYD_Status get03-10OExpr {$val =~ s/\n//g;; $val}
attr BYD_Status get03-15Name DeviceInformation_Board_SN
attr BYD_Status get03-1Name DeviceInformation_Machine_SN
attr BYD_Status get03-20Name DeviceInformation_Board_Factory_time
attr BYD_Status get03-8Name DeviceInformation_Machine_Factory_time
attr BYD_Status get03Name DeviceInformation
attr BYD_Status get03RegOpt g
attr BYD_Status get03Regex >(\d{9}-\d{5})<|Version:<\/td>\n<td>(V\d.\d{3}\n [A-Z])<|>SN:<\/td>\n.*>([\d|\w]{18})<|(\d{4}-\d+-\d+ \d+:\d+:\d+)
attr BYD_Status get03URL http://%IP-Address_BYD%/asp/DeviceInformation.asp
attr BYD_Status get04-13Name BatteryInformation_SOC
attr BYD_Status get04-17Name BatteryInformation_SysTemp
attr BYD_Status get04-1Name BatteryInformation_TotalVoltage
attr BYD_Status get04-21Name BatteryInformation_MaxCellVol
attr BYD_Status get04-25Name BatteryInformation_MinCellVol
attr BYD_Status get04-29Name BatteryInformation_MaxCellTemp
attr BYD_Status get04-33Name BatteryInformation_MinCellTemp
attr BYD_Status get04-37Name BatteryInformation_Power
attr BYD_Status get04-42Name BatteryInformation_System_state
attr BYD_Status get04-47Name BatteryInformation_Date_and_Time
attr BYD_Status get04-52Name BatteryInformation_Alarm_state
attr BYD_Status get04-5Name BatteryInformation_PackVoltage
attr BYD_Status get04-9Name BatteryInformation_Current
attr BYD_Status get04MaxAge 900
attr BYD_Status get04MaxAgeReplacementMode delete
attr BYD_Status get04Name BatteryInformation
attr BYD_Status get04RegOpt g
attr BYD_Status get04Regex value=([+|-]{0,1}\d+.\d+)[%]{0,1}>|value=([A-Z]+)>|value="(\d{4}-\d+-\d+ \d+:\d+:\d+)"|Alarm state:<\/h3><\/td>\n<td>.*">(\w+\W)<\/font>
attr BYD_Status get04URL http://%IP-Address_BYD%/asp/Home.asp
attr BYD_Status get05-1Name InstallationConfig_Array_Counts
attr BYD_Status get05-5Name InstallationConfig_Series_Battery_Counts
attr BYD_Status get05-9Name InstallationConfig_Installation_Time
attr BYD_Status get05Name InstallationConfig
attr BYD_Status get05RegOpt g
attr BYD_Status get05Regex >Array Counts :<\/td>\n<td class="text_l">(\d){1}<|>Series Battery Counts :<\/td>\n<td class="text_l">(\d){1}<|>Installation Time :<\/td>\n<td class="text_l">(\d{4}-\d+-\d+ \d+:\d+:\d+)<
attr BYD_Status get05URL http://%IP-Address_BYD%/asp/UserInfo.asp
attr BYD_Status getHeader01 Authorization: Digest username="installer", realm="%auth_realm%", nonce="%auth_nonce%", uri="/asp/RunData.asp%", algorithm=MD5, response="%auth_response%", opaque="%auth_opaque%", qop="auth", nc=%auth_nc%, cnonce="%auth_cnonce%"
attr BYD_Status group PV Eigenverbrauch
attr BYD_Status httpVersion 1.1
attr BYD_Status icon measure_battery_100
attr BYD_Status reAuthRegex Unauthorized
attr BYD_Status reading01Name auth_qop
attr BYD_Status reading01Regex qop="(.*)", nonce
attr BYD_Status reading02Name auth_nonce
attr BYD_Status reading02Regex nonce="(.*)", opaque
attr BYD_Status reading03Name auth_opaque
attr BYD_Status reading03Regex opaque="(.*)",algorithm
attr BYD_Status reading04Name auth_realm
attr BYD_Status reading04Regex realm="(.*)", domain
attr BYD_Status replacement01Mode expression
attr BYD_Status replacement01Regex %IP-Address_BYD%
attr BYD_Status replacement01Value ReadingsVal("PV_Anlage_1_config","IP-Address_BYD","")
attr BYD_Status replacement03Mode reading
attr BYD_Status replacement03Regex %auth_realm%
attr BYD_Status replacement03Value auth_realm
attr BYD_Status replacement04Mode reading
attr BYD_Status replacement04Regex %auth_nonce%
attr BYD_Status replacement04Value auth_nonce
attr BYD_Status replacement05Mode reading
attr BYD_Status replacement05Regex %auth_response%
attr BYD_Status replacement05Value auth_response
attr BYD_Status replacement06Mode reading
attr BYD_Status replacement06Regex %auth_opaque%
attr BYD_Status replacement06Value auth_opaque
attr BYD_Status replacement07Mode reading
attr BYD_Status replacement07Regex %auth_nc%
attr BYD_Status replacement07Value auth_nc
attr BYD_Status replacement08Mode reading
attr BYD_Status replacement08Regex %auth_cnonce%
attr BYD_Status replacement08Value auth_cnonce
attr BYD_Status room Strom->Photovoltaik
attr BYD_Status showBody 0
attr BYD_Status showError 0
attr BYD_Status sortby 03
attr BYD_Status stateFormat {round(ReadingsVal("BYD_Status","BatteryInformation_SOC",0),0)}
attr BYD_Status userReadings auth_first_called:auth_nonce.* {my $first_called = InternalVal("$NAME","path","n.a");;;; $first_called =~ s/:/_/g;;;; $first_called =~ s/\/api\/v1//g;;;; $first_called},\
auth_HA1:auth_first_called.* {md5_hex("installer:".ReadingsVal($NAME,"auth_realm","").":<Passwort>")},\
auth_HA2:auth_HA1.* {md5_hex("GET:/asp/RunData.asp")},\
auth_response:auth_HA2.* {md5_hex(ReadingsVal($NAME,"auth_HA1","").":".ReadingsVal($NAME,"auth_nonce","").":".ReadingsVal($NAME,"auth_nc","").":".ReadingsVal($NAME,"auth_cnonce","").":".ReadingsVal($NAME,"auth_qop","").":".ReadingsVal($NAME,"auth_HA2",""))},\
auth_nc:auth_nonce.* {"00000001"},\
auth_cnonce:auth_response.* {"d789ea5b7e9a2377"},\
auth_Step1_Message:auth_nonce.* {"HTTP nonce updated"},\
Specific_Information_00_Date:Statistic_SpecificInformation_05_EndTime.* { fhem("deletereading ".$NAME." StatisticInformation.*");;;; localtime()}\
## auth_Step2_Message:auth_Step1_Message.* { fhem("get ".$NAME." RunData") ;;;; "HTTP Request RunData called" },\
\
InstallationConfig_Array_Power:InstallationConfig_Series_Battery_Counts.* {1.28 * ReadingsVal($NAME,"InstallationConfig_Series_Battery_Counts",0)}

attr BYD_Status verbose 0
</syntaxhighlight>

== Timeing für die PV extra Funktionen ==
=== RAW Definition PV_Schedule (DOIF) ===
<syntaxhighlight lang="Perl">
defmod PV_Schedule DOIF ################################################################################################################\
## 1 BYD Status aktualisieren\
##\
([+:06] and !([:00] or [:30]))\
(\
get BYD_Status BatteryInformation\
)\
################################################################################################################\
## 2 Plenticore Status aktualisieren. Dies geschieht über das PV_Anlage_1_API Device\
##\
DOELSEIF\
([:57])\
(\
get PV_Anlage_1_API 20_/processdata/scb_statistic_EnergyFlow\
)\
################################################################################################################\
## 3 PV Prognose vom aktuellen Tag aktualisieren\
## zwischen 7 und 19 Uhr zur vollen Stunde\
DOELSEIF\
([07:00-20:00] and [:00])\
(\
{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",0)}\
)\
################################################################################################################\
## 4 PV Prognose für den nächsten Tag aktualisieren\
## \
DOELSEIF\
([06:55] or [19:11])\
(\
{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",1)}\
)\
################################################################################################################\
## 5 regelmäßig die Bilanz aktualisieren\
##\
DOELSEIF\
([+:05] and ![:00]) ## alle 5 Minuten außer um :00\
(\
get PV_Anlage_1_API 04_/auth/me\
)
attr PV_Schedule DbLogExclude .*
attr PV_Schedule alias PV_Schedule
attr PV_Schedule cmdState BYD Status|Plenticore Status
attr PV_Schedule comment Version 2020.10.23 17:00
attr PV_Schedule do always
attr PV_Schedule room Strom->Photovoltaik,Strom->System
attr PV_Schedule sortby 11
attr PV_Schedule verbose 3
attr PV_Schedule wait 0:0:0:0:0
attr PV_Schedule webCmd cmd_1:cmd_2:cmd_3:cmd_4:cmd_5
attr PV_Schedule webCmdLabel BYD_Status :Statistic_Update :Forecast_0 :Forecast_1 :Bilanz_Actual :
</syntaxhighlight>

== Energie Bilanz ==
[[Bild:Plenticore Bilanz.png|mini|900px|rechts|]]
<big>Achtung, es gab eine Umstellung mit diesem Device! Die Bilanz wird nun direkt im PV_Anlage_1_API Device als stateFormat angezeigt. Bitte holt diese Änderung mit den Informationen im Forum Thread nach.</big>

Die Energie Bilanz soll einen kompakten Überblick über die Produktions und Verbrauchswerte Liefern. Hierbei werden die Momentanwerte direkt berechnet, die restlichen Werte werden als Statistiken aus dem Gerät abgefragt.
=== Erstellen von zusätzlichen Werten in der Datenbank ===
[[Bild:SVG LogDB PV Bilanz.png|mini|900px|rechts|Die Definition diese Diagramms ist weiter unten beschrieben.]]
Hier werden Werte konsolidiert, weil z.B. der Wert PV_total_Month stetig steigt. Am Ende des Monats sind die gesamten Zwischenwerte ohne Aussagekraft und werden dann später mal gelöscht.

==== RAW Definition LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week ====
Dieser Wert ist der gesamte Verbrauch aus der PV Anlage inklusive Batterie pro Woche an.
Gestartet über DB_Service_Schedule am ersten Tag der Folgewoche.
Benötigt für SVG_LogDB_PV_Bilanz.
<syntaxhighlight lang="Perl">
defmod LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week DbRep LogDB
attr LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week DbLogExclude .*
attr LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week aggregation week
attr LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week allowDeletion 0
attr LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week comment Version 2020.10.23 15:00\
Dieser Wert ist der gesamte Verbrauch aus der PV Anlage inklusive Batterie pro Woche an.\
Gestartet über DB_Service_Schedule am ersten Tag der Folgewoche.\
Benötigt für SVG_LogDB_PV_Bilanz.
attr LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week device PV_Anlage_1_API
attr LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week diffAccept 7000
attr LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week reading Statistic_EnergyHomePvSum_Year
attr LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week readingNameMap Statistic_EnergyHomePvSum_Week
attr LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week room Strom->Energie,System
attr LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week timestamp_begin current_year_begin
attr LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week timestamp_end previous_week_end
</syntaxhighlight>

==== RAW Definition LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month ====
Dieser Wert ist der gesamte Verbrauch aus der PV Anlage inklusive Batterie im Monat.
Gestartet über DB_Service_Schedule am ersten des Monats.
Benötigt für SVG_LogDB_PV_Bilanz.
<syntaxhighlight lang="Perl">
defmod LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month DbRep LogDB
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month DbLogExclude .*
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month aggregation month
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month allowDeletion 0
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month comment Version 2020.10.23 15:00\
Dieser Wert ist der gesamte Verbrauch aus der PV Anlage inklusive Batterie im Monat.\
Gestartet über DB_Service_Schedule am ersten des Monats\
Benötigt für SVG_LogDB_PV_Bilanz.
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month device PV_Anlage_1_API
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month reading Statistic_EnergyHomePvSum_Month
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month room Strom->Energie,System
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month timestamp_begin current_year_begin
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month timestamp_end previous_month_end
</syntaxhighlight>

==== RAW Definition LogDBRep_Statistic_Yield_Year_diff_Week ====
Dieser Wert gibt den gesamten Ertrag der PV Anlage pro Woche an.\
Gestartet über DB_Service_Schedule am ersten Tag der Folgewoche.\
Benötigt für SVG_LogDB_PV_Bilanz.
<syntaxhighlight lang="Perl">
defmod LogDBRep_Statistic_Yield_Year_diff_Week DbRep LogDB
attr LogDBRep_Statistic_Yield_Year_diff_Week DbLogExclude .*
attr LogDBRep_Statistic_Yield_Year_diff_Week aggregation week
attr LogDBRep_Statistic_Yield_Year_diff_Week allowDeletion 0
attr LogDBRep_Statistic_Yield_Year_diff_Week comment Version 2020.10.23 15:00\
Dieser Wert gibt den gesamten Ertrag der PV Anlage pro Woche an.\
Gestartet über DB_Service_Schedule am ersten Tag der Folgewoche.\
Benötigt für SVG_LogDB_PV_Bilanz.
attr LogDBRep_Statistic_Yield_Year_diff_Week device PV_Anlage_1_API
attr LogDBRep_Statistic_Yield_Year_diff_Week diffAccept 20000
attr LogDBRep_Statistic_Yield_Year_diff_Week reading Statistic_Yield_Year
attr LogDBRep_Statistic_Yield_Year_diff_Week readingNameMap Statistic_Yield_Week
attr LogDBRep_Statistic_Yield_Year_diff_Week room Strom->Energie,System
attr LogDBRep_Statistic_Yield_Year_diff_Week timestamp_begin current_year_begin
attr LogDBRep_Statistic_Yield_Year_diff_Week timestamp_end previous_week_end
</syntaxhighlight>

==== RAW Definition LogDBRep_Statistic_Yield_Month_max_Month ====
Dieser Wert gibt den gesamten Ertrag der PV Anlage im Monat an.\
Gestartet über DB_Service_Schedule am ersten Tag der Folgewoche.\
Momentan noch in keinem SVC verwendet.
<syntaxhighlight lang="Perl">
defmod LogDBRep_Statistic_Yield_Month_max_Month DbRep LogDB
attr LogDBRep_Statistic_Yield_Month_max_Month DbLogExclude .*
attr LogDBRep_Statistic_Yield_Month_max_Month aggregation month
attr LogDBRep_Statistic_Yield_Month_max_Month allowDeletion 0
attr LogDBRep_Statistic_Yield_Month_max_Month comment Version 2020.10.23 15:00\
Dieser Wert gibt den gesamten Ertrag der PV Anlage im Monat an.\
Gestartet über DB_Service_Schedule am ersten Tag der Folgewoche.\
Momentan noch in keinem SVC verwendet.
attr LogDBRep_Statistic_Yield_Month_max_Month device PV_Anlage_1_API
attr LogDBRep_Statistic_Yield_Month_max_Month diffAccept 20000
attr LogDBRep_Statistic_Yield_Month_max_Month reading Statistic_Yield_Month
attr LogDBRep_Statistic_Yield_Month_max_Month room Strom->Energie,System
attr LogDBRep_Statistic_Yield_Month_max_Month timestamp_begin current_year_begin
attr LogDBRep_Statistic_Yield_Month_max_Month timestamp_end previous_month_end
</syntaxhighlight>

=== Timing für die Datenbank Einträge ===
Über dieses Scheduling werden in der Datenbank zusätzliche Wochen- und Monatseinträge gesteuert.
==== RAW Definition DB_Service_Schedule ====
Hier werden zusätzlich Werte in der Datenbank erzeugt.
<syntaxhighlight lang="Perl">
defmod DB_Service_Schedule DOIF ## Monatlich Einträge\
([01:13] and ($mday==1))\
(set LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month maxValue writeToDB)\
(set LogDBRep_Statistic_Yield_Month_max_Month maxValue writeToDB)\
## Wöchentliche Einträge\
DOELSEIF\
([01:17] and ($wday==1))\
(set LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week diffValue writeToDB)\
(set LogDBRep_Statistic_Yield_Year_diff_Week diffValue writeToDB)
attr DB_Service_Schedule DbLogExclude .*
attr DB_Service_Schedule comment Version 2020.10.23 17:00\
Hier werden zusätzlich Werte in der Datenbank erzeugt.
attr DB_Service_Schedule do always
attr DB_Service_Schedule room Strom->Energie,System
attr DB_Service_Schedule wait 0,3:0,3
attr DB_Service_Schedule webCmd cmd_1:cmd_2
attr DB_Service_Schedule webCmdLabel monatlich :wöchentlich :
</syntaxhighlight>

=== Löschen von nicht mehr benötigten Werten in der Datenbank ===
Hier wird endgültig aufgeräumt, alte momentan Werte werden gelöscht, wenn sie nach z.B. drei Monaten keine Relevanz mehr haben. Dafür wurden im vorherigen Abschnitt zusätzliche Werte in der Datenbank erzeugt, die in Diagrammen trotzdem noch einen trend erkennen lassen.
Wen eine immer größer werdende Datenbank mit steigenden Antwortzeiten nicht stört, der kann das Aufräumen auch weg lassen. Bei einer späteren Migration führt dies natürlich zu höherem Aufwand und hohen Laufzeiten.
<syntaxhighlight lang="Perl">
</syntaxhighlight>

== Wetter-/Leistungs-Prognose ==
Dies ist ein Thema, dass nicht wirklich gut zu fassen ist und ist eher etwas für Enthusiasten :-), wer schon mal mit Sonne, Wolken und Regen gerechnet hat versteht was ich meine. Dieser Ansatz ist nicht wissenschaftlicher Art und hat auch keinen Anspruch mathematischer Perfektion. Nach reinem Gefühl und mit aus dem Fenster schauen kommt jedoch ein respektables Ergebnis dabei heraus. Viel Vergnügen und Spaß beim mitbasteln ;-)
[[Bild:Plenticore_Forecast_Tagesanfang.png|mini|900px|rechts|Wenn der Tag begonnen hat ist die Prognose vom Vortag bereits im Diagramm. Der Wert Calculation in schwarz ist die aktuelle Korrektur.]]
==== Wetter Forecast Grundlagen ====
<pre>
1.) Astro Device mit dem Namen Astro und der Konfiguration
für den jeweiligen Standort
2.) DbLog Device, um die Daten in die Datenbank zu schreiben
3.) DbRep Device um auch wieder alte Forecasts zu löschen
4.) Das Wetter Device für wunderground wird nicht für den
Forecast benötigt.
</pre>

=== Deutscher Wetter Dienst (DWD) ===
Der DWD liefert über Mosmix kostenlos, stunden aktuelle Prognosedaten woraus für diese Anwendung die Werte Rad1h und TTT bezogen werden. In der Funktion Solar_forecast erfolgt noch eine Verschiebung um eine Stunde und die Umrechnung von Rad1h in Watt/m² .
'''Achtung: nicht alle Stationen liefern auch die Rad1h Daten, was deshalb bitte anhand der readings kontrolliert werden müsste.'''
[[DWD_OpenData|FHEM DWD_OpenData Modul]]
==== RAW Definition DWD_Forecast ====
Erfordert ggf.
<syntaxhighlight lang="Perl">
sudo apt-get install libxml-libxml-perl
</syntaxhighlight>

<syntaxhighlight lang="Perl">
defmod DWD_Forecast DWD_OpenData
attr DWD_Forecast DbLogExclude .*
attr DWD_Forecast forecastDays 1
attr DWD_Forecast forecastProperties Rad1h,TTT,Neff,R600
attr DWD_Forecast forecastResolution 1
attr DWD_Forecast forecastStation P0178
attr DWD_Forecast group PV Eigenverbrauch
attr DWD_Forecast icon weather_rain_fog
attr DWD_Forecast room Informationen->Wetter,Strom->Photovoltaik
attr DWD_Forecast sortby 06
</syntaxhighlight>

=== 99_myUtils.pm Funktionen ===
==== Solar_forecast ====
Achtung, diese Funktion ist noch nicht vollständig ausprogrammiert. Es wurden bereits Übergabeparameter integriert, um z.B. andere Wetterdienste zu berücksichtigen.
Um diese Funktion zu nutzen muss ein Dummy PV_Anlage_1_config vorhanden sein, in dem unter anderem die Modul und Anlagen Ausrichtung konfiguriert wird.
Rückfragen gerne im Forum.
<syntaxhighlight lang="Perl">
###########################################################
# Subroutine to calculate radiation
###########################################################
sub Solar_forecast($$$$$$) {
#
# 2020.10.15 15:37
#
# Mit "attr global verbose 3" erscheinen Logmeldungen
#
my $logdb = $_[0] ;
my $logdbrep = $_[1] ; # Das wird zum Löschen in der LogDB verwendet und muss entsprechend konfiguriert sein.
my $logdevice = $_[2] ;
# Hier könnte man noch andere Wetterdienste berücksichtigen bzw den Device Namen ändern
my $wetter = $_[4] ; if ($wetter ne "DWD_Forecast") {return("$wetter not supported")} ;
my $fc = $_[5] ; # Wieviel Tage in die Zukunft soll es gehen? 0,1,2
my $reading = $_[3].$fc ;

my $timeshift = 1; # Verschiebt die Prognose um eine Stunde
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); $year += 1900; $mon += 1;
my ($Solar_Cloud,$Solar_Rain,$Solar_Temp,$Solar_SolarRadiation,$logentry,$i) = (0) x 6 ;
my ($cloudk,$raink,$tempk,$cloudk_base,$raink_base,$tempk_base) = (0) x 6 ;
my ($Solar_Correction_Cloud,$Solar_Correction_Rain,$Solar_Correction_Temp,$Solar_Plain) = (1) x 4 ;
my (@Solar_,@module_count) = (0,0,0) ;

# Initialisieren des Basis TIMESTAMP für den Forecast
my $timestring = time_str2num($year."-".$mon."-".$mday." 07:00:00") ;
my $timestamp = POSIX::strftime("%Y-%m-%d %H:00:00",localtime($timestring+$fc*24*60*60)) ;

# Bei Forecast zuerst die bisherigen Einträge in der Datenbank für den Tag löschen
fhem "set ".$logdbrep." sqlCmd DELETE FROM history WHERE DEVICE='".$logdevice."' AND READING='".$reading."' AND TIMESTAMP>='".$timestamp."'" ;

# Es werden Stundenwerte von 07:00 bis 19:00 Uhr berechnet
for ($i = 7; $i <= 19; $i++) {
$timestring = time_str2num($year."-".$mon."-".$mday." ".$i.":00:00") ;
$timestamp = POSIX::strftime("%Y-%m-%d %H:00:00",localtime($timestring+$fc*24*60*60)) ;

if ( $wetter eq "DWD_Forecast") {
$Solar_Cloud = ReadingsVal($wetter,"fc".$fc."_".($i+$timeshift)."_Neff" ,0);
$Solar_Rain = ReadingsVal($wetter,"fc".$fc."_".($i+$timeshift)."_R600" ,0);
$Solar_Temp = ReadingsVal($wetter,"fc".$fc."_".($i+$timeshift)."_TTT" ,0)+10;
$Solar_SolarRadiation = ReadingsVal($wetter,"fc".$fc."_".($i+$timeshift)."_Rad1h",0);
$Solar_SolarRadiation = round($Solar_SolarRadiation * 0.277778 ,0);
Log 3, "Solar_SolarRadiation : ".$Solar_SolarRadiation." ".ReadingsVal($wetter,"fc".$fc."_".($i+$timeshift)."_Rad1h",0) ;
};

$cloudk = ReadingsVal($logdevice."_config","forecast_cloudk",0) * -0.01 ;
if ($cloudk ne 0) {
$cloudk_base = ReadingsVal($logdevice."_config","forecast_cloudk_base",0) ;
$Solar_Correction_Cloud = round((1 + ($Solar_Cloud - $cloudk_base) * $cloudk / 100),3) ;
};

$raink = ReadingsVal($logdevice."_config","forecast_raink",0) * -0.01 ;
if ($raink ne 0) {
$raink_base = ReadingsVal($logdevice."_config","forecast_raink_base" ,0) ;
$Solar_Correction_Rain = round((1 + ($Solar_Rain - $raink_base ) * $raink / 100),3) ;
};

$tempk = ReadingsVal($logdevice."_config","forecast_tempk",0) * -0.01 ;
if ($tempk ne 0) {
$tempk_base = ReadingsVal($logdevice."_config","forecast_tempk_base" ,0) ;
$Solar_Correction_Temp = round((1 + ($Solar_Temp - $tempk_base ) * $tempk / 100),3) ;
};

my $Solar_Correction_Faktor = ReadingsVal($logdevice."_config","forecast_factor",1) ;

$logentry = 0 ;
for(my $j=1;$j<4;$j++){
$module_count[$j] = ReadingsVal($logdevice."_config","module_".$j."_count",0) ;
if ($module_count[$j] ne 0) {
$Solar_Plain = round(Solar_plain(ReadingsVal($logdevice."_config","module_".$j."_plain",0) , ReadingsVal($logdevice."_config","module_".$j."_direction",0) , $timestamp),3) ;
Log 3, "plain/direction : ".ReadingsVal($logdevice."_config","module_".$j."_plain",0)."/".ReadingsVal($logdevice."_config","module_".$j."_direction",0)." >>> ".$Solar_Plain ;

$Solar_[$j] = $module_count[$j] * ReadingsVal($logdevice."_config","module_".$j."_power",1)/1000 ;
$Solar_[$j] = $Solar_[$j] * $Solar_Plain ;
$Solar_[$j] = $Solar_[$j] * $Solar_SolarRadiation ;
$Solar_[$j] = $Solar_[$j] * $Solar_Correction_Temp * $Solar_Correction_Cloud * $Solar_Correction_Rain * $Solar_Correction_Faktor ;
$Solar_[$j] = ($Solar_[$j] lt 0)?0:round($Solar_[$j],0) ;

$logentry = $logentry + $Solar_[$j] ;
if ($fc == 0 and $hour == $i) {
Log 3, "Solar_".ReadingsVal($logdevice."_config","module_".$j."_name",0)." : ".$Solar_[$j]." ".$i." Uhr" ;
fhem "setreading ".$logdevice." Solar_".ReadingsVal($logdevice."_config","module_".$j."_name",0)." ".$Solar_[$j] ;
};
};
};

fhem "set ".$logdb." addCacheLine ".$timestamp."|".$logdevice."|addlog|".$reading.": ".$logentry."|".$reading."|".$logentry."|";

if ($fc == 0 and $hour == $i and ($module_count[1] ne 0 or $module_count[2] ne 0 or $module_count[3] ne 0)) {
fhem "setreading ".$logdevice." Solar_SolarRadiation ".$Solar_SolarRadiation ;
fhem "setreading ".$logdevice." Solar_Cloud ".$Solar_Cloud ;
fhem "setreading ".$logdevice." Solar_Rain ".$Solar_Rain ;
fhem "setreading ".$logdevice." Solar_Temp ".$Solar_Temp ;
fhem "setreading ".$logdevice." Solar_Correction_Cloud ".$Solar_Correction_Cloud ;
fhem "setreading ".$logdevice." Solar_Correction_Rain ".$Solar_Correction_Rain ;
fhem "setreading ".$logdevice." Solar_Correction_Temp ".$Solar_Correction_Temp ;
fhem "setreading ".$logdevice." Solar_Calculation ".$logentry ;
} ;

Log 3, "Solar_Plain : ".$Solar_Plain ;
Log 3, "Solar_SolarRadiation : ".$Solar_SolarRadiation ;
Log 3, "Solar_Cloud : ".$Solar_Cloud ;
Log 3, "cloudk : ".$cloudk." ".$cloudk_base ;
Log 3, "Solar_Correction_Cloud : ".$Solar_Correction_Cloud ;
Log 3, "Solar_Rain : ".$Solar_Rain ;
Log 3, "raink : ".$raink." ".$raink_base ;
Log 3, "Solar_Correction_Rain : ".$Solar_Correction_Rain ;
Log 3, "Solar_Temp : ".$Solar_Temp ;
Log 3, "tempk : ".$tempk." ".$tempk_base ;
Log 3, "Solar_Correction_Temp : ".$Solar_Correction_Temp ;
Log 3, $fc." ".$i." ".$Solar_SolarRadiation." ".$logentry ;
} ;
return (0);
};
</syntaxhighlight>

==== Solar_Plain ====
<syntaxhighlight lang="Perl">
sub Solar_plain($$$) {
#
# 2020.10.15 15:37
#
my $rad = 57.296;
my $factor = 0.001;

# read parameter
my $angle = $_[0];
my $orienta = $_[1];
my $time = $_[2];

# get Astro information
my $azimuth = fhem "get Astro text SunAz ".$time ;
my $elevation = fhem "get Astro text SunAlt ".$time ;

# convert in radiant
$elevation = $elevation / $rad;
$angle = $angle / $rad;
my $orientation = ($azimuth - 180 - $orienta) / $rad;

if(cos($orientation) < 0.05 && cos($orientation) > -0.2) {
$orientation = $orientation - 0.2
};
Log 3, "Solar_plain: azimuth = $azimuth, orientation=$orientation, elevation=$elevation, angle=$angle";

# avoid unrealistic values (normally formula should only be used within boundaries of orientation +/- 90 degrees)
if ($elevation <= 0.14) {
Log 3, "Solar_plain: factor = $factor";
return($factor);
};

$factor = sin($angle) /
(sin( $elevation) / cos( $elevation)) *
cos($orientation) +
cos($angle);

# avoid too big values
if ($factor > - 0.05 && $factor < 0.05) {
$factor = 0.05
};
Log 3, "Solar_plain: factor = $factor";
return ($factor);
};
</syntaxhighlight>

=== Astro Device ===
==== RAW Definition Astro ====
<syntaxhighlight lang="Perl">
defmod Astro Astro
attr Astro DbLogExclude .*
attr Astro DbLogInclude SunAlt,SunAz
attr Astro alias Astro
attr Astro event-on-change-reading SunAlt,SunAz,ObsSeason,ObsSeasonN,.*Twilight.*
attr Astro group ASC Environment
attr Astro icon telescope
attr Astro interval 600
attr Astro recomputeAt NewDay,SunRise,SunSet,AstroTwilightEvening,AstroTwilightMorning,CivilTwilightEvening,CivilTwilightMorning,CustomTwilightEvening,CustomTwilightMorning
attr Astro room Informationen->Wetter,Rollos
attr Astro sortby 08
</syntaxhighlight>

==== fhem.cfg Einträge für das Astro Device ====
<syntaxhighlight lang="Perl">
attr global altitude 110
attr global latitude 47.85750
attr global longitude 9.49420
</syntaxhighlight>

=== DbLog Device ===
==== RAW Definition LogDB ====
Achtung, bitte hier beachten, ob bereits eine andere DbLog verwendet wird.
<syntaxhighlight lang="Perl">
defmod LogDB DbLog ./db.conf .*:.*
attr LogDB DbLogExclude .*
attr LogDB DbLogSelectionMode Exclude/Include
attr LogDB DbLogType History
attr LogDB asyncMode 1
attr LogDB bulkInsert 1
attr LogDB disable 0
attr LogDB room System
attr LogDB showproctime 1
attr LogDB verbose 0
</syntaxhighlight>

==== RAW Definition LogDBRep_delete_PV_Forecast ====
Achtung, bitte hier beachten, ob bereits eine andere DbLog verwendet wird.
<syntaxhighlight lang="Perl">
defmod LogDBRep_delete_PV_Forecast DbRep LogDB
attr LogDBRep_delete_PV_Forecast DbLogExclude .*
attr LogDBRep_delete_PV_Forecast allowDeletion 1
attr LogDBRep_delete_PV_Forecast room System
</syntaxhighlight>

==== Solar Forcast Tests ====
Grundlagen hierfür sind:
1.) Astro Device mit dem Namen Astro und der Konfiguration für den Standort (in der fhem.cfg eingetragen)
2.) DbLog Device, um die Daten in die Datenbank zu schreiben
3.) DbRep Device um auch wieder alte Forecasts zu löschen
4.) Die Solar_ Funktionen in der 99_myUtils
5.) Das Wetter Device für wunderground wird nicht für den Forecast benötigt

===== Astro Device Test =====
Bei diesen test wird der jeweilige Winkel des Sonnenstandes zu der gegebene Zeit und der eigenen Standortposition zurückgegeben.
<syntaxhighlight lang="Perl">
get Astro text SunAz "2020-10-10 15:00:00"
get Astro text SunAlt "2020-10-10 15:00:00"
</syntaxhighlight>

===== Solar_plain() Test =====
Diese Funktion kann man folgender Maßen testen.

In der fhem comandline:
<syntaxhighlight lang="Perl">
{Solar_plain(45,20,"2020-10-10 15:00:00")}
</syntaxhighlight>

Hierbei ist 45 die Dachneigung und 20 die Ausrichtung das Dach hätte dem nach also Süd/West Lage
Datum mit Uhrzeit reicht dann stundenweise hochzuzählen.

Im Log kommt dann folgendes
<syntaxhighlight lang="Perl">
2020.10.10 14:40:05.038 3: get Astro text SunAz 2020-10-10 15:00:00 : 210.6
2020.10.10 14:40:05.046 3: get Astro text SunAlt 2020-10-10 15:00:00 : 28.6
2020.10.10 14:40:05.046 3: Solar_plain: azimuth = 210.6, orientation=0.185004188774085, elevation=0.49916224518291, angle=0.785395141022061
2020.10.10 14:40:05.046 3: Factor: 1.98190505984713
</syntaxhighlight>

Sobald der Faktor unsinnig würde, wird von der Funktion 0.001 zurück geliefert. Somit würde die Prognose auf fast null reduziert!
<syntaxhighlight lang="Perl">
{Solar_plain(45,40,"2020-10-11 15:00:00") } => 2.00234055111251
{Solar_plain(45,40,"2020-10-11 16:00:00") } => 2.42298713810404
{Solar_plain(45,40,"2020-10-11 17:00:00") } => 3.20079343955795
{Solar_plain(45,40,"2020-10-11 18:00:00") } => 0.001
{Solar_plain(45,40,"2020-10-11 19:00:00") } => 0.001
</syntaxhighlight>

===== Solar_forecast() Test =====
Ein erster Test für diese Funktion wäre ein manueller Aufruf in der Kommandozeile. Hierbei ist 0 der aktuelle und 1 der nächste Tag.
<syntaxhighlight lang="Perl">
{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",0)}
{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",1)}
</syntaxhighlight>

=== Forecast Basiseinstellung ===
Erste Werte wurden bereits mit dem Gerät PV_Anlage_1_config von einer Ost/Süd/West Anlage mitgeliefert.

Grundlegend muss man als erstes jede Ausrichtung von Modulen definieren.
Steht *_count auf 0 so wird diese Ausrichtung nicht verwendet. Die Nennleistung ergibt sich aus der Anzahl der Module und der Nennleistung pro Modul.
Der Name ist frei wählbar und könnte auf "Garage" oder "Schuppen" lauten.
Die Nennleistung pro Modul wird mit dem reading *_power eingetragen.
Mit *.plain wird der Winkel der Module, bzw die Dachneigung eingetragen.
Das reading *_direction gibt die Orientierung an, wobei -90 exact Ost, 0 Richtung Süden und +90 Richtung Westen bedeutet. Diese Winkel können sehr gut auf der WEB Seite [https://www.sonnenverlauf.de/#/50.1121,8.6834,18/2020.09.06/15:41/1/3 Sonnenverlauf.de] ermittelt werden. Dort kann man bis auf sein Anlage hereinzoomen und die Orientierung entnehmen.

Sind diese Werte für alle Modulgruppen eingetragen, so wird eine Summe der Einzelleistungen ermittelt und im Gerät PV_Anlage_1 als reading "Solar_Calculation" eingetragen.
Die weiteren readings "Solar_*" geben noch weitere Werte an.
<syntaxhighlight lang="Perl">
module_1_count 13
module_1_direction -90
module_1_name East
module_1_plain 40
module_1_power 310
</syntaxhighlight>

=== Berücksichtigung von Temperatur, Bewölkung und Regen ===
Diese Wetterfaktoren haben einen starken Einfluss auf die Leistung, die durch die Module erzeugt wird. Ab hier wird es etwa wie Glaskugellesen, jedoch ist das ergebnis wirklich sehenswert, wenn man sich die Mühe gemacht hat etwas zu experimentieren.
Für alle Faktoren wurde eine Art Heizungskurve verwendet, da keine lineare Abhängigkeit zu erkennen war. Die Implementierung erhebt keinen Wissenschaftlichen Anspruch!

===== Temperatur =====
Je heißer die Module werden, je schlechter wird die Leistungsausbeute. Hierzu findet man in den Modulunterlagen einen Wert, der dies wiederspiegelt.
<syntaxhighlight lang="Perl">
tempk dies ist der Faktor aus den Unterlagen ( bei meinen Modulen 0.39 ) und wird dann mit 39 eingetragen
tempk_base Dieser Wert hebt die "Heizungskurve" an und wird mit 25 angegeben. Das bedeutet, bei einer Temperatur von 25° wird die Nennleistung erreicht.
</syntaxhighlight>

===== Wolken und Regen =====
Aus den DWD Forecast werden Prozent Werte geliefert, die experimentell in der "Heizungskurve" zu einem Faktor berechnet werden, der dann die zu erwartende Leistung reduziert.
Um das möglichst gut hinzubekommen sollte man zuerst nur einen Wert verwenden, was man durch raink oder cloudk auf 0 setzen erreichen kann. Eventuell passen ja auch die bereits
mitgelieferten Werte. Sollte das nicht passen, muss man sich leider doch etwas mit "Heizungskurven" beschäftigen. Es kann die Steilheit der Kurve (cloudk) beeinflusst werden,
oder auch eine Parallelverschiebung (cloudk_base) stattfinden. Wenn die Wolken einen starken einfluss haben sollen wäre cloudk z.B. zu verändern.

=== wunderground ===
Diesen Dienst wird nicht für die Prognose genutzt, jedoch kann man dort private Wetterstationen in seinem näheren Umfeld finden, die die Sonneneinstrahlung und den UV Index messen. Das ist dann als aktueller Wert in den Diagrammen zu sehen und lässt aktuelle Beschattung durch Wolken erkennen. Hier kann man dann auch mehrere Stationen definieren und eventuell mit einem Durchschnitt arbeiten, wenn nicht gerade der Nachbar eine Station hat.
Für diese Abfrage ist keine Registrierung notwendig und man muss auch nicht selber mir einer Station Daten liefern.
Aber bitte, die Abfrage nicht in einem zu kurzen Abstand, also mit hoher Frequenz stellen! Hier wird alle 15 Minuten (900 Sekunden) abgefragt.
=== RAW Definition Wetter_<Wohnort> ===
Ggf. muss UConv vorher noch aktiviert werden:
<syntaxhighlight lang="Perl">
define uconvInit notify global:INITIALIZED {use UConv}
</syntaxhighlight>

<syntaxhighlight lang="Perl">
defmod wetter_<Wohnort> HTTPMOD https://www.wunderground.com/dashboard/pws/<Wohnort_Station> 900

attr wetter_<Wohnort> DbLogExclude .*
attr wetter_<Wohnort> DbLogInclude solarRadiation,solarUV,temperature
attr wetter_<Wohnort> alias wetter_<Wohnort>
attr wetter_<Wohnort> enableControlSet 1
attr wetter_<Wohnort> event-on-change-reading solarRadiation,solarUV,temperature
attr wetter_<Wohnort> group ASC Environment
attr wetter_<Wohnort> icon weather_sunrise
attr wetter_<Wohnort> reading01Name date
attr wetter_<Wohnort> reading01Regex Summary<.*>([[:alpha:]]{1,9} [\d]{1,2}, [\d]{4})<\/strong
attr wetter_<Wohnort> reading02Format %.1f
attr wetter_<Wohnort> reading02Name dewpointTemperature
attr wetter_<Wohnort> reading02OExpr UConv::f2c($val,2)
attr wetter_<Wohnort> reading02Regex DEWPOINT.*>([\d\.]+)<\/span>.*PRECIP RATE
attr wetter_<Wohnort> reading03Name dewpointTemperature_EN
attr wetter_<Wohnort> reading03Regex DEWPOINT.*>([\d\.]+)<\/span>.*PRECIP RATE
attr wetter_<Wohnort> reading04Format %.0f
attr wetter_<Wohnort> reading04Name humidity
attr wetter_<Wohnort> reading04Regex HUMIDITY.*>([\d\.]+)<.*WIND
attr wetter_<Wohnort> reading05Name precip1hrmetric
attr wetter_<Wohnort> reading05Regex PRECIP RATE.*>([\d\.]+)<.*PRECIP TOTAL
attr wetter_<Wohnort> reading06Name preciptodaymetric
attr wetter_<Wohnort> reading06Regex PRECIP TOTAL.*>([\d\.]+)<.*tile-precipitation
attr wetter_<Wohnort> reading07Format %.2f
attr wetter_<Wohnort> reading07Name pressure
attr wetter_<Wohnort> reading07OExpr UConv::inhg2hpa($val,2)
attr wetter_<Wohnort> reading07Regex CURRENT.*>([\d\.]+)<.*tile-pressure
attr wetter_<Wohnort> reading08Format %.2f
attr wetter_<Wohnort> reading08Name pressure_EN
attr wetter_<Wohnort> reading08Regex CURRENT.*>([\d\.]+)<.*tile-pressure
attr wetter_<Wohnort> reading09Name solarRadiation
attr wetter_<Wohnort> reading09Regex SOLAR RADIATION.*CURRENT.*weather__text">([\d\.]+)
attr wetter_<Wohnort> reading10Name solarUV
attr wetter_<Wohnort> reading10Regex CURRENT UV.*>([\d\.]+)<.*UV RISK
attr wetter_<Wohnort> reading11Format %.1f
attr wetter_<Wohnort> reading11Name temperature
attr wetter_<Wohnort> reading11OExpr UConv::f2c($val,2)
attr wetter_<Wohnort> reading11Regex current-temp.*">([- ]*[\d\.]+).*DEWPOINT
attr wetter_<Wohnort> reading12Format %.1f
attr wetter_<Wohnort> reading12Name temperature_EN
attr wetter_<Wohnort> reading12Regex current-temp.*">([- ]*[\d\.]+).*DEWPOINT
attr wetter_<Wohnort> reading13Format %.1f
attr wetter_<Wohnort> reading13Name windChill
attr wetter_<Wohnort> reading13OExpr UConv::f2c($val,2)
attr wetter_<Wohnort> reading13Regex Feels Like.*>([\d\.]+)<.*wind-dial__container
attr wetter_<Wohnort> reading14Format %.1f
attr wetter_<Wohnort> reading14Name windChill_EN
attr wetter_<Wohnort> reading14Regex Feels Like.*>([\d\.]+)<.*wind-dial__container
attr wetter_<Wohnort> reading15Name windDirection
attr wetter_<Wohnort> reading15OExpr UConv::compasspoint2compasspoint($val,"en",1,"de")
attr wetter_<Wohnort> reading15Regex WIND FROM.*>([NESW]+)<.*GUST
attr wetter_<Wohnort> reading16Name windDirection_EN
attr wetter_<Wohnort> reading16Regex WIND FROM.*>([NESW]+)<.*GUST
attr wetter_<Wohnort> reading17Format %.0f
attr wetter_<Wohnort> reading17Name windSpeed
attr wetter_<Wohnort> reading17OExpr UConv::mph2kph($val,1)
attr wetter_<Wohnort> reading17Regex wind-dial__container.*>([\d\.]+)<.*unit-speed
attr wetter_<Wohnort> reading18Name windSpeed_EN
attr wetter_<Wohnort> reading18Regex wind-dial__container.*>([\d\.]+)<.*unit-speed
attr wetter_<Wohnort> reading19Name windGust
attr wetter_<Wohnort> reading19OExpr UConv::mph2kph($val,1)
attr wetter_<Wohnort> reading19Regex GUST.*>([\d\.]+)<.*mph
attr wetter_<Wohnort> reading20Name windGust_EN
attr wetter_<Wohnort> reading20Regex GUST.*>([\d\.]+)<.*mph
attr wetter_<Wohnort> room Informationen->Wetter,Rollos
attr wetter_<Wohnort> sortby 03
attr wetter_<Wohnort> stateFormat T: temperature °C | F: humidity % | W: windSpeed km/h | D: pressure hPa | U: solarUV | R: solarRadiation W/m²
attr wetter_<Wohnort> timeout 5
</syntaxhighlight>

== Diagramme ==
=== RAW Definition Hauptverbraucher ===
[[Bild:Plenticore_Hauptverbraucher.png|mini|600px|rechts|]]
==== SVG_LogDB_Photovoltaik_2 ====
<pre>
defmod SVG_LogDB_Photovoltaik_2 SVG LogDB:SVG_LogDB_Photovoltaik_2:HISTORY
attr SVG_LogDB_Photovoltaik_2 DbLogExclude .*
attr SVG_LogDB_Photovoltaik_2 group PV Eigenverbrauch
attr SVG_LogDB_Photovoltaik_2 plotsize 1400,320
attr SVG_LogDB_Photovoltaik_2 room Strom->Info,Strom->Photovoltaik
attr SVG_LogDB_Photovoltaik_2 sortby 00
</pre>
==== GPLOTFILE SVG_LogDB_Photovoltaik_2.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-03-16 10:23:52
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Hauptverbraucher'
set ytics
set y2tics
set grid
set ylabel "Leistung"
set y2label ""

#LogDB PV_Anlage_1:Total_DC_Power:::$val=abs($val)
#LogDB PV_Anlage_1:Total_PV_Power_reserve::
#LogDB StromZaehler_Heizung:SMAEM1901401955_Saldo_Wirkleistung:::$val=abs($val)
#LogDB shelly02:Power_0::
#LogDB shelly03:Power::

plot "<IN>" using 1:2 axes x1y2 title 'Total_DC' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Total_PV_reserve' ls l2 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Heizung' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Pool' ls l8 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Waschmaschine' ls l3 lw 1 with lines
</pre>
=== RAW Definition Leistungsbezug ===
[[Bild:Plenticore_Leistungsbezug.png|mini|600px|rechts|]]
==== SVG_LogDB_Photovoltaik_3 ====
<pre>
defmod SVG_LogDB_Photovoltaik_3 SVG LogDB:SVG_LogDB_Photovoltaik_3:HISTORY
attr SVG_LogDB_Photovoltaik_3 DbLogExclude .*
attr SVG_LogDB_Photovoltaik_3 group PV Eigenverbrauch
attr SVG_LogDB_Photovoltaik_3 plotsize 1400,320
attr SVG_LogDB_Photovoltaik_3 room Strom->Info,Strom->Photovoltaik
attr SVG_LogDB_Photovoltaik_3 sortby 00
</pre>
==== GPLOTFILE SVG_LogDB_Photovoltaik_3.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-07-22 13:51:57
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Leistungsbezug'
set ytics
set y2tics
set grid
set ylabel "Leistung"
set y2label ""
set yrange [0:9500]
set y2range [0:9500]

#LogDB PV_Anlage_1:Total_DC_Power:::$val=abs($val)
#LogDB PV_Anlage_1:Home_own_consumption_from_PV::
#LogDB PV_Anlage_1:Home_own_consumption_from_battery::
#LogDB PV_Anlage_1:Home_own_consumption_from_grid::
#LogDB PV_Anlage_1:Actual_battery_charge_usable_Power::
#LogDB PV_Anlage_1:Total_DC_Power_Max::
#LogDB PV_Anlage_1:Battery_temperature:::$val=$val*100
#LogDB Heizung:heatSourceIN:::$val=$val*100

plot "<IN>" using 1:2 axes x1y2 title 'Total_DC_Power' ls l1fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'own_PV' ls l2fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Bat_use' ls l0fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Grid_use' ls l5 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Bat_usable' ls l4 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Total_DC_Max' ls l6 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Bat_Temp_Trend' ls l0 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Out_Temp_Trend' ls l2 lw 2 with lines
</pre>
=== RAW Definition PV_Bilanz ===
[[Bild:SVG LogDB PV Bilanz.png|mini|600px|rechts|]]
==== SVG_LogDB_PV_Bilanz ====
<pre>
defmod SVG_LogDB_PV_Bilanz SVG LogDB:SVG_LogDB_PV_Bilanz:HISTORY
attr SVG_LogDB_PV_Bilanz DbLogExclude .*
attr SVG_LogDB_PV_Bilanz alias SVG_LogDB_PV_Bilanz
attr SVG_LogDB_PV_Bilanz comment Version 2020.10.21 11:37
attr SVG_LogDB_PV_Bilanz fixedrange year
attr SVG_LogDB_PV_Bilanz plotsize 1400,320
attr SVG_LogDB_PV_Bilanz room Strom->Energie
</pre>

==== GPLOTFILE SVG_LogDB_PV_Bilanz.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-08-02 09:55:06
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'PV_Bilanz'
set ytics
set y2tics
set grid ytics
set ylabel "KWh"
set y2label "KWh"

#LogDB PV_Anlage_1_API:max_month_Statistic_EnergyHomePvSum_Month:::$val=$val/1000
#LogDB PV_Anlage_1_API:diff_week_Statistic_EnergyHomePvSum_Week:::$val=$val/1000
#LogDB PV_Anlage_1_API:diff_week_Statistic_Yield_Week:::$val=$val/1000

plot "<IN>" using 1:2 axes x1y2 title 'Statistic_EnergyHomePvSum_Month' ls l2fill lw 2 with points,\
"<IN>" using 1:2 axes x1y2 title 'Statistic_EnergyHomePvSum_Week' ls l2fill lw 1 with fsteps,\
"<IN>" using 1:2 axes x1y2 title 'Statistic_Yield_Week' ls l1fill lw 1 with lines
</pre>

==== SVG_LogDB_PV_Netz ====
<pre>
defmod SVG_LogDB_PV_Netz SVG LogDB:SVG_LogDB_PV_Netz:HISTORY
attr SVG_LogDB_PV_Netz DbLogExclude .*
attr SVG_LogDB_PV_Netz alias SVG_LogDB_PV_Netz
attr SVG_LogDB_PV_Netz comment Version 2020.10.21 13:45
attr SVG_LogDB_PV_Netz fixedrange month
attr SVG_LogDB_PV_Netz plotsize 1400,320
attr SVG_LogDB_PV_Netz room Strom->Energie
</pre>

==== GPLOTFILE SVG_LogDB_PV_Netz.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-10-21 13:43:37
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'PV_Netz'
set ytics
set y2tics
set grid ytics
set ylabel "KWh"
set y2label "KWh"

#LogDB PV_Anlage_1_API:Statistic_EnergyFeedInGrid_Day::
#LogDB PV_Anlage_1_API:Statistic_EnergyHomeGrid_Day:::$val=$val*-1

plot "<IN>" using 1:2 axes x1y2 title 'Statistic_EnergyFeedInGrid_Day' ls l1fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Statistic_EnergyHomeGrid_Day' ls l0fill lw 1 with lines
</pre>

=== RAW Definition Forecast / Calculation ===
[[Bild:Plenticore_Forecast.png|mini|600px|rechts|]]
==== SVG_LogDB_Photovoltaik_4 ====
<pre>
defmod SVG_LogDB_Photovoltaik_4 SVG LogDB:SVG_LogDB_Photovoltaik_4:HISTORY
attr SVG_LogDB_Photovoltaik_4 DbLogExclude .*
attr SVG_LogDB_Photovoltaik_4 group PV Eigenverbrauch
attr SVG_LogDB_Photovoltaik_4 plotsize 1400,320
attr SVG_LogDB_Photovoltaik_4 room Strom->Photovoltaik
attr SVG_LogDB_Photovoltaik_4 sortby 00
</pre>
==== GPLOTFILE SVG_LogDB_Photovoltaik_4.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-08-17 08:58:42
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Forecast / Calculation'
set ytics
set y2tics
set grid
set ylabel "Leistung"
set y2label "Leistung"
set yrange [0:10000]
set y2range [0:10000]

#LogDB Astro:SunAlt:::$val=($val>0?$val*50+7000:7000)
#LogDB wetter_wolfskehlen_II:solarRadiation:::$val=($val>0?$val*3+7000:7000)
#LogDB PV_Anlage_1:Solar_SolarRadiation:::$val=($val>0?$val*3+7000:7000)
#LogDB Astro:SunAlt:::$val=7000
#LogDB PV_Anlage_1:Solar_Calculation_fc1::
#LogDB PV_Anlage_1:Power_DC_Sum::
#LogDB PV_Anlage_1:Solar_Calculation::
#LogDB PV_Anlage_1:Solar_East::
#LogDB PV_Anlage_1:Solar_South::
#LogDB PV_Anlage_1:Solar_West::

plot "<IN>" using 1:2 axes x1y2 title 'Sonnenhöhe' ls l7 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SolarRadiation' ls l8 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SolarRadiationPrognose' ls l8 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title '70%' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Calculation_fc1' ls l0 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Power_DC_Sum' ls l1fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Calculation' ls l5 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'East' ls l2 lw 0.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'South' ls l3 lw 0.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'West' ls l4 lw 0.5 with lines
</pre>

== PV Eigenverbrauch-Steuerung ==
=== Beispiel Luft Wärme Pumpe ===
==== RAW Definition LWP_LuftWärmePumpe (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod LWP dummy
attr LWP DbLogExclude .*
attr LWP DbLogInclude state
attr LWP alias LWP_LuftWärmePumpe
attr LWP group PV Eigenverbrauch
attr LWP icon sani_earth_source_heat_pump
attr LWP readingList LWP_Button PowerLevelMinTime PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay SetCmdOff SetCmdOn TimeStart TimeEnd
attr LWP room Strom->Photovoltaik
attr LWP setList LWP_Button:uzsuToggle,on,off PowerLevelMinTime:slider,60,30,300 PowerLimitOn:slider,1000,250,4000 PowerLimitOff:slider,1000,250,4000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,900,300,28800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr LWP sortby 10
attr LWP stateFormat state
attr LWP verbose 0
attr LWP webCmd LWP_Button

setstate LWP off
setstate LWP 2020-08-05 17:38:03 LWP_Button off
setstate LWP 2020-03-02 11:56:45 PowerLevelMinTime 600
setstate LWP 2020-02-05 14:11:42 PowerLimitOff 2250
setstate LWP 2020-03-02 11:56:39 PowerLimitOn 3000
setstate LWP 2019-08-02 10:31:21 RunTimeMin 3600
setstate LWP 2020-02-05 14:13:01 RunTimePerDay 28800
setstate LWP 2019-12-29 10:47:55 SetCmdOff set shelly01 off 0
setstate LWP 2019-07-22 15:35:59 SetCmdOn set shelly01 on 0
setstate LWP 2019-11-09 12:13:04 TimeEnd 16:00
setstate LWP 2020-04-02 13:51:54 TimeStart 12:30
setstate LWP 2020-08-05 17:38:03 state off
</syntaxhighlight>
==== RAW Definition LWP_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod LWP_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
##\
([LWP_Counter:pulseTimePerDay] >= [LWP:RunTimePerDay] and\
[LWP_Counter:pulseTimeIncrement] >= [LWP:RunTimeMin] and\
[LWP:state] ne "off" and [LWP:LWP_Button] eq "off" )\
\
({Log 3, " LWP_PV cmd_1 PV : LWP off"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
)\
################################################################################################################\
## 2 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und die PV Produktion unter dem Mindestbedarf ist\
##\
DOELSEIF\
( ([PV_Anlage_1:Total_PV_Power_reserve]+[StromZaehler_Heizung:SMAEM1901401955_Bezug_Wirkleistung]) < [LWP:PowerLimitOff] and\
[LWP_Counter:pulseTimeIncrement] >= [LWP:RunTimeMin] and\
[LWP:state] ne "off" and\
[LWP:LWP_Button] ne "on" )\
\
({Log 3, " LWP_PV cmd_2 PV : LWP off"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
)\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4 wieder außerkraft,\
## wenn wärend der Wartezeit die PV Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [LWP:PowerLimitOff] and\
[LWP_PV:wait_timer] ne "no timer" and\
[LWP_PV:wait_timer] ne "" and\
[LWP:state] eq "off" )\
\
({Log 3, "LWP_PV cmd_3 PV : Stop wait timer LWP"})\
################################################################################################################\
## 4 Eigenverbrauch einschalten: wenn PV Produktion über dem Mindestbedarf ist und die Laufzeit pro Tag noch nicht erreicht ist\
##\
DOELSEIF\
([Astro:ObsSeason] ne "Sommer" and [Astro:ObsSeason] ne "Frühling" and\
[PV_Anlage_1:Total_PV_Power_reserve] >= [LWP:PowerLimitOn] and\
[[LWP:TimeStart]-[LWP:TimeEnd]] and\
[LWP:state] eq "off" and\
[LWP_Counter:pulseTimePerDay] < [LWP:RunTimePerDay] and\
[Heizung:hotWaterTemperature] < 60 )\
\
({Log 3, "LWP_PV cmd_4 : LWP on"}\
{fhem("".ReadingsVal("LWP","SetCmdOn",0))}\
{fhem("set LWP on")}\
{fhem("set Heizung hotWaterTemperatureTarget 60.0")}\
)\
################################################################################################################\
## 5 Signal für den PV-Modus der LWP einschalten.\
##\
DOELSEIF\
([LWP:LWP_Button] eq "on" )\
\
({Log 3, "LWP_PV cmd_5 PV : LWP on for manuel PV-Modus"}\
{fhem("".ReadingsVal("LWP","SetCmdOn",0))}\
{fhem("set LWP on")}\
{fhem("set Heizung hotWaterTemperatureTarget 60.0")}\
)\
################################################################################################################\
## 6 Signal für den PV-Modus der LWP abschalten.\
##\
DOELSEIF\
([LWP:LWP_Button] eq "off" and\
[$SELF:cmd_nr] eq "5" )\
\
({Log 3, "LWP_PV cmd_6 PV : LWP off after manuel PV-Modus"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
)\
################################################################################################################\
## 7 Stop wait Timer für das Abschalten, wenn die LWP beim Starten noch anläuft\
##\
DOELSEIF\
([StromZaehler_Heizung:SMAEM1901401955_Bezug_Wirkleistung] > 300 and\
[Heizung:opStateHeatPump1] eq "Wärmepumpe kommt" and\
[Heizung:opStateHeatPump3] eq "Pumpenvorlauf" )\
\
({Log 3, "LWP_PV cmd_7 : Stop wait timer LWP"})\
################################################################################################################\
## 8 LWP Ende\
##\
DOELSEIF\
([StromZaehler_Heizung:SMAEM1901401955_Bezug_Wirkleistung] < 300 and\
[LWP_Counter:pulseTimeIncrement] >= [LWP:RunTimeMin] and\
([Heizung:opStateHeatPump1] ne "Wärmepumpe läuft" or [Heizung:opStateHeatPump3] eq "Luftabtauen" ) and\
([$SELF:cmd_nr] eq "4" or [$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "10") )\
\
({Log 3, "LWP_PV cmd_8 : LWP run finished"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
{fhem("setreading LWP LWP_Button off")}\
)\
################################################################################################################\
## 9 LWP Zwangseinschalten: Sollte das Brauchwasser noch nicht aufgeheizt sein, wird um die Hysterese erhöht.\
## Dies kann passieren, wenn am Tag vorher der PV-Modus lief und dann das Wasser noch knapp über dem Mindestwert ist.\
##\
DOELSEIF\
([Astro:ObsSeason] ne "Sommer" and [Astro:ObsSeason] ne "Frühling" and\
[[LWP:TimeEnd]] and\
[Heizung:hotWaterTemperature] < 47 and\
([LWP_Counter:pulseTimePerDay] < [Pool:RunTimePerDay] or\
[LWP_Counter:countsPerDay] eq 0) )\
\
({Log 3, "LWP_PV cmd_9 : LWP on for water heating"}\
\
{fhem("set Heizung hotWaterTemperatureTarget ". (ReadingsVal("Heizung","hotWaterTemperature",46)+4))}\
\
{Log 3, "LWP_PV cmd_9 : LWP hotWaterTemperatureTarget ".ReadingsVal("Heizung","hotWaterTemperatureTarget",0)}\
)\
################################################################################################################\
## 10 Hohe Priorität im Winter fuer die LWP\
## Einschalten, wenn der Pool läuft, der Speicher geladen ist und noch Überschuss da ist.\
##\
DOELSEIF\
([Astro:ObsSeason] eq "Winter" and\
[PV_Anlage_1:Total_PV_Power_reserve] >= 2000 and\
[shelly02:power_0] > 800 and\
[PV_Anlage_1:Act_state_of_charge] > 60 and\
[Heizung:hotWaterTemperature] < 60 and \
[$SELF:cmd_nr] ne "10" )\
\
({Log 3, "LWP_PV cmd_10 : LWP Priorität"}\
{fhem("set LWP_PV cmd_4")}\
)\

attr LWP_PV DbLogExclude .*
attr LWP_PV DbLogInclude state,cmd.*,Device,LWP_Status,wait_timer
attr LWP_PV alias LWP_PV
attr LWP_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch aus|Stop wait timer|Eigenverbrauch ein|LWP ein für manuellen PV-Modus|LWP aus nach manuellem PV-Modus|Stop wait timer fuer aus|LWP aus nach PV-Modus|LWP Brauchwasser nachheizen|LWP Priorität
attr LWP_PV do always
attr LWP_PV group PV Eigenverbrauch-Steuerung
attr LWP_PV icon sani_earth_source_heat_pump
attr LWP_PV room Strom->Photovoltaik
attr LWP_PV sortby 01
attr LWP_PV stateFormat state : LWP_Status : Brauchwasser e_Heizung_hotWaterTemperature °C
attr LWP_PV userReadings LWP_Status { ReadingsVal("Heizung","state","") }
attr LWP_PV verbose 5
attr LWP_PV wait 0:10:0:[LWP:PowerLevelMinTime]:0:0:900:0:0
</syntaxhighlight>
- RAW Definition LWP_Signale (Shelly Modul: shelly1pm)
<syntaxhighlight lang="Perl">
defmod shelly01 Shelly 192.168.178.55
attr shelly01 DbLogExclude .*
attr shelly01 DbLogInclude relay.*,power.*,energy.*
attr shelly01 alias LWP_Signale
attr shelly01 event-on-change-reading relay.*,power.*,energy.*,state,network
attr shelly01 group PV Eigenverbrauch-Steuerung
attr shelly01 icon taster_ch_1
attr shelly01 mode relay
attr shelly01 model shelly1pm
attr shelly01 room Shelly,Heizung->System,Strom->Photovoltaik
attr shelly01 sortby 02
attr shelly01 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Gesamt 0: %08.2f KWh<br>\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
ReadingsVal($name,"WebLink","none") ,\
ReadingsVal($name,"energy_0",0)/1000,\
(ReadingsVal($name,"relay","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power",0),\
)}
attr shelly01 userReadings WebLink:network { my $ip=ReadingsVal($NAME,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") }
attr shelly01 webCmd |
</pre>
==== RAW Definition LWP_Counter (HourCounter Modul) ====
<pre>
defmod LWP_Counter HourCounter LWP:on.* LWP:off
attr LWP_Counter DbLogExclude .*
attr LWP_Counter alias LWP_Counter
attr LWP_Counter event-min-interval .*:600
attr LWP_Counter event-on-change-reading .*
attr LWP_Counter group PV Eigenverbrauch-Steuerung
attr LWP_Counter icon time_timer
attr LWP_Counter interval 5
attr LWP_Counter room Strom->Photovoltaik
attr LWP_Counter sortby 03
attr LWP_Counter verbose 0
</syntaxhighlight>
==== RAW Definition rg_LWP_Status (readingsGroup Modul) ====
<syntaxhighlight lang="Perl">
defmod rg_LWP_Status readingsGroup <Device>,<Information>,<Wert> LWP:<Status>,state LWP:<PowerLevelMinTime>,PowerLevelMinTime LWP:<PowerLimitOn>,PowerLimitOn LWP:<PowerLimitOff>,PowerLimitOff LWP:<TimeStart>,!TimeStart LWP:<TimeEnd>,!TimeEnd LWP:<RunTimeMin>,RunTimeMin LWP_Counter:<RunTimeMin>,pulseTimeIncrement LWP:<RunTimePerDay>,RunTimePerDay LWP_Counter:<RunTimePerDay>,pulseTimePerDay LWP_PV:<wait>,wait_timer LWP_PV:<TimeStart>,timer_01_c04 LWP_PV:<TimeEnd>,timer_02_c04
attr rg_LWP_Status DbLogExclude .*
attr rg_LWP_Status alias Status LuftWärmePumpe Eigenverbrauch
attr rg_LWP_Status commands {state => 'state:on,off',\
PowerLevelMinTime => 'PowerLevelMinTime:selectnumbers,60,60,600,0,lin',\
PowerLimitOn => 'PowerLimitOn:selectnumbers,1000,250,4000,0,lin',\
PowerLimitOff => 'PowerLimitOff:selectnumbers,1000,250,4000,0,lin',\
RunTimeMin => 'RunTimeMin:selectnumbers,300,300,14400,0,lin',\
RunTimePerDay => 'RunTimePerDay:selectnumbers,300,300,28800,0,lin',\
TimeStart => 'TimeStart:time',\
TimeEnd => 'TimeEnd:time'}
attr rg_LWP_Status group PV Status
attr rg_LWP_Status nameStyle style="color:grey"
attr rg_LWP_Status room Strom->Photovoltaik
attr rg_LWP_Status sortby 01
attr rg_LWP_Status style style="font-size:18px"
</syntaxhighlight>

=== Beispiel Pool===
==== RAW Definition Pool_Softube (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod Pool dummy
attr Pool DbLogExclude .*
attr Pool DbLogInclude state
attr Pool alias Pool_Softube
attr Pool event-on-change-reading .*
attr Pool group PV Eigenverbrauch
attr Pool icon scene_swimming
attr Pool readingList Pool_Button PowerLevelMinTime PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay RunTimePerDaySummer RunTimePerDayWinter SetCmdOff SetCmdOn TimeStart TimeEnd
attr Pool room Strom->Photovoltaik
attr Pool setList Pool_Button:uzsuToggle,on,off PowerLevelMinTime:slider,30,30,300 PowerLimitOn:slider,500,100,1500 PowerLimitOff:slider,0,100,1000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,900,300,64800 RunTimePerDaySummer:slider,900,300,7200 RunTimePerDayWinter:slider,3600,900,64800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr Pool sortby 11
attr Pool stateFormat state
attr Pool verbose 0
attr Pool webCmd Pool_Button

setstate Pool off
setstate Pool 2020-08-28 13:30:10 Pool_Button off
setstate Pool 2019-12-02 10:31:26 PowerLevelMinTime 600
setstate Pool 2019-11-13 10:58:18 PowerLimitOff 800
setstate Pool 2019-11-06 11:49:00 PowerLimitOn 1000
setstate Pool 2020-08-14 16:26:09 RunTimeMin 1800
setstate Pool 2020-08-28 06:15:00 RunTimePerDay 3600
setstate Pool 2020-08-16 13:17:45 RunTimePerDaySummer 3600
setstate Pool 2020-08-25 19:32:33 RunTimePerDayWinter 14400
setstate Pool 2019-08-01 14:18:08 SetCmdOff set shelly02 off 0
setstate Pool 2019-08-02 09:33:06 SetCmdOn set shelly02 on 0
setstate Pool 2019-10-31 21:53:28 TimeEnd 16:00
setstate Pool 2020-04-08 18:19:29 TimeStart 12:30
setstate Pool 2020-08-28 14:13:02 state off
</syntaxhighlight>
==== RAW Definition Pool_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod Pool_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
##\
([Pool_Counter:pulseTimePerDay] >= [Pool:RunTimePerDay] and\
[Pool_Counter:pulseTimeIncrement] >= [Pool:RunTimeMin] and\
[Pool:state] eq "on" and [Pool:Pool_Button] eq "off" )\
\
({Log 3, "Pool_PV cmd_1 : Pool off"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")} )\
################################################################################################################\
## 2 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und die PV-Produktion unter dem Mindestbedarf ist.\
## Bei Pool Nutzung und Pflegeprogramm wird nicht abgeschaltet.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Pool:PowerLimitOff] and\
[Pool_Counter:pulseTimeIncrement] >= [Pool:RunTimeMin] and\
[Pool:state] eq "on" and \
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" and [$SELF:cmd_nr] ne "10" )\
\
({Log 3, "Pool_PV cmd_2 : Pool off"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")}\
{fhem("setreading Pool Pool_Button off")} )\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer Peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4 wieder außer kraft,\
## wenn während der Wartezeit die PV-Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Pool:PowerLimitOff] and\
[$SELF:wait_timer] ne "no timer" and\
[$SELF:wait_timer] ne "" and\
[Pool:state] eq "off" )\
\
({Log 3, "Pool_PV cmd_3 : Stop wait timer Pool"})\
################################################################################################################\
## 4 Eigenverbrauch einschalten: wenn PV-Produktion über dem Mindestbedarf ist und PV-Strom ins Netz eingespeist wird\
## und die Laufzeit pro Tag noch nicht erreicht ist;; Bei über 7000 Watt Einspeisung sofort aktivieren\
##\
DOELSEIF\
(([PV_Anlage_1:Total_PV_Power_reserve] >= [Pool:PowerLimitOn] and\
[[Pool:TimeStart]-[Pool:TimeEnd]] and\
[Pool:state] eq "off" and\
[Pool_Counter:pulseTimePerDay] < [Pool:RunTimePerDay]\
) or\
[PV_Anlage_1:Total_active_power_(powermeter)] <= -7000\
)\
\
({Log 3, "Pool_PV cmd_4 : Pool on"}\
{fhem("set Pool_Counter pulseTimeIncrement 0")}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 5 Steckdose für die Benutzung des Pools einschalten.\
##\
DOELSEIF\
([Pool:Pool_Button] eq "on" )\
\
({Log 3, "Pool_PV cmd_5 : Pool on for usage"}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 6 Steckdose des Pools abschalten.\
##\
DOELSEIF\
([Pool:Pool_Button] eq "off" and\
[$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7")\
\
({Log 3, "Pool_PV cmd_6 : Pool off after usage"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")} )\
################################################################################################################\
## 7 Stop wait Timer für das Abschalten, wenn die Pumpe beim Starten noch anläuft\
##\
DOELSEIF\
([shelly02:power_0] > 10 and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7" or [$SELF:cmd_nr] eq "9") and\
[$SELF:wait_timer] ne "no timer" and\
[$SELF:wait_timer] ne "" and\
[Pool:state] eq "on" )\
\
({Log 3, "Pool_PV cmd_7 : Stop wait timer Pool"})\
################################################################################################################\
## 8 Pool Ende\
##\
DOELSEIF\
([shelly02:power_0] < 10 and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7" or [$SELF:cmd_nr] eq "9") )\
\
({Log 3, "Pool_PV cmd_8 : Pool run finished"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")}\
{fhem("setreading Pool Pool_Button off")} )\
################################################################################################################\
## 9 Pflege Zwangseinschaltung: Es muss mindestens einmal pro Tag eingeschaltet werden, auch wenn kein PV Strom vorhanden war.\
##\
DOELSEIF\
([[Pool:TimeEnd]] and\
([Pool_Counter:pulseTimePerDay] < [Pool:RunTimePerDay] or\
[Pool_Counter:countsPerDay] eq 0)\
)\
\
({Log 3, "Pool_PV cmd_9 : Pool on for maintanance"}\
{fhem("set Pool_Counter pulseTimeIncrement 0")}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 10 Pflege Zwangseinschaltung bei günstigem Strom nachts im Winter\
##\
DOELSEIF\
([Astro:ObsSeason] eq "Winter" and\
[Strom_Kosten:aWATTar_Trigger] eq "on" and\
[22:00-05:00]\
)\
\
({Log 3, "Pool_PV cmd_10 : Pool on for maintanance by aWATTar"}\
{fhem("set Pool_Counter pulseTimeIncrement 0")}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 11 Abschaltung bei teurem Strom\
##\
DOELSEIF\
([Astro:ObsSeason] eq "Winter" and\
[Strom_Kosten:aWATTar_Trigger] eq "off" and\
[$SELF:cmd_nr] eq "10"\
)\
\
({Log 3, "Pool_PV cmd_11 : Pool off after maintanance by aWATTar"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")} )\
################################################################################################################\
## 12 Pool durch kürzere Laufzeit abkühlen lassen\
##\
DOELSEIF\
([06:15] and [Heizung:averageAmbientTemperature])\
\
(\
{ if ( [Heizung:averageAmbientTemperature] >= 18 )\
{fhem("setreading Pool RunTimePerDay ".ReadingsVal("Pool","RunTimePerDaySummer",0) )}\
else \
{fhem("setreading Pool RunTimePerDay ".ReadingsVal("Pool","RunTimePerDayWinter",0) )}\
},\
{Log 3, "Pool_PV cmd_12 : Pool RunTimePerDay switched"}\
)\
\

attr Pool_PV DbLogExclude .*
attr Pool_PV DbLogInclude cmd.*,state,cmd.*,Device,Pool_Pumpe_Status,wait_timer
attr Pool_PV alias Pool_PV
attr Pool_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch aus|Stop wait timer|Eigenverbrauch freigegeben|Pool ein für Benutzung|Pool aus nach Benutzung|Stop wait timer für aus|Pool aus|Pflegemodus ohne PV|Strombörse ein|Strombörse aus|RunTimePerDay switched
attr Pool_PV disable 0
attr Pool_PV do always
attr Pool_PV event-on-change-reading .*
attr Pool_PV group PV Eigenverbrauch-Steuerung
attr Pool_PV icon scene_swimming
attr Pool_PV room Strom->Photovoltaik
attr Pool_PV sortby 11
attr Pool_PV stateFormat state : Pool_Pumpe_Status
attr Pool_PV userReadings Pool_Pumpe_Status { ReadingsVal("shelly02","power_0",0)>10 ? "Pool_Pumpe_laeuft" : "Pool_Pumpe_aus"}
attr Pool_PV verbose 0
attr Pool_PV wait 0:10:0:[Pool:PowerLevelMinTime]:0:0:0:300:0:300
</syntaxhighlight>
==== RAW Definition Pool_Signale (Shelly Modul: shelly1pm) ====
<syntaxhighlight lang="Perl">
defmod shelly02 Shelly 192.168.178.52
attr shelly02 DbLogExclude .*
attr shelly02 DbLogInclude relay.*,power.*,energy.*
attr shelly02 alias Pool_Signale
attr shelly02 comment relais_0 => Pool limit 1000 W\
relail_1 => Terrasse Lichterkette limit 100 W
attr shelly02 event-on-change-reading relay.*,power.*,energy.*,state,network
attr shelly02 group PV Eigenverbrauch-Steuerung
attr shelly02 icon taster_ch_1
attr shelly02 mode relay
attr shelly02 model shelly2.5
attr shelly02 room Shelly,Strom->Photovoltaik
attr shelly02 sortby 12
attr shelly02 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
Status: %s<br>\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Gesamt 0: %08.2f KWh<br>Gesamt 1: %08.2f KWh\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
Relais 1: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
(ReadingsVal($name,"state","none") eq "OK") ? "<span style='color:#00FF00'>OK</span>":"<span style='color:#FF0000'>Error</span>",\
ReadingsVal($name,"WebLink","none") ,\
ReadingsVal($name,"energy_0",0)/1000,\
ReadingsVal($name,"energy_1",0)/1000,\
(ReadingsVal($name,"relay_0","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power_0",0),\
(ReadingsVal($name,"relay_1","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power_1",0)\
)}
attr shelly02 userReadings WebLink:network { my $ip=ReadingsVal($name,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") }
attr shelly02 verbose 0
attr shelly02 webCmd |
</syntaxhighlight>
==== RAW Definition Pool_Counter (HourCounter Modul) ====
<syntaxhighlight lang="Perl">
defmod Pool_Counter HourCounter shelly02:power_0:\s[0-9]{2,}(\.[0-9]{1,2})*$ shelly02:power_0:\s[0-9]{1}(\.[0-9]{1,2})*$
attr Pool_Counter DbLogExclude .*
attr Pool_Counter alias Pool_Counter
attr Pool_Counter comment On und Off des Pools werden direkt über den Shelly Stromverbrauch getriggert.
attr Pool_Counter event-on-change-reading .*
attr Pool_Counter group PV Eigenverbrauch-Steuerung
attr Pool_Counter icon time_timer
attr Pool_Counter interval 5
attr Pool_Counter room Strom->Photovoltaik
attr Pool_Counter sortby 13
attr Pool_Counter verbose 0
</syntaxhighlight>
==== RAW Definition rg_Pool_Status (readingsGroup Modul) ====
<syntaxhighlight lang="Perl">
defmod rg_Pool_Status readingsGroup <Device>,<Information>,<Wert> Pool:<Status>,!state Pool:<PowerLevelMinTime>,!PowerLevelMinTime Pool:<PowerLimitOn>,!PowerLimitOn Pool:<PowerLimitOff>,!PowerLimitOff Pool:<TimeStart>,!TimeStart Pool:<TimeEnd>,!TimeEnd Pool:<RunTimeMin>,!RunTimeMin Pool_Counter:<RunTimeMin>,!pulseTimeIncrement Pool:<RunTimePerDay>,!RunTimePerDay Pool:<RunTimePerDaySummer>,!RunTimePerDaySummer Pool:<RunTimePerDayWinter>,!RunTimePerDayWinter Pool_Counter:<RunTimePerDay>,!pulseTimePerDay Pool_PV:<wait>,wait_timer Pool_PV:<TimeStart>,timer_01_c04 Pool_PV:<TimeEnd>,timer_02_c04
attr rg_Pool_Status DbLogExclude .*
attr rg_Pool_Status alias Status Softube Pool Eigenverbrauch
attr rg_Pool_Status commands {state => 'state:on,off',\
PowerLevelMinTime => 'PowerLevelMinTime:selectnumbers,60,30,600,0,lin',\
PowerLimitOn => 'PowerLimitOn:selectnumbers,500,250,1500,0,lin',\
PowerLimitOff => 'PowerLimitOff:selectnumbers,0,100,1000,0,lin',\
RunTimeMin => 'RunTimeMin:selectnumbers,300,300,14400,0,lin',\
RunTimePerDaySummer => 'RunTimePerDaySummer:selectnumbers,300,300,3600,0,lin',\
RunTimePerDayWinter => 'RunTimePerDayWinter:selectnumbers,3600,900,64800,0,lin',\
TimeStart => 'TimeStart:time',\
TimeEnd => 'TimeEnd:time'}
attr rg_Pool_Status group PV Status
attr rg_Pool_Status nameStyle style="color:grey"
attr rg_Pool_Status room Strom->Photovoltaik
attr rg_Pool_Status sortby 02
attr rg_Pool_Status style style="font-size:18px"
</syntaxhighlight>

=== Beispiel Waschmaschine (mit Walzenschalter ;-) ) ===
==== RAW Definition Waschmaschine (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod Waschmaschine dummy
attr Waschmaschine DbLogExclude .*
attr Waschmaschine DbLogInclude state
attr Waschmaschine alias Waschmaschine
attr Waschmaschine group PV Eigenverbrauch
attr Waschmaschine icon scene_washing_machine
attr Waschmaschine readingList Waschmaschine_Button PowerLevelMinTime PowerPhaseUse PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay SetCmdOff SetCmdOn TimeStart TimeEnd
attr Waschmaschine room Strom->Photovoltaik
attr Waschmaschine setList Waschmaschine_Button:uzsuToggle,on,off PowerLevelMinTime:slider,30,30,300 PowerLimitOn:slider,250,250,2000 PowerLimitOff:slider,0,250,1000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,7200,300,28800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr Waschmaschine sortby 12
attr Waschmaschine stateFormat state
attr Waschmaschine verbose 0
attr Waschmaschine webCmd Waschmaschine_Button

setstate Waschmaschine off
setstate Waschmaschine 2019-12-02 10:29:49 PowerLevelMinTime 300
setstate Waschmaschine 2019-11-06 10:56:22 PowerLimitOff 250
setstate Waschmaschine 2020-04-20 13:06:04 PowerLimitOn 2000
setstate Waschmaschine 2019-12-02 15:01:18 RunTimeMin 5400
setstate Waschmaschine 2020-04-02 13:59:34 RunTimePerDay 19200
setstate Waschmaschine 2020-01-01 16:29:10 SetCmdOff set shelly03 off 0
setstate Waschmaschine 2020-01-01 16:29:24 SetCmdOn set shelly03 on 0
setstate Waschmaschine 2019-08-01 14:25:25 TimeEnd 18:00
setstate Waschmaschine 2019-10-28 09:13:30 TimeStart 09:00
setstate Waschmaschine 2020-08-27 16:17:23 Waschmaschine_Button off
setstate Waschmaschine 2020-08-28 16:29:42 state off
</syntaxhighlight>
==== RAW Definition Waschmaschine_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod Waschmaschine_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch sperren: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
## jedoch nicht wenn manueller Betrieb aktiv ist.\
##\
([Waschmaschine_Counter:pulseTimePerDay] >= [Waschmaschine:RunTimePerDay] and\
[Waschmaschine_Counter:pulseTimeIncrement] >= [Waschmaschine:RunTimeMin] and\
[Waschmaschine:state] eq "on" and [Waschmaschine:Waschmaschine_Button] eq "off" )\
\
({Log 3, "Waschmaschine cmd_1 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
{fhem("set Waschmaschine off")}\
)\
################################################################################################################\
## 2 Eigenverbrauch sperren: wenn Mindestlaufzeit erreicht wurde und die PV-Produktion unter dem Mindestbedarf ist\
## ausser bei manuellem Einschalten und wenn das Waschprogramm bereits läuft\
##\
## ([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOff] and\
## [Waschmaschine_Counter:pulseTimeIncrement] >= [Waschmaschine:RunTimeMin] and\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOn] and\
[Waschmaschine:state] eq "on" and\
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" )\
\
({Log 3, "Waschmaschine cmd_2 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
{fhem("set Waschmaschine off")}\
)\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer Peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4\
## wieder außer kraft, wenn während der Wartezeit die PV-Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOff] and\
[Waschmaschine_PV:wait_timer] ne "no timer" and\
[Waschmaschine_PV:wait_timer] ne "" and\
[Waschmaschine:state] eq "off" )\
\
({Log 3, "Waschmaschine cmd_3 : Waschmaschine stop wait timer"})\
################################################################################################################\
## 4 Eigenverbrauch freigeben: wenn PV-Produktion über dem Mindestbedarf ist und PV-Strom ins Netz eingespeist\
## wird und die Laufzeit pro Tag noch nicht erreicht ist\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] > [Waschmaschine:PowerLimitOn] and\
[Waschmaschine:state] eq "off" and\
[[Waschmaschine:TimeStart]-[Waschmaschine:TimeEnd]] and\
[Waschmaschine_Counter:pulseTimePerDay] < [Waschmaschine:RunTimePerDay] )\
\
({Log 3, "Waschmaschine cmd_4 : Waschmaschine freigabe"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOn",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist eingeschaltet")}\
{fhem("set Waschmaschine on")}\
)\
################################################################################################################\
## 5 Steckdose manuell für die Benutzung der Waschmaschine einschalten.\
##\
DOELSEIF\
([Waschmaschine:Waschmaschine_Button] eq "on" )\
\
({Log 3, "Waschmaschine cmd_5 : Waschmaschine manuell ein"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOn",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist eingeschaltet")}\
{fhem("set Waschmaschine on")}\
)\
################################################################################################################\
## 6 Steckdose der Waschmaschine manuell abschalten.\
##\
DOELSEIF\
([Waschmaschine:Waschmaschine_Button] eq "off" and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7") )\
\
({Log 3, "Waschmaschine cmd_6 : Waschmaschine manuell aus"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
{fhem("set Waschmaschine off")}\
)\
################################################################################################################\
## 7 Statuswechsel wenn das Waschprogramm gestartet ist\
##\
DOELSEIF\
([shelly03:power] > 0 and\
[shelly03:power_Waschmaschine_avg] < 70 and\
[$SELF:cmd_nr] ne "7")\
\
({Log 3, "Waschmaschine cmd_7 : Waschmaschine Programm gestarted"}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Waschprogramm gestartet")}\
)\
################################################################################################################\
## 8 Abschalten der Steckdose beim Waschprogramm Ende\
##\
DOELSEIF\
([shelly03:power] == 0 and\
[shelly03:power_Waschmaschine_avg] > 0 and\
[$SELF:cmd_nr] eq "7" )\
\
({Log 3, "Waschmaschine cmd_8 : Waschmaschine aus"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("set Waschmaschine off")}\
{fhem("setreading Waschmaschine Waschmaschine_Button off")}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Waschprogramm beendet")}\
)\
################################################################################################################\
## 9 Abschalten der Steckdose wenn die Waschmaschine nicht gebraucht wurde\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOn] and\
[[Waschmaschine:TimeEnd]-[Waschmaschine:TimeStart]] and\
[Waschmaschine:state] eq "on" and\
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" )\
\
({Log 3, "Waschmaschine cmd_9 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("set Waschmaschine off")}\
{fhem("setreading Waschmaschine Waschmaschine_Button off")}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
)
attr Waschmaschine_PV DbLogExclude .*
attr Waschmaschine_PV DbLogInclude state,STATE,cmd.*,Device,Waschmaschine_Status,wait_timer
attr Waschmaschine_PV alias Waschmaschine_PV
attr Waschmaschine_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch gesperrt|Stop wait timer|Eigenverbrauch freigegeben|Waschmaschine manuell ein|Waschmaschine manuell aus|Waschmaschine laeuft|Waschmaschine aus|Eigenverbrauch gesperrt
attr Waschmaschine_PV do always
attr Waschmaschine_PV group PV Eigenverbrauch-Steuerung
attr Waschmaschine_PV icon scene_washing_machine
attr Waschmaschine_PV room Strom->Photovoltaik
attr Waschmaschine_PV sortby 21
attr Waschmaschine_PV stateFormat state : Waschmaschine_Status
attr Waschmaschine_PV verbose 0
attr Waschmaschine_PV wait 0:0:0:[Waschmaschine:PowerLevelMinTime]:0:30:0:60:30
</syntaxhighlight>
==== RAW Definition Waschmaschine_Signale (Shelly Modul: shelly1pm) ====
<syntaxhighlight lang="Perl">
defmod shelly03 Shelly 192.168.178.54
attr shelly03 DbLogExclude .*
attr shelly03 DbLogInclude relay.*,power.*,energy.*
attr shelly03 alias Waschmaschine_Signale
attr shelly03 event-on-change-reading relay.*,power.*,energy.*,network
attr shelly03 group PV Eigenverbrauch-Steuerung
attr shelly03 icon taster_ch_1
attr shelly03 interval 60
attr shelly03 mode relay
attr shelly03 model shelly1pm
attr shelly03 room Shelly,Strom->Photovoltaik
attr shelly03 sortby 22
attr shelly03 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Gesamt 0: %08.2f KWh<br>\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
ReadingsVal($name,"WebLink","none") ,\
ReadingsVal($name,"energy",0)/1000,\
(ReadingsVal($name,"relay","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power",0)\
)}
attr shelly03 userReadings WebLink:network { my $ip=ReadingsVal($NAME,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") },\
power_Waschmaschine_avg:power.* { movingAverage($NAME,"power",300) }
attr shelly03 webCmd |
</syntaxhighlight>
==== RAW Definition Waschmaschine_Counter (HourCounter Modul) ====
<syntaxhighlight lang="Perl">
defmod Waschmaschine_Counter HourCounter Waschmaschine_PV:.*laeuft Waschmaschine_PV:Waschmaschine_Status:.*[beendet|ausgeschaltet]
attr Waschmaschine_Counter DbLogExclude .*
attr Waschmaschine_Counter alias Waschmaschine_Counter
attr Waschmaschine_Counter event-on-change-reading .*
attr Waschmaschine_Counter group PV Eigenverbrauch-Steuerung
attr Waschmaschine_Counter icon time_timer
attr Waschmaschine_Counter interval 5
attr Waschmaschine_Counter room Strom->Photovoltaik
attr Waschmaschine_Counter sortby 23
attr Waschmaschine_Counter verbose 0
</syntaxhighlight>
==== RAW Definition rg_Waschmaschine_Status (readingsGroup Modul) ====
<syntaxhighlight lang="Perl">
defmod rg_Waschmaschine_Status readingsGroup <Device>,<Information>,<Wert> Waschmaschine:<Status>,!state Waschmaschine:<PowerLevelMinTime>,!PowerLevelMinTime Waschmaschine:<PowerLimitOn>,!PowerLimitOn Waschmaschine:<PowerLimitOff>,!PowerLimitOff Waschmaschine:<TimeStart>,!TimeStart Waschmaschine:<TimeEnd>,!TimeEnd Waschmaschine:<RunTimeMin>,!RunTimeMin Waschmaschine_Counter:<RunTimeMin>,!pulseTimeIncrement Waschmaschine:<RunTimePerDay>,!RunTimePerDay Waschmaschine_Counter:<RunTimePerDay>,!pulseTimePerDay Waschmaschine_PV:<wait>,wait_timer Waschmaschine_PV:<TimeStart>,timer_01_c04 Waschmaschine_PV:<TimeEnd>,timer_02_c04
attr rg_Waschmaschine_Status DbLogExclude .*
attr rg_Waschmaschine_Status alias Status Waschmaschine Eigenverbrauch
attr rg_Waschmaschine_Status commands {state => 'state:on,off',\
PowerLevelMinTime => 'PowerLevelMinTime:selectnumbers,30,30,300,0,lin',\
PowerLimitOn => 'PowerLimitOn:selectnumbers,250,250,2000,0,lin',\
PowerLimitOff => 'PowerLimitOff:selectnumbers,0,50,800,0,lin',\
RunTimeMin => 'RunTimeMin:selectnumbers,300,300,7200,0,lin',\
RunTimePerDay => 'RunTimePerDay:selectnumbers,7200,300,28800,0,lin',\
TimeStart => 'TimeStart:time',\
TimeEnd => 'TimeEnd:time'}
attr rg_Waschmaschine_Status group PV Status
attr rg_Waschmaschine_Status nameStyle style="color:grey"
attr rg_Waschmaschine_Status room Strom->Photovoltaik
attr rg_Waschmaschine_Status sortby 03
attr rg_Waschmaschine_Status style style="font-size:18px"
</syntaxhighlight>

=== Beispiel Brunnenpumpe (mit extra Taster zum Aktivieren) ===
Das Beispiel für die Brunnenpumpe hat eine Besonderheit. Damit nicht vergessen wird die Brunnenpumpe nach der Benutzung wieder Stromlos zu schalten geschieht dies nach einer eingestellten Zeit, wenn sie nicht verwendet wurde. Also immer schön die Düse geöffnet halten :-) Des weitern kann die Pumpe über einen taster am Shelly2.5 aktiviert werden, was dem Elektriker gesagt werden sollte, damit er die Verdrahtung korrekt macht. Der Shelly2.5 aus diesem Beispiel wird ebenfalls für das nächste Beispiel verwendet, da die Steckdosen nebeneinander sind.
==== RAW Definition Brunnen (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod Brunnen dummy
attr Brunnen DbLogExclude .*
attr Brunnen DbLogInclude state
attr Brunnen alias Brunnen
attr Brunnen comment Version 2020.10.19 18:28
attr Brunnen group PV Eigenverbrauch
attr Brunnen icon well
attr Brunnen readingList Brunnen_Button PowerLevelMinTime PowerPhaseUse PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay SetCmdOff SetCmdOn TimeStart TimeEnd
attr Brunnen room Strom->Photovoltaik
attr Brunnen setList Brunnen_Button:uzsuToggle,on,off PowerLevelMinTime:slider,30,30,300 PowerLimitOn:slider,250,250,2000 PowerLimitOff:slider,0,250,1000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,7200,300,28800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr Brunnen sortby 13
attr Brunnen stateFormat state
attr Brunnen verbose 0
attr Brunnen webCmd Brunnen_Button

setstate Brunnen off
setstate Brunnen 2020-09-21 16:50:48 Brunnen_Button off
setstate Brunnen 2019-12-02 10:29:49 PowerLevelMinTime 300
setstate Brunnen 2019-11-06 10:56:22 PowerLimitOff 600
setstate Brunnen 2020-04-20 13:06:04 PowerLimitOn 900
setstate Brunnen 2019-12-02 15:01:18 RunTimeMin 60
setstate Brunnen 2020-04-02 13:59:34 RunTimePerDay 10800
setstate Brunnen 2020-01-01 16:29:10 SetCmdOff set shelly05 off 0
setstate Brunnen 2020-01-01 16:29:24 SetCmdOn set shelly05 on 0
setstate Brunnen 2020-09-13 15:07:03 TimeEnd 09:00
setstate Brunnen 2019-10-28 09:13:30 TimeStart 09:00
setstate Brunnen 2020-09-21 16:50:48 state off
</syntaxhighlight>
==== RAW Definition Brunnen_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod Brunnen_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch sperren: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
## jedoch nicht wenn manueller Betrieb aktiv ist.\
##\
([Brunnen_Counter:pulseTimePerDay] >= [Brunnen:RunTimePerDay] and\
[Brunnen_Counter:pulseTimeIncrement] >= [Brunnen:RunTimeMin] and\
[Brunnen:state] eq "on" and [Brunnen:Brunnen_Button] eq "off" )\
\
({Log 3, "Brunnen cmd_1 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Brunnen","SetCmdOff",0))}\
{fhem("setreading Brunnen_PV Brunnen_Status Steckdose ist ausgeschaltet")}\
{fhem("set Brunnen off")}\
)\
################################################################################################################\
## 2 Eigenverbrauch sperren: wenn Mindestlaufzeit erreicht wurde und die PV-Produktion unter dem Mindestbedarf ist\
## ausser bei manuellem Einschalten und wenn der Brunnen bereits läuft\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Brunnen:PowerLimitOn] and\
[Brunnen:state] eq "on" and\
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" )\
\
({Log 3, "Brunnen cmd_2 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Brunnen","SetCmdOff",0))}\
{fhem("setreading Brunnen_PV Brunnen_Status Steckdose ist ausgeschaltet")}\
{fhem("set Brunnen off")}\
)\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer Peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4\
## wieder außer kraft, wenn während der Wartezeit die PV-Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Brunnen:PowerLimitOff] and\
[Brunnen_PV:wait_timer] ne "no timer" and\
[Brunnen_PV:wait_timer] ne "" and\
[Brunnen:state] eq "off" )\
\
({Log 3, "Brunnen cmd_3 : Brunnen stop wait timer"})\
################################################################################################################\
## 4 Eigenverbrauch freigeben: wenn PV-Produktion über dem Mindestbedarf ist und PV-Strom ins Netz eingespeist\
## wird und die Laufzeit pro Tag noch nicht erreicht ist\
## Dies ist beim Brunnen nicht aktiv, um eine Überschwemmung zu vermeiden\
## Es wird nur eine log Meldung geschrieben\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] > [Brunnen:PowerLimitOn] and\
[Brunnen:state] eq "off" and\
[[Brunnen:TimeStart]-[Brunnen:TimeEnd]] and\
[Brunnen_Counter:pulseTimePerDay] < [Brunnen:RunTimePerDay] )\
\
({Log 3, "Brunnen cmd_4 : Brunnen freigabe"}\
{fhem("".ReadingsVal("Brunnen","SetCmdOn",0))}\
{fhem("setreading Brunnen_PV Brunnen_Status Steckdose kann eingeschaltet werden")}\
## {fhem("set Brunnen on")}\
)\
################################################################################################################\
## 5 Steckdose manuell für die Benutzung des Brunnens einschalten.\
##\
DOELSEIF\
([Brunnen:Brunnen_Button] eq "on" )\
\
({Log 3, "Brunnen cmd_5 : Brunnen manuell ein"}\
{fhem("".ReadingsVal("Brunnen","SetCmdOn",0))}\
{fhem("setreading Brunnen_PV Brunnen_Status Steckdose ist eingeschaltet")}\
{fhem("set Brunnen on")}\
)\
################################################################################################################\
## 6 Steckdose des Brunnen manuell abschalten.\
##\
DOELSEIF\
([Brunnen:Brunnen_Button] eq "off" and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7") )\
\
({Log 3, "Brunnen cmd_6 : Brunnen manuell aus"}\
{fhem("".ReadingsVal("Brunnen","SetCmdOff",0))}\
{fhem("setreading Brunnen_PV Brunnen_Status Steckdose ist ausgeschaltet")}\
{fhem("set Brunnen off")}\
)\
################################################################################################################\
## 7 Statuswechsel wenn die Brunnenpumpe läuft\
##\
DOELSEIF\
([shelly05:power_0] > 600 and\
[$SELF:cmd_nr] ne "7")\
\
({Log 3, "Brunnen cmd_7 : Brunnenpumpe läuft"}\
{fhem("setreading Brunnen_PV Brunnen_Status Brunnenpumpe gestartet")}\
{fhem("set Brunnen on")}\
)\
################################################################################################################\
## 8 Abschalten der Steckdose wenn Brunnenpumpe durch Druckschalter abschaltet\
##\
DOELSEIF\
([shelly05:power_0] == 0 )\
\
({Log 3, "Brunnen cmd_8 : Brunnenpumpe aus"}\
{fhem("".ReadingsVal("Brunnen","SetCmdOff",0))}\
{fhem("set Brunnen off")}\
{fhem("setreading Brunnen Brunnen_Button off")}\
{fhem("setreading Brunnen_PV Brunnen_Status Brunnenpumpe abgeschaltet")}\
)\
################################################################################################################\
## 9 Abschalten der Steckdose wenn der Brunnen nicht gebraucht wird\
##\
DOELSEIF\
([[Brunnen:TimeEnd]-[Brunnen:TimeStart]] and\
([Brunnen:state] eq "on" or [shelly05:relay_0] eq "on") )\
\
({Log 3, "Brunnen cmd_9 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Brunnen","SetCmdOff",0))}\
{fhem("set Brunnen off")}\
{fhem("setreading Brunnen Brunnen_Button off")}\
{fhem("setreading Brunnen_PV Brunnen_Status Steckdose ist ausgeschaltet")}\
)
attr Brunnen_PV DbLogExclude .*
attr Brunnen_PV DbLogInclude state,STATE,cmd.*,Device,Brunnen_Status,wait_timer
attr Brunnen_PV alias Brunnen_PV
attr Brunnen_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch gesperrt|Stop wait timer|Eigenverbrauch freigegeben|Brunnen manuell ein|Brunnen manuell aus|Brunnen laeuft|Brunnen aus|Eigenverbrauch gesperrt
attr Brunnen_PV comment Version 2020.10.19 18:28
attr Brunnen_PV do always
attr Brunnen_PV group PV Eigenverbrauch-Steuerung
attr Brunnen_PV icon well
attr Brunnen_PV room Strom->Photovoltaik
attr Brunnen_PV sortby 31
attr Brunnen_PV stateFormat state : Brunnen_Status
attr Brunnen_PV verbose 0
attr Brunnen_PV wait 0:0:0:[Brunnen:PowerLevelMinTime]:0:30:0:60:0
</syntaxhighlight>
==== RAW Definition Brunnen_Signale (Shelly Modul: shelly2.5) ====
Die Einschaltung der Brunnenpumpe erfolgt mit Relais 1 . Am Shelly2.5 ist auch ein Taster verdrahtet, über den die Pumpe vor Ort aktiviert werden kann.
<syntaxhighlight lang="Perl">
defmod shelly05 Shelly <IP-Address>
attr shelly05 DbLogExclude .*
attr shelly05 DbLogInclude relay.*,power.*,energy.*
attr shelly05 alias Brunnen und Shaun
attr shelly05 comment Version 2020.10.19 18:28
attr shelly05 event-on-change-reading relay.*,power.*,energy.*,state,network
attr shelly05 group PV Eigenverbrauch-Steuerung
attr shelly05 icon taster_ch_1
attr shelly05 interval 60
attr shelly05 mode relay
attr shelly05 model shelly2.5
attr shelly05 room Shelly,Strom->Photovoltaik
attr shelly05 sortby 32
attr shelly05 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
Status: %s<br>\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Brunnen Gesamt 0: %08.2f KWh<br>\
Shaun Gesamt 1: %08.2f KWh\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
Relais 1: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
(ReadingsVal($name,"state","none") eq "OK") ? "<span style='color:#00FF00'>OK</span>":"<span style='color:#FF0000'>Error</span>",\
ReadingsVal($name,"WebLink","none"),\
ReadingsVal($name,"energy_0",0)/1000,\
ReadingsVal($name,"energy_1",0)/1000,\
(ReadingsVal($name,"relay_0","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power_0",0),\
(ReadingsVal($name,"relay_1","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power_1",0)\
)}
attr shelly05 userReadings WebLink:network { my $ip=ReadingsVal($NAME,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") }
attr shelly05 webCmd |
</syntaxhighlight>
==== RAW Definition Brunnen_Counter (HourCounter Modul) ====
<syntaxhighlight lang="Perl">
defmod Brunnen_Counter HourCounter shelly05:power_0:\s[0-9]{2,}(\.[0-9]{1,2})*$ shelly05:power_0:\s[0-9]{1}(\.[0-9]{1,2})*$
attr Brunnen_Counter DbLogExclude .*
attr Brunnen_Counter alias Brunnen_Counter
attr Brunnen_Counter comment Version 2020.10.19 18:28\
On und Off des Pools werden direkt über den Shelly Stromverbrauch getriggert.
attr Brunnen_Counter event-on-change-reading .*
attr Brunnen_Counter group PV Eigenverbrauch-Steuerung
attr Brunnen_Counter icon time_timer
attr Brunnen_Counter interval 5
attr Brunnen_Counter room Strom->Photovoltaik
attr Brunnen_Counter sortby 33
attr Brunnen_Counter verbose 0
</syntaxhighlight>

=== Beispiel Accu laden ===
In diesem Beispiel wird der Accu eines Rasenroboters und in unserem Fall auch des E-Bikes an einer Steckdose geladen. Ziel ist es auch über den Winter immer wieder die Accus am Leben zu erhalten.
==== RAW Definition Shaun (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod Shaun dummy
attr Shaun DbLogExclude .*
attr Shaun DbLogInclude state
attr Shaun alias Shaun
attr Shaun comment Version 2020.10.19 18:28
attr Shaun group PV Eigenverbrauch
attr Shaun icon scene_robo_lawnmower
attr Shaun readingList Shaun_Button PowerLevelMinTime PowerPhaseUse PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay SetCmdOff SetCmdOn TimeStart TimeEnd
attr Shaun room Strom->Photovoltaik
attr Shaun setList Shaun_Button:uzsuToggle,on,off PowerLevelMinTime:slider,30,30,300 PowerLimitOn:slider,250,250,2000 PowerLimitOff:slider,0,250,1000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,7200,300,28800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr Shaun sortby 14
attr Shaun stateFormat state
attr Shaun verbose 0
attr Shaun webCmd Shaun_Button

setstate Shaun off
setstate Shaun 2019-12-02 10:29:49 PowerLevelMinTime 300
setstate Shaun 2019-11-06 10:56:22 PowerLimitOff 100
setstate Shaun 2020-04-20 13:06:04 PowerLimitOn 300
setstate Shaun 2019-12-02 15:01:18 RunTimeMin 300
setstate Shaun 2020-04-02 13:59:34 RunTimePerDay 21600
setstate Shaun 2020-01-01 16:29:10 SetCmdOff set shelly05 off 1
setstate Shaun 2020-01-01 16:29:24 SetCmdOn set shelly05 on 1
setstate Shaun 2020-10-21 12:30:05 Shaun_Button off
setstate Shaun 2020-09-21 12:05:19 TimeEnd 15:00
setstate Shaun 2020-09-21 12:05:34 TimeStart 12:00
setstate Shaun 2020-10-21 14:00:38 state off
</syntaxhighlight>
==== RAW Definition Shaun_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod Shaun_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch sperren: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
## jedoch nicht wenn manueller Betrieb aktiv ist.\
##\
([Shaun_Counter:pulseTimePerDay] >= [Shaun:RunTimePerDay] and\
[Shaun_Counter:pulseTimeIncrement] >= [Shaun:RunTimeMin] and\
[Shaun:state] eq "on" and [Shaun:Shaun_Button] eq "off" )\
\
({Log 3, "Shaun cmd_1 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Shaun","SetCmdOff",0))}\
{fhem("setreading Shaun_PV Shaun_Status Steckdose ist ausgeschaltet")}\
{fhem("set Shaun off")}\
)\
################################################################################################################\
## 2 Eigenverbrauch sperren: wenn Mindestlaufzeit erreicht wurde und die PV-Produktion unter dem Mindestbedarf ist\
## ausser bei manuellem Einschalten und wenn das Shaun Laden bereits läuft\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Shaun:PowerLimitOn] and\
[Shaun:state] eq "on" and\
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" )\
\
({Log 3, "Shaun cmd_2 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Shaun","SetCmdOff",0))}\
{fhem("setreading Shaun_PV Shaun_Status Steckdose ist ausgeschaltet")}\
{fhem("set Shaun off")}\
)\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer Peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4\
## wieder außer kraft, wenn während der Wartezeit die PV-Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Shaun:PowerLimitOff] and\
[Shaun_PV:wait_timer] ne "no timer" and\
[Shaun_PV:wait_timer] ne "" and\
[Shaun:state] eq "off" )\
\
({Log 3, "Shaun cmd_3 : Shaun stop wait timer"})\
################################################################################################################\
## 4 Eigenverbrauch freigeben: wenn PV-Produktion über dem Mindestbedarf ist und PV-Strom ins Netz eingespeist\
## wird und die Laufzeit pro Tag noch nicht erreicht ist\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] > [Shaun:PowerLimitOn] and\
[Shaun:state] eq "off" and\
[[Shaun:TimeStart]-[Shaun:TimeEnd]] and\
[Shaun_Counter:pulseTimePerDay] < [Shaun:RunTimePerDay] )\
\
({Log 3, "Shaun cmd_4 : Shaun freigabe"}\
{fhem("".ReadingsVal("Shaun","SetCmdOn",0))}\
{fhem("setreading Shaun_PV Shaun_Status Steckdose ist eingeschaltet")}\
{fhem("set Shaun on")}\
)\
################################################################################################################\
## 5 Steckdose manuell für die Benutzung des Shaun einschalten.\
##\
DOELSEIF\
([Brunnen:Brunnen_Button] eq "on" )\
\
({Log 3, "Shaun cmd_5 : Shaun manuell ein"}\
{fhem("".ReadingsVal("Shaun","SetCmdOn",0))}\
{fhem("setreading Shaun_PV Shaun_Status Steckdose ist eingeschaltet")}\
{fhem("set Shaun on")}\
)\
################################################################################################################\
## 6 Steckdose des Shaun manuell abschalten.\
##\
DOELSEIF\
([Shaun:Shaun_Button] eq "off" and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7") )\
\
({Log 3, "Shaun cmd_6 : Shaun manuell aus"}\
{fhem("".ReadingsVal("Shaun","SetCmdOff",0))}\
{fhem("setreading Shaun_PV Shaun_Status Steckdose ist ausgeschaltet")}\
{fhem("set Shaun off")}\
)\
################################################################################################################\
## 7 Statuswechsel wenn das Laden läuft\
##\
DOELSEIF\
([shelly05:power_1] > 15 and\
[$SELF:cmd_nr] ne "7")\
\
({Log 3, "Shaun cmd_7 : Shaun läuft"}\
{fhem("setreading Shaun_PV Shaun_Status Shaun wird geladen")}\
)\
################################################################################################################\
## 8 Abschalten der Steckdose wenn Shaun geladen ist\
##\
DOELSEIF\
([shelly05:power_1] <= 6 and\
[$SELF:cmd_nr] eq "7" )\
\
({Log 3, "Shaun cmd_8 : Shaun aus"}\
{fhem("".ReadingsVal("Shaun","SetCmdOff",0))}\
{fhem("set Shaun off")}\
{fhem("setreading Shaun Shaun_Button off")}\
{fhem("setreading Shaun_PV Shaun_Status Shaun hat geladen")}\
)\
################################################################################################################\
## 9 Abschalten der Steckdose wenn es nicht mehr benötigt wird\
##\
DOELSEIF\
(([PV_Anlage_1:Total_PV_Power_reserve] < [Shaun:PowerLimitOn] or\
[[Shaun:TimeEnd]-[Shaun:TimeStart]] ) and\
[Shaun:state] eq "on" and\
[$SELF:cmd_nr] ne "5" )\
\
({Log 3, "Shaun cmd_9 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Shaun","SetCmdOff",0))}\
{fhem("set Shaun off")}\
{fhem("setreading Shaun Shaun_Button off")}\
{fhem("setreading Shaun_PV Shaun_Status Steckdose ist ausgeschaltet")}\
)
attr Shaun_PV DbLogExclude .*
attr Shaun_PV DbLogInclude state,STATE,cmd.*,Device,Shaun_Status,wait_timer
attr Shaun_PV alias Shaun_PV
attr Shaun_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch gesperrt|Stop wait timer|Eigenverbrauch freigegeben|Shaun manuell ein|Shaun manuell aus|Shaun laed|Shaun aus|Eigenverbrauch gesperrt
attr Shaun_PV comment Version 2020.10.19 18:28
attr Shaun_PV do always
attr Shaun_PV group PV Eigenverbrauch-Steuerung
attr Shaun_PV icon scene_robo_lawnmower
attr Shaun_PV room Strom->Photovoltaik
attr Shaun_PV sortby 41
attr Shaun_PV stateFormat state : Shaun_Status
attr Shaun_PV verbose 0
attr Shaun_PV wait 0:0:0:[Shaun:PowerLevelMinTime]:0:30:0:60:30
</syntaxhighlight>
==== RAW Definition Shaun_Signale (Shelly Modul: shelly2.5) ====
Für die Ladung der Accus wird hier das Relais 0 verwendet.
<syntaxhighlight lang="Perl">
defmod shelly05 Shelly <IP-Address>
attr shelly05 DbLogExclude .*
attr shelly05 DbLogInclude relay.*,power.*,energy.*
attr shelly05 alias Brunnen und Shaun
attr shelly05 comment Version 2020.10.19 18:28
attr shelly05 event-on-change-reading relay.*,power.*,energy.*,state,network
attr shelly05 group PV Eigenverbrauch-Steuerung
attr shelly05 icon taster_ch_1
attr shelly05 interval 60
attr shelly05 mode relay
attr shelly05 model shelly2.5
attr shelly05 room Shelly,Strom->Photovoltaik
attr shelly05 sortby 32
attr shelly05 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
Status: %s<br>\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Brunnen Gesamt 0: %08.2f KWh<br>\
Shaun Gesamt 1: %08.2f KWh\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
Relais 1: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
(ReadingsVal($name,"state","none") eq "OK") ? "<span style='color:#00FF00'>OK</span>":"<span style='color:#FF0000'>Error</span>",\
ReadingsVal($name,"WebLink","none"),\
ReadingsVal($name,"energy_0",0)/1000,\
ReadingsVal($name,"energy_1",0)/1000,\
(ReadingsVal($name,"relay_0","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power_0",0),\
(ReadingsVal($name,"relay_1","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power_1",0)\
)}
attr shelly05 userReadings WebLink:network { my $ip=ReadingsVal($NAME,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") }
attr shelly05 webCmd |
</syntaxhighlight>
==== RAW Definition Shaun_Counter (HourCounter Modul) ====
<syntaxhighlight lang="Perl">
defmod Shaun_Counter HourCounter shelly05:power_1:\s[0-9]{2,}(\.[0-9]{1,2})*$ shelly05:power_1:\s[0-9]{1}(\.[0-9]{1,2})*$
attr Shaun_Counter DbLogExclude .*
attr Shaun_Counter alias Shaun_Counter
attr Shaun_Counter comment Version 2020.10.19 18:28\
On und Off des Ladens werden direkt über den Shelly Stromverbrauch getriggert.
attr Shaun_Counter event-on-change-reading .*
attr Shaun_Counter group PV Eigenverbrauch-Steuerung
attr Shaun_Counter icon time_timer
attr Shaun_Counter interval 5
attr Shaun_Counter room Strom->Photovoltaik
attr Shaun_Counter sortby 43
attr Shaun_Counter verbose 0
</syntaxhighlight>

== Problemlösung ==
Hier könnt Ihr Eure Fragen loswerden.
* {{Link2Forum|Topic=114849|Message=0}} - Photovoltaik mit Eigenverbrauch Steuerung (Kostal Plenticore; KSEM; BYD HV)

== Projekte der FHEM-Community ==

* {{Link2Forum|Topic=102297|Message=958564}} - Photovoltaik mit Eigenverbrauch Steuerung (Kostal plenticore; EM410)
* {{Link2Forum|Topic=109875|Message=1038741}} - Kostal Plenticore Bilanz
* {{Link2Forum|Topic=108191|Message=1038741}} - Kostal Plenticore, EM410 (KSEM), BYD, Solarprognose, Forecast

* {{Link2Forum|Topic=53584}} - Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
* {{Link2Forum|Topic=45176}} - Neue Version von HTTPMOD mit neuen Features zum Testen

== Links ==

* [https://www.photovoltaikforum.com/thread/142261-programmatischer-lesender-und-schreibender-zugriff-auf-kostal-plenticore-z-b-min/?pageNo=1/ Zugriff mit Python auf den Plenticore]
* [https://www.photovoltaikforum.com/thread/144350-kostenlose-wetterprognose-pv-prognose-ertragsprogonse-mit-st%C3%BCndlicher-aufl%C3%B6sung/?pageNo=1/ Ertragsprognose mit DWD]
* [https://www.photovoltaikforum.com/thread/146383-eigenverbrauchssteuerung-verh%C3%A4lt-sich-mit-speicher-anders-als-ohne/?pageNo=1/ Eigenverbrauchssteuerung beim Plenticore]
* [https://github.com/kilianknoll/ Github Kilian DWD Forecast]
* [https://github.com/FL550/ Github FL550 DWD Forecast]

[[Kategorie:IP Components]]
[[Kategorie:Other Components]]
[[Kategorie:Energieerzeugungsmessung]]

Kostal Plenticore 10 Plus

2020-09-16T08:33:37Z

Plin53177: /* RAW Definition DWD_Forecast */

{{Infobox Hardware
|Bild=Kostal_Plenticore_10_Plus.jpg
|Bildbeschreibung=Kostal Plenticore 10 Plus
|HWProtocol=IP und RS485
|HWType=Hybrid Wechselrichter
|HWCategory=Wechselrichter
|HWComm=n/a
|HWChannels=n/a
|HWVoltage=400 V
|HWPowerConsumption=
|HWPoweredBy=3P AC
|HWSize=56,3x40,5x23,3 cm (BxHxT)
|HWDeviceFHEM=[[HTTPMOD]], [[Modbus]], [[Python3]]

|HWManufacturer=KOSTAL Solar Electric GmbH
}}
[[Bild:Plenticore FHEM 1.png|mini|900px|rechts|Die Diagramme im Überblick]]
[[Bild:Plenticore FHEM 2.png|mini|900px|rechts|Geräte Überblick mit manueller Schaltmöglichkeit]]
[[Bild:Plenticore FHEM 3.png|mini|900px|rechts|Steuerungsgeräte für die Schaltlogik]]
[[Bild:Plenticore FHEM 4.png|mini|900px|rechts|ReadingsGroup für die schnelle Parametereinstellung]]

Ein Hinweis allgemeiner Art: Die hier abgebildeten Code Stücke sind nicht ausschließlich durch mich entstanden. Ich bedanke mich für die Unterstützung und Bereitstellung vieler Einzelkomponenten durch Dritte. Der Einsatz ist auf eigene Gefahr und für etwaige Schäden wird keinerlei Haftung übernommen. Bitte beachtet bei der Hardware die Gewährleistungsbestimmungen und Vorgaben der Hersteller.

Der [[Kostal Plenticore 10 Plus]] [https://www.kostal-solar-electric.com/de-de/produkte/hybrid-wechselrichter/ Hersteller Link] ist ein Hybrid Wechselrichter mit IP-Konnektivität.

Er verfügt über einen LAN-Anschluss und ist auf die Steuerung via WebGUI des Herstellers ausgelegt. Weiterhin kann eine Abfrage mit Modbus/TCP oder auch über eine undokumentierte API erfolgen. Für die API bietet der Hersteller keinerlei Support!

== Voraussetzungen Energietechnik ==

Der Wechselrichter, der Speicher und der KSEM wurden durch einen Fachbetrieb installiert und konfiguriert. Die gesamte Anlage läuft fehlerfrei und wurde durch den Fachbetrieb abgenommen, sowie beim Netzbetreiber angemeldet.

== Geräte-Registrierung ==

Hierfür ist die Dokumentation des Herstellers heranzuziehen. Für eine Verlängerung der Gewährleistungszeit kann man den Plenticore im Herstellerportal registrieren. Dies ist jedoch für die Anbindung an FHEM nicht notwendig.

== Hersteller Dokumentation ==

Für Links auf dieser Wiki Seite wird keine Haftung übernommen. Die Inhalte unterliegen der Verantwortung der Firma Kostal.
* [https://www.kostal-solar-electric.com/de-de/service-und-support/smart-warranty/ Plenticore Plus - Verlängerung der Gewährleistungszeit]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/06/15/11/40/plenticore-plus_ba_de.pdf/ Plenticore Plus - Betriebsanleitung]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/04/12/08/26/plenticore-plus_kba.pdf/ Plenticore Plus - Kurzanleitung]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/04/12/08/26/db_plenticore-plus_de.pdf/ Plenticore Plus - Datenblatt]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/03/12/07/13/kostal_update_plenticore_piko_iq_011504581.swu/ Plenticore Plus - Software Update UI: 01.15.04581 FW: 01.43]

* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/08/30/08/53/ba_kostal_interface_modbus-tcp_sunspec.pdf/ Plenticore - Modbus\/ Sunspec]

* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/03/06/13/17/ksem-ba_de.pdf/ KSEM - Betriebsanleitung]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/03/06/13/17/ksem-db_de.pdf/ KSEM - Datenblatt]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2020/06/09/11/49/kostal_update_ksem_1_2_1.zip/ KSEM - Software Update - 1.2.1]

* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/05/09/13/57/ba_kostal_interface_ksem---201911.pdf/ KSEM - Modbus\/ Sunspec]

* [https://www.kostal-solar-electric.com/de-de/service-und-support/kontakt/ Kostal - Service Kontakt]

== Einbindung in das Netzwerk ==

Als Grundlage ist der Plenticore mit dem LAN zu verbinden, wodurch er eine TCP/IP Adresse per DHCP bekommt. Diese ist dann entweder am Display des Plenticore abzulesen, oder über die Oberfläche des Routers zu ermitteln.

Das gleiche gilt für den BYD Speicher, der jedoch zusätzlich auch über WLAN verfügt. Eine Netzwerkanbindung des Speichers ist beim Plenticore nicht zwingend notwendig, da der Plenticore mit dem Speicher über eine RS-485 Schnittstelle kommuniziert. Bei dieser Anbindung werden jedoch noch nicht alle möglichen Werte aus dem Speicher ausgelesen. Später wird hierzu jedoch noch mehr geschrieben, um alle Möglichkeiten offen zu halten.

Der KSEM kann ebenfalls auch direkt per LAN ausgelesen werden, was jedoch ebenfalls nicht zwingend notwendig ist. Eine Kommunikation des KSEM mit dem Plenticore erfolgt über zwei mögliche Wege. Beim Betrieb mit Speicher ist zwingend die RS485 Schnittstelle erforderlich, über die auch der Plenticore alle Werte übermittelt bekommt. Auch diese sind dann am Plenticore abfragbar. Der zweite Weg wäre dann über die LAN Verbindung, bei der jedoch kein Speicher am Plenticore konfigurierbar ist.

== Voraussetzungen FHEM Umfeld ==

=== Alle Geräte müssen mit TCP/IP erreichbar sein ===

=== Alle Module sollten auf einem aktuellen Stand sein ===

=== Python ===

==== Ein Python 3 sollte vorhanden sein ====
Wenn man die erweiterten Funktionalitäten, wie Statistiken, Speicher auslesen und später auch das Setzen von Werten im Plenticore, verwenden möchte.

==== Es müssen folgende Python Module vorhanden sein ====
<syntaxhighlight lang="Perl">
python3-pip

pip3 install pycryptodome
pip3 install -U fhem
</syntaxhighlight>
=== Eine LogDB/LogDBRep sollte bereits vorhanden sein, was hier nicht weiter erklärt wird. ===

=== Verwendete Module ===
<pre>
- Modbus
- HTTPMOD
- expandJSON
- DbLog
- DbRep
- dummy
- Shelly
- HourCounter
- readingsGroup
</pre>

== Einbindung in FHEM: Überblick ==

=== Hardware Anbindung (alles über LAN) ===

==== Kostal Plenticore Plus ====
===== Kostal Plenticore Plus die Basis information (Modbus/TCP) =====
Der Kostal Plenticore wird mittels des Moduls MODBUS eingebunden. Dazu gilt zunächst die folgende Konfiguration als Basis, die am Display des Plenticore oder auch in der Kostal Dokumentation zu entnehmen ist.
====== Plenticore Modbus Definition ======
<pre>
GeräteId : 71
IP-Adresse: <IP-Adresse>
Port : 1502
</pre>

====== Modbus Timing ======
Das Gerät aktualisiert sich im Abstand von 60 Sekunden durch den stetigen Modbus/TCP Datenstrom. Der Plenticore ist als Modbus Master implementiert und sendet somit alle Daten permanent ins Netzwerk.

Die Zeit kann auch verändert werden, jedoch sollte sie nicht zu kurz gewählt sein.

====== RAW Definition des konfigurations Dummy ======
Diese Dummy soll alle Konfigurationsparameter halten, auf die dann die anderen Geräte Definitionen zentral zugreifen. Hier können auch default Namen und Vorschläge für Werte in Form von Slidern und Auswahllisten hinterlegt werden.
<syntaxhighlight lang="Perl">
defmod PV_Anlage_1_config dummy
attr PV_Anlage_1_config DbLogExclude .*
attr PV_Anlage_1_config alias PV_Anlage_1_config
attr PV_Anlage_1_config comment Steht das reading module_*_count auf 0 wird diese Ausrichtung nicht berücksichtigt\
Passworte zu dieser Konfiguration liegen im Dateiverzeichnis ~./python/pwd_*.json\
\
Korrekturkurven:\
Steilheit Parallel\
verschiebung\
tempk -0.39 25\
cloudk -0.65 0\
raink -0.30 0\
Der Slider für die Steilheit wird mit - k/100 umgerechnet. 39 ==> -0.39
attr PV_Anlage_1_config event-on-change-reading .*
attr PV_Anlage_1_config group PV Eigenverbrauch
attr PV_Anlage_1_config icon solar_icon
attr PV_Anlage_1_config readingList IP-Address_Plenticore IP-Address_BYD IP-Address_KSEM IP-Address_FHEM module_1_active module_2_active module_3_active module_1_name module_2_name module_3_name module_1_direction module_2_direction module_3_direction module_1_count module_2_count module_3_count module_1_power module_2_power module_3_power module_1_plain module_2_plain module_3_plain forecast_cloudk forecast_cloudk_base forecast_raink forecast_raink_base forecast_tempk forecast_tempk_base forecast_factor Forecast_Station Battery_Total_Power
attr PV_Anlage_1_config room Strom->Photovoltaik
attr PV_Anlage_1_config setList IP-Address_Plenticore IP-Address_BYD IP-Address_KSEM IP-Address_FHEM module_1_name:East,SouthEast,South,SouthWest,West,Garage,CarPort module_2_name:East,SouthEast,South,SouthWest,West module_3_name:East,SouthEast,South,SouthWest,West module_1_direction:slider,-90,5,+90 module_2_direction:slider,-90,5,90 module_3_direction:slider,-90,5,90 module_1_count:slider,0,1,40 module_2_count:slider,0,1,40 module_3_count:slider,0,1,40 module_1_power:slider,250,10,400 module_2_power:slider,250,10,400 module_3_power:slider,250,10,400 module_1_plain:slider,15,1,45 module_2_plain:slider,15,1,45 module_3_plain:slider,15,1,45 forecast_cloudk:slider,0,1,100 forecast_cloudk_base:slider,0,1,10 forecast_raink:slider,0,1,100 forecast_raink_base:slider,0,1,10 forecast_tempk:slider,0,1,100 forecast_tempk_base:slider,10,1,30 forecast_factor:1,1.5,2,2.5,3,3.5,4,4.5,5 Forecast_Station Battery_Total_Power
attr PV_Anlage_1_config sortby 06
attr PV_Anlage_1_config verbose 0

setstate PV_Anlage_1_config state
setstate PV_Anlage_1_config 2020-09-11 07:12:49 Battery_Total_Power 8960
setstate PV_Anlage_1_config 2020-09-11 07:36:39 Forecast_Station <Station>
setstate PV_Anlage_1_config 2020-08-31 12:44:46 IP-Address_BYD 192.168.178.10
setstate PV_Anlage_1_config 2020-08-31 12:39:26 IP-Address_FHEM 192.168.178.11
setstate PV_Anlage_1_config 2020-08-31 12:43:27 IP-Address_KSEM 192.168.178.12
setstate PV_Anlage_1_config 2020-08-31 12:39:44 IP-Address_Plenticore 192.168.178.13
setstate PV_Anlage_1_config 2020-09-02 18:39:15 forecast_cloudk 20
setstate PV_Anlage_1_config 2020-09-03 11:43:57 forecast_cloudk_base 0
setstate PV_Anlage_1_config 2020-09-02 18:40:29 forecast_raink 20
setstate PV_Anlage_1_config 2020-09-01 12:52:40 forecast_raink_base 0
setstate PV_Anlage_1_config 2020-09-01 12:46:57 forecast_tempk 39
setstate PV_Anlage_1_config 2020-09-01 12:50:06 forecast_tempk_base 25
setstate PV_Anlage_1_config 2020-08-31 12:27:30 module_1_count 0
setstate PV_Anlage_1_config 2020-08-31 12:27:38 module_1_direction -90
setstate PV_Anlage_1_config 2020-08-31 12:27:48 module_1_name East
setstate PV_Anlage_1_config 2020-08-31 12:29:42 module_1_plain 40
setstate PV_Anlage_1_config 2020-08-31 12:31:09 module_1_power 300
setstate PV_Anlage_1_config 2020-08-31 12:31:21 module_2_count 0
setstate PV_Anlage_1_config 2020-08-31 12:33:55 module_2_direction 0
setstate PV_Anlage_1_config 2020-08-31 12:34:03 module_2_name South
setstate PV_Anlage_1_config 2020-08-31 12:34:14 module_2_plain 40
setstate PV_Anlage_1_config 2020-08-31 12:34:25 module_2_power 300
setstate PV_Anlage_1_config 2020-08-31 12:34:42 module_3_count 0
setstate PV_Anlage_1_config 2020-08-31 12:34:50 module_3_direction 90
setstate PV_Anlage_1_config 2020-08-31 12:35:00 module_3_name West
setstate PV_Anlage_1_config 2020-08-31 12:35:08 module_3_plain 40
setstate PV_Anlage_1_config 2020-08-31 12:35:16 module_3_power 300
</syntaxhighlight>

====== RAW Definition des Wechselrichters ======
<syntaxhighlight lang="Perl">
defmod PV_Anlage_1 ModbusAttr 71 60 <IP-Address_Plenticore>:1502 TCP
attr PV_Anlage_1 DbLogExclude .*
attr PV_Anlage_1 DbLogInclude Act_state_of_charge,Actual_battery_charge_-minus_or_discharge_-plus_Power,Actual_battery_charge_usable_Power,Battery_temperature,Home_own_consumption_from_PV,Home_own_consumption_from_battery,Home_own_consumption_from_grid,Inverter_state,Power_DC1,Power_DC2,Power_DC_Sum,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Voltage_DC1,Voltage_DC2,.*_yield,Solar_.*
attr PV_Anlage_1 alias PV_Einspeisung
attr PV_Anlage_1 comment Kostal Plenticore 10 Plus mit BYD Speicher
attr PV_Anlage_1 dev-h-defFormat %.2f
attr PV_Anlage_1 dev-h-defLen 2
attr PV_Anlage_1 dev-h-defPoll 1
attr PV_Anlage_1 dev-h-defRevRegs 1
attr PV_Anlage_1 dev-h-defUnpack f>
attr PV_Anlage_1 dev-type-STR-format %s
attr PV_Anlage_1 dev-type-STR-len 8
attr PV_Anlage_1 dev-type-STR-revRegs 0
attr PV_Anlage_1 dev-type-STR-unpack a*
attr PV_Anlage_1 event-on-change-reading Act_state_of_charge,Actual_battery_charge_.*,Battery_temperature,Home_own_consumption_from_.*,Inverter_state,Power_DC1,Power_DC2,Power_DC_Sum,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Voltage_DC1,Voltage_DC2,.*_yield,Solar_.*
attr PV_Anlage_1 group PV Eigenverbrauch
attr PV_Anlage_1 icon sani_solar
attr PV_Anlage_1 obj-h100-reading Total_DC_Power
attr PV_Anlage_1 obj-h104-format %s
attr PV_Anlage_1 obj-h104-reading State_of_energy_manager
attr PV_Anlage_1 obj-h104-revRegs 0
attr PV_Anlage_1 obj-h104-unpack N
attr PV_Anlage_1 obj-h106-reading Home_own_consumption_from_battery
attr PV_Anlage_1 obj-h108-reading Home_own_consumption_from_grid
attr PV_Anlage_1 obj-h110-reading Total_home_consumption_Battery
attr PV_Anlage_1 obj-h112-reading Total_home_consumption_Grid
attr PV_Anlage_1 obj-h114-reading Total_home_consumption_PV
attr PV_Anlage_1 obj-h116-reading Home_own_consumption_from_PV
attr PV_Anlage_1 obj-h118-reading Total_home_consumption
attr PV_Anlage_1 obj-h120-reading Isolation_resistance
attr PV_Anlage_1 obj-h122-reading Power_limit_from_EVU
attr PV_Anlage_1 obj-h124-reading Total_home_consumption_rate
attr PV_Anlage_1 obj-h14-reading Inverter_serial_number
attr PV_Anlage_1 obj-h14-type STR
attr PV_Anlage_1 obj-h144-reading Worktime
attr PV_Anlage_1 obj-h150-reading Actual_cos_phi
attr PV_Anlage_1 obj-h152-reading Grid_frequency
attr PV_Anlage_1 obj-h154-reading Current_Phase_1
attr PV_Anlage_1 obj-h156-reading Active_power_Phase_1
attr PV_Anlage_1 obj-h158-reading Voltage_Phase_1
attr PV_Anlage_1 obj-h160-reading Current_Phase_2
attr PV_Anlage_1 obj-h162-reading Active_power_Phase_2
attr PV_Anlage_1 obj-h164-reading Voltage_Phase_2
attr PV_Anlage_1 obj-h166-reading Current_Phase_3
attr PV_Anlage_1 obj-h168-reading Active_power_Phase_3
attr PV_Anlage_1 obj-h170-reading Voltage_Phase_3
attr PV_Anlage_1 obj-h172-reading Total_AC_active_power
attr PV_Anlage_1 obj-h174-reading Total_AC_reactive_power
attr PV_Anlage_1 obj-h178-reading Total_AC_apparent_power
attr PV_Anlage_1 obj-h190-reading Battery_charge_current
attr PV_Anlage_1 obj-h194-format %.0f
attr PV_Anlage_1 obj-h194-reading Number_of_battery_cycles
attr PV_Anlage_1 obj-h200-reading Actual_battery_charge_-minus_or_discharge_-plus_current
attr PV_Anlage_1 obj-h202-reading PSSB_fuse_state
attr PV_Anlage_1 obj-h208-format %.0f
attr PV_Anlage_1 obj-h208-reading Battery_ready_flag
attr PV_Anlage_1 obj-h210-reading Act_state_of_charge
attr PV_Anlage_1 obj-h212-reading Battery_state
attr PV_Anlage_1 obj-h214-reading Battery_temperature
attr PV_Anlage_1 obj-h216-reading Battery_voltage
attr PV_Anlage_1 obj-h218-reading Cos_phi_(powermeter)
attr PV_Anlage_1 obj-h220-reading Frequency_(powermeter)
attr PV_Anlage_1 obj-h222-reading Current_phase_1_(powermeter)
attr PV_Anlage_1 obj-h224-reading Active_power_phase_1_(powermeter)
attr PV_Anlage_1 obj-h226-reading Reactive_power_phase_1_(powermeter)
attr PV_Anlage_1 obj-h228-reading Apparent_power_phase_1_(powermeter)
attr PV_Anlage_1 obj-h230-reading Voltage_phase_1_(powermeter)
attr PV_Anlage_1 obj-h232-reading Current_phase_2_(powermeter)
attr PV_Anlage_1 obj-h234-reading Active_power_phase_2_(powermeter)
attr PV_Anlage_1 obj-h236-reading Reactive_power_phase_2_(powermeter)
attr PV_Anlage_1 obj-h238-reading Apparent_power_phase_2_(powermeter)
attr PV_Anlage_1 obj-h240-reading Voltage_phase_2_(powermeter)
attr PV_Anlage_1 obj-h242-reading Current_phase_3_(powermeter)
attr PV_Anlage_1 obj-h244-reading Active_power_phase_3_(powermeter)
attr PV_Anlage_1 obj-h246-reading Reactive_power_phase_3_(powermeter)
attr PV_Anlage_1 obj-h248-reading Apparent_power_phase_3_(powermeter)
attr PV_Anlage_1 obj-h250-reading Voltage_phase_3_(powermeter)
attr PV_Anlage_1 obj-h252-reading Total_active_power_(powermeter)
attr PV_Anlage_1 obj-h254-reading Total_reactive_power_(powermeter)
attr PV_Anlage_1 obj-h256-reading Total_apparent_power_(powermeter)
attr PV_Anlage_1 obj-h258-reading Current_DC1
attr PV_Anlage_1 obj-h260-reading Power_DC1
attr PV_Anlage_1 obj-h266-reading Voltage_DC1
attr PV_Anlage_1 obj-h268-reading Current_DC2
attr PV_Anlage_1 obj-h270-reading Power_DC2
attr PV_Anlage_1 obj-h276-reading Voltage_DC2
attr PV_Anlage_1 obj-h278-reading Current_DC3
attr PV_Anlage_1 obj-h280-reading Power_DC3
attr PV_Anlage_1 obj-h286-reading Voltage_DC3
attr PV_Anlage_1 obj-h320-reading Total_yield
attr PV_Anlage_1 obj-h322-reading Daily_yield
attr PV_Anlage_1 obj-h324-reading Yearly_yield
attr PV_Anlage_1 obj-h326-reading Monthly_yield
attr PV_Anlage_1 obj-h38-reading Software-Version_Maincontroller_(MC)
attr PV_Anlage_1 obj-h38-type STR
attr PV_Anlage_1 obj-h384-len 16
attr PV_Anlage_1 obj-h384-reading Inverter_network_name
attr PV_Anlage_1 obj-h384-type STR
attr PV_Anlage_1 obj-h420-reading IP-address
attr PV_Anlage_1 obj-h420-type STR
attr PV_Anlage_1 obj-h428-reading IP-subnetmask
attr PV_Anlage_1 obj-h428-type STR
attr PV_Anlage_1 obj-h436-reading IP-gateway
attr PV_Anlage_1 obj-h436-type STR
attr PV_Anlage_1 obj-h446-reading IP-DNS1
attr PV_Anlage_1 obj-h446-type STR
attr PV_Anlage_1 obj-h454-reading IP-DNS2
attr PV_Anlage_1 obj-h454-type STR
attr PV_Anlage_1 obj-h46-reading Software-Version_IO-Controller_(IOC)
attr PV_Anlage_1 obj-h46-type STR
attr PV_Anlage_1 obj-h514-len 1
attr PV_Anlage_1 obj-h514-reading Battery_actual_SOC
attr PV_Anlage_1 obj-h517-reading Battery_Manufacturer
attr PV_Anlage_1 obj-h517-type STR
attr PV_Anlage_1 obj-h525-format %c
attr PV_Anlage_1 obj-h525-reading Battery_Model_ID
attr PV_Anlage_1 obj-h525-unpack N
attr PV_Anlage_1 obj-h527-format %c
attr PV_Anlage_1 obj-h527-reading Battery_Serial_Number
attr PV_Anlage_1 obj-h529-len 4
attr PV_Anlage_1 obj-h529-reading Work_Capacity
attr PV_Anlage_1 obj-h529-unpack N
attr PV_Anlage_1 obj-h531-format %.0f
attr PV_Anlage_1 obj-h531-reading Inverter_Max_Power
attr PV_Anlage_1 obj-h531-unpack N
attr PV_Anlage_1 obj-h535-revRegs 0
attr PV_Anlage_1 obj-h535-unpack n
attr PV_Anlage_1 obj-h551-revRegs 0
attr PV_Anlage_1 obj-h559-revRegs 0
attr PV_Anlage_1 obj-h56-format %.0f
attr PV_Anlage_1 obj-h56-reading Inverter_state
attr PV_Anlage_1 obj-h56-unpack N
attr PV_Anlage_1 obj-h575-len 1
attr PV_Anlage_1 obj-h575-reading Inverter_Generation_Power_(actual)
attr PV_Anlage_1 obj-h577-len 2
attr PV_Anlage_1 obj-h577-reading Generation_Energy
attr PV_Anlage_1 obj-h577-unpack N
attr PV_Anlage_1 obj-h578-reading Total_energy
attr PV_Anlage_1 obj-h582-reading Actual_battery_charge-discharge_power
attr PV_Anlage_1 obj-h586-format %s
attr PV_Anlage_1 obj-h586-reading Battery_Firmware
attr PV_Anlage_1 obj-h586-unpack N
attr PV_Anlage_1 obj-h588-format %s
attr PV_Anlage_1 obj-h588-len 1
attr PV_Anlage_1 obj-h588-reading Battery_Type
attr PV_Anlage_1 obj-h588-unpack N
attr PV_Anlage_1 obj-h6-reading Inverter_article_number
attr PV_Anlage_1 obj-h6-type STR
attr PV_Anlage_1 obj-h768-len 32
attr PV_Anlage_1 obj-h768-reading Productname
attr PV_Anlage_1 obj-h768-type STR
attr PV_Anlage_1 obj-h800-len 32
attr PV_Anlage_1 obj-h800-reading Power_class
attr PV_Anlage_1 obj-h800-type STR
attr PV_Anlage_1 room Strom->Photovoltaik
attr PV_Anlage_1 sortby 01
attr PV_Anlage_1 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TH ALIGN=\"MIDDLE\" WIDTH=\"20\">Batterie %s</TH>\
<TH ALIGN=\"MIDDLE\" WIDTH=\"20\">aktuell</TH>\
<TH ALIGN=\"RIGHT\" WIDTH=\"20\">Hausverbrauch</TH>\
<TH ALIGN=\"MIDDLE\" WIDTH=\"20\">Erträge</TH>\
</TR>\
\
<TR>\
<TD ALIGN=\"MIDDLE\" WIDTH=\"20\">\
Leistung: %04d W<br>\
Temp.: %02.1f °C<br>\
Ladung total: %2d %%<br>\
Ladung Res.: %04d Wh\
</TD>\
\
<TD ALIGN=\"RIGHT\" WIDTH=\"20\">\
DC total: %05d W<br>\
<br>\
<br>\
PV reserve: %05d W\
</TD>\
\
<TD ALIGN=\"RIGHT\" WIDTH=\"20\">\
von PV: %05d W <br>\
von Batterie: %05d W<br>\
vom Netz: %05d W<br>\
ins Haus: %05d W<br>\
Netz: %05d W\
</TD>\
\
<TD ALIGN=\"RIGHT\" WIDTH=\"20\">\
Tag: %05d KWh <br>\
Monat: %05d KWh<br>\
Jahr: %05d KWh<br>\
Total: %05d KWh\
</TD>\
</TR>\
\
</TABLE>\
" , \
(ReadingsVal($name,"Actual_battery_charge_-minus_or_discharge_-plus_Power",0) lt 0) ? "<span style='color:#00FF00'>Laden</span>":"<span style='color:#FF0000'>Entladen</span>" ,\
\
ReadingsVal($name,"Actual_battery_charge_-minus_or_discharge_-plus_Power",0),\
ReadingsVal($name,"Battery_temperature",0) ,\
ReadingsVal($name,"Act_state_of_charge",0) ,\
ReadingsVal($name,"Actual_battery_charge_usable_Power",0) ,\
\
ReadingsVal($name,"Power_DC_Sum","0"),\
ReadingsVal($name,"Total_PV_Power_reserve","0"),\
\
ReadingsVal($name,"Home_own_consumption_from_PV",0) ,\
ReadingsVal($name,"Home_own_consumption_from_battery",0) ,\
ReadingsVal($name,"Home_own_consumption_from_grid",0),\
ReadingsVal($name,"Home_own_consumption_from_PV",0) +ReadingsVal($name,"Home_own_consumption_from_battery",0)+ReadingsVal($name,"Home_own_consumption_from_grid",0),\
ReadingsVal($name,"Total_active_power_(powermeter)",0),\
\
round(ReadingsVal($name,"Daily_yield",0)/1000 ,0),\
round(ReadingsVal($name,"Monthly_yield",0)/1000 ,0) ,\
round(ReadingsVal($name,"Yearly_yield",0)/1000 ,0) ,\
round(ReadingsVal($name,"Total_yield",0)/1000 ,0)\
)}
attr PV_Anlage_1 userReadings Power_DC_Sum:Total_DC_Power.* { ReadingsVal($NAME,"Power_DC1","0")+ReadingsVal($NAME,"Power_DC2","0") },\
\
Total_PV_Power_reserve:Total_DC_Power.* {my $reserve = ReadingsVal($NAME,"Power_DC_Sum","0") * 0.90 - ReadingsVal($NAME,"Home_own_consumption_from_PV","0");;;; ($reserve lt 0)?0:round($reserve,3) },\
\
Total_DC_Power_Max:Total_DC_Power.* { my $Bat_out = (ReadingsVal($NAME,"Actual_battery_charge_-minus_or_discharge_-plus_current","0")*ReadingsVal($NAME,"Battery_voltage","0"));;;; ($Bat_out gt 0)?ReadingsVal($NAME,"Power_DC_Sum","0") + $Bat_out :ReadingsVal($NAME,"Power_DC_Sum","0") },\
\
Actual_battery_charge_-minus_or_discharge_-plus_Power:Actual_battery_charge_-minus_or_discharge_-plus_current.* {round((ReadingsVal($NAME,"Actual_battery_charge_-minus_or_discharge_-plus_current","0")*ReadingsVal($NAME,"Battery_voltage","0")),0)},\
\
Actual_battery_charge_usable_Power:Act_state_of_charge.* {my $x = (ReadingsVal($NAME."_config",Battery_Total_Power","0")*(ReadingsVal($NAME,"Act_state_of_charge","0")-10)/100);;;; ($x lt 0)?0:round($x,0) }
attr PV_Anlage_1 verbose 0
</syntaxhighlight>

====== Userreadings ======
Um später einige Abfragen und Diagramme einfacher zu erstellen wurden einige userreadings erstellt, die bereits bei der RAW Definition mit vorhanden sind. Während der Integration in FHEM und der Konfiguration kann es hierdurch jedoch noch Fehlermeldungen im FHEM Log geben, da noch nicht alle Werte vorhanden sind. Dies betrifft insbesondere die Statistics_* readings, die durch ein Python Skript später erzeugt werden.

Power_DC_Sum
Trigger: Total_DC_Power.*
Dies berechnet direkt die Summe der DC-Leistung. Wenn der Plenticore einen Speicher hat, wird dieser am String 3 angeschlossen,
sollte also kein Speicher vorhanden sein muss man hier den dritten String auch noch addieren.
Total_PV_Power_reserve
Trigger: Total_DC_Power.*
Hier wird ein reading erstellt, dass als Information über die verwendbare Reserve dient. Die Leistung, die in den Speicher geht
sollte man nämlich besser sofort verbrauchen, anstatt es erst zu speicher. Die 0.90 ist ein circa Wirkungsgrad, um von DC- auf AC-Leistung zu kommen.
Der Total_PV_Power_reserve Wert kann gerne nach eigenen Belangen kalkuliert werden.
Total_DC_Power_Max
Trigger: Total_DC_Power.*
Um die Batterieleistung mit zu berücksichtigen wird dieser Momentan Wert ermittelt.
Actual_battery_charge_-minus_or_discharge_-plus_Power
Trigger: Actual_battery_charge_-minus_or_discharge_-plus_current.*
Berechnung der Batterie Leistung aus Spannung und Strom , der wert kann positiv oder negativ sein, je nach dem ob geladen oder entladen wird.
Actual_battery_charge_usable_Power
Trigger: Act_state_of_charge.*
Dieser Wert gibt an, wieviel Leistung im Speicher vorhanden ist, reduziert um 10% Verluste. An dieser Stelle muss die Nennleistung des Speichers über das PV_Anlage_1_config Gerät
eingetragen werden, da diese noch nicht ausgelesen werden kann. Obwohl es im "Battery_Type 892941625" stecken könnte. 8929 >> 8.93 KW ???

===== Kostal Plenticore Plus die API (über HTTPMOD mit Python Skript Authentifizierung) =====
Der Plenticore erstellt intern noch diverse Statistiken, die auch über das WebGUI angesehen werden können. Diese werden jedoch nicht über MODBUS/TCP ausgegeben, aber zum Kostal Portal übermittelt, wo man dann bereits in Form von Diagrammen einen schönen Überblick bekommt. Das Ziel ist jedoch die Statistiken lokal im FHEM abzulegen, sie lassen sich nur über die API des Plenticore abfragen.
Für diesen API Zugang über HTTP steht nun ein neues Gerät zur Verfügung, dass mit HTTPMOD und Python Authentifizierungsskripten die mehrstufige Anmeldung durchführt. Das ganze soll in Zukunft den starren Zugriff auf die Statistiken ablösen und eine Erweiterung zum setzen von Parametern im Plenticore bieten.

====== Umstellungsaufwand, falls jemand früher eingestiegen ist. ======
Die erste Folge für den Umstieg ist, dass die Statistiken nicht mehr im PV_Anlage_1 Gerät abgelegt werden, da diese ja teil der API Abfrage sind. Das muss dann in der Bilanz berücksichtigt werden, da die Einträge dann unter dem neuen PV_Anlage_1_API Gerät abgelegt werden.

2020.09.06 Die Umstellung auf das Plenticore API Gerät hat begonnen

- Die Bilanz RAW Definition wurde aktualisiert

- In der PV_Schedule Definition wurde das Kommando für die Aktualisierung der Statistik auf PV_Anlage_1_API umgestellt

- Das Logging von Dum.Energy läuft wie gehabt weiter

- Die Statistic_* readings aus dem PV_Anlage_1 Gerät können in der SQL Datenbank zum neuen PV_Anlage_1_API Gerät verschoben werden.
<syntaxhighlight lang="SQL">
## Bitte zuerst den Zeitraum, in dem die Statistikeinträge in die Datenbank geschrieben wurden feststellen.
MySQL [fhem]> SELECT TIMESTAMP,DEVICE,READING,VALUE FROM history WHERE DEVICE='PV_Anlage_1_API' AND READING LIKE 'Statistic_%' AND TIMESTAMP > '2020-07-01 00:00:00' ORDER BY TIMESTAMP LIMIT 500;
## Für den Update dann din Zeitraum so weit es geht einschränken, damit die Laufzeit in der Datenbank nicht so hoch wird.
MySQL [fhem]> UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API' WHERE DEVICE='PV_Anlage_1' AND READING LIKE 'Statistic_%' AND TIMESTAMP > '2020-07-01 00:00:00';
</syntaxhighlight>
- Die alten Statistic_* readings können nun aus dem PV_Anlage_1 Gerät entfernt werden
<syntaxhighlight lang="Perl">
deletereading PV_Anlage_1 Statistic_.*
deletereading PV_Anlage_1 statistics_.*
</syntaxhighlight>
- Für das Logging kann nun im Attribut "DbLogInclude" ebenfalls "Statistic_.*" entfernt werden

- Beim Attribut "event-on-change-reading" sind auch "statistics_.*,Statistic_.*" zu entfernen

- Das userreading im PV_Anlage_1 kann ebenfalls geändert werden und um diese Zeile verkürzt werden.
<syntaxhighlight lang="Perl">
statistics_clean:statistics_output.* { my $x = ReadingsVal($NAME,"statistics_output",0);; $x =~ s/"moduleid": "scb:statistic:EnergyFlow", |, "moduleid": "scb:statistic:EnergyFlow"|"processdata": \[//g;; $x =~ s/id": "|, "unit": "", "value"|^\[|\]\}\]$//g;; $x =~ s/moduleid/statistics_00_moduleid/g;; $x =~ s/processdata/statistics/g;; $x =~ s/\}\, \{/\, /g;; $x =~ s/\{\{/\{/g;; return $x }
</syntaxhighlight>
- Nun noch das Gerät Plenticore_Statistics für das expandJSON löschen
<syntaxhighlight lang="Perl">
delete Plenticore_Statistics
</syntaxhighlight>
Das sollten nun alle erforderlichen Bereinigungen für den Wechsel auf das PV_Anlage_1_API Gerät sein.

====== Plenticore API ======
<syntaxhighlight lang="Perl">
http://<IP-Address_Plenticore>/api/v1
</syntaxhighlight>

====== Dateiverzeichnis ======
<pre>
/opt/fhem
/opt/fhem/python/pwd_fhem.json
/opt/fhem/python/pwd_plenticore.json
/opt/fhem/python/bin
/opt/fhem/python/bin/plenticore_auth_finish.py
/opt/fhem/python/bin/plenticore_auth_session.py
</pre>

====== Python 3 ======
<pre>
fhem@raspberrypi:~/python/bin$ which python3
/usr/bin/python3
fhem@raspberrypi:~/python/bin$ python3 --version
Python 3.7.3
</pre>

====== Passworte ======
Die Passworte für den Plenticore und den FHEM Zugang liegen in einzelnen JSON Dateien

fhem@raspberrypi:~/python$ cat pwd_plenticore.json
<pre>
{
"username": "user",
"password": "<Steht auf dem Gehäuse>"
}
</pre>

fhem@raspberrypi:~/python$ cat pwd_fhem.json
<pre>
{
"username": "<Ein Fhem Telnet User>",
"password": "<Das Passwort des Users>"
}
</pre>

====== plenticore_auth_* Erläuterung ======
Die folgenden beiden Skripte sind ein Extrakt aus den bisherigen Skripten, ohne die HTTP Aufrufe. Sie dienen nur noch der Generierung von Authentifizierungsschlüsseln. Optimaler Weise müssten sie auch noch nach Perl konvertiert werden, was für später geplant ist.
Als Übergabeparameter werden aus dem PV_Anlage_1_API Gerät Rückgabewerte der HTTP Aufrufe verwendet.

====== plenticore_auth_finish ======
fhem@raspberrypi:~/python/bin$ cat plenticore_auth_finish.py
<syntaxhighlight lang="Python">
import string
import base64
import hashlib
import hmac
from Crypto.Cipher import AES
import binascii

import sys
import json
import fhem

web = sys.argv[1]
randomString = sys.argv[2]
nonce = sys.argv[3]
salt = sys.argv[4]
rounds = sys.argv[5]

try:
with open('/opt/fhem/python/pwd_plenticore.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

PASSWD = credentials["password"]

u = randomString

#u = base64.b64encode(u.encode('utf-8')).decode('utf-8')
#print("randomString: ",u)

i = nonce
o = int(rounds)
a = salt
bitSalt = base64.b64decode(a)

#print("nonce : ",i)
#print("salt : ",a)
#print("rounds : ",o)

def getPBKDF2Hash(password, bytedSalt, rounds):
return hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), bytedSalt, rounds)

r = getPBKDF2Hash(PASSWD,bitSalt,o)
s = hmac.new(r, "Client Key".encode('utf-8'), hashlib.sha256).digest()
c = hmac.new(r, "Server Key".encode('utf-8'), hashlib.sha256).digest()
_ = hashlib.sha256(s).digest()
d = "n=user,r="+u+",r="+i+",s="+a+",i="+str(o)+",c=biws,r="+i
g = hmac.new(_, d.encode('utf-8'), hashlib.sha256).digest()
p = hmac.new(c, d.encode('utf-8'), hashlib.sha256).digest()
f = bytes(a ^ b for (a, b) in zip(s, g))
proof = base64.b64encode(f).decode('utf-8')

try:
with open('/opt/fhem/python/pwd_fhem.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

fh = fhem.Fhem(web, protocol="http", port=8083, username=credentials["username"], password=credentials["password"])

fh.send_cmd("setreading PV_Anlage_1_API auth_proof " + proof)

#print("proof : ",proof)
</syntaxhighlight>
====== plenticore_auth_session ======
fhem@raspberrypi:~/python/bin$ cat plenticore_auth_session.py
<syntaxhighlight lang="Python">
import string
import base64
import hashlib
import os
import hmac
from Crypto.Cipher import AES
import binascii

import sys
import json
import fhem

web = sys.argv[1]
randomString = sys.argv[2]
nonce = sys.argv[3]
salt = sys.argv[4]
rounds = sys.argv[5]
token = sys.argv[6]

try:
with open('/opt/fhem/python/pwd_plenticore.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

PASSWD = credentials["password"]

u = randomString
i = nonce
o = int(rounds)
a = salt
bitSalt = base64.b64decode(a)

def getPBKDF2Hash(password, bytedSalt, rounds):
return hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), bytedSalt, rounds)

r = getPBKDF2Hash(PASSWD,bitSalt,o)

#print("randomString: ",u)
#print("nonce : ",i)
#print("salt : ",a)
#print("rounds : ",o)
#print("token : ",token)

s = hmac.new(r, "Client Key".encode('utf-8'), hashlib.sha256).digest()
_ = hashlib.sha256(s).digest()
d = "n=user,r="+u+",r="+i+",s="+a+",i="+str(o)+",c=biws,r="+i

y = hmac.new(_, "Session Key".encode('utf-8'), hashlib.sha256)
y.update(d.encode('utf-8'))
y.update(s)
P = y.digest()
protocol_key = P
t = os.urandom(16)

e2 = AES.new(protocol_key,AES.MODE_GCM,t)
e2, authtag = e2.encrypt_and_digest(token.encode('utf-8'))

iv = base64.b64encode(t).decode('utf-8')
authtag = base64.b64encode(authtag).decode("utf-8")
payload = base64.b64encode(e2).decode('utf-8')

try:
with open('/opt/fhem/python/pwd_fhem.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

fh = fhem.Fhem(web, protocol="http", port=8083, username=credentials["username"], password=credentials["password"])

fh.send_cmd("setreading PV_Anlage_1_API auth_iv " + iv)
fh.send_cmd("setreading PV_Anlage_1_API auth_authtag " + authtag)
fh.send_cmd("setreading PV_Anlage_1_API auth_payload " + payload)

#print("iv : ",iv)
#print("authtag : ",authtag)
#print("payload : ",payload)
</syntaxhighlight>

====== Ablaufbeschreibung PV_Anlage_1_API ======
Hier soll ein kurzer Überblick für den Anmeldeablauf geschaffen werden.
======Automatischer Login mit Sessionaufbau======
Der Ablauf startet mit dem ersten Aufruf und läuft dann vollautomatisch bis zur Rückgabe der auth_sessionId
1. get PV_Anlage_1_API 01/auth/start
* auth_randomString64 - wird generiert
* /api/v1/auth/start - HTTP request erfolgt
* auth_nonce, auth_salt, auth_rounds werden empfangen
2. auth_Step1_Message:auth_nonce.* wird getriggert
* plenticore_auth_finish.py wird ausgeführt
* auth_proof - wird berechnet
3. auth_Step2_Message:auth_proof.* wird getriggert
* Start von 02_/auth/finish
4. get PV_Anlage_1_API 02_/auth/finish
* /api/v1/auth/finish - HTTP request erfolgt
* auth_signature, auth_token werden empfangen
5. auth_Step3_Message:auth_token.* wird getriggert
* plenticore_auth_session.py wird ausgeführt
* auth_iv, auth_authtag, auth_payload - wird berechnet
6. auth_Step4_Message:auth_payload.* wird getriggert
* Start von 03_/auth/session
7. get PV_Anlage_1_API 03_/auth/session
* /api/v1/auth/session - HTTP request erfolgt
* auth_sessionId wird empfangen

Bei allen folgenden HTTP requests wird nun die erhaltene auth_sessenId übermittelt.

Bereits Implementierte Abfragen:

get:

start, finish, create_session werden für den Login benötigt und arbeiten über userreadings mit zwei Python Skripten zusammen

01_/auth/start

02_/auth/finish

03_/auth/create_session

Auskunft über den Anmeldezustand, es muss aber kurz vorher abgefragt werden

04_/auth/me

Informationen zum Plenticore

05_/info/version

Abfrage der Statistiken

20_/processdata/scb_statistic_EnergyFlow

Liste aller Plenticore Module. Es werden keine readings erzeugt. Das Ergebnis steht im httpbody, der mit attr <Device> showBody 1 angezeigt werden kann.

21_/modules_list

Hier gibt es viele technische Loggings. Sollte es Probleme beim Abholen der Daten geben kann es am timeout liegen

24_/logdata/download

Speicher Typen wurden folgende ermittelt 0=keine , 4=BYD

Diese Abfragewerte können auch gesetzt werden, siehe set Befehle

31_Battery_Type

32_Battery_MinHomeComsumption

33_Battery_Strategy

34_Battery_MinSoc

35_Battery_SmartBatteryControl_Enable

36_Battery_DynamicSoc_Enable

Das zeigt den FW Update Status beim FW Laden an. Die Rückmeldung ist im httpbody zu sehen, es werden keine readings erzeugt.

41_/update/status

set:

Eine bestehende Session wird abgemeldet

06_/auth/logout

Die letzten Events können in deutsch oder englisch abgeholt werden

23_/events/latest_5 [en-gb,de-de]

Batterie Einstellungen können verändert werden. Es werden einige Werte vorgeschlagen. Bitte vorher immer den aktuellen Wert abfragen und besser aufschreiben!

Hier sollte nur etwas gesetzt werden, wenn man sich sicher ist, was man tut.

31_Battery_Type [0,4]

32_Battery_MinHomeComsumption

33_Battery_Strategy

34_Battery_MinSoc

35_Battery_SmartBatteryControl_Enable

36_Battery_DynamicSoc_Enable

Der Reboot läuft noch nicht. Da ist die API ziemlich zickig. Ich habe jedoch bereits ein Skript, womit es geht :-)

51_/system/reboot

Sollte die Session abgelaufen, oder noch kein Login vollzogen worden sein, so wird automatisch eine Login mit Sessionaufbau durchgeführt.

====== RAW Definition des PV_Anlage_1_API ======
<syntaxhighlight lang="Perl">
defmod PV_Anlage_1_API HTTPMOD http://%IP-Address_Plenticore%/api/v1/auth/me 0

attr PV_Anlage_1_API DbLogExclude .*
attr PV_Anlage_1_API DbLogInclude Statistic_.*
attr PV_Anlage_1_API authRetries 1
attr PV_Anlage_1_API dontRequeueAfterAuth 1
attr PV_Anlage_1_API enableControlSet 0
attr PV_Anlage_1_API enableCookies 1
attr PV_Anlage_1_API get01Data {"nonce": "%randomString64%","username": "user"}
attr PV_Anlage_1_API get01Name 01_/auth/start
attr PV_Anlage_1_API get01URL http://%IP-Address_Plenticore%/api/v1/auth/start
attr PV_Anlage_1_API get02-1Name auth_signature
attr PV_Anlage_1_API get02-2Name auth_token
attr PV_Anlage_1_API get02Data {"transactionId": "%auth_transactionId%", "proof": "%auth_proof%"}
attr PV_Anlage_1_API get02JSON .
attr PV_Anlage_1_API get02Name 02_/auth/finish
attr PV_Anlage_1_API get02URL http://%IP-Address_Plenticore%/api/v1/auth/finish
attr PV_Anlage_1_API get03Data {"transactionId": "%auth_transactionId%", "iv": "%auth_iv%", "tag": "%auth_authtag%", "payload": "%auth_payload%"}
attr PV_Anlage_1_API get03Name 03_/auth/create_session
attr PV_Anlage_1_API get03URL http://%IP-Address_Plenticore%/api/v1/auth/create_session
attr PV_Anlage_1_API get04-1Name auth_me_active
attr PV_Anlage_1_API get04-2Name auth_me_locked
attr PV_Anlage_1_API get04-3Name auth_me_authenticated
attr PV_Anlage_1_API get04-4Name auth_me_anonymous
attr PV_Anlage_1_API get04-5Name auth_me_role
attr PV_Anlage_1_API get04-6Name auth_me_permissions
attr PV_Anlage_1_API get04Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get04JSON .
attr PV_Anlage_1_API get04Name 04_/auth/me
attr PV_Anlage_1_API get04URL http://%IP-Address_Plenticore%/api/v1/auth/me
attr PV_Anlage_1_API get05-1Name info_name
attr PV_Anlage_1_API get05-2Name info_api_version
attr PV_Anlage_1_API get05-3Name info_sw_version
attr PV_Anlage_1_API get05-4Name info_hostname
attr PV_Anlage_1_API get05JSON .
attr PV_Anlage_1_API get05Name 05_/info/version
attr PV_Anlage_1_API get05URL http://%IP-Address_Plenticore%/api/v1/info/version
attr PV_Anlage_1_API get20-10Name Statistic_EnergyHome_Month
attr PV_Anlage_1_API get20-11Name Statistic_EnergyHome_Total
attr PV_Anlage_1_API get20-12Name Statistic_EnergyHome_Year
attr PV_Anlage_1_API get20-13Name Statistic_EnergyHomeBat_Day
attr PV_Anlage_1_API get20-14Name Statistic_EnergyHomeBat_Month
attr PV_Anlage_1_API get20-15Name Statistic_EnergyHomeBat_Total
attr PV_Anlage_1_API get20-16Name Statistic_EnergyHomeBat_Year
attr PV_Anlage_1_API get20-17Name Statistic_EnergyHomeGrid_Day
attr PV_Anlage_1_API get20-18Name Statistic_EnergyHomeGrid_Month
attr PV_Anlage_1_API get20-19Name Statistic_EnergyHomeGrid_Total
attr PV_Anlage_1_API get20-1Name Statistic_Autarky_Day
attr PV_Anlage_1_API get20-20Name Statistic_EnergyHomeGrid_Year
attr PV_Anlage_1_API get20-21Name Statistic_EnergyHomePv_Day
attr PV_Anlage_1_API get20-22Name Statistic_EnergyHomePv_Month
attr PV_Anlage_1_API get20-23Name Statistic_EnergyHomePv_Total
attr PV_Anlage_1_API get20-24Name Statistic_EnergyHomePv_Year
attr PV_Anlage_1_API get20-25Name Statistic_OwnConsumptionRate_Day
attr PV_Anlage_1_API get20-26Name Statistic_OwnConsumptionRate_Month
attr PV_Anlage_1_API get20-27Name Statistic_OwnConsumptionRate_Total
attr PV_Anlage_1_API get20-28Name Statistic_OwnConsumptionRate_Year
attr PV_Anlage_1_API get20-29Name Statistic_Yield_Day
attr PV_Anlage_1_API get20-2Name Statistic_Autarky_Month
attr PV_Anlage_1_API get20-30Name Statistic_Yield_Month
attr PV_Anlage_1_API get20-31Name Statistic_Yield_Total
attr PV_Anlage_1_API get20-32Name Statistic_Yield_Year
attr PV_Anlage_1_API get20-3Name Statistic_Autarky_Total
attr PV_Anlage_1_API get20-4Name Statistic_Autarky_Year
attr PV_Anlage_1_API get20-5Name Statistic_CO2Saving_Day
attr PV_Anlage_1_API get20-6Name Statistic_CO2Saving_Month
attr PV_Anlage_1_API get20-7Name Statistic_CO2Saving_Total
attr PV_Anlage_1_API get20-8Name Statistic_CO2Saving_Year
attr PV_Anlage_1_API get20-9Name Statistic_EnergyHome_Day
attr PV_Anlage_1_API get20Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get20JSON 01_processdata_.._value
attr PV_Anlage_1_API get20Name 20_/processdata/scb_statistic_EnergyFlow
attr PV_Anlage_1_API get20URL http://%IP-Address_Plenticore%/api/v1/processdata/scb:statistic:EnergyFlow
attr PV_Anlage_1_API get21Name 21_/modules_list
attr PV_Anlage_1_API get21URL http://%IP-Address_Plenticore%/api/v1/modules
attr PV_Anlage_1_API get24Data {"end":"%end_date%","begin":"%begin_date%"}
attr PV_Anlage_1_API get24Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get24Header02 Content-type: application/json, Accept: application/json, Connection: keep-alive
attr PV_Anlage_1_API get24Name 24_/logdata/download
attr PV_Anlage_1_API get24URL http://%IP-Address_Plenticore%/api/v1/logdata/download
attr PV_Anlage_1_API get31-1Name Battery_Type
attr PV_Anlage_1_API get31-2Name Battery_Type
attr PV_Anlage_1_API get31Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get31Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get31JSON .
attr PV_Anlage_1_API get31Name 31_Battery_Type
attr PV_Anlage_1_API get31URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:Type
attr PV_Anlage_1_API get32-1Name Battery_MinHomeComsumption
attr PV_Anlage_1_API get32-2Name Battery_MinHomeComsumption
attr PV_Anlage_1_API get32Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get32Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get32JSON .
attr PV_Anlage_1_API get32Name 32_Battery_MinHomeComsumption
attr PV_Anlage_1_API get32URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:MinHomeComsumption
attr PV_Anlage_1_API get33-1Name Battery_Strategy
attr PV_Anlage_1_API get33-2Name Battery_Strategy
attr PV_Anlage_1_API get33Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get33Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get33JSON .
attr PV_Anlage_1_API get33Name 33_Battery_Strategy
attr PV_Anlage_1_API get33URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:Strategy
attr PV_Anlage_1_API get34-1Name Battery_MinSoc
attr PV_Anlage_1_API get34-2Name Battery_MinSoc
attr PV_Anlage_1_API get34Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get34Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get34JSON .
attr PV_Anlage_1_API get34Name 34_Battery_MinSoc
attr PV_Anlage_1_API get34URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:MinSoc
attr PV_Anlage_1_API get35-1Name Battery_SmartBatteryControl_Enable
attr PV_Anlage_1_API get35-2Name Battery_SmartBatteryControl_Enable
attr PV_Anlage_1_API get35Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get35Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get35JSON .
attr PV_Anlage_1_API get35Name 35_Battery_SmartBatteryControl_Enable
attr PV_Anlage_1_API get35URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:SmartBatteryControl:Enable
attr PV_Anlage_1_API get36-1Name Battery_DynamicSoc_Enable
attr PV_Anlage_1_API get36-2Name Battery_DynamicSoc_Enable
attr PV_Anlage_1_API get36Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get36Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get36JSON .
attr PV_Anlage_1_API get36Name 36_Battery_DynamicSoc_Enable
attr PV_Anlage_1_API get36URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:DynamicSoc:Enable
attr PV_Anlage_1_API get41Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get41Name 41_/update/status
attr PV_Anlage_1_API get41URL http://%IP-Address_Plenticore%/api/v1/update/status
attr PV_Anlage_1_API getHeader01 Accept-Encoding: gzip,deflate
attr PV_Anlage_1_API getHeader02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API group PV Eigenverbrauch
attr PV_Anlage_1_API icon sani_solar
attr PV_Anlage_1_API reAuthRegex "authenticated":false|"processdata":\[\]|wrong credentials
attr PV_Anlage_1_API reading01-1Name auth_nonce
attr PV_Anlage_1_API reading01-2Name auth_rounds
attr PV_Anlage_1_API reading01-3Name auth_salt
attr PV_Anlage_1_API reading01-4Name auth_transactionId
attr PV_Anlage_1_API reading01JSON .
attr PV_Anlage_1_API reading02JSON sessionId
attr PV_Anlage_1_API reading02Name auth_sessionId
attr PV_Anlage_1_API reading0301JSON message
attr PV_Anlage_1_API reading0301Name info_message
attr PV_Anlage_1_API reading0302JSON error
attr PV_Anlage_1_API reading0302Name info_error
attr PV_Anlage_1_API replacement01Mode expression
attr PV_Anlage_1_API replacement01Regex %IP-Address_Plenticore%
attr PV_Anlage_1_API replacement01Value {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")}
attr PV_Anlage_1_API replacement02Mode reading
attr PV_Anlage_1_API replacement02Regex %auth_transactionId%
attr PV_Anlage_1_API replacement02Value auth_transactionId
attr PV_Anlage_1_API replacement03Mode reading
attr PV_Anlage_1_API replacement03Regex %auth_proof%
attr PV_Anlage_1_API replacement03Value auth_proof
attr PV_Anlage_1_API replacement04Mode expression
attr PV_Anlage_1_API replacement04Regex %randomString64%
attr PV_Anlage_1_API replacement04Value {my $NAME = "PV_Anlage_1_API" ;;;;fhem("deletereading ".$NAME." message");;;;fhem("deletereading ".$NAME." auth.*");;;;my @chars=('a'..'z','A'..'Z','0'..'9');; my $r;; foreach(1..16) {$r.=$chars[rand @chars];;};;;; fhem("setreading ".$NAME." auth_randomString64 ".$r);;;; $r;;;;}
attr PV_Anlage_1_API replacement05Mode reading
attr PV_Anlage_1_API replacement05Regex %auth_randomString64%
attr PV_Anlage_1_API replacement05Value auth_randomString64
attr PV_Anlage_1_API replacement06Mode reading
attr PV_Anlage_1_API replacement06Regex %auth_token%
attr PV_Anlage_1_API replacement06Value auth_token
attr PV_Anlage_1_API replacement07Mode reading
attr PV_Anlage_1_API replacement07Regex %auth_signature%
attr PV_Anlage_1_API replacement07Value auth_signature
attr PV_Anlage_1_API replacement08Mode reading
attr PV_Anlage_1_API replacement08Regex %auth_authtag%
attr PV_Anlage_1_API replacement08Value auth_authtag
attr PV_Anlage_1_API replacement09Mode reading
attr PV_Anlage_1_API replacement09Regex %auth_payload%
attr PV_Anlage_1_API replacement09Value auth_payload
attr PV_Anlage_1_API replacement10Mode reading
attr PV_Anlage_1_API replacement10Regex %auth_iv%
attr PV_Anlage_1_API replacement10Value auth_iv
attr PV_Anlage_1_API replacement11Mode reading
attr PV_Anlage_1_API replacement11Regex %auth_sessionId%
attr PV_Anlage_1_API replacement11Value auth_sessionId
attr PV_Anlage_1_API replacement12Mode expression
attr PV_Anlage_1_API replacement12Regex %begin_date%
attr PV_Anlage_1_API replacement12Value {POSIX::strftime("%Y-%m-%d",localtime(time))}
attr PV_Anlage_1_API replacement13Mode expression
attr PV_Anlage_1_API replacement13Regex %end_date%
attr PV_Anlage_1_API replacement13Value {POSIX::strftime("%Y-%m-%d",localtime(time))}
attr PV_Anlage_1_API room Strom->Photovoltaik
attr PV_Anlage_1_API set06Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set06Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set06Method POST
attr PV_Anlage_1_API set06Name 06_/auth/logout
attr PV_Anlage_1_API set06NoArg 1
attr PV_Anlage_1_API set06URL http://%IP-Address_Plenticore%/api/v1/auth/logout
attr PV_Anlage_1_API set23-10Name Event_02_code
attr PV_Anlage_1_API set23-11Name Event_02_description
attr PV_Anlage_1_API set23-12Name Event_02_end_time
attr PV_Anlage_1_API set23-13Name Event_02_group
attr PV_Anlage_1_API set23-14Name Event_02_is_active
attr PV_Anlage_1_API set23-15Name Event_02_long_description
attr PV_Anlage_1_API set23-16Name Event_02_start_time
attr PV_Anlage_1_API set23-17Name Event_03_category
attr PV_Anlage_1_API set23-18Name Event_03_code
attr PV_Anlage_1_API set23-19Name Event_03_description
attr PV_Anlage_1_API set23-1Name Event_01_category
attr PV_Anlage_1_API set23-20Name Event_03_end_time
attr PV_Anlage_1_API set23-21Name Event_03_group
attr PV_Anlage_1_API set23-22Name Event_03_is_active
attr PV_Anlage_1_API set23-23Name Event_03_long_description
attr PV_Anlage_1_API set23-24Name Event_03_start_time
attr PV_Anlage_1_API set23-25Name Event_04_category
attr PV_Anlage_1_API set23-26Name Event_04_code
attr PV_Anlage_1_API set23-27Name Event_04_description
attr PV_Anlage_1_API set23-28Name Event_04_end_time
attr PV_Anlage_1_API set23-29Name Event_04_group
attr PV_Anlage_1_API set23-2Name Event_01_code
attr PV_Anlage_1_API set23-30Name Event_04_is_active
attr PV_Anlage_1_API set23-31Name Event_04_long_description
attr PV_Anlage_1_API set23-32Name Event_04_start_time
attr PV_Anlage_1_API set23-33Name Event_05_category
attr PV_Anlage_1_API set23-34Name Event_05_code
attr PV_Anlage_1_API set23-35Name Event_05_description
attr PV_Anlage_1_API set23-36Name Event_05_end_time
attr PV_Anlage_1_API set23-37Name Event_05_group
attr PV_Anlage_1_API set23-38Name Event_05_is_active
attr PV_Anlage_1_API set23-39Name Event_05_long_description
attr PV_Anlage_1_API set23-3Name Event_01_description
attr PV_Anlage_1_API set23-40Name Event_05_start_time
attr PV_Anlage_1_API set23-4Name Event_01_end_time
attr PV_Anlage_1_API set23-5Name Event_01_group
attr PV_Anlage_1_API set23-6Name Event_01_is_active
attr PV_Anlage_1_API set23-7Name Event_01_long_description
attr PV_Anlage_1_API set23-8Name Event_01_start_time
attr PV_Anlage_1_API set23-9Name Event_02_category
attr PV_Anlage_1_API set23Data {"max":5,"language":"$val"}
attr PV_Anlage_1_API set23Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set23Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set23Hint en-gb,de-de
attr PV_Anlage_1_API set23JSON .
attr PV_Anlage_1_API set23Name 23_/events/latest_5
attr PV_Anlage_1_API set23ParseResponse 1
attr PV_Anlage_1_API set23TextArg 1
attr PV_Anlage_1_API set23URL http://%IP-Address_Plenticore%/api/v1/events/latest
attr PV_Anlage_1_API set31Data [{"moduleid":"devices:local","settings":[{"id":"Battery:Type","value":"$val"}]}]
attr PV_Anlage_1_API set31Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set31Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set31Hint 0,4
attr PV_Anlage_1_API set31Method PUT
attr PV_Anlage_1_API set31Name 31_Battery_Type
attr PV_Anlage_1_API set31URL http://%IP-Address_Plenticore%/api/v1/settings
attr PV_Anlage_1_API set33Data [{"moduleid":"devices:local","settings":[{"id":"Battery:Strategy","value":"$val"}]}]
attr PV_Anlage_1_API set33Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set33Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set33Hint 1,2
attr PV_Anlage_1_API set33Method PUT
attr PV_Anlage_1_API set33Name 31_Battery_Strategy
attr PV_Anlage_1_API set33URL http://%IP-Address_Plenticore%/api/v1/settings
attr PV_Anlage_1_API set34Data [{"moduleid":"devices:local","settings":[{"id":"Battery:MinSoc","value":"$val"}]}]
attr PV_Anlage_1_API set34Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set34Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set34Hint slider,10,5,100
attr PV_Anlage_1_API set34Method PUT
attr PV_Anlage_1_API set34Name 34_Battery_MinSoc
attr PV_Anlage_1_API set34URL http://%IP-Address_Plenticore%/api/v1/settings
attr PV_Anlage_1_API set35Data [{"moduleid":"devices:local","settings":[{"id":"Battery:SmartBatteryControl:Enable","value":"$val"}]}]
attr PV_Anlage_1_API set35Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set35Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set35Hint 0,1
attr PV_Anlage_1_API set35Method PUT
attr PV_Anlage_1_API set35Name 35_SmartBatteryControl_Enable
attr PV_Anlage_1_API set35URL http://%IP-Address_Plenticore%/api/v1/settings
attr PV_Anlage_1_API set51Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set51Header02 Accept: application/json, Connection: keep-alive, Content-type: application/json
attr PV_Anlage_1_API set51Method Post
attr PV_Anlage_1_API set51Name 51_/system/reboot
attr PV_Anlage_1_API set51NoArg 1
attr PV_Anlage_1_API set51URL http://%IP-Address_Plenticore%/api/v1/system/reboot
attr PV_Anlage_1_API showBody 1
attr PV_Anlage_1_API showError 1
attr PV_Anlage_1_API sid01Data {"nonce": "%randomString64%","username": "user"}
attr PV_Anlage_1_API sid01ParseResponse 1
attr PV_Anlage_1_API sid01URL http://%IP-Address_Plenticore%/api/v1/auth/start
attr PV_Anlage_1_API sidHeader01 Accept-Encoding: gzip,deflate
attr PV_Anlage_1_API sidHeader02 Content-type: application/json, Accept: application/json, Connection: keep-alive
attr PV_Anlage_1_API sortby 02
attr PV_Anlage_1_API timeout 7
attr PV_Anlage_1_API userReadings auth_first_called:auth_randomString64.* {my $first_called = InternalVal("$NAME","path","n.a");;;; $first_called =~ s/:/_/g;;;;$first_called ;;;;$first_called =~ s/\/api\/v1//g;;;; my %replace = ("/auth/me" => "04_/auth/me","/info/version" => "05_/info/version","/processdata/scb_statistic_EnergyFlow" => "20_/processdata/scb_statistic_EnergyFlow","/modules_list" => "21_/modules_list","/logdata/download" => "24_/logdata/download","/update/status" => "41_/update/status","/system/reboot" => "04_/auth/me",);;;; $replace{$first_called};;;;},\
\
auth_Step1_Message:auth_transactionId.* {system("/usr/bin/python3 /opt/fhem/python/bin/plenticore_auth_finish.py ".ReadingsVal("PV_Anlage_1_config","IP-Address_FHEM","")." ".ReadingsVal("$NAME","auth_randomString64","")." ".ReadingsVal("$NAME","auth_nonce","")." ".ReadingsVal("$NAME","auth_salt","")." ".ReadingsVal("$NAME","auth_rounds","29000")." &");;;; "Prepare auth_finish started with auth_nonce ".ReadingsVal("$NAME","auth_nonce","")},\
\
auth_Step2_Message:auth_proof.* { fhem("get ".$NAME." 02_/auth/finish") ;;;; "HTTP Request 02_/auth/finish with auth_proof ".ReadingsVal("$NAME","auth_proof","")},\
\
auth_Step3_Message:auth_token.* {system("/usr/bin/python3 /opt/fhem/python/bin/plenticore_auth_session.py ".ReadingsVal("PV_Anlage_1_config","IP-Address_FHEM","")." ".ReadingsVal("$NAME","auth_randomString64","")." ".ReadingsVal("$NAME","auth_nonce","")." ".ReadingsVal("$NAME","auth_salt","")." ".ReadingsVal("$NAME","auth_rounds","")." ".ReadingsVal("$NAME","auth_token","")." &");;;; "Prepare auth_session started with auth_token ".ReadingsVal("$NAME","auth_token","")},\
\
auth_Step4_Message:auth_payload.* { fhem("get ".$NAME." 03_/auth/create_session") ;;;; "HTTP Request 03_/auth/create_session with auth_authtag ".ReadingsVal("$NAME","auth_authtag","")},\
\
auth_Step5_Message:auth_sessionId.* {my $restack = ReadingsVal("$NAME","auth_first_called","") ;;;; ($restack != "")?fhem("get ".$NAME." ".$restack):"No further HTTP request";;;;}
attr PV_Anlage_1_API verbose 5
</syntaxhighlight>

=== Kostal Smart Energy Manager (KSEM) (Modbus/TCP) ===
Diese Einbindung ist nicht zwingend notwendig, jedoch weil es möglich ist hier beschrieben.
Das Gerät ist hier mit "disable 1" konfiguriert, um es zu verwenden muss das Attribut auf 0 gesetzt oder einfach gelöscht werden.

Auch hier ist ein Interval von 60 Sekunden gesetzt worden. Das Logging ist noch komplett deaktiviert, weshalb man seine Werte noch selber definieren muss.

==== RAW Definition des KSEM ====
Zun Thema KSEM bestand direkter Kontakt mit dem Kostal Service. Der KSEM ermittelt nicht alle Werte, welche in der SunSpec spezifiziert sind. Alle nicht unterstützen Werte sind in den Registern mit 0x8000 gekennzeichnet. Für die nicht unterstützten Zählerstände wird 0x800000000 ausgegeben.
Der Summenstrom M_AC_Current (sum of active phases) kann aber durch den Endanwender selber aus der Summe der Einzelwerte (Phase A AC current, Phase B AC current Phase C AC current) berechnet werden. Die einzelnen Spannungen zwischen den Phasen können nicht gemessen werden und werden deshalb nicht ausgegeben.
<syntaxhighlight lang="Perl">
defmod PV_KSEM ModbusAttr 1 60 <IP-Address_KSEM>:502 TCP
attr PV_KSEM DbLogExclude .*
attr PV_KSEM alias PV_Energy_Manager
attr PV_KSEM dev-h-defPoll 1
attr PV_KSEM dev-type-INT16-len 1
attr PV_KSEM dev-type-INT16-unpack s>
attr PV_KSEM dev-type-INT16_Current-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Current_SF",0))
attr PV_KSEM dev-type-INT16_Current-format %.2f
attr PV_KSEM dev-type-INT16_Current-len 1
attr PV_KSEM dev-type-INT16_Current-unpack s>
attr PV_KSEM dev-type-INT16_Freq-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Freq_SF",0))
attr PV_KSEM dev-type-INT16_Freq-format %.2f
attr PV_KSEM dev-type-INT16_Freq-len 1
attr PV_KSEM dev-type-INT16_Freq-unpack s>
attr PV_KSEM dev-type-INT16_PF-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_PF_SF",0))
attr PV_KSEM dev-type-INT16_PF-format %.2f
attr PV_KSEM dev-type-INT16_PF-len 1
attr PV_KSEM dev-type-INT16_PF-unpack s>
attr PV_KSEM dev-type-INT16_Power-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Power_SF",0))
attr PV_KSEM dev-type-INT16_Power-format %.2f
attr PV_KSEM dev-type-INT16_Power-len 1
attr PV_KSEM dev-type-INT16_Power-unpack s>
attr PV_KSEM dev-type-INT16_VA-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_VA_SF",0))
attr PV_KSEM dev-type-INT16_VA-format %.2f
attr PV_KSEM dev-type-INT16_VA-len 1
attr PV_KSEM dev-type-INT16_VA-unpack s>
attr PV_KSEM dev-type-INT16_VAR-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_VAR_SF",0))
attr PV_KSEM dev-type-INT16_VAR-format %.2f
attr PV_KSEM dev-type-INT16_VAR-len 1
attr PV_KSEM dev-type-INT16_VAR-unpack s>
attr PV_KSEM dev-type-INT16_Voltage-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Voltage_SF",0))
attr PV_KSEM dev-type-INT16_Voltage-format %.2f
attr PV_KSEM dev-type-INT16_Voltage-len 1
attr PV_KSEM dev-type-INT16_Voltage-unpack s>
attr PV_KSEM dev-type-STR32-expr $val =~ s/[\00]+//gr
attr PV_KSEM dev-type-STR32-format %s
attr PV_KSEM dev-type-STR32-len 16
attr PV_KSEM dev-type-STR32-unpack a*
attr PV_KSEM dev-type-UINT16-format %s
attr PV_KSEM dev-type-UINT16-len 1
attr PV_KSEM dev-type-UINT32-format %s
attr PV_KSEM dev-type-UINT32-len 2
attr PV_KSEM dev-type-UINT64-expr $val/10000
attr PV_KSEM dev-type-UINT64-format %s
attr PV_KSEM dev-type-UINT64-len 4
attr PV_KSEM dev-type-UINT64-unpack Q>
attr PV_KSEM disable 1
attr PV_KSEM group PV Eigenverbrauch
attr PV_KSEM icon measure_power
attr PV_KSEM obj-h40072-reading M_AC_Current_A
attr PV_KSEM obj-h40072-type INT16_Current
attr PV_KSEM obj-h40073-reading M_AC_Current_B
attr PV_KSEM obj-h40073-type INT16_Current
attr PV_KSEM obj-h40074-reading M_AC_Current_C
attr PV_KSEM obj-h40074-type INT16_Current
attr PV_KSEM obj-h40075-reading M_AC_Current_SF
attr PV_KSEM obj-h40075-type INT16
attr PV_KSEM obj-h40077-reading M_AC_Voltage_AN
attr PV_KSEM obj-h40077-type INT16_Voltage
attr PV_KSEM obj-h40078-reading M_AC_Voltage_BN
attr PV_KSEM obj-h40078-type INT16_Voltage
attr PV_KSEM obj-h40079-reading M_AC_Voltage_CN
attr PV_KSEM obj-h40079-type INT16_Voltage
attr PV_KSEM obj-h40084-reading M_AC_Voltage_SF
attr PV_KSEM obj-h40084-type INT16
attr PV_KSEM obj-h40085-reading M_AC_Freq
attr PV_KSEM obj-h40085-type INT16_Freq
attr PV_KSEM obj-h40086-reading M_AC_Freq_SF
attr PV_KSEM obj-h40086-type INT16
attr PV_KSEM obj-h40087-reading M_AC_Power
attr PV_KSEM obj-h40087-type INT16_Power
attr PV_KSEM obj-h40088-reading M_AC_Power_A
attr PV_KSEM obj-h40088-type INT16_Power
attr PV_KSEM obj-h40089-reading M_AC_Power_B
attr PV_KSEM obj-h40089-type INT16_Power
attr PV_KSEM obj-h40090-reading M_AC_Power_C
attr PV_KSEM obj-h40090-type INT16_Power
attr PV_KSEM obj-h40091-reading M_AC_Power_SF
attr PV_KSEM obj-h40091-type INT16
attr PV_KSEM obj-h40092-reading M_AC_VA
attr PV_KSEM obj-h40092-type INT16_VA
attr PV_KSEM obj-h40093-reading M_AC_VA_A
attr PV_KSEM obj-h40093-type INT16_VA
attr PV_KSEM obj-h40094-reading M_AC_VA_B
attr PV_KSEM obj-h40094-type INT16_VA
attr PV_KSEM obj-h40095-reading M_AC_VA_C
attr PV_KSEM obj-h40095-type INT16_VA
attr PV_KSEM obj-h40096-reading M_AC_VA_SF
attr PV_KSEM obj-h40096-type INT16
attr PV_KSEM obj-h40097-reading M_AC_VAR
attr PV_KSEM obj-h40097-type INT16_VAR
attr PV_KSEM obj-h40098-reading M_AC_VAR_A
attr PV_KSEM obj-h40098-type INT16_VAR
attr PV_KSEM obj-h40099-reading M_AC_VAR_B
attr PV_KSEM obj-h40099-type INT16_VAR
attr PV_KSEM obj-h40100-reading M_AC_VAR_C
attr PV_KSEM obj-h40100-type INT16_VAR
attr PV_KSEM obj-h40101-reading M_AC_VAR_SF
attr PV_KSEM obj-h40101-type INT16
attr PV_KSEM obj-h40102-reading M_AC_PF
attr PV_KSEM obj-h40102-type INT16_PF
attr PV_KSEM obj-h40103-reading M_AC_PF_A
attr PV_KSEM obj-h40103-type INT16_PF
attr PV_KSEM obj-h40104-reading M_AC_PF_B
attr PV_KSEM obj-h40104-type INT16_PF
attr PV_KSEM obj-h40105-reading M_AC_PF_C
attr PV_KSEM obj-h40105-type INT16_PF
attr PV_KSEM obj-h40106-reading M_AC_PF_SF
attr PV_KSEM obj-h40106-type INT16
attr PV_KSEM obj-h40108-reading M_Exported
attr PV_KSEM obj-h40108-type UINT32
attr PV_KSEM obj-h40110-reading M_Exported_A
attr PV_KSEM obj-h40110-type UINT32
attr PV_KSEM obj-h40112-reading M_Exported_B
attr PV_KSEM obj-h40112-type UINT32
attr PV_KSEM obj-h40114-reading M_Exported_C
attr PV_KSEM obj-h40114-type UINT32
attr PV_KSEM obj-h40116-reading M_Imported
attr PV_KSEM obj-h40116-type UINT32
attr PV_KSEM obj-h40118-reading M_Imported_A
attr PV_KSEM obj-h40118-type UINT32
attr PV_KSEM obj-h40120-reading M_Imported_B
attr PV_KSEM obj-h40120-type UINT32
attr PV_KSEM obj-h40122-reading M_Imported_C
attr PV_KSEM obj-h40122-type UINT32
attr PV_KSEM obj-h40125-reading M_Exported_VA
attr PV_KSEM obj-h40125-type UINT32
attr PV_KSEM obj-h40127-reading M_Exported_VA_A
attr PV_KSEM obj-h40127-type UINT32
attr PV_KSEM obj-h40129-reading M_Exported_VA_B
attr PV_KSEM obj-h40129-type UINT32
attr PV_KSEM obj-h40131-reading M_Exported_VA_C
attr PV_KSEM obj-h40131-type UINT32
attr PV_KSEM obj-h40133-reading M_Imported_VA
attr PV_KSEM obj-h40133-type UINT32
attr PV_KSEM obj-h40135-reading M_Imported_VA_A
attr PV_KSEM obj-h40135-type UINT32
attr PV_KSEM obj-h40137-reading M_Imported_VA_B
attr PV_KSEM obj-h40137-type UINT32
attr PV_KSEM obj-h40139-reading M_Imported_VA_C
attr PV_KSEM obj-h40139-type UINT32
attr PV_KSEM obj-h512-reading Active_energy+
attr PV_KSEM obj-h512-type UINT64
attr PV_KSEM obj-h516-reading Active_energy-
attr PV_KSEM obj-h516-type UINT64
attr PV_KSEM obj-h8192-reading ManufacturerID
attr PV_KSEM obj-h8192-type UINT16
attr PV_KSEM obj-h8193-reading ProductID
attr PV_KSEM obj-h8193-type UINT16
attr PV_KSEM obj-h8194-reading ProductVersion
attr PV_KSEM obj-h8194-type UINT16
attr PV_KSEM obj-h8195-reading FirmwareVersion
attr PV_KSEM obj-h8195-type UINT16
attr PV_KSEM obj-h8196-reading VendorName
attr PV_KSEM obj-h8196-type STR32
attr PV_KSEM obj-h8212-reading Productname
attr PV_KSEM obj-h8212-type STR32
attr PV_KSEM obj-h8228-reading SerialNumber
attr PV_KSEM obj-h8228-type STR32
attr PV_KSEM obj-h8244-reading MeasuringInterval
attr PV_KSEM obj-h8244-type UINT16
attr PV_KSEM room Strom->Photovoltaik
attr PV_KSEM sortby 03
attr PV_KSEM userReadings M_AC_Current:M_AC_Current_.* { ReadingsVal($NAME,"M_AC_Current_A",0) + ReadingsVal($NAME,"M_AC_Current_B",0) + ReadingsVal($NAME,"M_AC_Current_C",0) }
attr PV_KSEM verbose 0
</syntaxhighlight>

=== BYD Speicher (mit HTTPMOD) ===
Diese Einbindung ist nicht zwingend notwendig.
Das Passwort steht momentan noch im userreading .
==== RAW Definition BYD_Status ====
<syntaxhighlight lang="Perl">
defmod BYD_Status HTTPMOD http://%IP-Address_BYD%/asp/BatteryInformation.asp 0

attr BYD_Status DbLogExclude .*
attr BYD_Status authRetries 0
attr BYD_Status devStateIcon 100:measure_battery_100 \d:measure_battery_0 1\d.*:measure_battery_25 2\d.*:measure_battery_25 3\d.*:measure_battery_25 4\d.*:measure_battery_50 5\d.*:measure_battery_50 6\d.*:measure_battery_50 7\d.*:measure_battery_75 8\d.*:measure_battery_75 9\d.*:measure_battery_75
attr BYD_Status dontRequeueAfterAuth 1
attr BYD_Status enableControlSet 0
attr BYD_Status enableCookies 1
attr BYD_Status get01-101Name Array_Series_Battery_1_CellVol_09
attr BYD_Status get01-105Name Array_Series_Battery_1_CellVol_10
attr BYD_Status get01-109Name Array_Series_Battery_1_CellVol_11
attr BYD_Status get01-113Name Array_Series_Battery_1_CellVol_12
attr BYD_Status get01-117Name Array_Series_Battery_1_CellVol_13
attr BYD_Status get01-121Name Array_Series_Battery_1_CellVol_14
attr BYD_Status get01-125Name Array_Series_Battery_1_CellVol_15
attr BYD_Status get01-129Name Array_Series_Battery_1_CellVol_16
attr BYD_Status get01-133Name Array_Series_Battery_1_CellVolMax
attr BYD_Status get01-137Name Array_Series_Battery_1_CellVolMin
attr BYD_Status get01-13Name Array_Main_MinCellTemp
attr BYD_Status get01-141Name Array_Series_Battery_1_CellTemp_1
attr BYD_Status get01-145Name Array_Series_Battery_1_CellTemp_2
attr BYD_Status get01-149Name Array_Series_Battery_1_CellTemp_3
attr BYD_Status get01-14Name Array_Main_SOC
attr BYD_Status get01-153Name Array_Series_Battery_1_CellTemp_4
attr BYD_Status get01-17Name Array_Main_SysTemp
attr BYD_Status get01-1Name Array_Main_ArrayVoltage
attr BYD_Status get01-21Name Array_Main_MaxCellVol
attr BYD_Status get01-25Name Array_Main_MinCellVol
attr BYD_Status get01-29Name Array_Main_MaxCellTemp
attr BYD_Status get01-33Name Array_Main_MinCellTemp
attr BYD_Status get01-39Name Array_Main_MaxVolPos
attr BYD_Status get01-43Name Array_Main_MinVolPos
attr BYD_Status get01-47Name Array_Main_MaxTempPos
attr BYD_Status get01-51Name Array_Main_MinTempPos
attr BYD_Status get01-55Name Array_Main_Power
attr BYD_Status get01-56Name Array_Series_Battery_1_SerialNumber
attr BYD_Status get01-5Name Array_Main_PackVoltage
attr BYD_Status get01-60Name Array_Series_Battery_1_SerialNumber
attr BYD_Status get01-61Name Array_Series_Battery_1_BattVol
attr BYD_Status get01-65Name Array_Series_Battery_1_CellVolDiff
attr BYD_Status get01-69Name Array_Series_Battery_1_CellVol_01
attr BYD_Status get01-73Name Array_Series_Battery_1_CellVol_02
attr BYD_Status get01-77Name Array_Series_Battery_1_CellVol_03
attr BYD_Status get01-81Name Array_Series_Battery_1_CellVol_04
attr BYD_Status get01-85Name Array_Series_Battery_1_CellVol_05
attr BYD_Status get01-89Name Array_Series_Battery_1_CellVol_06
attr BYD_Status get01-93Name Array_Series_Battery_1_CellVol_07
attr BYD_Status get01-97Name Array_Series_Battery_1_CellVol_08
attr BYD_Status get01-9Name Array_Main_Current
attr BYD_Status get01MaxAge 900
attr BYD_Status get01MaxAgeReplacementMode delete
attr BYD_Status get01Name RunData
attr BYD_Status get01RegOpt g
attr BYD_Status get01Regex value=([+|-]{0,1}\d+.\d+)>|value=(\d+.\d+)%>|value=(\d)>|value=(.*-\d+\s+.*\d)>
attr BYD_Status get01URL http://%IP-Address_BYD%/asp/RunData.asp
attr BYD_Status get02-101Name Statistic_SpecificInformation_03_StartTime
attr BYD_Status get02-105Name Statistic_SpecificInformation_03_EndTime
attr BYD_Status get02-10Name Statistic_SpecificInformation_02_Type
attr BYD_Status get02-113Name Statistic_SpecificInformation_04_Type
attr BYD_Status get02-117Name Statistic_SpecificInformation_04_Ah
attr BYD_Status get02-11Name Statistic_SpecificInformation_02_Ah
attr BYD_Status get02-121Name Statistic_SpecificInformation_04_KWh
attr BYD_Status get02-125Name Statistic_SpecificInformation_04_EnvTemp
attr BYD_Status get02-129Name Statistic_SpecificInformation_04_BatTemp
attr BYD_Status get02-12Name Statistic_GeneralInformation_Total_Cycle_Counts
attr BYD_Status get02-133Name Statistic_SpecificInformation_04_StartTime
attr BYD_Status get02-137Name Statistic_SpecificInformation_04_EndTime
attr BYD_Status get02-13Name Statistic_SpecificInformation_02_EnvTemp
attr BYD_Status get02-145Name Statistic_SpecificInformation_05_Type
attr BYD_Status get02-149Name Statistic_SpecificInformation_05_Ah
attr BYD_Status get02-14Name Statistic_SpecificInformation_02_BatTemp
attr BYD_Status get02-153Name Statistic_SpecificInformation_05_KWh
attr BYD_Status get02-157Name Statistic_SpecificInformation_05_EnvTemp
attr BYD_Status get02-15Name Statistic_SpecificInformation_02_StartTime
attr BYD_Status get02-161Name Statistic_SpecificInformation_05_BatTemp
attr BYD_Status get02-165Name Statistic_SpecificInformation_05_StartTime
attr BYD_Status get02-169Name Statistic_SpecificInformation_05_EndTime
attr BYD_Status get02-16Name Statistic_SpecificInformation_02_EndTime
attr BYD_Status get02-17Name Statistic_SpecificInformation_01_Type
attr BYD_Status get02-18Name Statistic_SpecificInformation_03_Type
attr BYD_Status get02-19Name Statistic_SpecificInformation_03_Ah
attr BYD_Status get02-20Name Statistic_SpecificInformation_03_KWh
attr BYD_Status get02-21Name Statistic_SpecificInformation_01_Ah
attr BYD_Status get02-22Name Statistic_SpecificInformation_03_BatTemp
attr BYD_Status get02-23Name Statistic_SpecificInformation_03_StartTime
attr BYD_Status get02-24Name Statistic_SpecificInformation_03_EndTime
attr BYD_Status get02-25Name Statistic_SpecificInformation_01_KWh
attr BYD_Status get02-26Name Statistic_SpecificInformation_04_Type
attr BYD_Status get02-27Name Statistic_SpecificInformation_04_Ah
attr BYD_Status get02-28Name Statistic_SpecificInformation_04_KWh
attr BYD_Status get02-29Name Statistic_SpecificInformation_01_EnvTemp
attr BYD_Status get02-2Name Statistic_GeneralInformation_Total_Charge_Energy
attr BYD_Status get02-30Name Statistic_SpecificInformation_04_BatTemp
attr BYD_Status get02-31Name Statistic_SpecificInformation_04_StartTime
attr BYD_Status get02-32Name Statistic_SpecificInformation_04_EndTime
attr BYD_Status get02-33Name Statistic_SpecificInformation_01_BatTemp
attr BYD_Status get02-34Name Statistic_SpecificInformation_05_Type
attr BYD_Status get02-35Name Statistic_SpecificInformation_05_Ah
attr BYD_Status get02-36Name Statistic_SpecificInformation_05_KWh
attr BYD_Status get02-37Name Statistic_SpecificInformation_01_StartTime
attr BYD_Status get02-38Name Statistic_SpecificInformation_05_BatTemp
attr BYD_Status get02-39Name Statistic_SpecificInformation_05_StartTime
attr BYD_Status get02-3Name Statistic_SpecificInformation_01_Ah
attr BYD_Status get02-40Name Statistic_SpecificInformation_05_EndTime
attr BYD_Status get02-41Name Statistic_SpecificInformation_01_EndTime
attr BYD_Status get02-49Name Statistic_SpecificInformation_02_Type
attr BYD_Status get02-4Name Statistic_SpecificInformation_01_KWh
attr BYD_Status get02-53Name Statistic_SpecificInformation_02_Ah
attr BYD_Status get02-57Name Statistic_SpecificInformation_02_KWh
attr BYD_Status get02-5Name Statistic_SpecificInformation_01_EnvTemp
attr BYD_Status get02-61Name Statistic_SpecificInformation_02_EnvTemp
attr BYD_Status get02-65Name Statistic_SpecificInformation_02_BatTemp
attr BYD_Status get02-69Name Statistic_SpecificInformation_02_StartTime
attr BYD_Status get02-6Name Statistic_SpecificInformation_01_BatTemp
attr BYD_Status get02-73Name Statistic_SpecificInformation_02_EndTime
attr BYD_Status get02-7Name Statistic_GeneralInformation_Total_Discharge_Energy
attr BYD_Status get02-81Name Statistic_SpecificInformation_03_Type
attr BYD_Status get02-85Name Statistic_SpecificInformation_03_Ah
attr BYD_Status get02-89Name Statistic_SpecificInformation_03_KWh
attr BYD_Status get02-8Name Statistic_SpecificInformation_01_EndTime
attr BYD_Status get02-93Name Statistic_SpecificInformation_03_EnvTemp
attr BYD_Status get02-97Name Statistic_SpecificInformation_03_BatTemp
attr BYD_Status get02MaxAge 900
attr BYD_Status get02MaxAgeReplacementMode delete
attr BYD_Status get02Name StatisticInformation
attr BYD_Status get02RegOpt g
attr BYD_Status get02Regex <td class="text_l">(.*)<\/td>\n|Charge Energy:<\/td>\n.*>(\d+.\d+)|Discharge Energy:<\/td>\n.*>(\d+.\d+)|Cycle Counts:<\/td>\n.*>(\d+)
attr BYD_Status get02URL http://%IP-Address_BYD%/asp/StatisticInformation.asp
attr BYD_Status get03-10Name DeviceInformation_Machine_Version
attr BYD_Status get03-10OExpr {$val =~ s/\n//g;; $val}
attr BYD_Status get03-15Name DeviceInformation_Board_SN
attr BYD_Status get03-1Name DeviceInformation_Machine_SN
attr BYD_Status get03-20Name DeviceInformation_Board_Factory_time
attr BYD_Status get03-8Name DeviceInformation_Machine_Factory_time
attr BYD_Status get03Name DeviceInformation
attr BYD_Status get03RegOpt g
attr BYD_Status get03Regex >(\d{9}-\d{5})<|Version:<\/td>\n<td>(V\d.\d{3}\n [A-Z])<|>SN:<\/td>\n.*>([\d|\w]{18})<|(\d{4}-\d+-\d+ \d+:\d+:\d+)
attr BYD_Status get03URL http://%IP-Address_BYD%/asp/DeviceInformation.asp
attr BYD_Status get04-13Name BatteryInformation_SOC
attr BYD_Status get04-17Name BatteryInformation_SysTemp
attr BYD_Status get04-1Name BatteryInformation_TotalVoltage
attr BYD_Status get04-21Name BatteryInformation_MaxCellVol
attr BYD_Status get04-25Name BatteryInformation_MinCellVol
attr BYD_Status get04-29Name BatteryInformation_MaxCellTemp
attr BYD_Status get04-33Name BatteryInformation_MinCellTemp
attr BYD_Status get04-37Name BatteryInformation_Power
attr BYD_Status get04-42Name BatteryInformation_System_state
attr BYD_Status get04-47Name BatteryInformation_Date_and_Time
attr BYD_Status get04-52Name BatteryInformation_Alarm_state
attr BYD_Status get04-5Name BatteryInformation_PackVoltage
attr BYD_Status get04-9Name BatteryInformation_Current
attr BYD_Status get04MaxAge 900
attr BYD_Status get04MaxAgeReplacementMode delete
attr BYD_Status get04Name BatteryInformation
attr BYD_Status get04RegOpt g
attr BYD_Status get04Regex value=([+|-]{0,1}\d+.\d+)[%]{0,1}>|value=([A-Z]+)>|value="(\d{4}-\d+-\d+ \d+:\d+:\d+)"|Alarm state:<\/h3><\/td>\n<td>.*">(\w+\W)<\/font>
attr BYD_Status get04URL http://%IP-Address_BYD%/asp/Home.asp
attr BYD_Status getHeader01 Authorization: Digest username="installer", realm="%auth_realm%", nonce="%auth_nonce%", uri="/asp/RunData.asp", algorithm=MD5, response="%auth_response%", opaque="%auth_opaque%", qop="auth", nc=%auth_nc%, cnonce="%auth_cnonce%"
attr BYD_Status group PV Eigenverbrauch
attr BYD_Status httpVersion 1.1
attr BYD_Status icon measure_battery_100
attr BYD_Status reAuthRegex Unauthorized
attr BYD_Status reading01Name auth_qop
attr BYD_Status reading01Regex qop="(.*)", nonce
attr BYD_Status reading02Name auth_nonce
attr BYD_Status reading02Regex nonce="(.*)", opaque

attr BYD_Status reading03Name auth_opaque
attr BYD_Status reading03Regex opaque="(.*)",algorithm
attr BYD_Status reading04Name auth_realm
attr BYD_Status reading04Regex realm="(.*)", domain
attr BYD_Status replacement01Mode expression
attr BYD_Status replacement01Regex %IP-Address_BYD%
attr BYD_Status replacement01Value ReadingsVal("PV_Anlage_1_config","IP-Address_BYD","")
attr BYD_Status replacement03Mode reading
attr BYD_Status replacement03Regex %auth_realm%
attr BYD_Status replacement03Value auth_realm
attr BYD_Status replacement04Mode reading
attr BYD_Status replacement04Regex %auth_nonce%
attr BYD_Status replacement04Value auth_nonce
attr BYD_Status replacement05Mode reading
attr BYD_Status replacement05Regex %auth_response%
attr BYD_Status replacement05Value auth_response
attr BYD_Status replacement06Mode reading
attr BYD_Status replacement06Regex %auth_opaque%
attr BYD_Status replacement06Value auth_opaque
attr BYD_Status replacement07Mode reading
attr BYD_Status replacement07Regex %auth_nc%
attr BYD_Status replacement07Value auth_nc
attr BYD_Status replacement08Mode reading
attr BYD_Status replacement08Regex %auth_cnonce%
attr BYD_Status replacement08Value auth_cnonce
attr BYD_Status room Strom->Photovoltaik
attr BYD_Status showBody 1
attr BYD_Status showError 1
attr BYD_Status sid01Header Authorization: Digest username="installer", realm="%auth_realm%", nonce="%auth_nonce%", uri="/asp/RunData.asp", algorithm=MD5, response="%auth_response%", opaque="%auth_opaque%", qop=auth, nc=%auth_nc%, cnonce="%auth_cnonce%"
attr BYD_Status sid01ParseResponse 1
attr BYD_Status sid01URL http://%IP-Address_BYD%/asp/RunData.asp
attr BYD_Status sortby 02
attr BYD_Status stateFormat {round(ReadingsVal("BYD_Status","BatteryInformation_SOC",0),0)}
attr BYD_Status userReadings auth_first_called:auth_nonce.* {my $first_called = InternalVal("$NAME","path","n.a");;;; $first_called =~ s/:/_/g;;;;$first_called ;;;;$first_called =~ s/\/api\/v1//g;;;;;;;;$first_called},\
auth_HA1:auth_first_called.* {md5_hex("installer:".ReadingsVal($NAME,"auth_realm","").":<Password>")},\
auth_HA2:auth_HA1.* {md5_hex("GET:/asp/RunData.asp")},\
auth_response:auth_HA2.* {md5_hex(ReadingsVal($NAME,"auth_HA1","").":".ReadingsVal($NAME,"auth_nonce","").":".ReadingsVal($NAME,"auth_nc","").":".ReadingsVal($NAME,"auth_cnonce","").":".ReadingsVal($NAME,"auth_qop","").":".ReadingsVal($NAME,"auth_HA2",""))},\
auth_nc:auth_response.* {"00000001"},\
auth_cnonce:auth_response.* {"d789ea5b7e9a2377"},\
auth_Step1_Message:auth_nonce.* {"HTTP nonce updated"},\
Specific_Information_00_Date:Statistic_SpecificInformation_05_EndTime.* { fhem("deletereading ".$NAME." StatisticInformation.*");;;; localtime()}\
## auth_Step2_Message:auth_Step1_Message.* { fhem("get ".$NAME." RunData") ;;;; "HTTP Request RunData called" }\

attr BYD_Status verbose 0
</syntaxhighlight>

== Timeing für die PV extra Funktionen ==
=== RAW Definition PV_Schedule (DOIF) ===
<syntaxhighlight lang="Perl">
defmod PV_Schedule DOIF ################################################################################################################\
## 1 BYD Status aktualisieren\
##\
([+:06] and !([:00] or [:30]))\
(\
get BYD_Status RunData\
)\
################################################################################################################\
## 2 Plenticore Status aktualisieren. Dies geschieht über das PV_Anlage_1_API Device\
##\
DOELSEIF\
([:57])\
(\
get PV_Anlage_1_API 20_/processdata/scb_statistic_EnergyFlow\
)\
################################################################################################################\
## 3 PV Prognose vom aktuellen Tag aktualisieren\
## zwischen 7 und 19 Uhr zur vollen Stunde\
DOELSEIF\
([07:00-20:00] and [:00])\
(\
{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",0)}\
)\
################################################################################################################\
## 4 PV Prognose für den nächsten Tag aktualisieren\
## \
DOELSEIF\
([06:55] or [19:11])\
(\
{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",1)}\
)\
################################################################################################################\
## 5 regelmäßig die Bilanz aktualisieren\
##\
DOELSEIF\
([08:00-20:00] and [+:05] and ![:00]) ## Tagsüber alle 5 Minuten außer um :00\
(\
set Dum.Energy update\
)
attr PV_Schedule DbLogExclude .*
attr PV_Schedule alias PV_Schedule
attr PV_Schedule cmdState BYD Status|Plenticore Status
attr PV_Schedule do always
attr PV_Schedule room Strom->System
attr PV_Schedule sortby 11
attr PV_Schedule verbose 0
attr PV_Schedule wait 0:0:0:0:0
</syntaxhighlight>

== Energie Bilanz ==
[[Bild:Plenticore Bilanz.png|mini|900px|rechts|]]
Die Energie Bilanz soll einen kompakten Überblick über die Produktions und Verbrauchswerte Liefern. Hierbei werden die Momentanwerte direkt berechnet, die restlichen Werte werden als Statistiken aus dem Gerät abgefragt.
Die Aktualisierung erfolgt zyklisch über das Gerät PV_Schedule.
=== RAW Definition Energiebilanz ===
<syntaxhighlight lang="Perl">
defmod Dum.Energy dummy
attr Dum.Energy DbLogExclude .*
attr Dum.Energy DbLogInclude Autarky.*,GridFeed.*,PV.*,.*Consumption.*
attr Dum.Energy alias Energiebilanz
attr Dum.Energy comment TotalConsumption,AutarkyQuoteDay,SelfConsumptionQuoteDay,AutarkyQuoteMonth,SelfConsumptionQuoteMonth
attr Dum.Energy event-on-change-reading PV,GridConsumption,GridFeedIn,SelfConsumptionQuote,Autarky.*,GridFeed.*,PV.*,.*Consumption.*
attr Dum.Energy event-on-update-reading TotalConsumption,AutarkyQuoteDay,SelfConsumptionQuoteDay,AutarkyQuoteMonth,SelfConsumptionQuoteMonth
attr Dum.Energy group Energiebilanz
attr Dum.Energy icon measure_power_meter
attr Dum.Energy room Strom->Energie
attr Dum.Energy stateFormat {\
my $pvt = ReadingsVal("$name","PVTotal", "")." W";;\
my $pvtd = ReadingsVal("$name","PVTotalDay", "")." kWh";;\
my $pvtm = ReadingsVal("$name","PVTotalMonth", "")." kWh";;\
my $pvty = ReadingsVal("$name","PVTotalYear", "")." kWh";;\
\
my $pv = ReadingsVal("$name","PV", "")." W";;\
my $pvd = ReadingsVal("$name","PVDay", "")." kWh";;\
my $pvm = ReadingsVal("$name","PVMonth", "")." kWh";;\
my $pvy = ReadingsVal("$name","PVYear", "")." kWh";;\
\
my $gfi = ReadingsVal("$name","GridFeedIn", "")." W";;\
my $gfid = ReadingsVal("$name","GridFeedInDay", "")." kWh";;\
my $gfim = ReadingsVal("$name","GridFeedInMonth", "")." kWh";;\
my $gfiy = ReadingsVal("$name","GridFeedInYear", "")." kWh";;\
my $eb = ReadingsVal("$name","GridConsumption", "")." W";;\
my $ebd = ReadingsVal("$name","GridConsumptionDay", "")." kWh";;\
my $ebm = ReadingsVal("$name","GridConsumptionMonth", "")." kWh";;\
my $eby = ReadingsVal("$name","GridConsumptionYear", "")." kWh";;\
my $et = ReadingsVal("$name","TotalConsumption", "")." W";;\
my $etd = ReadingsVal("$name","TotalConsumptionDay", "")." kWh";;\
my $etm = ReadingsVal("$name","TotalConsumptionMonth", "")." kWh";;\
my $ety = ReadingsVal("$name","TotalConsumptionYear", "")." kWh";;\
my $aq = ReadingsVal("$name","AutarkyQuote", "")." %";;\
my $aqd = ReadingsVal("$name","AutarkyQuoteDay", "")." %";;\
my $aqm = ReadingsVal("$name","AutarkyQuoteMonth", "")." %";;\
my $aqy = ReadingsVal("$name","AutarkyQuoteYear", "")." %";;\
my $sq = ReadingsVal("$name","SelfConsumptionQuote", "")." %";;\
my $sqd = ReadingsVal("$name","SelfConsumptionQuoteDay", "")." %";;\
my $sqm = ReadingsVal("$name","SelfConsumptionQuoteMonth", "")." %";;\
my $sqy = ReadingsVal("$name","SelfConsumptionQuoteYear", "")." %";;\
my $md = ReadingsTimestamp("$name", "AutarkyQuote", "");;\
my $cd = ReadingsTimestamp("PV_Anlage_1_API", "Statistic_Autarky_Day", "");;\
my $cm = ReadingsTimestamp("PV_Anlage_1_API", "Statistic_Autarky_Month", "");;\
my $cy = ReadingsTimestamp("PV_Anlage_1_API", "Statistic_Autarky_Year", "");;\
"<html><table border=2 bordercolor='darkgreen' cellspacing=0>\
<tr><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'> </td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>aktueller Wert</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>Heute</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>dieser Monat</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>dieses Jahr</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>PV-Erzeugung-Total</td><td style='padding-right:5px;;padding-left:5px'>".$pvt."</td><td style='padding-right:5px;;padding-left:5px'>".$pvtd."</td><td style='padding-right:5px;;padding-left:5px'>".$pvtm."</td><td style='padding-right:5px;;padding-left:5px'>".$pvty."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>PV-Einspeisung</td><td style='padding-right:5px;;padding-left:5px'>".$gfi."</td><td style='padding-right:5px;;padding-left:5px'>".$gfid."</td><td style='padding-right:5px;;padding-left:5px'>".$gfim."</td><td style='padding-right:5px;;padding-left:5px'>".$gfiy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Netz-Bezug</td><td style='padding-right:5px;;padding-left:5px'>".$eb."</td><td style='padding-right:5px;;padding-left:5px'>".$ebd."</td><td style='padding-right:5px;;padding-left:5px'>".$ebm."</td><td style='padding-right:5px;;padding-left:5px'>".$eby."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>PV-Bezug</td><td style='padding-right:5px;;padding-left:5px'>".$pv."</td><td style='padding-right:5px;;padding-left:5px'>".$pvd."</td><td style='padding-right:5px;;padding-left:5px'>".$pvm."</td><td style='padding-right:5px;;padding-left:5px'>".$pvy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Energieverbrauch</td><td style='padding-right:5px;;padding-left:5px'>".$et."</td><td style='padding-right:5px;;padding-left:5px'>".$etd."</td><td style='padding-right:5px;;padding-left:5px'>".$etm."</td><td style='padding-right:5px;;padding-left:5px'>".$ety."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Autarkiequote</td><td style='padding-right:5px;;padding-left:5px'>".$aq."</td><td style='padding-right:5px;;padding-left:5px'>".$aqd."</td><td style='padding-right:5px;;padding-left:5px'>".$aqm."</td><td style='padding-right:5px;;padding-left:5px'>".$aqy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Eigenverbrauchsquote</td><td style='padding-right:5px;;padding-left:5px'>".$sq."</td><td style='padding-right:5px;;padding-left:5px'>".$sqd."</td><td style='padding-right:5px;;padding-left:5px'>".$sqm."</td><td style='padding-right:5px;;padding-left:5px'>".$sqy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Berechnung am</td><td style='padding-right:5px;;padding-left:5px'>".$md."</td><td style='padding-right:5px;;padding-left:5px'>".$cd."</td><td style='padding-right:5px;;padding-left:5px'>".$cm."</td><td style='padding-right:5px;;padding-left:5px'>".$cy."</td></tr>\
</table></html>"\
}
attr Dum.Energy userReadings PVTotal {round(ReadingsVal("PV_Anlage_1","Total_AC_active_power",""),0)},\
PVTotalDay {round( ReadingsVal("PV_Anlage_1_API","Statistic_Yield_Day", "")/1000 ,2)},\
PVTotalMonth {round( ReadingsVal("PV_Anlage_1_API","Statistic_Yield_Month", "")/1000 ,2)},\
PVTotalYear {round( ReadingsVal("PV_Anlage_1_API","Statistic_Yield_Year", "")/1000 ,2)},\
\
PV {round( ReadingsVal("PV_Anlage_1","Home_own_consumption_from_battery", "")+ReadingsVal("PV_Anlage_1","Home_own_consumption_from_PV", "") ,0)},\
PVDay {round( (ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Day", "")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Day", ""))/1000 ,2)},\
PVMonth {round( (ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Month", "")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Month", ""))/1000 ,2)},\
PVYear {round( (ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Year", "")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Year", ""))/1000 ,2)},\
\
GridFeedIn { ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0)<=0 ? abs(round(ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0),0)) : 0 },\
GridFeedInDay {round((ReadingsVal("PV_Anlage_1_API","Statistic_Yield_Day", "")-ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Day", "")-ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Day", ""))/1000,2)},\
GridFeedInMonth {round((ReadingsVal("PV_Anlage_1_API","Statistic_Yield_Month", "")-ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Month", "")-ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Month", ""))/1000,2)},\
GridFeedInYear {round((ReadingsVal("PV_Anlage_1_API","Statistic_Yield_Year", "")-ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Year", "")-ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Year", ""))/1000,2)},\
\
GridConsumption { ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0)>=0 ? round(ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0),0) : 0 },\
GridConsumptionDay {round(abs(ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeGrid_Day",""))/1000 ,2)},\
GridConsumptionMonth {round(ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeGrid_Month","")/1000 ,2)},\
GridConsumptionYear {round(ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeGrid_Year","")/1000 ,2)},\
\
TotalConsumption {round((ReadingsVal("PV_Anlage_1","Home_own_consumption_from_PV","")+ReadingsVal("PV_Anlage_1","Home_own_consumption_from_battery","")+ReadingsVal("PV_Anlage_1","Home_own_consumption_from_grid","")),0)},\
\
TotalConsumptionDay {round( (ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Day","")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Day","")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeGrid_Day","") )/1000 ,2)},\
TotalConsumptionMonth {round( (ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Month","")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Month","")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeGrid_Month","") )/1000 ,2)},\
TotalConsumptionYear {round( (ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Year","")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Year","")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeGrid_Year","") )/1000,2)},\
\
AutarkyQuote {my $valA = ReadingsVal("PV_Anlage_1", "Total_AC_active_power","")-ReadingsVal("PV_Anlage_1", "Home_own_consumption_from_grid","");;;; my $calcVal = ($valA > 0)?round($valA /($valA + ReadingsVal("PV_Anlage_1", "Home_own_consumption_from_grid",""))*100 ,0) : 0 ;;;; ($calcVal > 100)?100:$calcVal },\
AutarkyQuoteDay {round(ReadingsVal("PV_Anlage_1_API","Statistic_Autarky_Day", ""),0)},\
AutarkyQuoteMonth {round(ReadingsVal("PV_Anlage_1_API","Statistic_Autarky_Month", ""),0)},\
AutarkyQuoteYear {round(ReadingsVal("PV_Anlage_1_API","Statistic_Autarky_Year", ""),0)},\
\
SelfConsumptionQuote {my $valS = ReadingsVal("PV_Anlage_1","Total_AC_active_power", 0) ;;;; my $calcVal = ($valS > 0)?round((ReadingsVal("PV_Anlage_1","Home_own_consumption_from_PV", "0") + ReadingsVal("PV_Anlage_1","Home_own_consumption_from_battery","0")) / $valS * 100 ,0) : 0 ;;;; ($calcVal > 100)?100:$calcVal},\
SelfConsumptionQuoteDay {round(ReadingsVal("PV_Anlage_1_API","Statistic_OwnConsumptionRate_Day", ""),0)},\
SelfConsumptionQuoteMonth {round(ReadingsVal("PV_Anlage_1_API","Statistic_OwnConsumptionRate_Month", ""),0)},\
SelfConsumptionQuoteYear {round(ReadingsVal("PV_Anlage_1_API","Statistic_OwnConsumptionRate_Year", ""),0)}
</syntaxhighlight>

=== Erstellen von zusätzlichen Werten in der Datenbank ===
[[Bild:SVG LogDB PV Bilanz.png|mini|900px|rechts|Die Definitiun diese Diagramms ist weiter unten beschrieben.]]
Hier werden Werte konsolidiert, weil z.B. der Wert PV_total_Month stetig steigt. Am Ende des Monats sind die gesamten Zwischenwerte ohne Aussagekraft und werden dann später mal gelöscht.
==== RAW Definition LogDBRep_PV_total_diff_Week ====
<syntaxhighlight lang="Perl">
defmod LogDBRep_PV_total_diff_Week DbRep LogDB
attr LogDBRep_PV_total_diff_Week DbLogExclude .*
attr LogDBRep_PV_total_diff_Week aggregation week
attr LogDBRep_PV_total_diff_Week allowDeletion 0
attr LogDBRep_PV_total_diff_Week device Dum.Energy
attr LogDBRep_PV_total_diff_Week reading PVTotalMonth
attr LogDBRep_PV_total_diff_Week room Strom->Energie,System
attr LogDBRep_PV_total_diff_Week timestamp_begin previous_month_begin
attr LogDBRep_PV_total_diff_Week timestamp_end previous_week_end
</syntaxhighlight>
==== RAW Definition LogDBRep_PV_total_max_Month ====
<syntaxhighlight lang="Perl">
defmod LogDBRep_PV_total_max_Month DbRep LogDB
attr LogDBRep_PV_total_max_Month DbLogExclude .*
attr LogDBRep_PV_total_max_Month aggregation month
attr LogDBRep_PV_total_max_Month allowDeletion 0
attr LogDBRep_PV_total_max_Month device Dum.Energy
attr LogDBRep_PV_total_max_Month reading PVTotalMonth
attr LogDBRep_PV_total_max_Month room Strom->Energie,System
attr LogDBRep_PV_total_max_Month timestamp_begin previous_month_begin
attr LogDBRep_PV_total_max_Month timestamp_end previous_day_end
</syntaxhighlight>
==== RAW Definition LogDBRep_PV_used_diff_Week ====
<syntaxhighlight lang="Perl">
defmod LogDBRep_PV_used_diff_Week DbRep LogDB
attr LogDBRep_PV_used_diff_Week DbLogExclude .*
attr LogDBRep_PV_used_diff_Week aggregation week
attr LogDBRep_PV_used_diff_Week allowDeletion 0
attr LogDBRep_PV_used_diff_Week device Dum.Energy
attr LogDBRep_PV_used_diff_Week reading PVMonth
attr LogDBRep_PV_used_diff_Week room Strom->Energie,System
attr LogDBRep_PV_used_diff_Week timestamp_begin previous_month_begin
attr LogDBRep_PV_used_diff_Week timestamp_end previous_week_end
</syntaxhighlight>
==== RAW Definition LogDBRep_PV_used_max_Month ====
<syntaxhighlight lang="Perl">
defmod LogDBRep_PV_used_max_Month DbRep LogDB
attr LogDBRep_PV_used_max_Month DbLogExclude .*
attr LogDBRep_PV_used_max_Month aggregation month
attr LogDBRep_PV_used_max_Month allowDeletion 0
attr LogDBRep_PV_used_max_Month device Dum.Energy
attr LogDBRep_PV_used_max_Month reading PVMonth
attr LogDBRep_PV_used_max_Month room Strom->Energie,System
attr LogDBRep_PV_used_max_Month timestamp_begin previous_month_begin
attr LogDBRep_PV_used_max_Month timestamp_end previous_month_end
</syntaxhighlight>

=== Timing für die Datenbank Einträge ===
<syntaxhighlight lang="Perl">
defmod DF_DB_Service DOIF ## Monatlich Einträge\
([01:13] and ($mday==1))(\
set LogDBRep_PV_used_max_Month maxValue writeToDB;;\
set LogDBRep_PV_total_max_Month maxValue writeToDB\
)\
## Wöchentliche Einträge\
DOELSEIF\
([01:17] and ($wday==1))(\
set LogDBRep_PV_used_diff_Week diffValue writeToDB;;\
set LogDBRep_PV_total_diff_Week diffValue writeToDB\
)\

attr DF_DB_Service DbLogExclude .*
attr DF_DB_Service do always
attr DF_DB_Service room System
</syntaxhighlight>

=== Löschen von nicht mehr benötigten Werten in der Datenbank ===
Hier wird endgültig aufgeräumt, alte momentan Werte werden gelöscht, wenn sie nach z.B. drei Monaten keine Relevanz mehr haben. Dafür wurden im vorherigen Abschnitt zusätzliche Werte in der Datenbank erzeugt, die in Diagrammen trotzdem noch einen trend erkennen lassen.
Wen eine immer größer werdende Datenbank mit steigenden Antwortzeiten nicht stört, der kann das Aufräumen auch weg lassen. Bei einer späteren Migration führt dies natürlich zu höherem Aufwand und hohen Laufzeiten.
<syntaxhighlight lang="Perl">
</syntaxhighlight>

== Wetter-/Leistungs-Prognose ==
Dies ist ein Thema, dass nicht wirklich gut zu fassen ist und ist eher etwas für Enthusiasten :-), wer schon mal mit Sonne, Wolken und Regen gerechnet hat versteht was ich meine. Dieser Ansatz ist nicht wissenschaftlicher Art und hat auch keinen Anspruch mathematischer Perfektion. Nach reinem Gefühl und mit aus dem Fenster schauen kommt jedoch ein respektables Ergebnis dabei heraus. Viel Vergnügen und Spaß beim mitbasteln ;-)
[[Bild:Plenticore_Forecast_Tagesanfang.png|mini|900px|rechts|Wenn der Tag begonnen hat ist die Prognose vom Vortag bereits im Diagramm. Der Wert Calculation in schwarz ist die aktuelle Korrektur.]]
=== Deutscher Wetter Dienst (DWD) ===
Der DWD liefert über Mosmix kostenlos, stunden aktuelle Prognosedaten woraus für diese Anwendung die Werte Rad1h und TTT bezogen werden. In der Funktion Solar_forecast erfolgt noch eine Verschiebung um eine Stunde und die Umrechnung von Rad1h in Watt/m² .
'''Achtung: nicht alle Stationen liefern auch die Rad1h Daten, was deshalb bitte anhand der readings kontrolliert werden müsste.'''
[[DWD_OpenData|FHEM DWD_OpenData Modul]]
==== RAW Definition DWD_Forecast ====
Erfordert ggf.
<syntaxhighlight lang="Perl">
sudo apt-get install libxml-libxml-perl
</syntaxhighlight>

<syntaxhighlight lang="Perl">
defmod DWD_Forecast DWD_OpenData
attr DWD_Forecast DbLogExclude .*
attr DWD_Forecast forecastDays 1
attr DWD_Forecast forecastProperties Rad1h,TTT,Neff,R600
attr DWD_Forecast forecastResolution 1
attr DWD_Forecast forecastStation P0178
attr DWD_Forecast group PV Eigenverbrauch
attr DWD_Forecast icon weather_rain_fog
attr DWD_Forecast room Informationen->Wetter,Strom->Photovoltaik
attr DWD_Forecast sortby 02
</syntaxhighlight>

=== 99_myUtils.pm Funktionen ===
==== Solar_forecast ====
Achtung, diese Funktion ist noch nicht vollständig ausprogrammiert. Es wurden bereits Übergabeparameter integriert, um z.B. andere Wetterdienste zu berücksichtigen.
Um diese Funktion zu nutzen muss ein Dummy PV_Anlage_1_config vorhanden sein, in dem unter anderem die Modul und Anlagen Ausrichtung konfiguriert wird.
Rückfragen gerne im Forum.
<syntaxhighlight lang="Perl">
###########################################################
# Subroutine to calculate radiation
###########################################################
sub Solar_forecast($$$$$$) {
#
# Mit "attr global verbose 3" erscheinen Logmeldungen
#
my $logdb = $_[0] ;
my $logdbrep = $_[1] ; # Das wird zum Löschen in der LogDB verwendet und muss entsprechend konfiguriert sein.
my $logdevice = $_[2] ;
# Hier könnte man noch andere Wetterdienste berücksichtigen bzw den Device Namen ändern
my $wetter = $_[4] ; if ($wetter ne "DWD_Forecast") {return("$wetter not supported")} ;
my $fc = $_[5] ; # Wieviel Tage in die Zukunft soll es gehen? 0,1,2
my $reading = $_[3].$fc ;

my $timeshift = 1; # Verschiebt die Prognose um eine Stunde
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); $year += 1900; $mon += 1;
my ($Solar_Cloud,$Solar_Rain,$Solar_Temp,$Solar_SolarRadiation,$logentry,$i) = (0) x 6 ;
my ($cloudk,$raink,$tempk,$cloudk_base,$raink_base,$tempk_base) = (0) x 6 ;
my ($Solar_Correction_Cloud,$Solar_Correction_Rain,$Solar_Correction_Temp,$Solar_Plain) = (1) x 4 ;
my (@Solar_,@module_count) = (0,0,0) ;

# Initialisieren des Basis TIMESTAMP für den Forecast
my $timestring = time_str2num($year."-".$mon."-".$mday." 07:00:00") ;
my $timestamp = POSIX::strftime("%Y-%m-%d %H:00:00",localtime($timestring+$fc*24*60*60)) ;

# Bei Forecast zuerst die bisherigen Einträge in der Datenbank für den Tag löschen
fhem "set ".$logdbrep." sqlCmd DELETE FROM history WHERE DEVICE='".$logdevice."' AND READING='".$reading."' AND TIMESTAMP>='".$timestamp."'" ;

# Es werden Stundenwerte von 07:00 bis 19:00 Uhr berechnet
for ($i = 7; $i <= 19; $i++) {
$timestring = time_str2num($year."-".$mon."-".$mday." ".$i.":00:00") ;
$timestamp = POSIX::strftime("%Y-%m-%d %H:00:00",localtime($timestring+$fc*24*60*60)) ;

if ( $wetter eq "DWD_Forecast") {
$Solar_Cloud = ReadingsVal($wetter,"fc".$fc."_".($i+$timeshift)."_Neff" ,0);
$Solar_Rain = ReadingsVal($wetter,"fc".$fc."_".($i+$timeshift)."_R600" ,0);
$Solar_Temp = ReadingsVal($wetter,"fc".$fc."_".($i+$timeshift)."_TTT" ,0)+10;
$Solar_SolarRadiation = ReadingsVal($wetter,"fc".$fc."_".($i+$timeshift)."_Rad1h",0);
$Solar_SolarRadiation = round($Solar_SolarRadiation * 0.277778 ,0);
Log 3, "Solar_SolarRadiation : ".$Solar_SolarRadiation." ".ReadingsVal($wetter,"fc".$fc."_".($i+$timeshift)."_Rad1h",0) ;
};

$cloudk = ReadingsVal($logdevice."_config","forecast_cloudk",0) * -0.01 ;
if ($cloudk ne 0) {
$cloudk_base = ReadingsVal($logdevice."_config","forecast_cloudk_base",0) ;
$Solar_Correction_Cloud = round((1 + ($Solar_Cloud - $cloudk_base) * $cloudk / 100),3) ;
};

$raink = ReadingsVal($logdevice."_config","forecast_raink",0) * -0.01 ;
if ($raink ne 0) {
$raink_base = ReadingsVal($logdevice."_config","forecast_raink_base" ,0) ;
$Solar_Correction_Rain = round((1 + ($Solar_Rain - $raink_base ) * $raink / 100),3) ;
};

$tempk = ReadingsVal($logdevice."_config","forecast_tempk",0) * -0.01 ;
if ($tempk ne 0) {
$tempk_base = ReadingsVal($logdevice."_config","forecast_tempk_base" ,0) ;
$Solar_Correction_Temp = round((1 + ($Solar_Temp - $tempk_base ) * $tempk / 100),3) ;
};

my $Solar_Correction_Faktor = ReadingsVal($logdevice."_config","forecast_factor",1) ;

$logentry = 0 ;
for(my $j=1;$j<4;$j++){
$module_count[$j] = ReadingsVal($logdevice."_config","module_".$j."_count",0) ;
if ($module_count[$j] ne 0) {
$Solar_Plain = round(Solar_plain(ReadingsVal($logdevice."_config","module_".$j."_plain",0) , ReadingsVal($logdevice."_config","module_".$j."_direction",0) , $timestamp),3) ;
Log 3, "plain/direction : ".ReadingsVal($logdevice."_config","module_".$j."_plain",0)."/".ReadingsVal($logdevice."_config","module_".$j."_direction",0)." >>> ".$Solar_Plain ;

$Solar_[$j] = $module_count[$j] * ReadingsVal($logdevice."_config","module_".$j."_power",1)/1000 ;
$Solar_[$j] = $Solar_[$j] * $Solar_Plain ;
$Solar_[$j] = $Solar_[$j] * $Solar_SolarRadiation ;
$Solar_[$j] = $Solar_[$j] * $Solar_Correction_Temp * $Solar_Correction_Cloud * $Solar_Correction_Rain * $Solar_Correction_Faktor ;
$Solar_[$j] = ($Solar_[$j] lt 0)?0:round($Solar_[$j],0) ;
};
$logentry = $logentry + $Solar_[$j] ;
if ($fc == 0 and $hour == $i) {
fhem "setreading ".$logdevice." Solar_".ReadingsVal($logdevice."_config","module_".$j."_name",0)." ".$Solar_[$j] ;
};
};

fhem "set ".$logdb." addCacheLine ".$timestamp."|".$logdevice."|addlog|".$reading.": ".$logentry."|".$reading."|".$logentry."|";

if ($fc == 0 and $hour == $i and ($module_count[1] ne 0 or $module_count[2] ne 0 or $module_count[3] ne 0)) {
fhem "setreading ".$logdevice." Solar_SolarRadiation ".$Solar_SolarRadiation ;
fhem "setreading ".$logdevice." Solar_Cloud ".$Solar_Cloud ;
fhem "setreading ".$logdevice." Solar_Rain ".$Solar_Rain ;
fhem "setreading ".$logdevice." Solar_Temp ".$Solar_Temp ;
fhem "setreading ".$logdevice." Solar_Correction_Cloud ".$Solar_Correction_Cloud ;
fhem "setreading ".$logdevice." Solar_Correction_Rain ".$Solar_Correction_Rain ;
fhem "setreading ".$logdevice." Solar_Correction_Temp ".$Solar_Correction_Temp ;
fhem "setreading ".$logdevice." Solar_Calculation ".$logentry ;
} ;

Log 3, "Solar_Plain : ".$Solar_Plain ;
Log 3, "Solar_SolarRadiation : ".$Solar_SolarRadiation ;
Log 3, "Solar_Cloud : ".$Solar_Cloud ;
Log 3, "cloudk : ".$cloudk." ".$cloudk_base ;
Log 3, "Solar_Correction_Cloud : ".$Solar_Correction_Cloud ;
Log 3, "Solar_Rain : ".$Solar_Rain ;
Log 3, "raink : ".$raink." ".$raink_base ;
Log 3, "Solar_Correction_Rain : ".$Solar_Correction_Rain ;
Log 3, "Solar_Temp : ".$Solar_Temp ;
Log 3, "tempk : ".$tempk." ".$tempk_base ;
Log 3, "Solar_Correction_Temp : ".$Solar_Correction_Temp ;
Log 3, $fc." ".$i." ".$Solar_SolarRadiation." ".$logentry ;
} ;
return (0);
};
</syntaxhighlight>

==== Solar_Plain ====
<syntaxhighlight lang="Perl">
sub Solar_plain($$$) {

my $angle = $_[0];
my $orienta = $_[1];
my $time = $_[2];
my $azimuth = fhem "get Astro text SunAz ".$time ;

# angles in radiant
my $rad = 57.296;
my $elevation = fhem "get Astro text SunAlt ".$time ;
$elevation = $elevation / $rad;
$angle = $angle / $rad;
my $orientation = ($azimuth - 180 - $orienta) / $rad;

# avoid unrealistic values (normally formula should only be used within boundaries of orientation +/- 90 degrees)
return (0.001) if ($elevation <= 0.25);

if(cos($orientation) < 0.05 && cos($orientation) > -0.2) {$orientation =$orientation - 0.2};

# Log3 "", 1, "Solar radiation, azimuth = $azimuth, orientation=$orientation, elevation=$elevation, angle=$angle";
my $factor = sin($angle) /
(sin( $elevation) /
cos( $elevation)) *
cos($orientation) +
cos($angle);

# otherwise too big values (normally formula should only be used within boundaries of orientation +/- 90 degrees)
if ($factor > - 0.05 && $factor < 0.05) {$factor = 0.05};

return ($factor);
};
</syntaxhighlight>

=== wunderground ===
Diesen Dienst nutze ich nicht für die Prognose, jedoch kann man dort private Wetterstationen in seinem näheren Umfeld finden, die die Sonneneinstrahlung und den UV Index messen. Das ist dann als aktueller Wert in den Diagrammen zu sehen und lässt aktuelle Beschattung durch Wolken erkennen. Hier kann man dann auch mehrere Stationen definieren und eventuell mit einem Durchschnitt arbeiten, wenn nicht gerade der Nachbar eine Station hat.
Für diese Abfrage ist keine Registrierung notwendig und man muss auch nicht selber mir einer Station Daten liefern.
Aber bitte, die Abfrage nicht in einem zu kurzen Abstand, also mit hoher Frequenz stellen! Hier wird alle 15 Minuten (900 Sekunden) abgefragt.
=== RAW Definition Wetter_<Wohnort> ===
Ggf. muss UConv vorher noch aktiviert werden:
<syntaxhighlight lang="Perl">
define uconvInit notify global:INITIALIZED {use UConv}
</syntaxhighlight>

<syntaxhighlight lang="Perl">
defmod wetter_<Wohnort> HTTPMOD https://www.wunderground.com/dashboard/pws/<Wohnort_Station> 900

attr wetter_<Wohnort> DbLogExclude .*
attr wetter_<Wohnort> DbLogInclude solarRadiation,solarUV,temperature
attr wetter_<Wohnort> alias wetter_<Wohnort>
attr wetter_<Wohnort> enableControlSet 1
attr wetter_<Wohnort> event-on-change-reading solarRadiation,solarUV,temperature
attr wetter_<Wohnort> group ASC Environment
attr wetter_<Wohnort> icon weather_sunrise
attr wetter_<Wohnort> reading01Name date
attr wetter_<Wohnort> reading01Regex Summary.*>([[:alpha:]]{1,8} [\d]{1,2}, [\d]{4})<.*Temperature
attr wetter_<Wohnort> reading02Format %.1f
attr wetter_<Wohnort> reading02Name dewpointTemperature
attr wetter_<Wohnort> reading02OExpr UConv::f2c($val,2)
attr wetter_<Wohnort> reading02Regex DEWPOINT.*>([\d\.]+)<.*HUMIDITY
attr wetter_<Wohnort> reading03Name dewpointTemperature_EN
attr wetter_<Wohnort> reading03Regex DEWPOINT.*>([\d\.]+)<.*HUMIDITY
attr wetter_<Wohnort> reading04Format %.0f
attr wetter_<Wohnort> reading04Name humidity
attr wetter_<Wohnort> reading04Regex HUMIDITY.*>([\d\.]+)<.*WIND
attr wetter_<Wohnort> reading05Name precip1hrmetric
attr wetter_<Wohnort> reading05Regex PRECIP RATE.*>([\d\.]+)<.*PRECIP TOTAL
attr wetter_<Wohnort> reading06Name preciptodaymetric
attr wetter_<Wohnort> reading06Regex PRECIP TOTAL.*>([\d\.]+)<.*tile-precipitation
attr wetter_<Wohnort> reading07Format %.2f
attr wetter_<Wohnort> reading07Name pressure
attr wetter_<Wohnort> reading07OExpr UConv::inhg2hpa($val,2)
attr wetter_<Wohnort> reading07Regex CURRENT.*>([\d\.]+)<.*tile-pressure
attr wetter_<Wohnort> reading08Format %.2f
attr wetter_<Wohnort> reading08Name pressure_EN
attr wetter_<Wohnort> reading08Regex CURRENT.*>([\d\.]+)<.*tile-pressure
attr wetter_<Wohnort> reading09Name solarRadiation
attr wetter_<Wohnort> reading09Regex SOLAR RADIATION.*CURRENT.*weather__text">([\d\.]+)
attr wetter_<Wohnort> reading10Name solarUV
attr wetter_<Wohnort> reading10Regex CURRENT UV.*>([\d\.]+)<.*UV RISK
attr wetter_<Wohnort> reading11Format %.1f
attr wetter_<Wohnort> reading11Name temperature
attr wetter_<Wohnort> reading11OExpr UConv::f2c($val,2)
attr wetter_<Wohnort> reading11Regex current-temp.*">([- ]*[\d\.]+).*DEWPOINT
attr wetter_<Wohnort> reading12Format %.1f
attr wetter_<Wohnort> reading12Name temperature_EN
attr wetter_<Wohnort> reading12Regex current-temp.*">([- ]*[\d\.]+).*DEWPOINT
attr wetter_<Wohnort> reading13Format %.1f
attr wetter_<Wohnort> reading13Name windChill
attr wetter_<Wohnort> reading13OExpr UConv::f2c($val,2)
attr wetter_<Wohnort> reading13Regex Feels Like.*>([\d\.]+)<.*wind-dial__container
attr wetter_<Wohnort> reading14Format %.1f
attr wetter_<Wohnort> reading14Name windChill_EN
attr wetter_<Wohnort> reading14Regex Feels Like.*>([\d\.]+)<.*wind-dial__container
attr wetter_<Wohnort> reading15Name windDirection
attr wetter_<Wohnort> reading15OExpr UConv::compasspoint2compasspoint($val,"en",1,"de")
attr wetter_<Wohnort> reading15Regex WIND FROM.*>([NESW]+)<.*GUST
attr wetter_<Wohnort> reading16Name windDirection_EN
attr wetter_<Wohnort> reading16Regex WIND FROM.*>([NESW]+)<.*GUST
attr wetter_<Wohnort> reading17Format %.0f
attr wetter_<Wohnort> reading17Name windSpeed
attr wetter_<Wohnort> reading17OExpr UConv::mph2kph($val,1)
attr wetter_<Wohnort> reading17Regex wind-dial__container.*>([\d\.]+)<.*unit-speed
attr wetter_<Wohnort> reading18Name windSpeed_EN
attr wetter_<Wohnort> reading18Regex wind-dial__container.*>([\d\.]+)<.*unit-speed
attr wetter_<Wohnort> reading19Name windGust
attr wetter_<Wohnort> reading19OExpr UConv::mph2kph($val,1)
attr wetter_<Wohnort> reading19Regex GUST.*>([\d\.]+)<.*mph
attr wetter_<Wohnort> reading20Name windGust_EN
attr wetter_<Wohnort> reading20Regex GUST.*>([\d\.]+)<.*mph
attr wetter_<Wohnort> room Informationen->Wetter,Rollos
attr wetter_<Wohnort> sortby 03
attr wetter_<Wohnort> stateFormat T: temperature °C | F: humidity % | W: windSpeed km/h | D: pressure hPa | U: solarUV | R: solarRadiation W/m²
attr wetter_<Wohnort> timeout 5
</syntaxhighlight>

== Diagramme ==
=== RAW Definition Hauptverbraucher ===
[[Bild:Plenticore_Hauptverbraucher.png|mini|600px|rechts|]]
==== SVG_LogDB_Photovoltaik_2 ====
<pre>
defmod SVG_LogDB_Photovoltaik_2 SVG LogDB:SVG_LogDB_Photovoltaik_2:HISTORY
attr SVG_LogDB_Photovoltaik_2 DbLogExclude .*
attr SVG_LogDB_Photovoltaik_2 group PV Eigenverbrauch
attr SVG_LogDB_Photovoltaik_2 plotsize 1400,320
attr SVG_LogDB_Photovoltaik_2 room Strom->Info,Strom->Photovoltaik
attr SVG_LogDB_Photovoltaik_2 sortby 00
</pre>
==== GPLOTFILE SVG_LogDB_Photovoltaik_2.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-03-16 10:23:52
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Hauptverbraucher'
set ytics
set y2tics
set grid
set ylabel "Leistung"
set y2label ""

#LogDB PV_Anlage_1:Total_DC_Power:::$val=abs($val)
#LogDB PV_Anlage_1:Total_PV_Power_reserve::
#LogDB StromZaehler_Heizung:SMAEM1901401955_Saldo_Wirkleistung:::$val=abs($val)
#LogDB shelly02:Power_0::
#LogDB shelly03:Power::

plot "<IN>" using 1:2 axes x1y2 title 'Total_DC' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Total_PV_reserve' ls l2 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Heizung' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Pool' ls l8 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Waschmaschine' ls l3 lw 1 with lines
</pre>
=== RAW Definition Leistungsbezug ===
[[Bild:Plenticore_Leistungsbezug.png|mini|600px|rechts|]]
==== SVG_LogDB_Photovoltaik_3 ====
<pre>
defmod SVG_LogDB_Photovoltaik_3 SVG LogDB:SVG_LogDB_Photovoltaik_3:HISTORY
attr SVG_LogDB_Photovoltaik_3 DbLogExclude .*
attr SVG_LogDB_Photovoltaik_3 group PV Eigenverbrauch
attr SVG_LogDB_Photovoltaik_3 plotsize 1400,320
attr SVG_LogDB_Photovoltaik_3 room Strom->Info,Strom->Photovoltaik
attr SVG_LogDB_Photovoltaik_3 sortby 00
</pre>
==== GPLOTFILE SVG_LogDB_Photovoltaik_3.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-07-22 13:51:57
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Leistungsbezug'
set ytics
set y2tics
set grid
set ylabel "Leistung"
set y2label ""
set yrange [0:9500]
set y2range [0:9500]

#LogDB PV_Anlage_1:Total_DC_Power:::$val=abs($val)
#LogDB PV_Anlage_1:Home_own_consumption_from_PV::
#LogDB PV_Anlage_1:Home_own_consumption_from_battery::
#LogDB PV_Anlage_1:Home_own_consumption_from_grid::
#LogDB PV_Anlage_1:Actual_battery_charge_usable_Power::
#LogDB PV_Anlage_1:Total_DC_Power_Max::
#LogDB PV_Anlage_1:Battery_temperature:::$val=$val*100
#LogDB Heizung:heatSourceIN:::$val=$val*100

plot "<IN>" using 1:2 axes x1y2 title 'Total_DC_Power' ls l1fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'own_PV' ls l2fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Bat_use' ls l0fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Grid_use' ls l5 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Bat_usable' ls l4 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Total_DC_Max' ls l6 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Bat_Temp_Trend' ls l0 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Out_Temp_Trend' ls l2 lw 2 with lines
</pre>
=== RAW Definition PV_Bilanz ===
[[Bild:SVG LogDB PV Bilanz.png|mini|600px|rechts|]]
==== SVG_LogDB_PV_Bilanz ====
<pre>
defmod SVG_LogDB_PV_Bilanz SVG LogDB:SVG_LogDB_PV_Bilanz:HISTORY
attr SVG_LogDB_PV_Bilanz DbLogExclude .*
attr SVG_LogDB_PV_Bilanz alias SVG_LogDB_PV_Bilanz
attr SVG_LogDB_PV_Bilanz fixedrange year
attr SVG_LogDB_PV_Bilanz plotsize 1400,320
attr SVG_LogDB_PV_Bilanz room Strom->Energie
</pre>
==== GPLOTFILE SVG_LogDB_PV_Bilanz.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-08-02 09:55:06
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'PV_Bilanz'
set ytics
set y2tics
set grid ytics
set ylabel "KWh"
set y2label "KWh"

#LogDB Dum.Energy:max_month_PVMonth::
#LogDB Dum.Energy:diff_week_PVMonth::
#LogDB Dum.Energy:diff_week_PVTotalMonth::

plot "<IN>" using 1:2 axes x1y2 title 'PV-Bezug-Monat' ls l2fill lw 2 with points,\
"<IN>" using 1:2 axes x1y2 title 'PV-Bezug-Woche' ls l2fill lw 1 with fsteps,\
"<IN>" using 1:2 axes x1y2 title 'PV-Total-Woche' ls l1fill lw 1 with lines
</pre>

=== RAW Definition Forecast / Calculation ===
[[Bild:Plenticore_Forecast.png|mini|600px|rechts|]]
==== SVG_LogDB_Photovoltaik_4 ====
<pre>
defmod SVG_LogDB_Photovoltaik_4 SVG LogDB:SVG_LogDB_Photovoltaik_4:HISTORY
attr SVG_LogDB_Photovoltaik_4 DbLogExclude .*
attr SVG_LogDB_Photovoltaik_4 group PV Eigenverbrauch
attr SVG_LogDB_Photovoltaik_4 plotsize 1400,320
attr SVG_LogDB_Photovoltaik_4 room Strom->Photovoltaik
attr SVG_LogDB_Photovoltaik_4 sortby 00
</pre>
==== GPLOTFILE SVG_LogDB_Photovoltaik_4.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-08-17 08:58:42
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Forecast / Calculation'
set ytics
set y2tics
set grid
set ylabel "Leistung"
set y2label "Leistung"
set yrange [0:10000]
set y2range [0:10000]

#LogDB Astro:SunAlt:::$val=($val>0?$val*50+7000:7000)
#LogDB wetter_wolfskehlen_II:solarRadiation:::$val=($val>0?$val*3+7000:7000)
#LogDB PV_Anlage_1:Solar_SolarRadiation:::$val=($val>0?$val*3+7000:7000)
#LogDB Astro:SunAlt:::$val=7000
#LogDB PV_Anlage_1:Solar_Calculation_fc1::
#LogDB PV_Anlage_1:Power_DC_Sum::
#LogDB PV_Anlage_1:Solar_Calculation::
#LogDB PV_Anlage_1:Solar_East::
#LogDB PV_Anlage_1:Solar_South::
#LogDB PV_Anlage_1:Solar_West::

plot "<IN>" using 1:2 axes x1y2 title 'Sonnenhöhe' ls l7 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SolarRadiation' ls l8 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SolarRadiationPrognose' ls l8 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title '70%' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Calculation_fc1' ls l0 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Power_DC_Sum' ls l1fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Calculation' ls l5 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'East' ls l2 lw 0.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'South' ls l3 lw 0.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'West' ls l4 lw 0.5 with lines
</pre>

== PV Eigenverbrauch-Steuerung ==
=== Beispiel Luft Wärme Pumpe ===
==== RAW Definition LWP_LuftWärmePumpe (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod LWP dummy
attr LWP DbLogExclude .*
attr LWP DbLogInclude state
attr LWP alias LWP_LuftWärmePumpe
attr LWP group PV Eigenverbrauch
attr LWP icon sani_earth_source_heat_pump
attr LWP readingList LWP_Button PowerLevelMinTime PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay SetCmdOff SetCmdOn TimeStart TimeEnd
attr LWP room Strom->Photovoltaik
attr LWP setList LWP_Button:uzsuToggle,on,off PowerLevelMinTime:slider,60,30,300 PowerLimitOn:slider,1000,250,4000 PowerLimitOff:slider,1000,250,4000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,900,300,28800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr LWP sortby 05
attr LWP stateFormat state
attr LWP verbose 0
attr LWP webCmd LWP_Button

setstate LWP off
setstate LWP 2020-08-05 17:38:03 LWP_Button off
setstate LWP 2020-03-02 11:56:45 PowerLevelMinTime 600
setstate LWP 2020-02-05 14:11:42 PowerLimitOff 2250
setstate LWP 2020-03-02 11:56:39 PowerLimitOn 3000
setstate LWP 2019-08-02 10:31:21 RunTimeMin 3600
setstate LWP 2020-02-05 14:13:01 RunTimePerDay 28800
setstate LWP 2019-12-29 10:47:55 SetCmdOff set shelly01 off 0
setstate LWP 2019-07-22 15:35:59 SetCmdOn set shelly01 on 0
setstate LWP 2019-11-09 12:13:04 TimeEnd 16:00
setstate LWP 2020-04-02 13:51:54 TimeStart 12:30
setstate LWP 2020-08-05 17:38:03 state off
</syntaxhighlight>
==== RAW Definition LWP_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod LWP_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
##\
([LWP_Counter:pulseTimePerDay] >= [LWP:RunTimePerDay] and\
[LWP_Counter:pulseTimeIncrement] >= [LWP:RunTimeMin] and\
[LWP:state] ne "off" and [LWP:LWP_Button] eq "off" )\
\
({Log 3, " LWP_PV cmd_1 PV : LWP off"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
)\
################################################################################################################\
## 2 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und die PV Produktion unter dem Mindestbedarf ist\
##\
DOELSEIF\
( ([PV_Anlage_1:Total_PV_Power_reserve]+[StromZaehler_Heizung:SMAEM1901401955_Bezug_Wirkleistung]) < [LWP:PowerLimitOff] and\
[LWP_Counter:pulseTimeIncrement] >= [LWP:RunTimeMin] and\
[LWP:state] ne "off" and\
[LWP:LWP_Button] ne "on" )\
\
({Log 3, " LWP_PV cmd_2 PV : LWP off"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
)\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4 wieder außerkraft,\
## wenn wärend der Wartezeit die PV Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [LWP:PowerLimitOff] and\
[LWP_PV:wait_timer] ne "no timer" and\
[LWP_PV:wait_timer] ne "" and\
[LWP:state] eq "off" )\
\
({Log 3, "LWP_PV cmd_3 PV : Stop wait timer LWP"})\
################################################################################################################\
## 4 Eigenverbrauch einschalten: wenn PV Produktion über dem Mindestbedarf ist und die Laufzeit pro Tag noch nicht erreicht ist\
##\
DOELSEIF\
([Astro:ObsSeason] ne "Sommer" and [Astro:ObsSeason] ne "Frühling" and\
[PV_Anlage_1:Total_PV_Power_reserve] >= [LWP:PowerLimitOn] and\
[[LWP:TimeStart]-[LWP:TimeEnd]] and\
[LWP:state] eq "off" and\
[LWP_Counter:pulseTimePerDay] < [LWP:RunTimePerDay] and\
[Heizung:hotWaterTemperature] < 60 )\
\
({Log 3, "LWP_PV cmd_4 : LWP on"}\
{fhem("".ReadingsVal("LWP","SetCmdOn",0))}\
{fhem("set LWP on")}\
{fhem("set Heizung hotWaterTemperatureTarget 60.0")}\
)\
################################################################################################################\
## 5 Signal für den PV-Modus der LWP einschalten.\
##\
DOELSEIF\
([LWP:LWP_Button] eq "on" )\
\
({Log 3, "LWP_PV cmd_5 PV : LWP on for manuel PV-Modus"}\
{fhem("".ReadingsVal("LWP","SetCmdOn",0))}\
{fhem("set LWP on")}\
{fhem("set Heizung hotWaterTemperatureTarget 60.0")}\
)\
################################################################################################################\
## 6 Signal für den PV-Modus der LWP abschalten.\
##\
DOELSEIF\
([LWP:LWP_Button] eq "off" and\
[$SELF:cmd_nr] eq "5" )\
\
({Log 3, "LWP_PV cmd_6 PV : LWP off after manuel PV-Modus"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
)\
################################################################################################################\
## 7 Stop wait Timer für das Abschalten, wenn die LWP beim Starten noch anläuft\
##\
DOELSEIF\
([StromZaehler_Heizung:SMAEM1901401955_Bezug_Wirkleistung] > 300 and\
[Heizung:opStateHeatPump1] eq "Wärmepumpe kommt" and\
[Heizung:opStateHeatPump3] eq "Pumpenvorlauf" )\
\
({Log 3, "LWP_PV cmd_7 : Stop wait timer LWP"})\
################################################################################################################\
## 8 LWP Ende\
##\
DOELSEIF\
([StromZaehler_Heizung:SMAEM1901401955_Bezug_Wirkleistung] < 300 and\
[LWP_Counter:pulseTimeIncrement] >= [LWP:RunTimeMin] and\
([Heizung:opStateHeatPump1] ne "Wärmepumpe läuft" or [Heizung:opStateHeatPump3] eq "Luftabtauen" ) and\
([$SELF:cmd_nr] eq "4" or [$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "10") )\
\
({Log 3, "LWP_PV cmd_8 : LWP run finished"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
{fhem("setreading LWP LWP_Button off")}\
)\
################################################################################################################\
## 9 LWP Zwangseinschalten: Sollte das Brauchwasser noch nicht aufgeheizt sein, wird um die Hysterese erhöht.\
## Dies kann passieren, wenn am Tag vorher der PV-Modus lief und dann das Wasser noch knapp über dem Mindestwert ist.\
##\
DOELSEIF\
([Astro:ObsSeason] ne "Sommer" and [Astro:ObsSeason] ne "Frühling" and\
[[LWP:TimeEnd]] and\
[Heizung:hotWaterTemperature] < 47 and\
([LWP_Counter:pulseTimePerDay] < [Pool:RunTimePerDay] or\
[LWP_Counter:countsPerDay] eq 0) )\
\
({Log 3, "LWP_PV cmd_9 : LWP on for water heating"}\
\
{fhem("set Heizung hotWaterTemperatureTarget ". (ReadingsVal("Heizung","hotWaterTemperature",46)+4))}\
\
{Log 3, "LWP_PV cmd_9 : LWP hotWaterTemperatureTarget ".ReadingsVal("Heizung","hotWaterTemperatureTarget",0)}\
)\
################################################################################################################\
## 10 Hohe Priorität im Winter fuer die LWP\
## Einschalten, wenn der Pool läuft, der Speicher geladen ist und noch Überschuss da ist.\
##\
DOELSEIF\
([Astro:ObsSeason] eq "Winter" and\
[PV_Anlage_1:Total_PV_Power_reserve] >= 2000 and\
[shelly02:power_0] > 800 and\
[PV_Anlage_1:Act_state_of_charge] > 60 and\
[Heizung:hotWaterTemperature] < 60 and \
[$SELF:cmd_nr] ne "10" )\
\
({Log 3, "LWP_PV cmd_10 : LWP Priorität"}\
{fhem("set LWP_PV cmd_4")}\
)\

attr LWP_PV DbLogExclude .*
attr LWP_PV DbLogInclude state,cmd.*,Device,LWP_Status,wait_timer
attr LWP_PV alias LWP_PV
attr LWP_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch aus|Stop wait timer|Eigenverbrauch ein|LWP ein für manuellen PV-Modus|LWP aus nach manuellem PV-Modus|Stop wait timer fuer aus|LWP aus nach PV-Modus|LWP Brauchwasser nachheizen|LWP Priorität
attr LWP_PV do always
attr LWP_PV group PV Eigenverbrauch-Steuerung
attr LWP_PV icon sani_earth_source_heat_pump
attr LWP_PV room Strom->Photovoltaik
attr LWP_PV sortby 01
attr LWP_PV stateFormat state : LWP_Status : Brauchwasser e_Heizung_hotWaterTemperature °C
attr LWP_PV userReadings LWP_Status { ReadingsVal("Heizung","state","") }
attr LWP_PV verbose 5
attr LWP_PV wait 0:10:0:[LWP:PowerLevelMinTime]:0:0:900:0:0
</syntaxhighlight>
- RAW Definition LWP_Signale (Shelly Modul: shelly1pm)
<syntaxhighlight lang="Perl">
defmod shelly01 Shelly 192.168.178.55
attr shelly01 DbLogExclude .*
attr shelly01 DbLogInclude relay.*,power.*,energy.*
attr shelly01 alias LWP_Signale
attr shelly01 event-on-change-reading relay.*,power.*,energy.*,state,network
attr shelly01 group PV Eigenverbrauch-Steuerung
attr shelly01 icon taster_ch_1
attr shelly01 mode relay
attr shelly01 model shelly1pm
attr shelly01 room Shelly,Heizung->System,Strom->Photovoltaik
attr shelly01 sortby 02
attr shelly01 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Gesamt 0: %08.2f KWh<br>\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
ReadingsVal($name,"WebLink","none") ,\
ReadingsVal($name,"energy_0",0)/1000,\
(ReadingsVal($name,"relay","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power",0),\
)}
attr shelly01 userReadings WebLink:network { my $ip=ReadingsVal($NAME,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") }
attr shelly01 webCmd |
</pre>
==== RAW Definition LWP_Counter (HourCounter Modul) ====
<pre>
defmod LWP_Counter HourCounter LWP:on.* LWP:off
attr LWP_Counter DbLogExclude .*
attr LWP_Counter alias LWP_Counter
attr LWP_Counter event-min-interval .*:600
attr LWP_Counter event-on-change-reading .*
attr LWP_Counter group PV Eigenverbrauch-Steuerung
attr LWP_Counter icon time_timer
attr LWP_Counter interval 5
attr LWP_Counter room Strom->Photovoltaik
attr LWP_Counter sortby 03
attr LWP_Counter verbose 0
</syntaxhighlight>
==== RAW Definition rg_LWP_Status (readingsGroup Modul) ====
<syntaxhighlight lang="Perl">
defmod rg_LWP_Status readingsGroup <Device>,<Information>,<Wert> LWP:<Status>,state LWP:<PowerLevelMinTime>,PowerLevelMinTime LWP:<PowerLimitOn>,PowerLimitOn LWP:<PowerLimitOff>,PowerLimitOff LWP:<TimeStart>,!TimeStart LWP:<TimeEnd>,!TimeEnd LWP:<RunTimeMin>,RunTimeMin LWP_Counter:<RunTimeMin>,pulseTimeIncrement LWP:<RunTimePerDay>,RunTimePerDay LWP_Counter:<RunTimePerDay>,pulseTimePerDay LWP_PV:<wait>,wait_timer LWP_PV:<TimeStart>,timer_01_c04 LWP_PV:<TimeEnd>,timer_02_c04
attr rg_LWP_Status DbLogExclude .*
attr rg_LWP_Status alias Status LuftWärmePumpe Eigenverbrauch
attr rg_LWP_Status commands {state => 'state:on,off',\
PowerLevelMinTime => 'PowerLevelMinTime:selectnumbers,60,60,600,0,lin',\
PowerLimitOn => 'PowerLimitOn:selectnumbers,1000,250,4000,0,lin',\
PowerLimitOff => 'PowerLimitOff:selectnumbers,1000,250,4000,0,lin',\
RunTimeMin => 'RunTimeMin:selectnumbers,300,300,14400,0,lin',\
RunTimePerDay => 'RunTimePerDay:selectnumbers,300,300,28800,0,lin',\
TimeStart => 'TimeStart:time',\
TimeEnd => 'TimeEnd:time'}
attr rg_LWP_Status group PV Status
attr rg_LWP_Status nameStyle style="color:grey"
attr rg_LWP_Status room Strom->Photovoltaik
attr rg_LWP_Status sortby 01
attr rg_LWP_Status style style="font-size:18px"
</syntaxhighlight>

=== Beispiel Pool===
==== RAW Definition Pool_Softube (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod Pool dummy
attr Pool DbLogExclude .*
attr Pool DbLogInclude state
attr Pool alias Pool_Softube
attr Pool event-on-change-reading .*
attr Pool group PV Eigenverbrauch
attr Pool icon scene_swimming
attr Pool readingList Pool_Button PowerLevelMinTime PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay RunTimePerDaySummer RunTimePerDayWinter SetCmdOff SetCmdOn TimeStart TimeEnd
attr Pool room Strom->Photovoltaik
attr Pool setList Pool_Button:uzsuToggle,on,off PowerLevelMinTime:slider,30,30,300 PowerLimitOn:slider,500,100,1500 PowerLimitOff:slider,0,100,1000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,900,300,64800 RunTimePerDaySummer:slider,900,300,7200 RunTimePerDayWinter:slider,3600,900,64800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr Pool sortby 06
attr Pool stateFormat state
attr Pool verbose 0
attr Pool webCmd Pool_Button

setstate Pool off
setstate Pool 2020-08-28 13:30:10 Pool_Button off
setstate Pool 2019-12-02 10:31:26 PowerLevelMinTime 600
setstate Pool 2019-11-13 10:58:18 PowerLimitOff 800
setstate Pool 2019-11-06 11:49:00 PowerLimitOn 1000
setstate Pool 2020-08-14 16:26:09 RunTimeMin 1800
setstate Pool 2020-08-28 06:15:00 RunTimePerDay 3600
setstate Pool 2020-08-16 13:17:45 RunTimePerDaySummer 3600
setstate Pool 2020-08-25 19:32:33 RunTimePerDayWinter 14400
setstate Pool 2019-08-01 14:18:08 SetCmdOff set shelly02 off 0
setstate Pool 2019-08-02 09:33:06 SetCmdOn set shelly02 on 0
setstate Pool 2019-10-31 21:53:28 TimeEnd 16:00
setstate Pool 2020-04-08 18:19:29 TimeStart 12:30
setstate Pool 2020-08-28 14:13:02 state off
</syntaxhighlight>
==== RAW Definition Pool_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod Pool_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
##\
([Pool_Counter:pulseTimePerDay] >= [Pool:RunTimePerDay] and\
[Pool_Counter:pulseTimeIncrement] >= [Pool:RunTimeMin] and\
[Pool:state] eq "on" and [Pool:Pool_Button] eq "off" )\
\
({Log 3, "Pool_PV cmd_1 : Pool off"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")} )\
################################################################################################################\
## 2 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und die PV-Produktion unter dem Mindestbedarf ist.\
## Bei Pool Nutzung und Pflegeprogramm wird nicht abgeschaltet.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Pool:PowerLimitOff] and\
[Pool_Counter:pulseTimeIncrement] >= [Pool:RunTimeMin] and\
[Pool:state] eq "on" and \
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" and [$SELF:cmd_nr] ne "10" )\
\
({Log 3, "Pool_PV cmd_2 : Pool off"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")}\
{fhem("setreading Pool Pool_Button off")} )\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer Peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4 wieder außer kraft,\
## wenn während der Wartezeit die PV-Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Pool:PowerLimitOff] and\
[$SELF:wait_timer] ne "no timer" and\
[$SELF:wait_timer] ne "" and\
[Pool:state] eq "off" )\
\
({Log 3, "Pool_PV cmd_3 : Stop wait timer Pool"})\
################################################################################################################\
## 4 Eigenverbrauch einschalten: wenn PV-Produktion über dem Mindestbedarf ist und PV-Strom ins Netz eingespeist wird\
## und die Laufzeit pro Tag noch nicht erreicht ist;; Bei über 7000 Watt Einspeisung sofort aktivieren\
##\
DOELSEIF\
(([PV_Anlage_1:Total_PV_Power_reserve] >= [Pool:PowerLimitOn] and\
[[Pool:TimeStart]-[Pool:TimeEnd]] and\
[Pool:state] eq "off" and\
[Pool_Counter:pulseTimePerDay] < [Pool:RunTimePerDay]\
) or\
[PV_Anlage_1:Total_active_power_(powermeter)] <= -7000\
)\
\
({Log 3, "Pool_PV cmd_4 : Pool on"}\
{fhem("set Pool_Counter pulseTimeIncrement 0")}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 5 Steckdose für die Benutzung des Pools einschalten.\
##\
DOELSEIF\
([Pool:Pool_Button] eq "on" )\
\
({Log 3, "Pool_PV cmd_5 : Pool on for usage"}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 6 Steckdose des Pools abschalten.\
##\
DOELSEIF\
([Pool:Pool_Button] eq "off" and\
[$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7")\
\
({Log 3, "Pool_PV cmd_6 : Pool off after usage"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")} )\
################################################################################################################\
## 7 Stop wait Timer für das Abschalten, wenn die Pumpe beim Starten noch anläuft\
##\
DOELSEIF\
([shelly02:power_0] > 10 and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7" or [$SELF:cmd_nr] eq "9") and\
[$SELF:wait_timer] ne "no timer" and\
[$SELF:wait_timer] ne "" and\
[Pool:state] eq "on" )\
\
({Log 3, "Pool_PV cmd_7 : Stop wait timer Pool"})\
################################################################################################################\
## 8 Pool Ende\
##\
DOELSEIF\
([shelly02:power_0] < 10 and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7" or [$SELF:cmd_nr] eq "9") )\
\
({Log 3, "Pool_PV cmd_8 : Pool run finished"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")}\
{fhem("setreading Pool Pool_Button off")} )\
################################################################################################################\
## 9 Pflege Zwangseinschaltung: Es muss mindestens einmal pro Tag eingeschaltet werden, auch wenn kein PV Strom vorhanden war.\
##\
DOELSEIF\
([[Pool:TimeEnd]] and\
([Pool_Counter:pulseTimePerDay] < [Pool:RunTimePerDay] or\
[Pool_Counter:countsPerDay] eq 0)\
)\
\
({Log 3, "Pool_PV cmd_9 : Pool on for maintanance"}\
{fhem("set Pool_Counter pulseTimeIncrement 0")}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 10 Pflege Zwangseinschaltung bei günstigem Strom nachts im Winter\
##\
DOELSEIF\
([Astro:ObsSeason] eq "Winter" and\
[Strom_Kosten:aWATTar_Trigger] eq "on" and\
[22:00-05:00]\
)\
\
({Log 3, "Pool_PV cmd_10 : Pool on for maintanance by aWATTar"}\
{fhem("set Pool_Counter pulseTimeIncrement 0")}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 11 Abschaltung bei teurem Strom\
##\
DOELSEIF\
([Astro:ObsSeason] eq "Winter" and\
[Strom_Kosten:aWATTar_Trigger] eq "off" and\
[$SELF:cmd_nr] eq "10"\
)\
\
({Log 3, "Pool_PV cmd_11 : Pool off after maintanance by aWATTar"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")} )\
################################################################################################################\
## 12 Pool durch kürzere Laufzeit abkühlen lassen\
##\
DOELSEIF\
([06:15] and [Heizung:averageAmbientTemperature])\
\
(\
{ if ( [Heizung:averageAmbientTemperature] >= 18 )\
{fhem("setreading Pool RunTimePerDay ".ReadingsVal("Pool","RunTimePerDaySummer",0) )}\
else \
{fhem("setreading Pool RunTimePerDay ".ReadingsVal("Pool","RunTimePerDayWinter",0) )}\
},\
{Log 3, "Pool_PV cmd_12 : Pool RunTimePerDay switched"}\
)\
\

attr Pool_PV DbLogExclude .*
attr Pool_PV DbLogInclude cmd.*,state,cmd.*,Device,Pool_Pumpe_Status,wait_timer
attr Pool_PV alias Pool_PV
attr Pool_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch aus|Stop wait timer|Eigenverbrauch freigegeben|Pool ein für Benutzung|Pool aus nach Benutzung|Stop wait timer für aus|Pool aus|Pflegemodus ohne PV|Strombörse ein|Strombörse aus|RunTimePerDay switched
attr Pool_PV disable 0
attr Pool_PV do always
attr Pool_PV event-on-change-reading .*
attr Pool_PV group PV Eigenverbrauch-Steuerung
attr Pool_PV icon scene_swimming
attr Pool_PV room Strom->Photovoltaik
attr Pool_PV sortby 11
attr Pool_PV stateFormat state : Pool_Pumpe_Status
attr Pool_PV userReadings Pool_Pumpe_Status { ReadingsVal("shelly02","power_0",0)>10 ? "Pool_Pumpe_laeuft" : "Pool_Pumpe_aus"}
attr Pool_PV verbose 0
attr Pool_PV wait 0:10:0:[Pool:PowerLevelMinTime]:0:0:0:300:0:300
</syntaxhighlight>
==== RAW Definition Pool_Signale (Shelly Modul: shelly1pm) ====
<syntaxhighlight lang="Perl">
defmod shelly02 Shelly 192.168.178.52
attr shelly02 DbLogExclude .*
attr shelly02 DbLogInclude relay.*,power.*,energy.*
attr shelly02 alias Pool_Signale
attr shelly02 comment relais_0 => Pool limit 1000 W\
relail_1 => Terrasse Lichterkette limit 100 W
attr shelly02 event-on-change-reading relay.*,power.*,energy.*,state,network
attr shelly02 group PV Eigenverbrauch-Steuerung
attr shelly02 icon taster_ch_1
attr shelly02 mode relay
attr shelly02 model shelly2.5
attr shelly02 room Shelly,Strom->Photovoltaik
attr shelly02 sortby 12
attr shelly02 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
Status: %s<br>\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Gesamt 0: %08.2f KWh<br>Gesamt 1: %08.2f KWh\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
Relais 1: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
(ReadingsVal($name,"state","none") eq "OK") ? "<span style='color:#00FF00'>OK</span>":"<span style='color:#FF0000'>Error</span>",\
ReadingsVal($name,"WebLink","none") ,\
ReadingsVal($name,"energy_0",0)/1000,\
ReadingsVal($name,"energy_1",0)/1000,\
(ReadingsVal($name,"relay_0","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power_0",0),\
(ReadingsVal($name,"relay_1","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power_1",0)\
)}
attr shelly02 userReadings WebLink:network { my $ip=ReadingsVal($name,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") }
attr shelly02 verbose 0
attr shelly02 webCmd |
</syntaxhighlight>
==== RAW Definition Pool_Counter (HourCounter Modul) ====
<syntaxhighlight lang="Perl">
defmod Pool_Counter HourCounter shelly02:power_0:\s[0-9]{2,}(\.[0-9]{1,2})*$ shelly02:power_0:\s[0-9]{1}(\.[0-9]{1,2})*$
attr Pool_Counter DbLogExclude .*
attr Pool_Counter alias Pool_Counter
attr Pool_Counter comment On und Off des Pools werden direkt über den Shelly Stromverbrauch getriggert.
attr Pool_Counter event-on-change-reading .*
attr Pool_Counter group PV Eigenverbrauch-Steuerung
attr Pool_Counter icon time_timer
attr Pool_Counter interval 5
attr Pool_Counter room Strom->Photovoltaik
attr Pool_Counter sortby 13
attr Pool_Counter verbose 0
</syntaxhighlight>
==== RAW Definition rg_Pool_Status (readingsGroup Modul) ====
<syntaxhighlight lang="Perl">
defmod rg_Pool_Status readingsGroup <Device>,<Information>,<Wert> Pool:<Status>,!state Pool:<PowerLevelMinTime>,!PowerLevelMinTime Pool:<PowerLimitOn>,!PowerLimitOn Pool:<PowerLimitOff>,!PowerLimitOff Pool:<TimeStart>,!TimeStart Pool:<TimeEnd>,!TimeEnd Pool:<RunTimeMin>,!RunTimeMin Pool_Counter:<RunTimeMin>,!pulseTimeIncrement Pool:<RunTimePerDay>,!RunTimePerDay Pool:<RunTimePerDaySummer>,!RunTimePerDaySummer Pool:<RunTimePerDayWinter>,!RunTimePerDayWinter Pool_Counter:<RunTimePerDay>,!pulseTimePerDay Pool_PV:<wait>,wait_timer Pool_PV:<TimeStart>,timer_01_c04 Pool_PV:<TimeEnd>,timer_02_c04
attr rg_Pool_Status DbLogExclude .*
attr rg_Pool_Status alias Status Softube Pool Eigenverbrauch
attr rg_Pool_Status commands {state => 'state:on,off',\
PowerLevelMinTime => 'PowerLevelMinTime:selectnumbers,60,30,600,0,lin',\
PowerLimitOn => 'PowerLimitOn:selectnumbers,500,250,1500,0,lin',\
PowerLimitOff => 'PowerLimitOff:selectnumbers,0,100,1000,0,lin',\
RunTimeMin => 'RunTimeMin:selectnumbers,300,300,14400,0,lin',\
RunTimePerDaySummer => 'RunTimePerDaySummer:selectnumbers,300,300,3600,0,lin',\
RunTimePerDayWinter => 'RunTimePerDayWinter:selectnumbers,3600,900,64800,0,lin',\
TimeStart => 'TimeStart:time',\
TimeEnd => 'TimeEnd:time'}
attr rg_Pool_Status group PV Status
attr rg_Pool_Status nameStyle style="color:grey"
attr rg_Pool_Status room Strom->Photovoltaik
attr rg_Pool_Status sortby 02
attr rg_Pool_Status style style="font-size:18px"
</syntaxhighlight>

=== Beispiel Waschmaschine (mit Walzenschalter ;-) ) ===
==== RAW Definition Waschmaschine (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod Waschmaschine dummy
attr Waschmaschine DbLogExclude .*
attr Waschmaschine DbLogInclude state
attr Waschmaschine alias Waschmaschine
attr Waschmaschine group PV Eigenverbrauch
attr Waschmaschine icon scene_washing_machine
attr Waschmaschine readingList Waschmaschine_Button PowerLevelMinTime PowerPhaseUse PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay SetCmdOff SetCmdOn TimeStart TimeEnd
attr Waschmaschine room Strom->Photovoltaik
attr Waschmaschine setList Waschmaschine_Button:uzsuToggle,on,off PowerLevelMinTime:slider,30,30,300 PowerLimitOn:slider,250,250,2000 PowerLimitOff:slider,0,250,1000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,7200,300,28800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr Waschmaschine sortby 07
attr Waschmaschine stateFormat state
attr Waschmaschine verbose 0
attr Waschmaschine webCmd Waschmaschine_Button

setstate Waschmaschine off
setstate Waschmaschine 2019-12-02 10:29:49 PowerLevelMinTime 300
setstate Waschmaschine 2019-11-06 10:56:22 PowerLimitOff 250
setstate Waschmaschine 2020-04-20 13:06:04 PowerLimitOn 2000
setstate Waschmaschine 2019-12-02 15:01:18 RunTimeMin 5400
setstate Waschmaschine 2020-04-02 13:59:34 RunTimePerDay 19200
setstate Waschmaschine 2020-01-01 16:29:10 SetCmdOff set shelly03 off 0
setstate Waschmaschine 2020-01-01 16:29:24 SetCmdOn set shelly03 on 0
setstate Waschmaschine 2019-08-01 14:25:25 TimeEnd 18:00
setstate Waschmaschine 2019-10-28 09:13:30 TimeStart 09:00
setstate Waschmaschine 2020-08-27 16:17:23 Waschmaschine_Button off
setstate Waschmaschine 2020-08-28 16:29:42 state off
</syntaxhighlight>
==== RAW Definition Waschmaschine_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod Waschmaschine_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch sperren: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
## jedoch nicht wenn manueller Betrieb aktiv ist.\
##\
([Waschmaschine_Counter:pulseTimePerDay] >= [Waschmaschine:RunTimePerDay] and\
[Waschmaschine_Counter:pulseTimeIncrement] >= [Waschmaschine:RunTimeMin] and\
[Waschmaschine:state] eq "on" and [Waschmaschine:Waschmaschine_Button] eq "off" )\
\
({Log 3, "Waschmaschine cmd_1 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
{fhem("set Waschmaschine off")}\
)\
################################################################################################################\
## 2 Eigenverbrauch sperren: wenn Mindestlaufzeit erreicht wurde und die PV-Produktion unter dem Mindestbedarf ist\
## ausser bei manuellem Einschalten und wenn das Waschprogramm bereits läuft\
##\
## ([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOff] and\
## [Waschmaschine_Counter:pulseTimeIncrement] >= [Waschmaschine:RunTimeMin] and\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOn] and\
[Waschmaschine:state] eq "on" and\
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" )\
\
({Log 3, "Waschmaschine cmd_2 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
{fhem("set Waschmaschine off")}\
)\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer Peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4\
## wieder außer kraft, wenn während der Wartezeit die PV-Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOff] and\
[Waschmaschine_PV:wait_timer] ne "no timer" and\
[Waschmaschine_PV:wait_timer] ne "" and\
[Waschmaschine:state] eq "off" )\
\
({Log 3, "Waschmaschine cmd_3 : Waschmaschine stop wait timer"})\
################################################################################################################\
## 4 Eigenverbrauch freigeben: wenn PV-Produktion über dem Mindestbedarf ist und PV-Strom ins Netz eingespeist\
## wird und die Laufzeit pro Tag noch nicht erreicht ist\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] > [Waschmaschine:PowerLimitOn] and\
[Waschmaschine:state] eq "off" and\
[[Waschmaschine:TimeStart]-[Waschmaschine:TimeEnd]] and\
[Waschmaschine_Counter:pulseTimePerDay] < [Waschmaschine:RunTimePerDay] )\
\
({Log 3, "Waschmaschine cmd_4 : Waschmaschine freigabe"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOn",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist eingeschaltet")}\
{fhem("set Waschmaschine on")}\
)\
################################################################################################################\
## 5 Steckdose manuell für die Benutzung der Waschmaschine einschalten.\
##\
DOELSEIF\
([Waschmaschine:Waschmaschine_Button] eq "on" )\
\
({Log 3, "Waschmaschine cmd_5 : Waschmaschine manuell ein"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOn",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist eingeschaltet")}\
{fhem("set Waschmaschine on")}\
)\
################################################################################################################\
## 6 Steckdose der Waschmaschine manuell abschalten.\
##\
DOELSEIF\
([Waschmaschine:Waschmaschine_Button] eq "off" and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7") )\
\
({Log 3, "Waschmaschine cmd_6 : Waschmaschine manuell aus"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
{fhem("set Waschmaschine off")}\
)\
################################################################################################################\
## 7 Statuswechsel wenn das Waschprogramm gestartet ist\
##\
DOELSEIF\
([shelly03:power] > 0 and\
[shelly03:power_Waschmaschine_avg] < 70 and\
[$SELF:cmd_nr] ne "7")\
\
({Log 3, "Waschmaschine cmd_7 : Waschmaschine Programm gestarted"}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Waschprogramm gestartet")}\
)\
################################################################################################################\
## 8 Abschalten der Steckdose beim Waschprogramm Ende\
##\
DOELSEIF\
([shelly03:power] == 0 and\
[shelly03:power_Waschmaschine_avg] > 0 and\
[$SELF:cmd_nr] eq "7" )\
\
({Log 3, "Waschmaschine cmd_8 : Waschmaschine aus"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("set Waschmaschine off")}\
{fhem("setreading Waschmaschine Waschmaschine_Button off")}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Waschprogramm beendet")}\
)\
################################################################################################################\
## 9 Abschalten der Steckdose wenn die Waschmaschine nicht gebraucht wurde\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOn] and\
[[Waschmaschine:TimeEnd]-[Waschmaschine:TimeStart]] and\
[Waschmaschine:state] eq "on" and\
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" )\
\
({Log 3, "Waschmaschine cmd_9 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("set Waschmaschine off")}\
{fhem("setreading Waschmaschine Waschmaschine_Button off")}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
)
attr Waschmaschine_PV DbLogExclude .*
attr Waschmaschine_PV DbLogInclude state,STATE,cmd.*,Device,Waschmaschine_Status,wait_timer
attr Waschmaschine_PV alias Waschmaschine_PV
attr Waschmaschine_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch gesperrt|Stop wait timer|Eigenverbrauch freigegeben|Waschmaschine manuell ein|Waschmaschine manuell aus|Waschmaschine laeuft|Waschmaschine aus|Eigenverbrauch gesperrt
attr Waschmaschine_PV do always
attr Waschmaschine_PV group PV Eigenverbrauch-Steuerung
attr Waschmaschine_PV icon scene_washing_machine
attr Waschmaschine_PV room Strom->Photovoltaik
attr Waschmaschine_PV sortby 21
attr Waschmaschine_PV stateFormat state : Waschmaschine_Status
attr Waschmaschine_PV verbose 0
attr Waschmaschine_PV wait 0:0:0:[Waschmaschine:PowerLevelMinTime]:0:30:0:60:30
</syntaxhighlight>
==== RAW Definition Waschmaschine_Signale (Shelly Modul: shelly1pm) ====
<syntaxhighlight lang="Perl">
defmod shelly03 Shelly 192.168.178.54
attr shelly03 DbLogExclude .*
attr shelly03 DbLogInclude relay.*,power.*,energy.*
attr shelly03 alias Waschmaschine_Signale
attr shelly03 event-on-change-reading relay.*,power.*,energy.*,network
attr shelly03 group PV Eigenverbrauch-Steuerung
attr shelly03 icon taster_ch_1
attr shelly03 interval 60
attr shelly03 mode relay
attr shelly03 model shelly1pm
attr shelly03 room Shelly,Strom->Photovoltaik
attr shelly03 sortby 22
attr shelly03 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Gesamt 0: %08.2f KWh<br>\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
ReadingsVal($name,"WebLink","none") ,\
ReadingsVal($name,"energy",0)/1000,\
(ReadingsVal($name,"relay","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power",0)\
)}
attr shelly03 userReadings WebLink:network { my $ip=ReadingsVal($NAME,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") },\
power_Waschmaschine_avg:power.* { movingAverage($NAME,"power",300) }
attr shelly03 webCmd |
</syntaxhighlight>
==== RAW Definition Waschmaschine_Counter (HourCounter Modul) ====
<syntaxhighlight lang="Perl">
defmod Waschmaschine_Counter HourCounter Waschmaschine_PV:.*laeuft Waschmaschine_PV:Waschmaschine_Status:.*[beendet|ausgeschaltet]
attr Waschmaschine_Counter DbLogExclude .*
attr Waschmaschine_Counter alias Waschmaschine_Counter
attr Waschmaschine_Counter event-on-change-reading .*
attr Waschmaschine_Counter group PV Eigenverbrauch-Steuerung
attr Waschmaschine_Counter icon time_timer
attr Waschmaschine_Counter interval 5
attr Waschmaschine_Counter room Strom->Photovoltaik
attr Waschmaschine_Counter sortby 23
attr Waschmaschine_Counter verbose 0
</syntaxhighlight>
==== RAW Definition rg_Waschmaschine_Status (readingsGroup Modul) ====
<syntaxhighlight lang="Perl">
defmod rg_Waschmaschine_Status readingsGroup <Device>,<Information>,<Wert> Waschmaschine:<Status>,!state Waschmaschine:<PowerLevelMinTime>,!PowerLevelMinTime Waschmaschine:<PowerLimitOn>,!PowerLimitOn Waschmaschine:<PowerLimitOff>,!PowerLimitOff Waschmaschine:<TimeStart>,!TimeStart Waschmaschine:<TimeEnd>,!TimeEnd Waschmaschine:<RunTimeMin>,!RunTimeMin Waschmaschine_Counter:<RunTimeMin>,!pulseTimeIncrement Waschmaschine:<RunTimePerDay>,!RunTimePerDay Waschmaschine_Counter:<RunTimePerDay>,!pulseTimePerDay Waschmaschine_PV:<wait>,wait_timer Waschmaschine_PV:<TimeStart>,timer_01_c04 Waschmaschine_PV:<TimeEnd>,timer_02_c04
attr rg_Waschmaschine_Status DbLogExclude .*
attr rg_Waschmaschine_Status alias Status Waschmaschine Eigenverbrauch
attr rg_Waschmaschine_Status commands {state => 'state:on,off',\
PowerLevelMinTime => 'PowerLevelMinTime:selectnumbers,30,30,300,0,lin',\
PowerLimitOn => 'PowerLimitOn:selectnumbers,250,250,2000,0,lin',\
PowerLimitOff => 'PowerLimitOff:selectnumbers,0,50,800,0,lin',\
RunTimeMin => 'RunTimeMin:selectnumbers,300,300,7200,0,lin',\
RunTimePerDay => 'RunTimePerDay:selectnumbers,7200,300,28800,0,lin',\
TimeStart => 'TimeStart:time',\
TimeEnd => 'TimeEnd:time'}
attr rg_Waschmaschine_Status group PV Status
attr rg_Waschmaschine_Status nameStyle style="color:grey"
attr rg_Waschmaschine_Status room Strom->Photovoltaik
attr rg_Waschmaschine_Status sortby 03
attr rg_Waschmaschine_Status style style="font-size:18px"
</syntaxhighlight>

== Problemlösung ==

== Projekte der FHEM-Community ==

* {{Link2Forum|Topic=102297|Message=958564}} - Photovoltaik mit Eigenverbrauch Steuerung (Kostal plenticore; EM410)
* {{Link2Forum|Topic=109875|Message=1038741}} - Kostal Plenticore Bilanz
* {{Link2Forum|Topic=108191|Message=1038741}} - Kostal Plenticore, EM410 (KSEM), BYD, Solarprognose, Forecast

* {{Link2Forum|Topic=53584}} - Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
* {{Link2Forum|Topic=45176}} - Neue Version von HTTPMOD mit neuen Features zum Testen

== Links ==

* [https://www.photovoltaikforum.com/thread/142261-programmatischer-lesender-und-schreibender-zugriff-auf-kostal-plenticore-z-b-min/?pageNo=1/ Zugriff mit Python auf den Plenticore]
* [https://www.photovoltaikforum.com/thread/144350-kostenlose-wetterprognose-pv-prognose-ertragsprogonse-mit-st%C3%BCndlicher-aufl%C3%B6sung/?pageNo=1/ Ertragsprognose mit DWD]
* [https://www.photovoltaikforum.com/thread/146383-eigenverbrauchssteuerung-verh%C3%A4lt-sich-mit-speicher-anders-als-ohne/?pageNo=1/ Eigenverbrauchssteuerung beim Plenticore]
* [https://github.com/kilianknoll/ Github Kilian DWD Forecast]
* [https://github.com/FL550/ Github FL550 DWD Forecast]

[[Kategorie:IP Components]]
[[Kategorie:Other Components]]
[[Kategorie:Energieerzeugungsmessung]]

Benutzer:Plin53177

2020-09-16T06:51:23Z

Plin53177: /* Server */

==FHEM Landschaft (2020)==
[[Datei:Plin53177 landscape.PNG|rahmenlos|1261x1261px]]

==FHEM-Instanzen==
===Main===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Hausmitte
|
|-
|Hardware
|Raspberry Pi 3B
|
|-
|Peripherie
|CUL (Homematic)
SIGNALduino (433 MHz, OOK)
|für Homematic-Devices

für diverse Funkthermometer
|-
|Schwerpunkt
|Zentrale Steuerung
Funkbasierte Steuerung
|
|-
|Module
|Alarm, CUL, CUL_HM, CUL_TCM97001, CUL_TX, DOIF, Dashboard, ESPEasy, FHEM2FHEM, FHEMWEB, FLAMINGO, FLOORPLAN, FileLog, HMLAN, HMinfo, HTTPSRV, HUEBridge, HUEDevice, HourCounter, IT, LEDStripe, LightScene, MSGMail, OREGON, PRESENCE, RESIDENTS, RFHEM, ROLLO, ROOMMATE, SD_WS, SD_WS07, SIGNALduino, SVG, SYSMON, THRESHOLD, TelegramBot, Text2Speech, Weather, WifiLight, at, autocreate, autoload_undefined_devices, cmdalias, define, devStateIcon, dummy, eventTypes, laststate, notify, readingsGroup, siri, structure, telnet, weblink
|
|}

===Server===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Keller
|
|-
|Hardware
|x86-Server mit OpenSUSE Leap 15.1
|
|-
|Peripherie
|CUL (Homematic) mit hmland
|
|-
|Schwerpunkt
|IP-basierte Module/Dienste
CUL-Verlängerung für Aktoren im Keller
|
|-
|Module
|CALVIEW, CUL_HM, Calendar, DOIF, Dashboard, ESPEasy, FB_CALLLIST, FB_CALLMONITOR, FHEM2FHEM, FHEMWEB, FRITZBOX, FileLog, HTTPMOD, HTTPSRV, IPCAM, MPD, RFHEM, SIP, SIRD, STV, TelegramBot, Text2Speech, WOL, allowed, at, autocreate, autoload_undefined_devices, dummy, eventTypes, notify, onCreateEvent, plex, readingsGroup, telnet, vitoconnect, weblink
|
|-
|Sonstiges
|collectd für Fritz!Box 7490, MariaDB für diverse Anwendungen
|
|}
===Wohnzimmer===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Erdgeschoss
|
|-
|Hardware
|Raspberry Pi 2
|
|-
|Peripherie
|SIGNALduino (868 MHz, GFSK)
Lautsprecher
|für die Rolläden
|-
|Schwerpunkt
|Rolladensteuerung
Sound-Ausgabe
|
|-
|Module
|DOIF, FHEMWEB, FileLog, MsgQueue, PRESENCE, RFHEM, ROLLO, SD_Keeloq, SIGNALduino, Text2Speech, autocreate, autoload_undefined_devices, dummy, eventTypes, msgConfig, notify, structure, telnet, weblink
|
|}

===Log===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|docker container auf Server
|
|-
|Hardware
|(docker container)
|
|-
|Peripherie
|keine
|
|-
|Schwerpunkt
|Sammelt per FHEM2FHEM alle Metriken für die Visualisierung in Grafana
|
|-
|Module
|DOIF, DockerImageInfo, FHEM, FHEM2FHEM, FHEMWEB, InfluxDBLog, RFHEM, dummy, eventTypes, notify, telnet
|
|}
Wenn es bei der Speicherung von Daten in der InfluxDB zu IP-technischen Verzögerungen kommt, kann die gesamte FHEM-Instanz blockiert werden. Durch die Auslagerung in eine separate Instanz wird dies vermieden.

==Visualisierung==
===Prometheus===
für die Sammlung von collectd-Zeitreihen, node_exporter etc.
===InfluxDB===
für die Sammlung von FHEM-Zeitreihen
===Grafana===
für die übergreifende Visualisierung von Zeitreihen

Solar-/PV-Übersicht

2020-09-11T15:29:48Z

Plin53177: /* Angrenzende Themen */

<div style="float:right;margin-left:10px">__TOC__</div>
Die Seite [[Solar-/PV-Übersicht]] soll einen schnellen Einstieg in die für Solar-/Photovoltaik-Betreiber relevanten Seiten und Threads ermöglichen. Bitte bei Bedarf selbständig ergänzen.

==Forum==
Der Forenbereich {{Link2Forum|Area=Solaranlagen}} enthält Themen rund um Solaranlagen zur Wärme- oder Stromgewinnung

== Allgemein ==
* [[Fotovoltaikanlage]]
* Viele Seiten der Kategorie [[:Kategorie:Energieerzeugungsmessung|Energieerzeugungsmessung]]

==Wechselrichter==
===Kostal===
* [[KostalPiko]]
* [[Kostal Plenticore 10 Plus]]

===SMA===
* [[SMAWechselrichter]]

===Solar Edge===
* [[SolarEdge SE10k]]

===Sunways===
* [[NT5000]]

==Speicher==
* [[Sonnenspeicher]]

==Monitoring/Auswertung==
* [[Enecsys Monitoring System]]
* [[SunnyHomeManager]]
* [[Datenbankgestützte Erstellung der Energiebilanz einer SMA PV-Anlage mit Überschusseinspeisung]]
* [[SolarLog]]

==Angrenzende Themen==
Verwandte Themen, "gern verwendete" oder erforderliche Module, etc.:
* [[ModbusAttr]]
* [[SMLUSB]]
* Externer Link [https://www.photovoltaikforum.com/ Photovoltaik-Forum]

[[Kategorie:Energieerzeugungsmessung]]

Kostal Plenticore 10 Plus

2020-09-10T08:41:28Z

Plin53177: /* RAW Definition Wetter_ */

{{Infobox Hardware
|Bild=Kostal_Plenticore_10_Plus.jpg
|Bildbeschreibung=Kostal Plenticore 10 Plus
|HWProtocol=IP und RS485
|HWType=Hybrid Wechselrichter
|HWCategory=Wechselrichter
|HWComm=n/a
|HWChannels=n/a
|HWVoltage=400 V
|HWPowerConsumption=
|HWPoweredBy=3P AC
|HWSize=56,3x40,5x23,3 cm (BxHxT)
|HWDeviceFHEM=[[HTTPMOD]], [[Modbus]], [[Python3]]

|HWManufacturer=KOSTAL Solar Electric GmbH
}}
[[Bild:Plenticore FHEM 1.png|mini|900px|rechts|Die Diagramme im Überblick]]
[[Bild:Plenticore FHEM 2.png|mini|900px|rechts|Geräte Überblick mit manueller Schaltmöglichkeit]]
[[Bild:Plenticore FHEM 3.png|mini|900px|rechts|Steuerungsgeräte für die Schaltlogik]]
[[Bild:Plenticore FHEM 4.png|mini|900px|rechts|ReadingsGroup für die schnelle Parametereinstellung]]

Ein Hinweis allgemeiner Art: Die hier abgebildeten Code Stücke sind nicht ausschließlich durch mich entstanden. Ich bedanke mich für die Unterstützung und Bereitstellung vieler Einzelkomponenten durch Dritte. Der Einsatz ist auf eigene Gefahr und für etwaige Schäden wird keinerlei Haftung übernommen. Bitte beachtet bei der Hardware die Gewährleistungsbestimmungen und Vorgaben der Hersteller.

Der [[Kostal Plenticore 10 Plus]] [https://www.kostal-solar-electric.com/de-de/produkte/hybrid-wechselrichter/ Hersteller Link] ist ein Hybrid Wechselrichter mit IP-Konnektivität.

Er verfügt über einen LAN-Anschluss und ist auf die Steuerung via WebGUI des Herstellers ausgelegt. Weiterhin kann eine Abfrage mit Modbus/TCP oder auch über eine undokumentierte API erfolgen. Für die API bietet der Hersteller keinerlei Support!

== Voraussetzungen Energietechnik ==

Der Wechselrichter, der Speicher und der KSEM wurden durch einen Fachbetrieb installiert und konfiguriert. Die gesamte Anlage läuft fehlerfrei und wurde durch den Fachbetrieb abgenommen, sowie beim Netzbetreiber angemeldet.

== Geräte-Registrierung ==

Hierfür ist die Dokumentation des Herstellers heranzuziehen. Für eine Verlängerung der Gewährleistungszeit kann man den Plenticore im Herstellerportal registrieren. Dies ist jedoch für die Anbindung an FHEM nicht notwendig.

== Hersteller Dokumentation ==

Für Links auf dieser Wiki Seite wird keine Haftung übernommen. Die Inhalte unterliegen der Verantwortung der Firma Kostal.
* [https://www.kostal-solar-electric.com/de-de/service-und-support/smart-warranty/ Plenticore Plus - Verlängerung der Gewährleistungszeit]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/06/15/11/40/plenticore-plus_ba_de.pdf/ Plenticore Plus - Betriebsanleitung]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/04/12/08/26/plenticore-plus_kba.pdf/ Plenticore Plus - Kurzanleitung]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/04/12/08/26/db_plenticore-plus_de.pdf/ Plenticore Plus - Datenblatt]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/03/12/07/13/kostal_update_plenticore_piko_iq_011504581.swu/ Plenticore Plus - Software Update UI: 01.15.04581 FW: 01.43]

* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/08/30/08/53/ba_kostal_interface_modbus-tcp_sunspec.pdf/ Plenticore - Modbus\/ Sunspec]

* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/03/06/13/17/ksem-ba_de.pdf/ KSEM - Betriebsanleitung]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/03/06/13/17/ksem-db_de.pdf/ KSEM - Datenblatt]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2020/06/09/11/49/kostal_update_ksem_1_2_1.zip/ KSEM - Software Update - 1.2.1]

* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/05/09/13/57/ba_kostal_interface_ksem---201911.pdf/ KSEM - Modbus\/ Sunspec]

* [https://www.kostal-solar-electric.com/de-de/service-und-support/kontakt/ Kostal - Service Kontakt]

== Einbindung in das Netzwerk ==

Als Grundlage ist der Plenticore mit dem LAN zu verbinden, wodurch er eine TCP/IP Adresse per DHCP bekommt. Diese ist dann entweder am Display des Plenticore abzulesen, oder über die Oberfläche des Routers zu ermitteln.

Das gleiche gilt für den BYD Speicher, der jedoch zusätzlich auch über WLAN verfügt. Eine Netzwerkanbindung des Speichers ist beim Plenticore nicht zwingend notwendig, da der Plenticore mit dem Speicher über eine RS-485 Schnittstelle kommuniziert. Bei dieser Anbindung werden jedoch noch nicht alle möglichen Werte aus dem Speicher ausgelesen. Später wird hierzu jedoch noch mehr geschrieben, um alle Möglichkeiten offen zu halten.

Der KSEM kann ebenfalls auch direkt per LAN ausgelesen werden, was jedoch ebenfalls nicht zwingend notwendig ist. Eine Kommunikation des KSEM mit dem Plenticore erfolgt über zwei mögliche Wege. Beim Betrieb mit Speicher ist zwingend die RS485 Schnittstelle erforderlich, über die auch der Plenticore alle Werte übermittelt bekommt. Auch diese sind dann am Plenticore abfragbar. Der zweite Weg wäre dann über die LAN Verbindung, bei der jedoch kein Speicher am Plenticore konfigurierbar ist.

== Voraussetzungen FHEM Umfeld ==

=== Alle Geräte müssen mit TCP/IP erreichbar sein ===

=== Alle Module sollten auf einem aktuellen Stand sein ===

=== Python ===

==== Ein Python 3 sollte vorhanden sein ====
Wenn man die erweiterten Funktionalitäten, wie Statistiken, Speicher auslesen und später auch das Setzen von Werten im Plenticore, verwenden möchte.

==== Es müssen folgende Python Module vorhanden sein ====
<syntaxhighlight lang="Perl">
python3-pip

pip3 install pycryptodome
pip3 install -U fhem
</syntaxhighlight>
=== Eine LogDB/LogDBRep sollte bereits vorhanden sein, was hier nicht weiter erklärt wird. ===

=== Verwendete Module ===
<pre>
- Modbus
- HTTPMOD
- expandJSON
- DbLog
- DbRep
- dummy
- Shelly
- HourCounter
- readingsGroup
</pre>

== Einbindung in FHEM: Überblick ==

=== Hardware Anbindung (alles über LAN) ===

==== Kostal Plenticore Plus ====
===== Kostal Plenticore Plus die Basis information (Modbus/TCP) =====
Der Kostal Plenticore wird mittels des Moduls MODBUS eingebunden. Dazu gilt zunächst die folgende Konfiguration als Basis, die am Display des Plenticore oder auch in der Kostal Dokumentation zu entnehmen ist.
====== Plenticore Modbus Definition ======
<pre>
GeräteId : 71
IP-Adresse: <IP-Adresse>
Port : 1502
</pre>

====== Modbus Timing ======
Das Gerät aktualisiert sich im Abstand von 60 Sekunden durch den stetigen Modbus/TCP Datenstrom. Der Plenticore ist als Modbus Master implementiert und sendet somit alle Daten permanent ins Netzwerk.

Die Zeit kann auch verändert werden, jedoch sollte sie nicht zu kurz gewählt sein.

====== RAW Definition des konfigurations Dummy ======
Diese Dummy soll alle Konfigurationsparameter halten, auf die dann die anderen Geräte Definitionen zentral zugreifen. Hier können auch default Namen und Vorschläge für Werte in Form von Slidern und Auswahllisten hinterlegt werden.
<syntaxhighlight lang="Perl">
defmod PV_Anlage_1_config dummy
attr PV_Anlage_1_config DbLogExclude .*
attr PV_Anlage_1_config alias PV_Anlage_1_config
attr PV_Anlage_1_config comment Steht das reading module_*_count auf 0 wird diese Ausrichtung nicht berücksichtigt\
Passworte zu dieser Konfiguration liegen im Dateiverzeichnis ~./python/pwd_*.json\
\
Korrekturkurven:\
Steilheit Parallel\
verschiebung\
tempk -0.39 25\
cloudk -0.65 0\
raink -0.30 0\
Der Slider für die Steilheit wird mit - k/100 umgerechnet. 39 ==> -0.39
attr PV_Anlage_1_config event-on-change-reading .*
attr PV_Anlage_1_config group PV Eigenverbrauch
attr PV_Anlage_1_config icon solar_icon
attr PV_Anlage_1_config readingList IP-Address_Plenticore IP-Address_BYD IP-Address_KSEM IP-Address_FHEM module_1_active module_2_active module_3_active module_1_name module_2_name module_3_name module_1_direction module_2_direction module_3_direction module_1_count module_2_count module_3_count module_1_power module_2_power module_3_power module_1_plain module_2_plain module_3_plain forecast_cloudk forecast_cloudk_base forecast_raink forecast_raink_base forecast_tempk forecast_tempk_base forecast_factor
attr PV_Anlage_1_config room Strom->Photovoltaik
attr PV_Anlage_1_config setList IP-Address_Plenticore IP-Address_BYD IP-Address_KSEM IP-Address_FHEM module_1_name:East,SouthEast,South,SouthWest,West module_2_name:East,SouthEast,South,SouthWest,West module_3_name:East,SouthEast,South,SouthWest,West module_1_direction:slider,-90,5,+90 module_2_direction:slider,-90,5,90 module_3_direction:slider,-90,5,90 module_1_count:slider,0,1,40 module_2_count:slider,0,1,40 module_3_count:slider,0,1,40 module_1_power:slider,250,10,400 module_2_power:slider,250,10,400 module_3_power:slider,250,10,400 module_1_plain:slider,15,1,45 module_2_plain:slider,15,1,45 module_3_plain:slider,15,1,45 forecast_cloudk:slider,0,1,100 forecast_cloudk_base:slider,0,1,10 forecast_raink:slider,0,1,100 forecast_raink_base:slider,0,1,10 forecast_tempk:slider,0,1,100 forecast_tempk_base:slider,10,1,30 forecast_factor:1,1.5,2,2.5,3,3.5,4,4.5,5
attr PV_Anlage_1_config sortby 06
attr PV_Anlage_1_config verbose 0
</syntaxhighlight>

====== RAW Definition des Wechselrichters ======
<syntaxhighlight lang="Perl">
defmod PV_Anlage_1 ModbusAttr 71 60 <IP-Address_Plenticore>:1502 TCP
attr PV_Anlage_1 DbLogExclude .*
attr PV_Anlage_1 DbLogInclude Act_state_of_charge,Actual_battery_charge_-minus_or_discharge_-plus_Power,Actual_battery_charge_usable_Power,Battery_temperature,Home_own_consumption_from_PV,Home_own_consumption_from_battery,Home_own_consumption_from_grid,Inverter_state,Power_DC1,Power_DC2,Power_DC_Sum,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Voltage_DC1,Voltage_DC2,.*_yield,Solar_.*
attr PV_Anlage_1 alias PV_Einspeisung
attr PV_Anlage_1 comment Kostal Plenticore 10 Plus mit BYD Speicher
attr PV_Anlage_1 dev-h-defFormat %.2f
attr PV_Anlage_1 dev-h-defLen 2
attr PV_Anlage_1 dev-h-defPoll 1
attr PV_Anlage_1 dev-h-defRevRegs 1
attr PV_Anlage_1 dev-h-defUnpack f>
attr PV_Anlage_1 dev-type-STR-format %s
attr PV_Anlage_1 dev-type-STR-len 8
attr PV_Anlage_1 dev-type-STR-revRegs 0
attr PV_Anlage_1 dev-type-STR-unpack a*
attr PV_Anlage_1 event-on-change-reading Act_state_of_charge,Actual_battery_charge_.*,Battery_temperature,Home_own_consumption_from_.*,Inverter_state,Power_DC1,Power_DC2,Power_DC_Sum,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Voltage_DC1,Voltage_DC2,.*_yield,Solar_.*
attr PV_Anlage_1 group PV Eigenverbrauch
attr PV_Anlage_1 icon sani_solar
attr PV_Anlage_1 obj-h100-reading Total_DC_Power
attr PV_Anlage_1 obj-h104-format %s
attr PV_Anlage_1 obj-h104-reading State_of_energy_manager
attr PV_Anlage_1 obj-h104-revRegs 0
attr PV_Anlage_1 obj-h104-unpack N
attr PV_Anlage_1 obj-h106-reading Home_own_consumption_from_battery
attr PV_Anlage_1 obj-h108-reading Home_own_consumption_from_grid
attr PV_Anlage_1 obj-h110-reading Total_home_consumption_Battery
attr PV_Anlage_1 obj-h112-reading Total_home_consumption_Grid
attr PV_Anlage_1 obj-h114-reading Total_home_consumption_PV
attr PV_Anlage_1 obj-h116-reading Home_own_consumption_from_PV
attr PV_Anlage_1 obj-h118-reading Total_home_consumption
attr PV_Anlage_1 obj-h120-reading Isolation_resistance
attr PV_Anlage_1 obj-h122-reading Power_limit_from_EVU
attr PV_Anlage_1 obj-h124-reading Total_home_consumption_rate
attr PV_Anlage_1 obj-h14-reading Inverter_serial_number
attr PV_Anlage_1 obj-h14-type STR
attr PV_Anlage_1 obj-h144-reading Worktime
attr PV_Anlage_1 obj-h150-reading Actual_cos_phi
attr PV_Anlage_1 obj-h152-reading Grid_frequency
attr PV_Anlage_1 obj-h154-reading Current_Phase_1
attr PV_Anlage_1 obj-h156-reading Active_power_Phase_1
attr PV_Anlage_1 obj-h158-reading Voltage_Phase_1
attr PV_Anlage_1 obj-h160-reading Current_Phase_2
attr PV_Anlage_1 obj-h162-reading Active_power_Phase_2
attr PV_Anlage_1 obj-h164-reading Voltage_Phase_2
attr PV_Anlage_1 obj-h166-reading Current_Phase_3
attr PV_Anlage_1 obj-h168-reading Active_power_Phase_3
attr PV_Anlage_1 obj-h170-reading Voltage_Phase_3
attr PV_Anlage_1 obj-h172-reading Total_AC_active_power
attr PV_Anlage_1 obj-h174-reading Total_AC_reactive_power
attr PV_Anlage_1 obj-h178-reading Total_AC_apparent_power
attr PV_Anlage_1 obj-h190-reading Battery_charge_current
attr PV_Anlage_1 obj-h194-format %.0f
attr PV_Anlage_1 obj-h194-reading Number_of_battery_cycles
attr PV_Anlage_1 obj-h200-reading Actual_battery_charge_-minus_or_discharge_-plus_current
attr PV_Anlage_1 obj-h202-reading PSSB_fuse_state
attr PV_Anlage_1 obj-h208-format %.0f
attr PV_Anlage_1 obj-h208-reading Battery_ready_flag
attr PV_Anlage_1 obj-h210-reading Act_state_of_charge
attr PV_Anlage_1 obj-h212-reading Battery_state
attr PV_Anlage_1 obj-h214-reading Battery_temperature
attr PV_Anlage_1 obj-h216-reading Battery_voltage
attr PV_Anlage_1 obj-h218-reading Cos_phi_(powermeter)
attr PV_Anlage_1 obj-h220-reading Frequency_(powermeter)
attr PV_Anlage_1 obj-h222-reading Current_phase_1_(powermeter)
attr PV_Anlage_1 obj-h224-reading Active_power_phase_1_(powermeter)
attr PV_Anlage_1 obj-h226-reading Reactive_power_phase_1_(powermeter)
attr PV_Anlage_1 obj-h228-reading Apparent_power_phase_1_(powermeter)
attr PV_Anlage_1 obj-h230-reading Voltage_phase_1_(powermeter)
attr PV_Anlage_1 obj-h232-reading Current_phase_2_(powermeter)
attr PV_Anlage_1 obj-h234-reading Active_power_phase_2_(powermeter)
attr PV_Anlage_1 obj-h236-reading Reactive_power_phase_2_(powermeter)
attr PV_Anlage_1 obj-h238-reading Apparent_power_phase_2_(powermeter)
attr PV_Anlage_1 obj-h240-reading Voltage_phase_2_(powermeter)
attr PV_Anlage_1 obj-h242-reading Current_phase_3_(powermeter)
attr PV_Anlage_1 obj-h244-reading Active_power_phase_3_(powermeter)
attr PV_Anlage_1 obj-h246-reading Reactive_power_phase_3_(powermeter)
attr PV_Anlage_1 obj-h248-reading Apparent_power_phase_3_(powermeter)
attr PV_Anlage_1 obj-h250-reading Voltage_phase_3_(powermeter)
attr PV_Anlage_1 obj-h252-reading Total_active_power_(powermeter)
attr PV_Anlage_1 obj-h254-reading Total_reactive_power_(powermeter)
attr PV_Anlage_1 obj-h256-reading Total_apparent_power_(powermeter)
attr PV_Anlage_1 obj-h258-reading Current_DC1
attr PV_Anlage_1 obj-h260-reading Power_DC1
attr PV_Anlage_1 obj-h266-reading Voltage_DC1
attr PV_Anlage_1 obj-h268-reading Current_DC2
attr PV_Anlage_1 obj-h270-reading Power_DC2
attr PV_Anlage_1 obj-h276-reading Voltage_DC2
attr PV_Anlage_1 obj-h278-reading Current_DC3
attr PV_Anlage_1 obj-h280-reading Power_DC3
attr PV_Anlage_1 obj-h286-reading Voltage_DC3
attr PV_Anlage_1 obj-h320-reading Total_yield
attr PV_Anlage_1 obj-h322-reading Daily_yield
attr PV_Anlage_1 obj-h324-reading Yearly_yield
attr PV_Anlage_1 obj-h326-reading Monthly_yield
attr PV_Anlage_1 obj-h38-reading Software-Version_Maincontroller_(MC)
attr PV_Anlage_1 obj-h38-type STR
attr PV_Anlage_1 obj-h384-len 16
attr PV_Anlage_1 obj-h384-reading Inverter_network_name
attr PV_Anlage_1 obj-h384-type STR
attr PV_Anlage_1 obj-h420-reading IP-address
attr PV_Anlage_1 obj-h420-type STR
attr PV_Anlage_1 obj-h428-reading IP-subnetmask
attr PV_Anlage_1 obj-h428-type STR
attr PV_Anlage_1 obj-h436-reading IP-gateway
attr PV_Anlage_1 obj-h436-type STR
attr PV_Anlage_1 obj-h446-reading IP-DNS1
attr PV_Anlage_1 obj-h446-type STR
attr PV_Anlage_1 obj-h454-reading IP-DNS2
attr PV_Anlage_1 obj-h454-type STR
attr PV_Anlage_1 obj-h46-reading Software-Version_IO-Controller_(IOC)
attr PV_Anlage_1 obj-h46-type STR
attr PV_Anlage_1 obj-h514-len 1
attr PV_Anlage_1 obj-h514-reading Battery_actual_SOC
attr PV_Anlage_1 obj-h517-reading Battery_Manufacturer
attr PV_Anlage_1 obj-h517-type STR
attr PV_Anlage_1 obj-h525-format %c
attr PV_Anlage_1 obj-h525-reading Battery_Model_ID
attr PV_Anlage_1 obj-h525-unpack N
attr PV_Anlage_1 obj-h527-format %c
attr PV_Anlage_1 obj-h527-reading Battery_Serial_Number
attr PV_Anlage_1 obj-h529-len 4
attr PV_Anlage_1 obj-h529-reading Work_Capacity
attr PV_Anlage_1 obj-h529-unpack N
attr PV_Anlage_1 obj-h531-format %.0f
attr PV_Anlage_1 obj-h531-reading Inverter_Max_Power
attr PV_Anlage_1 obj-h531-unpack N
attr PV_Anlage_1 obj-h535-revRegs 0
attr PV_Anlage_1 obj-h535-unpack n
attr PV_Anlage_1 obj-h551-revRegs 0
attr PV_Anlage_1 obj-h559-revRegs 0
attr PV_Anlage_1 obj-h56-format %.0f
attr PV_Anlage_1 obj-h56-reading Inverter_state
attr PV_Anlage_1 obj-h56-unpack N
attr PV_Anlage_1 obj-h575-len 1
attr PV_Anlage_1 obj-h575-reading Inverter_Generation_Power_(actual)
attr PV_Anlage_1 obj-h577-len 2
attr PV_Anlage_1 obj-h577-reading Generation_Energy
attr PV_Anlage_1 obj-h577-unpack N
attr PV_Anlage_1 obj-h578-reading Total_energy
attr PV_Anlage_1 obj-h582-reading Actual_battery_charge-discharge_power
attr PV_Anlage_1 obj-h586-format %s
attr PV_Anlage_1 obj-h586-reading Battery_Firmware
attr PV_Anlage_1 obj-h586-unpack N
attr PV_Anlage_1 obj-h588-format %s
attr PV_Anlage_1 obj-h588-len 1
attr PV_Anlage_1 obj-h588-reading Battery_Type
attr PV_Anlage_1 obj-h588-unpack N
attr PV_Anlage_1 obj-h6-reading Inverter_article_number
attr PV_Anlage_1 obj-h6-type STR
attr PV_Anlage_1 obj-h768-len 32
attr PV_Anlage_1 obj-h768-reading Productname
attr PV_Anlage_1 obj-h768-type STR
attr PV_Anlage_1 obj-h800-len 32
attr PV_Anlage_1 obj-h800-reading Power_class
attr PV_Anlage_1 obj-h800-type STR
attr PV_Anlage_1 room Strom->Photovoltaik
attr PV_Anlage_1 sortby 01
attr PV_Anlage_1 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TH ALIGN=\"MIDDLE\" WIDTH=\"20\">Batterie %s</TH>\
<TH ALIGN=\"MIDDLE\" WIDTH=\"20\">aktuell</TH>\
<TH ALIGN=\"RIGHT\" WIDTH=\"20\">Hausverbrauch</TH>\
<TH ALIGN=\"MIDDLE\" WIDTH=\"20\">Erträge</TH>\
</TR>\
\
<TR>\
<TD ALIGN=\"MIDDLE\" WIDTH=\"20\">\
Leistung: %04d W<br>\
Temp.: %02.1f °C<br>\
Ladung total: %2d %%<br>\
Ladung Res.: %04d Wh\
</TD>\
\
<TD ALIGN=\"RIGHT\" WIDTH=\"20\">\
DC total: %05d W<br>\
<br>\
<br>\
PV reserve: %05d W\
</TD>\
\
<TD ALIGN=\"RIGHT\" WIDTH=\"20\">\
von PV: %05d W <br>\
von Batterie: %05d W<br>\
vom Netz: %05d W<br>\
ins Haus: %05d W<br>\
Netz: %05d W\
</TD>\
\
<TD ALIGN=\"RIGHT\" WIDTH=\"20\">\
Tag: %05d KWh <br>\
Monat: %05d KWh<br>\
Jahr: %05d KWh<br>\
Total: %05d KWh\
</TD>\
</TR>\
\
</TABLE>\
" , \
(ReadingsVal($name,"Actual_battery_charge_-minus_or_discharge_-plus_Power",0) lt 0) ? "<span style='color:#00FF00'>Laden</span>":"<span style='color:#FF0000'>Entladen</span>" ,\
\
ReadingsVal($name,"Actual_battery_charge_-minus_or_discharge_-plus_Power",0),\
ReadingsVal($name,"Battery_temperature",0) ,\
ReadingsVal($name,"Act_state_of_charge",0) ,\
ReadingsVal($name,"Actual_battery_charge_usable_Power",0) ,\
\
ReadingsVal($name,"Power_DC_Sum","0"),\
ReadingsVal($name,"Total_PV_Power_reserve","0"),\
\
ReadingsVal($name,"Home_own_consumption_from_PV",0) ,\
ReadingsVal($name,"Home_own_consumption_from_battery",0) ,\
ReadingsVal($name,"Home_own_consumption_from_grid",0),\
ReadingsVal($name,"Home_own_consumption_from_PV",0) +ReadingsVal($name,"Home_own_consumption_from_battery",0)+ReadingsVal($name,"Home_own_consumption_from_grid",0),\
ReadingsVal($name,"Total_active_power_(powermeter)",0),\
\
round(ReadingsVal($name,"Daily_yield",0)/1000 ,0),\
round(ReadingsVal($name,"Monthly_yield",0)/1000 ,0) ,\
round(ReadingsVal($name,"Yearly_yield",0)/1000 ,0) ,\
round(ReadingsVal($name,"Total_yield",0)/1000 ,0)\
)}
attr PV_Anlage_1 userReadings Power_DC_Sum:Total_DC_Power.* { ReadingsVal($NAME,"Power_DC1","0")+ReadingsVal($NAME,"Power_DC2","0") },\
\
Total_PV_Power_reserve:Total_DC_Power.* {my $reserve = ReadingsVal($NAME,"Power_DC_Sum","0") * 0.90 - ReadingsVal($NAME,"Home_own_consumption_from_PV","0");;;; ($reserve lt 0)?0:round($reserve,3) },\
\
Total_DC_Power_Max:Total_DC_Power.* { my $Bat_out = (ReadingsVal($NAME,"Actual_battery_charge_-minus_or_discharge_-plus_current","0")*ReadingsVal($NAME,"Battery_voltage","0"));;;; ($Bat_out gt 0)?ReadingsVal($NAME,"Power_DC_Sum","0") + $Bat_out :ReadingsVal($NAME,"Power_DC_Sum","0") },\
\
Actual_battery_charge_-minus_or_discharge_-plus_Power:Actual_battery_charge_-minus_or_discharge_-plus_current.* {round((ReadingsVal($NAME,"Actual_battery_charge_-minus_or_discharge_-plus_current","0")*ReadingsVal($NAME,"Battery_voltage","0")),0)},\
\
Actual_battery_charge_usable_Power:Act_state_of_charge.* {my $x = (8960*(ReadingsVal($NAME,"Act_state_of_charge","0")-10)/100);;;; ($x lt 0)?0:round($x,0) }
attr PV_Anlage_1 verbose 0
</syntaxhighlight>

====== Userreadings ======
Um später einige Abfragen und Diagramme einfacher zu erstellen wurden einige userreadings erstellt, die bereits bei der RAW Definition mit vorhanden sind. Während der Integration in FHEM und der Konfiguration kann es hierdurch jedoch noch Fehlermeldungen im FHEM Log geben, da noch nicht alle Werte vorhanden sind. Dies betrifft insbesondere die Statistics_* readings, die durch ein Python Skript später erzeugt werden.

Power_DC_Sum
Trigger: Total_DC_Power.*
Dies berechnet direkt die Summe der DC-Leistung. Wenn der Plenticore einen Speicher hat, wird dieser am String 3 angeschlossen,
sollte also kein Speicher vorhanden sein muss man hier den dritten String auch noch addieren.
Total_PV_Power_reserve
Trigger: Total_DC_Power.*
Hier wird ein reading erstellt, dass als Information über die verwendbare Reserve dient. Die Leistung, die in den Speicher geht
sollte man nämlich besser sofort verbrauchen, anstatt es erst zu speicher. Die 0.90 ist ein circa Wirkungsgrad, um von DC- auf AC-Leistung zu kommen.
Der Total_PV_Power_reserve Wert kann gerne nach eigenen Belangen kalkuliert werden.
Total_DC_Power_Max
Trigger: Total_DC_Power.*
Um die Batterieleistung mit zu berücksichtigen wird dieser Momentan Wert ermittelt.
Actual_battery_charge_-minus_or_discharge_-plus_Power
Trigger: Actual_battery_charge_-minus_or_discharge_-plus_current.*
Berechnung der Batterie Leistung aus Spannung und Strom , der wert kann positiv oder negativ sein, je nach dem ob geladen oder entladen wird.
Actual_battery_charge_usable_Power
Trigger: Act_state_of_charge.*
Dieser Wert gibt an, wieviel Leistung im Speicher vorhanden ist, reduziert um 10% Verluste. An dieser Stelle muss die Nennleistung des Speichers
eingetragen werden, da diese noch nicht ausgelesen werden kann. Obwohl es im "Battery_Type 892941625" stecken könnte. 8929 >> 8.93 KW ???

===== Kostal Plenticore Plus die API (über HTTPMOD mit Python Skript Authentifizierung) =====
Der Plenticore erstellt intern noch diverse Statistiken, die auch über das WebGUI angesehen werden können. Diese werden jedoch nicht über MODBUS/TCP ausgegeben, aber zum Kostal Portal übermittelt, wo man dann bereits in Form von Diagrammen einen schönen Überblick bekommt. Das Ziel ist jedoch die Statistiken lokal im FHEM abzulegen, sie lassen sich nur über die API des Plenticore abfragen.
Für diesen API Zugang über HTTP steht nun ein neues Gerät zur Verfügung, dass mit HTTPMOD und Python Authentifizierungsskripten die mehrstufige Anmeldung durchführt. Das ganze soll in Zukunft den starren Zugriff auf die Statistiken ablösen und eine Erweiterung zum setzen von Parametern im Plenticore bieten.

====== Umstellungsaufwand, falls jemand früher eingestiegen ist. ======
Die erste Folge für den Umstieg ist, dass die Statistiken nicht mehr im PV_Anlage_1 Gerät abgelegt werden, da diese ja teil der API Abfrage sind. Das muss dann in der Bilanz berücksichtigt werden, da die Einträge dann unter dem neuen PV_Anlage_1_API Gerät abgelegt werden.

2020.09.06 Die Umstellung auf das Plenticore API Gerät hat begonnen

- Die Bilanz RAW Definition wurde aktualisiert

- In der PV_Schedule Definition wurde das Kommando für die Aktualisierung der Statistik auf PV_Anlage_1_API umgestellt

- Das Logging von Dum.Energy läuft wie gehabt weiter

- Die Statistic_* readings aus dem PV_Anlage_1 Gerät können in der SQL Datenbank zum neuen PV_Anlage_1_API Gerät verschoben werden.
<syntaxhighlight lang="SQL">
## Bitte zuerst den Zeitraum, in dem die Statistikeinträge in die Datenbank geschrieben wurden feststellen.
MySQL [fhem]> SELECT TIMESTAMP,DEVICE,READING,VALUE FROM history WHERE DEVICE='PV_Anlage_1_API' AND READING LIKE 'Statistic_%' AND TIMESTAMP > '2020-07-01 00:00:00' ORDER BY TIMESTAMP LIMIT 500;
## Für den Update dann din Zeitraum so weit es geht einschränken, damit die Laufzeit in der Datenbank nicht so hoch wird.
MySQL [fhem]> UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API' WHERE DEVICE='PV_Anlage_1' AND READING LIKE 'Statistic_%' AND TIMESTAMP > '2020-07-01 00:00:00';
</syntaxhighlight>
- Die alten Statistic_* readings können nun aus dem PV_Anlage_1 Gerät entfernt werden
<syntaxhighlight lang="Perl">
deletereading PV_Anlage_1 Statistic_.*
deletereading PV_Anlage_1 statistics_.*
</syntaxhighlight>
- Für das Logging kann nun im Attribut "DbLogInclude" ebenfalls "Statistic_.*" entfernt werden

- Beim Attribut "event-on-change-reading" sind auch "statistics_.*,Statistic_.*" zu entfernen

- Das userreading im PV_Anlage_1 kann ebenfalls geändert werden und um diese Zeile verkürzt werden.
<syntaxhighlight lang="Perl">
statistics_clean:statistics_output.* { my $x = ReadingsVal($NAME,"statistics_output",0);; $x =~ s/"moduleid": "scb:statistic:EnergyFlow", |, "moduleid": "scb:statistic:EnergyFlow"|"processdata": \[//g;; $x =~ s/id": "|, "unit": "", "value"|^\[|\]\}\]$//g;; $x =~ s/moduleid/statistics_00_moduleid/g;; $x =~ s/processdata/statistics/g;; $x =~ s/\}\, \{/\, /g;; $x =~ s/\{\{/\{/g;; return $x }
</syntaxhighlight>
- Nun noch das Gerät Plenticore_Statistics für das expandJSON löschen
<syntaxhighlight lang="Perl">
delete Plenticore_Statistics
</syntaxhighlight>
Das sollten nun alle erforderlichen Bereinigungen für den Wechsel auf das PV_Anlage_1_API Gerät sein.

====== Plenticore API ======
<syntaxhighlight lang="Perl">
http://<IP-Address_Plenticore>/api/v1
</syntaxhighlight>

====== Dateiverzeichnis ======
<pre>
/opt/fhem
/opt/fhem/python/pwd_fhem.json
/opt/fhem/python/pwd_plenticore.json
/opt/fhem/python/bin
/opt/fhem/python/bin/plenticore_auth_finish.py
/opt/fhem/python/bin/plenticore_auth_session.py
</pre>

====== Python 3 ======
<pre>
fhem@raspberrypi:~/python/bin$ which python3
/usr/bin/python3
fhem@raspberrypi:~/python/bin$ python3 --version
Python 3.7.3
</pre>

====== Passworte ======
Die Passworte für den Plenticore und den FHEM Zugang liegen in einzelnen JSON Dateien

fhem@raspberrypi:~/python$ cat pwd_plenticore.json
<pre>
{
"username": "user",
"password": "<Steht auf dem Gehäuse>"
}
</pre>

fhem@raspberrypi:~/python$ cat pwd_fhem.json
<pre>
{
"username": "<Ein Fhem Telnet User>",
"password": "<Das Passwort des Users>"
}
</pre>

====== plenticore_auth_* Erläuterung ======
Die folgenden beiden Skripte sind ein Extrakt aus den bisherigen Skripten, ohne die HTTP Aufrufe. Sie dienen nur noch der Generierung von Authentifizierungsschlüsseln. Optimaler Weise müssten sie auch noch nach Perl konvertiert werden, was für später geplant ist.
Als Übergabeparameter werden aus dem PV_Anlage_1_API Gerät Rückgabewerte der HTTP Aufrufe verwendet.

====== plenticore_auth_finish ======
fhem@raspberrypi:~/python/bin$ cat plenticore_auth_finish.py
<syntaxhighlight lang="Python">
import string
import base64
import hashlib
import hmac
from Crypto.Cipher import AES
import binascii

import sys
import json
import fhem

web = sys.argv[1]
randomString = sys.argv[2]
nonce = sys.argv[3]
salt = sys.argv[4]
rounds = sys.argv[5]

try:
with open('/opt/fhem/python/pwd_plenticore.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

PASSWD = credentials["password"]

u = randomString

#u = base64.b64encode(u.encode('utf-8')).decode('utf-8')
#print("randomString: ",u)

i = nonce
o = int(rounds)
a = salt
bitSalt = base64.b64decode(a)

#print("nonce : ",i)
#print("salt : ",a)
#print("rounds : ",o)

def getPBKDF2Hash(password, bytedSalt, rounds):
return hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), bytedSalt, rounds)

r = getPBKDF2Hash(PASSWD,bitSalt,o)
s = hmac.new(r, "Client Key".encode('utf-8'), hashlib.sha256).digest()
c = hmac.new(r, "Server Key".encode('utf-8'), hashlib.sha256).digest()
_ = hashlib.sha256(s).digest()
d = "n=user,r="+u+",r="+i+",s="+a+",i="+str(o)+",c=biws,r="+i
g = hmac.new(_, d.encode('utf-8'), hashlib.sha256).digest()
p = hmac.new(c, d.encode('utf-8'), hashlib.sha256).digest()
f = bytes(a ^ b for (a, b) in zip(s, g))
proof = base64.b64encode(f).decode('utf-8')

try:
with open('/opt/fhem/python/pwd_fhem.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

fh = fhem.Fhem(web, protocol="http", port=8083, username=credentials["username"], password=credentials["password"])

fh.send_cmd("setreading PV_Anlage_1_API auth_proof " + proof)

#print("proof : ",proof)
</syntaxhighlight>
====== plenticore_auth_session ======
fhem@raspberrypi:~/python/bin$ cat plenticore_auth_session.py
<syntaxhighlight lang="Python">
import string
import base64
import hashlib
import os
import hmac
from Crypto.Cipher import AES
import binascii

import sys
import json
import fhem

web = sys.argv[1]
randomString = sys.argv[2]
nonce = sys.argv[3]
salt = sys.argv[4]
rounds = sys.argv[5]
token = sys.argv[6]

try:
with open('/opt/fhem/python/pwd_plenticore.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

PASSWD = credentials["password"]

u = randomString
i = nonce
o = int(rounds)
a = salt
bitSalt = base64.b64decode(a)

def getPBKDF2Hash(password, bytedSalt, rounds):
return hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), bytedSalt, rounds)

r = getPBKDF2Hash(PASSWD,bitSalt,o)

#print("randomString: ",u)
#print("nonce : ",i)
#print("salt : ",a)
#print("rounds : ",o)
#print("token : ",token)

s = hmac.new(r, "Client Key".encode('utf-8'), hashlib.sha256).digest()
_ = hashlib.sha256(s).digest()
d = "n=user,r="+u+",r="+i+",s="+a+",i="+str(o)+",c=biws,r="+i

y = hmac.new(_, "Session Key".encode('utf-8'), hashlib.sha256)
y.update(d.encode('utf-8'))
y.update(s)
P = y.digest()
protocol_key = P
t = os.urandom(16)

e2 = AES.new(protocol_key,AES.MODE_GCM,t)
e2, authtag = e2.encrypt_and_digest(token.encode('utf-8'))

iv = base64.b64encode(t).decode('utf-8')
authtag = base64.b64encode(authtag).decode("utf-8")
payload = base64.b64encode(e2).decode('utf-8')

try:
with open('/opt/fhem/python/pwd_fhem.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

fh = fhem.Fhem(web, protocol="http", port=8083, username=credentials["username"], password=credentials["password"])

fh.send_cmd("setreading PV_Anlage_1_API auth_iv " + iv)
fh.send_cmd("setreading PV_Anlage_1_API auth_authtag " + authtag)
fh.send_cmd("setreading PV_Anlage_1_API auth_payload " + payload)

#print("iv : ",iv)
#print("authtag : ",authtag)
#print("payload : ",payload)
</syntaxhighlight>

====== Ablaufbeschreibung PV_Anlage_1_API ======
Hier soll ein kurzer Überblick für den Anmeldeablauf geschaffen werden.
======Automatischer Login mit Sessionaufbau======
Der Ablauf startet mit dem ersten Aufruf und läuft dann vollautomatisch bis zur Rückgabe der auth_sessionId
1. get PV_Anlage_1_API 01/auth/start
* auth_randomString64 - wird generiert
* /api/v1/auth/start - HTTP request erfolgt
* auth_nonce, auth_salt, auth_rounds werden empfangen
2. auth_Step1_Message:auth_nonce.* wird getriggert
* plenticore_auth_finish.py wird ausgeführt
* auth_proof - wird berechnet
3. auth_Step2_Message:auth_proof.* wird getriggert
* Start von 02_/auth/finish
4. get PV_Anlage_1_API 02_/auth/finish
* /api/v1/auth/finish - HTTP request erfolgt
* auth_signature, auth_token werden empfangen
5. auth_Step3_Message:auth_token.* wird getriggert
* plenticore_auth_session.py wird ausgeführt
* auth_iv, auth_authtag, auth_payload - wird berechnet
6. auth_Step4_Message:auth_payload.* wird getriggert
* Start von 03_/auth/session
7. get PV_Anlage_1_API 03_/auth/session
* /api/v1/auth/session - HTTP request erfolgt
* auth_sessionId wird empfangen

Bei allen folgenden HTTP requests wird nun die erhaltene auth_sessenId übermittelt.

Bereits Implementierte Abfragen:

get:

start, finish, create_session werden für den Login benötigt und arbeiten über userreadings mit zwei Python Skripten zusammen

01_/auth/start

02_/auth/finish

03_/auth/create_session

Auskunft über den Anmeldezustand, es muss aber kurz vorher abgefragt werden

04_/auth/me

Informationen zum Plenticore

05_/info/version

Abfrage der Statistiken

20_/processdata/scb_statistic_EnergyFlow

Liste aller Plenticore Module. Es werden keine readings erzeugt. Das Ergebnis steht im httpbody, der mit attr <Device> showBody 1 angezeigt werden kann.

21_/modules_list

Hier gibt es viele technische Loggings. Sollte es Probleme beim Abholen der Daten geben kann es am timeout liegen

24_/logdata/download

Speicher Typen wurden folgende ermittelt 0=keine , 4=BYD

Diese Abfragewerte können auch gesetzt werden, siehe set Befehle

31_Battery_Type

32_Battery_MinHomeComsumption

33_Battery_Strategy

34_Battery_MinSoc

35_Battery_SmartBatteryControl_Enable

36_Battery_DynamicSoc_Enable

Das zeigt den FW Update Status beim FW Laden an. Die Rückmeldung ist im httpbody zu sehen, es werden keine readings erzeugt.

41_/update/status

set:

Eine bestehende Session wird abgemeldet

06_/auth/logout

Die letzten Events können in deutsch oder englisch abgeholt werden

23_/events/latest_5 [en-gb,de-de]

Batterie Einstellungen können verändert werden. Es werden einige Werte vorgeschlagen. Bitte vorher immer den aktuellen Wert abfragen und besser aufschreiben!

Hier sollte nur etwas gesetzt werden, wenn man sich sicher ist, was man tut.

31_Battery_Type [0,4]

32_Battery_MinHomeComsumption

33_Battery_Strategy

34_Battery_MinSoc

35_Battery_SmartBatteryControl_Enable

36_Battery_DynamicSoc_Enable

Der Reboot läuft noch nicht. Da ist die API ziemlich zickig. Ich habe jedoch bereits ein Skript, womit es geht :-)

51_/system/reboot

Sollte die Session abgelaufen, oder noch kein Login vollzogen worden sein, so wird automatisch eine Login mit Sessionaufbau durchgeführt.

====== RAW Definition des PV_Anlage_1_API ======
<syntaxhighlight lang="Perl">
defmod PV_Anlage_1_API HTTPMOD http://%IP-Address_Plenticore%/api/v1/auth/me 0

attr PV_Anlage_1_API DbLogExclude .*
attr PV_Anlage_1_API DbLogInclude Statistic_.*
attr PV_Anlage_1_API authRetries 1
attr PV_Anlage_1_API dontRequeueAfterAuth 1
attr PV_Anlage_1_API enableControlSet 0
attr PV_Anlage_1_API enableCookies 1
attr PV_Anlage_1_API get01Data {"nonce": "%randomString64%","username": "user"}
attr PV_Anlage_1_API get01Name 01_/auth/start
attr PV_Anlage_1_API get01URL http://%IP-Address_Plenticore%/api/v1/auth/start
attr PV_Anlage_1_API get02-1Name auth_signature
attr PV_Anlage_1_API get02-2Name auth_token
attr PV_Anlage_1_API get02Data {"transactionId": "%auth_transactionId%", "proof": "%auth_proof%"}
attr PV_Anlage_1_API get02JSON .
attr PV_Anlage_1_API get02Name 02_/auth/finish
attr PV_Anlage_1_API get02URL http://%IP-Address_Plenticore%/api/v1/auth/finish
attr PV_Anlage_1_API get03Data {"transactionId": "%auth_transactionId%", "iv": "%auth_iv%", "tag": "%auth_authtag%", "payload": "%auth_payload%"}
attr PV_Anlage_1_API get03Name 03_/auth/create_session
attr PV_Anlage_1_API get03URL http://%IP-Address_Plenticore%/api/v1/auth/create_session
attr PV_Anlage_1_API get04-1Name auth_me_active
attr PV_Anlage_1_API get04-2Name auth_me_locked
attr PV_Anlage_1_API get04-3Name auth_me_authenticated
attr PV_Anlage_1_API get04-4Name auth_me_anonymous
attr PV_Anlage_1_API get04-5Name auth_me_role
attr PV_Anlage_1_API get04-6Name auth_me_permissions
attr PV_Anlage_1_API get04Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get04JSON .
attr PV_Anlage_1_API get04Name 04_/auth/me
attr PV_Anlage_1_API get04URL http://%IP-Address_Plenticore%/api/v1/auth/me
attr PV_Anlage_1_API get05-1Name info_name
attr PV_Anlage_1_API get05-2Name info_api_version
attr PV_Anlage_1_API get05-3Name info_sw_version
attr PV_Anlage_1_API get05-4Name info_hostname
attr PV_Anlage_1_API get05JSON .
attr PV_Anlage_1_API get05Name 05_/info/version
attr PV_Anlage_1_API get05URL http://%IP-Address_Plenticore%/api/v1/info/version
attr PV_Anlage_1_API get20-10Name Statistic_EnergyHome_Month
attr PV_Anlage_1_API get20-11Name Statistic_EnergyHome_Total
attr PV_Anlage_1_API get20-12Name Statistic_EnergyHome_Year
attr PV_Anlage_1_API get20-13Name Statistic_EnergyHomeBat_Day
attr PV_Anlage_1_API get20-14Name Statistic_EnergyHomeBat_Month
attr PV_Anlage_1_API get20-15Name Statistic_EnergyHomeBat_Total
attr PV_Anlage_1_API get20-16Name Statistic_EnergyHomeBat_Year
attr PV_Anlage_1_API get20-17Name Statistic_EnergyHomeGrid_Day
attr PV_Anlage_1_API get20-18Name Statistic_EnergyHomeGrid_Month
attr PV_Anlage_1_API get20-19Name Statistic_EnergyHomeGrid_Total
attr PV_Anlage_1_API get20-1Name Statistic_Autarky_Day
attr PV_Anlage_1_API get20-20Name Statistic_EnergyHomeGrid_Year
attr PV_Anlage_1_API get20-21Name Statistic_EnergyHomePv_Day
attr PV_Anlage_1_API get20-22Name Statistic_EnergyHomePv_Month
attr PV_Anlage_1_API get20-23Name Statistic_EnergyHomePv_Total
attr PV_Anlage_1_API get20-24Name Statistic_EnergyHomePv_Year
attr PV_Anlage_1_API get20-25Name Statistic_OwnConsumptionRate_Day
attr PV_Anlage_1_API get20-26Name Statistic_OwnConsumptionRate_Month
attr PV_Anlage_1_API get20-27Name Statistic_OwnConsumptionRate_Total
attr PV_Anlage_1_API get20-28Name Statistic_OwnConsumptionRate_Year
attr PV_Anlage_1_API get20-29Name Statistic_Yield_Day
attr PV_Anlage_1_API get20-2Name Statistic_Autarky_Month
attr PV_Anlage_1_API get20-30Name Statistic_Yield_Month
attr PV_Anlage_1_API get20-31Name Statistic_Yield_Total
attr PV_Anlage_1_API get20-32Name Statistic_Yield_Year
attr PV_Anlage_1_API get20-3Name Statistic_Autarky_Total
attr PV_Anlage_1_API get20-4Name Statistic_Autarky_Year
attr PV_Anlage_1_API get20-5Name Statistic_CO2Saving_Day
attr PV_Anlage_1_API get20-6Name Statistic_CO2Saving_Month
attr PV_Anlage_1_API get20-7Name Statistic_CO2Saving_Total
attr PV_Anlage_1_API get20-8Name Statistic_CO2Saving_Year
attr PV_Anlage_1_API get20-9Name Statistic_EnergyHome_Day
attr PV_Anlage_1_API get20Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get20JSON 01_processdata_.._value
attr PV_Anlage_1_API get20Name 20_/processdata/scb_statistic_EnergyFlow
attr PV_Anlage_1_API get20URL http://%IP-Address_Plenticore%/api/v1/processdata/scb:statistic:EnergyFlow
attr PV_Anlage_1_API get21Name 21_/modules_list
attr PV_Anlage_1_API get21URL http://%IP-Address_Plenticore%/api/v1/modules
attr PV_Anlage_1_API get24Data {"end":"%end_date%","begin":"%begin_date%"}
attr PV_Anlage_1_API get24Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get24Header02 Content-type: application/json, Accept: application/json, Connection: keep-alive
attr PV_Anlage_1_API get24Name 24_/logdata/download
attr PV_Anlage_1_API get24URL http://%IP-Address_Plenticore%/api/v1/logdata/download
attr PV_Anlage_1_API get31-1Name Battery_Type
attr PV_Anlage_1_API get31-2Name Battery_Type
attr PV_Anlage_1_API get31Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get31Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get31JSON .
attr PV_Anlage_1_API get31Name 31_Battery_Type
attr PV_Anlage_1_API get31URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:Type
attr PV_Anlage_1_API get32-1Name Battery_MinHomeComsumption
attr PV_Anlage_1_API get32-2Name Battery_MinHomeComsumption
attr PV_Anlage_1_API get32Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get32Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get32JSON .
attr PV_Anlage_1_API get32Name 32_Battery_MinHomeComsumption
attr PV_Anlage_1_API get32URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:MinHomeComsumption
attr PV_Anlage_1_API get33-1Name Battery_Strategy
attr PV_Anlage_1_API get33-2Name Battery_Strategy
attr PV_Anlage_1_API get33Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get33Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get33JSON .
attr PV_Anlage_1_API get33Name 33_Battery_Strategy
attr PV_Anlage_1_API get33URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:Strategy
attr PV_Anlage_1_API get34-1Name Battery_MinSoc
attr PV_Anlage_1_API get34-2Name Battery_MinSoc
attr PV_Anlage_1_API get34Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get34Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get34JSON .
attr PV_Anlage_1_API get34Name 34_Battery_MinSoc
attr PV_Anlage_1_API get34URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:MinSoc
attr PV_Anlage_1_API get35-1Name Battery_SmartBatteryControl_Enable
attr PV_Anlage_1_API get35-2Name Battery_SmartBatteryControl_Enable
attr PV_Anlage_1_API get35Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get35Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get35JSON .
attr PV_Anlage_1_API get35Name 35_Battery_SmartBatteryControl_Enable
attr PV_Anlage_1_API get35URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:SmartBatteryControl:Enable
attr PV_Anlage_1_API get36-1Name Battery_DynamicSoc_Enable
attr PV_Anlage_1_API get36-2Name Battery_DynamicSoc_Enable
attr PV_Anlage_1_API get36Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get36Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API get36JSON .
attr PV_Anlage_1_API get36Name 36_Battery_DynamicSoc_Enable
attr PV_Anlage_1_API get36URL http://%IP-Address_Plenticore%/api/v1/settings/devices:local/Battery:DynamicSoc:Enable
attr PV_Anlage_1_API get41Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get41Name 41_/update/status
attr PV_Anlage_1_API get41URL http://%IP-Address_Plenticore%/api/v1/update/status
attr PV_Anlage_1_API getHeader01 Accept-Encoding: gzip,deflate
attr PV_Anlage_1_API getHeader02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API group PV Eigenverbrauch
attr PV_Anlage_1_API icon sani_solar
attr PV_Anlage_1_API reAuthRegex "authenticated":false|"processdata":\[\]|wrong credentials
attr PV_Anlage_1_API reading01-1Name auth_nonce
attr PV_Anlage_1_API reading01-2Name auth_rounds
attr PV_Anlage_1_API reading01-3Name auth_salt
attr PV_Anlage_1_API reading01-4Name auth_transactionId
attr PV_Anlage_1_API reading01JSON .
attr PV_Anlage_1_API reading02JSON sessionId
attr PV_Anlage_1_API reading02Name auth_sessionId
attr PV_Anlage_1_API reading0301JSON message
attr PV_Anlage_1_API reading0301Name info_message
attr PV_Anlage_1_API reading0302JSON error
attr PV_Anlage_1_API reading0302Name info_error
attr PV_Anlage_1_API replacement01Mode expression
attr PV_Anlage_1_API replacement01Regex %IP-Address_Plenticore%
attr PV_Anlage_1_API replacement01Value {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")}
attr PV_Anlage_1_API replacement02Mode reading
attr PV_Anlage_1_API replacement02Regex %auth_transactionId%
attr PV_Anlage_1_API replacement02Value auth_transactionId
attr PV_Anlage_1_API replacement03Mode reading
attr PV_Anlage_1_API replacement03Regex %auth_proof%
attr PV_Anlage_1_API replacement03Value auth_proof
attr PV_Anlage_1_API replacement04Mode expression
attr PV_Anlage_1_API replacement04Regex %randomString64%
attr PV_Anlage_1_API replacement04Value {my $NAME = "PV_Anlage_1_API" ;;;;fhem("deletereading ".$NAME." message");;;;fhem("deletereading ".$NAME." auth.*");;;;my @chars=('a'..'z','A'..'Z','0'..'9');; my $r;; foreach(1..16) {$r.=$chars[rand @chars];;};;;; fhem("setreading ".$NAME." auth_randomString64 ".$r);;;; $r;;;;}
attr PV_Anlage_1_API replacement05Mode reading
attr PV_Anlage_1_API replacement05Regex %auth_randomString64%
attr PV_Anlage_1_API replacement05Value auth_randomString64
attr PV_Anlage_1_API replacement06Mode reading
attr PV_Anlage_1_API replacement06Regex %auth_token%
attr PV_Anlage_1_API replacement06Value auth_token
attr PV_Anlage_1_API replacement07Mode reading
attr PV_Anlage_1_API replacement07Regex %auth_signature%
attr PV_Anlage_1_API replacement07Value auth_signature
attr PV_Anlage_1_API replacement08Mode reading
attr PV_Anlage_1_API replacement08Regex %auth_authtag%
attr PV_Anlage_1_API replacement08Value auth_authtag
attr PV_Anlage_1_API replacement09Mode reading
attr PV_Anlage_1_API replacement09Regex %auth_payload%
attr PV_Anlage_1_API replacement09Value auth_payload
attr PV_Anlage_1_API replacement10Mode reading
attr PV_Anlage_1_API replacement10Regex %auth_iv%
attr PV_Anlage_1_API replacement10Value auth_iv
attr PV_Anlage_1_API replacement11Mode reading
attr PV_Anlage_1_API replacement11Regex %auth_sessionId%
attr PV_Anlage_1_API replacement11Value auth_sessionId
attr PV_Anlage_1_API replacement12Mode expression
attr PV_Anlage_1_API replacement12Regex %begin_date%
attr PV_Anlage_1_API replacement12Value {POSIX::strftime("%Y-%m-%d",localtime(time))}
attr PV_Anlage_1_API replacement13Mode expression
attr PV_Anlage_1_API replacement13Regex %end_date%
attr PV_Anlage_1_API replacement13Value {POSIX::strftime("%Y-%m-%d",localtime(time))}
attr PV_Anlage_1_API room Strom->Photovoltaik
attr PV_Anlage_1_API set06Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set06Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set06Method POST
attr PV_Anlage_1_API set06Name 06_/auth/logout
attr PV_Anlage_1_API set06NoArg 1
attr PV_Anlage_1_API set06URL http://%IP-Address_Plenticore%/api/v1/auth/logout
attr PV_Anlage_1_API set23-10Name Event_02_code
attr PV_Anlage_1_API set23-11Name Event_02_description
attr PV_Anlage_1_API set23-12Name Event_02_end_time
attr PV_Anlage_1_API set23-13Name Event_02_group
attr PV_Anlage_1_API set23-14Name Event_02_is_active
attr PV_Anlage_1_API set23-15Name Event_02_long_description
attr PV_Anlage_1_API set23-16Name Event_02_start_time
attr PV_Anlage_1_API set23-17Name Event_03_category
attr PV_Anlage_1_API set23-18Name Event_03_code
attr PV_Anlage_1_API set23-19Name Event_03_description
attr PV_Anlage_1_API set23-1Name Event_01_category
attr PV_Anlage_1_API set23-20Name Event_03_end_time
attr PV_Anlage_1_API set23-21Name Event_03_group
attr PV_Anlage_1_API set23-22Name Event_03_is_active
attr PV_Anlage_1_API set23-23Name Event_03_long_description
attr PV_Anlage_1_API set23-24Name Event_03_start_time
attr PV_Anlage_1_API set23-25Name Event_04_category
attr PV_Anlage_1_API set23-26Name Event_04_code
attr PV_Anlage_1_API set23-27Name Event_04_description
attr PV_Anlage_1_API set23-28Name Event_04_end_time
attr PV_Anlage_1_API set23-29Name Event_04_group
attr PV_Anlage_1_API set23-2Name Event_01_code
attr PV_Anlage_1_API set23-30Name Event_04_is_active
attr PV_Anlage_1_API set23-31Name Event_04_long_description
attr PV_Anlage_1_API set23-32Name Event_04_start_time
attr PV_Anlage_1_API set23-33Name Event_05_category
attr PV_Anlage_1_API set23-34Name Event_05_code
attr PV_Anlage_1_API set23-35Name Event_05_description
attr PV_Anlage_1_API set23-36Name Event_05_end_time
attr PV_Anlage_1_API set23-37Name Event_05_group
attr PV_Anlage_1_API set23-38Name Event_05_is_active
attr PV_Anlage_1_API set23-39Name Event_05_long_description
attr PV_Anlage_1_API set23-3Name Event_01_description
attr PV_Anlage_1_API set23-40Name Event_05_start_time
attr PV_Anlage_1_API set23-4Name Event_01_end_time
attr PV_Anlage_1_API set23-5Name Event_01_group
attr PV_Anlage_1_API set23-6Name Event_01_is_active
attr PV_Anlage_1_API set23-7Name Event_01_long_description
attr PV_Anlage_1_API set23-8Name Event_01_start_time
attr PV_Anlage_1_API set23-9Name Event_02_category
attr PV_Anlage_1_API set23Data {"max":5,"language":"$val"}
attr PV_Anlage_1_API set23Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set23Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set23Hint en-gb,de-de
attr PV_Anlage_1_API set23JSON .
attr PV_Anlage_1_API set23Name 23_/events/latest_5
attr PV_Anlage_1_API set23ParseResponse 1
attr PV_Anlage_1_API set23TextArg 1
attr PV_Anlage_1_API set23URL http://%IP-Address_Plenticore%/api/v1/events/latest
attr PV_Anlage_1_API set31Data [{"moduleid":"devices:local","settings":[{"id":"Battery:Type","value":"$val"}]}]
attr PV_Anlage_1_API set31Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set31Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set31Hint 0,4
attr PV_Anlage_1_API set31Method PUT
attr PV_Anlage_1_API set31Name 31_Battery_Type
attr PV_Anlage_1_API set31URL http://%IP-Address_Plenticore%/api/v1/settings
attr PV_Anlage_1_API set33Data [{"moduleid":"devices:local","settings":[{"id":"Battery:Strategy","value":"$val"}]}]
attr PV_Anlage_1_API set33Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set33Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set33Hint 1,2
attr PV_Anlage_1_API set33Method PUT
attr PV_Anlage_1_API set33Name 31_Battery_Strategy
attr PV_Anlage_1_API set33URL http://%IP-Address_Plenticore%/api/v1/settings
attr PV_Anlage_1_API set34Data [{"moduleid":"devices:local","settings":[{"id":"Battery:MinSoc","value":"$val"}]}]
attr PV_Anlage_1_API set34Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set34Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set34Hint slider,10,5,100
attr PV_Anlage_1_API set34Method PUT
attr PV_Anlage_1_API set34Name 34_Battery_MinSoc
attr PV_Anlage_1_API set34URL http://%IP-Address_Plenticore%/api/v1/settings
attr PV_Anlage_1_API set35Data [{"moduleid":"devices:local","settings":[{"id":"Battery:SmartBatteryControl:Enable","value":"$val"}]}]
attr PV_Anlage_1_API set35Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set35Header02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API set35Hint 0,1
attr PV_Anlage_1_API set35Method PUT
attr PV_Anlage_1_API set35Name 35_SmartBatteryControl_Enable
attr PV_Anlage_1_API set35URL http://%IP-Address_Plenticore%/api/v1/settings
attr PV_Anlage_1_API set51Header01 authorization: Session %auth_sessionId%
attr PV_Anlage_1_API set51Header02 Accept: application/json, Connection: keep-alive, Content-type: application/json
attr PV_Anlage_1_API set51Method Post
attr PV_Anlage_1_API set51Name 51_/system/reboot
attr PV_Anlage_1_API set51NoArg 1
attr PV_Anlage_1_API set51URL http://%IP-Address_Plenticore%/api/v1/system/reboot
attr PV_Anlage_1_API showBody 1
attr PV_Anlage_1_API showError 1
attr PV_Anlage_1_API sid01Data {"nonce": "%randomString64%","username": "user"}
attr PV_Anlage_1_API sid01ParseResponse 1
attr PV_Anlage_1_API sid01URL http://%IP-Address_Plenticore%/api/v1/auth/start
attr PV_Anlage_1_API sidHeader01 Accept-Encoding: gzip,deflate
attr PV_Anlage_1_API sidHeader02 Content-type: application/json, Accept: application/json, Connection: keep-alive
attr PV_Anlage_1_API sortby 02
attr PV_Anlage_1_API timeout 7
attr PV_Anlage_1_API userReadings auth_first_called:auth_randomString64.* {my $first_called = InternalVal("$NAME","path","n.a");;;; $first_called =~ s/:/_/g;;;;$first_called ;;;;$first_called =~ s/\/api\/v1//g;;;; my %replace = ("/auth/me" => "04_/auth/me","/info/version" => "05_/info/version","/processdata/scb_statistic_EnergyFlow" => "20_/processdata/scb_statistic_EnergyFlow","/modules_list" => "21_/modules_list","/logdata/download" => "24_/logdata/download","/update/status" => "41_/update/status","/system/reboot" => "04_/auth/me",);;;; $replace{$first_called};;;;},\
\
auth_Step1_Message:auth_transactionId.* {system("/usr/bin/python3 /opt/fhem/python/bin/plenticore_auth_finish.py ".ReadingsVal("PV_Anlage_1_config","IP-Address_FHEM","")." ".ReadingsVal("$NAME","auth_randomString64","")." ".ReadingsVal("$NAME","auth_nonce","")." ".ReadingsVal("$NAME","auth_salt","")." ".ReadingsVal("$NAME","auth_rounds","29000")." &");;;; "Prepare auth_finish started with auth_nonce ".ReadingsVal("$NAME","auth_nonce","")},\
\
auth_Step2_Message:auth_proof.* { fhem("get ".$NAME." 02_/auth/finish") ;;;; "HTTP Request 02_/auth/finish with auth_proof ".ReadingsVal("$NAME","auth_proof","")},\
\
auth_Step3_Message:auth_token.* {system("/usr/bin/python3 /opt/fhem/python/bin/plenticore_auth_session.py ".ReadingsVal("PV_Anlage_1_config","IP-Address_FHEM","")." ".ReadingsVal("$NAME","auth_randomString64","")." ".ReadingsVal("$NAME","auth_nonce","")." ".ReadingsVal("$NAME","auth_salt","")." ".ReadingsVal("$NAME","auth_rounds","")." ".ReadingsVal("$NAME","auth_token","")." &");;;; "Prepare auth_session started with auth_token ".ReadingsVal("$NAME","auth_token","")},\
\
auth_Step4_Message:auth_payload.* { fhem("get ".$NAME." 03_/auth/create_session") ;;;; "HTTP Request 03_/auth/create_session with auth_authtag ".ReadingsVal("$NAME","auth_authtag","")},\
\
auth_Step5_Message:auth_sessionId.* {my $restack = ReadingsVal("$NAME","auth_first_called","") ;;;; ($restack != "")?fhem("get ".$NAME." ".$restack):"No further HTTP request";;;;}
attr PV_Anlage_1_API verbose 5
</syntaxhighlight>

=== Kostal Smart Energy Manager (KSEM) (Modbus/TCP) ===
Diese Einbindung ist nicht zwingend notwendig, jedoch weil es möglich ist hier beschrieben.
Das Gerät ist hier mit "disable 1" konfiguriert, um es zu verwenden muss das Attribut auf 0 gesetzt oder einfach gelöscht werden.

Auch hier ist ein Interval von 60 Sekunden gesetzt worden. Das Logging ist noch komplett deaktiviert, weshalb man seine Werte noch selber definieren muss.

==== RAW Definition des KSEM ====
Zun Thema KSEM bestand direkter Kontakt mit dem Kostal Service. Der KSEM ermittelt nicht alle Werte, welche in der SunSpec spezifiziert sind. Alle nicht unterstützen Werte sind in den Registern mit 0x8000 gekennzeichnet. Für die nicht unterstützten Zählerstände wird 0x800000000 ausgegeben.
Der Summenstrom M_AC_Current (sum of active phases) kann aber durch den Endanwender selber aus der Summe der Einzelwerte (Phase A AC current, Phase B AC current Phase C AC current) berechnet werden. Die einzelnen Spannungen zwischen den Phasen können nicht gemessen werden und werden deshalb nicht ausgegeben.
<syntaxhighlight lang="Perl">
defmod PV_KSEM ModbusAttr 1 60 <IP-Address_KSEM>:502 TCP
attr PV_KSEM DbLogExclude .*
attr PV_KSEM alias PV_Energy_Manager
attr PV_KSEM dev-h-defPoll 1
attr PV_KSEM dev-type-INT16-len 1
attr PV_KSEM dev-type-INT16-unpack s>
attr PV_KSEM dev-type-INT16_Current-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Current_SF",0))
attr PV_KSEM dev-type-INT16_Current-format %.2f
attr PV_KSEM dev-type-INT16_Current-len 1
attr PV_KSEM dev-type-INT16_Current-unpack s>
attr PV_KSEM dev-type-INT16_Freq-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Freq_SF",0))
attr PV_KSEM dev-type-INT16_Freq-format %.2f
attr PV_KSEM dev-type-INT16_Freq-len 1
attr PV_KSEM dev-type-INT16_Freq-unpack s>
attr PV_KSEM dev-type-INT16_PF-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_PF_SF",0))
attr PV_KSEM dev-type-INT16_PF-format %.2f
attr PV_KSEM dev-type-INT16_PF-len 1
attr PV_KSEM dev-type-INT16_PF-unpack s>
attr PV_KSEM dev-type-INT16_Power-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Power_SF",0))
attr PV_KSEM dev-type-INT16_Power-format %.2f
attr PV_KSEM dev-type-INT16_Power-len 1
attr PV_KSEM dev-type-INT16_Power-unpack s>
attr PV_KSEM dev-type-INT16_VA-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_VA_SF",0))
attr PV_KSEM dev-type-INT16_VA-format %.2f
attr PV_KSEM dev-type-INT16_VA-len 1
attr PV_KSEM dev-type-INT16_VA-unpack s>
attr PV_KSEM dev-type-INT16_VAR-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_VAR_SF",0))
attr PV_KSEM dev-type-INT16_VAR-format %.2f
attr PV_KSEM dev-type-INT16_VAR-len 1
attr PV_KSEM dev-type-INT16_VAR-unpack s>
attr PV_KSEM dev-type-INT16_Voltage-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Voltage_SF",0))
attr PV_KSEM dev-type-INT16_Voltage-format %.2f
attr PV_KSEM dev-type-INT16_Voltage-len 1
attr PV_KSEM dev-type-INT16_Voltage-unpack s>
attr PV_KSEM dev-type-STR32-expr $val =~ s/[\00]+//gr
attr PV_KSEM dev-type-STR32-format %s
attr PV_KSEM dev-type-STR32-len 16
attr PV_KSEM dev-type-STR32-unpack a*
attr PV_KSEM dev-type-UINT16-format %s
attr PV_KSEM dev-type-UINT16-len 1
attr PV_KSEM dev-type-UINT32-format %s
attr PV_KSEM dev-type-UINT32-len 2
attr PV_KSEM dev-type-UINT64-expr $val/10000
attr PV_KSEM dev-type-UINT64-format %s
attr PV_KSEM dev-type-UINT64-len 4
attr PV_KSEM dev-type-UINT64-unpack Q>
attr PV_KSEM disable 1
attr PV_KSEM group PV Eigenverbrauch
attr PV_KSEM icon measure_power
attr PV_KSEM obj-h40072-reading M_AC_Current_A
attr PV_KSEM obj-h40072-type INT16_Current
attr PV_KSEM obj-h40073-reading M_AC_Current_B
attr PV_KSEM obj-h40073-type INT16_Current
attr PV_KSEM obj-h40074-reading M_AC_Current_C
attr PV_KSEM obj-h40074-type INT16_Current
attr PV_KSEM obj-h40075-reading M_AC_Current_SF
attr PV_KSEM obj-h40075-type INT16
attr PV_KSEM obj-h40077-reading M_AC_Voltage_AN
attr PV_KSEM obj-h40077-type INT16_Voltage
attr PV_KSEM obj-h40078-reading M_AC_Voltage_BN
attr PV_KSEM obj-h40078-type INT16_Voltage
attr PV_KSEM obj-h40079-reading M_AC_Voltage_CN
attr PV_KSEM obj-h40079-type INT16_Voltage
attr PV_KSEM obj-h40084-reading M_AC_Voltage_SF
attr PV_KSEM obj-h40084-type INT16
attr PV_KSEM obj-h40085-reading M_AC_Freq
attr PV_KSEM obj-h40085-type INT16_Freq
attr PV_KSEM obj-h40086-reading M_AC_Freq_SF
attr PV_KSEM obj-h40086-type INT16
attr PV_KSEM obj-h40087-reading M_AC_Power
attr PV_KSEM obj-h40087-type INT16_Power
attr PV_KSEM obj-h40088-reading M_AC_Power_A
attr PV_KSEM obj-h40088-type INT16_Power
attr PV_KSEM obj-h40089-reading M_AC_Power_B
attr PV_KSEM obj-h40089-type INT16_Power
attr PV_KSEM obj-h40090-reading M_AC_Power_C
attr PV_KSEM obj-h40090-type INT16_Power
attr PV_KSEM obj-h40091-reading M_AC_Power_SF
attr PV_KSEM obj-h40091-type INT16
attr PV_KSEM obj-h40092-reading M_AC_VA
attr PV_KSEM obj-h40092-type INT16_VA
attr PV_KSEM obj-h40093-reading M_AC_VA_A
attr PV_KSEM obj-h40093-type INT16_VA
attr PV_KSEM obj-h40094-reading M_AC_VA_B
attr PV_KSEM obj-h40094-type INT16_VA
attr PV_KSEM obj-h40095-reading M_AC_VA_C
attr PV_KSEM obj-h40095-type INT16_VA
attr PV_KSEM obj-h40096-reading M_AC_VA_SF
attr PV_KSEM obj-h40096-type INT16
attr PV_KSEM obj-h40097-reading M_AC_VAR
attr PV_KSEM obj-h40097-type INT16_VAR
attr PV_KSEM obj-h40098-reading M_AC_VAR_A
attr PV_KSEM obj-h40098-type INT16_VAR
attr PV_KSEM obj-h40099-reading M_AC_VAR_B
attr PV_KSEM obj-h40099-type INT16_VAR
attr PV_KSEM obj-h40100-reading M_AC_VAR_C
attr PV_KSEM obj-h40100-type INT16_VAR
attr PV_KSEM obj-h40101-reading M_AC_VAR_SF
attr PV_KSEM obj-h40101-type INT16
attr PV_KSEM obj-h40102-reading M_AC_PF
attr PV_KSEM obj-h40102-type INT16_PF
attr PV_KSEM obj-h40103-reading M_AC_PF_A
attr PV_KSEM obj-h40103-type INT16_PF
attr PV_KSEM obj-h40104-reading M_AC_PF_B
attr PV_KSEM obj-h40104-type INT16_PF
attr PV_KSEM obj-h40105-reading M_AC_PF_C
attr PV_KSEM obj-h40105-type INT16_PF
attr PV_KSEM obj-h40106-reading M_AC_PF_SF
attr PV_KSEM obj-h40106-type INT16
attr PV_KSEM obj-h40108-reading M_Exported
attr PV_KSEM obj-h40108-type UINT32
attr PV_KSEM obj-h40110-reading M_Exported_A
attr PV_KSEM obj-h40110-type UINT32
attr PV_KSEM obj-h40112-reading M_Exported_B
attr PV_KSEM obj-h40112-type UINT32
attr PV_KSEM obj-h40114-reading M_Exported_C
attr PV_KSEM obj-h40114-type UINT32
attr PV_KSEM obj-h40116-reading M_Imported
attr PV_KSEM obj-h40116-type UINT32
attr PV_KSEM obj-h40118-reading M_Imported_A
attr PV_KSEM obj-h40118-type UINT32
attr PV_KSEM obj-h40120-reading M_Imported_B
attr PV_KSEM obj-h40120-type UINT32
attr PV_KSEM obj-h40122-reading M_Imported_C
attr PV_KSEM obj-h40122-type UINT32
attr PV_KSEM obj-h40125-reading M_Exported_VA
attr PV_KSEM obj-h40125-type UINT32
attr PV_KSEM obj-h40127-reading M_Exported_VA_A
attr PV_KSEM obj-h40127-type UINT32
attr PV_KSEM obj-h40129-reading M_Exported_VA_B
attr PV_KSEM obj-h40129-type UINT32
attr PV_KSEM obj-h40131-reading M_Exported_VA_C
attr PV_KSEM obj-h40131-type UINT32
attr PV_KSEM obj-h40133-reading M_Imported_VA
attr PV_KSEM obj-h40133-type UINT32
attr PV_KSEM obj-h40135-reading M_Imported_VA_A
attr PV_KSEM obj-h40135-type UINT32
attr PV_KSEM obj-h40137-reading M_Imported_VA_B
attr PV_KSEM obj-h40137-type UINT32
attr PV_KSEM obj-h40139-reading M_Imported_VA_C
attr PV_KSEM obj-h40139-type UINT32
attr PV_KSEM obj-h512-reading Active_energy+
attr PV_KSEM obj-h512-type UINT64
attr PV_KSEM obj-h516-reading Active_energy-
attr PV_KSEM obj-h516-type UINT64
attr PV_KSEM obj-h8192-reading ManufacturerID
attr PV_KSEM obj-h8192-type UINT16
attr PV_KSEM obj-h8193-reading ProductID
attr PV_KSEM obj-h8193-type UINT16
attr PV_KSEM obj-h8194-reading ProductVersion
attr PV_KSEM obj-h8194-type UINT16
attr PV_KSEM obj-h8195-reading FirmwareVersion
attr PV_KSEM obj-h8195-type UINT16
attr PV_KSEM obj-h8196-reading VendorName
attr PV_KSEM obj-h8196-type STR32
attr PV_KSEM obj-h8212-reading Productname
attr PV_KSEM obj-h8212-type STR32
attr PV_KSEM obj-h8228-reading SerialNumber
attr PV_KSEM obj-h8228-type STR32
attr PV_KSEM obj-h8244-reading MeasuringInterval
attr PV_KSEM obj-h8244-type UINT16
attr PV_KSEM room Strom->Photovoltaik
attr PV_KSEM sortby 03
attr PV_KSEM userReadings M_AC_Current:M_AC_Current_.* { ReadingsVal($NAME,"M_AC_Current_A",0) + ReadingsVal($NAME,"M_AC_Current_B",0) + ReadingsVal($NAME,"M_AC_Current_C",0) }
attr PV_KSEM verbose 0
</syntaxhighlight>

=== BYD Speicher (über Python Skript) ===
Diese Einbindung ist nicht zwingend notwendig.
Ein Ziel ist es das Python Skript später zu entfernen und eine direkten HTTPMOD Abfrage zu implementieren.
==== byd_status.py ====
fhem@raspberrypi:~/python/bin$ cat byd_status.py
<syntaxhighlight lang="Python">
#
# Copyright: Kilian Knoll, 10.3.2019
#
# Utility to parse rundata values of BYD HV BOX
# Version 1.0
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
#
# Please note that any incorrect or careless usage of this module as well as errors in the implementation can damage your BYD box!
# Therefore, the author does not provide any guarantee or warranty concerning to correctness, functionality or performance and does not accept any liability for damage caused by this module, examples or mentioned information.
# Thus, use it at your own risk!
#
#
# Purpose:
# Query Rundata values from BYD box via local network connection
# Used with BYD HV 6.4
#
# Returnvalue: 0 (Everything all right)
# Returnvalue: -1 (Crap happened)
# BYDdata: (Empty list in case Returnvalue =-1)
# BYDdata: (Full list of key-value pairs in case Returnvalue = 0)
#
# Tested with
# BYD HV 6.4,
# Firmware verison V3.012 R
# python 3.6
#
# Changes:
# 2020.07.30 added fhem connectivity
# added sys for argument parsing; BYDboxIP and FHEM Web Interface are read from commandline
# password and username is read from file

import fhem

import sys
BYDboxIP = sys.argv[1]
web = sys.argv[2]

import requests
import time
import json

from pprint import pprint
from bs4 import BeautifulSoup
from requests.auth import HTTPBasicAuth
import logging

#from loggerdate import loggerdate

def getvaluefromsubstring (inputvalue):
# The input we pass looks like this:
#<input readonly="readonly" type="text" value="5186"/>
#Goal is to return value 5186 as outputvalue
#Not sure if BeautifulSoup could do more / better...
output_array= str(inputvalue)
A,B,C,outputvalue= output_array.split('=')
outputvalue, A= outputvalue.split('/')
A,outputvalue,B = outputvalue.split('"')
if ('%' in outputvalue):
outputvalue, A = outputvalue.split('%')
outputvalue = float(outputvalue)
return outputvalue

def readbyd():

#Please adjust the parameters below as appropriate for your environment:

# username and password are read from pwd_byd.json file ; BYDboxIP is parsed from sys commandline
#print ("Start reading Password file for BYD access....")
try:
with open('/opt/fhem/python/pwd_byd.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

#No configurable parameters beyond this point

mySession = requests.Session()
try:
BYDdata={}
#The two stupid lines below took me almost a day...
#You can access other pages on the BYD WEB-Page - calling other asp scripts
url='http://'+BYDboxIP+'/asp/RunData.asp'
r4 = mySession.get(url, auth=HTTPBasicAuth(credentials["username"],credentials["password"]))
if (r4.status_code == 200):
page = r4.text
soup = BeautifulSoup(page, 'html.parser')
soup_ele = soup.body.form.table #This gets us the RunData Table and Array Num 1 values - using this approach
soup_reduced = soup_ele.find_all('input',attrs={"type": "text"} ) #Using this option now since BYD introduced some glitches with Firmware 3.012R on their html code..
# It now contains a list of the following kind
#<input readonly="readonly" type="text" value="19.300"/>
#print (soup_reduced)
#print ("ERSTES ELE", soup_reduced[1])
Keyvalue=[]
for elems in soup_reduced:
elems=str(elems)
myarray= elems.split('=')
CurValue=myarray[3].split('"')
Keyvalue.append(CurValue[1])

BYDdata["arrayvoltage"]= float(Keyvalue[0])
BYDdata["packvoltage"] = float(Keyvalue[1])
BYDdata["current"] = float(Keyvalue[2])
BYDdata["soc"] = (Keyvalue[3])
BYDdata["sysTemp"] = Keyvalue[4]
BYDdata["maxcellvol"] = float(Keyvalue[5])
BYDdata["mincellvol"] = float(Keyvalue[6])
BYDdata["maxcelltemp"] = float(Keyvalue[7])
BYDdata["mincelltemp"] = float(Keyvalue[8])
BYDdata["maxvolpos"] = int(Keyvalue[9])
BYDdata["minvolpos"] = Keyvalue[10]
BYDdata["maxtemppos"] = Keyvalue[11]
BYDdata["mintemppos"] = Keyvalue[12]
BYDdata["power"] = Keyvalue[13]
"""
# Oh well - with Firmware 3.012R, these values have disappeared from the BYD web pages...
BYDdata["soc"] = Keyvalue[3]
BYDdata["socwh"] = Keyvalue[4]
BYDdata["socah"] = Keyvalue[5]
BYDdata["soh"] = Keyvalue[6]
"""

Error_Connecting = 0

else:
print ("Not sure if we are able to connect with the given username & password - error code is:", r4.status_code)
print ("Header information passed is :", r4.headers)
Error_Connecting = r4.status_code

url='http://'+BYDboxIP+'/asp/StatisticInformation.asp'
r2 = mySession.get(url, auth=HTTPBasicAuth(credentials["username"],credentials["password"]))
if ((r2.status_code == 200) and (Error_Connecting == 0)):
page = r2.text
soup = BeautifulSoup(page, 'html.parser')
soup_ele = soup.body.table
#print (soup_ele)
#print ("--------------------------------------------------------")
#<input readonly="readonly" type="text" value="5186"/>
soup_reduced = soup_ele.find_all('input')
#print (soup_reduced)
#print ("soup_ele", soup_ele)
i = 0
a= len(soup_ele.contents)
total_charge_energy = soup_ele.find("td", text="Total Charge Energy:").find_next_sibling("td").text
total_charge_energy,b = (total_charge_energy.split())
total_charge_energy = float(total_charge_energy)
#print ("Total Charge Energy :", total_charge_energy)
BYDdata["Total_Charge_Energy"]= total_charge_energy

total_discharge_energy = soup_ele.find("td", text="Total Discharge Energy:").find_next_sibling("td").text
total_discharge_energy,b = (total_discharge_energy.split())
total_discharge_energy = float(total_discharge_energy)
#print ("Total Discharge Energy :", total_discharge_energy)
BYDdata["Total_Discharge_Energy"] = total_discharge_energy

total_cycle_counts = soup_ele.find("td", text="Total Cycle Counts:").find_next_sibling("td").text
#total_cycle_counts,b = (total_cycle_counts.split())
total_cycle_counts = float(total_cycle_counts)
#print ("Total Cycle Counts :", total_cycle_counts)
BYDdata["Total_Cycle_Counts"] = total_cycle_counts
else:
print ("Not sure if we are able to connect with the given username & password - error code is:", r4.status_code)
print ("Header information passed is :", r2.headers)
Error_Connecting = r2.status_code

except Exception as Connecterror:
print ("Error connecting to the BYD box :", Connecterror)
#logging.error("%s %s %s", loggerdate(), ",readbyd: Ran into exception querying the BYD Box : ", Connecterror)
Error_Connecting = Connecterror
if (Error_Connecting == 0):
if (len(BYDdata) >1): # We have something in the list

Returnvalue =0
else: # We ran into trouble and allocate an empty list
BYDdata={}
print ("Issue getting data from BYD ", Error_Connecting)

return (Returnvalue, BYDdata)

if __name__ == "__main__":

#print ("Start querying BYD....")
try:
Myreturnvalue, Mydata = readbyd();
if (Myreturnvalue == 0):
#print ("Returnvalue -should be zero if successful : ", Myreturnvalue)
#print ("----------------Start Values BYD ----------------")
#pprint (Mydata)
#print ("----------------End - Values from BYD ----------------")
#print ("Specific values from array....")
#print ("BYD Total Charge Energy :", Mydata['Total_Charge_Energy'], "Kwh")
#print ("BYD Total Discharge Energy :", Mydata['Total_Discharge_Energy'], "Kwh")
#print ("Calculations...")
#print ("Charging (+) / Discharging (-) Energy :", round(Mydata['packvoltage']*Mydata['current'],0), "W")
#print ("Efficiency is :",round(Mydata['Total_Discharge_Energy']/Mydata['Total_Charge_Energy'],3))
#print (Mydata)

message = json.dumps(Mydata)

#print ("Start reading Password file for FHEM access....")
try:
with open('/opt/fhem/python/pwd_fhem.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

#print ("Start login to FHEM ....")
fh = fhem.Fhem(web, protocol="http", port=8083, username=credentials["username"], password=credentials["password"])

#print ("Start transfer of data to FHEM ....")
fh.send_cmd("setreading BYD_Status output " + message)

else:
print ("Error unable to query BYD Box")
except Exception as ex:
print ("Issues querying BYD Box :", ex)
</syntaxhighlight>

====== Userreadings ======
Die Userreadings gehören zum Gerät BYD_Status .

output
Trigger: externes Python Skript
Das Python Skript beschreibt im Gerät BYD_Status das reading output, das dort dann weiter verarbeitet wird.

====== Passworte ======
Das Passwort für den BYD Speicher liegt in einer JSON Datei

fhem@raspberrypi:~/python$ cat pwd_byd.json
<pre>
{
"username": "installer",
"password": "<Steht in der BYD Dokumentation>"
}
</pre>
==== RAW Definition BYD_Status ====
<syntaxhighlight lang="Perl">
defmod BYD_Status expandJSON BYD_Status:output:.\{.*}
attr BYD_Status DbLogExclude .*
attr BYD_Status alias BYD_Status
attr BYD_Status comment Das Device wird über ein Python Skript im reading output befüllt.\
deletereading BYD_Status [min|max|cur|array|Total|pack|power|soc|sys].*\

attr BYD_Status group PV Eigenverbrauch
attr BYD_Status icon measure_battery_50
attr BYD_Status room Strom->Photovoltaik,Strom->System
attr BYD_Status sortby 02
</syntaxhighlight>
== Timeing für die PV extra Funktionen ==
=== RAW Definition PV_Schedule (DOIF) ===
<syntaxhighlight lang="Perl">
defmod PV_Schedule DOIF ################################################################################################################\
## 1 BYD Status aktualisieren\
##\
([+:05] and !([:00] or [:30]))\
(\
{system("/usr/bin/python3 /opt/fhem/python/bin/byd_status.py ".ReadingsVal("BYD_Status","IP-Address_BYD","?")." ".ReadingsVal("BYD_Status","IP-Address_FHEM","?")." &")}\
)\
################################################################################################################\
## 2 Plenticore Status aktualisieren. Dies geschieht über das PV_Anlage_1_API Device\
##\
DOELSEIF\
([:57])\
(\
get PV_Anlage_1_API 20_/processdata/scb_statistic_EnergyFlow\
set Dum.Energy update\
\
)\
################################################################################################################\
## 3 DWD Prognose aktualisieren, die Daten stehen immer verzögert zur Verfügung.\
##\
DOELSEIF\
([06:37] or [11:37] or [17:37] or [00:37])\
(\
{system("/usr/bin/python3 /opt/fhem/python/bin/dwd_get_forecast.py ".ReadingsVal("PV_Anlage_1","IP-Address_FHEM","?")." ".ReadingsVal("PV_Anlage_1","Solar_Station","?")." &")}\
)\
\
################################################################################################################\
## 4 PV Prognose vom aktuellen Tag aktualisieren\
## zwischen 7 und 19 Uhr zur vollen Stunde\
DOELSEIF\
([07:00-19:00] and [:00])\
(\
{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Prognose","ProPlanta",0)}\
)\
################################################################################################################\
## 5 PV Prognose für den nächsten Tag aktualisieren\
## \
DOELSEIF\
([09:11])\
(\
{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Prognose","ProPlanta",1)}\
)\

attr PV_Schedule DbLogExclude .*
attr PV_Schedule alias PV_Schedule
attr PV_Schedule cmdState BYD Status|Plenticore Status
attr PV_Schedule do always
attr PV_Schedule room Strom->System
attr PV_Schedule sortby 11
attr PV_Schedule wait 0:0:0:10:0:0
</syntaxhighlight>

== Energie Bilanz ==
[[Bild:Plenticore Bilanz.png|mini|900px|rechts|]]
Die Energie Bilanz soll einen kompakten Überblick über die Produktions und Verbrauchswerte Liefern. Hierbei werden die Momentanwerte direkt berechnet, die restlichen Werte werden als Statistiken aus dem Gerät abgefragt.
Die Aktualisierung erfolgt zyklisch über das Gerät PV_Schedule.
=== RAW Definition Energiebilanz ===
<syntaxhighlight lang="Perl">
defmod Dum.Energy dummy
attr Dum.Energy DbLogExclude .*
attr Dum.Energy DbLogInclude Autarky.*,GridFeed.*,PV.*,.*Consumption.*
attr Dum.Energy alias Energiebilanz
attr Dum.Energy comment TotalConsumption,AutarkyQuoteDay,SelfConsumptionQuoteDay,AutarkyQuoteMonth,SelfConsumptionQuoteMonth
attr Dum.Energy event-on-change-reading PV,GridConsumption,GridFeedIn,SelfConsumptionQuote,Autarky.*,GridFeed.*,PV.*,.*Consumption.*
attr Dum.Energy event-on-update-reading TotalConsumption,AutarkyQuoteDay,SelfConsumptionQuoteDay,AutarkyQuoteMonth,SelfConsumptionQuoteMonth
attr Dum.Energy group Energiebilanz
attr Dum.Energy icon measure_power_meter
attr Dum.Energy room Strom->Energie
attr Dum.Energy stateFormat {\
my $pvt = ReadingsVal("$name","PVTotal", "")." W";;\
my $pvtd = ReadingsVal("$name","PVTotalDay", "")." kWh";;\
my $pvtm = ReadingsVal("$name","PVTotalMonth", "")." kWh";;\
my $pvty = ReadingsVal("$name","PVTotalYear", "")." kWh";;\
\
my $pv = ReadingsVal("$name","PV", "")." W";;\
my $pvd = ReadingsVal("$name","PVDay", "")." kWh";;\
my $pvm = ReadingsVal("$name","PVMonth", "")." kWh";;\
my $pvy = ReadingsVal("$name","PVYear", "")." kWh";;\
\
my $gfi = ReadingsVal("$name","GridFeedIn", "")." W";;\
my $gfid = ReadingsVal("$name","GridFeedInDay", "")." kWh";;\
my $gfim = ReadingsVal("$name","GridFeedInMonth", "")." kWh";;\
my $gfiy = ReadingsVal("$name","GridFeedInYear", "")." kWh";;\
my $eb = ReadingsVal("$name","GridConsumption", "")." W";;\
my $ebd = ReadingsVal("$name","GridConsumptionDay", "")." kWh";;\
my $ebm = ReadingsVal("$name","GridConsumptionMonth", "")." kWh";;\
my $eby = ReadingsVal("$name","GridConsumptionYear", "")." kWh";;\
my $et = ReadingsVal("$name","TotalConsumption", "")." W";;\
my $etd = ReadingsVal("$name","TotalConsumptionDay", "")." kWh";;\
my $etm = ReadingsVal("$name","TotalConsumptionMonth", "")." kWh";;\
my $ety = ReadingsVal("$name","TotalConsumptionYear", "")." kWh";;\
my $aq = ReadingsVal("$name","AutarkyQuote", "")." %";;\
my $aqd = ReadingsVal("$name","AutarkyQuoteDay", "")." %";;\
my $aqm = ReadingsVal("$name","AutarkyQuoteMonth", "")." %";;\
my $aqy = ReadingsVal("$name","AutarkyQuoteYear", "")." %";;\
my $sq = ReadingsVal("$name","SelfConsumptionQuote", "")." %";;\
my $sqd = ReadingsVal("$name","SelfConsumptionQuoteDay", "")." %";;\
my $sqm = ReadingsVal("$name","SelfConsumptionQuoteMonth", "")." %";;\
my $sqy = ReadingsVal("$name","SelfConsumptionQuoteYear", "")." %";;\
my $md = ReadingsTimestamp("$name", "AutarkyQuote", "");;\
my $cd = ReadingsTimestamp("PV_Anlage_1_API", "Statistic_Autarky_Day", "");;\
my $cm = ReadingsTimestamp("PV_Anlage_1_API", "Statistic_Autarky_Month", "");;\
my $cy = ReadingsTimestamp("PV_Anlage_1_API", "Statistic_Autarky_Year", "");;\
"<html><table border=2 bordercolor='darkgreen' cellspacing=0>\
<tr><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'> </td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>aktueller Wert</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>Heute</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>dieser Monat</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>dieses Jahr</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>PV-Erzeugung-Total</td><td style='padding-right:5px;;padding-left:5px'>".$pvt."</td><td style='padding-right:5px;;padding-left:5px'>".$pvtd."</td><td style='padding-right:5px;;padding-left:5px'>".$pvtm."</td><td style='padding-right:5px;;padding-left:5px'>".$pvty."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>PV-Einspeisung</td><td style='padding-right:5px;;padding-left:5px'>".$gfi."</td><td style='padding-right:5px;;padding-left:5px'>".$gfid."</td><td style='padding-right:5px;;padding-left:5px'>".$gfim."</td><td style='padding-right:5px;;padding-left:5px'>".$gfiy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Netz-Bezug</td><td style='padding-right:5px;;padding-left:5px'>".$eb."</td><td style='padding-right:5px;;padding-left:5px'>".$ebd."</td><td style='padding-right:5px;;padding-left:5px'>".$ebm."</td><td style='padding-right:5px;;padding-left:5px'>".$eby."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>PV-Bezug</td><td style='padding-right:5px;;padding-left:5px'>".$pv."</td><td style='padding-right:5px;;padding-left:5px'>".$pvd."</td><td style='padding-right:5px;;padding-left:5px'>".$pvm."</td><td style='padding-right:5px;;padding-left:5px'>".$pvy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Energieverbrauch</td><td style='padding-right:5px;;padding-left:5px'>".$et."</td><td style='padding-right:5px;;padding-left:5px'>".$etd."</td><td style='padding-right:5px;;padding-left:5px'>".$etm."</td><td style='padding-right:5px;;padding-left:5px'>".$ety."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Autarkiequote</td><td style='padding-right:5px;;padding-left:5px'>".$aq."</td><td style='padding-right:5px;;padding-left:5px'>".$aqd."</td><td style='padding-right:5px;;padding-left:5px'>".$aqm."</td><td style='padding-right:5px;;padding-left:5px'>".$aqy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Eigenverbrauchsquote</td><td style='padding-right:5px;;padding-left:5px'>".$sq."</td><td style='padding-right:5px;;padding-left:5px'>".$sqd."</td><td style='padding-right:5px;;padding-left:5px'>".$sqm."</td><td style='padding-right:5px;;padding-left:5px'>".$sqy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Berechnung am</td><td style='padding-right:5px;;padding-left:5px'>".$md."</td><td style='padding-right:5px;;padding-left:5px'>".$cd."</td><td style='padding-right:5px;;padding-left:5px'>".$cm."</td><td style='padding-right:5px;;padding-left:5px'>".$cy."</td></tr>\
</table></html>"\
}
attr Dum.Energy userReadings PVTotal {round(ReadingsVal("PV_Anlage_1","Total_AC_active_power",""),0)},\
PVTotalDay {round( ReadingsVal("PV_Anlage_1_API","Statistic_Yield_Day", "")/1000 ,2)},\
PVTotalMonth {round( ReadingsVal("PV_Anlage_1_API","Statistic_Yield_Month", "")/1000 ,2)},\
PVTotalYear {round( ReadingsVal("PV_Anlage_1_API","Statistic_Yield_Year", "")/1000 ,2)},\
\
PV {round( ReadingsVal("PV_Anlage_1","Home_own_consumption_from_battery", "")+ReadingsVal("PV_Anlage_1","Home_own_consumption_from_PV", "") ,0)},\
PVDay {round( (ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Day", "")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Day", ""))/1000 ,2)},\
PVMonth {round( (ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Month", "")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Month", ""))/1000 ,2)},\
PVYear {round( (ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Year", "")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Year", ""))/1000 ,2)},\
\
GridFeedIn { ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0)<=0 ? abs(round(ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0),0)) : 0 },\
GridFeedInDay {round((ReadingsVal("PV_Anlage_1_API","Statistic_Yield_Day", "")-ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Day", "")-ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Day", ""))/1000,2)},\
GridFeedInMonth {round((ReadingsVal("PV_Anlage_1_API","Statistic_Yield_Month", "")-ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Month", "")-ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Month", ""))/1000,2)},\
GridFeedInYear {round((ReadingsVal("PV_Anlage_1_API","Statistic_Yield_Year", "")-ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Year", "")-ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Year", ""))/1000,2)},\
\
GridConsumption { ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0)>=0 ? round(ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0),0) : 0 },\
GridConsumptionDay {round(abs(ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeGrid_Day",""))/1000 ,2)},\
GridConsumptionMonth {round(ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeGrid_Month","")/1000 ,2)},\
GridConsumptionYear {round(ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeGrid_Year","")/1000 ,2)},\
\
TotalConsumption {round((ReadingsVal("PV_Anlage_1","Home_own_consumption_from_PV","")+ReadingsVal("PV_Anlage_1","Home_own_consumption_from_battery","")+ReadingsVal("PV_Anlage_1","Home_own_consumption_from_grid","")),0)},\
\
TotalConsumptionDay {round( (ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Day","")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Day","")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeGrid_Day","") )/1000 ,2)},\
TotalConsumptionMonth {round( (ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Month","")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Month","")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeGrid_Month","") )/1000 ,2)},\
TotalConsumptionYear {round( (ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomePv_Year","")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeBat_Year","")+ReadingsVal("PV_Anlage_1_API","Statistic_EnergyHomeGrid_Year","") )/1000,2)},\
\
AutarkyQuote {my $valA = ReadingsVal("PV_Anlage_1", "Total_AC_active_power","")-ReadingsVal("PV_Anlage_1", "Home_own_consumption_from_grid","");;;; my $calcVal = ($valA > 0)?round($valA /($valA + ReadingsVal("PV_Anlage_1", "Home_own_consumption_from_grid",""))*100 ,0) : 0 ;;;; ($calcVal > 100)?100:$calcVal },\
AutarkyQuoteDay {round(ReadingsVal("PV_Anlage_1_API","Statistic_Autarky_Day", ""),0)},\
AutarkyQuoteMonth {round(ReadingsVal("PV_Anlage_1_API","Statistic_Autarky_Month", ""),0)},\
AutarkyQuoteYear {round(ReadingsVal("PV_Anlage_1_API","Statistic_Autarky_Year", ""),0)},\
\
SelfConsumptionQuote {my $valS = ReadingsVal("PV_Anlage_1","Total_AC_active_power", 0) ;;;; my $calcVal = ($valS > 0)?round((ReadingsVal("PV_Anlage_1","Home_own_consumption_from_PV", "0") + ReadingsVal("PV_Anlage_1","Home_own_consumption_from_battery","0")) / $valS * 100 ,0) : 0 ;;;; ($calcVal > 100)?100:$calcVal},\
SelfConsumptionQuoteDay {round(ReadingsVal("PV_Anlage_1_API","Statistic_OwnConsumptionRate_Day", ""),0)},\
SelfConsumptionQuoteMonth {round(ReadingsVal("PV_Anlage_1_API","Statistic_OwnConsumptionRate_Month", ""),0)},\
SelfConsumptionQuoteYear {round(ReadingsVal("PV_Anlage_1_API","Statistic_OwnConsumptionRate_Year", ""),0)}
</syntaxhighlight>

=== Erstellen von zusätzlichen Werten in der Datenbank ===
[[Bild:SVG LogDB PV Bilanz.png|mini|900px|rechts|Die Definitiun diese Diagramms ist weiter unten beschrieben.]]
Hier werden Werte konsolidiert, weil z.B. der Wert PV_total_Month stetig steigt. Am Ende des Monats sind die gesamten Zwischenwerte ohne Aussagekraft und werden dann später mal gelöscht.
==== RAW Definition LogDBRep_PV_total_diff_Week ====
<syntaxhighlight lang="Perl">
defmod LogDBRep_PV_total_diff_Week DbRep LogDB
attr LogDBRep_PV_total_diff_Week DbLogExclude .*
attr LogDBRep_PV_total_diff_Week aggregation week
attr LogDBRep_PV_total_diff_Week allowDeletion 0
attr LogDBRep_PV_total_diff_Week device Dum.Energy
attr LogDBRep_PV_total_diff_Week reading PVTotalMonth
attr LogDBRep_PV_total_diff_Week room Strom->Energie,System
attr LogDBRep_PV_total_diff_Week timestamp_begin previous_month_begin
attr LogDBRep_PV_total_diff_Week timestamp_end previous_week_end
</syntaxhighlight>
==== RAW Definition LogDBRep_PV_total_max_Month ====
<syntaxhighlight lang="Perl">
defmod LogDBRep_PV_total_max_Month DbRep LogDB
attr LogDBRep_PV_total_max_Month DbLogExclude .*
attr LogDBRep_PV_total_max_Month aggregation month
attr LogDBRep_PV_total_max_Month allowDeletion 0
attr LogDBRep_PV_total_max_Month device Dum.Energy
attr LogDBRep_PV_total_max_Month reading PVTotalMonth
attr LogDBRep_PV_total_max_Month room Strom->Energie,System
attr LogDBRep_PV_total_max_Month timestamp_begin previous_month_begin
attr LogDBRep_PV_total_max_Month timestamp_end previous_day_end
</syntaxhighlight>
==== RAW Definition LogDBRep_PV_used_diff_Week ====
<syntaxhighlight lang="Perl">
defmod LogDBRep_PV_used_diff_Week DbRep LogDB
attr LogDBRep_PV_used_diff_Week DbLogExclude .*
attr LogDBRep_PV_used_diff_Week aggregation week
attr LogDBRep_PV_used_diff_Week allowDeletion 0
attr LogDBRep_PV_used_diff_Week device Dum.Energy
attr LogDBRep_PV_used_diff_Week reading PVMonth
attr LogDBRep_PV_used_diff_Week room Strom->Energie,System
attr LogDBRep_PV_used_diff_Week timestamp_begin previous_month_begin
attr LogDBRep_PV_used_diff_Week timestamp_end previous_week_end
</syntaxhighlight>
==== RAW Definition LogDBRep_PV_used_max_Month ====
<syntaxhighlight lang="Perl">
defmod LogDBRep_PV_used_max_Month DbRep LogDB
attr LogDBRep_PV_used_max_Month DbLogExclude .*
attr LogDBRep_PV_used_max_Month aggregation month
attr LogDBRep_PV_used_max_Month allowDeletion 0
attr LogDBRep_PV_used_max_Month device Dum.Energy
attr LogDBRep_PV_used_max_Month reading PVMonth
attr LogDBRep_PV_used_max_Month room Strom->Energie,System
attr LogDBRep_PV_used_max_Month timestamp_begin previous_month_begin
attr LogDBRep_PV_used_max_Month timestamp_end previous_month_end
</syntaxhighlight>

=== Timing für die Datenbank Einträge ===
<syntaxhighlight lang="Perl">
defmod DF_DB_Service DOIF ## Monatlich Einträge\
([01:13] and ($mday==1))(\
set LogDBRep_PV_used_max_Month maxValue writeToDB;;\
set LogDBRep_PV_total_max_Month maxValue writeToDB\
)\
## Wöchentliche Einträge\
DOELSEIF\
([01:17] and ($wday==1))(\
set LogDBRep_PV_used_diff_Week diffValue writeToDB;;\
set LogDBRep_PV_total_diff_Week diffValue writeToDB\
)\

attr DF_DB_Service DbLogExclude .*
attr DF_DB_Service do always
attr DF_DB_Service room System
</syntaxhighlight>

=== Löschen von nicht mehr benötigten Werten in der Datenbank ===
Hier wird endgültig aufgeräumt, alte momentan Werte werden gelöscht, wenn sie nach z.B. drei Monaten keine Relevanz mehr haben. Dafür wurden im vorherigen Abschnitt zusätzliche Werte in der Datenbank erzeugt, die in Diagrammen trotzdem noch einen trend erkennen lassen.
Wen eine immer größer werdende Datenbank mit steigenden Antwortzeiten nicht stört, der kann das Aufräumen auch weg lassen. Bei einer späteren Migration führt dies natürlich zu höherem Aufwand und hohen Laufzeiten.
<syntaxhighlight lang="Perl">
</syntaxhighlight>

== Wetter-/Leistungs-Prognose ==
Dies ist ein Thema, dass nicht wirklich gut zu fassen ist und ist eher etwas für Enthusiasten :-), wer schon mal mit Sonne, Wolken und Regen gerechnet hat versteht was ich meine. Dieser Ansatz ist nicht wissenschaftlicher Art und hat auch keinen Anspruch mathematischer Perfektion. Nach reinem Gefühl und mit aus dem Fenster schauen kommt jedoch ein respektables Ergebnis dabei heraus. Viel Vergnügen und Spaß beim mitbasteln ;-)
[[Bild:Plenticore_Forecast_Tagesanfang.png|mini|900px|rechts|Wenn der Tag begonnen hat ist die Prognose vom Vortag bereits im Diagramm. Der Wert Calculation in schwarz ist die aktuelle Korrektur.]]
=== Deutscher Wetter Dienst (DWD) ===
Der DWD liefert über Mosmix kostenlos, stunden aktuelle Prognosedaten. Über einen Link am Ende dieser Seite kommt man zum "Photovoltaikforum", wo dieses Thema erarbeitet wurde, weshalb ich es hier nicht wiederholen möchte.
Über Mosmix werden für diese Anwendung die Werte Rad1h und TTT bezogen, was der globalen Sonneneinstrahlung und der Temperatur entspricht.
Die Daten werden ins Gerät "DWD_Prognose" in das reading "output" als JSON String geschrieben und dort in readings ausgepackt.
Der Trigger erfolgt über das DOIF PV_Schedule , die Abholzeiten muss man noch auf die eigenen Belange anpassen, damit man nicht abholt bevor die Daten vom DWD bereit stehen. Hier gibt es oftmals Verzögerungen von über einer Stunde, was man auf dem FTP Server am Zeitstempel sehen kann. Auch hier bitte nicht zu oft abholen, damit die Server nicht überlastet werden.
==== Daten abholen und auspacken ====
fhem@raspberrypi:~/python/bin$ cat dwd_get_forecast.py
<syntaxhighlight lang="Python">
#
# Copyright (C) 2020 Kilian Knoll kilian.knoll@gmx.de
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
# Purpose
#Extract weather forecast data from DWD Mosmix for a given Station ID
#
# Background information:
# DWD provides 10 day forecast weather - and radiation data at an hourly resolution for over 5000 Stations worldwide (focus is on Germany/Europe though...)
# Description of kml file:
#https://www.dwd.de/DE/leistungen/opendata/help/schluessel_datenformate/kml/mosmix_elemente_pdf.pdf?__blob=publicationFile&v=3
#
#List of available stations:
#https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/mosmix_stationskatalog.cfg?view=nasPublication&nn=495490
#
# How to use this ?
# 1) Find the station close by your geographic location:
# Go to the website below, zoom to your location - and click on "Mosmix Stationen anzeigen"
# Once you found the closest station, please change the station number to the station number
# https://wettwarn.de/mosmix/mosmix.html
# In my case, I picked Station P755 (which is close to Munich)
# 2) Make changes in code below to reflect your station number - and the corresponding URL
# change
# self.mystation = P755
# below to the one you identified during step 1
# change the URL further down below to reflect the station:
# self.urlpath = 'https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_L/single_stations/P755/kml'
# Your one time setup is done...
#
# Implementation
# DWD provides two types of kml files
# single station kml files. These get updated approx every 6 hours
# all stations. These get updated hourly. However the file is pretty large. On embedded systems such as raspberry pi, I ran out of memory trying to parse XML files that size (exceeded 1GB of memory). Hence the decision to use the single station files
# we are only looking for a couple of key parameters that are relevant
#Currently the following Parameters get extracted from the kml file and put into a twodimensional array:
#mytimestamp : Timestamp of the forecast data
#Rad1h : Radiation Energy [kj/m²]
#TTT : Temperature 2 m above surface [°C]
#PPPP : Presssure Values (Surface Pressure reduced)
#FF : Wind speed [m/s]
#
#
# Update August 05 2020
# Kilian did a lot of perfect prework, but I did some cleanup on this code. Originally it was written for a different environment.
# The changes are related to the communication with FHEM and the code is triggered also by FHEM for a one time run each call.
# Unnessesary data is dropped, to reduce the amount of data transfered to FHEM

import urllib.request
import shutil
import zipfile
from bs4 import BeautifulSoup
import requests
import xml.etree.ElementTree as ET
import time
import datetime
import queue
import threading
import logging
import pprint

import fhem
import json

import sys
web = sys.argv[1]
station = sys.argv[2]

pp = pprint.PrettyPrinter(indent=4)

def connvertINTtimestamptoDWD(inputstring):
# Purpose: Convert a timestamp as presented by the UTC: 1545030000.0
# and return it to a UTC representation: 2018-12-17T08:00:00.000000Z
#mynewtime =time.mktime(datetime.datetime.strptime(inputstring, "%Y-%m-%dT%H:%M:%S.%fZ").timetuple())
#print ("neue Zeit ", mynewtime)
mysecondtime = (datetime.datetime.fromtimestamp(inputstring).strftime('%Y-%m-%dT%H:%M:%S.%f')[:-3]) + "Z"
return (mysecondtime)

# Main class that holds the required information
class dwdforecast(threading.Thread):
def __init__ (self, myqueue):
print ("Starting dwdforecast init ...")
self.myqueue = myqueue
self.event = threading.Event()
self.ext = 'kmz'
self.mystation = station # This should be your closes station
# Only use the "all_stations" if you got decent hardware
#self.urlpath = 'http://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml'
#On Raspberries & alikes, use the one for your specific station:
self.urlpath = 'https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_L/single_stations/' + self.mystation +'/kml'
self.lasttimecheck = 1534800680.0 # Dec 14th 2018 (pure initialization)
self.sleeptime = 15 #Time interval we poll the server [seconds]- please increase time since updates from DWD are hourly at best
self.myinit = 0 #So we can populate the queue initially / subsequently
threading.Thread.__init__ (self)
print ("I am looking for data from DWD for the following station: ", self.mystation)
print ("I will be polling the following URL for the latest updates ", self.urlpath)

# Based on the user specified URL, find the latest file file with it´s timestamp
def GetURLForLatest(self,urlpath, ext=''):
try:
page = requests.get(urlpath).text
except Exception as ErrorGetWebdata:
logging.error("%s %s",",GetURLForLatest Error getting data from the internet:", ErrorGetWebdata)
soup = BeautifulSoup(page, 'html.parser')
soup_reduced= soup.find_all('pre')
soup_reduced = soup_reduced[0]
counter = 0
for elements in soup_reduced:
elements = str(elements)
if (counter >0):
words =elements.split()
mytime = words[0] +"-" + words[1]
logging.debug("%s %s" ,",GetURLForLatest :DWD Filetimestamp found :", mytime)
mynewtime =time.mktime(datetime.datetime.strptime(mytime, "%d-%b-%Y-%H:%M").timetuple())
logging.debug("%s %s" ,",GetURLForLatest :DWD Filetimestamp found :", mynewtime)
#print ("From function GetURLForLatest -mynewtime", 2*mynewtime)

if (elements.find("LATEST") >0):
#print ("My element", elements)
counter = 1
myurl = [urlpath + '/' + node.get('href') for node in soup.find_all('a') if node.get('href').endswith(ext)]
return (myurl, mynewtime)

def connvertDWDtimestamptoINT(self,inputstring):
# Purpose: Convert a timestamp as presented by the DWD: 2018-12-25T07:00:00.000Z
# and return it to a UTC representation
mynewtime =time.mktime(datetime.datetime.strptime(inputstring, "%Y-%m-%dT%H:%M:%S.%fZ").timetuple())
#print ("neue Zeit ", mynewtime)
#mysecondtime = datetime.datetime.fromtimestamp(mynewtime).strftime('%Y-%m-%dT%H:%M:%S.%fZ')
#print ("Einmal retour", mysecondtime)
mycurrentINTtimestamp =int(mynewtime)
return (mycurrentINTtimestamp)

def connvertDWDtimestamptoINT(self,inputstring):
# Purpose: Convert a timestamp as presented by the DWD: 2018-12-25T07:00:00.000Z
# and return it to a UTC representation
mynewtime =time.mktime(datetime.datetime.strptime(inputstring, "%Y-%m-%dT%H:%M:%S.%fZ").timetuple())
mycurrentINTtimestamp =int(mynewtime)
return (mycurrentINTtimestamp)

try:
def run(self):
if (self.myinit== 0): #We populate the first timestamp to signal to main that we are up & running
temptimestamp = time.time()
print ("From dwdforecast - initial queue population", temptimestamp)
self.myqueue.put(temptimestamp)
self.myinit = 1
time.sleep(1)
try:
self.mydownloadfiles, self.mynewtime = self.GetURLForLatest(self.urlpath, self.ext)
#print ("Downloadfiles = ", self.mydownloadfiles)
#print ("Timestamp = ", self.mynewtime)
except Exception as ErrorReadFromDWD:
logging.error("%s %s" ,",dwdforecast :", ErrorReadFromDWD)

self.myarray =[]
for self.file in self.mydownloadfiles:
self.myarray.append(self.file)
self.temp_length = len(self.myarray)
self.url = self.myarray[self.temp_length-1]

logging.debug("%s %s %s",",dwdforecast : -BEFORE if- time comparison :", self.mynewtime, self.lasttimecheck)
# if (self.mynewtime > self.lasttimecheck):
logging.debug("%s %s %s" ,",dwdforecast : -in if- time comparison :", self.mynewtime, self.lasttimecheck)
#print ("DWD Weather - we have found a new kml file that we will download - timestamp was :", self.mynewtime)
#print ("DWD Weather - self.lasttimecheck was ", self.lasttimecheck)
self.lasttimecheck = self.mynewtime
self.file_name = "dwd_temp1.gz"
self.out_file = "dwd_temp2.gz"
self.targetdir ="./"
try:
time.sleep(10) #Assumption is - we see the file on the DWD server - but it has not yet been copied over
# Download the file from `url` and save it locally under `self.file_name`:
with urllib.request.urlopen(self.url) as self.response, open(self.file_name, 'wb') as self.out_file:
shutil.copyfileobj(self.response, self.out_file)
time.sleep(5) #not sure if this gets rid of the access problems
with zipfile.ZipFile(self.file_name,"r") as zip_ref:
Myzipfilename = (zip_ref.namelist())
Myzipfilename = str(Myzipfilename[0])
zip_ref.extractall(self.targetdir)
logging.debug("%s %s" ,",dwdforecast : -File that I extract is zipfile :", Myzipfilename)
time.sleep(5) #not sure if this gets rid of the access problems
except Exception as MyException:
logging.error("%s %s", ",subroutine dwdforecast exception getting the data from server : ", MyException)

self.tree = ET.parse(Myzipfilename)
self.root = self.tree.getroot()
self.root.tag
"""
<kml:kml xmlns:dwd="https://opendata.dwd.de/weather/lib/pointforecast_dwd_extension_V1_0.xsd" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:xal="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">

<kml:kml xmlns:dwd="https://opendata.dwd.de/weather/lib/pointforecast_dwd_extension_V1_0.xsd" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:xal="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">
"""
#--------------------------------------------------
#Namespace definition for kml file:
#
self.ns = {'dwd': 'https://opendata.dwd.de/weather/lib/pointforecast_dwd_extension_V1_0.xsd', 'gx': 'http://www.google.com/kml/ext/2.2',
'kml': 'http://www.opengis.net/kml/2.2', 'atom': 'http://www.w3.org/2005/Atom', 'xal':'urn:oasis:names:tc:ciq:xsdschema:xAL:2.0'}
#--------------------------------------------------
# We get the timestamps
#
self.timestamps = self.root.findall('kml:Document/kml:ExtendedData/dwd:ProductDefinition/dwd:ForecastTimeSteps/dwd:TimeStep',self.ns)
self.i = 0
self.timevalue=[]
for self.child in self.timestamps:
#print ("TIMESTAMPS", child.text)
self.timevalue.append(self.child.text)
"""
for j in timevalue:
print ("Zeit",i, " ", timevalue[i])
i = i+1
"""

for self.elem in self.tree.findall('./kml:Document/kml:Placemark',self.ns): #Position us at the Placemark
#print ("SUCERJH ", sucher)
#print ("Elemente ", elem.tag, elem.attrib, elem.text)
self.mylocation = self.elem.find('kml:name',self.ns).text #Look for the station Number

# Hier IF Frage einbauen
if (self.mylocation == self.mystation):
#print ("meine location", self.mylocation)
self.myforecastdata = self.elem.find('kml:ExtendedData',self.ns)
for self.elem in self.myforecastdata:
#We may get the following strings and are only interested in the right hand quoted property name WPcd1:
#{'{https://opendata.dwd.de/weather/lib/pointforecast_dwd_extension_V1_0.xsd}elementName': 'WPcd1'}
self.trash = str(self.elem.attrib)
self.trash1,self.mosmix_element = self.trash.split("': '")
self.mosmix_element, self.trash = self.mosmix_element.split("'}")
#-------------------------------------------------------------
# Currently looking at the following key Data:
# Looking for the following mosmix_elements
#FF : Wind Speed [m/s]
#Rad1h : Global irridance [kJ/m²]
#TTT : Temperature 2m above ground [Kelvin]
#PPPP : Pressure reduced [Pa]
#-------------------------------------------------------------
if ('FF' == self.mosmix_element):
self.FF_temp = self.elem[0].text
self.FF = list (self.FF_temp.split())
if ('Rad1h' == self.mosmix_element):
self.Rad1h_temp = self.elem[0].text
self.Rad1h = list (self.Rad1h_temp.split())
if ('TTT' == self.mosmix_element):
self.TTT_temp = self.elem[0].text
self.TTT = list(self.TTT_temp.split())
counter = 0
# We convert from Kelvin to Celcius...:
for i in self.TTT:
self.TTT[counter]=round((float(self.TTT[counter])-273.13),2)
#print (self.TTT[counter])
counter = counter +1
if ('PPPP' == self.mosmix_element):
self.PPPP_temp = self.elem[0].text
self.PPPP = list (self.PPPP_temp.split())

#------------------------------------
# Define empty array
self.mosmixdata =[]
for self.j in range(6): #Right now we have timevalue, mytimestamp, self.FF Rad1h TTT PPPP
self.column = []
self.counter = 0
for self.i in self.timevalue:
self.column.append(0)
self.mosmixdata.append(self.column)
#------------------------------------
#Populate values
counter = 0

for self.i in self.timevalue:
self.mytimestamp = self.connvertDWDtimestamptoINT(self.timevalue[counter])
self.mosmixdata[0][counter]=self.timevalue[counter]
self.mosmixdata[1][counter]=self.mytimestamp
self.mosmixdata[2][counter]=self.Rad1h[counter]
self.mosmixdata[3][counter]=self.TTT[counter]
self.mosmixdata[4][counter]=self.PPPP[counter]
self.mosmixdata[5][counter]=self.FF[counter]
counter = counter + 1
#------------------------------------------

self.cols = len(self.mosmixdata)
rows = 0
if self.cols:
self.rows = len(self.mosmixdata[0])
self.MosmixFileFirsttimestamp = self.mosmixdata[1][0]
#print ("My first stamp from the file is:",self.mosmixdata[0][0],"Endstring",self.mosmixdata[1][0] )
#print ("-------------------------------------------------")
#print (self.mosmixdata)
self.indexcounter_addrows=1
self.MyWeathervalues = {}
try:
print ("Here is what we got from DWD :")
for j in range(self.rows):
if (self.indexcounter_addrows >0): #We are adding from the point onward - see self.indexcounter_addrows if check below
#print ("counting indices", self.indexcounter_addrows)
#self.MyWeathervalues.update({'mydatetime':self.mosmixdata[0][j]})
#self.MyWeathervalues.update({'mytimestamp':self.mosmixdata[1][j]})
if (self.mosmixdata[2][j] > '0.00'): #Reduce unneccessary data
self.time = time.strftime("%Y-%m-%d_%H:%M", time.localtime(self.mosmixdata[1][j]))
self.MyWeathervalues.update({self.time + '_Rad1wh':int(round(float(self.mosmixdata[2][j]) * 0.277778 , 0))})
self.MyWeathervalues.update({self.time + '_TTT':self.mosmixdata[3][j]})
#self.MyWeathervalues.update({'TTT':self.mosmixdata[3][j]})
#self.MyWeathervalues.update({'PPPP':self.mosmixdata[4][j]})
#self.MyWeathervalues.update({'FF':self.mosmixdata[5][j]})

#print ('mydatetime',self.mosmixdata[0][j],'mytimestamp ',self.mosmixdata[1][j],'Rad1h ',self.mosmixdata[2][j],'TTT ',self.mosmixdata[3][j], 'PPPP',self.mosmixdata[4][j],'FF',self.mosmixdata[5][j])

import re
self.message = re.sub("'", "\"", str(self.MyWeathervalues))
#print(self.MyWeathervalues)
#print(self.message)

try:
with open('/opt/fhem/python/pwd_fhem.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

fh = fhem.Fhem(web, protocol="http", port=8083, username=credentials["username"], password=credentials["password"])

fh.send_cmd("setreading DWD_Prognose output " + self.message)

self.mytimestamp = connvertINTtimestamptoDWD(self.mynewtime)
logging.debug ("%s %s %s %s", ",Subroutine dwdforecast -we have used DWD file from time : ", self.mynewtime, " ", self.mytimestamp)
except Exception as ErrorDWDArray:
print ("Shit happened ?", ErrorDWDArray)
logging.error ("%s %s", ",subroutine dwdforecast final exception : ", ErrorDWDArray)
logging.debug("%s %s", "From dwdforecast - we have found a true commit and have updated the database at the following dwd time :", self.mynewtime)
time.sleep(self.sleeptime) # We are putting in a sleep
self.myqueue.put(self.mynewtime)

except Exception as ExceptionError:
print ("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX")
print ("XXX-Aus Subroutine dwdforecast -verrant ? ", ExceptionError)
print ("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX")
logging.error("%s %s", ",subroutine dwdforecast final exception : ", ExceptionError)

if __name__ == "__main__":

logging.basicConfig(filename="./log/dwd_debug.txt",level=logging.DEBUG)
#
"""
Interaction can be 'Simple' - or 'Complex'
Simple : Try to get weather data once only - then terminate
Complex : Start a seperate queue that continuously polls the DWD server on the internet to get updated data
"""
Interaction = 'Simple' #Interaction can be 'Simple' - or 'Complex'
#

#-----------------------------------------------------------------
# START Queue (To read dwd values and populate them to database):
try:
myQueue1 = queue.Queue()
myThread1= dwdforecast(myQueue1)
myThread1.start()
while myQueue1.empty():
print(" Waiting on DWD dwdforecastdata Queue results to tell it is started...")
logging.info("%s " ",Main :Waiting on Queue results to be populated ...")
time.sleep(1)
# Queue End (To read values from DWD)
#_________________________________________________________________
i = 0

try:
while i <1:
if not myQueue1.empty(): # Falls was in der Queue steht machen wir was
quelength = myQueue1.qsize() # Wenn da viele Werte angelaufen sind, nehmen wir jetzt einfach den Letzten
#print ("LAENGE der QUEUE -XXXXXXXXXXXXXXXXXXXXXXX : ", quelength)
logging.info("%s %s " ,",Main :Queue length is : ", quelength)

for x in range (0,quelength):
LastDWDtimestamp = myQueue1.get() # Das ist die magische Zeile in der wir den Wert aus der Queue abholen
mylasttimestamp = connvertINTtimestamptoDWD(LastDWDtimestamp)
print ("From Main : DWD File access I checked / got uploaded by DWD was at :", LastDWDtimestamp,mylasttimestamp )
i = i + 1

except Exception as OtherExceptionError:
print ("hit some other error.... !", OtherExceptionError)

except Exception as FinalExceptionError:
print ("I am clueless ... Hit some other error .... !", FinalExceptionError)
</syntaxhighlight>
==== RAW Definition DWD_Prognose ====
<syntaxhighlight lang="Perl">
defmod DWD_Prognose expandJSON DWD_Prognose:output:.\{.*}
attr DWD_Prognose DbLogExclude .*
attr DWD_Prognose alias DWD_Prognose
attr DWD_Prognose comment Das Device wird über ein Python Skript im reading output befüllt.\
deletereading DWD_Prognose .*_Rad1wh\

attr DWD_Prognose group PV Eigenverbrauch
attr DWD_Prognose icon measure_photovoltaic_inst
attr DWD_Prognose room Informationen->Wetter,Strom->Photovoltaik,Strom->System
attr DWD_Prognose sortby 02
</syntaxhighlight>
=== ProPlanta ===
Die Webseite Proplanta stellt unter anderem chOfRain*, cloud* in einer drei Stunden Prognose bereit und dies dann für mehrere Tage fc0 , fc1, ...
==== RAW Definition ProPlanta ====
<syntaxhighlight lang="Perl">
defmod ProPlanta PROPLANTA <Wohnort> de
attr ProPlanta DbLogExclude .*
attr ProPlanta DbLogInclude cloudBaseMax,cloudBaseMin,fc0_cloud06,fc0_cloud09,fc0_cloud12,fc0_cloud15,fc0_cloud18,fc0_rad,fc0_sun,fc0_uv,fc0_weather06,fc0_weather09,fc0_weather12,fc0_weather15,fc0_weather18,fc1_cloud06,fc1_cloud09,fc1_cloud12,fc1_cloud15,fc1_cloud18,fc1_rad,fc1_sun,fc1_uv,fc1_weather06,fc1_weather09,fc1_weather12,fc1_weather15,fc1_weather18,weather
attr ProPlanta INTERVAL 900
attr ProPlanta alias ProPlanta
attr ProPlanta event-on-change-reading cloudBaseMax,cloudBaseMin,fc0_cloud06,fc0_cloud09,fc0_cloud12,fc0_cloud15,fc0_cloud18,fc0_rad,fc0_sun,fc0_uv,fc0_weather06,fc0_weather09,fc0_weather12,fc0_weather15,fc0_weather18,fc1_cloud06,fc1_cloud09,fc1_cloud12,fc1_cloud15,fc1_cloud18,fc1_rad,fc1_sun,fc1_uv,fc1_weather06,fc1_weather09,fc1_weather12,fc1_weather15,fc1_weather18,weather
attr ProPlanta forecastDays 4
attr ProPlanta group ASC Environment
attr ProPlanta icon weather_sunrise
attr ProPlanta room Informationen->Wetter,Rollos
attr ProPlanta sortby 02
</syntaxhighlight>
=== myUtils.pm Funktionen ===
==== Solar_forecast ====
Achtung, diese Funktion ist noch nicht vollständig ausprogrammiert. Es wurden bereits Übergabeparameter integriert, um z.B. andere Wetterdienste zu berücksichtigen.
Um diese Funktion zu nutzen muss ein Dummy PV_Anlage_1_config vorhanden sein, in dem unter anderem die Modul und Anlagen Ausrichtung konfiguriert wird.
Rückfragen gerne im Forum.
<syntaxhighlight lang="Perl">
###########################################################
# Subroutine to calculate radiation
###########################################################
sub Solar_forecast($$$$$$$) {

my $logdb = $_[0] ;
my $logdbrep = $_[1] ; # Das wird zum Löschen in der LogDB verwendet und muss entsprechend konfiguriert sein.
my $logdevice = $_[2] ;
# Hier könnte man noch andere Wetterdienste berücksichtigen bzw den Device Namen ändern
my $wetter_1 = $_[4] ; if ($wetter_1 ne "DWD_Prognose") {return("$wetter_1 not supported")} ;
my $wetter_2 = $_[5] ; if ($wetter_2 ne "ProPlanta" ) {return("$wetter_2 not supported")} ;
my $fc = $_[6] ; # Wieviel Tage in die Zukunft soll es gehen? 0,1,2
my $reading = $_[3].$fc ;

my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); $year += 1900; $mon += 1;
my ($Solar_Cloud,$Solar_Rain,$Solar_Temp,$Solar_SolarRadiation,$logentry,$i) = (0) x 6 ;
my ($cloudk,$raink,$tempk,$cloudk_base,$raink_base,$tempk_base) = (0) x 6 ;
my ($Solar_Correction_Cloud,$Solar_Correction_Rain,$Solar_Correction_Temp,$Solar_Plain) = (1) x 4 ;
my (@Solar_,@module_count) = (0,0,0) ;

# Initialisieren des Basis TIMESTAMP für den Forecast
my $timestring = time_str2num($year."-".$mon."-".$mday." 08:00:00") ;
my $timestamp = POSIX::strftime("%Y-%m-%d %H:00:00",localtime($timestring+$fc*24*60*60)) ;

# Bei Forecast ab dem nächsten Tag zuerst die bisherigen Einträge für den Tag löschen
# if ( $fc != 0 ) {
fhem "set ".$logdbrep." sqlCmd DELETE FROM history WHERE DEVICE='".$logdevice."' AND READING='".$reading."' AND TIMESTAMP>='".$timestamp."'" ;
# };

# Es werden Stundenwerte von 08:00 bis 19:00 Uhr berechnet
for ($i = 8; $i <= 19; $i++) {
$timestring = time_str2num($year."-".$mon."-".$mday." ".$i.":00:00") ;
$timestamp = POSIX::strftime("%Y-%m-%d %H:00:00",localtime($timestring+$fc*24*60*60)) ;

# Bei ProPlanta liegen die Werte im drei Stunden Abstand vor
if ( $wetter_2 eq "ProPlanta") {
if ( $i >= 6 and $i < 9 )
{ $Solar_Cloud = ReadingsVal($wetter_2,"fc".$fc."_cloud09" ,0) ;
$Solar_Rain = ReadingsVal($wetter_2,"fc".$fc."_chOfRain09",0) ; } ;
if ( $i >= 9 and $i < 12 )
{ $Solar_Cloud = ReadingsVal($wetter_2,"fc".$fc."_cloud09" ,0) ;
$Solar_Rain = ReadingsVal($wetter_2,"fc".$fc."_chOfRain09",0) ; } ;
if ( $i >= 12 and $i < 15 )
{ $Solar_Cloud = ReadingsVal($wetter_2,"fc".$fc."_cloud12" ,0) ;
$Solar_Rain = ReadingsVal($wetter_2,"fc".$fc."_chOfRain12",0) ; } ;
if ( $i >= 15 and $i < 18 )
{ $Solar_Cloud = ReadingsVal($wetter_2,"fc".$fc."_cloud15" ,0) ;
$Solar_Rain = ReadingsVal($wetter_2,"fc".$fc."_chOfRain15",0) ; } ;
};

if ( $wetter_1 eq "DWD_Prognose") {
$Solar_Temp = ReadingsVal($wetter_1,POSIX::strftime("%Y-%m-%d_%H_00_TTT", localtime($timestring+($fc*24-1)*60*60)),0)+10;
$Solar_SolarRadiation = ReadingsVal($wetter_1,POSIX::strftime("%Y-%m-%d_%H_00_Rad1wh",localtime($timestring+($fc*24-1)*60*60)),0) ;
};

$cloudk = ReadingsVal($logdevice."_config","forecast_cloudk",0) * -0.01 ;
if ($cloudk ne 0) {
$cloudk_base = ReadingsVal($logdevice."_config","forecast_cloudk_base",0) ;
$Solar_Correction_Cloud = round((1 + ($Solar_Cloud - $cloudk_base) * $cloudk / 100),3) ;
};

$raink = ReadingsVal($logdevice."_config","forecast_raink",0) * -0.01 ;
if ($raink ne 0) {
$raink_base = ReadingsVal($logdevice."_config","forecast_raink_base" ,0) ;
$Solar_Correction_Rain = round((1 + ($Solar_Rain - $raink_base ) * $raink / 100),3) ;
};

$tempk = ReadingsVal($logdevice."_config","forecast_tempk",0) * -0.01 ;
if ($tempk ne 0) {
$tempk_base = ReadingsVal($logdevice."_config","forecast_tempk_base" ,0) ;
$Solar_Correction_Temp = round((1 + ($Solar_Temp - $tempk_base ) * $tempk / 100),3) ;
};

my $Solar_Correction_Faktor = ReadingsVal($logdevice."_config","forecast_factor",1) ;

$logentry = 0 ;
for(my $j=1;$j<4;$j++){
$module_count[$j] = ReadingsVal($logdevice."_config","module_".$j."_count",0) ;
if ($module_count[$j] ne 0) {
$Solar_Plain = round(Solar_plain(ReadingsVal($logdevice."_config","module_".$j."_plain",0) , ReadingsVal($logdevice."_config","module_".$j."_direction",0) , $timestamp),3) ;
Log 3, "plain/direction : ".ReadingsVal($logdevice."_config","module_".$j."_plain",0)."/".ReadingsVal($logdevice."_config","module_".$j."_direction",0)." >>> ".$Solar_Plain ;
$Solar_[$j] = $module_count[$j] * ReadingsVal($logdevice."_config","module_".$j."_power",1)/1000 ;
$Solar_[$j] = $Solar_[$j] * $Solar_Plain ;
$Solar_[$j] = $Solar_[$j] * $Solar_SolarRadiation ;
$Solar_[$j] = $Solar_[$j] * $Solar_Correction_Temp * $Solar_Correction_Cloud * $Solar_Correction_Rain * $Solar_Correction_Faktor ;
$Solar_[$j] = ($Solar_[$j] lt 0)?0:round($Solar_[$j],0) ;
};
$logentry = $logentry + $Solar_[$j] ;
if ($fc == 0 and $hour == $i) {
fhem "setreading ".$logdevice." Solar_".ReadingsVal($logdevice."_config","module_".$j."_name",0)." ".$Solar_[$j] ;
};
};

if ($fc == 0) {
fhem "set ".$logdb." addCacheLine ".$timestamp."|".$logdevice."|addlog|".$reading.": ".$logentry."|".$reading."|".$logentry."|";
};

if ($fc == 0 and $hour == $i and ($module_count[1] ne 0 or $module_count[2] ne 0 or $module_count[3] ne 0)) {
fhem "setreading ".$logdevice." Solar_SolarRadiation ".$Solar_SolarRadiation ;
fhem "setreading ".$logdevice." Solar_Cloud ".$Solar_Cloud ;
fhem "setreading ".$logdevice." Solar_Rain ".$Solar_Rain ;
fhem "setreading ".$logdevice." Solar_Temp ".$Solar_Temp ;
fhem "setreading ".$logdevice." Solar_Correction_Cloud ".$Solar_Correction_Cloud ;
fhem "setreading ".$logdevice." Solar_Correction_Rain ".$Solar_Correction_Rain ;
fhem "setreading ".$logdevice." Solar_Correction_Temp ".$Solar_Correction_Temp ;
fhem "setreading ".$logdevice." Solar_Calculation ".$logentry ;

Log 3, "Solar_Plain : ".$Solar_Plain ;
Log 3, "Solar_SolarRadiation : ".$Solar_SolarRadiation ;
Log 3, "Solar_Cloud : ".$Solar_Cloud ;
Log 3, "cloudk : ".$cloudk." ".$cloudk_base ;
Log 3, "Solar_Correction_Cloud : ".$Solar_Correction_Cloud ;
Log 3, "Solar_Rain : ".$Solar_Rain ;
Log 3, "raink : ".$raink." ".$raink_base ;
Log 3, "Solar_Correction_Rain : ".$Solar_Correction_Rain ;
Log 3, "Solar_Temp : ".$Solar_Temp ;
Log 3, "tempk : ".$tempk." ".$tempk_base ;
Log 3, "Solar_Correction_Temp : ".$Solar_Correction_Temp ;
Log 3, $fc." ".$hour." ".$i." ".$Solar_SolarRadiation." ".$logentry ;
} ;

if ($fc != 0) {
fhem "set ".$logdb." addCacheLine ".$timestamp."|".$logdevice."|addlog|".$reading.": ".$logentry."|".$reading."|".$logentry."|";

Log 3, "Solar_Plain : ".$Solar_Plain ;
Log 3, "Solar_SolarRadiation : ".$Solar_SolarRadiation ;
Log 3, "Solar_Cloud : ".$Solar_Cloud ;
Log 3, "cloudk : ".$cloudk." ".$cloudk_base ;
Log 3, "Solar_Correction_Cloud : ".$Solar_Correction_Cloud ;
Log 3, "Solar_Rain : ".$Solar_Rain ;
Log 3, "raink : ".$raink." ".$raink_base ;
Log 3, "Solar_Correction_Rain : ".$Solar_Correction_Rain ;
Log 3, "Solar_Temp : ".$Solar_Temp ;
Log 3, "tempk : ".$tempk." ".$tempk_base ;
Log 3, "Solar_Correction_Temp : ".$Solar_Correction_Temp ;
Log 3, $fc." ".$i." ".$Solar_SolarRadiation." ".$logentry ;
} ;
} ;
return (0);
};
</syntaxhighlight>

==== Solar_Plain ====
<syntaxhighlight lang="Perl">
sub Solar_plain($$$) {

my $angle = $_[0];
my $orienta = $_[1];
my $time = $_[2];
my $azimuth = fhem "get Astro text SunAz ".$time ;

# angles in radiant
my $rad = 57.296;
my $elevation = fhem "get Astro text SunAlt ".$time ;
$elevation = $elevation / $rad;
$angle = $angle / $rad;
my $orientation = ($azimuth - 180 - $orienta) / $rad;

# avoid unrealistic values (normally formula should only be used within boundaries of orientation +/- 90 degrees)
return (0.001) if ($elevation <= 0.25);

if(cos($orientation) < 0.05 && cos($orientation) > -0.2) {$orientation =$orientation - 0.2};

# Log3 "", 1, "Solar radiation, azimuth = $azimuth, orientation=$orientation, elevation=$elevation, angle=$angle";
my $factor = sin($angle) /
(sin( $elevation) /
cos( $elevation)) *
cos($orientation) +
cos($angle);

# otherwise too big values (normally formula should only be used within boundaries of orientation +/- 90 degrees)
if ($factor > - 0.05 && $factor < 0.05) {$factor = 0.05};

return ($factor);
};
</syntaxhighlight>

=== wunderground ===
Diesen Dienst nutze ich nicht für die Prognose, jedoch kann man dort private Wetterstationen in seinem näheren Umfeld finden, die die Sonneneinstrahlung und den UV Index messen. Das ist dann als aktueller Wert in den Diagrammen zu sehen und lässt aktuelle Beschattung durch Wolken erkennen. Hier kann man dann auch mehrere Stationen definieren und eventuell mit einem Durchschnitt arbeiten, wenn nicht gerade der Nachbar eine Station hat.
Für diese Abfrage ist keine Registrierung notwendig und man muss auch nicht selber mir einer Station Daten liefern.
Aber bitte, die Abfrage nicht in einem zu kurzen Abstand, also mit hoher Frequenz stellen! Hier wird alle 15 Minuten (900 Sekunden) abgefragt.
=== RAW Definition Wetter_<Wohnort> ===
Ggf. muss UConv vorher noch aktiviert werden:
<syntaxhighlight lang="Perl">
define uconvInit notify global:INITIALIZED {use UConv}
</syntaxhighlight>

<syntaxhighlight lang="Perl">
defmod wetter_<Wohnort> HTTPMOD https://www.wunderground.com/dashboard/pws/<Wohnort_Station> 900

attr wetter_<Wohnort> DbLogExclude .*
attr wetter_<Wohnort> DbLogInclude solarRadiation,solarUV,temperature
attr wetter_<Wohnort> alias wetter_<Wohnort>
attr wetter_<Wohnort> enableControlSet 1
attr wetter_<Wohnort> event-on-change-reading solarRadiation,solarUV,temperature
attr wetter_<Wohnort> group ASC Environment
attr wetter_<Wohnort> icon weather_sunrise
attr wetter_<Wohnort> reading01Name date
attr wetter_<Wohnort> reading01Regex Summary.*>([[:alpha:]]{1,8} [\d]{1,2}, [\d]{4})<.*Temperature
attr wetter_<Wohnort> reading02Format %.1f
attr wetter_<Wohnort> reading02Name dewpointTemperature
attr wetter_<Wohnort> reading02OExpr UConv::f2c($val,2)
attr wetter_<Wohnort> reading02Regex DEWPOINT.*>([\d\.]+)<.*HUMIDITY
attr wetter_<Wohnort> reading03Name dewpointTemperature_EN
attr wetter_<Wohnort> reading03Regex DEWPOINT.*>([\d\.]+)<.*HUMIDITY
attr wetter_<Wohnort> reading04Format %.0f
attr wetter_<Wohnort> reading04Name humidity
attr wetter_<Wohnort> reading04Regex HUMIDITY.*>([\d\.]+)<.*WIND
attr wetter_<Wohnort> reading05Name precip1hrmetric
attr wetter_<Wohnort> reading05Regex PRECIP RATE.*>([\d\.]+)<.*PRECIP TOTAL
attr wetter_<Wohnort> reading06Name preciptodaymetric
attr wetter_<Wohnort> reading06Regex PRECIP TOTAL.*>([\d\.]+)<.*tile-precipitation
attr wetter_<Wohnort> reading07Format %.2f
attr wetter_<Wohnort> reading07Name pressure
attr wetter_<Wohnort> reading07OExpr UConv::inhg2hpa($val,2)
attr wetter_<Wohnort> reading07Regex CURRENT.*>([\d\.]+)<.*tile-pressure
attr wetter_<Wohnort> reading08Format %.2f
attr wetter_<Wohnort> reading08Name pressure_EN
attr wetter_<Wohnort> reading08Regex CURRENT.*>([\d\.]+)<.*tile-pressure
attr wetter_<Wohnort> reading09Name solarRadiation
attr wetter_<Wohnort> reading09Regex SOLAR RADIATION.*CURRENT.*weather__text">([\d\.]+)
attr wetter_<Wohnort> reading10Name solarUV
attr wetter_<Wohnort> reading10Regex CURRENT UV.*>([\d\.]+)<.*UV RISK
attr wetter_<Wohnort> reading11Format %.1f
attr wetter_<Wohnort> reading11Name temperature
attr wetter_<Wohnort> reading11OExpr UConv::f2c($val,2)
attr wetter_<Wohnort> reading11Regex current-temp.*">([- ]*[\d\.]+).*DEWPOINT
attr wetter_<Wohnort> reading12Format %.1f
attr wetter_<Wohnort> reading12Name temperature_EN
attr wetter_<Wohnort> reading12Regex current-temp.*">([- ]*[\d\.]+).*DEWPOINT
attr wetter_<Wohnort> reading13Format %.1f
attr wetter_<Wohnort> reading13Name windChill
attr wetter_<Wohnort> reading13OExpr UConv::f2c($val,2)
attr wetter_<Wohnort> reading13Regex Feels Like.*>([\d\.]+)<.*wind-dial__container
attr wetter_<Wohnort> reading14Format %.1f
attr wetter_<Wohnort> reading14Name windChill_EN
attr wetter_<Wohnort> reading14Regex Feels Like.*>([\d\.]+)<.*wind-dial__container
attr wetter_<Wohnort> reading15Name windDirection
attr wetter_<Wohnort> reading15OExpr UConv::compasspoint2compasspoint($val,"en",1,"de")
attr wetter_<Wohnort> reading15Regex WIND FROM.*>([NESW]+)<.*GUST
attr wetter_<Wohnort> reading16Name windDirection_EN
attr wetter_<Wohnort> reading16Regex WIND FROM.*>([NESW]+)<.*GUST
attr wetter_<Wohnort> reading17Format %.0f
attr wetter_<Wohnort> reading17Name windSpeed
attr wetter_<Wohnort> reading17OExpr UConv::mph2kph($val,1)
attr wetter_<Wohnort> reading17Regex wind-dial__container.*>([\d\.]+)<.*unit-speed
attr wetter_<Wohnort> reading18Name windSpeed_EN
attr wetter_<Wohnort> reading18Regex wind-dial__container.*>([\d\.]+)<.*unit-speed
attr wetter_<Wohnort> reading19Name windGust
attr wetter_<Wohnort> reading19OExpr UConv::mph2kph($val,1)
attr wetter_<Wohnort> reading19Regex GUST.*>([\d\.]+)<.*mph
attr wetter_<Wohnort> reading20Name windGust_EN
attr wetter_<Wohnort> reading20Regex GUST.*>([\d\.]+)<.*mph
attr wetter_<Wohnort> room Informationen->Wetter,Rollos
attr wetter_<Wohnort> sortby 03
attr wetter_<Wohnort> stateFormat T: temperature °C | F: humidity % | W: windSpeed km/h | D: pressure hPa | U: solarUV | R: solarRadiation W/m²
attr wetter_<Wohnort> timeout 5
</syntaxhighlight>

== Diagramme ==
=== RAW Definition Hauptverbraucher ===
[[Bild:Plenticore_Hauptverbraucher.png|mini|600px|rechts|]]
==== SVG_LogDB_Photovoltaik_2 ====
<pre>
defmod SVG_LogDB_Photovoltaik_2 SVG LogDB:SVG_LogDB_Photovoltaik_2:HISTORY
attr SVG_LogDB_Photovoltaik_2 DbLogExclude .*
attr SVG_LogDB_Photovoltaik_2 group PV Eigenverbrauch
attr SVG_LogDB_Photovoltaik_2 plotsize 1400,320
attr SVG_LogDB_Photovoltaik_2 room Strom->Info,Strom->Photovoltaik
attr SVG_LogDB_Photovoltaik_2 sortby 00
</pre>
==== GPLOTFILE SVG_LogDB_Photovoltaik_2.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-03-16 10:23:52
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Hauptverbraucher'
set ytics
set y2tics
set grid
set ylabel "Leistung"
set y2label ""

#LogDB PV_Anlage_1:Total_DC_Power:::$val=abs($val)
#LogDB PV_Anlage_1:Total_PV_Power_reserve::
#LogDB StromZaehler_Heizung:SMAEM1901401955_Saldo_Wirkleistung:::$val=abs($val)
#LogDB shelly02:Power_0::
#LogDB shelly03:Power::

plot "<IN>" using 1:2 axes x1y2 title 'Total_DC' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Total_PV_reserve' ls l2 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Heizung' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Pool' ls l8 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Waschmaschine' ls l3 lw 1 with lines
</pre>
=== RAW Definition Leistungsbezug ===
[[Bild:Plenticore_Leistungsbezug.png|mini|600px|rechts|]]
==== SVG_LogDB_Photovoltaik_3 ====
<pre>
defmod SVG_LogDB_Photovoltaik_3 SVG LogDB:SVG_LogDB_Photovoltaik_3:HISTORY
attr SVG_LogDB_Photovoltaik_3 DbLogExclude .*
attr SVG_LogDB_Photovoltaik_3 group PV Eigenverbrauch
attr SVG_LogDB_Photovoltaik_3 plotsize 1400,320
attr SVG_LogDB_Photovoltaik_3 room Strom->Info,Strom->Photovoltaik
attr SVG_LogDB_Photovoltaik_3 sortby 00
</pre>
==== GPLOTFILE SVG_LogDB_Photovoltaik_3.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-07-22 13:51:57
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Leistungsbezug'
set ytics
set y2tics
set grid
set ylabel "Leistung"
set y2label ""
set yrange [0:9500]
set y2range [0:9500]

#LogDB PV_Anlage_1:Total_DC_Power:::$val=abs($val)
#LogDB PV_Anlage_1:Home_own_consumption_from_PV::
#LogDB PV_Anlage_1:Home_own_consumption_from_battery::
#LogDB PV_Anlage_1:Home_own_consumption_from_grid::
#LogDB PV_Anlage_1:Actual_battery_charge_usable_Power::
#LogDB PV_Anlage_1:Total_DC_Power_Max::
#LogDB PV_Anlage_1:Battery_temperature:::$val=$val*100
#LogDB Heizung:heatSourceIN:::$val=$val*100

plot "<IN>" using 1:2 axes x1y2 title 'Total_DC_Power' ls l1fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'own_PV' ls l2fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Bat_use' ls l0fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Grid_use' ls l5 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Bat_usable' ls l4 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Total_DC_Max' ls l6 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Bat_Temp_Trend' ls l0 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Out_Temp_Trend' ls l2 lw 2 with lines
</pre>
=== RAW Definition PV_Bilanz ===
[[Bild:SVG LogDB PV Bilanz.png|mini|600px|rechts|]]
==== SVG_LogDB_PV_Bilanz ====
<pre>
defmod SVG_LogDB_PV_Bilanz SVG LogDB:SVG_LogDB_PV_Bilanz:HISTORY
attr SVG_LogDB_PV_Bilanz DbLogExclude .*
attr SVG_LogDB_PV_Bilanz alias SVG_LogDB_PV_Bilanz
attr SVG_LogDB_PV_Bilanz fixedrange year
attr SVG_LogDB_PV_Bilanz plotsize 1400,320
attr SVG_LogDB_PV_Bilanz room Strom->Energie
</pre>
==== GPLOTFILE SVG_LogDB_PV_Bilanz.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-08-02 09:55:06
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'PV_Bilanz'
set ytics
set y2tics
set grid ytics
set ylabel "KWh"
set y2label "KWh"

#LogDB Dum.Energy:max_month_PVMonth::
#LogDB Dum.Energy:diff_week_PVMonth::
#LogDB Dum.Energy:diff_week_PVTotalMonth::

plot "<IN>" using 1:2 axes x1y2 title 'PV-Bezug-Monat' ls l2fill lw 2 with points,\
"<IN>" using 1:2 axes x1y2 title 'PV-Bezug-Woche' ls l2fill lw 1 with fsteps,\
"<IN>" using 1:2 axes x1y2 title 'PV-Total-Woche' ls l1fill lw 1 with lines
</pre>

=== RAW Definition Forecast / Calculation ===
[[Bild:Plenticore_Forecast.png|mini|600px|rechts|]]
==== SVG_LogDB_Photovoltaik_4 ====
<pre>
defmod SVG_LogDB_Photovoltaik_4 SVG LogDB:SVG_LogDB_Photovoltaik_4:HISTORY
attr SVG_LogDB_Photovoltaik_4 DbLogExclude .*
attr SVG_LogDB_Photovoltaik_4 group PV Eigenverbrauch
attr SVG_LogDB_Photovoltaik_4 plotsize 1400,320
attr SVG_LogDB_Photovoltaik_4 room Strom->Photovoltaik
attr SVG_LogDB_Photovoltaik_4 sortby 00
</pre>
==== GPLOTFILE SVG_LogDB_Photovoltaik_4.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-08-17 08:58:42
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Forecast / Calculation'
set ytics
set y2tics
set grid
set ylabel "Leistung"
set y2label "Leistung"
set yrange [0:10000]
set y2range [0:10000]

#LogDB Astro:SunAlt:::$val=($val>0?$val*50+7000:7000)
#LogDB wetter_wolfskehlen_II:solarRadiation:::$val=($val>0?$val*3+7000:7000)
#LogDB PV_Anlage_1:Solar_SolarRadiation:::$val=($val>0?$val*3+7000:7000)
#LogDB Astro:SunAlt:::$val=7000
#LogDB PV_Anlage_1:Solar_Calculation_fc1::
#LogDB PV_Anlage_1:Power_DC_Sum::
#LogDB PV_Anlage_1:Solar_Calculation::
#LogDB PV_Anlage_1:Solar_East::
#LogDB PV_Anlage_1:Solar_South::
#LogDB PV_Anlage_1:Solar_West::

plot "<IN>" using 1:2 axes x1y2 title 'Sonnenhöhe' ls l7 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SolarRadiation' ls l8 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SolarRadiationPrognose' ls l8 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title '70%' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Calculation_fc1' ls l0 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Power_DC_Sum' ls l1fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Calculation' ls l5 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'East' ls l2 lw 0.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'South' ls l3 lw 0.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'West' ls l4 lw 0.5 with lines
</pre>

== PV Eigenverbrauch-Steuerung ==
=== Beispiel Luft Wärme Pumpe ===
==== RAW Definition LWP_LuftWärmePumpe (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod LWP dummy
attr LWP DbLogExclude .*
attr LWP DbLogInclude state
attr LWP alias LWP_LuftWärmePumpe
attr LWP group PV Eigenverbrauch
attr LWP icon sani_earth_source_heat_pump
attr LWP readingList LWP_Button PowerLevelMinTime PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay SetCmdOff SetCmdOn TimeStart TimeEnd
attr LWP room Strom->Photovoltaik
attr LWP setList LWP_Button:uzsuToggle,on,off PowerLevelMinTime:slider,60,30,300 PowerLimitOn:slider,1000,250,4000 PowerLimitOff:slider,1000,250,4000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,900,300,28800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr LWP sortby 05
attr LWP stateFormat state
attr LWP verbose 0
attr LWP webCmd LWP_Button

setstate LWP off
setstate LWP 2020-08-05 17:38:03 LWP_Button off
setstate LWP 2020-03-02 11:56:45 PowerLevelMinTime 600
setstate LWP 2020-02-05 14:11:42 PowerLimitOff 2250
setstate LWP 2020-03-02 11:56:39 PowerLimitOn 3000
setstate LWP 2019-08-02 10:31:21 RunTimeMin 3600
setstate LWP 2020-02-05 14:13:01 RunTimePerDay 28800
setstate LWP 2019-12-29 10:47:55 SetCmdOff set shelly01 off 0
setstate LWP 2019-07-22 15:35:59 SetCmdOn set shelly01 on 0
setstate LWP 2019-11-09 12:13:04 TimeEnd 16:00
setstate LWP 2020-04-02 13:51:54 TimeStart 12:30
setstate LWP 2020-08-05 17:38:03 state off
</syntaxhighlight>
==== RAW Definition LWP_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod LWP_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
##\
([LWP_Counter:pulseTimePerDay] >= [LWP:RunTimePerDay] and\
[LWP_Counter:pulseTimeIncrement] >= [LWP:RunTimeMin] and\
[LWP:state] ne "off" and [LWP:LWP_Button] eq "off" )\
\
({Log 3, " LWP_PV cmd_1 PV : LWP off"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
)\
################################################################################################################\
## 2 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und die PV Produktion unter dem Mindestbedarf ist\
##\
DOELSEIF\
( ([PV_Anlage_1:Total_PV_Power_reserve]+[StromZaehler_Heizung:SMAEM1901401955_Bezug_Wirkleistung]) < [LWP:PowerLimitOff] and\
[LWP_Counter:pulseTimeIncrement] >= [LWP:RunTimeMin] and\
[LWP:state] ne "off" and\
[LWP:LWP_Button] ne "on" )\
\
({Log 3, " LWP_PV cmd_2 PV : LWP off"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
)\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4 wieder außerkraft,\
## wenn wärend der Wartezeit die PV Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [LWP:PowerLimitOff] and\
[LWP_PV:wait_timer] ne "no timer" and\
[LWP_PV:wait_timer] ne "" and\
[LWP:state] eq "off" )\
\
({Log 3, "LWP_PV cmd_3 PV : Stop wait timer LWP"})\
################################################################################################################\
## 4 Eigenverbrauch einschalten: wenn PV Produktion über dem Mindestbedarf ist und die Laufzeit pro Tag noch nicht erreicht ist\
##\
DOELSEIF\
([Astro:ObsSeason] ne "Sommer" and [Astro:ObsSeason] ne "Frühling" and\
[PV_Anlage_1:Total_PV_Power_reserve] >= [LWP:PowerLimitOn] and\
[[LWP:TimeStart]-[LWP:TimeEnd]] and\
[LWP:state] eq "off" and\
[LWP_Counter:pulseTimePerDay] < [LWP:RunTimePerDay] and\
[Heizung:hotWaterTemperature] < 60 )\
\
({Log 3, "LWP_PV cmd_4 : LWP on"}\
{fhem("".ReadingsVal("LWP","SetCmdOn",0))}\
{fhem("set LWP on")}\
{fhem("set Heizung hotWaterTemperatureTarget 60.0")}\
)\
################################################################################################################\
## 5 Signal für den PV-Modus der LWP einschalten.\
##\
DOELSEIF\
([LWP:LWP_Button] eq "on" )\
\
({Log 3, "LWP_PV cmd_5 PV : LWP on for manuel PV-Modus"}\
{fhem("".ReadingsVal("LWP","SetCmdOn",0))}\
{fhem("set LWP on")}\
{fhem("set Heizung hotWaterTemperatureTarget 60.0")}\
)\
################################################################################################################\
## 6 Signal für den PV-Modus der LWP abschalten.\
##\
DOELSEIF\
([LWP:LWP_Button] eq "off" and\
[$SELF:cmd_nr] eq "5" )\
\
({Log 3, "LWP_PV cmd_6 PV : LWP off after manuel PV-Modus"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
)\
################################################################################################################\
## 7 Stop wait Timer für das Abschalten, wenn die LWP beim Starten noch anläuft\
##\
DOELSEIF\
([StromZaehler_Heizung:SMAEM1901401955_Bezug_Wirkleistung] > 300 and\
[Heizung:opStateHeatPump1] eq "Wärmepumpe kommt" and\
[Heizung:opStateHeatPump3] eq "Pumpenvorlauf" )\
\
({Log 3, "LWP_PV cmd_7 : Stop wait timer LWP"})\
################################################################################################################\
## 8 LWP Ende\
##\
DOELSEIF\
([StromZaehler_Heizung:SMAEM1901401955_Bezug_Wirkleistung] < 300 and\
[LWP_Counter:pulseTimeIncrement] >= [LWP:RunTimeMin] and\
([Heizung:opStateHeatPump1] ne "Wärmepumpe läuft" or [Heizung:opStateHeatPump3] eq "Luftabtauen" ) and\
([$SELF:cmd_nr] eq "4" or [$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "10") )\
\
({Log 3, "LWP_PV cmd_8 : LWP run finished"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
{fhem("setreading LWP LWP_Button off")}\
)\
################################################################################################################\
## 9 LWP Zwangseinschalten: Sollte das Brauchwasser noch nicht aufgeheizt sein, wird um die Hysterese erhöht.\
## Dies kann passieren, wenn am Tag vorher der PV-Modus lief und dann das Wasser noch knapp über dem Mindestwert ist.\
##\
DOELSEIF\
([Astro:ObsSeason] ne "Sommer" and [Astro:ObsSeason] ne "Frühling" and\
[[LWP:TimeEnd]] and\
[Heizung:hotWaterTemperature] < 47 and\
([LWP_Counter:pulseTimePerDay] < [Pool:RunTimePerDay] or\
[LWP_Counter:countsPerDay] eq 0) )\
\
({Log 3, "LWP_PV cmd_9 : LWP on for water heating"}\
\
{fhem("set Heizung hotWaterTemperatureTarget ". (ReadingsVal("Heizung","hotWaterTemperature",46)+4))}\
\
{Log 3, "LWP_PV cmd_9 : LWP hotWaterTemperatureTarget ".ReadingsVal("Heizung","hotWaterTemperatureTarget",0)}\
)\
################################################################################################################\
## 10 Hohe Priorität im Winter fuer die LWP\
## Einschalten, wenn der Pool läuft, der Speicher geladen ist und noch Überschuss da ist.\
##\
DOELSEIF\
([Astro:ObsSeason] eq "Winter" and\
[PV_Anlage_1:Total_PV_Power_reserve] >= 2000 and\
[shelly02:power_0] > 800 and\
[PV_Anlage_1:Act_state_of_charge] > 60 and\
[Heizung:hotWaterTemperature] < 60 and \
[$SELF:cmd_nr] ne "10" )\
\
({Log 3, "LWP_PV cmd_10 : LWP Priorität"}\
{fhem("set LWP_PV cmd_4")}\
)\

attr LWP_PV DbLogExclude .*
attr LWP_PV DbLogInclude state,cmd.*,Device,LWP_Status,wait_timer
attr LWP_PV alias LWP_PV
attr LWP_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch aus|Stop wait timer|Eigenverbrauch ein|LWP ein für manuellen PV-Modus|LWP aus nach manuellem PV-Modus|Stop wait timer fuer aus|LWP aus nach PV-Modus|LWP Brauchwasser nachheizen|LWP Priorität
attr LWP_PV do always
attr LWP_PV group PV Eigenverbrauch-Steuerung
attr LWP_PV icon sani_earth_source_heat_pump
attr LWP_PV room Strom->Photovoltaik
attr LWP_PV sortby 01
attr LWP_PV stateFormat state : LWP_Status : Brauchwasser e_Heizung_hotWaterTemperature °C
attr LWP_PV userReadings LWP_Status { ReadingsVal("Heizung","state","") }
attr LWP_PV verbose 5
attr LWP_PV wait 0:10:0:[LWP:PowerLevelMinTime]:0:0:900:0:0
</syntaxhighlight>
- RAW Definition LWP_Signale (Shelly Modul: shelly1pm)
<syntaxhighlight lang="Perl">
defmod shelly01 Shelly 192.168.178.55
attr shelly01 DbLogExclude .*
attr shelly01 DbLogInclude relay.*,power.*,energy.*
attr shelly01 alias LWP_Signale
attr shelly01 event-on-change-reading relay.*,power.*,energy.*,state,network
attr shelly01 group PV Eigenverbrauch-Steuerung
attr shelly01 icon taster_ch_1
attr shelly01 mode relay
attr shelly01 model shelly1pm
attr shelly01 room Shelly,Heizung->System,Strom->Photovoltaik
attr shelly01 sortby 02
attr shelly01 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Gesamt 0: %08.2f KWh<br>\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
ReadingsVal($name,"WebLink","none") ,\
ReadingsVal($name,"energy_0",0)/1000,\
(ReadingsVal($name,"relay","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power",0),\
)}
attr shelly01 userReadings WebLink:network { my $ip=ReadingsVal($NAME,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") }
attr shelly01 webCmd |
</pre>
==== RAW Definition LWP_Counter (HourCounter Modul) ====
<pre>
defmod LWP_Counter HourCounter LWP:on.* LWP:off
attr LWP_Counter DbLogExclude .*
attr LWP_Counter alias LWP_Counter
attr LWP_Counter event-min-interval .*:600
attr LWP_Counter event-on-change-reading .*
attr LWP_Counter group PV Eigenverbrauch-Steuerung
attr LWP_Counter icon time_timer
attr LWP_Counter interval 5
attr LWP_Counter room Strom->Photovoltaik
attr LWP_Counter sortby 03
attr LWP_Counter verbose 0
</syntaxhighlight>
==== RAW Definition rg_LWP_Status (readingsGroup Modul) ====
<syntaxhighlight lang="Perl">
defmod rg_LWP_Status readingsGroup <Device>,<Information>,<Wert> LWP:<Status>,state LWP:<PowerLevelMinTime>,PowerLevelMinTime LWP:<PowerLimitOn>,PowerLimitOn LWP:<PowerLimitOff>,PowerLimitOff LWP:<TimeStart>,!TimeStart LWP:<TimeEnd>,!TimeEnd LWP:<RunTimeMin>,RunTimeMin LWP_Counter:<RunTimeMin>,pulseTimeIncrement LWP:<RunTimePerDay>,RunTimePerDay LWP_Counter:<RunTimePerDay>,pulseTimePerDay LWP_PV:<wait>,wait_timer LWP_PV:<TimeStart>,timer_01_c04 LWP_PV:<TimeEnd>,timer_02_c04
attr rg_LWP_Status DbLogExclude .*
attr rg_LWP_Status alias Status LuftWärmePumpe Eigenverbrauch
attr rg_LWP_Status commands {state => 'state:on,off',\
PowerLevelMinTime => 'PowerLevelMinTime:selectnumbers,60,60,600,0,lin',\
PowerLimitOn => 'PowerLimitOn:selectnumbers,1000,250,4000,0,lin',\
PowerLimitOff => 'PowerLimitOff:selectnumbers,1000,250,4000,0,lin',\
RunTimeMin => 'RunTimeMin:selectnumbers,300,300,14400,0,lin',\
RunTimePerDay => 'RunTimePerDay:selectnumbers,300,300,28800,0,lin',\
TimeStart => 'TimeStart:time',\
TimeEnd => 'TimeEnd:time'}
attr rg_LWP_Status group PV Status
attr rg_LWP_Status nameStyle style="color:grey"
attr rg_LWP_Status room Strom->Photovoltaik
attr rg_LWP_Status sortby 01
attr rg_LWP_Status style style="font-size:18px"
</syntaxhighlight>

=== Beispiel Pool===
==== RAW Definition Pool_Softube (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod Pool dummy
attr Pool DbLogExclude .*
attr Pool DbLogInclude state
attr Pool alias Pool_Softube
attr Pool event-on-change-reading .*
attr Pool group PV Eigenverbrauch
attr Pool icon scene_swimming
attr Pool readingList Pool_Button PowerLevelMinTime PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay RunTimePerDaySummer RunTimePerDayWinter SetCmdOff SetCmdOn TimeStart TimeEnd
attr Pool room Strom->Photovoltaik
attr Pool setList Pool_Button:uzsuToggle,on,off PowerLevelMinTime:slider,30,30,300 PowerLimitOn:slider,500,100,1500 PowerLimitOff:slider,0,100,1000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,900,300,64800 RunTimePerDaySummer:slider,900,300,7200 RunTimePerDayWinter:slider,3600,900,64800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr Pool sortby 06
attr Pool stateFormat state
attr Pool verbose 0
attr Pool webCmd Pool_Button

setstate Pool off
setstate Pool 2020-08-28 13:30:10 Pool_Button off
setstate Pool 2019-12-02 10:31:26 PowerLevelMinTime 600
setstate Pool 2019-11-13 10:58:18 PowerLimitOff 800
setstate Pool 2019-11-06 11:49:00 PowerLimitOn 1000
setstate Pool 2020-08-14 16:26:09 RunTimeMin 1800
setstate Pool 2020-08-28 06:15:00 RunTimePerDay 3600
setstate Pool 2020-08-16 13:17:45 RunTimePerDaySummer 3600
setstate Pool 2020-08-25 19:32:33 RunTimePerDayWinter 14400
setstate Pool 2019-08-01 14:18:08 SetCmdOff set shelly02 off 0
setstate Pool 2019-08-02 09:33:06 SetCmdOn set shelly02 on 0
setstate Pool 2019-10-31 21:53:28 TimeEnd 16:00
setstate Pool 2020-04-08 18:19:29 TimeStart 12:30
setstate Pool 2020-08-28 14:13:02 state off
</syntaxhighlight>
==== RAW Definition Pool_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod Pool_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
##\
([Pool_Counter:pulseTimePerDay] >= [Pool:RunTimePerDay] and\
[Pool_Counter:pulseTimeIncrement] >= [Pool:RunTimeMin] and\
[Pool:state] eq "on" and [Pool:Pool_Button] eq "off" )\
\
({Log 3, "Pool_PV cmd_1 : Pool off"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")} )\
################################################################################################################\
## 2 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und die PV-Produktion unter dem Mindestbedarf ist.\
## Bei Pool Nutzung und Pflegeprogramm wird nicht abgeschaltet.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Pool:PowerLimitOff] and\
[Pool_Counter:pulseTimeIncrement] >= [Pool:RunTimeMin] and\
[Pool:state] eq "on" and \
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" and [$SELF:cmd_nr] ne "10" )\
\
({Log 3, "Pool_PV cmd_2 : Pool off"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")}\
{fhem("setreading Pool Pool_Button off")} )\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer Peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4 wieder außer kraft,\
## wenn während der Wartezeit die PV-Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Pool:PowerLimitOff] and\
[$SELF:wait_timer] ne "no timer" and\
[$SELF:wait_timer] ne "" and\
[Pool:state] eq "off" )\
\
({Log 3, "Pool_PV cmd_3 : Stop wait timer Pool"})\
################################################################################################################\
## 4 Eigenverbrauch einschalten: wenn PV-Produktion über dem Mindestbedarf ist und PV-Strom ins Netz eingespeist wird\
## und die Laufzeit pro Tag noch nicht erreicht ist;; Bei über 7000 Watt Einspeisung sofort aktivieren\
##\
DOELSEIF\
(([PV_Anlage_1:Total_PV_Power_reserve] >= [Pool:PowerLimitOn] and\
[[Pool:TimeStart]-[Pool:TimeEnd]] and\
[Pool:state] eq "off" and\
[Pool_Counter:pulseTimePerDay] < [Pool:RunTimePerDay]\
) or\
[PV_Anlage_1:Total_active_power_(powermeter)] <= -7000\
)\
\
({Log 3, "Pool_PV cmd_4 : Pool on"}\
{fhem("set Pool_Counter pulseTimeIncrement 0")}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 5 Steckdose für die Benutzung des Pools einschalten.\
##\
DOELSEIF\
([Pool:Pool_Button] eq "on" )\
\
({Log 3, "Pool_PV cmd_5 : Pool on for usage"}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 6 Steckdose des Pools abschalten.\
##\
DOELSEIF\
([Pool:Pool_Button] eq "off" and\
[$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7")\
\
({Log 3, "Pool_PV cmd_6 : Pool off after usage"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")} )\
################################################################################################################\
## 7 Stop wait Timer für das Abschalten, wenn die Pumpe beim Starten noch anläuft\
##\
DOELSEIF\
([shelly02:power_0] > 10 and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7" or [$SELF:cmd_nr] eq "9") and\
[$SELF:wait_timer] ne "no timer" and\
[$SELF:wait_timer] ne "" and\
[Pool:state] eq "on" )\
\
({Log 3, "Pool_PV cmd_7 : Stop wait timer Pool"})\
################################################################################################################\
## 8 Pool Ende\
##\
DOELSEIF\
([shelly02:power_0] < 10 and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7" or [$SELF:cmd_nr] eq "9") )\
\
({Log 3, "Pool_PV cmd_8 : Pool run finished"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")}\
{fhem("setreading Pool Pool_Button off")} )\
################################################################################################################\
## 9 Pflege Zwangseinschaltung: Es muss mindestens einmal pro Tag eingeschaltet werden, auch wenn kein PV Strom vorhanden war.\
##\
DOELSEIF\
([[Pool:TimeEnd]] and\
([Pool_Counter:pulseTimePerDay] < [Pool:RunTimePerDay] or\
[Pool_Counter:countsPerDay] eq 0)\
)\
\
({Log 3, "Pool_PV cmd_9 : Pool on for maintanance"}\
{fhem("set Pool_Counter pulseTimeIncrement 0")}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 10 Pflege Zwangseinschaltung bei günstigem Strom nachts im Winter\
##\
DOELSEIF\
([Astro:ObsSeason] eq "Winter" and\
[Strom_Kosten:aWATTar_Trigger] eq "on" and\
[22:00-05:00]\
)\
\
({Log 3, "Pool_PV cmd_10 : Pool on for maintanance by aWATTar"}\
{fhem("set Pool_Counter pulseTimeIncrement 0")}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 11 Abschaltung bei teurem Strom\
##\
DOELSEIF\
([Astro:ObsSeason] eq "Winter" and\
[Strom_Kosten:aWATTar_Trigger] eq "off" and\
[$SELF:cmd_nr] eq "10"\
)\
\
({Log 3, "Pool_PV cmd_11 : Pool off after maintanance by aWATTar"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")} )\
################################################################################################################\
## 12 Pool durch kürzere Laufzeit abkühlen lassen\
##\
DOELSEIF\
([06:15] and [Heizung:averageAmbientTemperature])\
\
(\
{ if ( [Heizung:averageAmbientTemperature] >= 18 )\
{fhem("setreading Pool RunTimePerDay ".ReadingsVal("Pool","RunTimePerDaySummer",0) )}\
else \
{fhem("setreading Pool RunTimePerDay ".ReadingsVal("Pool","RunTimePerDayWinter",0) )}\
},\
{Log 3, "Pool_PV cmd_12 : Pool RunTimePerDay switched"}\
)\
\

attr Pool_PV DbLogExclude .*
attr Pool_PV DbLogInclude cmd.*,state,cmd.*,Device,Pool_Pumpe_Status,wait_timer
attr Pool_PV alias Pool_PV
attr Pool_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch aus|Stop wait timer|Eigenverbrauch freigegeben|Pool ein für Benutzung|Pool aus nach Benutzung|Stop wait timer für aus|Pool aus|Pflegemodus ohne PV|Strombörse ein|Strombörse aus|RunTimePerDay switched
attr Pool_PV disable 0
attr Pool_PV do always
attr Pool_PV event-on-change-reading .*
attr Pool_PV group PV Eigenverbrauch-Steuerung
attr Pool_PV icon scene_swimming
attr Pool_PV room Strom->Photovoltaik
attr Pool_PV sortby 11
attr Pool_PV stateFormat state : Pool_Pumpe_Status
attr Pool_PV userReadings Pool_Pumpe_Status { ReadingsVal("shelly02","power_0",0)>10 ? "Pool_Pumpe_laeuft" : "Pool_Pumpe_aus"}
attr Pool_PV verbose 0
attr Pool_PV wait 0:10:0:[Pool:PowerLevelMinTime]:0:0:0:300:0:300
</syntaxhighlight>
==== RAW Definition Pool_Signale (Shelly Modul: shelly1pm) ====
<syntaxhighlight lang="Perl">
defmod shelly02 Shelly 192.168.178.52
attr shelly02 DbLogExclude .*
attr shelly02 DbLogInclude relay.*,power.*,energy.*
attr shelly02 alias Pool_Signale
attr shelly02 comment relais_0 => Pool limit 1000 W\
relail_1 => Terrasse Lichterkette limit 100 W
attr shelly02 event-on-change-reading relay.*,power.*,energy.*,state,network
attr shelly02 group PV Eigenverbrauch-Steuerung
attr shelly02 icon taster_ch_1
attr shelly02 mode relay
attr shelly02 model shelly2.5
attr shelly02 room Shelly,Strom->Photovoltaik
attr shelly02 sortby 12
attr shelly02 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
Status: %s<br>\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Gesamt 0: %08.2f KWh<br>Gesamt 1: %08.2f KWh\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
Relais 1: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
(ReadingsVal($name,"state","none") eq "OK") ? "<span style='color:#00FF00'>OK</span>":"<span style='color:#FF0000'>Error</span>",\
ReadingsVal($name,"WebLink","none") ,\
ReadingsVal($name,"energy_0",0)/1000,\
ReadingsVal($name,"energy_1",0)/1000,\
(ReadingsVal($name,"relay_0","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power_0",0),\
(ReadingsVal($name,"relay_1","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power_1",0)\
)}
attr shelly02 userReadings WebLink:network { my $ip=ReadingsVal($name,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") }
attr shelly02 verbose 0
attr shelly02 webCmd |
</syntaxhighlight>
==== RAW Definition Pool_Counter (HourCounter Modul) ====
<syntaxhighlight lang="Perl">
defmod Pool_Counter HourCounter shelly02:power_0:\s[0-9]{2,}(\.[0-9]{1,2})*$ shelly02:power_0:\s[0-9]{1}(\.[0-9]{1,2})*$
attr Pool_Counter DbLogExclude .*
attr Pool_Counter alias Pool_Counter
attr Pool_Counter comment On und Off des Pools werden direkt über den Shelly Stromverbrauch getriggert.
attr Pool_Counter event-on-change-reading .*
attr Pool_Counter group PV Eigenverbrauch-Steuerung
attr Pool_Counter icon time_timer
attr Pool_Counter interval 5
attr Pool_Counter room Strom->Photovoltaik
attr Pool_Counter sortby 13
attr Pool_Counter verbose 0
</syntaxhighlight>
==== RAW Definition rg_Pool_Status (readingsGroup Modul) ====
<syntaxhighlight lang="Perl">
defmod rg_Pool_Status readingsGroup <Device>,<Information>,<Wert> Pool:<Status>,!state Pool:<PowerLevelMinTime>,!PowerLevelMinTime Pool:<PowerLimitOn>,!PowerLimitOn Pool:<PowerLimitOff>,!PowerLimitOff Pool:<TimeStart>,!TimeStart Pool:<TimeEnd>,!TimeEnd Pool:<RunTimeMin>,!RunTimeMin Pool_Counter:<RunTimeMin>,!pulseTimeIncrement Pool:<RunTimePerDay>,!RunTimePerDay Pool:<RunTimePerDaySummer>,!RunTimePerDaySummer Pool:<RunTimePerDayWinter>,!RunTimePerDayWinter Pool_Counter:<RunTimePerDay>,!pulseTimePerDay Pool_PV:<wait>,wait_timer Pool_PV:<TimeStart>,timer_01_c04 Pool_PV:<TimeEnd>,timer_02_c04
attr rg_Pool_Status DbLogExclude .*
attr rg_Pool_Status alias Status Softube Pool Eigenverbrauch
attr rg_Pool_Status commands {state => 'state:on,off',\
PowerLevelMinTime => 'PowerLevelMinTime:selectnumbers,60,30,600,0,lin',\
PowerLimitOn => 'PowerLimitOn:selectnumbers,500,250,1500,0,lin',\
PowerLimitOff => 'PowerLimitOff:selectnumbers,0,100,1000,0,lin',\
RunTimeMin => 'RunTimeMin:selectnumbers,300,300,14400,0,lin',\
RunTimePerDaySummer => 'RunTimePerDaySummer:selectnumbers,300,300,3600,0,lin',\
RunTimePerDayWinter => 'RunTimePerDayWinter:selectnumbers,3600,900,64800,0,lin',\
TimeStart => 'TimeStart:time',\
TimeEnd => 'TimeEnd:time'}
attr rg_Pool_Status group PV Status
attr rg_Pool_Status nameStyle style="color:grey"
attr rg_Pool_Status room Strom->Photovoltaik
attr rg_Pool_Status sortby 02
attr rg_Pool_Status style style="font-size:18px"
</syntaxhighlight>

=== Beispiel Waschmaschine (mit Walzenschalter ;-) ) ===
==== RAW Definition Waschmaschine (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod Waschmaschine dummy
attr Waschmaschine DbLogExclude .*
attr Waschmaschine DbLogInclude state
attr Waschmaschine alias Waschmaschine
attr Waschmaschine group PV Eigenverbrauch
attr Waschmaschine icon scene_washing_machine
attr Waschmaschine readingList Waschmaschine_Button PowerLevelMinTime PowerPhaseUse PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay SetCmdOff SetCmdOn TimeStart TimeEnd
attr Waschmaschine room Strom->Photovoltaik
attr Waschmaschine setList Waschmaschine_Button:uzsuToggle,on,off PowerLevelMinTime:slider,30,30,300 PowerLimitOn:slider,250,250,2000 PowerLimitOff:slider,0,250,1000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,7200,300,28800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr Waschmaschine sortby 07
attr Waschmaschine stateFormat state
attr Waschmaschine verbose 0
attr Waschmaschine webCmd Waschmaschine_Button

setstate Waschmaschine off
setstate Waschmaschine 2019-12-02 10:29:49 PowerLevelMinTime 300
setstate Waschmaschine 2019-11-06 10:56:22 PowerLimitOff 250
setstate Waschmaschine 2020-04-20 13:06:04 PowerLimitOn 2000
setstate Waschmaschine 2019-12-02 15:01:18 RunTimeMin 5400
setstate Waschmaschine 2020-04-02 13:59:34 RunTimePerDay 19200
setstate Waschmaschine 2020-01-01 16:29:10 SetCmdOff set shelly03 off 0
setstate Waschmaschine 2020-01-01 16:29:24 SetCmdOn set shelly03 on 0
setstate Waschmaschine 2019-08-01 14:25:25 TimeEnd 18:00
setstate Waschmaschine 2019-10-28 09:13:30 TimeStart 09:00
setstate Waschmaschine 2020-08-27 16:17:23 Waschmaschine_Button off
setstate Waschmaschine 2020-08-28 16:29:42 state off
</syntaxhighlight>
==== RAW Definition Waschmaschine_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod Waschmaschine_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch sperren: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
## jedoch nicht wenn manueller Betrieb aktiv ist.\
##\
([Waschmaschine_Counter:pulseTimePerDay] >= [Waschmaschine:RunTimePerDay] and\
[Waschmaschine_Counter:pulseTimeIncrement] >= [Waschmaschine:RunTimeMin] and\
[Waschmaschine:state] eq "on" and [Waschmaschine:Waschmaschine_Button] eq "off" )\
\
({Log 3, "Waschmaschine cmd_1 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
{fhem("set Waschmaschine off")}\
)\
################################################################################################################\
## 2 Eigenverbrauch sperren: wenn Mindestlaufzeit erreicht wurde und die PV-Produktion unter dem Mindestbedarf ist\
## ausser bei manuellem Einschalten und wenn das Waschprogramm bereits läuft\
##\
## ([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOff] and\
## [Waschmaschine_Counter:pulseTimeIncrement] >= [Waschmaschine:RunTimeMin] and\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOn] and\
[Waschmaschine:state] eq "on" and\
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" )\
\
({Log 3, "Waschmaschine cmd_2 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
{fhem("set Waschmaschine off")}\
)\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer Peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4\
## wieder außer kraft, wenn während der Wartezeit die PV-Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOff] and\
[Waschmaschine_PV:wait_timer] ne "no timer" and\
[Waschmaschine_PV:wait_timer] ne "" and\
[Waschmaschine:state] eq "off" )\
\
({Log 3, "Waschmaschine cmd_3 : Waschmaschine stop wait timer"})\
################################################################################################################\
## 4 Eigenverbrauch freigeben: wenn PV-Produktion über dem Mindestbedarf ist und PV-Strom ins Netz eingespeist\
## wird und die Laufzeit pro Tag noch nicht erreicht ist\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] > [Waschmaschine:PowerLimitOn] and\
[Waschmaschine:state] eq "off" and\
[[Waschmaschine:TimeStart]-[Waschmaschine:TimeEnd]] and\
[Waschmaschine_Counter:pulseTimePerDay] < [Waschmaschine:RunTimePerDay] )\
\
({Log 3, "Waschmaschine cmd_4 : Waschmaschine freigabe"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOn",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist eingeschaltet")}\
{fhem("set Waschmaschine on")}\
)\
################################################################################################################\
## 5 Steckdose manuell für die Benutzung der Waschmaschine einschalten.\
##\
DOELSEIF\
([Waschmaschine:Waschmaschine_Button] eq "on" )\
\
({Log 3, "Waschmaschine cmd_5 : Waschmaschine manuell ein"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOn",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist eingeschaltet")}\
{fhem("set Waschmaschine on")}\
)\
################################################################################################################\
## 6 Steckdose der Waschmaschine manuell abschalten.\
##\
DOELSEIF\
([Waschmaschine:Waschmaschine_Button] eq "off" and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7") )\
\
({Log 3, "Waschmaschine cmd_6 : Waschmaschine manuell aus"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
{fhem("set Waschmaschine off")}\
)\
################################################################################################################\
## 7 Statuswechsel wenn das Waschprogramm gestartet ist\
##\
DOELSEIF\
([shelly03:power] > 0 and\
[shelly03:power_Waschmaschine_avg] < 70 and\
[$SELF:cmd_nr] ne "7")\
\
({Log 3, "Waschmaschine cmd_7 : Waschmaschine Programm gestarted"}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Waschprogramm gestartet")}\
)\
################################################################################################################\
## 8 Abschalten der Steckdose beim Waschprogramm Ende\
##\
DOELSEIF\
([shelly03:power] == 0 and\
[shelly03:power_Waschmaschine_avg] > 0 and\
[$SELF:cmd_nr] eq "7" )\
\
({Log 3, "Waschmaschine cmd_8 : Waschmaschine aus"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("set Waschmaschine off")}\
{fhem("setreading Waschmaschine Waschmaschine_Button off")}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Waschprogramm beendet")}\
)\
################################################################################################################\
## 9 Abschalten der Steckdose wenn die Waschmaschine nicht gebraucht wurde\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOn] and\
[[Waschmaschine:TimeEnd]-[Waschmaschine:TimeStart]] and\
[Waschmaschine:state] eq "on" and\
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" )\
\
({Log 3, "Waschmaschine cmd_9 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("set Waschmaschine off")}\
{fhem("setreading Waschmaschine Waschmaschine_Button off")}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
)
attr Waschmaschine_PV DbLogExclude .*
attr Waschmaschine_PV DbLogInclude state,STATE,cmd.*,Device,Waschmaschine_Status,wait_timer
attr Waschmaschine_PV alias Waschmaschine_PV
attr Waschmaschine_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch gesperrt|Stop wait timer|Eigenverbrauch freigegeben|Waschmaschine manuell ein|Waschmaschine manuell aus|Waschmaschine laeuft|Waschmaschine aus|Eigenverbrauch gesperrt
attr Waschmaschine_PV do always
attr Waschmaschine_PV group PV Eigenverbrauch-Steuerung
attr Waschmaschine_PV icon scene_washing_machine
attr Waschmaschine_PV room Strom->Photovoltaik
attr Waschmaschine_PV sortby 21
attr Waschmaschine_PV stateFormat state : Waschmaschine_Status
attr Waschmaschine_PV verbose 0
attr Waschmaschine_PV wait 0:0:0:[Waschmaschine:PowerLevelMinTime]:0:30:0:60:30
</syntaxhighlight>
==== RAW Definition Waschmaschine_Signale (Shelly Modul: shelly1pm) ====
<syntaxhighlight lang="Perl">
defmod shelly03 Shelly 192.168.178.54
attr shelly03 DbLogExclude .*
attr shelly03 DbLogInclude relay.*,power.*,energy.*
attr shelly03 alias Waschmaschine_Signale
attr shelly03 event-on-change-reading relay.*,power.*,energy.*,network
attr shelly03 group PV Eigenverbrauch-Steuerung
attr shelly03 icon taster_ch_1
attr shelly03 interval 60
attr shelly03 mode relay
attr shelly03 model shelly1pm
attr shelly03 room Shelly,Strom->Photovoltaik
attr shelly03 sortby 22
attr shelly03 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Gesamt 0: %08.2f KWh<br>\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
ReadingsVal($name,"WebLink","none") ,\
ReadingsVal($name,"energy",0)/1000,\
(ReadingsVal($name,"relay","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power",0)\
)}
attr shelly03 userReadings WebLink:network { my $ip=ReadingsVal($NAME,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") },\
power_Waschmaschine_avg:power.* { movingAverage($NAME,"power",300) }
attr shelly03 webCmd |
</syntaxhighlight>
==== RAW Definition Waschmaschine_Counter (HourCounter Modul) ====
<syntaxhighlight lang="Perl">
defmod Waschmaschine_Counter HourCounter Waschmaschine_PV:.*laeuft Waschmaschine_PV:Waschmaschine_Status:.*[beendet|ausgeschaltet]
attr Waschmaschine_Counter DbLogExclude .*
attr Waschmaschine_Counter alias Waschmaschine_Counter
attr Waschmaschine_Counter event-on-change-reading .*
attr Waschmaschine_Counter group PV Eigenverbrauch-Steuerung
attr Waschmaschine_Counter icon time_timer
attr Waschmaschine_Counter interval 5
attr Waschmaschine_Counter room Strom->Photovoltaik
attr Waschmaschine_Counter sortby 23
attr Waschmaschine_Counter verbose 0
</syntaxhighlight>
==== RAW Definition rg_Waschmaschine_Status (readingsGroup Modul) ====
<syntaxhighlight lang="Perl">
defmod rg_Waschmaschine_Status readingsGroup <Device>,<Information>,<Wert> Waschmaschine:<Status>,!state Waschmaschine:<PowerLevelMinTime>,!PowerLevelMinTime Waschmaschine:<PowerLimitOn>,!PowerLimitOn Waschmaschine:<PowerLimitOff>,!PowerLimitOff Waschmaschine:<TimeStart>,!TimeStart Waschmaschine:<TimeEnd>,!TimeEnd Waschmaschine:<RunTimeMin>,!RunTimeMin Waschmaschine_Counter:<RunTimeMin>,!pulseTimeIncrement Waschmaschine:<RunTimePerDay>,!RunTimePerDay Waschmaschine_Counter:<RunTimePerDay>,!pulseTimePerDay Waschmaschine_PV:<wait>,wait_timer Waschmaschine_PV:<TimeStart>,timer_01_c04 Waschmaschine_PV:<TimeEnd>,timer_02_c04
attr rg_Waschmaschine_Status DbLogExclude .*
attr rg_Waschmaschine_Status alias Status Waschmaschine Eigenverbrauch
attr rg_Waschmaschine_Status commands {state => 'state:on,off',\
PowerLevelMinTime => 'PowerLevelMinTime:selectnumbers,30,30,300,0,lin',\
PowerLimitOn => 'PowerLimitOn:selectnumbers,250,250,2000,0,lin',\
PowerLimitOff => 'PowerLimitOff:selectnumbers,0,50,800,0,lin',\
RunTimeMin => 'RunTimeMin:selectnumbers,300,300,7200,0,lin',\
RunTimePerDay => 'RunTimePerDay:selectnumbers,7200,300,28800,0,lin',\
TimeStart => 'TimeStart:time',\
TimeEnd => 'TimeEnd:time'}
attr rg_Waschmaschine_Status group PV Status
attr rg_Waschmaschine_Status nameStyle style="color:grey"
attr rg_Waschmaschine_Status room Strom->Photovoltaik
attr rg_Waschmaschine_Status sortby 03
attr rg_Waschmaschine_Status style style="font-size:18px"
</syntaxhighlight>

== Problemlösung ==

== Projekte der FHEM-Community ==

* {{Link2Forum|Topic=102297|Message=958564}} - Photovoltaik mit Eigenverbrauch Steuerung (Kostal plenticore; EM410)
* {{Link2Forum|Topic=109875|Message=1038741}} - Kostal Plenticore Bilanz
* {{Link2Forum|Topic=108191|Message=1038741}} - Kostal Plenticore, EM410 (KSEM), BYD, Solarprognose, Forecast

* {{Link2Forum|Topic=53584}} - Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
* {{Link2Forum|Topic=45176}} - Neue Version von HTTPMOD mit neuen Features zum Testen

== Links ==

* [https://www.photovoltaikforum.com/thread/142261-programmatischer-lesender-und-schreibender-zugriff-auf-kostal-plenticore-z-b-min/?pageNo=1/ Zugriff mit Python auf den Plenticore]
* [https://www.photovoltaikforum.com/thread/144350-kostenlose-wetterprognose-pv-prognose-ertragsprogonse-mit-st%C3%BCndlicher-aufl%C3%B6sung/?pageNo=1/ Ertragsprognose mit DWD]
* [https://www.photovoltaikforum.com/thread/146383-eigenverbrauchssteuerung-verh%C3%A4lt-sich-mit-speicher-anders-als-ohne/?pageNo=1/ Eigenverbrauchssteuerung beim Plenticore]
* [https://github.com/kilianknoll/ Github Kilian DWD Forecast]
* [https://github.com/FL550/ Github FL550 DWD Forecast]

[[Kategorie:IP Components]]
[[Kategorie:Other Components]]
[[Kategorie:Energieerzeugungsmessung]]

Benutzer:Plin53177

2020-09-05T18:25:08Z

Plin53177: /* Log */

==FHEM Landschaft (2020)==
[[Datei:Plin53177 landscape.PNG|rahmenlos|1261x1261px]]

==FHEM-Instanzen==
===Main===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Hausmitte
|
|-
|Hardware
|Raspberry Pi 3B
|
|-
|Peripherie
|CUL (Homematic)
SIGNALduino (433 MHz, OOK)
|für Homematic-Devices

für diverse Funkthermometer
|-
|Schwerpunkt
|Zentrale Steuerung
Funkbasierte Steuerung
|
|-
|Module
|Alarm, CUL, CUL_HM, CUL_TCM97001, CUL_TX, DOIF, Dashboard, ESPEasy, FHEM2FHEM, FHEMWEB, FLAMINGO, FLOORPLAN, FileLog, HMLAN, HMinfo, HTTPSRV, HUEBridge, HUEDevice, HourCounter, IT, LEDStripe, LightScene, MSGMail, OREGON, PRESENCE, RESIDENTS, RFHEM, ROLLO, ROOMMATE, SD_WS, SD_WS07, SIGNALduino, SVG, SYSMON, THRESHOLD, TelegramBot, Text2Speech, Weather, WifiLight, at, autocreate, autoload_undefined_devices, cmdalias, define, devStateIcon, dummy, eventTypes, laststate, notify, readingsGroup, siri, structure, telnet, weblink
|
|}

===Server===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Keller
|
|-
|Hardware
|x86-Server mit OpenSUSE Leap 15.1
|
|-
|Peripherie
|CUL (Homematic) mit hmland
|
|-
|Schwerpunkt
|IP-basierte Module/Dienste
CUL-Verlängerung für Aktoren im Keller
|
|-
|Module
|CALVIEW, CUL_HM, Calendar, DOIF, Dashboard, ESPEasy, FB_CALLLIST, FB_CALLMONITOR, FHEM2FHEM, FHEMWEB, FRITZBOX, FileLog, HTTPMOD, HTTPSRV, IPCAM, MPD, RFHEM, SIP, SIRD, STV, TelegramBot, Text2Speech, WOL, allowed, at, autocreate, autoload_undefined_devices, dummy, eventTypes, notify, onCreateEvent, plex, readingsGroup, telnet, vitoconnect, weblink
|
|-
|Sonstiges
|collectd für Fritz!Box 7490
|
|}
===Wohnzimmer===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Erdgeschoss
|
|-
|Hardware
|Raspberry Pi 2
|
|-
|Peripherie
|SIGNALduino (868 MHz, GFSK)
Lautsprecher
|für die Rolläden
|-
|Schwerpunkt
|Rolladensteuerung
Sound-Ausgabe
|
|-
|Module
|DOIF, FHEMWEB, FileLog, MsgQueue, PRESENCE, RFHEM, ROLLO, SD_Keeloq, SIGNALduino, Text2Speech, autocreate, autoload_undefined_devices, dummy, eventTypes, msgConfig, notify, structure, telnet, weblink
|
|}

===Log===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|docker container auf Server
|
|-
|Hardware
|(docker container)
|
|-
|Peripherie
|keine
|
|-
|Schwerpunkt
|Sammelt per FHEM2FHEM alle Metriken für die Visualisierung in Grafana
|
|-
|Module
|DOIF, DockerImageInfo, FHEM, FHEM2FHEM, FHEMWEB, InfluxDBLog, RFHEM, dummy, eventTypes, notify, telnet
|
|}
Wenn es bei der Speicherung von Daten in der InfluxDB zu IP-technischen Verzögerungen kommt, kann die gesamte FHEM-Instanz blockiert werden. Durch die Auslagerung in eine separate Instanz wird dies vermieden.

==Visualisierung==
===Prometheus===
für die Sammlung von collectd-Zeitreihen, node_exporter etc.
===InfluxDB===
für die Sammlung von FHEM-Zeitreihen
===Grafana===
für die übergreifende Visualisierung von Zeitreihen

Benutzer:Plin53177

2020-09-05T18:23:57Z

Plin53177: /* Visualisierung */

==FHEM Landschaft (2020)==
[[Datei:Plin53177 landscape.PNG|rahmenlos|1261x1261px]]

==FHEM-Instanzen==
===Main===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Hausmitte
|
|-
|Hardware
|Raspberry Pi 3B
|
|-
|Peripherie
|CUL (Homematic)
SIGNALduino (433 MHz, OOK)
|für Homematic-Devices

für diverse Funkthermometer
|-
|Schwerpunkt
|Zentrale Steuerung
Funkbasierte Steuerung
|
|-
|Module
|Alarm, CUL, CUL_HM, CUL_TCM97001, CUL_TX, DOIF, Dashboard, ESPEasy, FHEM2FHEM, FHEMWEB, FLAMINGO, FLOORPLAN, FileLog, HMLAN, HMinfo, HTTPSRV, HUEBridge, HUEDevice, HourCounter, IT, LEDStripe, LightScene, MSGMail, OREGON, PRESENCE, RESIDENTS, RFHEM, ROLLO, ROOMMATE, SD_WS, SD_WS07, SIGNALduino, SVG, SYSMON, THRESHOLD, TelegramBot, Text2Speech, Weather, WifiLight, at, autocreate, autoload_undefined_devices, cmdalias, define, devStateIcon, dummy, eventTypes, laststate, notify, readingsGroup, siri, structure, telnet, weblink
|
|}

===Server===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Keller
|
|-
|Hardware
|x86-Server mit OpenSUSE Leap 15.1
|
|-
|Peripherie
|CUL (Homematic) mit hmland
|
|-
|Schwerpunkt
|IP-basierte Module/Dienste
CUL-Verlängerung für Aktoren im Keller
|
|-
|Module
|CALVIEW, CUL_HM, Calendar, DOIF, Dashboard, ESPEasy, FB_CALLLIST, FB_CALLMONITOR, FHEM2FHEM, FHEMWEB, FRITZBOX, FileLog, HTTPMOD, HTTPSRV, IPCAM, MPD, RFHEM, SIP, SIRD, STV, TelegramBot, Text2Speech, WOL, allowed, at, autocreate, autoload_undefined_devices, dummy, eventTypes, notify, onCreateEvent, plex, readingsGroup, telnet, vitoconnect, weblink
|
|-
|Sonstiges
|collectd für Fritz!Box 7490
|
|}
===Wohnzimmer===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Erdgeschoss
|
|-
|Hardware
|Raspberry Pi 2
|
|-
|Peripherie
|SIGNALduino (868 MHz, GFSK)
Lautsprecher
|für die Rolläden
|-
|Schwerpunkt
|Rolladensteuerung
Sound-Ausgabe
|
|-
|Module
|DOIF, FHEMWEB, FileLog, MsgQueue, PRESENCE, RFHEM, ROLLO, SD_Keeloq, SIGNALduino, Text2Speech, autocreate, autoload_undefined_devices, dummy, eventTypes, msgConfig, notify, structure, telnet, weblink
|
|}

===Log===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|docker container auf Server
|
|-
|Hardware
|(docker container)
|
|-
|Peripherie
|keine
|
|-
|Schwerpunkt
|Sammelt per FHEM2FHEM alle Metriken für
die Visualisierung in Grafana
|
|-
|Module
|DOIF, DockerImageInfo, FHEM, FHEM2FHEM, FHEMWEB, InfluxDBLog, RFHEM, dummy, eventTypes, notify, telnet
|
|}
Wenn es bei der Speicherung von Daten in der InfluxDB zu IP-technischen Verzögerungen kommt, kann die gesamte FHEM-Instanz blockiert werden. Durch die Auslagerung in eine separate Instanz wird dies vermieden.

==Visualisierung==
===Prometheus===
für die Sammlung von collectd-Zeitreihen, node_exporter etc.
===InfluxDB===
für die Sammlung von FHEM-Zeitreihen
===Grafana===
für die übergreifende Visualisierung von Zeitreihen

Benutzer:Plin53177

2020-09-05T18:22:39Z

Plin53177: /* Wohnzimmer */

==FHEM Landschaft (2020)==
[[Datei:Plin53177 landscape.PNG|rahmenlos|1261x1261px]]

==FHEM-Instanzen==
===Main===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Hausmitte
|
|-
|Hardware
|Raspberry Pi 3B
|
|-
|Peripherie
|CUL (Homematic)
SIGNALduino (433 MHz, OOK)
|für Homematic-Devices

für diverse Funkthermometer
|-
|Schwerpunkt
|Zentrale Steuerung
Funkbasierte Steuerung
|
|-
|Module
|Alarm, CUL, CUL_HM, CUL_TCM97001, CUL_TX, DOIF, Dashboard, ESPEasy, FHEM2FHEM, FHEMWEB, FLAMINGO, FLOORPLAN, FileLog, HMLAN, HMinfo, HTTPSRV, HUEBridge, HUEDevice, HourCounter, IT, LEDStripe, LightScene, MSGMail, OREGON, PRESENCE, RESIDENTS, RFHEM, ROLLO, ROOMMATE, SD_WS, SD_WS07, SIGNALduino, SVG, SYSMON, THRESHOLD, TelegramBot, Text2Speech, Weather, WifiLight, at, autocreate, autoload_undefined_devices, cmdalias, define, devStateIcon, dummy, eventTypes, laststate, notify, readingsGroup, siri, structure, telnet, weblink
|
|}

===Server===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Keller
|
|-
|Hardware
|x86-Server mit OpenSUSE Leap 15.1
|
|-
|Peripherie
|CUL (Homematic) mit hmland
|
|-
|Schwerpunkt
|IP-basierte Module/Dienste
CUL-Verlängerung für Aktoren im Keller
|
|-
|Module
|CALVIEW, CUL_HM, Calendar, DOIF, Dashboard, ESPEasy, FB_CALLLIST, FB_CALLMONITOR, FHEM2FHEM, FHEMWEB, FRITZBOX, FileLog, HTTPMOD, HTTPSRV, IPCAM, MPD, RFHEM, SIP, SIRD, STV, TelegramBot, Text2Speech, WOL, allowed, at, autocreate, autoload_undefined_devices, dummy, eventTypes, notify, onCreateEvent, plex, readingsGroup, telnet, vitoconnect, weblink
|
|-
|Sonstiges
|collectd für Fritz!Box 7490
|
|}
===Wohnzimmer===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Erdgeschoss
|
|-
|Hardware
|Raspberry Pi 2
|
|-
|Peripherie
|SIGNALduino (868 MHz, GFSK)
Lautsprecher
|für die Rolläden
|-
|Schwerpunkt
|Rolladensteuerung
Sound-Ausgabe
|
|-
|Module
|DOIF, FHEMWEB, FileLog, MsgQueue, PRESENCE, RFHEM, ROLLO, SD_Keeloq, SIGNALduino, Text2Speech, autocreate, autoload_undefined_devices, dummy, eventTypes, msgConfig, notify, structure, telnet, weblink
|
|}

===Log===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|docker container auf Server
|
|-
|Hardware
|(docker container)
|
|-
|Peripherie
|keine
|
|-
|Schwerpunkt
|Sammelt per FHEM2FHEM alle Metriken für
die Visualisierung in Grafana
|
|-
|Module
|DOIF, DockerImageInfo, FHEM, FHEM2FHEM, FHEMWEB, InfluxDBLog, RFHEM, dummy, eventTypes, notify, telnet
|
|}
Wenn es bei der Speicherung von Daten in der InfluxDB zu IP-technischen Verzögerungen kommt, kann die gesamte FHEM-Instanz blockiert werden. Durch die Auslagerung in eine separate Instanz wird dies vermieden.

===Visualisierung===
====Prometheus====
für die Sammlung von collectd-Zeitreihen, node_exporter etc.
====InfluxDB====
für die Sammlung von FHEM-Zeitreihen
====Grafana====
für die übergreifende Visualisierung von Zeitreihen

Benutzer:Plin53177

2020-09-05T18:21:36Z

Plin53177: /* Wohnzimmer */

==FHEM Landschaft (2020)==
[[Datei:Plin53177 landscape.PNG|rahmenlos|1261x1261px]]

==FHEM-Instanzen==
===Main===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Hausmitte
|
|-
|Hardware
|Raspberry Pi 3B
|
|-
|Peripherie
|CUL (Homematic)
SIGNALduino (433 MHz, OOK)
|für Homematic-Devices

für diverse Funkthermometer
|-
|Schwerpunkt
|Zentrale Steuerung
Funkbasierte Steuerung
|
|-
|Module
|Alarm, CUL, CUL_HM, CUL_TCM97001, CUL_TX, DOIF, Dashboard, ESPEasy, FHEM2FHEM, FHEMWEB, FLAMINGO, FLOORPLAN, FileLog, HMLAN, HMinfo, HTTPSRV, HUEBridge, HUEDevice, HourCounter, IT, LEDStripe, LightScene, MSGMail, OREGON, PRESENCE, RESIDENTS, RFHEM, ROLLO, ROOMMATE, SD_WS, SD_WS07, SIGNALduino, SVG, SYSMON, THRESHOLD, TelegramBot, Text2Speech, Weather, WifiLight, at, autocreate, autoload_undefined_devices, cmdalias, define, devStateIcon, dummy, eventTypes, laststate, notify, readingsGroup, siri, structure, telnet, weblink
|
|}

===Server===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Keller
|
|-
|Hardware
|x86-Server mit OpenSUSE Leap 15.1
|
|-
|Peripherie
|CUL (Homematic) mit hmland
|
|-
|Schwerpunkt
|IP-basierte Module/Dienste
CUL-Verlängerung für Aktoren im Keller
|
|-
|Module
|CALVIEW, CUL_HM, Calendar, DOIF, Dashboard, ESPEasy, FB_CALLLIST, FB_CALLMONITOR, FHEM2FHEM, FHEMWEB, FRITZBOX, FileLog, HTTPMOD, HTTPSRV, IPCAM, MPD, RFHEM, SIP, SIRD, STV, TelegramBot, Text2Speech, WOL, allowed, at, autocreate, autoload_undefined_devices, dummy, eventTypes, notify, onCreateEvent, plex, readingsGroup, telnet, vitoconnect, weblink
|
|-
|Sonstiges
|collectd für Fritz!Box 7490
|
|}
===Wohnzimmer===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|rdgeschossE
|
|-
|Hardware
|Raspberry Pi 2
|
|-
|Peripherie
|SIGNALduino (868 MHz, GFSK)
Lautsprecher
|für die Rolläden
|-
|Schwerpunkt
|Rolladensteuerung
Sound-Ausgabe
|
|-
|Module
|DOIF, FHEMWEB, FileLog, MsgQueue, PRESENCE, RFHEM, ROLLO, SD_Keeloq, SIGNALduino, Text2Speech, autocreate, autoload_undefined_devices, dummy, eventTypes, msgConfig, notify, structure, telnet, weblink
|
|}

===Log===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|docker container auf Server
|
|-
|Hardware
|(docker container)
|
|-
|Peripherie
|keine
|
|-
|Schwerpunkt
|Sammelt per FHEM2FHEM alle Metriken für
die Visualisierung in Grafana
|
|-
|Module
|DOIF, DockerImageInfo, FHEM, FHEM2FHEM, FHEMWEB, InfluxDBLog, RFHEM, dummy, eventTypes, notify, telnet
|
|}
Wenn es bei der Speicherung von Daten in der InfluxDB zu IP-technischen Verzögerungen kommt, kann die gesamte FHEM-Instanz blockiert werden. Durch die Auslagerung in eine separate Instanz wird dies vermieden.

===Visualisierung===
====Prometheus====
für die Sammlung von collectd-Zeitreihen, node_exporter etc.
====InfluxDB====
für die Sammlung von FHEM-Zeitreihen
====Grafana====
für die übergreifende Visualisierung von Zeitreihen

Benutzer:Plin53177

2020-09-05T13:09:27Z

Plin53177: /* Log */

==FHEM Landschaft (2020)==
[[Datei:Plin53177 landscape.PNG|rahmenlos|1261x1261px]]

==FHEM-Instanzen==
===Main===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Hausmitte
|
|-
|Hardware
|Raspberry Pi 3B
|
|-
|Peripherie
|CUL (Homematic)
SIGNALduino (433 MHz, OOK)
|für Homematic-Devices

für diverse Funkthermometer
|-
|Schwerpunkt
|Zentrale Steuerung
Funkbasierte Steuerung
|
|-
|Module
|Alarm, CUL, CUL_HM, CUL_TCM97001, CUL_TX, DOIF, Dashboard, ESPEasy, FHEM2FHEM, FHEMWEB, FLAMINGO, FLOORPLAN, FileLog, HMLAN, HMinfo, HTTPSRV, HUEBridge, HUEDevice, HourCounter, IT, LEDStripe, LightScene, MSGMail, OREGON, PRESENCE, RESIDENTS, RFHEM, ROLLO, ROOMMATE, SD_WS, SD_WS07, SIGNALduino, SVG, SYSMON, THRESHOLD, TelegramBot, Text2Speech, Weather, WifiLight, at, autocreate, autoload_undefined_devices, cmdalias, define, devStateIcon, dummy, eventTypes, laststate, notify, readingsGroup, siri, structure, telnet, weblink
|
|}

===Server===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Keller
|
|-
|Hardware
|x86-Server mit OpenSUSE Leap 15.1
|
|-
|Peripherie
|CUL (Homematic) mit hmland
|
|-
|Schwerpunkt
|IP-basierte Module/Dienste
CUL-Verlängerung für Aktoren im Keller
|
|-
|Module
|CALVIEW, CUL_HM, Calendar, DOIF, Dashboard, ESPEasy, FB_CALLLIST, FB_CALLMONITOR, FHEM2FHEM, FHEMWEB, FRITZBOX, FileLog, HTTPMOD, HTTPSRV, IPCAM, MPD, RFHEM, SIP, SIRD, STV, TelegramBot, Text2Speech, WOL, allowed, at, autocreate, autoload_undefined_devices, dummy, eventTypes, notify, onCreateEvent, plex, readingsGroup, telnet, vitoconnect, weblink
|
|-
|Sonstiges
|collectd für Fritz!Box 7490
|
|}
===Wohnzimmer===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|rdgeschossE
|
|-
|Hardware
|Raspberry Pi 2
|
|-
|Peripherie
|SIGNALduino (868 MHz, GFSK)
Lautsprecher
|für die Rolläden
|-
|Schwerpunkt
|Rolladensteuerung
Sound-Ausgabe
|
|-
|Module
|DOIF, FHEMWEB, FileLog, MsqQueue, PRESENCE, RFHEM, ROLLO, SD_Keeloq, SIGNALduino, Text2Speech, autocreate, autoload_undefined_devices, dummy, eventTypes, msgConfig, notify, structure, telnet, weblink
|
|}
===Log===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|docker container auf Server
|
|-
|Hardware
|(docker container)
|
|-
|Peripherie
|keine
|
|-
|Schwerpunkt
|Sammelt per FHEM2FHEM alle Metriken für
die Visualisierung in Grafana
|
|-
|Module
|DOIF, DockerImageInfo, FHEM, FHEM2FHEM, FHEMWEB, InfluxDBLog, RFHEM, dummy, eventTypes, notify, telnet
|
|}
Wenn es bei der Speicherung von Daten in der InfluxDB zu IP-technischen Verzögerungen kommt, kann die gesamte FHEM-Instanz blockiert werden. Durch die Auslagerung in eine separate Instanz wird dies vermieden.

===Visualisierung===
====Prometheus====
für die Sammlung von collectd-Zeitreihen, node_exporter etc.
====InfluxDB====
für die Sammlung von FHEM-Zeitreihen
====Grafana====
für die übergreifende Visualisierung von Zeitreihen

Benutzer:Plin53177

2020-09-05T13:07:17Z

Plin53177: /* Visualisierung */

==FHEM Landschaft (2020)==
[[Datei:Plin53177 landscape.PNG|rahmenlos|1261x1261px]]

==FHEM-Instanzen==
===Main===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Hausmitte
|
|-
|Hardware
|Raspberry Pi 3B
|
|-
|Peripherie
|CUL (Homematic)
SIGNALduino (433 MHz, OOK)
|für Homematic-Devices

für diverse Funkthermometer
|-
|Schwerpunkt
|Zentrale Steuerung
Funkbasierte Steuerung
|
|-
|Module
|Alarm, CUL, CUL_HM, CUL_TCM97001, CUL_TX, DOIF, Dashboard, ESPEasy, FHEM2FHEM, FHEMWEB, FLAMINGO, FLOORPLAN, FileLog, HMLAN, HMinfo, HTTPSRV, HUEBridge, HUEDevice, HourCounter, IT, LEDStripe, LightScene, MSGMail, OREGON, PRESENCE, RESIDENTS, RFHEM, ROLLO, ROOMMATE, SD_WS, SD_WS07, SIGNALduino, SVG, SYSMON, THRESHOLD, TelegramBot, Text2Speech, Weather, WifiLight, at, autocreate, autoload_undefined_devices, cmdalias, define, devStateIcon, dummy, eventTypes, laststate, notify, readingsGroup, siri, structure, telnet, weblink
|
|}

===Server===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Keller
|
|-
|Hardware
|x86-Server mit OpenSUSE Leap 15.1
|
|-
|Peripherie
|CUL (Homematic) mit hmland
|
|-
|Schwerpunkt
|IP-basierte Module/Dienste
CUL-Verlängerung für Aktoren im Keller
|
|-
|Module
|CALVIEW, CUL_HM, Calendar, DOIF, Dashboard, ESPEasy, FB_CALLLIST, FB_CALLMONITOR, FHEM2FHEM, FHEMWEB, FRITZBOX, FileLog, HTTPMOD, HTTPSRV, IPCAM, MPD, RFHEM, SIP, SIRD, STV, TelegramBot, Text2Speech, WOL, allowed, at, autocreate, autoload_undefined_devices, dummy, eventTypes, notify, onCreateEvent, plex, readingsGroup, telnet, vitoconnect, weblink
|
|-
|Sonstiges
|collectd für Fritz!Box 7490
|
|}
===Wohnzimmer===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|rdgeschossE
|
|-
|Hardware
|Raspberry Pi 2
|
|-
|Peripherie
|SIGNALduino (868 MHz, GFSK)
Lautsprecher
|für die Rolläden
|-
|Schwerpunkt
|Rolladensteuerung
Sound-Ausgabe
|
|-
|Module
|DOIF, FHEMWEB, FileLog, MsqQueue, PRESENCE, RFHEM, ROLLO, SD_Keeloq, SIGNALduino, Text2Speech, autocreate, autoload_undefined_devices, dummy, eventTypes, msgConfig, notify, structure, telnet, weblink
|
|}
===Log===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|docker container auf Server
|
|-
|Hardware
|(docker container)
|
|-
|Peripherie
|keine
|
|-
|Schwerpunkt
|Sammelt per FHEM2FHEM alle Metriken für
die Visualisierung in Grafana
|
|-
|Module
|DOIF, DockerImageInfo, FHEM, FHEM2FHEM, FHEMWEB, InfluxDBLog, RFHEM, dummy, eventTypes, notify, telnet
|
|}
===Visualisierung===
====Prometheus====
für die Sammlung von collectd-Zeitreihen, node_exporter etc.
====InfluxDB====
für die Sammlung von FHEM-Zeitreihen
====Grafana====
für die übergreifende Visualisierung von Zeitreihen

Benutzer:Plin53177

2020-09-05T13:04:45Z

Plin53177:

==FHEM Landschaft (2020)==
[[Datei:Plin53177 landscape.PNG|rahmenlos|1261x1261px]]

==FHEM-Instanzen==
===Main===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Hausmitte
|
|-
|Hardware
|Raspberry Pi 3B
|
|-
|Peripherie
|CUL (Homematic)
SIGNALduino (433 MHz, OOK)
|für Homematic-Devices

für diverse Funkthermometer
|-
|Schwerpunkt
|Zentrale Steuerung
Funkbasierte Steuerung
|
|-
|Module
|Alarm, CUL, CUL_HM, CUL_TCM97001, CUL_TX, DOIF, Dashboard, ESPEasy, FHEM2FHEM, FHEMWEB, FLAMINGO, FLOORPLAN, FileLog, HMLAN, HMinfo, HTTPSRV, HUEBridge, HUEDevice, HourCounter, IT, LEDStripe, LightScene, MSGMail, OREGON, PRESENCE, RESIDENTS, RFHEM, ROLLO, ROOMMATE, SD_WS, SD_WS07, SIGNALduino, SVG, SYSMON, THRESHOLD, TelegramBot, Text2Speech, Weather, WifiLight, at, autocreate, autoload_undefined_devices, cmdalias, define, devStateIcon, dummy, eventTypes, laststate, notify, readingsGroup, siri, structure, telnet, weblink
|
|}

===Server===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Keller
|
|-
|Hardware
|x86-Server mit OpenSUSE Leap 15.1
|
|-
|Peripherie
|CUL (Homematic) mit hmland
|
|-
|Schwerpunkt
|IP-basierte Module/Dienste
CUL-Verlängerung für Aktoren im Keller
|
|-
|Module
|CALVIEW, CUL_HM, Calendar, DOIF, Dashboard, ESPEasy, FB_CALLLIST, FB_CALLMONITOR, FHEM2FHEM, FHEMWEB, FRITZBOX, FileLog, HTTPMOD, HTTPSRV, IPCAM, MPD, RFHEM, SIP, SIRD, STV, TelegramBot, Text2Speech, WOL, allowed, at, autocreate, autoload_undefined_devices, dummy, eventTypes, notify, onCreateEvent, plex, readingsGroup, telnet, vitoconnect, weblink
|
|-
|Sonstiges
|collectd für Fritz!Box 7490
|
|}
===Wohnzimmer===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|rdgeschossE
|
|-
|Hardware
|Raspberry Pi 2
|
|-
|Peripherie
|SIGNALduino (868 MHz, GFSK)
Lautsprecher
|für die Rolläden
|-
|Schwerpunkt
|Rolladensteuerung
Sound-Ausgabe
|
|-
|Module
|DOIF, FHEMWEB, FileLog, MsqQueue, PRESENCE, RFHEM, ROLLO, SD_Keeloq, SIGNALduino, Text2Speech, autocreate, autoload_undefined_devices, dummy, eventTypes, msgConfig, notify, structure, telnet, weblink
|
|}
===Log===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|docker container auf Server
|
|-
|Hardware
|(docker container)
|
|-
|Peripherie
|keine
|
|-
|Schwerpunkt
|Sammelt per FHEM2FHEM alle Metriken für
die Visualisierung in Grafana
|
|-
|Module
|DOIF, DockerImageInfo, FHEM, FHEM2FHEM, FHEMWEB, InfluxDBLog, RFHEM, dummy, eventTypes, notify, telnet
|
|}
===Visualisierung===

Benutzer:Plin53177

2020-09-05T12:45:07Z

Plin53177:

==FHEM Landschaft (2020)==
[[Datei:Plin53177 landscape.PNG|rahmenlos|1261x1261px]]

==FHEM-Instanzen==
===Main===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Hausmitte
|
|-
|Hardware
|Raspberry Pi 3B
|
|-
|Peripherie
|CUL (Homematic)
SIGNALduino (433 MHz, OOK)
|für Homematic-Devices

für diverse Funkthermometer
|-
|Schwerpunkt
|Zentrale Steuerung
Funkbasierte Steuerung
|
|-
|Module
|Alarm, CUL, CUL_HM, CUL_TCM97001, CUL_TX, DOIF, Dashboard, ESPEasy, FHEM2FHEM, FHEMWEB, FLAMINGO, FLOORPLAN, FileLog, HMLAN, HMinfo, HTTPSRV, HUEBridge, HUEDevice, HourCounter, IT, LEDStripe, LightScene, MSGMail, OREGON, PRESENCE, RESIDENTS, RFHEM, ROLLO, ROOMMATE, SD_WS, SD_WS07, SIGNALduino, SVG, SYSMON, THRESHOLD, TelegramBot, Text2Speech, Weather, WifiLight, at, autocreate, autoload_undefined_devices, cmdalias, define, devStateIcon, dummy, eventTypes, laststate, notify, readingsGroup, siri, structure, telnet, weblink
|
|}

===Server===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|Keller
|
|-
|Hardware
|x86-Server mit OpenSUSE Leap 15.1
|
|-
|Peripherie
|CUL (Homematic) mit hmland
|
|-
|Schwerpunkt
|IP-basierte Module/Dienste
CUL-Verlängerung für Aktoren im Keller
|
|-
|Module
|CALVIEW, CUL_HM, Calendar, DOIF, Dashboard, ESPEasy, FB_CALLLIST, FB_CALLMONITOR, FHEM2FHEM, FHEMWEB, FRITZBOX, FileLog, HTTPMOD, HTTPSRV, IPCAM, MPD, RFHEM, SIP, SIRD, STV, TelegramBot, Text2Speech, WOL, allowed, at, autocreate, autoload_undefined_devices, dummy, eventTypes, notify, onCreateEvent, plex, readingsGroup, telnet, vitoconnect, weblink
|
|}
===Wohnzimmer===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|rdgeschossE
|
|-
|Hardware
|Raspberry Pi 2
|
|-
|Peripherie
|SIGNALduino (868 MHz, GFSK)
|für die Rolläden
|-
|Schwerpunkt
|Rolladensteuerung
Sound-Ausgabe
|
|-
|Module
|DOIF, FHEMWEB, FileLog, MsqQueue, PRESENCE, RFHEM, ROLLO, SD_Keeloq, SIGNALduino, Text2Speech, autocreate, autoload_undefined_devices, dummy, eventTypes, msgConfig, notify, structure, telnet, weblink
|
|}
===Log===
{| class="wikitable"
|+
!Aspekt
!Info
!Bemerkung
|-
|Position
|docker container auf Server
|
|-
|Hardware
|(docker container)
|
|-
|Peripherie
|keine
|
|-
|Schwerpunkt
|Sammelt per FHEM2FHEM alle Metriken für
die Visualisierung in Grafana
|
|-
|Module
|DOIF, DockerImageInfo, FHEM, FHEM2FHEM, FHEMWEB, InfluxDBLog, RFHEM, dummy, eventTypes, notify, telnet
|
|}
===Visualisierung===

Benutzer:Plin53177

2020-09-05T12:24:18Z

Plin53177: /* Main */

Benutzer:Plin53177

2020-09-05T08:38:09Z

Plin53177:

==FHEM Landschaft (2020)==
[[Datei:Plin53177 landscape.PNG|rahmenlos|1261x1261px]]

==FHEM-Instanzen==
===Main===
{| class="wikitable"
|+
!Aspekt
!.
!Bemerkung
|-
|Position
|Hausmitte
|
|-
|Hardware
|Raspberry Pi 3B
|
|-
|Peripherie
|CUL (Homematic)
SIGNALduino (433 MHz, OOK)
|
|-
|Schwerpunkt
|Zentrale Steuerung
Funkbasierte Steuerung
|
|-
|Module
|
|
|}

===Server===

===Wohnzimmer===

===Log===

Datei:Plin53177 landscape.PNG

2020-09-05T08:30:46Z

Plin53177: pli53177 FHEM Landscpae

== Beschreibung ==
pli53177 FHEM Landscpae

Benutzer:Plin53177

2020-09-05T08:29:18Z

Plin53177: Die Seite wurde neu angelegt: „==FHEM Landschaft (2020)== xxx ==FHEM-Instanzen== ===Main=== ===Server=== ===Wohnzimmer=== ===Log===“

==FHEM Landschaft (2020)==

xxx

==FHEM-Instanzen==
===Main===

===Server===

===Wohnzimmer===

===Log===

Solar-/PV-Übersicht

2020-09-02T18:27:11Z

Plin53177: /* Wechselrichter */

<div style="float:right;margin-left:10px">__TOC__</div>
Die Seite [[Solar-/PV-Übersicht]] soll einen schnellen Einstieg in die für Solar-/Photovoltaik-Betreiber relevanten Seiten und Threads ermöglichen. Bitte bei Bedarf selbständig ergänzen.

==Forum==
Der Forenbereich {{Link2Forum|Area=Solaranlagen}} enthält Themen rund um Solaranlagen zur Wärme- oder Stromgewinnung

== Allgemein ==
* [[Fotovoltaikanlage]]
* Viele Seiten der Kategorie [[:Kategorie:Energieerzeugungsmessung|Energieerzeugungsmessung]]

==Wechselrichter==
===Kostal===
* [[KostalPiko]]
* [[Kostal Plenticore 10 Plus]]

===SMA===
* [[SMAWechselrichter]]

===Solar Edge===
* [[SolarEdge SE10k]]

===Sunways===
* [[NT5000]]

==Speicher==
* [[Sonnenspeicher]]

==Monitoring/Auswertung==
* [[Enecsys Monitoring System]]
* [[SunnyHomeManager]]
* [[Datenbankgestützte Erstellung der Energiebilanz einer SMA PV-Anlage mit Überschusseinspeisung]]
* [[SolarLog]]

==Angrenzende Themen==
Verwandte Themen, "gern verwendete" oder erforderliche Module, etc.:
* [[ModbusAttr]]
* [[SMLUSB]]

[[Kategorie:Energieerzeugungsmessung]]

Kostal Plenticore 10 Plus

2020-09-02T06:46:46Z

Plin53177: Kategorie Energieerzeugungsmessung ergänzt

{{Infobox Hardware
|Bild=Kostal_Plenticore_10_Plus.jpg
|Bildbeschreibung=Kostal Plenticore 10 Plus
|HWProtocol=IP und RS485
|HWType=Hybrid Wechselrichter
|HWCategory=Wechselrichter
|HWComm=n/a
|HWChannels=n/a
|HWVoltage=400 V
|HWPowerConsumption=
|HWPoweredBy=3P AC
|HWSize=56,3x40,5x23,3 cm (BxHxT)
|HWDeviceFHEM=[[HTTPMOD]], [[Modbus]], [[Python3]]

|HWManufacturer=KOSTAL Solar Electric GmbH
}}
[[Bild:Plenticore FHEM 1.png|mini|900px|rechts|Die Diagramme im Überblick]]
[[Bild:Plenticore FHEM 2.png|mini|900px|rechts|Geräte Überblick mit manueller Schaltmöglichkeit]]
[[Bild:Plenticore FHEM 3.png|mini|900px|rechts|Steuerungsgeräte für die Schaltlogik]]
[[Bild:Plenticore FHEM 4.png|mini|900px|rechts|ReadingsGroup für die schnelle Parametereinstellung]]

Ein Hinweis allgemeiner Art: Die hier abgebildeten Code Stücke sind nicht ausschließlich durch mich entstanden. Ich bedanke mich für die Unterstützung und Bereitstellung vieler Einzelkomponenten durch Dritte. Der Einsatz ist auf eigene Gefahr und für etwaige Schäden wird keinerlei Haftung übernommen. Bitte beachtet bei der Hardware die Gewährleistungsbestimmungen und Vorgaben der Hersteller.

Der [[Kostal Plenticore 10 Plus]] [https://www.kostal-solar-electric.com/de-de/produkte/hybrid-wechselrichter/ Hersteller Link] ist ein Hybrid Wechselrichter mit IP-Konnektivität.

Er verfügt über einen LAN-Anschluss und ist auf die Steuerung via WebGUI des Herstellers ausgelegt. Weiterhin kann eine Abfrage mit Modbus/TCP oder auch über eine undokumentierte API erfolgen. Für die API bietet der Hersteller keinerlei Support!

== Voraussetzungen Energietechnik ==

Der Wechselrichter, der Speicher und der KSEM wurden durch einen Fachbetrieb installiert und konfiguriert. Die gesamte Anlage läuft fehlerfrei und wurde durch den Fachbetrieb abgenommen, sowie beim Netzbetreiber angemeldet.

== Geräte-Registrierung ==

Hierfür ist die Dokumentation des Herstellers heranzuziehen. Für eine Verlängerung der Gewährleistungszeit kann man den Plenticore im Herstellerportal registrieren. Dies ist jedoch für die Anbindung an FHEM nicht notwendig.

== Hersteller Dokumentation ==

Für Links auf dieser Wiki Seite wird keine Haftung übernommen. Die Inhalte unterliegen der Verantwortung der Firma Kostal.
* [https://www.kostal-solar-electric.com/de-de/service-und-support/smart-warranty/ Plenticore Plus - Verlängerung der Gewährleistungszeit]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/06/15/11/40/plenticore-plus_ba_de.pdf/ Plenticore Plus - Betriebsanleitung]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/04/12/08/26/plenticore-plus_kba.pdf/ Plenticore Plus - Kurzanleitung]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/04/12/08/26/db_plenticore-plus_de.pdf/ Plenticore Plus - Datenblatt]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/03/12/07/13/kostal_update_plenticore_piko_iq_011504581.swu/ Plenticore Plus - Software Update UI: 01.15.04581 FW: 01.43]

* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2018/08/30/08/53/ba_kostal_interface_modbus-tcp_sunspec.pdf/ Plenticore - Modbus\/ Sunspec]

* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/03/06/13/17/ksem-ba_de.pdf/ KSEM - Betriebsanleitung]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/03/06/13/17/ksem-db_de.pdf/ KSEM - Datenblatt]
* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2020/06/09/11/49/kostal_update_ksem_1_2_1.zip/ KSEM - Software Update - 1.2.1]

* [https://www.kostal-solar-electric.com/de-de/download/-/media/document-library-folder---kse/2019/05/09/13/57/ba_kostal_interface_ksem---201911.pdf/ KSEM - Modbus\/ Sunspec]

* [https://www.kostal-solar-electric.com/de-de/service-und-support/kontakt/ Kostal - Service Kontakt]

== Einbindung in das Netzwerk ==

Als Grundlage ist der Plenticore mit dem LAN zu verbinden, wodurch er eine TCP/IP Adresse per DHCP bekommt. Diese ist dann entweder am Display des Plenticore abzulesen, oder über die Oberfläche des Routers zu ermitteln.

Das gleiche gilt für den BYD Speicher, der jedoch zusätzlich auch über WLAN verfügt. Eine Netzwerkanbindung des Speichers ist beim Plenticore nicht zwingend notwendig, da der Plenticore mit dem Speicher über eine RS-485 Schnittstelle kommuniziert. Bei dieser Anbindung werden jedoch noch nicht alle möglichen Werte aus dem Speicher ausgelesen. Später wird hierzu jedoch noch mehr geschrieben, um alle Möglichkeiten offen zu halten.

Der KSEM kann ebenfalls auch direkt per LAN ausgelesen werden, was jedoch ebenfalls nicht zwingend notwendig ist. Eine Kommunikation des KSEM mit dem Plenticore erfolgt über zwei mögliche Wege. Beim Betrieb mit Speicher ist zwingend die RS485 Schnittstelle erforderlich, über die auch der Plenticore alle Werte übermittelt bekommt. Auch diese sind dann am Plenticore abfragbar. Der zweite Weg wäre dann über die LAN Verbindung, bei der jedoch kein Speicher am Plenticore konfigurierbar ist.

== Voraussetzungen FHEM Umfeld ==

=== Alle Geräte müssen mit TCP/IP erreichbar sein ===

=== Alle Module sollten auf einem aktuellen Stand sein ===

=== Python ===

==== Ein Python 3 sollte vorhanden sein ====
Wenn man die erweiterten Funktionalitäten, wie Statistiken, Speicher auslesen und später auch das Setzen von Werten im Plenticore, verwenden möchte.

==== Es müssen folgende Python Module vorhanden sein ====
<syntaxhighlight lang="Perl">
python3-pip

pip3 install pycryptodome
pip3 install -U fhem
</syntaxhighlight>
=== Eine LogDB/LogDBRep sollte bereits vorhanden sein, was hier nicht weiter erklärt wird. ===

=== Verwendete Module ===
<pre>
- Modbus
- HTTPMOD
- expandJSON
- DbLog
- DbRep
- dummy
- Shelly
- HourCounter
- readingsGroup
</pre>

== Einbindung in FHEM: Überblick ==

=== Hardware Anbindung (alles über LAN) ===

==== Kostal Plenticore Plus ====
===== Kostal Plenticore Plus die Basis information (Modbus/TCP) =====
Der Kostal Plenticore wird mittels des Moduls MODBUS eingebunden. Dazu gilt zunächst die folgende Konfiguration als Basis, die am Display des Plenticore oder auch in der Kostal Dokumentation zu entnehmen ist.
====== Plenticore Modbus Definition ======
<pre>
GeräteId : 71
IP-Adresse: <IP-Adresse>
Port : 1502
</pre>

====== Modbus Timing ======
Das Gerät aktualisiert sich im Abstand von 60 Sekunden durch den stetigen Modbus/TCP Datenstrom. Der Plenticore ist als Modbus Master implementiert und sendet somit alle Daten permanent ins Netzwerk.

Die Zeit kann auch verändert werden, jedoch sollte sie nicht zu kurz gewählt sein.

====== RAW Definition des konfigurations Dummy ======
Diese Dummy soll alle Konfigurationsparameter halten, auf die dann die anderen Geräte Definitionen zentral zugreifen. Hier können auch default Namen und Vorschläge für Werte in Form von Slidern und Auswahllisten hinterlegt werden.
<syntaxhighlight lang="Perl">
defmod PV_Anlage_1_config dummy
attr PV_Anlage_1_config DbLogExclude .*
attr PV_Anlage_1_config alias PV_Anlage_1_config
attr PV_Anlage_1_config comment Steht das reading module_*_count auf 0 wird diese Ausrichtung nicht berücksichtigt\
Passworte zu dieser Konfiguration liegen im Dateiverzeichnis ~./python/pwd_*.json\
\
Korrekturkurven:\
Steilheit Parallel\
verschiebung\
tempk -0.39 25\
cloudk -0.65 0\
raink -0.30 0\
Der Slider für die Steilheit wird mit - k/100 umgerechnet. 39 ==> -0.39
attr PV_Anlage_1_config event-on-change-reading .*
attr PV_Anlage_1_config group PV Eigenverbrauch
attr PV_Anlage_1_config icon solar_icon
attr PV_Anlage_1_config readingList IP-Address_Plenticore IP-Address_BYD IP-Address_KSEM IP-Address_FHEM module_1_active module_2_active module_3_active module_1_name module_2_name module_3_name module_1_direction module_2_direction module_3_direction module_1_count module_2_count module_3_count module_1_power module_2_power module_3_power module_1_plain module_2_plain module_3_plain forecast_cloudk forecast_cloudk_base forecast_raink forecast_raink_base forecast_tempk forecast_tempk_base forecast_factor
attr PV_Anlage_1_config room Strom->Photovoltaik
attr PV_Anlage_1_config setList IP-Address_Plenticore IP-Address_BYD IP-Address_KSEM IP-Address_FHEM module_1_name:East,SouthEast,South,SouthWest,West module_2_name:East,SouthEast,South,SouthWest,West module_3_name:East,SouthEast,South,SouthWest,West module_1_direction:slider,-90,5,+90 module_2_direction:slider,-90,5,90 module_3_direction:slider,-90,5,90 module_1_count:slider,0,1,40 module_2_count:slider,0,1,40 module_3_count:slider,0,1,40 module_1_power:slider,250,10,400 module_2_power:slider,250,10,400 module_3_power:slider,250,10,400 module_1_plain:slider,15,1,45 module_2_plain:slider,15,1,45 module_3_plain:slider,15,1,45 forecast_cloudk:slider,0,1,100 forecast_cloudk_base:slider,0,1,10 forecast_raink:slider,0,1,100 forecast_raink_base:slider,0,1,10 forecast_tempk:slider,0,1,100 forecast_tempk_base:slider,10,1,30 forecast_factor:1,1.5,2,2.5,3,3.5,4,4.5,5
attr PV_Anlage_1_config sortby 06
attr PV_Anlage_1_config verbose 0
</syntaxhighlight>

====== RAW Definition des Wechselrichters ======
<syntaxhighlight lang="Perl">
defmod PV_Anlage_1 ModbusAttr 71 60 <IP-Address_Plenticore>:1502 TCP
attr PV_Anlage_1 DbLogExclude .*
attr PV_Anlage_1 DbLogInclude Act_state_of_charge,Actual_battery_charge_-minus_or_discharge_-plus_Power,Actual_battery_charge_usable_Power,Battery_temperature,Home_own_consumption_from_PV,Home_own_consumption_from_battery,Home_own_consumption_from_grid,Inverter_state,Power_DC1,Power_DC2,Power_DC_Sum,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Voltage_DC1,Voltage_DC2,.*_yield,Solar_.*,Statistic_.*
attr PV_Anlage_1 alias PV_Einspeisung
attr PV_Anlage_1 comment Kostal Plenticore 10 Plus mit BYD Speicher
attr PV_Anlage_1 dev-h-defFormat %.2f
attr PV_Anlage_1 dev-h-defLen 2
attr PV_Anlage_1 dev-h-defPoll 1
attr PV_Anlage_1 dev-h-defRevRegs 1
attr PV_Anlage_1 dev-h-defUnpack f>
attr PV_Anlage_1 dev-type-STR-format %s
attr PV_Anlage_1 dev-type-STR-len 8
attr PV_Anlage_1 dev-type-STR-revRegs 0
attr PV_Anlage_1 dev-type-STR-unpack a*
attr PV_Anlage_1 event-on-change-reading statistics_.*,Statistic_.*,Act_state_of_charge,Actual_battery_charge_.*,Battery_temperature,Home_own_consumption_from_.*,Inverter_state,Power_DC1,Power_DC2,Power_DC_Sum,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Voltage_DC1,Voltage_DC2,.*_yield,Solar_.*
attr PV_Anlage_1 group PV Eigenverbrauch
attr PV_Anlage_1 icon sani_solar
attr PV_Anlage_1 obj-h100-reading Total_DC_Power
attr PV_Anlage_1 obj-h104-format %s
attr PV_Anlage_1 obj-h104-reading State_of_energy_manager
attr PV_Anlage_1 obj-h104-revRegs 0
attr PV_Anlage_1 obj-h104-unpack N
attr PV_Anlage_1 obj-h106-reading Home_own_consumption_from_battery
attr PV_Anlage_1 obj-h108-reading Home_own_consumption_from_grid
attr PV_Anlage_1 obj-h110-reading Total_home_consumption_Battery
attr PV_Anlage_1 obj-h112-reading Total_home_consumption_Grid
attr PV_Anlage_1 obj-h114-reading Total_home_consumption_PV
attr PV_Anlage_1 obj-h116-reading Home_own_consumption_from_PV
attr PV_Anlage_1 obj-h118-reading Total_home_consumption
attr PV_Anlage_1 obj-h120-reading Isolation_resistance
attr PV_Anlage_1 obj-h122-reading Power_limit_from_EVU
attr PV_Anlage_1 obj-h124-reading Total_home_consumption_rate
attr PV_Anlage_1 obj-h14-reading Inverter_serial_number
attr PV_Anlage_1 obj-h14-type STR
attr PV_Anlage_1 obj-h144-reading Worktime
attr PV_Anlage_1 obj-h150-reading Actual_cos_phi
attr PV_Anlage_1 obj-h152-reading Grid_frequency
attr PV_Anlage_1 obj-h154-reading Current_Phase_1
attr PV_Anlage_1 obj-h156-reading Active_power_Phase_1
attr PV_Anlage_1 obj-h158-reading Voltage_Phase_1
attr PV_Anlage_1 obj-h160-reading Current_Phase_2
attr PV_Anlage_1 obj-h162-reading Active_power_Phase_2
attr PV_Anlage_1 obj-h164-reading Voltage_Phase_2
attr PV_Anlage_1 obj-h166-reading Current_Phase_3
attr PV_Anlage_1 obj-h168-reading Active_power_Phase_3
attr PV_Anlage_1 obj-h170-reading Voltage_Phase_3
attr PV_Anlage_1 obj-h172-reading Total_AC_active_power
attr PV_Anlage_1 obj-h174-reading Total_AC_reactive_power
attr PV_Anlage_1 obj-h178-reading Total_AC_apparent_power
attr PV_Anlage_1 obj-h190-reading Battery_charge_current
attr PV_Anlage_1 obj-h194-format %.0f
attr PV_Anlage_1 obj-h194-reading Number_of_battery_cycles
attr PV_Anlage_1 obj-h200-reading Actual_battery_charge_-minus_or_discharge_-plus_current
attr PV_Anlage_1 obj-h202-reading PSSB_fuse_state
attr PV_Anlage_1 obj-h208-format %.0f
attr PV_Anlage_1 obj-h208-reading Battery_ready_flag
attr PV_Anlage_1 obj-h210-reading Act_state_of_charge
attr PV_Anlage_1 obj-h212-reading Battery_state
attr PV_Anlage_1 obj-h214-reading Battery_temperature
attr PV_Anlage_1 obj-h216-reading Battery_voltage
attr PV_Anlage_1 obj-h218-reading Cos_phi_(powermeter)
attr PV_Anlage_1 obj-h220-reading Frequency_(powermeter)
attr PV_Anlage_1 obj-h222-reading Current_phase_1_(powermeter)
attr PV_Anlage_1 obj-h224-reading Active_power_phase_1_(powermeter)
attr PV_Anlage_1 obj-h226-reading Reactive_power_phase_1_(powermeter)
attr PV_Anlage_1 obj-h228-reading Apparent_power_phase_1_(powermeter)
attr PV_Anlage_1 obj-h230-reading Voltage_phase_1_(powermeter)
attr PV_Anlage_1 obj-h232-reading Current_phase_2_(powermeter)
attr PV_Anlage_1 obj-h234-reading Active_power_phase_2_(powermeter)
attr PV_Anlage_1 obj-h236-reading Reactive_power_phase_2_(powermeter)
attr PV_Anlage_1 obj-h238-reading Apparent_power_phase_2_(powermeter)
attr PV_Anlage_1 obj-h240-reading Voltage_phase_2_(powermeter)
attr PV_Anlage_1 obj-h242-reading Current_phase_3_(powermeter)
attr PV_Anlage_1 obj-h244-reading Active_power_phase_3_(powermeter)
attr PV_Anlage_1 obj-h246-reading Reactive_power_phase_3_(powermeter)
attr PV_Anlage_1 obj-h248-reading Apparent_power_phase_3_(powermeter)
attr PV_Anlage_1 obj-h250-reading Voltage_phase_3_(powermeter)
attr PV_Anlage_1 obj-h252-reading Total_active_power_(powermeter)
attr PV_Anlage_1 obj-h254-reading Total_reactive_power_(powermeter)
attr PV_Anlage_1 obj-h256-reading Total_apparent_power_(powermeter)
attr PV_Anlage_1 obj-h258-reading Current_DC1
attr PV_Anlage_1 obj-h260-reading Power_DC1
attr PV_Anlage_1 obj-h266-reading Voltage_DC1
attr PV_Anlage_1 obj-h268-reading Current_DC2
attr PV_Anlage_1 obj-h270-reading Power_DC2
attr PV_Anlage_1 obj-h276-reading Voltage_DC2
attr PV_Anlage_1 obj-h278-reading Current_DC3
attr PV_Anlage_1 obj-h280-reading Power_DC3
attr PV_Anlage_1 obj-h286-reading Voltage_DC3
attr PV_Anlage_1 obj-h320-reading Total_yield
attr PV_Anlage_1 obj-h322-reading Daily_yield
attr PV_Anlage_1 obj-h324-reading Yearly_yield
attr PV_Anlage_1 obj-h326-reading Monthly_yield
attr PV_Anlage_1 obj-h38-reading Software-Version_Maincontroller_(MC)
attr PV_Anlage_1 obj-h38-type STR
attr PV_Anlage_1 obj-h384-len 16
attr PV_Anlage_1 obj-h384-reading Inverter_network_name
attr PV_Anlage_1 obj-h384-type STR
attr PV_Anlage_1 obj-h420-reading IP-address
attr PV_Anlage_1 obj-h420-type STR
attr PV_Anlage_1 obj-h428-reading IP-subnetmask
attr PV_Anlage_1 obj-h428-type STR
attr PV_Anlage_1 obj-h436-reading IP-gateway
attr PV_Anlage_1 obj-h436-type STR
attr PV_Anlage_1 obj-h446-reading IP-DNS1
attr PV_Anlage_1 obj-h446-type STR
attr PV_Anlage_1 obj-h454-reading IP-DNS2
attr PV_Anlage_1 obj-h454-type STR
attr PV_Anlage_1 obj-h46-reading Software-Version_IO-Controller_(IOC)
attr PV_Anlage_1 obj-h46-type STR
attr PV_Anlage_1 obj-h514-len 1
attr PV_Anlage_1 obj-h514-reading Battery_actual_SOC
attr PV_Anlage_1 obj-h517-reading Battery_Manufacturer
attr PV_Anlage_1 obj-h517-type STR
attr PV_Anlage_1 obj-h525-format %c
attr PV_Anlage_1 obj-h525-reading Battery_Model_ID
attr PV_Anlage_1 obj-h525-unpack N
attr PV_Anlage_1 obj-h527-format %c
attr PV_Anlage_1 obj-h527-reading Battery_Serial_Number
attr PV_Anlage_1 obj-h529-len 4
attr PV_Anlage_1 obj-h529-reading Work_Capacity
attr PV_Anlage_1 obj-h529-unpack N
attr PV_Anlage_1 obj-h531-format %.0f
attr PV_Anlage_1 obj-h531-reading Inverter_Max_Power
attr PV_Anlage_1 obj-h531-unpack N
attr PV_Anlage_1 obj-h535-revRegs 0
attr PV_Anlage_1 obj-h535-unpack n
attr PV_Anlage_1 obj-h551-revRegs 0
attr PV_Anlage_1 obj-h559-revRegs 0
attr PV_Anlage_1 obj-h56-format %.0f
attr PV_Anlage_1 obj-h56-reading Inverter_state
attr PV_Anlage_1 obj-h56-unpack N
attr PV_Anlage_1 obj-h575-len 1
attr PV_Anlage_1 obj-h575-reading Inverter_Generation_Power_(actual)
attr PV_Anlage_1 obj-h577-len 2
attr PV_Anlage_1 obj-h577-reading Generation_Energy
attr PV_Anlage_1 obj-h577-unpack N
attr PV_Anlage_1 obj-h578-reading Total_energy
attr PV_Anlage_1 obj-h582-reading Actual_battery_charge-discharge_power
attr PV_Anlage_1 obj-h586-format %s
attr PV_Anlage_1 obj-h586-reading Battery_Firmware
attr PV_Anlage_1 obj-h586-unpack N
attr PV_Anlage_1 obj-h588-format %s
attr PV_Anlage_1 obj-h588-len 1
attr PV_Anlage_1 obj-h588-reading Battery_Type
attr PV_Anlage_1 obj-h588-unpack N
attr PV_Anlage_1 obj-h6-reading Inverter_article_number
attr PV_Anlage_1 obj-h6-type STR
attr PV_Anlage_1 obj-h768-len 32
attr PV_Anlage_1 obj-h768-reading Productname
attr PV_Anlage_1 obj-h768-type STR
attr PV_Anlage_1 obj-h800-len 32
attr PV_Anlage_1 obj-h800-reading Power_class
attr PV_Anlage_1 obj-h800-type STR
attr PV_Anlage_1 room Strom->Photovoltaik
attr PV_Anlage_1 sortby 01
attr PV_Anlage_1 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TH ALIGN=\"MIDDLE\" WIDTH=\"20\">Batterie %s</TH>\
<TH ALIGN=\"MIDDLE\" WIDTH=\"20\">aktuell</TH>\
<TH ALIGN=\"RIGHT\" WIDTH=\"20\">Hausverbrauch</TH>\
<TH ALIGN=\"MIDDLE\" WIDTH=\"20\">Erträge</TH>\
</TR>\
\
<TR>\
<TD ALIGN=\"MIDDLE\" WIDTH=\"20\">\
Leistung: %04d W<br>\
Temp.: %02.1f °C<br>\
Ladung total: %2d %%<br>\
Ladung Res.: %04d Wh\
</TD>\
\
<TD ALIGN=\"RIGHT\" WIDTH=\"20\">\
DC total: %05d W<br>\
<br>\
<br>\
PV reserve: %05d W\
</TD>\
\
<TD ALIGN=\"RIGHT\" WIDTH=\"20\">\
von PV: %05d W <br>\
von Batterie: %05d W<br>\
vom Netz: %05d W<br>\
ins Haus: %05d W<br>\
Netz: %05d W\
</TD>\
\
<TD ALIGN=\"RIGHT\" WIDTH=\"20\">\
Tag: %05d KWh <br>\
Monat: %05d KWh<br>\
Jahr: %05d KWh<br>\
Total: %05d KWh\
</TD>\
</TR>\
\
</TABLE>\
" , \
(ReadingsVal($name,"Actual_battery_charge_-minus_or_discharge_-plus_Power",0) lt 0) ? "<span style='color:#00FF00'>Laden</span>":"<span style='color:#FF0000'>Entladen</span>" ,\
\
ReadingsVal($name,"Actual_battery_charge_-minus_or_discharge_-plus_Power",0),\
ReadingsVal($name,"Battery_temperature",0) ,\
ReadingsVal($name,"Act_state_of_charge",0) ,\
ReadingsVal($name,"Actual_battery_charge_usable_Power",0) ,\
\
ReadingsVal($name,"Power_DC_Sum","0"),\
ReadingsVal($name,"Total_PV_Power_reserve","0"),\
\
ReadingsVal($name,"Home_own_consumption_from_PV",0) ,\
ReadingsVal($name,"Home_own_consumption_from_battery",0) ,\
ReadingsVal($name,"Home_own_consumption_from_grid",0),\
ReadingsVal($name,"Home_own_consumption_from_PV",0) +ReadingsVal($name,"Home_own_consumption_from_battery",0)+ReadingsVal($name,"Home_own_consumption_from_grid",0),\
ReadingsVal($name,"Total_active_power_(powermeter)",0),\
\
round(ReadingsVal($name,"Daily_yield",0)/1000 ,0),\
round(ReadingsVal($name,"Monthly_yield",0)/1000 ,0) ,\
round(ReadingsVal($name,"Yearly_yield",0)/1000 ,0) ,\
round(ReadingsVal($name,"Total_yield",0)/1000 ,0)\
)}
attr PV_Anlage_1 userReadings Power_DC_Sum:Total_DC_Power.* { ReadingsVal($NAME,"Power_DC1","0")+ReadingsVal($NAME,"Power_DC2","0") },\
\
Total_PV_Power_reserve:Total_DC_Power.* {my $reserve = ReadingsVal($NAME,"Power_DC_Sum","0") * 0.90 - ReadingsVal($NAME,"Home_own_consumption_from_PV","0");;;; ($reserve lt 0)?0:round($reserve,3) },\
\
Total_DC_Power_Max:Total_DC_Power.* { my $Bat_out = (ReadingsVal($NAME,"Actual_battery_charge_-minus_or_discharge_-plus_current","0")*ReadingsVal($NAME,"Battery_voltage","0"));;;; ($Bat_out gt 0)?ReadingsVal($NAME,"Power_DC_Sum","0") + $Bat_out :ReadingsVal($NAME,"Power_DC_Sum","0") },\
\
Actual_battery_charge_-minus_or_discharge_-plus_Power:Actual_battery_charge_-minus_or_discharge_-plus_current.* {round((ReadingsVal($NAME,"Actual_battery_charge_-minus_or_discharge_-plus_current","0")*ReadingsVal($NAME,"Battery_voltage","0")),0)},\
\
Actual_battery_charge_usable_Power:Act_state_of_charge.* {my $x = (8960*(ReadingsVal($NAME,"Act_state_of_charge","0")-10)/100);;;; ($x lt 0)?0:round($x,0) },\
\
statistics_clean:statistics_output.* { my $x = ReadingsVal($NAME,"statistics_output",0);;;; $x =~ s/"moduleid": "scb:statistic:EnergyFlow", |, "moduleid": "scb:statistic:EnergyFlow"|"processdata": \[//g;;;; $x =~ s/id": "|, "unit": "", "value"|^\[|\]\}\]$//g;;;; $x =~ s/moduleid/statistics_00_moduleid/g;;;; $x =~ s/processdata/statistics/g;;;; $x =~ s/\}\, \{/\, /g;;;; $x =~ s/\{\{/\{/g;;;; return $x }
attr PV_Anlage_1 verbose 0
</syntaxhighlight>

====== Userreadings ======
Um später einige Abfragen und Diagramme einfacher zu erstellen wurden einige userreadings erstellt, die bereits bei der RAW Definition mit vorhanden sind. Während der Integration in FHEM und der Konfiguration kann es hierdurch jedoch noch Fehlermeldungen im FHEM Log geben, da noch nicht alle Werte vorhanden sind. Dies betrifft insbesondere die Statistics_* readings, die durch ein Python Skript später erzeugt werden.

Power_DC_Sum
Trigger: Total_DC_Power.*
Dies berechnet direkt die Summe der DC-Leistung. Wenn der Plenticore einen Speicher hat, wird dieser am String 3 angeschlossen,
sollte also kein Speicher vorhanden sein muss man hier den dritten String auch noch addieren.
Total_PV_Power_reserve
Trigger: Total_DC_Power.*
Hier wird ein reading erstellt, dass als Information über die verwendbare Reserve dient. Die Leistung, die in den Speicher geht
sollte man nämlich besser sofort verbrauchen, anstatt es erst zu speicher. Die 0.90 ist ein circa Wirkungsgrad, um von DC- auf AC-Leistung zu kommen.
Der Total_PV_Power_reserve Wert kann gerne nach eigenen Belangen kalkuliert werden.
Total_DC_Power_Max
Trigger: Total_DC_Power.*
Um die Batterieleistung mit zu berücksichtigen wird dieser Momentan Wert ermittelt.
Actual_battery_charge_-minus_or_discharge_-plus_Power
Trigger: Actual_battery_charge_-minus_or_discharge_-plus_current.*
Berechnung der Batterie Leistung aus Spannung und Strom , der wert kann positiv oder negativ sein, je nach dem ob geladen oder entladen wird.
Actual_battery_charge_usable_Power
Trigger: Act_state_of_charge.*
Dieser Wert gibt an, wieviel Leistung im Speicher vorhanden ist, reduziert um 10% Verluste. An dieser Stelle muss die Nennleistung des Speichers
eingetragen werden, da diese noch nicht ausgelesen werden kann. Obwohl es im "Battery_Type 892941625" stecken könnte. 8929 >> 8.93 KW ???
statistics_clean
Trigger: statistics_output.*
Dies ist ein temporäres reading, das nur als zwischen Schritt für die Erstellung der Statistics_* readings verwendet wird. Befüllt wird zuerst
das reading statistics_output durch ein regelmäßig laufendes Python Skript.
Wer keine Statistiken haben möchte kann das einfach entfernen.
statistics_output
Trigger: externes Python Skript
Das userreading wird über ein Python Skript mit Daten gefüllt und dient als Trigger für statistics_clean

====== statistics_clean in readings umwandeln ======
Die Statistiken des Plenticore werden über ein Python Skript in das reading statistics_output geschrieben. Durch ein userreading wird daraus das JSON vereinfacht und in statistics_claen übertragen. Im letzten Schritt wandelt das expandJSON den JSON String in einzelne readings um.
<syntaxhighlight lang="Perl">
defmod Plenticore_Statistics expandJSON PV_Anlage_1:statistics_clean:.\{.*}
attr Plenticore_Statistics DbLogExclude .*
attr Plenticore_Statistics alias Plenticore_Statistics
attr Plenticore_Statistics comment Das Device wird über ein Python Skript im reading output befüllt.\

attr Plenticore_Statistics disable 0
attr Plenticore_Statistics room Strom->Photovoltaik
</syntaxhighlight>

===== Kostal Plenticore Plus die Statistiken (über Python Skript) =====
Der Plenticore erstellt intern noch diverse Statistiken, die auch über das WebGUI angesehen werden können. Diese werden jedoch nicht über MODBUS/TCP ausgegeben, aber zum Kostal Portal übermittelt, wo man dann bereits in Form von Diagrammen einen schönen Überblick bekommt. Das Ziel ist jedoch die Statistiken lokal im FHEM abzulegen, sie lassen sich nur über die API des Plenticore abfragen.

====== Plenticore API ======
<syntaxhighlight lang="Perl">
http://<IP-Address_Plenticore>/api/v1
</syntaxhighlight>

====== Dateiverzeichnis ======
<pre>
/opt/fhem
/opt/fhem/python/pwd_fhem.json
/opt/fhem/python/pwd_plenticore.json
/opt/fhem/python/bin
/opt/fhem/python/bin/plenticore_statistic.py
</pre>

====== Python 3 ======
<pre>
fhem@raspberrypi:~/python/bin$ which python3
/usr/bin/python3
fhem@raspberrypi:~/python/bin$ python3 --version
Python 3.7.3
</pre>

====== plenticore_statistic.py ======
fhem@raspberrypi:~/python/bin$ cat plenticore_statistic.py
<syntaxhighlight lang="Python">
import random
import string
import base64
import json
import requests
import hashlib
import os
import hmac
from Crypto.Cipher import AES
import binascii

import fhem
import asyncio

import sys
plenticore = sys.argv[1]
web = sys.argv[2]
request = '/processdata/scb:statistic:EnergyFlow'

try:
with open('/opt/fhem/python/pwd_plenticore.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

USER_TYPE = credentials["username"]
PASSWD = credentials["password"]
BASE_URL = "http://" + plenticore + "/api/v1"
AUTH_START = "/auth/start"
AUTH_FINISH = "/auth/finish"
AUTH_CREATE_SESSION = "/auth/create_session"
ME = "/auth/me"

def randomString(stringLength):
letters = string.ascii_letters
return ''.join(random.choice(letters) for i in range(stringLength))''

u = randomString(12)
u = base64.b64encode(u.encode('utf-8')).decode('utf-8')

step1 = {
"username": USER_TYPE,
"nonce": u
}
step1 = json.dumps(step1)

url = BASE_URL + AUTH_START
headers = {'Content-type': 'application/json', 'Accept': 'application/json'}
response = requests.post(url, data=step1, headers=headers)
response = json.loads(response.text)
i = response['nonce']
e = response['transactionId']
o = response['rounds']
a = response['salt']
bitSalt = base64.b64decode(a)

def getPBKDF2Hash(password, bytedSalt, rounds):
return hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), bytedSalt, rounds)

r = getPBKDF2Hash(PASSWD,bitSalt,o)
s = hmac.new(r, "Client Key".encode('utf-8'), hashlib.sha256).digest()
c = hmac.new(r, "Server Key".encode('utf-8'), hashlib.sha256).digest()
_ = hashlib.sha256(s).digest()
d = "n=user,r="+u+",r="+i+",s="+a+",i="+str(o)+",c=biws,r="+i
g = hmac.new(_, d.encode('utf-8'), hashlib.sha256).digest()
p = hmac.new(c, d.encode('utf-8'), hashlib.sha256).digest()
f = bytes(a ^ b for (a, b) in zip(s, g))
proof = base64.b64encode(f).decode('utf-8')

step2 = {
"transactionId": e,
"proof": proof
}
step2 = json.dumps(step2)

url = BASE_URL + AUTH_FINISH
headers = {'Content-type': 'application/json', 'Accept': 'application/json'}
response = requests.post(url, data=step2, headers=headers)
response = json.loads(response.text)
token = response['token']
signature = response['signature']

y = hmac.new(_, "Session Key".encode('utf-8'), hashlib.sha256)
y.update(d.encode('utf-8'))
y.update(s)
P = y.digest()
protocol_key = P
t = os.urandom(16)

e2 = AES.new(protocol_key,AES.MODE_GCM,t)
e2, authtag = e2.encrypt_and_digest(token.encode('utf-8'))

step3 = {
"transactionId": e,
"iv": base64.b64encode(t).decode('utf-8'),
"tag": base64.b64encode(authtag).decode("utf-8"),
"payload": base64.b64encode(e2).decode('utf-8')
}
step3 = json.dumps(step3)

headers = { 'Content-type': 'application/json', 'Accept': 'application/json' }
url = BASE_URL + AUTH_CREATE_SESSION
response = requests.post(url, data=step3, headers=headers)
response = json.loads(response.text)
sessionId = response['sessionId']

#create a new header with the new Session-ID for all further requests
headers = { 'Content-type': 'application/json', 'Accept': 'application/json', 'authorization': "Session " + sessionId }
url = BASE_URL + ME
response = requests.get(url = url, headers = headers)
response = json.loads(response.text)
authOK = response['authenticated']
if not authOK:
print("authorization NOT OK")
sys.exit()

url = BASE_URL + "/info/version"
response = requests.get(url = url, headers = headers)
response = json.loads(response.text)
swversion = response['sw_version']
apiversion = response['api_version']
hostname = response['hostname']
name = response['name']
print("Connected to the inverter " + name + "/" + hostname + " with SW-Version " + swversion + " and API-Version " + apiversion)

# Auth OK, now send your desired requests

url = BASE_URL + request

response = requests.get(url = url, headers = headers)
response = json.loads(response.text)

message = json.dumps(response)

#print(json.dumps(response, indent=4, sort_keys=True))
#print(message)

async def run():

try:
with open('/opt/fhem/python/pwd_fhem.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

fh = fhem.Fhem(web, protocol="http", port=8083, username=credentials["username"], password=credentials["password"])

fh.send_cmd("setreading PV_Anlage_1 statistics_output " + message)

asyncio.get_event_loop().run_until_complete(run())
</syntaxhighlight>

====== Userreadings ======
Die userreadings gehören zum Gerät PV_Anlage_1 .

statistics_output
Trigger: externes Python Skript
Das Python Skript beschreibt im Gerät PV_Anlage_1 das reading statistics_output, das dort dann weiterverarbeitet wird.

====== Passworte ======
Die Passworte für den Plenticore und den FHEM Zugang liegen in einzelnen JSON Dateien

fhem@raspberrypi:~/python$ cat pwd_plenticore.json
<pre>
{
"username": "user",
"password": "<Steht auf dem Gehäuse>"
}
</pre>

fhem@raspberrypi:~/python$ cat pwd_fhem.json
<pre>
{
"username": "<Ein Fhem Telnet User>",
"password": "<Das Passwort des Users>"
}
</pre>

===== Kostal Plenticore Plus die API (über HTTPMOD mit Python Skript Authentifizierung) =====
Der Plenticore erstellt intern noch diverse Statistiken, die auch über das WebGUI angesehen werden können. Diese werden jedoch nicht über MODBUS/TCP ausgegeben, aber zum Kostal Portal übermittelt, wo man dann bereits in Form von Diagrammen einen schönen Überblick bekommt. Das Ziel ist jedoch die Statistiken lokal im FHEM abzulegen, sie lassen sich nur über die API des Plenticore abfragen.
Für diesen API Zugang über HTTP steht nun ein neues Gerät zur Verfügung, dass mit HTTPMOD und Python Authentifizierungsskripten die mehrstufige Anmeldung durchführt. Das ganze soll in Zukunft den starren Zugriff auf die Statistiken ablösen und eine Erweiterung zum setzen von Parametern im Plenticore bieten.

====== Umstellungsaufwand ======
Die erste Folge für einen Umstieg wäre, dass die Statistiken nicht mehr im PV_Anlage_1 Gerät abgelegt werden, da diese ja teil der API Abfrage sind. Das muss dann in den Diagrammen und der Bilanz berücksichtigt werden, da die LogDb Einträge dann unter dem neuen PV_Anlage_1_API Gerät abgelegt werden.

====== Plenticore API ======
<syntaxhighlight lang="Perl">
http://<IP-Address_Plenticore>/api/v1
</syntaxhighlight>

====== Dateiverzeichnis ======
<pre>
/opt/fhem
/opt/fhem/python/pwd_fhem.json
/opt/fhem/python/pwd_plenticore.json
/opt/fhem/python/bin
/opt/fhem/python/bin/plenticore_finish.py
/opt/fhem/python/bin/plenticore_session.py
</pre>

====== Python 3 ======
<pre>
fhem@raspberrypi:~/python/bin$ which python3
/usr/bin/python3
fhem@raspberrypi:~/python/bin$ python3 --version
Python 3.7.3
</pre>

====== plenticore_auth_* Erläuterung ======
Die folgenden beiden Skripte sind ein Extrakt aus den bisherigen Skripten, ohne die HTTP Aufrufe. Sie dienen nur noch der Generierung von Authentifizierungsschlüsseln. Optimaler Weise müssten sie auch noch nach Perl konvertiert werden, was für später geplant ist.
Als Übergabeparameter werden aus dem PV_Anlage_1_API Gerät Rückgabewerte der HTTP Aufrufe verwendet.

====== plenticore_auth_finish ======
fhem@raspberrypi:~/python/bin$ cat plenticore_auth_finish.py
<syntaxhighlight lang="Python">
import string
import base64
import hashlib
import hmac
from Crypto.Cipher import AES
import binascii

import sys
import json
import fhem

web = sys.argv[1]
randomString = sys.argv[2]
nonce = sys.argv[3]
salt = sys.argv[4]
rounds = sys.argv[5]

try:
with open('/opt/fhem/python/pwd_plenticore.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

PASSWD = credentials["password"]

u = randomString

#u = base64.b64encode(u.encode('utf-8')).decode('utf-8')
#print("randomString: ",u)

i = nonce
o = int(rounds)
a = salt
bitSalt = base64.b64decode(a)

#print("nonce : ",i)
#print("salt : ",a)
#print("rounds : ",o)

def getPBKDF2Hash(password, bytedSalt, rounds):
return hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), bytedSalt, rounds)

r = getPBKDF2Hash(PASSWD,bitSalt,o)
s = hmac.new(r, "Client Key".encode('utf-8'), hashlib.sha256).digest()
c = hmac.new(r, "Server Key".encode('utf-8'), hashlib.sha256).digest()
_ = hashlib.sha256(s).digest()
d = "n=user,r="+u+",r="+i+",s="+a+",i="+str(o)+",c=biws,r="+i
g = hmac.new(_, d.encode('utf-8'), hashlib.sha256).digest()
p = hmac.new(c, d.encode('utf-8'), hashlib.sha256).digest()
f = bytes(a ^ b for (a, b) in zip(s, g))
proof = base64.b64encode(f).decode('utf-8')

try:
with open('/opt/fhem/python/pwd_fhem.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

fh = fhem.Fhem(web, protocol="http", port=8083, username=credentials["username"], password=credentials["password"])

fh.send_cmd("setreading PV_Anlage_1_API auth_proof " + proof)

#print("proof : ",proof)
</syntaxhighlight>
====== plenticore_auth_session ======
fhem@raspberrypi:~/python/bin$ cat plenticore_auth_session.py
<syntaxhighlight lang="Python">
import string
import base64
import hashlib
import os
import hmac
from Crypto.Cipher import AES
import binascii

import sys
import json
import fhem

web = sys.argv[1]
randomString = sys.argv[2]
nonce = sys.argv[3]
salt = sys.argv[4]
rounds = sys.argv[5]
token = sys.argv[6]

try:
with open('/opt/fhem/python/pwd_plenticore.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

PASSWD = credentials["password"]

u = randomString
i = nonce
o = int(rounds)
a = salt
bitSalt = base64.b64decode(a)

def getPBKDF2Hash(password, bytedSalt, rounds):
return hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), bytedSalt, rounds)

r = getPBKDF2Hash(PASSWD,bitSalt,o)

#print("randomString: ",u)
#print("nonce : ",i)
#print("salt : ",a)
#print("rounds : ",o)
#print("token : ",token)

s = hmac.new(r, "Client Key".encode('utf-8'), hashlib.sha256).digest()
_ = hashlib.sha256(s).digest()
d = "n=user,r="+u+",r="+i+",s="+a+",i="+str(o)+",c=biws,r="+i

y = hmac.new(_, "Session Key".encode('utf-8'), hashlib.sha256)
y.update(d.encode('utf-8'))
y.update(s)
P = y.digest()
protocol_key = P
t = os.urandom(16)

e2 = AES.new(protocol_key,AES.MODE_GCM,t)
e2, authtag = e2.encrypt_and_digest(token.encode('utf-8'))

iv = base64.b64encode(t).decode('utf-8')
authtag = base64.b64encode(authtag).decode("utf-8")
payload = base64.b64encode(e2).decode('utf-8')

try:
with open('/opt/fhem/python/pwd_fhem.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

fh = fhem.Fhem(web, protocol="http", port=8083, username=credentials["username"], password=credentials["password"])

fh.send_cmd("setreading PV_Anlage_1_API auth_iv " + iv)
fh.send_cmd("setreading PV_Anlage_1_API auth_authtag " + authtag)
fh.send_cmd("setreading PV_Anlage_1_API auth_payload " + payload)

#print("iv : ",iv)
#print("authtag : ",authtag)
#print("payload : ",payload)
</syntaxhighlight>

====== Ablaufbeschreibung PV_Anlage_1_API ======
Hier soll ein kurzer Überblick für den Anmeldeablauf geschaffen werden.
======Automatischer Login mit Sessionaufbau======
Der Ablauf startet mit dem ersten Aufruf und läuft dann vollautomatisch bis zur Rückgabe der auth_sessionId
1. get PV_Anlage_1_API 01/auth/start
* auth_randomString64 - wird generiert
* /api/v1/auth/start - HTTP request erfolgt
* auth_nonce, auth_salt, auth_rounds werden empfangen
2. auth_Step1_Message:auth_nonce.* wird getriggert
* plenticore_auth_finish.py wird ausgeführt
* auth_proof - wird berechnet
3. auth_Step2_Message:auth_proof.* wird getriggert
* Start von 02_/auth/finish
4. get PV_Anlage_1_API 02_/auth/finish
* /api/v1/auth/finish - HTTP request erfolgt
* auth_signature, auth_token werden empfangen
5. auth_Step3_Message:auth_token.* wird getriggert
* plenticore_auth_session.py wird ausgeführt
* auth_iv, auth_authtag, auth_payload - wird berechnet
6. auth_Step4_Message:auth_payload.* wird getriggert
* Start von 03_/auth/session
7. get PV_Anlage_1_API 03_/auth/session
* /api/v1/auth/session - HTTP request erfolgt
* auth_sessionId wird empfangen

Bei allen folgenden HTTP requests wird nun die erhaltene auth_sessenId übermittelt.
Bereits Implementierte Abfragen:
1. 04_/auth/me
2. 05_/info/version
3. 06_/auth/logout (läuft noch nicht)
4. 20_/processdata/scb_statistic_EnergyFlow
5. 21_Modules_List
Sollte die Session abgelaufen, oder noch kein Login vollzogen worden sein, so wird automatisch eine Login mit Sessionaufbau durchgeführt, jedoch wird bis auf /auth/me der letzte Aufruf nicht wiederholt. Dies liegt an dem momentan etwas komplexen Ablauf beim Sessionaufbau.

====== RAW Definition des PV_Anlage_1_API ======
<syntaxhighlight lang="Perl">
defmod PV_Anlage_1_API HTTPMOD http://%IP-Address_Plenticore%/api/v1/auth/me 0

attr PV_Anlage_1_API DbLogExclude .*
attr PV_Anlage_1_API authRetries 1
attr PV_Anlage_1_API dontRequeueAfterAuth 1
attr PV_Anlage_1_API enableControlSet 1
attr PV_Anlage_1_API enableCookies 1
attr PV_Anlage_1_API get01Data {"nonce": "%randomString64%","username": "user"}
attr PV_Anlage_1_API get01Name 01_/auth/start
attr PV_Anlage_1_API get01URL http://%IP-Address_Plenticore%/api/v1/auth/start
attr PV_Anlage_1_API get02Data {"transactionId": "%auth_transactionId%", "proof": "%auth_proof%"}
attr PV_Anlage_1_API get02Name 02_/auth/finish
attr PV_Anlage_1_API get02URL http://%IP-Address_Plenticore%/api/v1/auth/finish
attr PV_Anlage_1_API get03Data {"transactionId": "%auth_transactionId%", "iv": "%auth_iv%", "tag": "%auth_authtag%", "payload": "%auth_payload%"}
attr PV_Anlage_1_API get03Name 03_/auth/create_session
attr PV_Anlage_1_API get03URL http://%IP-Address_Plenticore%/api/v1/auth/create_session
attr PV_Anlage_1_API get04Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get04Name 04_/auth/me
attr PV_Anlage_1_API get04URL http://%IP-Address_Plenticore%/api/v1/auth/me
attr PV_Anlage_1_API get05Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get05Name 05_/info/version
attr PV_Anlage_1_API get05URL http://%IP-Address_Plenticore%/api/v1/info/version
attr PV_Anlage_1_API get06Name 06_/auth/logout
attr PV_Anlage_1_API get06URL http://%IP-Address_Plenticore%/api/v1/auth/logout
attr PV_Anlage_1_API get20Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get20Name 20_/processdata/scb_statistic_EnergyFlow
attr PV_Anlage_1_API get20URL http://%IP-Address_Plenticore%/api/v1/processdata/scb:statistic:EnergyFlow
attr PV_Anlage_1_API get21Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API get21Name 21_Modules_List
attr PV_Anlage_1_API get21URL http://%IP-Address_Plenticore%/api/v1/modules
attr PV_Anlage_1_API get22Header authorization: Session %auth_sessionId%
attr PV_Anlage_1_API getHeader01 Accept-Encoding: gzip,deflate
attr PV_Anlage_1_API getHeader02 Content-type:application/json, Accept:application/json, Connection:keep-alive
attr PV_Anlage_1_API group PV Eigenverbrauch
attr PV_Anlage_1_API icon sani_solar
attr PV_Anlage_1_API reAuthRegex "authenticated":false|"processdata":\[\]
attr PV_Anlage_1_API reading0100JSON anonymous
attr PV_Anlage_1_API reading0100Name auth_me_anonymous
attr PV_Anlage_1_API reading0101JSON role
attr PV_Anlage_1_API reading0101Name auth_me_role
attr PV_Anlage_1_API reading0102JSON active
attr PV_Anlage_1_API reading0102Name auth_me_active
attr PV_Anlage_1_API reading0103JSON locked
attr PV_Anlage_1_API reading0103Name auth_me_locked
attr PV_Anlage_1_API reading0104JSON authenticated
attr PV_Anlage_1_API reading0104Name auth_me_authenticated
attr PV_Anlage_1_API reading0105JSON salt
attr PV_Anlage_1_API reading0105Name auth_salt
attr PV_Anlage_1_API reading0106JSON transactionId
attr PV_Anlage_1_API reading0106Name auth_transactionId
attr PV_Anlage_1_API reading0107JSON rounds
attr PV_Anlage_1_API reading0107Name auth_rounds
attr PV_Anlage_1_API reading0108JSON nonce
attr PV_Anlage_1_API reading0108Name auth_nonce
attr PV_Anlage_1_API reading0109JSON token
attr PV_Anlage_1_API reading0109Name auth_token
attr PV_Anlage_1_API reading0110JSON message
attr PV_Anlage_1_API reading0111JSON signature
attr PV_Anlage_1_API reading0111Name auth_signature
attr PV_Anlage_1_API reading0112JSON sessionId
attr PV_Anlage_1_API reading0112Name auth_sessionId
attr PV_Anlage_1_API reading0200JSON api_version
attr PV_Anlage_1_API reading0200Name info_api_version
attr PV_Anlage_1_API reading0201JSON sw_version
attr PV_Anlage_1_API reading0201Name info_sw_version
attr PV_Anlage_1_API reading0202JSON name
attr PV_Anlage_1_API reading0202Name info_name
attr PV_Anlage_1_API reading0203JSON hostname
attr PV_Anlage_1_API reading0203Name info_hostname
attr PV_Anlage_1_API reading2001JSON 01_processdata_01_value
attr PV_Anlage_1_API reading2001Name Statistic_Autarky_Day
attr PV_Anlage_1_API reading2002JSON 01_processdata_02_value
attr PV_Anlage_1_API reading2002Name Statistic_Autarky_Month
attr PV_Anlage_1_API reading2003JSON 01_processdata_03_value
attr PV_Anlage_1_API reading2003Name Statistic_Autarky_Total
attr PV_Anlage_1_API reading2004JSON 01_processdata_04_value
attr PV_Anlage_1_API reading2004Name Statistic_Autarky_Year
attr PV_Anlage_1_API reading2011JSON 01_processdata_05_value
attr PV_Anlage_1_API reading2011Name Statistic_CO2Saving_Day
attr PV_Anlage_1_API reading2012JSON 01_processdata_06_value
attr PV_Anlage_1_API reading2012Name Statistic_CO2Saving_Month
attr PV_Anlage_1_API reading2013JSON 01_processdata_08_value
attr PV_Anlage_1_API reading2013Name Statistic_CO2Saving_Year
attr PV_Anlage_1_API reading2021JSON 01_processdata_09_value
attr PV_Anlage_1_API reading2021Name Statistic_EnergyHome_Day
attr PV_Anlage_1_API reading2022JSON 01_processdata_10_value
attr PV_Anlage_1_API reading2022Name Statistic_EnergyHome_Month
attr PV_Anlage_1_API reading2023JSON 01_processdata_11_value
attr PV_Anlage_1_API reading2023Name Statistic_EnergyHome_Total
attr PV_Anlage_1_API reading2024JSON 01_processdata_12_value
attr PV_Anlage_1_API reading2024Name Statistic_EnergyHome_Year
attr PV_Anlage_1_API reading2031JSON 01_processdata_13_value
attr PV_Anlage_1_API reading2031Name Statistic_EnergyHomeBat_Day
attr PV_Anlage_1_API reading2032JSON 01_processdata_14_value
attr PV_Anlage_1_API reading2032Name Statistic_EnergyHomeBat_Month
attr PV_Anlage_1_API reading2033JSON 01_processdata_15_value
attr PV_Anlage_1_API reading2033Name Statistic_EnergyHomeBat_Total
attr PV_Anlage_1_API reading2034JSON 01_processdata_16_value
attr PV_Anlage_1_API reading2034Name Statistic_EnergyHomeBat_Year
attr PV_Anlage_1_API reading2041JSON 01_processdata_17_value
attr PV_Anlage_1_API reading2041Name Statistic_EnergyHomeGrid_Day
attr PV_Anlage_1_API reading2042JSON 01_processdata_18_value
attr PV_Anlage_1_API reading2042Name Statistic_EnergyHomeGrid_Month
attr PV_Anlage_1_API reading2043JSON 01_processdata_19_value
attr PV_Anlage_1_API reading2043Name Statistic_EnergyHomeGrid_Total
attr PV_Anlage_1_API reading2044JSON 01_processdata_20_value
attr PV_Anlage_1_API reading2044Name Statistic_EnergyHomeGrid_Year
attr PV_Anlage_1_API reading2051JSON 01_processdata_21_value
attr PV_Anlage_1_API reading2051Name Statistic_EnergyHomePv_Day
attr PV_Anlage_1_API reading2052JSON 01_processdata_22_value
attr PV_Anlage_1_API reading2052Name Statistic_EnergyHomePv_Month
attr PV_Anlage_1_API reading2053JSON 01_processdata_23_value
attr PV_Anlage_1_API reading2053Name Statistic_EnergyHomePv_Total
attr PV_Anlage_1_API reading2054JSON 01_processdata_24_value
attr PV_Anlage_1_API reading2054Name Statistic_EnergyHomePv_Year
attr PV_Anlage_1_API reading2061JSON 01_processdata_25_value
attr PV_Anlage_1_API reading2061Name Statistic_OwnConsumptionRate_Day
attr PV_Anlage_1_API reading2062JSON 01_processdata_26_value
attr PV_Anlage_1_API reading2062Name Statistic_OwnConsumptionRate_Month
attr PV_Anlage_1_API reading2063JSON 01_processdata_27_value
attr PV_Anlage_1_API reading2063Name Statistic_OwnConsumptionRate_Total
attr PV_Anlage_1_API reading2064JSON 01_processdata_28_value
attr PV_Anlage_1_API reading2064Name Statistic_OwnConsumptionRate_Year
attr PV_Anlage_1_API reading2071JSON 01_processdata_29_value
attr PV_Anlage_1_API reading2071Name Statistic_Yield_Day
attr PV_Anlage_1_API reading2072JSON 01_processdata_30_value
attr PV_Anlage_1_API reading2072Name Statistic_Yield_Month
attr PV_Anlage_1_API reading2073JSON 01_processdata_31_value
attr PV_Anlage_1_API reading2073Name Statistic_Yield_Total
attr PV_Anlage_1_API reading2074JSON 01_processdata_32_value
attr PV_Anlage_1_API reading2074Name Statistic_Yield_Year
attr PV_Anlage_1_API replacement01Mode expression
attr PV_Anlage_1_API replacement01Regex %IP-Address_Plenticore%
attr PV_Anlage_1_API replacement01Value {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")}
attr PV_Anlage_1_API replacement02Mode reading
attr PV_Anlage_1_API replacement02Regex %auth_transactionId%
attr PV_Anlage_1_API replacement02Value auth_transactionId
attr PV_Anlage_1_API replacement03Mode reading
attr PV_Anlage_1_API replacement03Regex %auth_proof%
attr PV_Anlage_1_API replacement03Value auth_proof
attr PV_Anlage_1_API replacement04Mode expression
attr PV_Anlage_1_API replacement04Regex %randomString64%
attr PV_Anlage_1_API replacement04Value {my $NAME = "PV_Anlage_1_API" ;;;;fhem("deletereading ".$NAME." message");;;;fhem("deletereading ".$NAME." auth.*");;;;my @chars=('a'..'z','A'..'Z','0'..'9');; my $r;; foreach(1..16) {$r.=$chars[rand @chars];;};; fhem("setreading ".$NAME." auth_randomString64 ".$r);; $r;;}
attr PV_Anlage_1_API replacement05Mode reading
attr PV_Anlage_1_API replacement05Regex %auth_randomString64%
attr PV_Anlage_1_API replacement05Value auth_randomString64
attr PV_Anlage_1_API replacement06Mode reading
attr PV_Anlage_1_API replacement06Regex %auth_token%
attr PV_Anlage_1_API replacement06Value auth_token
attr PV_Anlage_1_API replacement07Mode reading
attr PV_Anlage_1_API replacement07Regex %auth_signature%
attr PV_Anlage_1_API replacement07Value auth_signature
attr PV_Anlage_1_API replacement08Mode reading
attr PV_Anlage_1_API replacement08Regex %auth_authtag%
attr PV_Anlage_1_API replacement08Value auth_authtag
attr PV_Anlage_1_API replacement09Mode reading
attr PV_Anlage_1_API replacement09Regex %auth_payload%
attr PV_Anlage_1_API replacement09Value auth_payload
attr PV_Anlage_1_API replacement10Mode reading
attr PV_Anlage_1_API replacement10Regex %auth_iv%
attr PV_Anlage_1_API replacement10Value auth_iv
attr PV_Anlage_1_API replacement11Mode reading
attr PV_Anlage_1_API replacement11Regex %auth_sessionId%
attr PV_Anlage_1_API replacement11Value auth_sessionId
attr PV_Anlage_1_API room Strom->Photovoltaik
attr PV_Anlage_1_API showBody 1
attr PV_Anlage_1_API showError 1
attr PV_Anlage_1_API sid01Data {"nonce": "%randomString64%","username": "user"}
attr PV_Anlage_1_API sid01ParseResponse 1
attr PV_Anlage_1_API sid01URL http://%IP-Address_Plenticore%/api/v1/auth/start
attr PV_Anlage_1_API sidHeader01 Accept-Encoding: gzip,deflate
attr PV_Anlage_1_API sidHeader02 Content-type: application/json, Accept: application/json, Connection: keep-alive
attr PV_Anlage_1_API sortby 02
attr PV_Anlage_1_API timeout 5
attr PV_Anlage_1_API userReadings auth_Step1_Message:auth_nonce.* {system("/usr/bin/python3 /opt/fhem/python/bin/plenticore_auth_finish.py ".ReadingsVal("PV_Anlage_1_config","IP-Address_FHEM","")." ".ReadingsVal("$NAME","auth_randomString64","")." ".ReadingsVal("$NAME","auth_nonce","")." ".ReadingsVal("$NAME","auth_salt","")." ".ReadingsVal("$NAME","auth_rounds","")." &");;;; "Prepare auth_finish started with auth_nonce ".ReadingsVal("$NAME","auth_nonce","")},\
\
auth_Step2_Message:auth_proof.* { fhem("get ".$NAME." 02_/auth/finish") ;;;; "HTTP Request 02_/auth/finish with auth_proof ".ReadingsVal("$NAME","auth_proof","")},\
\
auth_Step3_Message:auth_token.* {system("/usr/bin/python3 /opt/fhem/python/bin/plenticore_auth_session.py ".ReadingsVal("PV_Anlage_1_config","IP-Address_FHEM","")." ".ReadingsVal("$NAME","auth_randomString64","")." ".ReadingsVal("$NAME","auth_nonce","")." ".ReadingsVal("$NAME","auth_salt","")." ".ReadingsVal("$NAME","auth_rounds","")." ".ReadingsVal("$NAME","auth_token","")." &");;;; "Prepare auth_session started with auth_token ".ReadingsVal("$NAME","auth_token","")},\
\
auth_Step4_Message:auth_payload.* { fhem("get ".$NAME." 03_/auth/create_session") ;;;; "HTTP Request 03_/auth/create_session with auth_authtag ".ReadingsVal("$NAME","auth_authtag","")},\
\
auth_Step5_Message:auth_sessionId.* { fhem("get ".$NAME." 04_/auth/me") ;;;; "HTTP Request 04_/auth/me with auth_sessionId ".ReadingsVal("$NAME","auth_sessionId","")}
attr PV_Anlage_1_API verbose 0
</syntaxhighlight>

=== Kostal Smart Energy Manager (KSEM) (Modbus/TCP) ===
Diese Einbindung ist nicht zwingend notwendig, jedoch weil es möglich ist hier beschrieben.
Das Gerät ist hier mit "disable 1" konfiguriert, um es zu verwenden muss das Attribut auf 0 gesetzt oder einfach gelöscht werden.

Auch hier ist ein Interval von 60 Sekunden gesetzt worden. Das Logging ist noch komplett deaktiviert, weshalb man seine Werte noch selber definieren muss.

==== RAW Definition des KSEM ====
Zun Thema KSEM bestand direkter Kontakt mit dem Kostal Service. Der KSEM ermittelt nicht alle Werte, welche in der SunSpec spezifiziert sind. Alle nicht unterstützen Werte sind in den Registern mit 0x8000 gekennzeichnet. Für die nicht unterstützten Zählerstände wird 0x800000000 ausgegeben.
Der Summenstrom M_AC_Current (sum of active phases) kann aber durch den Endanwender selber aus der Summe der Einzelwerte (Phase A AC current, Phase B AC current Phase C AC current) berechnet werden. Die einzelnen Spannungen zwischen den Phasen können nicht gemessen werden und werden deshalb nicht ausgegeben.
<syntaxhighlight lang="Perl">
defmod PV_KSEM ModbusAttr 1 60 <IP-Address_KSEM>:502 TCP
attr PV_KSEM DbLogExclude .*
attr PV_KSEM alias PV_Energy_Manager
attr PV_KSEM dev-h-defPoll 1
attr PV_KSEM dev-type-INT16-len 1
attr PV_KSEM dev-type-INT16-unpack s>
attr PV_KSEM dev-type-INT16_Current-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Current_SF",0))
attr PV_KSEM dev-type-INT16_Current-format %.2f
attr PV_KSEM dev-type-INT16_Current-len 1
attr PV_KSEM dev-type-INT16_Current-unpack s>
attr PV_KSEM dev-type-INT16_Freq-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Freq_SF",0))
attr PV_KSEM dev-type-INT16_Freq-format %.2f
attr PV_KSEM dev-type-INT16_Freq-len 1
attr PV_KSEM dev-type-INT16_Freq-unpack s>
attr PV_KSEM dev-type-INT16_PF-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_PF_SF",0))
attr PV_KSEM dev-type-INT16_PF-format %.2f
attr PV_KSEM dev-type-INT16_PF-len 1
attr PV_KSEM dev-type-INT16_PF-unpack s>
attr PV_KSEM dev-type-INT16_Power-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Power_SF",0))
attr PV_KSEM dev-type-INT16_Power-format %.2f
attr PV_KSEM dev-type-INT16_Power-len 1
attr PV_KSEM dev-type-INT16_Power-unpack s>
attr PV_KSEM dev-type-INT16_VA-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_VA_SF",0))
attr PV_KSEM dev-type-INT16_VA-format %.2f
attr PV_KSEM dev-type-INT16_VA-len 1
attr PV_KSEM dev-type-INT16_VA-unpack s>
attr PV_KSEM dev-type-INT16_VAR-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_VAR_SF",0))
attr PV_KSEM dev-type-INT16_VAR-format %.2f
attr PV_KSEM dev-type-INT16_VAR-len 1
attr PV_KSEM dev-type-INT16_VAR-unpack s>
attr PV_KSEM dev-type-INT16_Voltage-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Voltage_SF",0))
attr PV_KSEM dev-type-INT16_Voltage-format %.2f
attr PV_KSEM dev-type-INT16_Voltage-len 1
attr PV_KSEM dev-type-INT16_Voltage-unpack s>
attr PV_KSEM dev-type-STR32-expr $val =~ s/[\00]+//gr
attr PV_KSEM dev-type-STR32-format %s
attr PV_KSEM dev-type-STR32-len 16
attr PV_KSEM dev-type-STR32-unpack a*
attr PV_KSEM dev-type-UINT16-format %s
attr PV_KSEM dev-type-UINT16-len 1
attr PV_KSEM dev-type-UINT32-format %s
attr PV_KSEM dev-type-UINT32-len 2
attr PV_KSEM dev-type-UINT64-expr $val/10000
attr PV_KSEM dev-type-UINT64-format %s
attr PV_KSEM dev-type-UINT64-len 4
attr PV_KSEM dev-type-UINT64-unpack Q>
attr PV_KSEM disable 1
attr PV_KSEM group PV Eigenverbrauch
attr PV_KSEM icon measure_power
attr PV_KSEM obj-h40072-reading M_AC_Current_A
attr PV_KSEM obj-h40072-type INT16_Current
attr PV_KSEM obj-h40073-reading M_AC_Current_B
attr PV_KSEM obj-h40073-type INT16_Current
attr PV_KSEM obj-h40074-reading M_AC_Current_C
attr PV_KSEM obj-h40074-type INT16_Current
attr PV_KSEM obj-h40075-reading M_AC_Current_SF
attr PV_KSEM obj-h40075-type INT16
attr PV_KSEM obj-h40077-reading M_AC_Voltage_AN
attr PV_KSEM obj-h40077-type INT16_Voltage
attr PV_KSEM obj-h40078-reading M_AC_Voltage_BN
attr PV_KSEM obj-h40078-type INT16_Voltage
attr PV_KSEM obj-h40079-reading M_AC_Voltage_CN
attr PV_KSEM obj-h40079-type INT16_Voltage
attr PV_KSEM obj-h40084-reading M_AC_Voltage_SF
attr PV_KSEM obj-h40084-type INT16
attr PV_KSEM obj-h40085-reading M_AC_Freq
attr PV_KSEM obj-h40085-type INT16_Freq
attr PV_KSEM obj-h40086-reading M_AC_Freq_SF
attr PV_KSEM obj-h40086-type INT16
attr PV_KSEM obj-h40087-reading M_AC_Power
attr PV_KSEM obj-h40087-type INT16_Power
attr PV_KSEM obj-h40088-reading M_AC_Power_A
attr PV_KSEM obj-h40088-type INT16_Power
attr PV_KSEM obj-h40089-reading M_AC_Power_B
attr PV_KSEM obj-h40089-type INT16_Power
attr PV_KSEM obj-h40090-reading M_AC_Power_C
attr PV_KSEM obj-h40090-type INT16_Power
attr PV_KSEM obj-h40091-reading M_AC_Power_SF
attr PV_KSEM obj-h40091-type INT16
attr PV_KSEM obj-h40092-reading M_AC_VA
attr PV_KSEM obj-h40092-type INT16_VA
attr PV_KSEM obj-h40093-reading M_AC_VA_A
attr PV_KSEM obj-h40093-type INT16_VA
attr PV_KSEM obj-h40094-reading M_AC_VA_B
attr PV_KSEM obj-h40094-type INT16_VA
attr PV_KSEM obj-h40095-reading M_AC_VA_C
attr PV_KSEM obj-h40095-type INT16_VA
attr PV_KSEM obj-h40096-reading M_AC_VA_SF
attr PV_KSEM obj-h40096-type INT16
attr PV_KSEM obj-h40097-reading M_AC_VAR
attr PV_KSEM obj-h40097-type INT16_VAR
attr PV_KSEM obj-h40098-reading M_AC_VAR_A
attr PV_KSEM obj-h40098-type INT16_VAR
attr PV_KSEM obj-h40099-reading M_AC_VAR_B
attr PV_KSEM obj-h40099-type INT16_VAR
attr PV_KSEM obj-h40100-reading M_AC_VAR_C
attr PV_KSEM obj-h40100-type INT16_VAR
attr PV_KSEM obj-h40101-reading M_AC_VAR_SF
attr PV_KSEM obj-h40101-type INT16
attr PV_KSEM obj-h40102-reading M_AC_PF
attr PV_KSEM obj-h40102-type INT16_PF
attr PV_KSEM obj-h40103-reading M_AC_PF_A
attr PV_KSEM obj-h40103-type INT16_PF
attr PV_KSEM obj-h40104-reading M_AC_PF_B
attr PV_KSEM obj-h40104-type INT16_PF
attr PV_KSEM obj-h40105-reading M_AC_PF_C
attr PV_KSEM obj-h40105-type INT16_PF
attr PV_KSEM obj-h40106-reading M_AC_PF_SF
attr PV_KSEM obj-h40106-type INT16
attr PV_KSEM obj-h40108-reading M_Exported
attr PV_KSEM obj-h40108-type UINT32
attr PV_KSEM obj-h40110-reading M_Exported_A
attr PV_KSEM obj-h40110-type UINT32
attr PV_KSEM obj-h40112-reading M_Exported_B
attr PV_KSEM obj-h40112-type UINT32
attr PV_KSEM obj-h40114-reading M_Exported_C
attr PV_KSEM obj-h40114-type UINT32
attr PV_KSEM obj-h40116-reading M_Imported
attr PV_KSEM obj-h40116-type UINT32
attr PV_KSEM obj-h40118-reading M_Imported_A
attr PV_KSEM obj-h40118-type UINT32
attr PV_KSEM obj-h40120-reading M_Imported_B
attr PV_KSEM obj-h40120-type UINT32
attr PV_KSEM obj-h40122-reading M_Imported_C
attr PV_KSEM obj-h40122-type UINT32
attr PV_KSEM obj-h40125-reading M_Exported_VA
attr PV_KSEM obj-h40125-type UINT32
attr PV_KSEM obj-h40127-reading M_Exported_VA_A
attr PV_KSEM obj-h40127-type UINT32
attr PV_KSEM obj-h40129-reading M_Exported_VA_B
attr PV_KSEM obj-h40129-type UINT32
attr PV_KSEM obj-h40131-reading M_Exported_VA_C
attr PV_KSEM obj-h40131-type UINT32
attr PV_KSEM obj-h40133-reading M_Imported_VA
attr PV_KSEM obj-h40133-type UINT32
attr PV_KSEM obj-h40135-reading M_Imported_VA_A
attr PV_KSEM obj-h40135-type UINT32
attr PV_KSEM obj-h40137-reading M_Imported_VA_B
attr PV_KSEM obj-h40137-type UINT32
attr PV_KSEM obj-h40139-reading M_Imported_VA_C
attr PV_KSEM obj-h40139-type UINT32
attr PV_KSEM obj-h512-reading Active_energy+
attr PV_KSEM obj-h512-type UINT64
attr PV_KSEM obj-h516-reading Active_energy-
attr PV_KSEM obj-h516-type UINT64
attr PV_KSEM obj-h8192-reading ManufacturerID
attr PV_KSEM obj-h8192-type UINT16
attr PV_KSEM obj-h8193-reading ProductID
attr PV_KSEM obj-h8193-type UINT16
attr PV_KSEM obj-h8194-reading ProductVersion
attr PV_KSEM obj-h8194-type UINT16
attr PV_KSEM obj-h8195-reading FirmwareVersion
attr PV_KSEM obj-h8195-type UINT16
attr PV_KSEM obj-h8196-reading VendorName
attr PV_KSEM obj-h8196-type STR32
attr PV_KSEM obj-h8212-reading Productname
attr PV_KSEM obj-h8212-type STR32
attr PV_KSEM obj-h8228-reading SerialNumber
attr PV_KSEM obj-h8228-type STR32
attr PV_KSEM obj-h8244-reading MeasuringInterval
attr PV_KSEM obj-h8244-type UINT16
attr PV_KSEM room Strom->Photovoltaik
attr PV_KSEM sortby 03
attr PV_KSEM userReadings M_AC_Current:M_AC_Current_.* { ReadingsVal($NAME,"M_AC_Current_A",0) + ReadingsVal($NAME,"M_AC_Current_B",0) + ReadingsVal($NAME,"M_AC_Current_C",0) }
attr PV_KSEM verbose 0
</syntaxhighlight>

=== BYD Speicher (über Python Skript) ===
Diese Einbindung ist nicht zwingend notwendig.
Ein Ziel ist es das Python Skript später zu entfernen und eine direkten HTTPMOD Abfrage zu implementieren.
==== byd_status.py ====
fhem@raspberrypi:~/python/bin$ cat byd_status.py
<syntaxhighlight lang="Python">
#
# Copyright: Kilian Knoll, 10.3.2019
#
# Utility to parse rundata values of BYD HV BOX
# Version 1.0
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
#
# Please note that any incorrect or careless usage of this module as well as errors in the implementation can damage your BYD box!
# Therefore, the author does not provide any guarantee or warranty concerning to correctness, functionality or performance and does not accept any liability for damage caused by this module, examples or mentioned information.
# Thus, use it at your own risk!
#
#
# Purpose:
# Query Rundata values from BYD box via local network connection
# Used with BYD HV 6.4
#
# Returnvalue: 0 (Everything all right)
# Returnvalue: -1 (Crap happened)
# BYDdata: (Empty list in case Returnvalue =-1)
# BYDdata: (Full list of key-value pairs in case Returnvalue = 0)
#
# Tested with
# BYD HV 6.4,
# Firmware verison V3.012 R
# python 3.6
#
# Changes:
# 2020.07.30 added fhem connectivity
# added sys for argument parsing; BYDboxIP and FHEM Web Interface are read from commandline
# password and username is read from file

import fhem

import sys
BYDboxIP = sys.argv[1]
web = sys.argv[2]

import requests
import time
import json

from pprint import pprint
from bs4 import BeautifulSoup
from requests.auth import HTTPBasicAuth
import logging

#from loggerdate import loggerdate

def getvaluefromsubstring (inputvalue):
# The input we pass looks like this:
#<input readonly="readonly" type="text" value="5186"/>
#Goal is to return value 5186 as outputvalue
#Not sure if BeautifulSoup could do more / better...
output_array= str(inputvalue)
A,B,C,outputvalue= output_array.split('=')
outputvalue, A= outputvalue.split('/')
A,outputvalue,B = outputvalue.split('"')
if ('%' in outputvalue):
outputvalue, A = outputvalue.split('%')
outputvalue = float(outputvalue)
return outputvalue

def readbyd():

#Please adjust the parameters below as appropriate for your environment:

# username and password are read from pwd_byd.json file ; BYDboxIP is parsed from sys commandline
#print ("Start reading Password file for BYD access....")
try:
with open('/opt/fhem/python/pwd_byd.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

#No configurable parameters beyond this point

mySession = requests.Session()
try:
BYDdata={}
#The two stupid lines below took me almost a day...
#You can access other pages on the BYD WEB-Page - calling other asp scripts
url='http://'+BYDboxIP+'/asp/RunData.asp'
r4 = mySession.get(url, auth=HTTPBasicAuth(credentials["username"],credentials["password"]))
if (r4.status_code == 200):
page = r4.text
soup = BeautifulSoup(page, 'html.parser')
soup_ele = soup.body.form.table #This gets us the RunData Table and Array Num 1 values - using this approach
soup_reduced = soup_ele.find_all('input',attrs={"type": "text"} ) #Using this option now since BYD introduced some glitches with Firmware 3.012R on their html code..
# It now contains a list of the following kind
#<input readonly="readonly" type="text" value="19.300"/>
#print (soup_reduced)
#print ("ERSTES ELE", soup_reduced[1])
Keyvalue=[]
for elems in soup_reduced:
elems=str(elems)
myarray= elems.split('=')
CurValue=myarray[3].split('"')
Keyvalue.append(CurValue[1])

BYDdata["arrayvoltage"]= float(Keyvalue[0])
BYDdata["packvoltage"] = float(Keyvalue[1])
BYDdata["current"] = float(Keyvalue[2])
BYDdata["soc"] = (Keyvalue[3])
BYDdata["sysTemp"] = Keyvalue[4]
BYDdata["maxcellvol"] = float(Keyvalue[5])
BYDdata["mincellvol"] = float(Keyvalue[6])
BYDdata["maxcelltemp"] = float(Keyvalue[7])
BYDdata["mincelltemp"] = float(Keyvalue[8])
BYDdata["maxvolpos"] = int(Keyvalue[9])
BYDdata["minvolpos"] = Keyvalue[10]
BYDdata["maxtemppos"] = Keyvalue[11]
BYDdata["mintemppos"] = Keyvalue[12]
BYDdata["power"] = Keyvalue[13]
"""
# Oh well - with Firmware 3.012R, these values have disappeared from the BYD web pages...
BYDdata["soc"] = Keyvalue[3]
BYDdata["socwh"] = Keyvalue[4]
BYDdata["socah"] = Keyvalue[5]
BYDdata["soh"] = Keyvalue[6]
"""

Error_Connecting = 0

else:
print ("Not sure if we are able to connect with the given username & password - error code is:", r4.status_code)
print ("Header information passed is :", r4.headers)
Error_Connecting = r4.status_code

url='http://'+BYDboxIP+'/asp/StatisticInformation.asp'
r2 = mySession.get(url, auth=HTTPBasicAuth(credentials["username"],credentials["password"]))
if ((r2.status_code == 200) and (Error_Connecting == 0)):
page = r2.text
soup = BeautifulSoup(page, 'html.parser')
soup_ele = soup.body.table
#print (soup_ele)
#print ("--------------------------------------------------------")
#<input readonly="readonly" type="text" value="5186"/>
soup_reduced = soup_ele.find_all('input')
#print (soup_reduced)
#print ("soup_ele", soup_ele)
i = 0
a= len(soup_ele.contents)
total_charge_energy = soup_ele.find("td", text="Total Charge Energy:").find_next_sibling("td").text
total_charge_energy,b = (total_charge_energy.split())
total_charge_energy = float(total_charge_energy)
#print ("Total Charge Energy :", total_charge_energy)
BYDdata["Total_Charge_Energy"]= total_charge_energy

total_discharge_energy = soup_ele.find("td", text="Total Discharge Energy:").find_next_sibling("td").text
total_discharge_energy,b = (total_discharge_energy.split())
total_discharge_energy = float(total_discharge_energy)
#print ("Total Discharge Energy :", total_discharge_energy)
BYDdata["Total_Discharge_Energy"] = total_discharge_energy

total_cycle_counts = soup_ele.find("td", text="Total Cycle Counts:").find_next_sibling("td").text
#total_cycle_counts,b = (total_cycle_counts.split())
total_cycle_counts = float(total_cycle_counts)
#print ("Total Cycle Counts :", total_cycle_counts)
BYDdata["Total_Cycle_Counts"] = total_cycle_counts
else:
print ("Not sure if we are able to connect with the given username & password - error code is:", r4.status_code)
print ("Header information passed is :", r2.headers)
Error_Connecting = r2.status_code

except Exception as Connecterror:
print ("Error connecting to the BYD box :", Connecterror)
#logging.error("%s %s %s", loggerdate(), ",readbyd: Ran into exception querying the BYD Box : ", Connecterror)
Error_Connecting = Connecterror
if (Error_Connecting == 0):
if (len(BYDdata) >1): # We have something in the list

Returnvalue =0
else: # We ran into trouble and allocate an empty list
BYDdata={}
print ("Issue getting data from BYD ", Error_Connecting)

return (Returnvalue, BYDdata)

if __name__ == "__main__":

#print ("Start querying BYD....")
try:
Myreturnvalue, Mydata = readbyd();
if (Myreturnvalue == 0):
#print ("Returnvalue -should be zero if successful : ", Myreturnvalue)
#print ("----------------Start Values BYD ----------------")
#pprint (Mydata)
#print ("----------------End - Values from BYD ----------------")
#print ("Specific values from array....")
#print ("BYD Total Charge Energy :", Mydata['Total_Charge_Energy'], "Kwh")
#print ("BYD Total Discharge Energy :", Mydata['Total_Discharge_Energy'], "Kwh")
#print ("Calculations...")
#print ("Charging (+) / Discharging (-) Energy :", round(Mydata['packvoltage']*Mydata['current'],0), "W")
#print ("Efficiency is :",round(Mydata['Total_Discharge_Energy']/Mydata['Total_Charge_Energy'],3))
#print (Mydata)

message = json.dumps(Mydata)

#print ("Start reading Password file for FHEM access....")
try:
with open('/opt/fhem/python/pwd_fhem.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

#print ("Start login to FHEM ....")
fh = fhem.Fhem(web, protocol="http", port=8083, username=credentials["username"], password=credentials["password"])

#print ("Start transfer of data to FHEM ....")
fh.send_cmd("setreading BYD_Status output " + message)

else:
print ("Error unable to query BYD Box")
except Exception as ex:
print ("Issues querying BYD Box :", ex)
</syntaxhighlight>

====== Userreadings ======
Die Userreadings gehören zum Gerät BYD_Status .

output
Trigger: externes Python Skript
Das Python Skript beschreibt im Gerät BYD_Status das reading output, das dort dann weiter verarbeitet wird.

====== Passworte ======
Das Passwort für den BYD Speicher liegt in einer JSON Datei

fhem@raspberrypi:~/python$ cat pwd_byd.json
<pre>
{
"username": "installer",
"password": "<Steht in der BYD Dokumentation>"
}
</pre>
==== RAW Definition BYD_Status ====
<syntaxhighlight lang="Perl">
defmod BYD_Status expandJSON BYD_Status:output:.\{.*}
attr BYD_Status DbLogExclude .*
attr BYD_Status alias BYD_Status
attr BYD_Status comment Das Device wird über ein Python Skript im reading output befüllt.\
deletereading BYD_Status [min|max|cur|array|Total|pack|power|soc|sys].*\

attr BYD_Status group PV Eigenverbrauch
attr BYD_Status icon measure_battery_50
attr BYD_Status room Strom->Photovoltaik,Strom->System
attr BYD_Status sortby 02
</syntaxhighlight>
== Timeing für die PV extra Funktionen ==
=== RAW Definition PV_Schedule (DOIF) ===
<syntaxhighlight lang="Perl">
defmod PV_Schedule DOIF ################################################################################################################\
## 1 BYD Status aktualisieren\
##\
([+:05] and !([:00] or [:30]))\
(\
{system("/usr/bin/python3 /opt/fhem/python/bin/byd_status.py ".ReadingsVal("BYD_Status","IP-Address_BYD","?")." ".ReadingsVal("BYD_Status","IP-Address_FHEM","?")." &")}\
)\
################################################################################################################\
## 2 Plenticore Status aktualisieren\
##\
DOELSEIF\
([:57])\
(\
{system("/usr/bin/python3 /opt/fhem/python/bin/plenticore_statistic.py ".ReadingsVal("PV_Anlage_1","IP-Address_Plenticore","?")." ".ReadingsVal("PV_Anlage_1","IP-Address_FHEM","?")." &")}\
set Dum.Energy update\
\
)\
################################################################################################################\
## 3 DWD Prognose aktualisieren, die Daten stehen immer verzögert zur Verfügung.\
##\
DOELSEIF\
([06:37] or [11:37] or [17:37] or [00:37])\
(\
{system("/usr/bin/python3 /opt/fhem/python/bin/dwd_get_forecast.py ".ReadingsVal("PV_Anlage_1","IP-Address_FHEM","?")." ".ReadingsVal("PV_Anlage_1","Solar_Station","?")." &")}\
)\
\
################################################################################################################\
## 4 PV Prognose vom aktuellen Tag aktualisieren\
## zwischen 7 und 19 Uhr zur vollen Stunde\
DOELSEIF\
([07:00-19:00] and [:00])\
(\
{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","ESW","DWD_Prognose","ProPlanta",0)}\
)\
################################################################################################################\
## 5 PV Prognose für den nächsten Tag aktualisieren\
## \
DOELSEIF\
([09:11])\
(\
{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","ESW","DWD_Prognose","ProPlanta",1)}\
)\

attr PV_Schedule DbLogExclude .*
attr PV_Schedule alias PV_Schedule
attr PV_Schedule cmdState BYD Status|Plenticore Status
attr PV_Schedule do always
attr PV_Schedule room Strom->System
attr PV_Schedule sortby 11
attr PV_Schedule wait 0:0:0:10:0:0
</syntaxhighlight>

== Energie Bilanz ==
=== RAW Definition Energiebilanz ===
<syntaxhighlight lang="Perl">
defmod Dum.Energy dummy
attr Dum.Energy DbLogExclude .*
attr Dum.Energy DbLogInclude Autarky.*,GridFeed.*,PV.*,.*Consumption.*
attr Dum.Energy alias Energiebilanz
attr Dum.Energy comment TotalConsumption,AutarkyQuoteDay,SelfConsumptionQuoteDay,AutarkyQuoteMonth,SelfConsumptionQuoteMonth
attr Dum.Energy event-on-change-reading PV,GridConsumption,GridFeedIn,SelfConsumptionQuote,Autarky.*,GridFeed.*,PV.*,.*Consumption.*
attr Dum.Energy event-on-update-reading TotalConsumption,AutarkyQuoteDay,SelfConsumptionQuoteDay,AutarkyQuoteMonth,SelfConsumptionQuoteMonth
attr Dum.Energy group Energiebilanz
attr Dum.Energy icon measure_power_meter
attr Dum.Energy room Strom->Energie
attr Dum.Energy stateFormat {\
my $pvt = ReadingsVal("$name","PVTotal", "")." W";;\
my $pvtd = ReadingsVal("$name","PVTotalDay", "")." kWh";;\
my $pvtm = ReadingsVal("$name","PVTotalMonth", "")." kWh";;\
my $pvty = ReadingsVal("$name","PVTotalYear", "")." kWh";;\
\
my $pv = ReadingsVal("$name","PV", "")." W";;\
my $pvd = ReadingsVal("$name","PVDay", "")." kWh";;\
my $pvm = ReadingsVal("$name","PVMonth", "")." kWh";;\
my $pvy = ReadingsVal("$name","PVYear", "")." kWh";;\
\
my $gfi = ReadingsVal("$name","GridFeedIn", "")." W";;\
my $gfid = ReadingsVal("$name","GridFeedInDay", "")." kWh";;\
my $gfim = ReadingsVal("$name","GridFeedInMonth", "")." kWh";;\
my $gfiy = ReadingsVal("$name","GridFeedInYear", "")." kWh";;\
my $eb = ReadingsVal("$name","GridConsumption", "")." W";;\
my $ebd = ReadingsVal("$name","GridConsumptionDay", "")." kWh";;\
my $ebm = ReadingsVal("$name","GridConsumptionMonth", "")." kWh";;\
my $eby = ReadingsVal("$name","GridConsumptionYear", "")." kWh";;\
my $et = ReadingsVal("$name","TotalConsumption", "")." W";;\
my $etd = ReadingsVal("$name","TotalConsumptionDay", "")." kWh";;\
my $etm = ReadingsVal("$name","TotalConsumptionMonth", "")." kWh";;\
my $ety = ReadingsVal("$name","TotalConsumptionYear", "")." kWh";;\
my $aq = ReadingsVal("$name","AutarkyQuote", "")." %";;\
my $aqd = ReadingsVal("$name","AutarkyQuoteDay", "")." %";;\
my $aqm = ReadingsVal("$name","AutarkyQuoteMonth", "")." %";;\
my $aqy = ReadingsVal("$name","AutarkyQuoteYear", "")." %";;\
my $sq = ReadingsVal("$name","SelfConsumptionQuote", "")." %";;\
my $sqd = ReadingsVal("$name","SelfConsumptionQuoteDay", "")." %";;\
my $sqm = ReadingsVal("$name","SelfConsumptionQuoteMonth", "")." %";;\
my $sqy = ReadingsVal("$name","SelfConsumptionQuoteYear", "")." %";;\
my $md = ReadingsTimestamp("$name", "AutarkyQuote", "");;\
my $cd = ReadingsTimestamp("PV_Anlage_1", "Statistic_Autarky_Day", "");;\
my $cm = ReadingsTimestamp("PV_Anlage_1", "Statistic_Autarky_Month", "");;\
my $cy = ReadingsTimestamp("PV_Anlage_1", "Statistic_Autarky_Year", "");;\
"<html><table border=2 bordercolor='darkgreen' cellspacing=0>\
<tr><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'> </td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>aktueller Wert</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>Heute</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>dieser Monat</td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'>dieses Jahr</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>PV-Erzeugung-Total</td><td style='padding-right:5px;;padding-left:5px'>".$pvt."</td><td style='padding-right:5px;;padding-left:5px'>".$pvtd."</td><td style='padding-right:5px;;padding-left:5px'>".$pvtm."</td><td style='padding-right:5px;;padding-left:5px'>".$pvty."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>PV-Einspeisung</td><td style='padding-right:5px;;padding-left:5px'>".$gfi."</td><td style='padding-right:5px;;padding-left:5px'>".$gfid."</td><td style='padding-right:5px;;padding-left:5px'>".$gfim."</td><td style='padding-right:5px;;padding-left:5px'>".$gfiy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Netz-Bezug</td><td style='padding-right:5px;;padding-left:5px'>".$eb."</td><td style='padding-right:5px;;padding-left:5px'>".$ebd."</td><td style='padding-right:5px;;padding-left:5px'>".$ebm."</td><td style='padding-right:5px;;padding-left:5px'>".$eby."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>PV-Bezug</td><td style='padding-right:5px;;padding-left:5px'>".$pv."</td><td style='padding-right:5px;;padding-left:5px'>".$pvd."</td><td style='padding-right:5px;;padding-left:5px'>".$pvm."</td><td style='padding-right:5px;;padding-left:5px'>".$pvy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Energieverbrauch</td><td style='padding-right:5px;;padding-left:5px'>".$et."</td><td style='padding-right:5px;;padding-left:5px'>".$etd."</td><td style='padding-right:5px;;padding-left:5px'>".$etm."</td><td style='padding-right:5px;;padding-left:5px'>".$ety."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Autarkiequote</td><td style='padding-right:5px;;padding-left:5px'>".$aq."</td><td style='padding-right:5px;;padding-left:5px'>".$aqd."</td><td style='padding-right:5px;;padding-left:5px'>".$aqm."</td><td style='padding-right:5px;;padding-left:5px'>".$aqy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Eigenverbrauchsquote</td><td style='padding-right:5px;;padding-left:5px'>".$sq."</td><td style='padding-right:5px;;padding-left:5px'>".$sqd."</td><td style='padding-right:5px;;padding-left:5px'>".$sqm."</td><td style='padding-right:5px;;padding-left:5px'>".$sqy."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Berechnung am</td><td style='padding-right:5px;;padding-left:5px'>".$md."</td><td style='padding-right:5px;;padding-left:5px'>".$cd."</td><td style='padding-right:5px;;padding-left:5px'>".$cm."</td><td style='padding-right:5px;;padding-left:5px'>".$cy."</td></tr>\
</table></html>"\
}
attr Dum.Energy userReadings PVTotal {round(ReadingsVal("PV_Anlage_1","Total_AC_active_power",""),0)},\
PVTotalDay {round( ReadingsVal("PV_Anlage_1","Statistic_Yield_Day", "")/1000 ,2)},\
PVTotalMonth {round( ReadingsVal("PV_Anlage_1","Statistic_Yield_Month", "")/1000 ,2)},\
PVTotalYear {round( ReadingsVal("PV_Anlage_1","Statistic_Yield_Year", "")/1000 ,2)},\
\
PV {round( ReadingsVal("PV_Anlage_1","Home_own_consumption_from_battery", "")+ReadingsVal("PV_Anlage_1","Home_own_consumption_from_PV", "") ,0)},\
PVDay {round( (ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeBat_Day", "")+ReadingsVal("PV_Anlage_1","Statistic_EnergyHomePv_Day", ""))/1000 ,2)},\
PVMonth {round( (ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeBat_Month", "")+ReadingsVal("PV_Anlage_1","Statistic_EnergyHomePv_Month", ""))/1000 ,2)},\
PVYear {round( (ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeBat_Year", "")+ReadingsVal("PV_Anlage_1","Statistic_EnergyHomePv_Year", ""))/1000 ,2)},\
\
GridFeedIn { ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0)<=0 ? abs(round(ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0),0)) : 0 },\
GridFeedInDay {round((ReadingsVal("PV_Anlage_1","Statistic_Yield_Day", "")-ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeBat_Day", "")-ReadingsVal("PV_Anlage_1","Statistic_EnergyHomePv_Day", ""))/1000,2)},\
GridFeedInMonth {round((ReadingsVal("PV_Anlage_1","Statistic_Yield_Month", "")-ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeBat_Month", "")-ReadingsVal("PV_Anlage_1","Statistic_EnergyHomePv_Month", ""))/1000,2)},\
GridFeedInYear {round((ReadingsVal("PV_Anlage_1","Statistic_Yield_Year", "")-ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeBat_Year", "")-ReadingsVal("PV_Anlage_1","Statistic_EnergyHomePv_Year", ""))/1000,2)},\
\
GridConsumption { ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0)>=0 ? round(ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0),0) : 0 },\
GridConsumptionDay {round(abs(ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeGrid_Day",""))/1000 ,2)},\
GridConsumptionMonth {round(ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeGrid_Month","")/1000 ,2)},\
GridConsumptionYear {round(ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeGrid_Year","")/1000 ,2)},\
\
TotalConsumption {round((ReadingsVal("PV_Anlage_1","Home_own_consumption_from_PV","")+ReadingsVal("PV_Anlage_1","Home_own_consumption_from_battery","")+ReadingsVal("PV_Anlage_1","Home_own_consumption_from_grid","")),0)},\
\
TotalConsumptionDay {round( (ReadingsVal("PV_Anlage_1","Statistic_EnergyHomePv_Day","")+ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeBat_Day","")+ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeGrid_Day","") )/1000 ,2)},\
TotalConsumptionMonth {round( (ReadingsVal("PV_Anlage_1","Statistic_EnergyHomePv_Month","")+ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeBat_Month","")+ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeGrid_Month","") )/1000 ,2)},\
TotalConsumptionYear {round( (ReadingsVal("PV_Anlage_1","Statistic_EnergyHomePv_Year","")+ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeBat_Year","")+ReadingsVal("PV_Anlage_1","Statistic_EnergyHomeGrid_Year","") )/1000,2)},\
\
AutarkyQuote {my $valA = ReadingsVal("PV_Anlage_1", "Total_AC_active_power","")-ReadingsVal("PV_Anlage_1", "Home_own_consumption_from_grid","");; my $calcVal = ($valA > 0)?round($valA /($valA + ReadingsVal("PV_Anlage_1", "Home_own_consumption_from_grid",""))*100 ,0) : 0 ;; ($calcVal > 100)?100:$calcVal },\
AutarkyQuoteDay {round(ReadingsVal("PV_Anlage_1","Statistic_Autarky_Day", ""),0)},\
AutarkyQuoteMonth {round(ReadingsVal("PV_Anlage_1","Statistic_Autarky_Month", ""),0)},\
AutarkyQuoteYear {round(ReadingsVal("PV_Anlage_1","Statistic_Autarky_Year", ""),0)},\
\
SelfConsumptionQuote {my $valS = ReadingsVal("PV_Anlage_1","Total_AC_active_power", 0) ;; my $calcVal = ($valS > 0)?round((ReadingsVal("PV_Anlage_1","Home_own_consumption_from_PV", "0") + ReadingsVal("PV_Anlage_1","Home_own_consumption_from_battery","0")) / $valS * 100 ,0) : 0 ;; ($calcVal > 100)?100:$calcVal},\
SelfConsumptionQuoteDay {round(ReadingsVal("PV_Anlage_1","Statistic_OwnConsumptionRate_Day", ""),0)},\
SelfConsumptionQuoteMonth {round(ReadingsVal("PV_Anlage_1","Statistic_OwnConsumptionRate_Month", ""),0)},\
SelfConsumptionQuoteYear {round(ReadingsVal("PV_Anlage_1","Statistic_OwnConsumptionRate_Year", ""),0)}
</syntaxhighlight>

=== Erstellen von zusätzlichen Werten in der Datenbank ===
Hier werden Werte konsolidiert, weil z.B. der Wert PV_total_Month stetig steigt. Am Ende des Monats sind die gesamten Zwischenwerte ohne Aussagekraft.

==== RAW Definition LogDBRep_PV_total_diff_Week ====
<syntaxhighlight lang="Perl">
defmod LogDBRep_PV_total_diff_Week DbRep LogDB
attr LogDBRep_PV_total_diff_Week DbLogExclude .*
attr LogDBRep_PV_total_diff_Week aggregation week
attr LogDBRep_PV_total_diff_Week allowDeletion 0
attr LogDBRep_PV_total_diff_Week device Dum.Energy
attr LogDBRep_PV_total_diff_Week reading PVTotalMonth
attr LogDBRep_PV_total_diff_Week room Strom->Energie,System
attr LogDBRep_PV_total_diff_Week timestamp_begin previous_month_begin
attr LogDBRep_PV_total_diff_Week timestamp_end previous_week_end
</syntaxhighlight>
==== RAW Definition LogDBRep_PV_total_max_Month ====
<syntaxhighlight lang="Perl">
defmod LogDBRep_PV_total_max_Month DbRep LogDB
attr LogDBRep_PV_total_max_Month DbLogExclude .*
attr LogDBRep_PV_total_max_Month aggregation month
attr LogDBRep_PV_total_max_Month allowDeletion 0
attr LogDBRep_PV_total_max_Month device Dum.Energy
attr LogDBRep_PV_total_max_Month reading PVTotalMonth
attr LogDBRep_PV_total_max_Month room Strom->Energie,System
attr LogDBRep_PV_total_max_Month timestamp_begin previous_month_begin
attr LogDBRep_PV_total_max_Month timestamp_end previous_day_end
</syntaxhighlight>
==== RAW Definition LogDBRep_PV_used_diff_Week ====
<syntaxhighlight lang="Perl">
defmod LogDBRep_PV_used_diff_Week DbRep LogDB
attr LogDBRep_PV_used_diff_Week DbLogExclude .*
attr LogDBRep_PV_used_diff_Week aggregation week
attr LogDBRep_PV_used_diff_Week allowDeletion 0
attr LogDBRep_PV_used_diff_Week device Dum.Energy
attr LogDBRep_PV_used_diff_Week reading PVMonth
attr LogDBRep_PV_used_diff_Week room Strom->Energie,System
attr LogDBRep_PV_used_diff_Week timestamp_begin previous_month_begin
attr LogDBRep_PV_used_diff_Week timestamp_end previous_week_end
</syntaxhighlight>
==== RAW Definition LogDBRep_PV_used_max_Month ====
<syntaxhighlight lang="Perl">
defmod LogDBRep_PV_used_max_Month DbRep LogDB
attr LogDBRep_PV_used_max_Month DbLogExclude .*
attr LogDBRep_PV_used_max_Month aggregation month
attr LogDBRep_PV_used_max_Month allowDeletion 0
attr LogDBRep_PV_used_max_Month device Dum.Energy
attr LogDBRep_PV_used_max_Month reading PVMonth
attr LogDBRep_PV_used_max_Month room Strom->Energie,System
attr LogDBRep_PV_used_max_Month timestamp_begin previous_month_begin
attr LogDBRep_PV_used_max_Month timestamp_end previous_month_end
</syntaxhighlight>

=== Timing für die Datenbank Einträge ===
<syntaxhighlight lang="Perl">
defmod DF_DB_Service DOIF ## Monatlich Einträge\
([01:13] and ($mday==1))(\
set LogDBRep_PV_used_max_Month maxValue writeToDB;;\
set LogDBRep_PV_total_max_Month maxValue writeToDB\
)\
## Wöchentliche Einträge\
DOELSEIF\
([01:17] and ($wday==1))(\
set LogDBRep_PV_used_diff_Week diffValue writeToDB;;\
set LogDBRep_PV_total_diff_Week diffValue writeToDB\
)\

attr DF_DB_Service DbLogExclude .*
attr DF_DB_Service do always
attr DF_DB_Service room System
</syntaxhighlight>

=== Löschen von nicht mehr benötigten Werten in der Datenbank ===
Hier wird endgültig aufgeräumt, alte momentan Werte werden gelöscht, wenn sie nach z.B. drei Monaten keine Relevanz mehr haben. Dafür wurden im vorherigen Abschnitt zusätzliche Werte in der Datenbank erzeugt, die in Diagrammen trotzdem noch einen trend erkennen lassen.
Wen eine immer größer werdende Datenbank mit steigenden Antwortzeiten nicht stört, der kann das Aufräumen auch weg lassen. Bei einer späteren Migration führt dies natürlich zu höherem Aufwand und hohen Laufzeiten.
<syntaxhighlight lang="Perl">
</syntaxhighlight>

== Wetter-/Leistungs-Prognose ==
Dies ist ein Thema, dass nicht wirklich gut zu fassen ist und ist eher etwas für Enthusiasten :-), wer schon mal mit Sonne, Wolken und Regen gerechnet hat versteht was ich meine. Dieser Ansatz ist nicht wissenschaftlicher Art und hat auch keinen Anspruch mathematischer Perfektion. Nach reinem Gefühl und mit aus dem Fenster schauen kommt jedoch ein respektables Ergebnis dabei heraus. Viel Vergnügen und Spaß beim mitbasteln ;-)
[[Bild:Plenticore_Forecast_Tagesanfang.png|mini|900px|rechts|Wenn der Tag begonnen hat ist die Prognose vom Vortag bereits im Diagramm. Der Wert Calculation in schwarz ist die aktuelle Korrektur.]]
=== Deutscher Wetter Dienst (DWD) ===
Der DWD liefert über Mosmix kostenlos, stunden aktuelle Prognosedaten. Über einen Link am Ende dieser Seite kommt man zum "Photovoltaikforum", wo dieses Thema erarbeitet wurde, weshalb ich es hier nicht wiederholen möchte.
Über Mosmix werden für diese Anwendung die Werte Rad1h und TTT bezogen, was der globalen Sonneneinstrahlung und der Temperatur entspricht.
Die Daten werden ins Gerät "DWD_Prognose" in das reading "output" als JSON String geschrieben und dort in readings ausgepackt.
Der Trigger erfolgt über das DOIF PV_Schedule , die Abholzeiten muss man noch auf die eigenen Belange anpassen, damit man nicht abholt bevor die Daten vom DWD bereit stehen. Hier gibt es oftmals Verzögerungen von über einer Stunde, was man auf dem FTP Server am Zeitstempel sehen kann. Auch hier bitte nicht zu oft abholen, damit die Server nicht überlastet werden.
==== Daten abholen und auspacken ====
fhem@raspberrypi:~/python/bin$ cat dwd_get_forecast.py
<syntaxhighlight lang="Python">
#
# Copyright (C) 2020 Kilian Knoll kilian.knoll@gmx.de
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
# Purpose
#Extract weather forecast data from DWD Mosmix for a given Station ID
#
# Background information:
# DWD provides 10 day forecast weather - and radiation data at an hourly resolution for over 5000 Stations worldwide (focus is on Germany/Europe though...)
# Description of kml file:
#https://www.dwd.de/DE/leistungen/opendata/help/schluessel_datenformate/kml/mosmix_elemente_pdf.pdf?__blob=publicationFile&v=3
#
#List of available stations:
#https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/mosmix_stationskatalog.cfg?view=nasPublication&nn=495490
#
# How to use this ?
# 1) Find the station close by your geographic location:
# Go to the website below, zoom to your location - and click on "Mosmix Stationen anzeigen"
# Once you found the closest station, please change the station number to the station number
# https://wettwarn.de/mosmix/mosmix.html
# In my case, I picked Station P755 (which is close to Munich)
# 2) Make changes in code below to reflect your station number - and the corresponding URL
# change
# self.mystation = P755
# below to the one you identified during step 1
# change the URL further down below to reflect the station:
# self.urlpath = 'https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_L/single_stations/P755/kml'
# Your one time setup is done...
#
# Implementation
# DWD provides two types of kml files
# single station kml files. These get updated approx every 6 hours
# all stations. These get updated hourly. However the file is pretty large. On embedded systems such as raspberry pi, I ran out of memory trying to parse XML files that size (exceeded 1GB of memory). Hence the decision to use the single station files
# we are only looking for a couple of key parameters that are relevant
#Currently the following Parameters get extracted from the kml file and put into a twodimensional array:
#mytimestamp : Timestamp of the forecast data
#Rad1h : Radiation Energy [kj/m²]
#TTT : Temperature 2 m above surface [°C]
#PPPP : Presssure Values (Surface Pressure reduced)
#FF : Wind speed [m/s]
#
#
# Update August 05 2020
# Kilian did a lot of perfect prework, but I did some cleanup on this code. Originally it was written for a different environment.
# The changes are related to the communication with FHEM and the code is triggered also by FHEM for a one time run each call.
# Unnessesary data is dropped, to reduce the amount of data transfered to FHEM

import urllib.request
import shutil
import zipfile
from bs4 import BeautifulSoup
import requests
import xml.etree.ElementTree as ET
import time
import datetime
import queue
import threading
import logging
import pprint

import fhem
import json

import sys
web = sys.argv[1]
station = sys.argv[2]

pp = pprint.PrettyPrinter(indent=4)

def connvertINTtimestamptoDWD(inputstring):
# Purpose: Convert a timestamp as presented by the UTC: 1545030000.0
# and return it to a UTC representation: 2018-12-17T08:00:00.000000Z
#mynewtime =time.mktime(datetime.datetime.strptime(inputstring, "%Y-%m-%dT%H:%M:%S.%fZ").timetuple())
#print ("neue Zeit ", mynewtime)
mysecondtime = (datetime.datetime.fromtimestamp(inputstring).strftime('%Y-%m-%dT%H:%M:%S.%f')[:-3]) + "Z"
return (mysecondtime)

# Main class that holds the required information
class dwdforecast(threading.Thread):
def __init__ (self, myqueue):
print ("Starting dwdforecast init ...")
self.myqueue = myqueue
self.event = threading.Event()
self.ext = 'kmz'
self.mystation = station # This should be your closes station
# Only use the "all_stations" if you got decent hardware
#self.urlpath = 'http://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml'
#On Raspberries & alikes, use the one for your specific station:
self.urlpath = 'https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_L/single_stations/' + self.mystation +'/kml'
self.lasttimecheck = 1534800680.0 # Dec 14th 2018 (pure initialization)
self.sleeptime = 15 #Time interval we poll the server [seconds]- please increase time since updates from DWD are hourly at best
self.myinit = 0 #So we can populate the queue initially / subsequently
threading.Thread.__init__ (self)
print ("I am looking for data from DWD for the following station: ", self.mystation)
print ("I will be polling the following URL for the latest updates ", self.urlpath)

# Based on the user specified URL, find the latest file file with it´s timestamp
def GetURLForLatest(self,urlpath, ext=''):
try:
page = requests.get(urlpath).text
except Exception as ErrorGetWebdata:
logging.error("%s %s",",GetURLForLatest Error getting data from the internet:", ErrorGetWebdata)
soup = BeautifulSoup(page, 'html.parser')
soup_reduced= soup.find_all('pre')
soup_reduced = soup_reduced[0]
counter = 0
for elements in soup_reduced:
elements = str(elements)
if (counter >0):
words =elements.split()
mytime = words[0] +"-" + words[1]
logging.debug("%s %s" ,",GetURLForLatest :DWD Filetimestamp found :", mytime)
mynewtime =time.mktime(datetime.datetime.strptime(mytime, "%d-%b-%Y-%H:%M").timetuple())
logging.debug("%s %s" ,",GetURLForLatest :DWD Filetimestamp found :", mynewtime)
#print ("From function GetURLForLatest -mynewtime", 2*mynewtime)

if (elements.find("LATEST") >0):
#print ("My element", elements)
counter = 1
myurl = [urlpath + '/' + node.get('href') for node in soup.find_all('a') if node.get('href').endswith(ext)]
return (myurl, mynewtime)

def connvertDWDtimestamptoINT(self,inputstring):
# Purpose: Convert a timestamp as presented by the DWD: 2018-12-25T07:00:00.000Z
# and return it to a UTC representation
mynewtime =time.mktime(datetime.datetime.strptime(inputstring, "%Y-%m-%dT%H:%M:%S.%fZ").timetuple())
#print ("neue Zeit ", mynewtime)
#mysecondtime = datetime.datetime.fromtimestamp(mynewtime).strftime('%Y-%m-%dT%H:%M:%S.%fZ')
#print ("Einmal retour", mysecondtime)
mycurrentINTtimestamp =int(mynewtime)
return (mycurrentINTtimestamp)

def connvertDWDtimestamptoINT(self,inputstring):
# Purpose: Convert a timestamp as presented by the DWD: 2018-12-25T07:00:00.000Z
# and return it to a UTC representation
mynewtime =time.mktime(datetime.datetime.strptime(inputstring, "%Y-%m-%dT%H:%M:%S.%fZ").timetuple())
mycurrentINTtimestamp =int(mynewtime)
return (mycurrentINTtimestamp)

try:
def run(self):
if (self.myinit== 0): #We populate the first timestamp to signal to main that we are up & running
temptimestamp = time.time()
print ("From dwdforecast - initial queue population", temptimestamp)
self.myqueue.put(temptimestamp)
self.myinit = 1
time.sleep(1)
try:
self.mydownloadfiles, self.mynewtime = self.GetURLForLatest(self.urlpath, self.ext)
#print ("Downloadfiles = ", self.mydownloadfiles)
#print ("Timestamp = ", self.mynewtime)
except Exception as ErrorReadFromDWD:
logging.error("%s %s" ,",dwdforecast :", ErrorReadFromDWD)

self.myarray =[]
for self.file in self.mydownloadfiles:
self.myarray.append(self.file)
self.temp_length = len(self.myarray)
self.url = self.myarray[self.temp_length-1]

logging.debug("%s %s %s",",dwdforecast : -BEFORE if- time comparison :", self.mynewtime, self.lasttimecheck)
# if (self.mynewtime > self.lasttimecheck):
logging.debug("%s %s %s" ,",dwdforecast : -in if- time comparison :", self.mynewtime, self.lasttimecheck)
#print ("DWD Weather - we have found a new kml file that we will download - timestamp was :", self.mynewtime)
#print ("DWD Weather - self.lasttimecheck was ", self.lasttimecheck)
self.lasttimecheck = self.mynewtime
self.file_name = "dwd_temp1.gz"
self.out_file = "dwd_temp2.gz"
self.targetdir ="./"
try:
time.sleep(10) #Assumption is - we see the file on the DWD server - but it has not yet been copied over
# Download the file from `url` and save it locally under `self.file_name`:
with urllib.request.urlopen(self.url) as self.response, open(self.file_name, 'wb') as self.out_file:
shutil.copyfileobj(self.response, self.out_file)
time.sleep(5) #not sure if this gets rid of the access problems
with zipfile.ZipFile(self.file_name,"r") as zip_ref:
Myzipfilename = (zip_ref.namelist())
Myzipfilename = str(Myzipfilename[0])
zip_ref.extractall(self.targetdir)
logging.debug("%s %s" ,",dwdforecast : -File that I extract is zipfile :", Myzipfilename)
time.sleep(5) #not sure if this gets rid of the access problems
except Exception as MyException:
logging.error("%s %s", ",subroutine dwdforecast exception getting the data from server : ", MyException)

self.tree = ET.parse(Myzipfilename)
self.root = self.tree.getroot()
self.root.tag
"""
<kml:kml xmlns:dwd="https://opendata.dwd.de/weather/lib/pointforecast_dwd_extension_V1_0.xsd" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:xal="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">

<kml:kml xmlns:dwd="https://opendata.dwd.de/weather/lib/pointforecast_dwd_extension_V1_0.xsd" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:xal="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">
"""
#--------------------------------------------------
#Namespace definition for kml file:
#
self.ns = {'dwd': 'https://opendata.dwd.de/weather/lib/pointforecast_dwd_extension_V1_0.xsd', 'gx': 'http://www.google.com/kml/ext/2.2',
'kml': 'http://www.opengis.net/kml/2.2', 'atom': 'http://www.w3.org/2005/Atom', 'xal':'urn:oasis:names:tc:ciq:xsdschema:xAL:2.0'}
#--------------------------------------------------
# We get the timestamps
#
self.timestamps = self.root.findall('kml:Document/kml:ExtendedData/dwd:ProductDefinition/dwd:ForecastTimeSteps/dwd:TimeStep',self.ns)
self.i = 0
self.timevalue=[]
for self.child in self.timestamps:
#print ("TIMESTAMPS", child.text)
self.timevalue.append(self.child.text)
"""
for j in timevalue:
print ("Zeit",i, " ", timevalue[i])
i = i+1
"""

for self.elem in self.tree.findall('./kml:Document/kml:Placemark',self.ns): #Position us at the Placemark
#print ("SUCERJH ", sucher)
#print ("Elemente ", elem.tag, elem.attrib, elem.text)
self.mylocation = self.elem.find('kml:name',self.ns).text #Look for the station Number

# Hier IF Frage einbauen
if (self.mylocation == self.mystation):
#print ("meine location", self.mylocation)
self.myforecastdata = self.elem.find('kml:ExtendedData',self.ns)
for self.elem in self.myforecastdata:
#We may get the following strings and are only interested in the right hand quoted property name WPcd1:
#{'{https://opendata.dwd.de/weather/lib/pointforecast_dwd_extension_V1_0.xsd}elementName': 'WPcd1'}
self.trash = str(self.elem.attrib)
self.trash1,self.mosmix_element = self.trash.split("': '")
self.mosmix_element, self.trash = self.mosmix_element.split("'}")
#-------------------------------------------------------------
# Currently looking at the following key Data:
# Looking for the following mosmix_elements
#FF : Wind Speed [m/s]
#Rad1h : Global irridance [kJ/m²]
#TTT : Temperature 2m above ground [Kelvin]
#PPPP : Pressure reduced [Pa]
#-------------------------------------------------------------
if ('FF' == self.mosmix_element):
self.FF_temp = self.elem[0].text
self.FF = list (self.FF_temp.split())
if ('Rad1h' == self.mosmix_element):
self.Rad1h_temp = self.elem[0].text
self.Rad1h = list (self.Rad1h_temp.split())
if ('TTT' == self.mosmix_element):
self.TTT_temp = self.elem[0].text
self.TTT = list(self.TTT_temp.split())
counter = 0
# We convert from Kelvin to Celcius...:
for i in self.TTT:
self.TTT[counter]=round((float(self.TTT[counter])-273.13),2)
#print (self.TTT[counter])
counter = counter +1
if ('PPPP' == self.mosmix_element):
self.PPPP_temp = self.elem[0].text
self.PPPP = list (self.PPPP_temp.split())

#------------------------------------
# Define empty array
self.mosmixdata =[]
for self.j in range(6): #Right now we have timevalue, mytimestamp, self.FF Rad1h TTT PPPP
self.column = []
self.counter = 0
for self.i in self.timevalue:
self.column.append(0)
self.mosmixdata.append(self.column)
#------------------------------------
#Populate values
counter = 0

for self.i in self.timevalue:
self.mytimestamp = self.connvertDWDtimestamptoINT(self.timevalue[counter])
self.mosmixdata[0][counter]=self.timevalue[counter]
self.mosmixdata[1][counter]=self.mytimestamp
self.mosmixdata[2][counter]=self.Rad1h[counter]
self.mosmixdata[3][counter]=self.TTT[counter]
self.mosmixdata[4][counter]=self.PPPP[counter]
self.mosmixdata[5][counter]=self.FF[counter]
counter = counter + 1
#------------------------------------------

self.cols = len(self.mosmixdata)
rows = 0
if self.cols:
self.rows = len(self.mosmixdata[0])
self.MosmixFileFirsttimestamp = self.mosmixdata[1][0]
#print ("My first stamp from the file is:",self.mosmixdata[0][0],"Endstring",self.mosmixdata[1][0] )
#print ("-------------------------------------------------")
#print (self.mosmixdata)
self.indexcounter_addrows=1
self.MyWeathervalues = {}
try:
print ("Here is what we got from DWD :")
for j in range(self.rows):
if (self.indexcounter_addrows >0): #We are adding from the point onward - see self.indexcounter_addrows if check below
#print ("counting indices", self.indexcounter_addrows)
#self.MyWeathervalues.update({'mydatetime':self.mosmixdata[0][j]})
#self.MyWeathervalues.update({'mytimestamp':self.mosmixdata[1][j]})
if (self.mosmixdata[2][j] > '0.00'): #Reduce unneccessary data
self.time = time.strftime("%Y-%m-%d_%H:%M", time.localtime(self.mosmixdata[1][j]))
self.MyWeathervalues.update({self.time + '_Rad1wh':int(round(float(self.mosmixdata[2][j]) * 0.277778 , 0))})
self.MyWeathervalues.update({self.time + '_TTT':self.mosmixdata[3][j]})
#self.MyWeathervalues.update({'TTT':self.mosmixdata[3][j]})
#self.MyWeathervalues.update({'PPPP':self.mosmixdata[4][j]})
#self.MyWeathervalues.update({'FF':self.mosmixdata[5][j]})

#print ('mydatetime',self.mosmixdata[0][j],'mytimestamp ',self.mosmixdata[1][j],'Rad1h ',self.mosmixdata[2][j],'TTT ',self.mosmixdata[3][j], 'PPPP',self.mosmixdata[4][j],'FF',self.mosmixdata[5][j])

import re
self.message = re.sub("'", "\"", str(self.MyWeathervalues))
#print(self.MyWeathervalues)
#print(self.message)

try:
with open('/opt/fhem/python/pwd_fhem.json', 'r') as f:
credentials=json.load(f)
except Exception as e:
print('Something went wrong: {}'.format(e))

fh = fhem.Fhem(web, protocol="http", port=8083, username=credentials["username"], password=credentials["password"])

fh.send_cmd("setreading DWD_Prognose output " + self.message)

self.mytimestamp = connvertINTtimestamptoDWD(self.mynewtime)
logging.debug ("%s %s %s %s", ",Subroutine dwdforecast -we have used DWD file from time : ", self.mynewtime, " ", self.mytimestamp)
except Exception as ErrorDWDArray:
print ("Shit happened ?", ErrorDWDArray)
logging.error ("%s %s", ",subroutine dwdforecast final exception : ", ErrorDWDArray)
logging.debug("%s %s", "From dwdforecast - we have found a true commit and have updated the database at the following dwd time :", self.mynewtime)
time.sleep(self.sleeptime) # We are putting in a sleep
self.myqueue.put(self.mynewtime)

except Exception as ExceptionError:
print ("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX")
print ("XXX-Aus Subroutine dwdforecast -verrant ? ", ExceptionError)
print ("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX")
logging.error("%s %s", ",subroutine dwdforecast final exception : ", ExceptionError)

if __name__ == "__main__":

logging.basicConfig(filename="./log/dwd_debug.txt",level=logging.DEBUG)
#
"""
Interaction can be 'Simple' - or 'Complex'
Simple : Try to get weather data once only - then terminate
Complex : Start a seperate queue that continuously polls the DWD server on the internet to get updated data
"""
Interaction = 'Simple' #Interaction can be 'Simple' - or 'Complex'
#

#-----------------------------------------------------------------
# START Queue (To read dwd values and populate them to database):
try:
myQueue1 = queue.Queue()
myThread1= dwdforecast(myQueue1)
myThread1.start()
while myQueue1.empty():
print(" Waiting on DWD dwdforecastdata Queue results to tell it is started...")
logging.info("%s " ",Main :Waiting on Queue results to be populated ...")
time.sleep(1)
# Queue End (To read values from DWD)
#_________________________________________________________________
i = 0

try:
while i <1:
if not myQueue1.empty(): # Falls was in der Queue steht machen wir was
quelength = myQueue1.qsize() # Wenn da viele Werte angelaufen sind, nehmen wir jetzt einfach den Letzten
#print ("LAENGE der QUEUE -XXXXXXXXXXXXXXXXXXXXXXX : ", quelength)
logging.info("%s %s " ,",Main :Queue length is : ", quelength)

for x in range (0,quelength):
LastDWDtimestamp = myQueue1.get() # Das ist die magische Zeile in der wir den Wert aus der Queue abholen
mylasttimestamp = connvertINTtimestamptoDWD(LastDWDtimestamp)
print ("From Main : DWD File access I checked / got uploaded by DWD was at :", LastDWDtimestamp,mylasttimestamp )
i = i + 1

except Exception as OtherExceptionError:
print ("hit some other error.... !", OtherExceptionError)

except Exception as FinalExceptionError:
print ("I am clueless ... Hit some other error .... !", FinalExceptionError)
</syntaxhighlight>
==== RAW Definition DWD_Prognose ====
<syntaxhighlight lang="Perl">
defmod DWD_Prognose expandJSON DWD_Prognose:output:.\{.*}
attr DWD_Prognose DbLogExclude .*
attr DWD_Prognose alias DWD_Prognose
attr DWD_Prognose comment Das Device wird über ein Python Skript im reading output befüllt.\
deletereading DWD_Prognose .*_Rad1wh\

attr DWD_Prognose group PV Eigenverbrauch
attr DWD_Prognose icon measure_photovoltaic_inst
attr DWD_Prognose room Informationen->Wetter,Strom->Photovoltaik,Strom->System
attr DWD_Prognose sortby 02
</syntaxhighlight>
=== ProPlanta ===
Die Webseite Proplanta stellt unter anderem chOfRain*, cloud* in einer drei Stunden Prognose bereit und dies dann für mehrere Tage fc0 , fc1, ...
==== RAW Definition ProPlanta ====
<syntaxhighlight lang="Perl">
defmod ProPlanta PROPLANTA <Wohnort> de
attr ProPlanta DbLogExclude .*
attr ProPlanta DbLogInclude cloudBaseMax,cloudBaseMin,fc0_cloud06,fc0_cloud09,fc0_cloud12,fc0_cloud15,fc0_cloud18,fc0_rad,fc0_sun,fc0_uv,fc0_weather06,fc0_weather09,fc0_weather12,fc0_weather15,fc0_weather18,fc1_cloud06,fc1_cloud09,fc1_cloud12,fc1_cloud15,fc1_cloud18,fc1_rad,fc1_sun,fc1_uv,fc1_weather06,fc1_weather09,fc1_weather12,fc1_weather15,fc1_weather18,weather
attr ProPlanta INTERVAL 900
attr ProPlanta alias ProPlanta
attr ProPlanta event-on-change-reading cloudBaseMax,cloudBaseMin,fc0_cloud06,fc0_cloud09,fc0_cloud12,fc0_cloud15,fc0_cloud18,fc0_rad,fc0_sun,fc0_uv,fc0_weather06,fc0_weather09,fc0_weather12,fc0_weather15,fc0_weather18,fc1_cloud06,fc1_cloud09,fc1_cloud12,fc1_cloud15,fc1_cloud18,fc1_rad,fc1_sun,fc1_uv,fc1_weather06,fc1_weather09,fc1_weather12,fc1_weather15,fc1_weather18,weather
attr ProPlanta forecastDays 4
attr ProPlanta group ASC Environment
attr ProPlanta icon weather_sunrise
attr ProPlanta room Informationen->Wetter,Rollos
attr ProPlanta sortby 02
</syntaxhighlight>
=== myUtils.pm Funktionen ===
==== Solar_forecast ====
Achtung, diese Funktion ist noch nicht vollständig ausprogrammiert. Es wurden bereits Übergabeparameter integriert, um z.B. andere Wetterdienste zu berücksichtigen.
Um diese Funktion zu nutzen muss ein Dummy PV_Anlage_1_config vorhanden sein, in dem unter anderem die Modul und Anlagen Ausrichtung konfiguriert wird.
Rückfragen gerne im Forum.
<syntaxhighlight lang="Perl">
###########################################################
# Subroutine to calculate radiation
###########################################################
sub Solar_forecast($$$$$$$) {

my $logdb = $_[0] ;
my $logdbrep = $_[1] ; # Das wird zum Löschen in der LogDB verwendet und muss entsprechend konfiguriert sein.
my $logdevice = $_[2] ;
# Hier könnte man noch andere Wetterdienste berücksichtigen bzw den Device Namen ändern
my $wetter_1 = $_[4] ; if ($wetter_1 ne "DWD_Prognose") {return("$wetter_1 not supported")} ;
my $wetter_2 = $_[5] ; if ($wetter_2 ne "ProPlanta" ) {return("$wetter_2 not supported")} ;
my $fc = $_[6] ; # Wieviel Tage in die Zukunft soll es gehen? 0,1,2
my $reading = $_[3].$fc ;

my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); $year += 1900; $mon += 1;
my ($Solar_Cloud,$Solar_Rain,$Solar_Temp,$Solar_Correction_Cloud,$Solar_Correction_Rain,$Solar_Correction_Temp,$Solar_SolarRadiation,$Solar_East,$Solar_South,$Solar_West,$logentry,$i) = 0 ;
my ($Solar_1,$Solar_2,$Solar_3) = 0 ;

# Initialisieren des Basis TIMESTAMP für den Forecast
my $timestring = time_str2num($year."-".$mon."-".$mday." 08:00:00") ;
my $timestamp = POSIX::strftime("%Y-%m-%d %H:00:00",localtime($timestring+$fc*24*60*60)) ;

# Bei Forecast ab dem nächsten Tag zuerst die bisherigen Einträge für den Tag löschen
if ( $fc != 0 ) {
fhem "set ".$logdbrep." sqlCmd DELETE FROM history WHERE DEVICE='".$logdevice."' AND READING='".$reading."' AND TIMESTAMP>='".$timestamp."'"} ;

# Es werden Stundenwerte von 08:00 bis 19:00 Uhr berechnet
for ($i = 8; $i <= 19; $i++) {
$timestring = time_str2num($year."-".$mon."-".$mday." ".$i.":00:00") ;
$timestamp = POSIX::strftime("%Y-%m-%d %H:00:00",localtime($timestring+$fc*24*60*60)) ;

# Bei ProPlanta liegen die Werte im drei Stunden Abstand vor
if ( $wetter_2 eq "ProPlanta") {
if ( $i >= 6 and $i < 9 )
{ $Solar_Cloud = ReadingsVal($wetter_2,"fc".$fc."_cloud09" ,0) ;
$Solar_Rain = ReadingsVal($wetter_2,"fc".$fc."_chOfRain09",0) ; } ;
if ( $i >= 9 and $i < 12 )
{ $Solar_Cloud = ReadingsVal($wetter_2,"fc".$fc."_cloud09" ,0) ;
$Solar_Rain = ReadingsVal($wetter_2,"fc".$fc."_chOfRain09",0) ; } ;
if ( $i >= 12 and $i < 15 )
{ $Solar_Cloud = ReadingsVal($wetter_2,"fc".$fc."_cloud12" ,0) ;
$Solar_Rain = ReadingsVal($wetter_2,"fc".$fc."_chOfRain12",0) ; } ;
if ( $i >= 15 and $i < 18 )
{ $Solar_Cloud = ReadingsVal($wetter_2,"fc".$fc."_cloud15" ,0) ;
$Solar_Rain = ReadingsVal($wetter_2,"fc".$fc."_chOfRain15",0) ; } ;
};

if ( $wetter_1 eq "DWD_Prognose") {
$Solar_Temp = ReadingsVal($wetter_1,POSIX::strftime("%Y-%m-%d_%H_00_TTT", localtime($timestring+($fc*24-1)*60*60)),0)+10;
$Solar_SolarRadiation = ReadingsVal($wetter_1,POSIX::strftime("%Y-%m-%d_%H_00_Rad1wh",localtime($timestring+($fc*24-1)*60*60)),0) ;
};

my $cloudk = ReadingsVal($logdevice."_config","forecast_cloudk",0) * -0.01 ;
if ($cloudk ne 0) {
my $cloudk_base = ReadingsVal($logdevice."_config","forecast_cloudk_base",0) ;
# printf "cloudk ".$cloudk." ".$cloudk_base."\n" ;
$Solar_Correction_Cloud = round((1 + ($Solar_Cloud - $cloudk_base) * $cloudk / 100),3) ;
} else {
$Solar_Correction_Cloud = 1 ;
};

my $raink = ReadingsVal($logdevice."_config","forecast_raink",0) * -0.01 ;
if ($raink ne 0) {
my $raink_base = ReadingsVal($logdevice."_config","forecast_raink_base" ,0) ;
# printf "raink ".$raink." ".$raink_base."\n" ;
$Solar_Correction_Rain = round((1 + ($Solar_Rain - $raink_base ) * $raink / 100),3) ;
} else {
$Solar_Correction_Rain = 1 ;
};

my $tempk = ReadingsVal($logdevice."_config","forecast_tempk",0) * -0.01 ;
if ($tempk ne 0) {
my $tempk_base = ReadingsVal($logdevice."_config","forecast_tempk_base" ,0) ;
# printf "tempk ".$tempk." ".$tempk_base."\n" ;
$Solar_Correction_Temp = round((1 + ($Solar_Temp - $tempk_base ) * $tempk / 100),3) ;
} else {
$Solar_Correction_Temp = 1 ;
};

my $Solar_Correction_Faktor = ReadingsVal($logdevice."_config","forecast_factor",1) ;

my $module_1_count = ReadingsVal($logdevice."_config","module_1_count",0) ;
if ($module_1_count ne 0) {
$Solar_1 = $module_1_count * ReadingsVal($logdevice."_config","module_1_power",1)/1000 ;
$Solar_1 = $Solar_1 * Solar_plain(ReadingsVal($logdevice."_config","module_1_plain",0) , ReadingsVal($logdevice."_config","module_1_direction",0) , $timestamp) ;
$Solar_1 = $Solar_1 * $Solar_SolarRadiation ;
$Solar_1 = $Solar_1 * $Solar_Correction_Temp * $Solar_Correction_Cloud * $Solar_Correction_Rain * $Solar_Correction_Faktor ;
$Solar_1 = ($Solar_1 lt 0)?0:round($Solar_1,0) ;
} else {
$Solar_1 = 0 ;
};

my $module_2_count = ReadingsVal($logdevice."_config","module_2_count",0) ;
if ($module_2_count ne 0) {
$Solar_2 = $module_2_count * ReadingsVal($logdevice."_config","module_2_power",1)/1000 ;
$Solar_2 = $Solar_2 * Solar_plain(ReadingsVal($logdevice."_config","module_2_plain",0) , ReadingsVal($logdevice."_config","module_2_direction",0) , $timestamp) ;
$Solar_2 = $Solar_2 * $Solar_SolarRadiation ;
$Solar_2 = $Solar_2 * $Solar_Correction_Temp * $Solar_Correction_Cloud * $Solar_Correction_Rain * $Solar_Correction_Faktor ;
$Solar_2 = ($Solar_2 lt 0)?0:round($Solar_2,0) ;
} else {
$Solar_2 = 0 ;
};

my $module_3_count = ReadingsVal($logdevice."_config","module_1_count",0) ;
if ($module_3_count ne 0) {
$Solar_3 = $module_3_count * ReadingsVal($logdevice."_config","module_3_power",1)/1000 ;
$Solar_3 = $Solar_3 * Solar_plain(ReadingsVal($logdevice."_config","module_3_plain",0) , ReadingsVal($logdevice."_config","module_3_direction",0) , $timestamp) ;
$Solar_3 = $Solar_3 * $Solar_SolarRadiation ;
$Solar_3 = $Solar_3 * $Solar_Correction_Temp * $Solar_Correction_Cloud * $Solar_Correction_Rain * $Solar_Correction_Faktor ;
$Solar_3 = ($Solar_3 lt 0)?0:round($Solar_3,0) ;
} else {
$Solar_3 = 0 ;
};

$logentry = round( $Solar_1 + $Solar_2 + $Solar_3,0) ;

# printf $fc." ".$hour." ".$Solar_SolarRadiation." ".$logentry."\n" ;

if ($fc == 0 and $hour == $i and $orientation eq "ESW") {
fhem "setreading ".$logdevice." Solar_SolarRadiation ".$Solar_SolarRadiation ;
fhem "setreading ".$logdevice." Solar_Cloud ".$Solar_Cloud ;
fhem "setreading ".$logdevice." Solar_Rain ".$Solar_Rain ;
fhem "setreading ".$logdevice." Solar_Correction_Cloud ".$Solar_Correction_Cloud ;
fhem "setreading ".$logdevice." Solar_Correction_Rain ".$Solar_Correction_Rain ;
fhem "setreading ".$logdevice." Solar_Correction_Temp ".$Solar_Correction_Temp ;
fhem "setreading ".$logdevice." Solar_Calculation ".$logentry ;
fhem "setreading ".$logdevice." Solar_".ReadingsVal($logdevice."_config","module_1_name",0)." ".$Solar_1;
fhem "setreading ".$logdevice." Solar_".ReadingsVal($logdevice."_config","module_2_name",0)." ".$Solar_2;
fhem "setreading ".$logdevice." Solar_".ReadingsVal($logdevice."_config","module_3_name",0)." ".$Solar_3;
} ;
if ($fc != 0) {
fhem "set ".$logdb." addCacheLine ".$timestamp."|".$logdevice."|addlog|".$reading.": ".$logentry."|".$reading."|".$logentry."|";
} ;
} ;

return (0);
};
</syntaxhighlight>
==== Solar_Plain ====
<syntaxhighlight lang="Perl">
sub Solar_plain($$$) {

my $angle = $_[0];
my $orienta = $_[1];
my $time = $_[2];
my $azimuth = fhem "get Astro text SunAz ".$time ;

# angles in radiant
my $rad = 57.296;
my $elevation = fhem "get Astro text SunAlt ".$time ;
$elevation = $elevation / $rad;
$angle = $angle / $rad;
my $orientation = ($azimuth - 180 - $orienta) / $rad;

# avoid unrealistic values (normally formula should only be used within boundaries of orientation +/- 90 degrees)
return (0.001) if ($elevation <= 0.35);

if(cos($orientation) < 0.05 && cos($orientation) > -0.2) {$orientation =$orientation - 0.2}

## Log3 "", 1, "Solar radiation, azimuth = $azimuth, orientation=$orientation, elevation=$elevation, angle=$angle";
my $factor = sin($angle) /
(sin( $elevation) /
cos( $elevation)) *
cos($orientation) +
cos($angle);

# otherwise too big values (normally formula should only be used within boundaries of orientation +/- 90 degrees)
if ($factor > - 0.05 && $factor < 0.05) {$factor = 0.05}

return ($factor);
};
</syntaxhighlight>
=== wunderground ===
Diesen Dienst nutze ich nicht für die Prognose, jedoch kann man dort private Wetterstationen in seinem näheren Umfeld finden, die die Sonneneinstrahlung und den UV Index messen. Das ist dann als aktueller Wert in den Diagrammen zu sehen und lässt aktuelle Beschattung durch Wolken erkennen. Hier kann man dann auch mehrere Stationen definieren und eventuell mit einem Durchschnitt arbeiten, wenn nicht gerade der Nachbar eine Station hat.
Für diese Abfrage ist keine Registrierung notwendig und man muss auch nicht selber mir einer Station Daten liefern.
Aber bitte, die Abfrage nicht in einem zu kurzen Abstand, also mit hoher Frequenz stellen! Hier wird alle 15 Minuten (900 Sekunden) abgefragt.
=== RAW Definition Wetter_<Wohnort> ===
<syntaxhighlight lang="Perl">
defmod wetter_<Wohnort> HTTPMOD https://www.wunderground.com/dashboard/pws/<Wohnort_Station> 900

attr wetter_<Wohnort> DbLogExclude .*
attr wetter_<Wohnort> DbLogInclude solarRadiation,solarUV,temperature
attr wetter_<Wohnort> alias wetter_<Wohnort>
attr wetter_<Wohnort> enableControlSet 1
attr wetter_<Wohnort> event-on-change-reading solarRadiation,solarUV,temperature
attr wetter_<Wohnort> group ASC Environment
attr wetter_<Wohnort> icon weather_sunrise
attr wetter_<Wohnort> reading01Name date
attr wetter_<Wohnort> reading01Regex Summary.*>([[:alpha:]]{1,8} [\d]{1,2}, [\d]{4})<.*Temperature
attr wetter_<Wohnort> reading02Format %.1f
attr wetter_<Wohnort> reading02Name dewpointTemperature
attr wetter_<Wohnort> reading02OExpr UConv::f2c($val,2)
attr wetter_<Wohnort> reading02Regex DEWPOINT.*>([\d\.]+)<.*HUMIDITY
attr wetter_<Wohnort> reading03Name dewpointTemperature_EN
attr wetter_<Wohnort> reading03Regex DEWPOINT.*>([\d\.]+)<.*HUMIDITY
attr wetter_<Wohnort> reading04Format %.0f
attr wetter_<Wohnort> reading04Name humidity
attr wetter_<Wohnort> reading04Regex HUMIDITY.*>([\d\.]+)<.*WIND
attr wetter_<Wohnort> reading05Name precip1hrmetric
attr wetter_<Wohnort> reading05Regex PRECIP RATE.*>([\d\.]+)<.*PRECIP TOTAL
attr wetter_<Wohnort> reading06Name preciptodaymetric
attr wetter_<Wohnort> reading06Regex PRECIP TOTAL.*>([\d\.]+)<.*tile-precipitation
attr wetter_<Wohnort> reading07Format %.2f
attr wetter_<Wohnort> reading07Name pressure
attr wetter_<Wohnort> reading07OExpr UConv::inhg2hpa($val,2)
attr wetter_<Wohnort> reading07Regex CURRENT.*>([\d\.]+)<.*tile-pressure
attr wetter_<Wohnort> reading08Format %.2f
attr wetter_<Wohnort> reading08Name pressure_EN
attr wetter_<Wohnort> reading08Regex CURRENT.*>([\d\.]+)<.*tile-pressure
attr wetter_<Wohnort> reading09Name solarRadiation
attr wetter_<Wohnort> reading09Regex SOLAR RADIATION.*CURRENT.*weather__text">([\d\.]+)
attr wetter_<Wohnort> reading10Name solarUV
attr wetter_<Wohnort> reading10Regex CURRENT UV.*>([\d\.]+)<.*UV RISK
attr wetter_<Wohnort> reading11Format %.1f
attr wetter_<Wohnort> reading11Name temperature
attr wetter_<Wohnort> reading11OExpr UConv::f2c($val,2)
attr wetter_<Wohnort> reading11Regex current-temp.*">([- ]*[\d\.]+).*DEWPOINT
attr wetter_<Wohnort> reading12Format %.1f
attr wetter_<Wohnort> reading12Name temperature_EN
attr wetter_<Wohnort> reading12Regex current-temp.*">([- ]*[\d\.]+).*DEWPOINT
attr wetter_<Wohnort> reading13Format %.1f
attr wetter_<Wohnort> reading13Name windChill
attr wetter_<Wohnort> reading13OExpr UConv::f2c($val,2)
attr wetter_<Wohnort> reading13Regex Feels Like.*>([\d\.]+)<.*wind-dial__container
attr wetter_<Wohnort> reading14Format %.1f
attr wetter_<Wohnort> reading14Name windChill_EN
attr wetter_<Wohnort> reading14Regex Feels Like.*>([\d\.]+)<.*wind-dial__container
attr wetter_<Wohnort> reading15Name windDirection
attr wetter_<Wohnort> reading15OExpr UConv::compasspoint2compasspoint($val,"en",1,"de")
attr wetter_<Wohnort> reading15Regex WIND FROM.*>([NESW]+)<.*GUST
attr wetter_<Wohnort> reading16Name windDirection_EN
attr wetter_<Wohnort> reading16Regex WIND FROM.*>([NESW]+)<.*GUST
attr wetter_<Wohnort> reading17Format %.0f
attr wetter_<Wohnort> reading17Name windSpeed
attr wetter_<Wohnort> reading17OExpr UConv::mph2kph($val,1)
attr wetter_<Wohnort> reading17Regex wind-dial__container.*>([\d\.]+)<.*unit-speed
attr wetter_<Wohnort> reading18Name windSpeed_EN
attr wetter_<Wohnort> reading18Regex wind-dial__container.*>([\d\.]+)<.*unit-speed
attr wetter_<Wohnort> reading19Name windGust
attr wetter_<Wohnort> reading19OExpr UConv::mph2kph($val,1)
attr wetter_<Wohnort> reading19Regex GUST.*>([\d\.]+)<.*mph
attr wetter_<Wohnort> reading20Name windGust_EN
attr wetter_<Wohnort> reading20Regex GUST.*>([\d\.]+)<.*mph
attr wetter_<Wohnort> room Informationen->Wetter,Rollos
attr wetter_<Wohnort> sortby 03
attr wetter_<Wohnort> stateFormat T: temperature °C | F: humidity % | W: windSpeed km/h | D: pressure hPa | U: solarUV | R: solarRadiation W/m²
attr wetter_<Wohnort> timeout 5
</syntaxhighlight>

== Diagramme ==
=== RAW Definition Hauptverbraucher ===
[[Bild:Plenticore_Hauptverbraucher.png|mini|600px|rechts|]]
==== SVG_LogDB_Photovoltaik_2 ====
<pre>
defmod SVG_LogDB_Photovoltaik_2 SVG LogDB:SVG_LogDB_Photovoltaik_2:HISTORY
attr SVG_LogDB_Photovoltaik_2 DbLogExclude .*
attr SVG_LogDB_Photovoltaik_2 group PV Eigenverbrauch
attr SVG_LogDB_Photovoltaik_2 plotsize 1400,320
attr SVG_LogDB_Photovoltaik_2 room Strom->Info,Strom->Photovoltaik
attr SVG_LogDB_Photovoltaik_2 sortby 00
</pre>
==== GPLOTFILE SVG_LogDB_Photovoltaik_2.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-03-16 10:23:52
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Hauptverbraucher'
set ytics
set y2tics
set grid
set ylabel "Leistung"
set y2label ""

#LogDB PV_Anlage_1:Total_DC_Power:::$val=abs($val)
#LogDB PV_Anlage_1:Total_PV_Power_reserve::
#LogDB StromZaehler_Heizung:SMAEM1901401955_Saldo_Wirkleistung:::$val=abs($val)
#LogDB shelly02:Power_0::
#LogDB shelly03:Power::

plot "<IN>" using 1:2 axes x1y2 title 'Total_DC' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Total_PV_reserve' ls l2 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Heizung' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Pool' ls l8 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Waschmaschine' ls l3 lw 1 with lines
</pre>
=== RAW Definition Leistungsbezug ===
[[Bild:Plenticore_Leistungsbezug.png|mini|600px|rechts|]]
==== SVG_LogDB_Photovoltaik_3 ====
<pre>
defmod SVG_LogDB_Photovoltaik_3 SVG LogDB:SVG_LogDB_Photovoltaik_3:HISTORY
attr SVG_LogDB_Photovoltaik_3 DbLogExclude .*
attr SVG_LogDB_Photovoltaik_3 group PV Eigenverbrauch
attr SVG_LogDB_Photovoltaik_3 plotsize 1400,320
attr SVG_LogDB_Photovoltaik_3 room Strom->Info,Strom->Photovoltaik
attr SVG_LogDB_Photovoltaik_3 sortby 00
</pre>
==== GPLOTFILE SVG_LogDB_Photovoltaik_3.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-07-22 13:51:57
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Leistungsbezug'
set ytics
set y2tics
set grid
set ylabel "Leistung"
set y2label ""
set yrange [0:9500]
set y2range [0:9500]

#LogDB PV_Anlage_1:Total_DC_Power:::$val=abs($val)
#LogDB PV_Anlage_1:Home_own_consumption_from_PV::
#LogDB PV_Anlage_1:Home_own_consumption_from_battery::
#LogDB PV_Anlage_1:Home_own_consumption_from_grid::
#LogDB PV_Anlage_1:Actual_battery_charge_usable_Power::
#LogDB PV_Anlage_1:Total_DC_Power_Max::
#LogDB PV_Anlage_1:Battery_temperature:::$val=$val*100
#LogDB Heizung:heatSourceIN:::$val=$val*100

plot "<IN>" using 1:2 axes x1y2 title 'Total_DC_Power' ls l1fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'own_PV' ls l2fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Bat_use' ls l0fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Grid_use' ls l5 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Bat_usable' ls l4 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Total_DC_Max' ls l6 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Bat_Temp_Trend' ls l0 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Out_Temp_Trend' ls l2 lw 2 with lines
</pre>
=== RAW Definition PV_Bilanz ===
==== SVG_LogDB_PV_Bilanz ====
<pre>
defmod SVG_LogDB_PV_Bilanz SVG LogDB:SVG_LogDB_PV_Bilanz:HISTORY
attr SVG_LogDB_PV_Bilanz DbLogExclude .*
attr SVG_LogDB_PV_Bilanz alias SVG_LogDB_PV_Bilanz
attr SVG_LogDB_PV_Bilanz fixedrange year
attr SVG_LogDB_PV_Bilanz plotsize 1400,320
attr SVG_LogDB_PV_Bilanz room Strom->Energie
</pre>
==== GPLOTFILE SVG_LogDB_PV_Bilanz.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-08-02 09:55:06
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'PV_Bilanz'
set ytics
set y2tics
set grid ytics
set ylabel "KWh"
set y2label "KWh"

#LogDB Dum.Energy:max_month_PVMonth::
#LogDB Dum.Energy:diff_week_PVMonth::
#LogDB Dum.Energy:max_month_PVTotalMonth::
#LogDB Dum.Energy:diff_week_PVTotalMonth::
#LogDB Dum.Energy:AutarkyQuoteYear::

plot "<IN>" using 1:2 axes x1y2 title 'PV-Bezug-Monat' ls l2fill lw 1 with bars,\
"<IN>" using 1:2 axes x1y2 title 'PV-Bezug-Woche' ls l2fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'PV-Total-Monat' ls l1dot lw 4 with fsteps,\
"<IN>" using 1:2 axes x1y2 title 'PV-Total-Woche' ls l1fill lw 1 with fsteps,\
"<IN>" using 1:2 axes x1y2 title 'AutarkyQuoteYear' ls l0 lw 1 with steps
</pre>
=== RAW Definition Forecast / Calculation ===
[[Bild:Plenticore_Forecast.png|mini|600px|rechts|]]
==== SVG_LogDB_Photovoltaik_4 ====
<pre>
defmod SVG_LogDB_Photovoltaik_4 SVG LogDB:SVG_LogDB_Photovoltaik_4:HISTORY
attr SVG_LogDB_Photovoltaik_4 DbLogExclude .*
attr SVG_LogDB_Photovoltaik_4 group PV Eigenverbrauch
attr SVG_LogDB_Photovoltaik_4 plotsize 1400,320
attr SVG_LogDB_Photovoltaik_4 room Strom->Photovoltaik
attr SVG_LogDB_Photovoltaik_4 sortby 00
</pre>
==== GPLOTFILE SVG_LogDB_Photovoltaik_4.gplot ====
<pre>
# Created by FHEM/98_SVG.pm, 2020-08-17 08:58:42
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Forecast / Calculation'
set ytics
set y2tics
set grid
set ylabel "Leistung"
set y2label "Leistung"
set yrange [0:10000]
set y2range [0:10000]

#LogDB Astro:SunAlt:::$val=($val>0?$val*50+7000:7000)
#LogDB wetter_wolfskehlen_II:solarRadiation:::$val=($val>0?$val*3+7000:7000)
#LogDB PV_Anlage_1:Solar_SolarRadiation:::$val=($val>0?$val*3+7000:7000)
#LogDB Astro:SunAlt:::$val=7000
#LogDB PV_Anlage_1:Solar_Calculation_fc1::
#LogDB PV_Anlage_1:Power_DC_Sum::
#LogDB PV_Anlage_1:Solar_Calculation::
#LogDB PV_Anlage_1:Solar_East::
#LogDB PV_Anlage_1:Solar_South::
#LogDB PV_Anlage_1:Solar_West::

plot "<IN>" using 1:2 axes x1y2 title 'Sonnenhöhe' ls l7 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SolarRadiation' ls l8 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SolarRadiationPrognose' ls l8 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title '70%' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Calculation_fc1' ls l0 lw 2 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Power_DC_Sum' ls l1fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Calculation' ls l5 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'East' ls l2 lw 0.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'South' ls l3 lw 0.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'West' ls l4 lw 0.5 with lines
</pre>

== PV Eigenverbrauch-Steuerung ==
=== Beispiel Luft Wärme Pumpe ===
==== RAW Definition LWP_LuftWärmePumpe (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod LWP dummy
attr LWP DbLogExclude .*
attr LWP DbLogInclude state
attr LWP alias LWP_LuftWärmePumpe
attr LWP group PV Eigenverbrauch
attr LWP icon sani_earth_source_heat_pump
attr LWP readingList LWP_Button PowerLevelMinTime PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay SetCmdOff SetCmdOn TimeStart TimeEnd
attr LWP room Strom->Photovoltaik
attr LWP setList LWP_Button:uzsuToggle,on,off PowerLevelMinTime:slider,60,30,300 PowerLimitOn:slider,1000,250,4000 PowerLimitOff:slider,1000,250,4000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,900,300,28800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr LWP sortby 05
attr LWP stateFormat state
attr LWP verbose 0
attr LWP webCmd LWP_Button

setstate LWP off
setstate LWP 2020-08-05 17:38:03 LWP_Button off
setstate LWP 2020-03-02 11:56:45 PowerLevelMinTime 600
setstate LWP 2020-02-05 14:11:42 PowerLimitOff 2250
setstate LWP 2020-03-02 11:56:39 PowerLimitOn 3000
setstate LWP 2019-08-02 10:31:21 RunTimeMin 3600
setstate LWP 2020-02-05 14:13:01 RunTimePerDay 28800
setstate LWP 2019-12-29 10:47:55 SetCmdOff set shelly01 off 0
setstate LWP 2019-07-22 15:35:59 SetCmdOn set shelly01 on 0
setstate LWP 2019-11-09 12:13:04 TimeEnd 16:00
setstate LWP 2020-04-02 13:51:54 TimeStart 12:30
setstate LWP 2020-08-05 17:38:03 state off
</syntaxhighlight>
==== RAW Definition LWP_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod LWP_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
##\
([LWP_Counter:pulseTimePerDay] >= [LWP:RunTimePerDay] and\
[LWP_Counter:pulseTimeIncrement] >= [LWP:RunTimeMin] and\
[LWP:state] ne "off" and [LWP:LWP_Button] eq "off" )\
\
({Log 3, " LWP_PV cmd_1 PV : LWP off"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
)\
################################################################################################################\
## 2 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und die PV Produktion unter dem Mindestbedarf ist\
##\
DOELSEIF\
( ([PV_Anlage_1:Total_PV_Power_reserve]+[StromZaehler_Heizung:SMAEM1901401955_Bezug_Wirkleistung]) < [LWP:PowerLimitOff] and\
[LWP_Counter:pulseTimeIncrement] >= [LWP:RunTimeMin] and\
[LWP:state] ne "off" and\
[LWP:LWP_Button] ne "on" )\
\
({Log 3, " LWP_PV cmd_2 PV : LWP off"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
)\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4 wieder außerkraft,\
## wenn wärend der Wartezeit die PV Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [LWP:PowerLimitOff] and\
[LWP_PV:wait_timer] ne "no timer" and\
[LWP_PV:wait_timer] ne "" and\
[LWP:state] eq "off" )\
\
({Log 3, "LWP_PV cmd_3 PV : Stop wait timer LWP"})\
################################################################################################################\
## 4 Eigenverbrauch einschalten: wenn PV Produktion über dem Mindestbedarf ist und die Laufzeit pro Tag noch nicht erreicht ist\
##\
DOELSEIF\
([Astro:ObsSeason] ne "Sommer" and [Astro:ObsSeason] ne "Frühling" and\
[PV_Anlage_1:Total_PV_Power_reserve] >= [LWP:PowerLimitOn] and\
[[LWP:TimeStart]-[LWP:TimeEnd]] and\
[LWP:state] eq "off" and\
[LWP_Counter:pulseTimePerDay] < [LWP:RunTimePerDay] and\
[Heizung:hotWaterTemperature] < 60 )\
\
({Log 3, "LWP_PV cmd_4 : LWP on"}\
{fhem("".ReadingsVal("LWP","SetCmdOn",0))}\
{fhem("set LWP on")}\
{fhem("set Heizung hotWaterTemperatureTarget 60.0")}\
)\
################################################################################################################\
## 5 Signal für den PV-Modus der LWP einschalten.\
##\
DOELSEIF\
([LWP:LWP_Button] eq "on" )\
\
({Log 3, "LWP_PV cmd_5 PV : LWP on for manuel PV-Modus"}\
{fhem("".ReadingsVal("LWP","SetCmdOn",0))}\
{fhem("set LWP on")}\
{fhem("set Heizung hotWaterTemperatureTarget 60.0")}\
)\
################################################################################################################\
## 6 Signal für den PV-Modus der LWP abschalten.\
##\
DOELSEIF\
([LWP:LWP_Button] eq "off" and\
[$SELF:cmd_nr] eq "5" )\
\
({Log 3, "LWP_PV cmd_6 PV : LWP off after manuel PV-Modus"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
)\
################################################################################################################\
## 7 Stop wait Timer für das Abschalten, wenn die LWP beim Starten noch anläuft\
##\
DOELSEIF\
([StromZaehler_Heizung:SMAEM1901401955_Bezug_Wirkleistung] > 300 and\
[Heizung:opStateHeatPump1] eq "Wärmepumpe kommt" and\
[Heizung:opStateHeatPump3] eq "Pumpenvorlauf" )\
\
({Log 3, "LWP_PV cmd_7 : Stop wait timer LWP"})\
################################################################################################################\
## 8 LWP Ende\
##\
DOELSEIF\
([StromZaehler_Heizung:SMAEM1901401955_Bezug_Wirkleistung] < 300 and\
[LWP_Counter:pulseTimeIncrement] >= [LWP:RunTimeMin] and\
([Heizung:opStateHeatPump1] ne "Wärmepumpe läuft" or [Heizung:opStateHeatPump3] eq "Luftabtauen" ) and\
([$SELF:cmd_nr] eq "4" or [$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "10") )\
\
({Log 3, "LWP_PV cmd_8 : LWP run finished"}\
{fhem("".ReadingsVal("LWP","SetCmdOff",0))}\
{fhem("set LWP off")}\
{fhem("set Heizung hotWaterTemperatureTarget 50.0")}\
{fhem("setreading LWP LWP_Button off")}\
)\
################################################################################################################\
## 9 LWP Zwangseinschalten: Sollte das Brauchwasser noch nicht aufgeheizt sein, wird um die Hysterese erhöht.\
## Dies kann passieren, wenn am Tag vorher der PV-Modus lief und dann das Wasser noch knapp über dem Mindestwert ist.\
##\
DOELSEIF\
([Astro:ObsSeason] ne "Sommer" and [Astro:ObsSeason] ne "Frühling" and\
[[LWP:TimeEnd]] and\
[Heizung:hotWaterTemperature] < 47 and\
([LWP_Counter:pulseTimePerDay] < [Pool:RunTimePerDay] or\
[LWP_Counter:countsPerDay] eq 0) )\
\
({Log 3, "LWP_PV cmd_9 : LWP on for water heating"}\
\
{fhem("set Heizung hotWaterTemperatureTarget ". (ReadingsVal("Heizung","hotWaterTemperature",46)+4))}\
\
{Log 3, "LWP_PV cmd_9 : LWP hotWaterTemperatureTarget ".ReadingsVal("Heizung","hotWaterTemperatureTarget",0)}\
)\
################################################################################################################\
## 10 Hohe Priorität im Winter fuer die LWP\
## Einschalten, wenn der Pool läuft, der Speicher geladen ist und noch Überschuss da ist.\
##\
DOELSEIF\
([Astro:ObsSeason] eq "Winter" and\
[PV_Anlage_1:Total_PV_Power_reserve] >= 2000 and\
[shelly02:power_0] > 800 and\
[PV_Anlage_1:Act_state_of_charge] > 60 and\
[Heizung:hotWaterTemperature] < 60 and \
[$SELF:cmd_nr] ne "10" )\
\
({Log 3, "LWP_PV cmd_10 : LWP Priorität"}\
{fhem("set LWP_PV cmd_4")}\
)\

attr LWP_PV DbLogExclude .*
attr LWP_PV DbLogInclude state,cmd.*,Device,LWP_Status,wait_timer
attr LWP_PV alias LWP_PV
attr LWP_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch aus|Stop wait timer|Eigenverbrauch ein|LWP ein für manuellen PV-Modus|LWP aus nach manuellem PV-Modus|Stop wait timer fuer aus|LWP aus nach PV-Modus|LWP Brauchwasser nachheizen|LWP Priorität
attr LWP_PV do always
attr LWP_PV group PV Eigenverbrauch-Steuerung
attr LWP_PV icon sani_earth_source_heat_pump
attr LWP_PV room Strom->Photovoltaik
attr LWP_PV sortby 01
attr LWP_PV stateFormat state : LWP_Status : Brauchwasser e_Heizung_hotWaterTemperature °C
attr LWP_PV userReadings LWP_Status { ReadingsVal("Heizung","state","") }
attr LWP_PV verbose 5
attr LWP_PV wait 0:10:0:[LWP:PowerLevelMinTime]:0:0:900:0:0
</syntaxhighlight>
- RAW Definition LWP_Signale (Shelly Modul: shelly1pm)
<syntaxhighlight lang="Perl">
defmod shelly01 Shelly 192.168.178.55
attr shelly01 DbLogExclude .*
attr shelly01 DbLogInclude relay.*,power.*,energy.*
attr shelly01 alias LWP_Signale
attr shelly01 event-on-change-reading relay.*,power.*,energy.*,state,network
attr shelly01 group PV Eigenverbrauch-Steuerung
attr shelly01 icon taster_ch_1
attr shelly01 mode relay
attr shelly01 model shelly1pm
attr shelly01 room Shelly,Heizung->System,Strom->Photovoltaik
attr shelly01 sortby 02
attr shelly01 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Gesamt 0: %08.2f KWh<br>\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
ReadingsVal($name,"WebLink","none") ,\
ReadingsVal($name,"energy_0",0)/1000,\
(ReadingsVal($name,"relay","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power",0),\
)}
attr shelly01 userReadings WebLink:network { my $ip=ReadingsVal($NAME,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") }
attr shelly01 webCmd |
</pre>
==== RAW Definition LWP_Counter (HourCounter Modul) ====
<pre>
defmod LWP_Counter HourCounter LWP:on.* LWP:off
attr LWP_Counter DbLogExclude .*
attr LWP_Counter alias LWP_Counter
attr LWP_Counter event-min-interval .*:600
attr LWP_Counter event-on-change-reading .*
attr LWP_Counter group PV Eigenverbrauch-Steuerung
attr LWP_Counter icon time_timer
attr LWP_Counter interval 5
attr LWP_Counter room Strom->Photovoltaik
attr LWP_Counter sortby 03
attr LWP_Counter verbose 0
</syntaxhighlight>
==== RAW Definition rg_LWP_Status (readingsGroup Modul) ====
<syntaxhighlight lang="Perl">
defmod rg_LWP_Status readingsGroup <Device>,<Information>,<Wert> LWP:<Status>,state LWP:<PowerLevelMinTime>,PowerLevelMinTime LWP:<PowerLimitOn>,PowerLimitOn LWP:<PowerLimitOff>,PowerLimitOff LWP:<TimeStart>,!TimeStart LWP:<TimeEnd>,!TimeEnd LWP:<RunTimeMin>,RunTimeMin LWP_Counter:<RunTimeMin>,pulseTimeIncrement LWP:<RunTimePerDay>,RunTimePerDay LWP_Counter:<RunTimePerDay>,pulseTimePerDay LWP_PV:<wait>,wait_timer LWP_PV:<TimeStart>,timer_01_c04 LWP_PV:<TimeEnd>,timer_02_c04
attr rg_LWP_Status DbLogExclude .*
attr rg_LWP_Status alias Status LuftWärmePumpe Eigenverbrauch
attr rg_LWP_Status commands {state => 'state:on,off',\
PowerLevelMinTime => 'PowerLevelMinTime:selectnumbers,60,60,600,0,lin',\
PowerLimitOn => 'PowerLimitOn:selectnumbers,1000,250,4000,0,lin',\
PowerLimitOff => 'PowerLimitOff:selectnumbers,1000,250,4000,0,lin',\
RunTimeMin => 'RunTimeMin:selectnumbers,300,300,14400,0,lin',\
RunTimePerDay => 'RunTimePerDay:selectnumbers,300,300,28800,0,lin',\
TimeStart => 'TimeStart:time',\
TimeEnd => 'TimeEnd:time'}
attr rg_LWP_Status group PV Status
attr rg_LWP_Status nameStyle style="color:grey"
attr rg_LWP_Status room Strom->Photovoltaik
attr rg_LWP_Status sortby 01
attr rg_LWP_Status style style="font-size:18px"
</syntaxhighlight>

=== Beispiel Pool===
==== RAW Definition Pool_Softube (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod Pool dummy
attr Pool DbLogExclude .*
attr Pool DbLogInclude state
attr Pool alias Pool_Softube
attr Pool event-on-change-reading .*
attr Pool group PV Eigenverbrauch
attr Pool icon scene_swimming
attr Pool readingList Pool_Button PowerLevelMinTime PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay RunTimePerDaySummer RunTimePerDayWinter SetCmdOff SetCmdOn TimeStart TimeEnd
attr Pool room Strom->Photovoltaik
attr Pool setList Pool_Button:uzsuToggle,on,off PowerLevelMinTime:slider,30,30,300 PowerLimitOn:slider,500,100,1500 PowerLimitOff:slider,0,100,1000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,900,300,64800 RunTimePerDaySummer:slider,900,300,7200 RunTimePerDayWinter:slider,3600,900,64800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr Pool sortby 06
attr Pool stateFormat state
attr Pool verbose 0
attr Pool webCmd Pool_Button

setstate Pool off
setstate Pool 2020-08-28 13:30:10 Pool_Button off
setstate Pool 2019-12-02 10:31:26 PowerLevelMinTime 600
setstate Pool 2019-11-13 10:58:18 PowerLimitOff 800
setstate Pool 2019-11-06 11:49:00 PowerLimitOn 1000
setstate Pool 2020-08-14 16:26:09 RunTimeMin 1800
setstate Pool 2020-08-28 06:15:00 RunTimePerDay 3600
setstate Pool 2020-08-16 13:17:45 RunTimePerDaySummer 3600
setstate Pool 2020-08-25 19:32:33 RunTimePerDayWinter 14400
setstate Pool 2019-08-01 14:18:08 SetCmdOff set shelly02 off 0
setstate Pool 2019-08-02 09:33:06 SetCmdOn set shelly02 on 0
setstate Pool 2019-10-31 21:53:28 TimeEnd 16:00
setstate Pool 2020-04-08 18:19:29 TimeStart 12:30
setstate Pool 2020-08-28 14:13:02 state off
</syntaxhighlight>
==== RAW Definition Pool_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod Pool_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
##\
([Pool_Counter:pulseTimePerDay] >= [Pool:RunTimePerDay] and\
[Pool_Counter:pulseTimeIncrement] >= [Pool:RunTimeMin] and\
[Pool:state] eq "on" and [Pool:Pool_Button] eq "off" )\
\
({Log 3, "Pool_PV cmd_1 : Pool off"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")} )\
################################################################################################################\
## 2 Eigenverbrauch abschalten: wenn Mindestlaufzeit erreicht wurde und die PV-Produktion unter dem Mindestbedarf ist.\
## Bei Pool Nutzung und Pflegeprogramm wird nicht abgeschaltet.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Pool:PowerLimitOff] and\
[Pool_Counter:pulseTimeIncrement] >= [Pool:RunTimeMin] and\
[Pool:state] eq "on" and \
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" and [$SELF:cmd_nr] ne "10" )\
\
({Log 3, "Pool_PV cmd_2 : Pool off"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")}\
{fhem("setreading Pool Pool_Button off")} )\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer Peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4 wieder außer kraft,\
## wenn während der Wartezeit die PV-Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Pool:PowerLimitOff] and\
[$SELF:wait_timer] ne "no timer" and\
[$SELF:wait_timer] ne "" and\
[Pool:state] eq "off" )\
\
({Log 3, "Pool_PV cmd_3 : Stop wait timer Pool"})\
################################################################################################################\
## 4 Eigenverbrauch einschalten: wenn PV-Produktion über dem Mindestbedarf ist und PV-Strom ins Netz eingespeist wird\
## und die Laufzeit pro Tag noch nicht erreicht ist;; Bei über 7000 Watt Einspeisung sofort aktivieren\
##\
DOELSEIF\
(([PV_Anlage_1:Total_PV_Power_reserve] >= [Pool:PowerLimitOn] and\
[[Pool:TimeStart]-[Pool:TimeEnd]] and\
[Pool:state] eq "off" and\
[Pool_Counter:pulseTimePerDay] < [Pool:RunTimePerDay]\
) or\
[PV_Anlage_1:Total_active_power_(powermeter)] <= -7000\
)\
\
({Log 3, "Pool_PV cmd_4 : Pool on"}\
{fhem("set Pool_Counter pulseTimeIncrement 0")}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 5 Steckdose für die Benutzung des Pools einschalten.\
##\
DOELSEIF\
([Pool:Pool_Button] eq "on" )\
\
({Log 3, "Pool_PV cmd_5 : Pool on for usage"}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 6 Steckdose des Pools abschalten.\
##\
DOELSEIF\
([Pool:Pool_Button] eq "off" and\
[$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7")\
\
({Log 3, "Pool_PV cmd_6 : Pool off after usage"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")} )\
################################################################################################################\
## 7 Stop wait Timer für das Abschalten, wenn die Pumpe beim Starten noch anläuft\
##\
DOELSEIF\
([shelly02:power_0] > 10 and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7" or [$SELF:cmd_nr] eq "9") and\
[$SELF:wait_timer] ne "no timer" and\
[$SELF:wait_timer] ne "" and\
[Pool:state] eq "on" )\
\
({Log 3, "Pool_PV cmd_7 : Stop wait timer Pool"})\
################################################################################################################\
## 8 Pool Ende\
##\
DOELSEIF\
([shelly02:power_0] < 10 and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7" or [$SELF:cmd_nr] eq "9") )\
\
({Log 3, "Pool_PV cmd_8 : Pool run finished"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")}\
{fhem("setreading Pool Pool_Button off")} )\
################################################################################################################\
## 9 Pflege Zwangseinschaltung: Es muss mindestens einmal pro Tag eingeschaltet werden, auch wenn kein PV Strom vorhanden war.\
##\
DOELSEIF\
([[Pool:TimeEnd]] and\
([Pool_Counter:pulseTimePerDay] < [Pool:RunTimePerDay] or\
[Pool_Counter:countsPerDay] eq 0)\
)\
\
({Log 3, "Pool_PV cmd_9 : Pool on for maintanance"}\
{fhem("set Pool_Counter pulseTimeIncrement 0")}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 10 Pflege Zwangseinschaltung bei günstigem Strom nachts im Winter\
##\
DOELSEIF\
([Astro:ObsSeason] eq "Winter" and\
[Strom_Kosten:aWATTar_Trigger] eq "on" and\
[22:00-05:00]\
)\
\
({Log 3, "Pool_PV cmd_10 : Pool on for maintanance by aWATTar"}\
{fhem("set Pool_Counter pulseTimeIncrement 0")}\
{fhem("".ReadingsVal("Pool","SetCmdOn",0))}\
{fhem("set Pool on")} )\
################################################################################################################\
## 11 Abschaltung bei teurem Strom\
##\
DOELSEIF\
([Astro:ObsSeason] eq "Winter" and\
[Strom_Kosten:aWATTar_Trigger] eq "off" and\
[$SELF:cmd_nr] eq "10"\
)\
\
({Log 3, "Pool_PV cmd_11 : Pool off after maintanance by aWATTar"}\
{fhem("".ReadingsVal("Pool","SetCmdOff",0))}\
{fhem("set Pool off")} )\
################################################################################################################\
## 12 Pool durch kürzere Laufzeit abkühlen lassen\
##\
DOELSEIF\
([06:15] and [Heizung:averageAmbientTemperature])\
\
(\
{ if ( [Heizung:averageAmbientTemperature] >= 18 )\
{fhem("setreading Pool RunTimePerDay ".ReadingsVal("Pool","RunTimePerDaySummer",0) )}\
else \
{fhem("setreading Pool RunTimePerDay ".ReadingsVal("Pool","RunTimePerDayWinter",0) )}\
},\
{Log 3, "Pool_PV cmd_12 : Pool RunTimePerDay switched"}\
)\
\

attr Pool_PV DbLogExclude .*
attr Pool_PV DbLogInclude cmd.*,state,cmd.*,Device,Pool_Pumpe_Status,wait_timer
attr Pool_PV alias Pool_PV
attr Pool_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch aus|Stop wait timer|Eigenverbrauch freigegeben|Pool ein für Benutzung|Pool aus nach Benutzung|Stop wait timer für aus|Pool aus|Pflegemodus ohne PV|Strombörse ein|Strombörse aus|RunTimePerDay switched
attr Pool_PV disable 0
attr Pool_PV do always
attr Pool_PV event-on-change-reading .*
attr Pool_PV group PV Eigenverbrauch-Steuerung
attr Pool_PV icon scene_swimming
attr Pool_PV room Strom->Photovoltaik
attr Pool_PV sortby 11
attr Pool_PV stateFormat state : Pool_Pumpe_Status
attr Pool_PV userReadings Pool_Pumpe_Status { ReadingsVal("shelly02","power_0",0)>10 ? "Pool_Pumpe_laeuft" : "Pool_Pumpe_aus"}
attr Pool_PV verbose 0
attr Pool_PV wait 0:10:0:[Pool:PowerLevelMinTime]:0:0:0:300:0:300
</syntaxhighlight>
==== RAW Definition Pool_Signale (Shelly Modul: shelly1pm) ====
<syntaxhighlight lang="Perl">
defmod shelly02 Shelly 192.168.178.52
attr shelly02 DbLogExclude .*
attr shelly02 DbLogInclude relay.*,power.*,energy.*
attr shelly02 alias Pool_Signale
attr shelly02 comment relais_0 => Pool limit 1000 W\
relail_1 => Terrasse Lichterkette limit 100 W
attr shelly02 event-on-change-reading relay.*,power.*,energy.*,state,network
attr shelly02 group PV Eigenverbrauch-Steuerung
attr shelly02 icon taster_ch_1
attr shelly02 mode relay
attr shelly02 model shelly2.5
attr shelly02 room Shelly,Strom->Photovoltaik
attr shelly02 sortby 12
attr shelly02 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
Status: %s<br>\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Gesamt 0: %08.2f KWh<br>Gesamt 1: %08.2f KWh\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
Relais 1: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
(ReadingsVal($name,"state","none") eq "OK") ? "<span style='color:#00FF00'>OK</span>":"<span style='color:#FF0000'>Error</span>",\
ReadingsVal($name,"WebLink","none") ,\
ReadingsVal($name,"energy_0",0)/1000,\
ReadingsVal($name,"energy_1",0)/1000,\
(ReadingsVal($name,"relay_0","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power_0",0),\
(ReadingsVal($name,"relay_1","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power_1",0)\
)}
attr shelly02 userReadings WebLink:network { my $ip=ReadingsVal($name,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") }
attr shelly02 verbose 0
attr shelly02 webCmd |
</syntaxhighlight>
==== RAW Definition Pool_Counter (HourCounter Modul) ====
<syntaxhighlight lang="Perl">
defmod Pool_Counter HourCounter shelly02:power_0:\s[0-9]{2,}(\.[0-9]{1,2})*$ shelly02:power_0:\s[0-9]{1}(\.[0-9]{1,2})*$
attr Pool_Counter DbLogExclude .*
attr Pool_Counter alias Pool_Counter
attr Pool_Counter comment On und Off des Pools werden direkt über den Shelly Stromverbrauch getriggert.
attr Pool_Counter event-on-change-reading .*
attr Pool_Counter group PV Eigenverbrauch-Steuerung
attr Pool_Counter icon time_timer
attr Pool_Counter interval 5
attr Pool_Counter room Strom->Photovoltaik
attr Pool_Counter sortby 13
attr Pool_Counter verbose 0
</syntaxhighlight>
==== RAW Definition rg_Pool_Status (readingsGroup Modul) ====
<syntaxhighlight lang="Perl">
defmod rg_Pool_Status readingsGroup <Device>,<Information>,<Wert> Pool:<Status>,!state Pool:<PowerLevelMinTime>,!PowerLevelMinTime Pool:<PowerLimitOn>,!PowerLimitOn Pool:<PowerLimitOff>,!PowerLimitOff Pool:<TimeStart>,!TimeStart Pool:<TimeEnd>,!TimeEnd Pool:<RunTimeMin>,!RunTimeMin Pool_Counter:<RunTimeMin>,!pulseTimeIncrement Pool:<RunTimePerDay>,!RunTimePerDay Pool:<RunTimePerDaySummer>,!RunTimePerDaySummer Pool:<RunTimePerDayWinter>,!RunTimePerDayWinter Pool_Counter:<RunTimePerDay>,!pulseTimePerDay Pool_PV:<wait>,wait_timer Pool_PV:<TimeStart>,timer_01_c04 Pool_PV:<TimeEnd>,timer_02_c04
attr rg_Pool_Status DbLogExclude .*
attr rg_Pool_Status alias Status Softube Pool Eigenverbrauch
attr rg_Pool_Status commands {state => 'state:on,off',\
PowerLevelMinTime => 'PowerLevelMinTime:selectnumbers,60,30,600,0,lin',\
PowerLimitOn => 'PowerLimitOn:selectnumbers,500,250,1500,0,lin',\
PowerLimitOff => 'PowerLimitOff:selectnumbers,0,100,1000,0,lin',\
RunTimeMin => 'RunTimeMin:selectnumbers,300,300,14400,0,lin',\
RunTimePerDaySummer => 'RunTimePerDaySummer:selectnumbers,300,300,3600,0,lin',\
RunTimePerDayWinter => 'RunTimePerDayWinter:selectnumbers,3600,900,64800,0,lin',\
TimeStart => 'TimeStart:time',\
TimeEnd => 'TimeEnd:time'}
attr rg_Pool_Status group PV Status
attr rg_Pool_Status nameStyle style="color:grey"
attr rg_Pool_Status room Strom->Photovoltaik
attr rg_Pool_Status sortby 02
attr rg_Pool_Status style style="font-size:18px"
</syntaxhighlight>

=== Beispiel Waschmaschine (mit Walzenschalter ;-) ) ===
==== RAW Definition Waschmaschine (dummy Modul) ====
<syntaxhighlight lang="Perl">
defmod Waschmaschine dummy
attr Waschmaschine DbLogExclude .*
attr Waschmaschine DbLogInclude state
attr Waschmaschine alias Waschmaschine
attr Waschmaschine group PV Eigenverbrauch
attr Waschmaschine icon scene_washing_machine
attr Waschmaschine readingList Waschmaschine_Button PowerLevelMinTime PowerPhaseUse PowerLimitOn PowerLimitOff RunTimeMin RunTimePerDay SetCmdOff SetCmdOn TimeStart TimeEnd
attr Waschmaschine room Strom->Photovoltaik
attr Waschmaschine setList Waschmaschine_Button:uzsuToggle,on,off PowerLevelMinTime:slider,30,30,300 PowerLimitOn:slider,250,250,2000 PowerLimitOff:slider,0,250,1000 RunTimeMin:slider,300,300,7200 RunTimePerDay:slider,7200,300,28800 SetCmdOff SetCmdOn TimeStart:time TimeEnd:time
attr Waschmaschine sortby 07
attr Waschmaschine stateFormat state
attr Waschmaschine verbose 0
attr Waschmaschine webCmd Waschmaschine_Button

setstate Waschmaschine off
setstate Waschmaschine 2019-12-02 10:29:49 PowerLevelMinTime 300
setstate Waschmaschine 2019-11-06 10:56:22 PowerLimitOff 250
setstate Waschmaschine 2020-04-20 13:06:04 PowerLimitOn 2000
setstate Waschmaschine 2019-12-02 15:01:18 RunTimeMin 5400
setstate Waschmaschine 2020-04-02 13:59:34 RunTimePerDay 19200
setstate Waschmaschine 2020-01-01 16:29:10 SetCmdOff set shelly03 off 0
setstate Waschmaschine 2020-01-01 16:29:24 SetCmdOn set shelly03 on 0
setstate Waschmaschine 2019-08-01 14:25:25 TimeEnd 18:00
setstate Waschmaschine 2019-10-28 09:13:30 TimeStart 09:00
setstate Waschmaschine 2020-08-27 16:17:23 Waschmaschine_Button off
setstate Waschmaschine 2020-08-28 16:29:42 state off
</syntaxhighlight>
==== RAW Definition Waschmaschine_PV (DOIF Modul) ====
<syntaxhighlight lang="Perl">
defmod Waschmaschine_PV DOIF ################################################################################################################\
## 1 Eigenverbrauch sperren: wenn Mindestlaufzeit erreicht wurde und Maximallaufzeit pro Tag erreicht ist\
## jedoch nicht wenn manueller Betrieb aktiv ist.\
##\
([Waschmaschine_Counter:pulseTimePerDay] >= [Waschmaschine:RunTimePerDay] and\
[Waschmaschine_Counter:pulseTimeIncrement] >= [Waschmaschine:RunTimeMin] and\
[Waschmaschine:state] eq "on" and [Waschmaschine:Waschmaschine_Button] eq "off" )\
\
({Log 3, "Waschmaschine cmd_1 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
{fhem("set Waschmaschine off")}\
)\
################################################################################################################\
## 2 Eigenverbrauch sperren: wenn Mindestlaufzeit erreicht wurde und die PV-Produktion unter dem Mindestbedarf ist\
## ausser bei manuellem Einschalten und wenn das Waschprogramm bereits läuft\
##\
## ([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOff] and\
## [Waschmaschine_Counter:pulseTimeIncrement] >= [Waschmaschine:RunTimeMin] and\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOn] and\
[Waschmaschine:state] eq "on" and\
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" )\
\
({Log 3, "Waschmaschine cmd_2 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
{fhem("set Waschmaschine off")}\
)\
################################################################################################################\
## 3 Stop, wenn es nur ein kurzer Peak ist. Dieser Do Zweig setzt den wait timer vom Einschaltkommando cmd_4\
## wieder außer kraft, wenn während der Wartezeit die PV-Anlage zuwenig liefert.\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOff] and\
[Waschmaschine_PV:wait_timer] ne "no timer" and\
[Waschmaschine_PV:wait_timer] ne "" and\
[Waschmaschine:state] eq "off" )\
\
({Log 3, "Waschmaschine cmd_3 : Waschmaschine stop wait timer"})\
################################################################################################################\
## 4 Eigenverbrauch freigeben: wenn PV-Produktion über dem Mindestbedarf ist und PV-Strom ins Netz eingespeist\
## wird und die Laufzeit pro Tag noch nicht erreicht ist\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] > [Waschmaschine:PowerLimitOn] and\
[Waschmaschine:state] eq "off" and\
[[Waschmaschine:TimeStart]-[Waschmaschine:TimeEnd]] and\
[Waschmaschine_Counter:pulseTimePerDay] < [Waschmaschine:RunTimePerDay] )\
\
({Log 3, "Waschmaschine cmd_4 : Waschmaschine freigabe"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOn",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist eingeschaltet")}\
{fhem("set Waschmaschine on")}\
)\
################################################################################################################\
## 5 Steckdose manuell für die Benutzung der Waschmaschine einschalten.\
##\
DOELSEIF\
([Waschmaschine:Waschmaschine_Button] eq "on" )\
\
({Log 3, "Waschmaschine cmd_5 : Waschmaschine manuell ein"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOn",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist eingeschaltet")}\
{fhem("set Waschmaschine on")}\
)\
################################################################################################################\
## 6 Steckdose der Waschmaschine manuell abschalten.\
##\
DOELSEIF\
([Waschmaschine:Waschmaschine_Button] eq "off" and\
([$SELF:cmd_nr] eq "5" or [$SELF:cmd_nr] eq "7") )\
\
({Log 3, "Waschmaschine cmd_6 : Waschmaschine manuell aus"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
{fhem("set Waschmaschine off")}\
)\
################################################################################################################\
## 7 Statuswechsel wenn das Waschprogramm gestartet ist\
##\
DOELSEIF\
([shelly03:power] > 0 and\
[shelly03:power_Waschmaschine_avg] < 70 and\
[$SELF:cmd_nr] ne "7")\
\
({Log 3, "Waschmaschine cmd_7 : Waschmaschine Programm gestarted"}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Waschprogramm gestartet")}\
)\
################################################################################################################\
## 8 Abschalten der Steckdose beim Waschprogramm Ende\
##\
DOELSEIF\
([shelly03:power] == 0 and\
[shelly03:power_Waschmaschine_avg] > 0 and\
[$SELF:cmd_nr] eq "7" )\
\
({Log 3, "Waschmaschine cmd_8 : Waschmaschine aus"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("set Waschmaschine off")}\
{fhem("setreading Waschmaschine Waschmaschine_Button off")}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Waschprogramm beendet")}\
)\
################################################################################################################\
## 9 Abschalten der Steckdose wenn die Waschmaschine nicht gebraucht wurde\
##\
DOELSEIF\
([PV_Anlage_1:Total_PV_Power_reserve] < [Waschmaschine:PowerLimitOn] and\
[[Waschmaschine:TimeEnd]-[Waschmaschine:TimeStart]] and\
[Waschmaschine:state] eq "on" and\
[$SELF:cmd_nr] ne "5" and [$SELF:cmd_nr] ne "7" )\
\
({Log 3, "Waschmaschine cmd_9 : Eigenverbrauch sperren"}\
{fhem("".ReadingsVal("Waschmaschine","SetCmdOff",0))}\
{fhem("set Waschmaschine off")}\
{fhem("setreading Waschmaschine Waschmaschine_Button off")}\
{fhem("setreading Waschmaschine_PV Waschmaschine_Status Steckdose ist ausgeschaltet")}\
)
attr Waschmaschine_PV DbLogExclude .*
attr Waschmaschine_PV DbLogInclude state,STATE,cmd.*,Device,Waschmaschine_Status,wait_timer
attr Waschmaschine_PV alias Waschmaschine_PV
attr Waschmaschine_PV cmdState Maximalzeit pro Tag überschritten|Eigenverbrauch gesperrt|Stop wait timer|Eigenverbrauch freigegeben|Waschmaschine manuell ein|Waschmaschine manuell aus|Waschmaschine laeuft|Waschmaschine aus|Eigenverbrauch gesperrt
attr Waschmaschine_PV do always
attr Waschmaschine_PV group PV Eigenverbrauch-Steuerung
attr Waschmaschine_PV icon scene_washing_machine
attr Waschmaschine_PV room Strom->Photovoltaik
attr Waschmaschine_PV sortby 21
attr Waschmaschine_PV stateFormat state : Waschmaschine_Status
attr Waschmaschine_PV verbose 0
attr Waschmaschine_PV wait 0:0:0:[Waschmaschine:PowerLevelMinTime]:0:30:0:60:30
</syntaxhighlight>
==== RAW Definition Waschmaschine_Signale (Shelly Modul: shelly1pm) ====
<syntaxhighlight lang="Perl">
defmod shelly03 Shelly 192.168.178.54
attr shelly03 DbLogExclude .*
attr shelly03 DbLogInclude relay.*,power.*,energy.*
attr shelly03 alias Waschmaschine_Signale
attr shelly03 event-on-change-reading relay.*,power.*,energy.*,network
attr shelly03 group PV Eigenverbrauch-Steuerung
attr shelly03 icon taster_ch_1
attr shelly03 interval 60
attr shelly03 mode relay
attr shelly03 model shelly1pm
attr shelly03 room Shelly,Strom->Photovoltaik
attr shelly03 sortby 22
attr shelly03 stateFormat {sprintf("\
<TABLE>\
\
<TR>\
<TD VALIGN=\"TOP\" ALIGN=\"LEFT\" WIDTH=\"50\">\
WebLink: %s\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"100\">\
Gesamt 0: %08.2f KWh<br>\
</TD>\
\
<TD VALIGN=\"TOP\" ALIGN=\"RIGHT\" WIDTH=\"70\">\
Relais 0: %s %06.1f Watt<br>\
</TD>\
</TR>\
\
</TABLE>\
" ,\
ReadingsVal($name,"WebLink","none") ,\
ReadingsVal($name,"energy",0)/1000,\
(ReadingsVal($name,"relay","") eq "off") ? "<span style='color:#FF0000'>off</span>":"<span style='color:#00FF00'>on</span>",\
ReadingsVal($name,"power",0)\
)}
attr shelly03 userReadings WebLink:network { my $ip=ReadingsVal($NAME,"network","");; $ip =~ s/connected to //gs;; $ip =~ s/<[^>]*>//gs;; return("<html><a href='http://".$ip."/'>WEB</a></html>") },\
power_Waschmaschine_avg:power.* { movingAverage($NAME,"power",300) }
attr shelly03 webCmd |
</syntaxhighlight>
==== RAW Definition Waschmaschine_Counter (HourCounter Modul) ====
<syntaxhighlight lang="Perl">
defmod Waschmaschine_Counter HourCounter Waschmaschine_PV:.*laeuft Waschmaschine_PV:Waschmaschine_Status:.*[beendet|ausgeschaltet]
attr Waschmaschine_Counter DbLogExclude .*
attr Waschmaschine_Counter alias Waschmaschine_Counter
attr Waschmaschine_Counter event-on-change-reading .*
attr Waschmaschine_Counter group PV Eigenverbrauch-Steuerung
attr Waschmaschine_Counter icon time_timer
attr Waschmaschine_Counter interval 5
attr Waschmaschine_Counter room Strom->Photovoltaik
attr Waschmaschine_Counter sortby 23
attr Waschmaschine_Counter verbose 0
</syntaxhighlight>
==== RAW Definition rg_Waschmaschine_Status (readingsGroup Modul) ====
<syntaxhighlight lang="Perl">
defmod rg_Waschmaschine_Status readingsGroup <Device>,<Information>,<Wert> Waschmaschine:<Status>,!state Waschmaschine:<PowerLevelMinTime>,!PowerLevelMinTime Waschmaschine:<PowerLimitOn>,!PowerLimitOn Waschmaschine:<PowerLimitOff>,!PowerLimitOff Waschmaschine:<TimeStart>,!TimeStart Waschmaschine:<TimeEnd>,!TimeEnd Waschmaschine:<RunTimeMin>,!RunTimeMin Waschmaschine_Counter:<RunTimeMin>,!pulseTimeIncrement Waschmaschine:<RunTimePerDay>,!RunTimePerDay Waschmaschine_Counter:<RunTimePerDay>,!pulseTimePerDay Waschmaschine_PV:<wait>,wait_timer Waschmaschine_PV:<TimeStart>,timer_01_c04 Waschmaschine_PV:<TimeEnd>,timer_02_c04
attr rg_Waschmaschine_Status DbLogExclude .*
attr rg_Waschmaschine_Status alias Status Waschmaschine Eigenverbrauch
attr rg_Waschmaschine_Status commands {state => 'state:on,off',\
PowerLevelMinTime => 'PowerLevelMinTime:selectnumbers,30,30,300,0,lin',\
PowerLimitOn => 'PowerLimitOn:selectnumbers,250,250,2000,0,lin',\
PowerLimitOff => 'PowerLimitOff:selectnumbers,0,50,800,0,lin',\
RunTimeMin => 'RunTimeMin:selectnumbers,300,300,7200,0,lin',\
RunTimePerDay => 'RunTimePerDay:selectnumbers,7200,300,28800,0,lin',\
TimeStart => 'TimeStart:time',\
TimeEnd => 'TimeEnd:time'}
attr rg_Waschmaschine_Status group PV Status
attr rg_Waschmaschine_Status nameStyle style="color:grey"
attr rg_Waschmaschine_Status room Strom->Photovoltaik
attr rg_Waschmaschine_Status sortby 03
attr rg_Waschmaschine_Status style style="font-size:18px"
</syntaxhighlight>

== Problemlösung ==

== Projekte der FHEM-Community ==

* {{Link2Forum|Topic=102297|Message=958564}} - Photovoltaik mit Eigenverbrauch Steuerung (Kostal plenticore; EM410)
* {{Link2Forum|Topic=109875|Message=1038741}} - Kostal Plenticore Bilanz
* {{Link2Forum|Topic=108191|Message=1038741}} - Kostal Plenticore, EM410 (KSEM), BYD, Solarprognose, Forecast

* {{Link2Forum|Topic=53584}} - Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
* {{Link2Forum|Topic=45176}} - Neue Version von HTTPMOD mit neuen Features zum Testen

== Links ==

* [https://www.photovoltaikforum.com/thread/142261-programmatischer-lesender-und-schreibender-zugriff-auf-kostal-plenticore-z-b-min/?pageNo=1/ Zugriff mit Python auf den Plenticore]
* [https://www.photovoltaikforum.com/thread/144350-kostenlose-wetterprognose-pv-prognose-ertragsprogonse-mit-st%C3%BCndlicher-aufl%C3%B6sung/?pageNo=1/ Ertragsprognose mit DWD]
* [https://www.photovoltaikforum.com/thread/146383-eigenverbrauchssteuerung-verh%C3%A4lt-sich-mit-speicher-anders-als-ohne/?pageNo=1/ Eigenverbrauchssteuerung beim Plenticore]
* [https://github.com/kilianknoll/ Github Kilian DWD Forecast]
* [https://github.com/FL550/ Github FL550 DWD Forecast]

[[Kategorie:IP Components]]
[[Kategorie:Other Components]]
[[Kategorie:Energieerzeugungsmessung]]

Solar-/PV-Übersicht

2020-09-01T09:39:55Z

Plin53177:

'''Solar-/Photovoltaik-Übersicht'''

Diese Seite soll einen schnellen Einstieg in die für Solar-/Photovoltaik-Betreiber relevanten Seiten und Threads ermöglichen. Bitte bei Bedarf selbständig ergänzen.

=Forum=
* [https://forum.fhem.de/index.php/board,61.0.html Solaranlangen] Themen rund um Solaranlagen zur Wärme- oder Stromgewinnung

sowie aus dem Wiki:

=Wechselrichter=
==Kostal==
* [https://wiki.fhem.de/wiki/KostalPiko Kostal Piko]
* [https://wiki.fhem.de/wiki/Kostal_Plenticore_10_Plus Kostal Plenticore]

==SMA==
* [https://wiki.fhem.de/wiki/SMAWechselrichter SMA Wechselrichter]

==Solar Edge==
* [https://wiki.fhem.de/wiki/SolarEdge_SE10k Solar Edge SE10k]

=Speicher=
* [https://wiki.fhem.de/wiki/Sonnenspeicher Sonnenspeicher]

=Monitoring/Auswertung=
* [https://wiki.fhem.de/wiki/Enecsys_Monitoring_System Enecsys Monitoring System]
* [https://wiki.fhem.de/wiki/SunnyHomeManager SunnyHomeManager]
* [https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschusseinspeisung Datenbankgestützte Energiebilanz]

=Angrenzende Themen=
* [https://wiki.fhem.de/wiki/ModbusAttr ModBus]
* [https://wiki.fhem.de/wiki/SMLUSB SML USB]

== Links ==
* tbd

Solar-/PV-Übersicht

2020-09-01T09:38:19Z

Plin53177: Die Seite wurde neu angelegt: „'''Solar-/Photovoltaik-Übersicht''' Diese Seite soll einen schnellen Einstieg in die für Solar-/Photovoltaik-Betreiber relevanten Siten und Threads ermögl…“

'''Solar-/Photovoltaik-Übersicht'''

Diese Seite soll einen schnellen Einstieg in die für Solar-/Photovoltaik-Betreiber relevanten Siten und Threads ermöglichen. Bitte bei Bedarf selbständig ergänzen.

=Forum=
* [https://forum.fhem.de/index.php/board,61.0.html Solaranlangen] Themen rund um Solaranlagen zur Wärme- oder Stromgewinnung

sowie aus dem Wiki:

=Wechselrichter=
==Kostal==
* [https://wiki.fhem.de/wiki/KostalPiko Kostal Piko]
* [https://wiki.fhem.de/wiki/Kostal_Plenticore_10_Plus Kostal Plenticore]

==SMA==
* [https://wiki.fhem.de/wiki/SMAWechselrichter SMA Wechselrichter]

==Solar Edge==
* [https://wiki.fhem.de/wiki/SolarEdge_SE10k Solar Edge SE10k]

=Speicher=
* [https://wiki.fhem.de/wiki/Sonnenspeicher Sonnenspeicher]

=Monitoring/Auswertung=
* [https://wiki.fhem.de/wiki/Enecsys_Monitoring_System Enecsys Monitoring System]
* [https://wiki.fhem.de/wiki/SunnyHomeManager SunnyHomeManager]
* [https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschusseinspeisung Datenbankgestützte Energiebilanz]

=Angrenzende Themen=
* [https://wiki.fhem.de/wiki/ModbusAttr ModBus]
* [https://wiki.fhem.de/wiki/SMLUSB SML USB]

== Links ==
* tbd

Unbekannte Funkprotokolle

2020-01-20T19:01:00Z

Plin53177: /* Finale */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

=== Finale ===

Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.

Der SIGNALduino erkennt
<pre>
2020.01.12 14:33:03 4: mySIGNALduino: Parse_MS, Decoded matched MS Protocol id 88 dmsg P88#74D21B18008B48058 length 68 RSSI = -32
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, test ungleich: disabled
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, -32 dB, dispatch
2020.01.12 14:33:03 5: mySIGNALduino: dispatch P88#74D21B18008B48058
2020.01.12 14:33:04 2: mySIGNALduino: SD_Keeloq_Parse Unknown device unknown with Code 012D100 detected, please define (rawdate=74D21B18008B48058)
2020.01.12 14:33:04 2: autocreate: define SD_Keeloq_012D100 SD_Keeloq 012D100
2020.01.12 14:33:04 2: autocreate: define FileLog_SD_Keeloq_012D100 FileLog ./log/SD_Keeloq_012D100-%Y.log SD_Keeloq_012D100
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 91.1 -> Atlantic security
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=2 reconstructed, last bit=0
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 87 -> JAROLIFT
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=1 reconstructed, last bit=1
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 88 -> HCS300/HCS301
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
</pre>
und routet die Request an das Modul SD_Keeloq weiter. Der Hinweis auf HCS301 führt auf die richtige Spur. Das analysierte Protokoll KeeLoq ist im Data Sheet des Microchip HCS301 (KeeLoq Code Hopping Encoder) beschrieben. Somit wurde aus einem unbekannten Funkprotokoll letztlich ein bekanntes.

Mittlerweile ist das Protokoll als '''model enjoy_motors_HS''' in das Modul '''SD_Keeloq''' aufgenommen.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2020-01-16T16:38:46Z

Plin53177: /* Finale */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

=== Finale ===

Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.

Der SIGNALduino erkennt
<pre>
2020.01.12 14:33:03 4: mySIGNALduino: Parse_MS, Decoded matched MS Protocol id 88 dmsg P88#74D21B18008B48058 length 68 RSSI = -32
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, test ungleich: disabled
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, -32 dB, dispatch
2020.01.12 14:33:03 5: mySIGNALduino: dispatch P88#74D21B18008B48058
2020.01.12 14:33:04 2: mySIGNALduino: SD_Keeloq_Parse Unknown device unknown with Code 012D100 detected, please define (rawdate=74D21B18008B48058)
2020.01.12 14:33:04 2: autocreate: define SD_Keeloq_012D100 SD_Keeloq 012D100
2020.01.12 14:33:04 2: autocreate: define FileLog_SD_Keeloq_012D100 FileLog ./log/SD_Keeloq_012D100-%Y.log SD_Keeloq_012D100
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 91.1 -> Atlantic security
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=2 reconstructed, last bit=0
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 87 -> JAROLIFT
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=1 reconstructed, last bit=1
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 88 -> HCS300/HCS301
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
</pre>
und routet die Request an das Modul SD_Keeloq weiter. Der Hinweis auf HCS301 führt auf die richtige Spur. Das analysierte Protokoll KeeLoq ist im Data Sheet des Microchip HCS301 (KeeLoq Code Hopping Encoder) beschrieben. Somit wurde aus einem unbekannten Funkprotokoll letztlich ein bekanntes.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2020-01-12T20:02:47Z

Plin53177: /* Finale */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

=== Finale ===

Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.

Der SIGNALduino erkennt
<pre>
2020.01.12 14:33:03 4: mySIGNALduino: Parse_MS, Decoded matched MS Protocol id 88 dmsg P88#74D21B18008B48058 length 68 RSSI = -32
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, test ungleich: disabled
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, -32 dB, dispatch
2020.01.12 14:33:03 5: mySIGNALduino: dispatch P88#74D21B18008B48058
2020.01.12 14:33:04 2: mySIGNALduino: SD_Keeloq_Parse Unknown device unknown with Code 012D100 detected, please define (rawdate=74D21B18008B48058)
2020.01.12 14:33:04 2: autocreate: define SD_Keeloq_012D100 SD_Keeloq 012D100
2020.01.12 14:33:04 2: autocreate: define FileLog_SD_Keeloq_012D100 FileLog ./log/SD_Keeloq_012D100-%Y.log SD_Keeloq_012D100
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 91.1 -> Atlantic security
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=2 reconstructed, last bit=0
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 87 -> JAROLIFT
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=1 reconstructed, last bit=1
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 88 -> HCS300/HCS301
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
</pre>
und routet die Request an das Modul SD_Keeloq weiter. Der Hinweis auf HCS301 führt auf die richtige Spur. Das analysierte Protokoll ist im Data Sheet des Microchip HCS301 (KeeLoq Code Hopping Encoder) beschrieben. Somit wurde aus einem unbekannten Funkprotokoll letztlich ein bekanntes.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2020-01-12T17:25:20Z

Plin53177: /* Es geht weiter */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

=== Finale ===

Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.

Der SIGNALduino erkennt
<pre>
2020.01.12 14:33:03 4: mySIGNALduino: Parse_MS, Decoded matched MS Protocol id 88 dmsg P88#74D21B18008B48058 length 68 RSSI = -32
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, test ungleich: disabled
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, -32 dB, dispatch
2020.01.12 14:33:03 5: mySIGNALduino: dispatch P88#74D21B18008B48058
2020.01.12 14:33:04 2: mySIGNALduino: SD_Keeloq_Parse Unknown device unknown with Code 012D100 detected, please define (rawdate=74D21B18008B48058)
2020.01.12 14:33:04 2: autocreate: define SD_Keeloq_012D100 SD_Keeloq 012D100
2020.01.12 14:33:04 2: autocreate: define FileLog_SD_Keeloq_012D100 FileLog ./log/SD_Keeloq_012D100-%Y.log SD_Keeloq_012D100
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 91.1 -> Atlantic security
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=2 reconstructed, last bit=0
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 87 -> JAROLIFT
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=1 reconstructed, last bit=1
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 88 -> HCS300/HCS301
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
</pre>
und routet die Request an das Modul SD_Keeloq weiter. Der Hinweis auf HCS301 führt auf die richtige Spur. Das analysierte Protkoll ist im Data Sheet des Microchip HCS301 (KeeLoq Code Hopping Encoder) beschrieben. Somit wurde aus einem unbekannten Funkprotokoll letztlich ein bekanntes.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2020-01-12T17:25:04Z

Plin53177: /* Es geht weiter */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

=== Es geht weiter ===

Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.

Der SIGNALduino erkennt
<pre>
2020.01.12 14:33:03 4: mySIGNALduino: Parse_MS, Decoded matched MS Protocol id 88 dmsg P88#74D21B18008B48058 length 68 RSSI = -32
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, test ungleich: disabled
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, -32 dB, dispatch
2020.01.12 14:33:03 5: mySIGNALduino: dispatch P88#74D21B18008B48058
2020.01.12 14:33:04 2: mySIGNALduino: SD_Keeloq_Parse Unknown device unknown with Code 012D100 detected, please define (rawdate=74D21B18008B48058)
2020.01.12 14:33:04 2: autocreate: define SD_Keeloq_012D100 SD_Keeloq 012D100
2020.01.12 14:33:04 2: autocreate: define FileLog_SD_Keeloq_012D100 FileLog ./log/SD_Keeloq_012D100-%Y.log SD_Keeloq_012D100
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 91.1 -> Atlantic security
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=2 reconstructed, last bit=0
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 87 -> JAROLIFT
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=1 reconstructed, last bit=1
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 88 -> HCS300/HCS301
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
</pre>
und routet die Request an das Modul SD_Keeloq weiter. Der Hinweis auf HCS301 führt auf die richtige Spur. Das analysierte Protkoll ist im Data Sheet des Microchip HCS301 (KeeLoq Code Hopping Encoder) beschrieben. Somit wurde aus einem unbekannten Funkprotokoll letztlich ein bekanntes.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2020-01-12T16:54:37Z

Plin53177: /* Es geht weiter */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

=== Es geht weiter ===

Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.

Der SIGNALduino erkennt
<code>
2020.01.12 14:33:03 4: mySIGNALduino: Parse_MS, Decoded matched MS Protocol id 88 dmsg P88#74D21B18008B48058 length 68 RSSI = -32
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, test ungleich: disabled
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, -32 dB, dispatch
2020.01.12 14:33:03 5: mySIGNALduino: dispatch P88#74D21B18008B48058
2020.01.12 14:33:04 2: mySIGNALduino: SD_Keeloq_Parse Unknown device unknown with Code 012D100 detected, please define (rawdate=74D21B18008B48058)
2020.01.12 14:33:04 2: autocreate: define SD_Keeloq_012D100 SD_Keeloq 012D100
2020.01.12 14:33:04 2: autocreate: define FileLog_SD_Keeloq_012D100 FileLog ./log/SD_Keeloq_012D100-%Y.log SD_Keeloq_012D100
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 91.1 -> Atlantic security
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=2 reconstructed, last bit=0
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 87 -> JAROLIFT
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=1 reconstructed, last bit=1
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 88 -> HCS300/HCS301
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
</code>
und routet die Request an das Modul SD_Keeloq weiter. Der Hinweis auf HCS301 führt auf die richtige Spur. Das analysierte Protkoll ist im Data Sheet des Microchip HCS301 (KeeLoq Code Hopping Encoder) beschrieben. Somit wurde aus einem unbekannten Funkprotokoll letztlich ein bekanntes.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2020-01-12T16:52:57Z

Plin53177: /* Es geht weiter */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

=== Es geht weiter ===

Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.

Der SIGNALduino erkennt
<nowiki>
2020.01.12 14:33:03 4: mySIGNALduino: Parse_MS, Decoded matched MS Protocol id 88 dmsg P88#74D21B18008B48058 length 68 RSSI = -32
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, test ungleich: disabled
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, -32 dB, dispatch
2020.01.12 14:33:03 5: mySIGNALduino: dispatch P88#74D21B18008B48058
2020.01.12 14:33:04 2: mySIGNALduino: SD_Keeloq_Parse Unknown device unknown with Code 012D100 detected, please define (rawdate=74D21B18008B48058)
2020.01.12 14:33:04 2: autocreate: define SD_Keeloq_012D100 SD_Keeloq 012D100
2020.01.12 14:33:04 2: autocreate: define FileLog_SD_Keeloq_012D100 FileLog ./log/SD_Keeloq_012D100-%Y.log SD_Keeloq_012D100
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 91.1 -> Atlantic security
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=2 reconstructed, last bit=0
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 87 -> JAROLIFT
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=1 reconstructed, last bit=1
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 88 -> HCS300/HCS301
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
</nowiki>
und routet die Request an das Modul SD_Keeloq weiter. Der Hinweis auf HCS301 führt auf die richtige Spur. Das analysierte Protkoll ist im Data Sheet des Microchio HCS301 (KeeLoq Code Hopping Encoder) beschrieben. Somit wurde aus einem unbekannten Funkprotokoll letztlich ein bekanntes.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2020-01-11T17:41:12Z

Plin53177: /* Konfiguration */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

=== Es geht weiter ===

Nach Aktivierung der vormals ausgeschalteten MessaegTypen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2019-12-31T08:06:21Z

Plin53177: /* Konfiguration */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2019-12-31T08:04:27Z

Plin53177: /* SIGNALduino - FSK */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2019-12-30T20:57:36Z

Plin53177: /* Baudrate */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2019-12-30T20:52:34Z

Plin53177: /* Baudrate */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Datei:RIO-Signal.png

2019-12-30T20:51:43Z

Plin53177:

RIO-Signal

Unbekannte Funkprotokolle

2019-12-30T20:46:53Z

Plin53177: /* Codesequenzen */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal decodiert.png|mini|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2019-12-30T20:46:08Z

Plin53177: /* SIGNALduino - FSK */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal decodiert.png|mini|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Ferndbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2019-12-30T12:37:44Z

Plin53177: /* Codesequenzen */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal decodiert.png|mini|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Ferndbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

=== Konfiguration ===

Last but not least: SDUINO Firmware war die Version v3.4.1_dev_21.12

Register-Settings:

* Trägerfrequenz: 868.302 MHz
* Deviation: 25 kHz
* Bandwidth: 58 kHz
* Baudrate: 24.795 kBaud
* Modulation: GFSK

<pre>ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
</pre>

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2019-12-30T10:48:08Z

Plin53177:

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal decodiert.png|mini|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Ferndbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

Last but not least: SDUINO Firmware war die Version v3.4.1_dev_21.12

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Unbekannte Funkprotokolle

2019-12-30T10:45:00Z

Plin53177: /* Codesequenzen */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal decodiert.png|mini|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Ferndbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

Last but not least: SDUINO Firmware war die Version v3.4.1_dev_21.12

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]

Unbekannte Funkprotokolle

2019-12-30T10:42:10Z

Plin53177: /* Baudrate */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal decodiert.png|mini|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die korrekt mittels FSK empfangenen. Deshalb: Sequenzen neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Hier könnte Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dan erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt dann die Sprecu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]

Unbekannte Funkprotokolle

2019-12-30T10:41:33Z

Plin53177: /* Baudrate */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal decodiert.png|mini|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die SOftware URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine realse Darstellung zu kommen gebe ich 402 Samples/bit ein.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die korrekt mittels FSK empfangenen. Deshalb: Sequenzen neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Hier könnte Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dan erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt dann die Sprecu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]

Unbekannte Funkprotokolle

2019-12-30T10:37:45Z

Plin53177: /* Hub einstellen */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Hub ===

Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels get <myduino> ccconf ausgegebene Baudrate ist die zwischen dem Arduino ind dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino das Signal und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal decodiert.png|mini|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die korrekt mittels FSK empfangenen. Deshalb: Sequenzen neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Hier könnte Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dan erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt dann die Sprecu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]

Unbekannte Funkprotokolle

2019-12-30T10:36:50Z

Plin53177: /* FSK Senden */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== FSK Senden ===

Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
''get <mysduino> ccreg 99''
Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
Das Register wird über
''set <mysduino> raw W1410''
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Hub einstellen ===

Da hilft Euch aktuell noch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels get <myduino> ccconf ausgegebene Baudrate ist die zwischen dem Arduino ind dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino das Signal und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal decodiert.png|mini|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die korrekt mittels FSK empfangenen. Deshalb: Sequenzen neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Hier könnte Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dan erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt dann die Sprecu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]

Unbekannte Funkprotokolle

2019-12-30T10:32:54Z

Plin53177: /* Ermittlung der Frequenzen */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnte Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

=== FSK Senden ===

Das die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändern. A, einfachtesn geht das über einen
get <mysduino> ccreg 99
Ihr müsst bei angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK machen.
Das Registzer wird über
set <mysduino> raw W1410
abgeändert (bitte beachtet das offset von 0x02 für das Beschreiben eines Registers, 14 adressiert hier Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Hub einstellen ===

Da hilft Euch aktuell noch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels get <myduino> ccconf ausgegebene Baudrate ist die zwischen dem Arduino ind dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino das Signal und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal decodiert.png|mini|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die korrekt mittels FSK empfangenen. Deshalb: Sequenzen neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Hier könnte Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dan erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt dann die Sprecu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]

Unbekannte Funkprotokolle

2019-12-30T10:30:59Z

Plin53177: /* Sendefrequenz und Frequenzhub */

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...

Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:

Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).

== Basics ==

==== Hardware ====

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]
* Modulationsverfahren (OOK, ASK/FSK)
* Frequenzband (433 MHz, 868 MHz)

(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

==== Frequenzbereich ====
Für die funkbasierte Heimautomation kommen im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz. Die meisten Geräte haben auf der Rückseite ein Typenschild, auf dem das Frequenzband ausgewiesen ist.

Dann gibt es noch 2,4 GHz (WLAN, Bluetooth, Funkmaus-Chipsätze...) und 5GHz (WLAN...), diese Frequenzbänder werden in diesem Artikel aber nicht betrachtet.

==== Modulationsverfahren ====

So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren.

* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]
: Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe [http://www.rfwireless-world.com/Terminology/2FSK-modulation-vs-4FSK-modulation.html hier]).

==== Encoding oder auch Leitungscode ====

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge
* 100 (short high, long low) wird als 0
* 110 (long high, short low) wird als 1
interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

==== Signalstruktur ====

Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus

| Pause | Sync | Pause | Daten |

* eine größere Pause zur Trennung der Sequenzen
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
* eine Pause um Sync und Daten zu trennen
* die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch [https://de.wikipedia.org/wiki/Datenpr%C3%A4ambel Datenpräambel] oder auch [https://en.wikipedia.org/wiki/Syncword Syncword]).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

==== Protokoll ====

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

== Wie fange ich an? ==

==== Recherche ====

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen, die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise, wie diese Devices in FHEM eingebunden werden können.

Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]

Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.

==== Ansatz 1 - Versuchen ====

Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten
* es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf [https://github.com/RFD-FHEM/RFFHEM/issues github] wie im [[SIGNALduino]]-Wiki vorgeschlagen)
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

==== Ansatz 2 - Aufschrauben ====

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Folgende Möglichkeiten:
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
* OOK-Modulation -> [[SIGNALduino]]
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

==== Ansatz 3 - Messen ====

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über
* das Modulationsverfahren (OOK vs. FSK) sowie
* die relevante(n) Frequenz(en)

== SIGNALduino - OOK ==

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

==== Log-Meldungen ====

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Senden auch wieder generieren.

Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Was bedeutet D=012323...?
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: 2 -> P2=-398 => 398 Mikrosekunden Pause
: 3 -> P3=415 => 415 Mikrosekunden Signal
: ...

Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:
Nicht langwierig auf das jeweils nächste verzögerte Intervall der Funk-Aktivität des Geräts warten, sondern stattdessen mehrfach die Geräte-Batterien erneut wieder einsetzen, so dass (hoffentlich) das Gerät immer eine erste Funk-Aktivität sendet, die:
* Log-Zeitstempelmäßig genau erkennbar ist
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.

==== Frequenz ermitteln ====

Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schrittweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

==== Eingrenzung - Selektiver Empfang ====

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command <code>disableMessagetype</code> die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob es bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

==== Eingrenzung - Log-Analyse via regex ====

Wenn man schon ziemlich genau weiß, wie das Message-Pattern des relevanten Geräts aussieht, dann kann man sich folgendermaßen sehr elegant und schnell viele weitere zu diesem Gerät gehörige Aktivitäten aus dem Log fischen, ohne sehr störenden Traffic von anderen Geräten mit dabei zu haben:
z.B.:

<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code>

um sich alle Pattern eines Geräts rauszufischen, bei dem man weiß, dass dessen Sende-Traffic das hinreichend charakteristische Merkmal besitzt, einen Low-Puls mit +- 4000us Länge zu haben:

<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code>

Anmerkung: dies ist natürlich mit einem On-Demand-beherrschbaren Gerät (z.B. Fernbedienung, oder Batterie-basiertes Außerbetriebsetzen) kein Problem: hier kann man direkt live (aktueller Zeitpunkt!) nachvollziehen, ob die aktuelle Regex-Filterung tatsächlich Geräte-Aktivität richtig herausfischt (oder eben dummerweise nicht!). Jedoch bei nicht so leicht kontrollierbaren Geräten (intervall-mäßiges Senden, z.B. Klima-Sensoren, oder noch blöder, nur vereinzeltes Senden, z.B. Schwellwert-Sensoren, oder nicht direkt zugängliche Geräte) muss man natürlich den Regex möglichst wenig strikt formulieren, um sicherzustellen, dass man keine im Log abgelegte Aktivität dieses Geräts fälschlicherweise total übersieht/ignoriert.

==== Variationen ====

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombination durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

==== Signal analysieren ====

Habt Ihr nun den Punkt erreicht an dem Ihr ''reproduzierbar'' (hinreichend stabil erfasste) (Teil-)Code-Sequenzen (oft in mehrfacher, identischer Wiederholung) im FHEM-Log seht, geht es ans Entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an (da das aber öfter nicht der Fall sein wird, muss man hier weiterarbeiten).

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code>

Wie ist diese Sequenz zu interpretieren?

* Es startet mit einer Pause D='''0'''123232323232
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf die Daten

<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC</code>

Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
* Mapping von Puls-Werten auf logische Zustände: wenn 800-ter Pulse: Wert kleiner 0 (z.B. -800) ist ein l (long low), größer 0 ist L (long high), wenn 400-ter Pulse: analog, gemapped auf sS (short low/high) - "sSlL-Notation"...
* Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0) (ein Gerät hat ja salopp gesagt nicht mehr zu tun als nur 2 Zustände - 0er und 1er Daten-Bits - robust codiert über Funk zu vermitteln - aus diesen Bits ergibt sich dann zusammengefügt ein gesamtes Geräte-Datenwort, welches anschließend in Bit-Bereiche wie Temperatur, Feuchte, Wind zerlegungs-analysiert werden muss, anhand charakteristischer Werte-Veränderungen, die man idealerweise auch direkt in z.B. einem Sensor-LCD-Display erkennen kann)

Abseits-Bemerkung: Sollte man mit dem SIGNALduino ein ''FSK''-Signal empfangen/interpretieren (im Gegensatz zu "normaleren" ''ASK'', ''OOK''), so hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert. FIXME diese Beschreibung ist (mir) zu unklar, eine Verbesserung sollte erarbeitet werden.

Weitere wichtige Tips:
* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen
* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
* richtige Verarbeitung von empfangenen Funk-Pattern (oder in leicht abgeänderter Form derselben) kann man wohl besonders effizient debuggen, indem man sich einen Dummy-SIGNALduino anlegt:
<code>define sduino_dummy SIGNALduino none</code>

In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:

<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code>

Alle Strichpunkte (Semikolon) müssen hierbei jeweils escaped werden (durch Wiederholung), vermutlich da sie in FHEM's Perl-Code-Umgebung sonst als normale ''sequence points'' interpretiert würden.

Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.

Wenn alles richtig läuft (weil man es richtig implementiert hat), dann sollte die gesamte Kette von Pattern-Fingerprinting bis hin zu Dispatch an Datenwort-Modul und dortige Verarbeitung bis hin zu einem entsprechend sichtbaren Auftauchen der Device-Aktivitäten/-Autocreate in FHEMWEB Event Monitor page und/oder Log durchlaufen werden.

==== Steuern ====

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei Puls-Beschreibungen P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R jedoch für die Anzahl der Wiederholungen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation [https://github.com/RFD-FHEM/SIGNALDuino/wiki/Commands Commands].

==== Signal-Protokoll-Beschreibung verfeinern ====

Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:

Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:

wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann
landet das Signal-Pattern (auch) bei falschen Protokoll-Beschreibungen - die weitere Zuordnung (dies ist eine Routing-Entscheidung!) hin zu spezifischen Geräte-Datenwort-FHEM-Modulen ist also gefährdet / sinnlos:
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.

Daher sollte man folgendes beachten:
* sicherstellen, dass nicht eine andere - also bereits existierende! - Protokoll-Beschreibung eigentlich die richtige gewesen wäre, welche nur aufgrund von Impräzisionen das aktuelle völlig Protokoll-gleiche Gerät NICHT erkannt hat (zudem: "ähnlich" aussehende Protokolle, die allerdings von klar unterschiedlichen Geräte-Familien erzeugt werden, sollten NICHT in der gleichen Protokoll-Beschreibung zusammengemischt werden, und man sollte diese Abgrenzung dort auch klarstellen: durch Referenz-Hinweise auf entsprechende fast gleiche Protokoll-Beschreibungen dort)
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))

Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:
* einige Geräte-Pattern aus dem Log fischen
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
* evt. ist es auch hilfreich, den im Gerät verbauten Quartz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)

==== Development / patch submission ====

Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
* Änderungen durchführen (im korrekten Branch)
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
* alles committen
* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

== SIGNALduino - FSK ==

Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].

=== Sendefrequenz und Frequenzhub ===

<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div>
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div>

Bei OOK wird das Funksignal ein- und ausgeschaltet, um die bits als 0 und 1 darzustellen. Bei FSK sieht das anders aus. Zur Übertragung wird ein permanentes Signal ausgestrahlt; die Darstellung der bits 0 und 1 erfolgt durch Erniedrigung bzw. Erhöhung der Frequenz. Folglich gilt es sowohl die Trägerfrequenz als auch den Frequenzhub zu ermitteln. Das bit 0 wird i.d.R. durch Trägerfrequenz minus Hub, das bit 1 durch Trägerfrequenz plus Hub dargestellt.

In diesem Beispielspektrum eines FSK-Signals ist ersichtlich, dass die untere Frequenz bei ca. 868,233 Mhz und die obere bei ca. 868,281 Mhz liegt. Die Trägerfrequenz liegt folglich in der Mitte bei 868,257 MHz und der Frequenzhub beträgt ca. 24 kHz.

=== Ermittlung der Frequenzen ===

Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz ist "relativ" gut gemessen. Was aber hilt ist ein Vergleich Original/Fälschung. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehemt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgebene Frequenz. Die Abweichung könnte Ihr dann in der URH-Software zur Frequenzkorrektur vorgeben..

=== FSK Senden ===

Das die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
000 = 2-FSK
001 = GFSK
011 = ASK/OOK
100 = 4-FSK

Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändern. A, einfachtesn geht das über einen
get <mysduino> ccreg 99
Ihr müsst bei angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK machen.
Das Registzer wird über
set <mysduino> raw W1410
abgeändert (bitte beachtet das offset von 0x02 für das Beschreiben eines Registers, 14 adressiert hier Register 12).

Nun könnt Ihr FSK senden. Das im URH angezeigte Spektrum sollte nun zwei Spitzen aufweisen. Ihr seht daneben vermutlich auch weitere kleine links und rechts daneben. Das liegt daran, dass es Oberwellen gibt. Bei 2-FSK sind dies mehr als bei dem geglätteten GFSK.

=== Hub einstellen ===

Da hilft Euch aktuell noch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels
''set <mysduino> raw W1740''
an den CC1101 des SDUINO übermittelt wird.

Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.

<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div>
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div>
<div style="clear:both"></div>

=== Baudrate ===

Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ein Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.

Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden
FHEM <-> Arduino <-> CC1101 <-> Sendesignal

Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels get <myduino> ccconf ausgegebene Baudrate ist die zwischen dem Arduino ind dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

Beim Empfang interpretiert der Arduino das Signal und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittels und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

<div class="tleft" style="clear:both">[[Datei:RIO-Signal decodiert.png|mini|RIO-Signal decodiert]]</div>
<div style="clear:both"></div>

Die Baudrate lässt sich nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts.

Das Ergebnis:

<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|Vergleich RIO/SDUINO-Signale]]</div>
<div style="clear:both"></div>

=== Codesequenzen ===
Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anderes interpretiert als die korrekt mittels FSK empfangenen. Deshalb: Sequenzen neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Hier könnte Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dan erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt dann die Sprecu vom Weizen.

Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.

== CUL - FSK und Co. ==

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

== FAQ ==

=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.

Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.

Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.

Beispiel einer empfangenen Sequenz

<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code>

P0, P2 + P5 haben ein negatives Vorzeichen. Damit ist gemeint, dass für eine Zeit von 762µs (P5) kein Signal empfangen wurde (Low). Die positiven sind dann High.

Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.

Wie bereits ausgeführt, werden für die Daten die Pulse P2, P3, P5 und P6 genutzt. Der Mittelwert [ (P2 + P3 + P5 + P6) / 6 ] der absoluten Werte ergibt 404µs für ein Short und 808µs ein Long (2xShort). Idealisiert werden 400µs angenommen.

Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.

== Links ==

* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]
* [https://github.com/jopohl/urh Universal Radio Hacker]
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]
* [[Intertechno Code Berechnung]]
* [[Funksignalanalyse mit DVB-T Stick]]

[[Kategorie:Intertechno]]
[[Kategorie:HOWTOS]]
[[Kategorie:433MHz]]