http://wiki.fhem.de/w/api.php?action=feedcontributions&user=AndreasMohr&feedformat=atomFHEMWiki - Benutzerbeiträge [de]2024-03-28T14:19:43ZBenutzerbeiträgeMediaWiki 1.39.3http://wiki.fhem.de/w/index.php?title=CUL&diff=37550CUL2022-09-13T20:48:40Z<p>AndreasMohr: Typos</p>
<hr />
<div>Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8&nbsp;bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433&nbsp;MHz sind weitere Protokolle zugänglich, z.&nbsp;B. Intertechno, viele Baumarkt-Funksteckdosen. <br />
<br />
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.<br />
<br />
Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1&nbsp;kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.<br />
<br />
Das CUL kann mittels des CULModuls von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.<br />
<br />
Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version&#160;3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}<br />
<br />
Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z.&nbsp;B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.<br />
<br />
Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.<br />
<br />
Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.<br />
<br />
Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.<br />
<br />
Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen. <br />
<br />
* Ist Empfang eingeschaltet ?<br />
*: <code> get myCUL raw C35</code> (13 = ja, z.&nbsp;b.: C35 = 0D / 13)<br />
* Auslesen der culfw Version:<br />
*: <code>get myCUL raw V</code><br />
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)<br />
*: <code>set myCUL raw l00</code><br />
* LED einschalten<br />
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen<br />
* LED soll blinken (einmal in der Sekunde)<br />
*: <code>set myCUL raw l02</code><br />
* Reboot / Reset des CUL:<br />
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=&gt; neue Firmware)<br />
* Freie CUL Sendezeit ([[1% Regel]]):<br />
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots<br />
* Freie Kapazität des FHT Buffers<br />
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a<br />
* Inhalt des FHT Buffers<br />
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes groß, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer<br />
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]<br />
*: <code> get myCUL raw T01</code> <br />
* Eingestellte Frequenz, Bandbreite etc. Ausgeben<br />
*: <code> get myCUL ccconf</code>. <br>Rückgabe z.&nbsp;B.: <br><code><nowiki>myCUL ccconf =&gt; freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code><br />
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):<br />
*:<code>set myCUL bWidth 464</code><br />
* Einstellen der Sendestärke:<br />
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.<br />
<br />
Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen<br />
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. <br />
<br />
Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z.&nbsp;B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl). <br />
<br />
'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).<br />
<br />
Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit&#160;:<br />
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt<br />
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet<br />
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet<br />
* <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet<br />
* <code>set CUL1 raw X21</code> normal Modus<br />
<br />
Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!<br />
<br />
Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.<br />
<br />
== Versionen ==<br />
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.<br />
<br />
* CUL V1 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.<br />
* CUL V2 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.<br />
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kB EEPROM). Voll einsatzfähig.<br />
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM, 32 kB Flashmemory, 1 kB EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.<br />
<br />
Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.<br />
<br />
== Firmware {{Anker|FW}} ==<br />
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der<br />
* [http://culfw.de CUL Firmware Homepage]<br />
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.<br />
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der<br />
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]<br />
Hier kann man sich z.B. mit<br />
<syntaxhighlight lang="bash"><br />
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw<br />
</syntaxhighlight><br />
die aktuelle Version laden.<br />
<br />
Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:<br />
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.<br />
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.<br />
<br />
Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).<br />
<br />
Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.<br />
<br />
== Sendefrequenz ==<br />
Das CUL gibt es in Ausführungen für 868 und 433 MHz. <br />
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.<br />
<br />
Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.<br />
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.<br />
<br />
== Antenne ==<br />
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.<br />
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.<br />
<br />
Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik. <br />
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.<br />
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.<br />
<br />
Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne. <br />
<br />
Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene. <br />
<br />
Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.<br />
<br />
Weitere Informationen sind im {{Link2Forum|Topic=93021|LinkText=Antennenthread}} des Forums zu finden. <br />
<br />
Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar "Lambda" lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").<br />
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.<br />
<br />
Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser. <br />
<br />
Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.<br />
<br />
Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4&nbsp;GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.<br />
<br />
== Antennenlänge ==<br />
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch ein Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.<br />
<br />
Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:<br />
868,35 MHz (z.B. HM, FS20, FHT …)<br />
1/4 Lambda = 8,63 Zentimeter <br />
1/2 Lambda = 17,26 Zentimeter <br />
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)<br />
<br />
433,92 MHz (z.B. Intertechno …)<br />
1/4 Lambda = 17,27 Zentimeter <br />
1/2 Lambda = 34,54 Zentimeter <br />
<br />
Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:<br />
<br />
8,6 Zentimeter als 1/4 Lambda für 868,35 MHz<br />
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz<br />
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz<br />
<br />
== Bekannte Probleme ==<br />
<br />
=== RF-Tuning ===<br />
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z.&nbsp;B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern (z.&nbsp;B. der FHT Raumregler) zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.<br />
<br />
Bei Empfangsproblemen von z.&nbsp;B. HEM-Sensoren oder dem S300TH kann man folgendes testen:<br />
<br />
* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.<br />
*: <code>set CUL freq 868.350</code><br />
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.<br />
*: <code>set CUL sens 8</code><br />
* Oft hilft auch, die Bandbreite auf z.&nbsp;B. 464 kHz aufzuweiten.<br />
*: <code>set CUL bWidth 464</code><br />
<br />
=== Übertragungs-Stall nach zu vielen Einträgen in der Queue ===<br />
<br />
Ich habe mich ewig damit rumgeärgert, dass die Übertragung zu bestimmten häufig angesprochenen Geräten zusammenbrach, sobald die Queue zu lang wurde (FHEM: 'list CUL').<br />
Irgendwann habe ich dann zufällig herausgefunden, dass dieses sehr fragwürdige Anwachsen der Queue an einer krassen [[Sendpool]]-Fehlkonfiguration lag: ich hatte dort ein Transceiver-Device mit angegeben, welches den [[Sendpool]]-Mechanismus (noch) gar nicht unterstützt!<br />
Sobald ich dieses falsche Gerät aus der Sendpool-Element-Liste entfernt hatte, war Ruhe --> BUG im Modul (es kann nicht sein, dass ein Device ohne [[Sendpool]]-Support das Queue-Handling so zerschießt). Dieser Bug existiert allerdings wohl weiterhin (das Perl-Handling war mir etwas zu verwirrend, um direkt zu sehen, wo das Problem ist) --> sollte nachgestellt und gefixt werden.<br />
<br />
=== Harter Lockup des CUL ===<br />
<br />
Trotz behobenem (erkanntem) Queue-Problem gibt es weiterhin Probleme ("Problem #2"): es passiert - recht selten -, dass sich der nanoCUL komplett aufhängt, mit hektisch blinkender LED.<br />
Es ist in diesem Fall noch nicht einmal mit dem Reset-Taster möglich, den Stick zu resetten - es ist also tatsächlich nötig, das USB-Kabel komplett zu ziehen. Wenigstens automatisieren lassen würde sich dieser Workaround wohl per [https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux uhubctl].<br />
Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.<br />
<br />
Device-Attribute wie <code>version</code> etc. könnten evt. den Zeitpunkt der letzten Aktivität verdeutlichen; dann im FHEM-Log um diesen Zeitpunkt herum suchen, um Auffälligkeiten/Spezialitäten zu erkennen. Und dann muss man, wenn man Pech hat, eine custom culfw bauen, die entsprechendes Reporting mit eingebaut hat...<br />
<br />
(nanoCUL; V 1.26.00 a-culfw Build: 267).<br />
<br />
UPDATE: die Lösung des Problems steht evtl. im Forum (Lockup beseitigt durch Optiboot bootloader): <br />
: {{Link2Forum|Topic=73144|Message=977406|LinkText=[Gelöst] Nanocul LED blinkt schnell}}.<br />
[https://www.ebay.de/itm/1-3-mal-Flash-Service-fur-ZigBee-nanoCUL-JeeLink-Shelly-Sonoff-Blitzwolf-Gosund/264472055531] scheint das zu bestätigen:<br />
"Weiterhin bieten wir beim nanoCUL an, einen alternativen Bootloader (Optiboot Bootloader) zu flashen.<br />
Dieser verhindert das Abstürzen des nanoCUL's im Betrieb z.B. bei FHEM. (Stichwort: opened)"<br />
<br />
--> Empfehlung: Redundanz für nahtlosen Weiterbetrieb schaffen: weiteren CUL kaufen, dessen Inbetriebnahme erfolgreich testen, dann einen der CULs auf optiboot umflashen (...lassen? Siehe bekanntes Online-Auktionshaus...), und testen.<br />
(Idee: dreckiger Workaround: mit mehreren CULs könnte man sich auch ein Script schreiben, das zwischen ihnen umschalten kann, sobald es mal wieder Probleme gibt)<br />
<br />
Ein weiterer Bericht über CUL-Lockups (dort reproduzierbar/deterministisch, und Regression-Bug): [https://github.com/heliflieger/a-culfw/issues/23 Selfmade Cul freezing with blinking LED when sending ITv3 messages #23]<br />
<br />
Randnotiz: interessante Optiboot-Modifikation, die es trotz Hardware-Sperren erreicht, per Software den Bootloader-Bereich zu flashen: [https://hackaday.com/2015/07/03/arduinos-and-other-avrs-write-to-own-flash/ Arduinos (and Other AVRs) Write To Own Flash]<br />
<br />
Evt. ist auch ein USB-Port-Reset ein funktionierender Workaround (bitte Text als bestätigt umformulieren, falls das hilft): [https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html], erwähnt in diesem {{Link2Forum|Topic=77380|Message=783352|LinkText=Forenbeitrag}}.<br />
UPDATE: ein erster Test (Device herausfinden [https://unix.stackexchange.com/questions/81754/how-to-match-a-ttyusbx-device-to-a-usb-serial-device] via fhem log infos etc., fhem shutdown, usbreset, start fhem) hat bei mir nicht funktioniert ("get ccconf" --> "No FD").<br />
<br />
==== Ständige Lockups ====<br />
Falls Lockups gefühlt "ständig" passieren sollten (alle paar Tage, oder fast täglich insb. bei warmem Wetter), dann könnte es z.B. an einem schlechten/kaputten Kabel liegen (bei mir: dünne USB-2-"Drachenschnur", mit Bissmarken o.ä. - durch ein gutes dickes USB-3-Kabel ersetzt und sofort dramatisch robuster - UPDATE: das war der erste Eindruck innerhalb weniger Tage, aber längerfristig war es gefühlt nicht wirklich besser).<br />
<br />
== Selbstbau-/Bastelprojekte ==<br />
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:<br />
* [[Selbstbau CUL]]<br />
* [[FHEMduino]]<br />
* [[SIGNALduino]]<br />
* [[MapleCUN]] mit STM32 Mikrocontroller<br />
<br />
== Links ==<br />
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]<br />
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:CUL|!]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Arduino&diff=37549Arduino2022-09-13T20:39:30Z<p>AndreasMohr: Typos</p>
<hr />
<div>=== Generelles zu Arduino ===<br />
<br />
====Die Arduino-Initiative====<br />
<br />
Das [http://www.arduino.cc/ Arduino]-Projekt ist eine open-source-Initiative, die "easy-to-use" Hardware und Software bereitstellt. Als Hardware stehen unterschiedliche Platinen zur Verfügung, auf denen ein Microcontroller sowie grundlegende Schnittstellen, z.B. ein USB-Port bereits "ready-to-use" vorhanden sind. An diese Boards (ab ca. 20€ Stand Nov. 2016, China-Klone ab 2€) lassen sich einfach und recht preisgünstig eigene Sensoren/Aktoren an FHEM anbinden. <br />
<br />
Das Board lässt sich u.A. mit Hilfe der Projekt-Software Arduino-IDE relativ einfach programmieren, um Sensorwerte zu verarbeiten und diese z.B. per Ethernet an FHEM zu senden oder abfragen zu lassen. Über zahlreiche Schnittstellen (Standard: RS232, TWI/1-Wire, SPI, PWM, analog/digital-I/O, I2C) mit den entsprechenden Software-Libraries kann auf viele gängige Sensoren zugegriffen werden. Über Erweiterungsboards ("Shields") können die Anschlussmöglichkeiten ausgebaut werden. Zudem ist der Anschluss von Parallel-/Seriell-/I2C-LCD-Displays und SD-Karten möglich. Die IDE läßt sich auch für andere Enwicklerboards nutzen, insbesondere den ESP8266 (für WLAN) oder Boards auf STM32-Basis.<br />
<br />
Die Arduino-Boards bzw. Klone und eine Vielfalt an Sensoren/Aktoren sind über Online-Auktionen bzw. -Anbieter einfach zu bekommen. Kommunikation mit dem Arduino ist z.B. per Netzwerk/Ethernet, WLAN, 433/868MHz/2,4GHz-RF, Bluetooth, 1-Wire etc. möglich.<br />
<br />
Bei der Anbindung der Arduinos über USB ist zu beachten, dass auf China-Klonen in der Regel ein einfacher USB-Seriell-Wandler verbaut ist, der eine eindeutige Zuordnung der Schnittstellen innerhalb des Linux-Dateisystems erschwert. Daher sind Boards mit eindeutiger Identifizierungsmöglichkeit (in der Regel auf FTDI-Basis) für derartige Anwendungsfälle besser geeignet.<br />
<br />
<br />
====Arduino-Projekte mit Anbindung an FHEM====<br />
<br />
Folgende Projekte basieren (u.A.) auf Arduino:<br />
*[[Selbstbau_CUL]]<br />
*[[Arduino_Firmata]] bzw. [[Arduino_mit_OneWireFirmata]]<br />
*[[FHEMduino]]<br />
*[[SIGNALduino]]<br />
*[[panStamp]]s über das [[SWAP]] Protokoll per RF<br />
*[[HomeMatic_Asksin_Library]]<br />
*[[MySensors]] per RF oder RS485<br />
*[[ArduCounter]]<br />
*KeyValueProtocol (siehe {{Link2CmdRef|Anker=KeyValueProtocol}})<br />
<br />
=== Beispiel: Arduino mit Ethernet ===<br />
<br />
Eine einfache und sehr kompakte Lösung ist der Arduino Nano mit Ethernet-Shield. Der Nano hat je 8 nutzbare Analog- und Digital Ein-/Ausgänge über die sich beispielsweise Temperatursensoren, Relais etc. ansprechen lassen.<br />
<br />
Folgende Schritte sind zur Vorbereitung zu tun:<br />
<br />
# Arduino (bzw. Klon) mit Ethernet-Shield (z.B. mit ENC28J60 Chip) und gewünschten Sensoren kaufen<br />
# Arduino-IDE von der [http://arduino.cc/en/Main/Software Arduino-Homepage] (für Windows, Mac OS X und Linux vorhanden) herunterladen und installieren<br />
# Falls ENC28J60-Ethernet-Shield verwendet wird: Ethernet-Library für ENC28J60 herunterladen und in Arduino-IDE-Installation hineinkopieren (z.B. von hier: [http://trollmaker.com/article11/arduino-1-0-with-enc28j60-ethernet-shield-v1-1/], alternativ nach arduino+ENC28J60+library googeln). Eine Arduino-library für den ENC28J60, die richtige (persistente) TCP/IP-Verbindungen unterstützt und von der API her vollständig kompatibel zur original-Ethernetlibrary ist findet sich hier: [https://github.com/ntruchsess/arduino_uip UIPEthernet (arduino_uip)]<br />
# Folgenden Beispiel-Sketch mit Arduino-IDE öffnen Arduino_FHEM.ino [https://sites.google.com/site/fhemarduino/file-cabinet/Arduino_FHEM.ino?attredirects=0&amp;d=1]<br />
# IP Adresse im Sketch passend zum eigenen Netzwerk ändern (steht im Sketch auf 192.168.2.44)<br />
# Sketch auf Arduino laden<br />
# Arduino mit 5V-USB-Netzteil ans Netzwerk anschließen<br />
# Verbindung testen indem in einem Webbrowser &lt;arduino_ip_adresse&gt;/?cmd=set_D5_ON [http://192.168.2.44/?cmd=set_D5_ON] eingegeben wird (natürlich hier die im Sketch verwendete IP-Adresse angeben). Falls an Ausgang D5 eine Leuchtdiode o.ä. angeschlossen wurde sollte diese nun leuchten.<br />
# Wenn das geklappt hat sollte sich der Ausgang auch aus der FHEM-Kommandozeile ausschalten lassen mit { GetHttpFile('192.168.2.44:80', '/?cmd=set_D5_OFF');; } -&gt; natürlich wieder die im Sketch verwendete IP-Adresse verwenden.<br />
# Letzter Schritt wäre eine Definition in die fhem.cfg einzutragen um auch entsprechende Buttons in der FHEM-Oberfläche zu haben, ggf. wieder die verwendete IP-Adresse statt arduino:80 verwenden (für die Buttons wurde das FS20-Modul verwendet):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinobutton FS20 55d1 00<br />
attr arduinobutton room Arduino<br />
define FileLog_arduinobutton FileLog /otp/fhem/log/arduinobuttonon-%Y.log arduinobutton<br />
attr FileLog_arduinobutton room Arduino<br />
define arduinoswitchon notify FS20_55d100:on { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_ON&quot;)}<br />
attr arduinoswitchon room Arduino<br />
define arduinoswitchoff notify FS20_55d100:off { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_OFF&quot;)}<br />
attr arduinoswitchoff room Arduino<br />
define weblink_arduinobutton weblink fileplot FileLog_arduinobutton:fs20:CURRENT<br />
attr weblink_arduinobutton label &quot;arduinobutton Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_arduinobutton room Arduino</nowiki><br />
<br />
<br />
Abfragen von Sensorwerten sind natürlich auch möglich, z.B. mit folgender Definition (Analog- und Digital-PINs werden alle fünf Minuten abgefragt und in Plots visualisiert):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinogetsensorvalues at +*00:05:00 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_analog_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvalues $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvalues room Arduino<br />
define FileLog_arduinogetsensorvalues FileLog /opt/fhem/log/arduinogetsensorvalues-%Y.log arduinogetsensorvalues:.*<br />
attr FileLog_arduinogetsensorvalues room Arduino<br />
define weblink_getsensorvalues weblink fileplot FileLog_arduinogetsensorvalues:arduino:CURRENT<br />
attr weblink_getsensorvalues label &quot;Arduino Sensorvalues Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvalues room Arduino<br />
define arduinogetsensorvaluesD at +*00:05:35 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_digital_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvaluesD $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvaluesD room Arduino<br />
define FileLog_arduinogetsensorvaluesD FileLog /opt/fhem/log/arduinogetsensorvaluesD-%Y.log arduinogetsensorvaluesD:.*<br />
attr FileLog_arduinogetsensorvaluesD room Arduino<br />
define weblink_getsensorvaluesD weblink fileplot FileLog_arduinogetsensorvaluesD:arduino:CURRENT<br />
attr weblink_getsensorvaluesD label &quot;Arduino Digital Values Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvaluesD room Arduino</nowiki><br />
<br />
<br />
=== WLAN ===<br />
Die Anbindung von Arduinos über WLAN ist möglich, indem z.B. ein [[ESP8266]] mit dem Arduino verbunden wird. In der Regel ist es aber zielführender, direkt den Microcontroller auf dem ESP-Board auch für die Auswertung der anzuschließenden Sensoren zu nutzen und so auf den Arduino zu verzichten. Die entsprechenden Sketche für Arduino laufen in der Regel mit geringen Überarbeitungen auch auf diesen Boards.<br />
<br />
=== ToDo ===<br />
Kommunikation via Bluetooth<br />
<br />
=== Bekannte Probleme ===<br />
==== FTDI-Resets ====<br />
[[Bild:FTDI_PINS.png|100px|thumb|right|FTDI-Pinbelegung]]<br />
Bei Arduinos Nanos mit FTDI-USB-Seriell-Wandlern kann es vorkommen, dass diese immer wieder scheinbar grundlos rebooten und keine stabile Kommunikation entsteht. In diesem Fall sollte geprüft werden, ob der TEST-Pin (26) auf Ground liegt. Ist dies nicht der Fall, kann der Fehler dadurch behoben werden, dass der TEST-Pin mit AGND (25) zusammengelötet wird:<br />
<br />
[https://ketturi.kapsi.fi/2014/04/how-to-fix-moody-arduino-nano/ How to fix moody Arduino nano]<br />
<br />
(via [https://forum.fhem.de/index.php/topic,88440.msg810659.html#msg810659 Antw:CUL -Device empfängt nach Neustart keine Daten])<br />
<br />
[[Kategorie:Arduino]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=SIGNALduino&diff=37548SIGNALduino2022-09-13T20:35:53Z<p>AndreasMohr: Typos</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Empfang und Verarbeitung von digitalen Signalen<br />
|ModType=d<br />
|ModFTopic=38402<br />
|ModCmdRef=SIGNALduino<br />
|ModForumArea=Sonstige Systeme<br />
|ModTechName=00_SIGNALduino.pm<br />
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])<br />
}}<br />
<br />
== Einleitung ==<br />
=== Übersicht ===<br />
Unter den Namen SIGNALduino versteht man sowohl den Low-Cost Empfänger für digitale Signale (vergleichbar dem [[CUL]]) als auch das gleichnamige Modul mit dem Dateinamen 00_SIGNALduino.pm. Mit dem SIGNALduino kann man entweder 433 oder 868 MHz-Geräte auslesen und ansprechen. Der SIGNALduino funktioniert auch mit anderen Medien wie Infrarot oder direkter Kabelverbindung.<br />
<br />
Der SIGNALduino(-Stick) erkennt Signale anhand von Mustern und gibt sie (als maximal detaillierte Beschreibung einer Signalabfolge) dann schlicht sofort nur noch an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben.<br />
Aufgabe des SIGNALduino (Firmware/Stick) ist es also nur, Signal-Aktivitäten zu erfassen und maximal präzise (als kurzer Text-String) zu beschreiben.<br />
Alles weitere (echte, finale Auswertung / Zuweisung dieser Signal-Daten) wird dann auf einer großen Box (z.B. Raspberry) gemacht.<br />
<br />
=== Vorteil gegenüber einem CUL/FHEMduino ===<br />
Der SIGNALduino hat den Vorteil einer sehr schnellen Demodulation des Funksignals. Sollen weitere Protokolle dekodiert werden, so muss dazu nur ein passendes FHEM Modul entwickelt oder ein universelles Modul erweitert werden (also auf flexibel direkt änderbarer/updatebarer Rechner-Seite!!). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung auf Stick-Firmware-Seite korrekt funktioniert - leider nicht immer, z.B.: [https://github.com/RFD-FHEM/SIGNALDuino/issues/65 MU-Nachrichten werden z.T. als MC erkannt]).<br />
<br />
Ein großer Vorteil des SIGNALduino besteht darin, dass auch Geräte mit leicht abweichenden Frequenzen steuerbar sind; so empfangen die ''Somfy''-Rolladenmotoren beispielsweise auf 433.42 MHz und nicht, wie bei anderen Geräten sehr oft üblich, auf 433.92 MHz. Die Frequenzumstellung stellt für den SIGNALduino kein Problem dar.<br />
<br />
Ebenso kann man den SIGNALduino direkt an den Sendeausgang eines Sensors anbinden und die digitalen Signale empfangen, dabei bitte aber auf die passenden Spannungen achten, denn ein Arduino Nano verträgt nur 5V.<br />
<br />
<br />
=== Entwicklungsversion ===<br />
Der SIGNALduino wird derzeit aktiv weiterentwickelt. In FHEM existieren inzwischen zwei verschiedene Versionen: eine offizielle (Maintainer ist Sidey) und eine inoffizielle (Maintainer ist Ralf9). Die offizielle Version wird über den update-Prozess verteilt, wer die inoffizielle nutzen will, muss hier händisch eingreifen. Beide Versionen sind inzwischen so weit entwickelt, dass sie nicht mehr ohne Weiteres kompatibel sind. Man muss also eine Entscheidung treffen, welches das für einen geeignete Modul ist. Das betrifft inzwischen nicht nur das eigentliche SIGNALduino.pm-Modul, sondern auch die dazugehörige Firmware.<br />
<br />
==== Offizielles Modul (Sidey) ====<br />
Die offizielle Version wird in mehreren Forenbeiträgen beschrieben: [https://forum.fhem.de/index.php/topic,58397.0.html Erster Thread] (inzwischen geschlossen), {{Link2Forum|Topic=58396|LinkText=weiterer Thread}} sowie [https://forum.fhem.de/index.php/topic,60170.0.html noch ein Thread.] <br />
<br />
An einem weiteren Thread ([https://forum.fhem.de/index.php/topic,58396.0.html Link]) scheinen beide Autoren beteiligt zu sein.<br />
<br />
==== Inoffizielles Modul (Ralf9) ====<br />
Das Modul von Ralf9 wird [https://forum.fhem.de/index.php/topic,111653.0.html hier] beschrieben. Wer es installieren möchte, muss beim üblichen update-Prozess das Modul 00_SIGNALduino.pm vom update ausschließen oder nach jedem Update erneut Ralf9s-Modul herunterladen. Die Installation des Moduls wird im ersten Post beschrieben, Hilfe gibt es auch in diesem Thread. <br />
<br />
== Hardware ==<br />
=== Controller ===<br />
Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden. Bei Einbindung via ESP muss man beachten, dass der ESP nach 5 Minuten Inaktivität seine TCP-Verbindung unterbricht (siehe [[ESP8266#Bekannte_Probleme|diesen Hinweis]]). Zu diesem Zweck gibt es einen Signalduino-eigenen Ping-Befehl ('get signalduino ping'), der diese Aktivität wieder aufbaut. Ping-Befehle sind auch auf Betriebssystemebene bekannt - allerdings beachte man, dass der ping-Befehl auf Betriebssystemebene ICMP verwendet, zum "Aufwachen" des ESP aber auf TCP-Ebene aktiviert werden muss (zum Unterschied siehe [https://www.tippscout.de/internet-was-sind-tcp-ip-udp-und-icmp_tipp_2268.html hier]) und man daher besser den Signalduino-eigenen Befehl und nicht das Betriebssystem verwendet.<br />
<br />
Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht dem [[Selbstbau CUL]] (eine frühere Version ist der nicht mehr weiterentwickelte [[FHEMduino]]):<br />
* Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum FHEMduino <br />
* Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum [[Selbstbau CUL]]. Dieser Aufbau wird derzeit empfohlen.<br />
* Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, Link zum [http://shop.in-circuit.de/index.php Hersteller]. <br />
<br />
Achten Sie beim Selbstbau auf die entsprechenden Sender-Empfänger. Der sehr preiswert angebotene XY-MK-5V hat sich als zu unzuverlässig erwiesen, während anscheinend beim CC1101 (insbesondere der "grünen Version") keine Probleme auftreten. <br />
<br />
Es stehen auch für den [https://www.arduino.cc/en/Main/arduinoBoardUno UNO] und [https://www.arduino.cc/en/Main/ArduinoBoardProMini PRO Mini] Firmware-Dateien zur Verfügung. Die ausgelieferte Firmware läuft nur auf Mikrocontrollern mit 16 MHz; wer einen Mikrocontroller mit 8 MHz verwenden möchte, muss die Firmware selbst compilieren. Die SW ist auf [https://github.com/RFD-FHEM/SIGNALDuino github]. Vorgesehen ist momentan (für ordentlich breiten Support müsste man wohl eine CMake-Build-Config hinzufügen - ich sollte hier mal in die Pötte kommen...) nur die Übersetzung unter Windows mit Visual Studio und dem Visual Micro Zusatz. Es gibt aber auch eine Anleitung, wie man mit der [[Arduino]] IDE oder einem Makefile [[SIGNALduino Compilieren]] kann.<br />
<br />
Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] nativ läuft, diese funktioniert seit Anfang 2018 annehmbar, allerdings befindet diese sich noch in einer Entwicklungsphase.<br />
<br />
An den "SIGNALESP" kann auch ein CC1101 via SPI angebunden werden:<br />
<br />
{| |<br />
!CC1101 Bezeichnung<br />
!ESP Pin<br />
|-<br />
|CLK||GPIO14<br />
|-<br />
|MOSI||GPIO13<br />
|-<br />
|MISO||GPIO12<br />
|-<br />
|CSN||GPIO15<br />
|-<br />
|GDO0||GPIO4<br />
|-<br />
|GDO2||GPIO5<br />
|}<br />
<br />
Wird eine einfache Empfänger / Sender Kombination verwendet, dann über die Pins:<br />
<br />
{| |<br />
! Bezeichnung <br />
! ESP Pin<br />
|-<br />
|Transmitter||GPIO4<br />
|-<br />
|Receiver||GPIO5<br />
|}<br />
<br />
=== Sendemodule ===<br />
{{Randnotiz|RNTyp=r|RNText=Viele user berichten über Empfangsprobleme bei Nutzung des XY-MK-5V; es wird ausdrücklich empfohlen, ein anderes Empfangsmodul zu nutzen!}}<br />
[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]] <br />
<br />
Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:<br />
* FS1000A Dies ist das Sendemodul (TX) - es wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€). <br />
* RXB6 Das ist das empfohlene Empfangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.<br />
<br />
Die Verkabelung erfolgt analog zum [[FHEMduino]] und das bedeutet (Arduino -> Modul):<br />
* PIN D2 an DATA des RX-Moduls<br />
* PIN D11 an DATA des TX-Moduls (PIN links mit Beschriftung ATAD)<br />
<br />
Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.<br />
<br />
Jetzt fehlen noch die Antennen. Dafür braucht man ein 17,2 cm langes Stück Kupferdraht, das wird beim Anschluss "ANT" jeweils am Modul angelötet (anfängergeeignet).<br />
<br />
== Software ==<br />
<br />
=== USB-ID ermitteln ===<br />
Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) verbunden werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl<br />
<pre> ls -l /dev/serial/by-id </pre><br />
ausführen. Beispielhaft sieht das Ergebnis etwa so aus:<br />
<br />
''lrwxrwxrwx 1 root root 13 Jan 31 00:02 '''usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port''' -> ../../ttyUSB0''<br />
<br />
Damit ist der Anschluss des SIGNALduino bestimmt und das Gerät kann wie im nächsten Abschnitt beschrieben definiert werden. Zuvor muss noch das Modul geladen werden.<br />
<br />
=== FHEM-Modul laden ===<br />
Die SIGNALduino Module werden über das FHEM [[update]] verteilt, sobald die Änderungen einen "stabilen" und alltagstauglichen Zustand haben. Aktuell wird dort die Version 3.5.2 seit 18.01.2022 verteilt.<br />
<br />
Mit Version 3.5.x ist die Unterstützung für Geräte mit FSK-Modulation integriert.<br />
<br />
Die aktuell in Entwicklung befindliche Version (3.5.3) kann über folgende Vorgehensweise installiert werden:<br />
<br />
* FHEM aktualisieren: <code>update</code> <br />
* SIGNALduino Modul aktualisieren: <code>update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master<nowiki/>/controls_signalduino.txt</code> Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet.<code><nowiki/></code><br />
* Es empfiehlt sich, die Github-Quelle dauerhaft einzutragen: <code>update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt</code>, um weitere Entwicklungs-Updates zu bekommen, und damit das nächste Standard-<code>update</code> nicht die alte Version wieder einspielt.<br />
<br />
Das Gerät kann wie folgt definiert werden (die Spezifikation des USB-Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):<br />
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code><br />
* Solltet Ihr einen SIGNALESP via IP einbinden wollen, ist die Syntax (ebenso wird auch vorgegangen wenn der SIGNALduino beispielsweise über ser2net freigeben wird):<br />
:<code>define <eigener-SIGNALESP-Name> SIGNALduino <ip-adresse>:23</code><br />
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt. Die Baudrate beim SIGNALduino beträgt 57600 - <br />
<br />
Verbindungsversuche via telnet müssen dieselbe Baudrate verwenden. <br />
<br />
Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.<br />
<br />
==== Flashen des Arduino mit der SIGNALduino Firmware ====<br />
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:<br />
:<code>sudo apt-get install avrdude</code><br />
<br />
In FHEM ist der SIGNALduino mit dem Status "Open" vorhanden. Jetzt müssen wir FHEM noch mitteilen, welche Hardware wir angeschlossen haben. Über das Attribut ''hardware'' lässt sich zwischen den mitgelieferten Firmware-Dateien wechseln. Solltet ihr einen Nano mit cc1101 Transceiver verwenden, so wählt bitte folgende Hardware<br />
:<code>attr sduino hardware nanoCC1101</code><br />
sonst üblicherweise<br />
:<code>attr sduino hardware nano328</code><br />
<br />
Dann muss mitgeteilt werden, welche Version man geladen haben will: stable oder testing. <br />
:<code>attr sduino updateChannelFW testing</code><br />
Nun wird die entsprechende Firmware heruntergeladen. Dies geschieht durch den Befehl<br />
:<code>get sduino availableFirmware</code><br />
Anschließend kann der ''flash'' Befehl abgesetzt werden: <br />
:<code>set sduino flash <und-dann-auswaehlen></code><br />
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.<br />
<br />
Alternativ kann auch der Flash-Befehl mit einem Dateinamen aufgerufen werden. Diese Möglichkeit sollte jedoch nur verwendet werden, wenn die SIGNALduino Firmware selbst compiliert wurde und eine andere Hardware verwendet wird. Der Flash-Befehl wird wie folgt aufgerufen:<br />
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code><br />
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)<br />
<br />
Wenn ein miniCUL geflasht werden soll, sind einige Besonderheiten zu beachten. Details dazu in {{Link2Forum|Topic=114413|LinkText=diesem Forenthema}}.<br />
<br />
==== Flashen einer Firmware über HTTP ====<br />
Die Firmware wird nicht mehr über den FHEM Update Mechanismus verteilt. <br />
Damit die passende Firmware auf den SIGNALduino geladen werden kann, wird diese dann über HTTP aus den Github Releases geladen.<br />
<br />
==== Vorabversion einer Firmware ====<br />
Die Firmware des SIGNALduino wird ebenso wie das FHEM Modul auch weiter entwickelt.<br />
Die Entwickler sind auf Tests und Rückmeldungen der Nutzer angewiesen, da leider nicht alle Sensoren vorher getestet werden können.<br />
<br />
Die Version 3.4 ist die aktuell stabile Version.<br />
<br />
Für die folgenden Microcontroller kann man die Firmware seit 21.02.2019 auch direkt downloaden und teilweise flashen. <br />
Dazu muss das Attribut <code>hardware</code> auf einen gültigen Wert angepasst werden!<br />
Über den GET Befehl <code>availableFirmware</code> werden dann für die hinterlegte Hardware die passenden Versionen gesucht. Über das Attribut <code>updateChannelFW</code> kann zwischen "stable" und "testing" definiert werden, welche Art von Firmware angeboten werden soll.<br />
<br />
Nachdem die Firmwareversion erfragt wurde, bietet der set flash Befehl eine Auswahlliste an. Wird ein Flash Befehl mit einer der Versionen ausgewählt, wird diese Version zunächst heruntergeladen und bei den AVR Versionen auch versucht diese mittels avrdude zu flashen.<br />
Die Firmware für den ESP8266 kann aktuell leider noch nicht über diesen Befehl aktualisiert werden.<br />
<br />
Alternativ funktioniert aber auch die Option, dem Flash Befehl eine URL zu übergeben. Dann wird die Datei aus der URL heruntergeladen und auch versucht diese zu Flashen. z.B.<br />
SIGNALDuino_nanocc1101.hex für einen Nano mit CC1101<br />
<br />
<code>set sduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_radinocc11013.3.1.hex<br />
<br />
oder<br />
SIGNALESP_.hex (mit cc1101) für einen ESP8266 <br />
<code>set ipduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_ESP8266cc11013.3.1.hex<br />
<br />
!Achtung, aktuell wird die Firmware für den ESP dadurch nur herunter geladen. Flashen müsst ihr leider immer noch über ein passendes Tool <br />
z.B. [https://github.com/nodemcu/nodemcu-flasher ESP8266Flasher.exe] oder Esptool und einer seriellen Konsole.<br />
Auch ist zu beachten, es handelt sich hierbei tatsächlich um ein Binary und nicht um ein Hex File. <br />
<br />
Nach dem Booten des ESPs spannt dieser ein eigenes WLAN auf. Habt ihr euch damit verbunden, könnt ihr den ESP mit eurem vorhandenen WLAN nach Eingabe der Daten verbinden.<br />
<br />
Die Hauptseite für Firmware-Releases findet sich unter https://github.com/RFD-FHEM/SIGNALDuino/releases/ .<br />
Dort kann auch eine Änderungshistorie eingesehen werden.<br />
==== Flashen eines radino Boards mit ATmega32U4 ====<br />
<br />
Diese Funktion steht seit 21.02.2019 nun auch in der via FHEM aktualisierten Version zur Verfügung:<br />
<br />
Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird.<br />
Weiterhin ist zu beachten, dass der Bootloader eine andere USB ID bekommt und diese im Attribut <code>flashCommand</code> hinterlegt werden muss.<br />
<br />
==== Fehler beim Flashen ====<br />
Sollte bei einem Flash Vorgang ein Fehler auftreten, solltet ihr zunächst im Logfile mit Verbose 5 nachsehen.<br />
<br />
Findet ihr dort keine Fehlermeldung, gibt es noch ein separates Flashlog, welches ihr über einen Browser aufrufen könnt. Dazu müsst ihr nur den folgenden Pfad an euren Servernamen anhängen:<br />
<code><br />
/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=SIGNALduino-Flash.log<br />
</code><br />
<br />
=== Geräteerkennung ===<br />
==== Unterstützte Geräte ====<br />
Für die folgenden Geräte gibt es derzeit (2017) eine Unterstützung für den Betrieb mit FHEM. Die Geräte werden [[autocreate|automatisch erkannt]] und in der Konfiguration eingetragen, wenn der SIGNALduino läuft.<br />
Bitte Geräte mit sehr präzisen Referenzen hier listen (Produktnummer, Protokoll-Variantenname etc.), damit eine globale Suche/Verifikation maximal erfolgreich ist. In der detaillierten Liste [[Geprüfte Geräte]] lassen sich die Geräte näher identifizieren.<br />
{| class="wikitable"<br />
! style="text-align:left;" | Produkt <br />
! (E)mpfangen<br />(S)enden <br />
! Hinweise <br />
! Verwendetes Modul <br />
! Protokoll ID<br />
|-<br />
|Conrad Wetterstation KW9110||E S||Sensor: KW9010, neben Temperatur u. Luftfeuchte werden auch Trend, Batterie u. Kanal erfasst|| CUL_TCM97001 || 0.3<br />
|-<br />
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0 <br />
|-<br />
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17<br />
|-<br />
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL || <br />
|-<br />
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10<br />
|-<br />
|Bresser Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12<br />
|-<br />
|TFA Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8<br />
|-<br />
|TFA 30320902||E || || SD_WS07 || 7<br />
|-<br />
|Eurochron eas800z||E || || SD_WS07 || 7<br />
|-<br />
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7<br />
|-<br />
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7<br />
|-<br />
|CTW600||E || || SD_WS09 || 9<br />
|-<br />
|CTW602||E ||neuere Version des CTW600 mit 868.35 MHz || SD_WS09 || 9<br />
|-<br />
|WH1080||E || || SD_WS09 || 9<br />
|-<br />
|Visivon remote pt4450||E || || none || 24<br />
|-<br />
|Einhell HS 434/6||E || || none || 21<br />
|-<br />
|Flamingo FA20RF / FA21RF / FA22RF Rauchmelder||E || || FLAMINGO || 13,13.1,13.2<br />
|-<br />
|mumbi m-FS300||E || || none || 26,27<br />
|-<br />
|TFA 30.3200||E || || none || 33<br />
|-<br />
|Livolo||E|| || none || 20<br />
|-<br />
|Smartwares RM174RF/2 (RM174RF-001CPR) 4500177571 ||E [S?]|| IT EV1527; TODO herausfinden: Alarmierung (wie Alarmton getriggered werden kann); Batterieinfo? || IT || 3<br />
|-<br />
|Smartwares SH5-TSO-A||E S|| || IT || ?<br />
|-<br />
|X10 Security Devices||E|| || || 39<br />
|-<br />
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43<br />
|}<br />
Bei einigen ''Intertechno''-Funksteckdosen (''Brennenstuhl'') kann es zu Empfangsproblemen kommen. Hier muss die Taktrate, mit der gesendet wird, angepasst werden. Dazu muss für ''Funksteckdose'' (also sauber per-Client-Instanz-spezifisch, NICHT SIGNALduino-Transceiver-global) das Attribut <br />
:<code>attr <Funksteckdose> ITclock 300</code> <br />
gesetzt werden, der Standardwert ist 250.<br />
<br />
==== Mein Gerät wird in FHEM nicht erkannt ====<br />
1. Prüfen, ob vom Sensor die Signaldaten (<code>verbose</code> >=4) erkannt werden. Sobald ihr die empfangenen Signaldaten im Logfile zuordnen könnt, geht es weiter mit:<br />
<br />
2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues/new?template=sensor---device-feature.md github]:<br />
<!-- <syntaxhighlight lang="md"> ... markdown lexer not yet available; use pre instead --><br />
<pre><br />
## Specifications for new sensor / switch / or other device ... <br />
<br />
- manufacturer:<br />
- model name:<br />
- pictures of the device / the board (very helpful)<br />
<br />
<br />
## Specifications <br />
<br />
- Microcontroller:<br />
- Version (Firmware):<br />
<br />
<!-- ( can be found here devicename -> Internals -> version ) --><br />
- Versionmodul (FHEM Module):<br />
</pre><br />
<br />
3. Auszug aus dem Logfile, welches zum Gerät gehört.<br />
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.''<br />
<br />
Im Forum solltet ihr solche Fragen besser nicht posten, wenn das Gerät noch nicht unterstützt wird, dazu ist Github besser geeignet. Inzwischen wurde im Wiki eine eigene Seite eröffnet, die sich mit der Erkennung unbekannter Protokolle beschäftigt: [[Unbekannte_Funkprotokolle#Ansatz_1_-_Versuchen|Unbekannte_Funkprotokolle]].<br />
<br />
==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ====<br />
Im SIGNALduino sind >70 Protokolle implementiert. Jedoch gibt es nicht immer ein logisches Modul, welches diese Protokolle verarbeitet.<br />
Teilweise ist das auch nicht zwingend notwendig, um seine Anforderungen zu erfüllen. Insbesondere für Schalter bzw. Sensoren, die nur zwei Zustände kennen, geht es meist auch kurz und knapp manuell (also ohne Modul und automatisch angelegtem Gerät).<br />
<br />
Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden.<br />
Im FHEM Log (und, insbesondere, im FHEMWEB Event Monitor) tauchen Meldungen ähnlich dieser auf<br />
<br />
<code><br />
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081<br />
</code><br />
<br />
Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:<br />
<br />
Entweder, wenn wir den Inhalt der Nachricht nur zu Teilen wissen, da er sich ändert:<br />
<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)<br />
attr mydoif do always<br />
</code><br />
<br />
Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring<br />
<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on)<br />
attr mydoif do always<br />
</code><br />
<br />
Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.<br />
<br />
Als Alternative zu DOIF hier ein regex-verwendendes [[notify]]-Beispiel für einen Sender, der meint, zwei Codes alternierend senden zu müssen:<br />
<br />
<code><br />
define n_sender_trigger notify sduino:UNKNOWNCODE.*u41#(13B72253|163873B3) { my_sender_trigger_indicate();; }<br />
</code><br />
<br />
Selbstverständlich muss in diesem Moment auch eine <code>sub my_sender_trigger_indicate()</code> definiert werden (z.B. in <code>FHEM/99_myUtils.pm</code>), die dort z.B. als Test eine Log-Ausgabe (<code>Log3()</code>) machen kann.<br />
<br />
=== Das Logfile ===<br />
Im Logfile ab [[verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (<code>verbose</code> 3 unterdrückt diese Meldungen).<br />
<br />
UPDATE: der folgende Bereich ist von einem weniger erfahrenen Zeitgenossen früher nach Kräften erweitert/geschrieben worden. Mittlerweile existiert aber ein neuer Inhalt [[Unbekannte Funkprotokolle]] (siehe auch Erwähnung weiter oben), der als sehr gut beschrieben und unvergleichlich detailreicher bezeichnet werden muss ("endlich gibt es sowas!"). Der Bereich hier dürfte somit zwar für grundlegende Verdeutlichungen noch recht sinnvoll sein, der Inhalt sollte allerdings evt. in eine konsistente Dokumentation überarbeitet (verlagert/dedupliziert/reduziert) werden.<br />
<br />
Die Protokolle (von der SIGNALDuino-Firmware gesendete Signal-Beschreibungs-Strings) können wie folgt unterschieden werden:<br />
<br />
*MS - Nachricht mit Sync Puls: Hierzu ein Beispiel<br />
:<code>MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;</code> P0-P6 sind die Signalpegel (Dauer und positiv/negativ). Hinter D= befindet sich die Abfolge der Signale. Die ersten beiden Ziffern 15 in D sind wie folgt zu lesen. Zuerst wurde ein Signal "1" also P1 mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal "5" also P5 mit 8916 Mikrosekunden low (die Zeitdauer ergibt sich aufgrund der Mitteilung "P5=-8916") gemessen. CP=1 ist die Referenz auf den Takt des Signales - der Basistakt ist in diesem Fall ~395 Mikrosekunden. SP=5 gibt die Referenz zum Syncpuls an, der das gesamte Signal einleitet. Welche Signalfolge nun eine binäre 1 bzw. 0 bedeutet, wird im SIGNALduino über die integrierte Protokoll Liste realisiert.<br />
<br />
*MC - Nachricht vom Typ Manchester: Manchesterkodierte Signale können bereits sehr einfach im Arduino in eine Binärform umgewandelt werden. Es wird hier nach IEEE 802.3 umgewandelt. In Manchester Signalen gibt es lange und kurze Pulse. Deren Durchschnittswert wird mit LL (long low), LH (long high), SL (short low) und SH (short high) übermittelt. Zusätzlich, um das Protokoll schneller erkennen zu können, wird die Taktfrequenz mit übermittelt (C=429 Mikrosekunden). Die Daten befinden sich hinter D= und werden in HEX Form übergeben.<br />
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code><br />
<br />
*MU - Message unsynced: Diese Art von Nachrichten sind nicht nach Manchester codiert und haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht. Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist. Wie bei MS sind P0-P6 die Signalpegel und in D= wird die Abfolge der Signalpegel referenziert. CP=2 gibt auch hier die Referenz zum Takt an, allerdings muss dieser nicht korrekt erkannt worden sein.<br />
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code><br />
<br />
Es erscheinen viele Meldungen dieser Art:<br />
<br />
<pre><br />
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate<br />
</pre><br />
<br />
Dies sind nun Bemühungen, anhand der von der SIGNALDuino-Firmware gelieferten rohen aber detaillierten Signal-Strings eine Vor-Analyse / Fingerprinting vorzunehmen.<br />
Man könnte nun z.B. bei solchen Fingerprinting-Analysen erkennen:<br />
* dass der Basis-Takt-Wert innerhalb eines charakteristischen Zeit-Bereichs liegt<br />
* dass die Anzahl der Sync-Pulse eine präzise Zahl ist<br />
* dass Längen erkannter Puls-Typen innerhalb eines Bereichs liegen<br />
<br />
Mittels solcher Untersuchungen kann man also final hoffentlich hinreichend plausibel feststellen, "dass diese Aktivitäten offensichtlich(?) zu einer Funk-Komponente Rauchmelder von Hersteller XYZ gehören müssen, und man somit weiterleiten muss an ein (möglicherweise bereits existierendes) Userdaten-Dekodier-Modul für diese Herstellerkomponente".<br />
<br />
<br />
Bei einer dann erfolgenden Demodulation des noch rohen SIGNALDuino-Strings könnte man z.B. (hoffentlich richtigerweise) annehmen, dass eine Signalpegel-Typ-Folge "13" eine binäre 1 bedeuten soll, während eine Folge "12" eine binäre 0 bedeuten soll. Man erhält aus dem Gesamt-Puls-String also nach vollständiger Demodulation eine Abfolge von vielen 0/1 Bits, die insgesamt ein Datenwort darstellen, mit einer gewissen Länge von NN bits (diese Längen-Angabe könnte übrigens - neben Namenssuche nach Hersteller oder Produkt etc. - ein wichtiges Internet-Such-Merkmal sein, ob andere Frameworks tatsächlich bereits wissen, wie Daten dieser Funk-Komponente zu dekodieren sind!). Dieses demodulierte Datenwort ist nun das finale Datenwort, welches einen Container für die Funk-Komponenten-Informationen darstellt (in diesem Container also beispielsweise folgende Bits-Bereiche enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Daten-Container erst einmal CRC- oder Crypto-verschlüsselt ist...).<br />
<br />
Man muss an dieser Stelle unbedingt sagen, dass dieses Userdaten-Datenwort (einer bestimmten Hersteller-Funk-Komponente!) natürlich bei ''jeglichen'' Transceiver-Systemen ''immer'' gleich (identisch) erkannt werden ''muss'' - an dieser Stelle ist also ganz klar, dass diese Daten an ''allgemeine'' FHEM-Module weitergeleitet (Dispatched) werden müssen, die nach Übernahme von Daten von ''jeglichen'' Transceiver-Systemen diese Daten immer auf die gleiche Weise ('''''generisch/zentral''''') für die jeweilige Hersteller-Funk-Komponente erledigen.<br />
<br />
'''Die Abfolge ist also ganz klar:'''<br />
Funk-Aktivität --> Transceiver-Gerät/Firmware (SIGNALDuino) --> maximal detailreich beschreibender Rx-Analyse-Output-String --> Fingerprinting-Grobzuordnung des (SIGNALDuino-Firmware-)Outputs (durch 00_SIGNALduino.pm) auf gerätespezifisches Verhalten --> ''generische/zentrale'' Dekodierung des gerätespezifischen Protokoll-Datenworts, in zentralen Grundsatz-Modulen wie z.B. <code>14_SD_WS.pm</code>).<br />
<br />
Und wenn dann bei einer solchen Schritte-Abfolge irgendetwas noch fehlen/unpassend sein sollte, dann muss eben entsprechendes Development an gewissen Stellen erfolgen ;-)<br />
<br />
====Minimieren (whitelist/blacklist) von unerwünschter Kommunikations-Aktivität/Einträgen====<br />
<br />
"Unknown Code" bedeutet, dass der SIGNALduino Signaldaten empfangen und diese binär interpretiert hat. Diese Meldung soll uns nun aber mitteilen, dass es dann nicht weiter verarbeitet werden kann, da kein Modul existiert (oder kein Weiterleitungs-Dispatch zu einem bereits existierenden), welches diese Daten jetzt in ihre Bedeutung umwandeln kann. <br />
:<code>sduino: Unknown code u1FFFFF0, help me!</code><br />
<br />
Außerdem kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:<br />
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code><br />
<br />
Mittlerweile sind über 50 Protokolle für den SIGNALduino definiert. Dadurch kommt es vor, dass sich ein Signal mit mehr als einem Protokoll demodulieren lässt. Meist führt dies dann zu zusätzlichen "Unknown code"-Einträgen.<br />
<br />
Derartige Einträge können mit dem Attribut <code>WhitelistID</code> minimiert werden. Dabei werden die Geräte, die nach Daten-Empfang tatsächlich verarbeitet werden sollen (also welche Protokolle vom FHEM Modul berücksichtigt werden), mit ihrer Protokollnummer in die <code>WhitelistID</code> aufgenommen.<br />
Für Protokolle, die nicht berücksichtigt werden, gibt es weder Logeinträge noch Events. Diese werden im Programmablauf nicht berücksichtigt. Das spart zum einen Ressourcen und trägt auch zur Übersichtlichkeit bei. <br />
Die Protokollnummer kann der Tabelle [[#Unterstützte Geräte|Unterstützte Geräte]] entnommen werden (hilfreich ist es auch, wenn in den verwendeten Geräten im Internal <gerätename>_DMSG nachgesehen wird). So bedeutet beispielsweise ein Eintrag der Form <code>W50#FF553335FFBC</code> dass dann das Protokoll #50 in die Whitelist aufzunehmen wäre (<code>attr sduino whitelist_IDs 50</code>).<br />
{{Randnotiz|RNTyp=r|RNText=Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!!<br />
}}<br />
Die Angabe erfolgt durch Komma getrennt: z.B.:<br />
:<code>1,2,5,10</code><br />
<br />
=== Senden mit dem SIGNALduino ===<br />
Der SIGNALduino kann etwas "raw senden", indem ihm das Signal so übermittelt wird, wie er es moduliert. Hierzu muss der Befehl wie folgt eingegeben werden:<br />
<br />
<code><br />
set sduino sendMsg P3#00111010#R4<br />
</code><br />
<br />
Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.<br />
Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits.<br />
<code><br />
sduino: extracted data 00111010 (bin)<br />
sduino: Found Protocol id 3 <br />
</code><br />
<br />
Alternativ kann das Signal auch in einer "Rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig:<br />
<code><br />
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;<br />
</code><br />
<br />
R=3 bedeutet, das Signal wird 3x gesendet.<br />
Die Übertragung besteht aus den in D angegebenen Pulsen, welche in P0-P5 definiert werden.<br />
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.<br />
<br />
Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.<br />
<br />
====Fehlersuche====<br />
(Zielgerät reagiert nicht, etc.)<br />
<br />
* Nachrichtenwiederholungsanzahl muss evt. für manche Geräte entsprechend groß eingestellt sein<br />
{{Randnotiz|RNTyp=r|RNText=VORSICHT blöder Schreibweisen-Mismatch ITClock vs. ITclock!!}}<br />
* Sende-Takt-Wert (Clock) passt evt. nicht ganz, siehe z.B. Thread-Antwort {{Link2Forum|Topic=58397|Message=775434|LinkText=Signalduino Version 3.3.1}}, wo für IT-Geräte ein Attribut anhand der CP= des Empfangsdaten-Logs modifiziert wird. ACHTUNG: dies kann entweder global das Internal-Attribut <code>ITClock</code> eines SIGNALduino-Transceiver-Devices sein, oder (viel besser da korrekt Geräte-Instanz-spezifische Konfiguration) das <code>ITclock</code> eines IT-Client-Devices.<br />
<br />
== Fehlerbehandlung ==<br />
<br />
=== Modul-Initialisierung ===<br />
<br />
==== Perl-Modul Digest::CRC fehlt ====<br />
<br />
Das FHEM-Log kann (bei Version ab 3.5.x) folgendes enthalten:<br />
<br />
<code>Can't locate Digest/CRC.pm in @INC (you may need to install the Digest::CRC module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib /opt/fhem . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870.<br />
BEGIN failed--compilation aborted at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870.</code><br />
<br />
In diesem Fall ist der Transceiver nicht funktionsfähig - es muss erst Perl-Modul <code>Digest::CRC</code> (Ubuntu und Debian: Package <code>libdigest-crc-perl</code>) installiert werden und fhem neu gestartet werden.<br />
<br />
=== Konfiguration von Firmware/Hardware (Reset usw.) ===<br />
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:<br />
:<code>set raw e</code><br />
Ob ein solcher Reset nötig ist, erkennt man an dem Inhalt vom Reading <code>cc1101_config</code>, dort unsinnige Werte angezeigt werden oder dem Reading <code>config</code> welches durch den Befehl "get config" aktualisiert wird, was im Standard auf "MS=1;MU=1;MC=1" entspricht.<br />
<br />
In der Firmware sind diverse Befehle eingebaut, welche über einen <code>set raw</code> Befehl im Modul direkt ausgeführt werden können. Sofern möglich, sollte die Abfrage von Werten aus dem Modul allerdings mit den dafür vorgesehenen Kommandos erfolgen, da die Rückmeldungen des <code>set raw</code> Befehls nur im Logfile ab verbose 4 erscheinen. Die Befehle sind nützlich, wenn direkt auf den Microcontroller zugegriffen wird: <br />
<br />
:<code>C<reg></code> <reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers. Example: <code>set raw C35</code> führt ab verbose 4 zu einer Logausgabe folgender Art: <code>Read, msg: C35 = 0D</code><br />
:<code>e</code> EEPROM / factory reset. resets all eeprom values without reboot<br />
:<code>W<AA><XX></code> Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die EEPROM Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2 des CC1101)<br />
<br />
Die Sendeleistung lässt sich mit <br />
:<code>get sduino ccpatable</code> <br />
<br />
prüfen, wobei die Rückmeldung wie folgt zu lesen ist: <br />
"-10_dBm" => '34',<br />
"-5_dBm" => '68',<br />
"0_dBm" => '60',<br />
"5_dBm" => '84',<br />
"7_dBm" => 'C8',<br />
"10_dBm" => 'C0' <br />
Dabei wird die Sendeleistung dauerhaft mit dem Befehl<br />
:<code>set sduino cc1101_patable <value></code><br />
hochgeschaltet (<value> durch den Wert ersetzen).<br />
<br />
Weitere Firmware-Befehle sind im Thread-Beitrag {{Link2Forum|Topic=58396|Message=497921}} zu finden.<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=82379|Message=1033374|LinkText=SIGNALDuino Schaltplan}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.rflink.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]]<br />
* [[Somfy via SIGNALduino]]<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Arduino&diff=37546Arduino2022-09-11T21:58:14Z<p>AndreasMohr: /* FTDI-Resets */ add important references to test pin problem</p>
<hr />
<div>=== Generelles zu Arduino ===<br />
<br />
====Die Arduino-Initiative====<br />
<br />
Das [http://www.arduino.cc/ Arduino]-Projekt ist eine open-source-Initiative, die "easy-to-use" Hardware und Software bereitstellt. Als Hardware stehen unterschiedliche Platinen zur Verfügung, auf denen ein Microcontroller sowie grundlegende Schnittstellen, z.B. ein USB-Port bereits "ready-to-use" vorhanden sind. An diese Boards (ab ca. 20€ Stand Nov. 2016, China-Klone ab 2€) lassen sich einfach und recht preisgünstig eigene Sensoren/Aktoren an FHEM anbinden. <br />
<br />
Das Board lässt sich u.A. mit Hilfe der Projekt-Software Arduino-IDE relativ einfach programmieren, um Sensorwerte zu verarbeiten und diese z.B. per Ethernet an FHEM zu senden oder abfragen zu lassen. Über zahlreiche Schnittstellen (Standard: RS232, TWI/1-Wire, SPI, PWM, analog/digital-I/O, I2C) mit den entsprechenden Software-Libraries kann auf viele gängige Sensoren zugegriffen werden. Über Erweiterungsboards ("Shields") können die Anschlussmöglichkeiten ausgebaut werden. Zudem ist der Anschluss von Parallel-/Seriell-/I2C-LCD-Displays und SD-Karten möglich. Die IDE läßt sich auch für andere Enwicklerboards nutzen, insbesondere den ESP8266 (für WLAN) oder Boards auf STM32-Basis.<br />
<br />
Die Arduino-Boards bzw. Klone und eine Vielfalt an Sensoren/Aktoren sind über Online-Auktionen bzw. -Anbieter einfach zu bekommen. Kommunikation mit dem Arduino ist z.B. per Netzwerk/Ethernet, WLAN, 433/868MHz/2,4GHz-RF, Bluetooth, 1-Wire etc. möglich.<br />
<br />
Bei der Anbindnung der Arduinos über USB ist zu beachten, dass auf China-Klonen in der Regel ein einfacher USB-seriell-Wandler verbaut ist, der eine eindeutige Zuordnung der Schnittstellen innerhalb des Linux-Dateisystems erschwert. Daher sind Boards mit eindeutiger Idetifizierungsmöglichkeit (in der Regel auf FTDI-Basis) für derartige Anwendungsfälle besser geeignet.<br />
<br />
<br />
====Arduino-Projekte mit Anbindung an FHEM====<br />
<br />
Folgende Projekte basieren (u.A.) auf Arduino:<br />
*[[Selbstbau_CUL]]<br />
*[[Arduino_Firmata]] bzw. [[Arduino_mit_OneWireFirmata]]<br />
*[[FHEMduino]]<br />
*[[SIGNALduino]]<br />
*[[panStamp]]s über das [[SWAP]] Protokoll per RF<br />
*[[HomeMatic_Asksin_Library]]<br />
*[[MySensors]] per RF oder RS485<br />
*[[ArduCounter]]<br />
*KeyValueProtocol (siehe {{Link2CmdRef|Anker=KeyValueProtocol}})<br />
<br />
=== Beispiel: Arduino mit Ethernet ===<br />
<br />
Eine einfache und sehr kompakte Lösung ist der Arduino Nano mit Ethernet-Shield. Der Nano hat je 8 nutzbare Analog- und Digital Ein-/Ausgänge über die sich beispielsweise Temperatursensoren, Relais etc. ansprechen lassen.<br />
<br />
Folgende Schritte sind zur Vorbereitung zu tun:<br />
<br />
# Arduino (bzw. Klon) mit Ethernet-Shield (z.B. mit ENC28J60 Chip) und gewünschten Sensoren kaufen<br />
# Arduino-IDE von der [http://arduino.cc/en/Main/Software Arduino-Homepage] (für Windows, Mac OS X und Linux vorhanden) herunterladen und installieren<br />
# Falls ENC28J60-Ethernet-Shield verwendet wird: Ethernet-Library für ENC28J60 herunterladen und in Arduino-IDE-Installation hineinkopieren (z.B. von hier: [http://trollmaker.com/article11/arduino-1-0-with-enc28j60-ethernet-shield-v1-1/], alternativ nach arduino+ENC28J60+library googeln). Eine Arduino-library für den ENC28J60, die richtige (persistente) TCP/IP-Verbindungen unterstützt und von der API her vollständig kompatibel zur original-Ethernetlibrary ist findet sich hier: [https://github.com/ntruchsess/arduino_uip UIPEthernet (arduino_uip)]<br />
# Folgenden Beispiel-Sketch mit Arduino-IDE öffnen Arduino_FHEM.ino [https://sites.google.com/site/fhemarduino/file-cabinet/Arduino_FHEM.ino?attredirects=0&amp;d=1]<br />
# IP Adresse im Sketch passend zum eigenen Netzwerk ändern (steht im Sketch auf 192.168.2.44)<br />
# Sketch auf Arduino laden<br />
# Arduino mit 5V-USB-Netzteil ans Netzwerk anschliessen<br />
# Verbindung testen indem in einem Webbrowser &lt;arduino_ip_adresse&gt;/?cmd=set_D5_ON [http://192.168.2.44/?cmd=set_D5_ON] eingegeben wird (natürlich hier die im Sketch verwendete IP-Adresse angeben). Falls an Ausgang D5 eine Leuchtdiode o.ä. angeschlossen wurde sollte diese nun leuchten.<br />
# Wenn das geklappt hat sollte sich der Ausgang auch aus der FHEM-Kommandozeile ausschalten lassen mit { GetHttpFile('192.168.2.44:80', '/?cmd=set_D5_OFF');; } -&gt; natürlich wieder die im Sketch verwendete IP-Adresse verwenden.<br />
# Letzter Schritt wäre eine Definition in die fhem.cfg einzutragen um auch entsprechende Buttons in der FHEM-Oberfläche zu haben, ggf. wieder die verwendete IP-Adresse statt arduino:80 verwenden (für die Buttons wurde das FS20-Modul verwendet):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinobutton FS20 55d1 00<br />
attr arduinobutton room Arduino<br />
define FileLog_arduinobutton FileLog /otp/fhem/log/arduinobuttonon-%Y.log arduinobutton<br />
attr FileLog_arduinobutton room Arduino<br />
define arduinoswitchon notify FS20_55d100:on { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_ON&quot;)}<br />
attr arduinoswitchon room Arduino<br />
define arduinoswitchoff notify FS20_55d100:off { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_OFF&quot;)}<br />
attr arduinoswitchoff room Arduino<br />
define weblink_arduinobutton weblink fileplot FileLog_arduinobutton:fs20:CURRENT<br />
attr weblink_arduinobutton label &quot;arduinobutton Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_arduinobutton room Arduino</nowiki><br />
<br />
<br />
Abfragen von Sensorwerten sind natürlich auch möglich, z.B. mit folgender Definition (Analog- und Digital-PINs werden alle fünf Minuten abgefragt und in Plots visualisiert):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinogetsensorvalues at +*00:05:00 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_analog_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvalues $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvalues room Arduino<br />
define FileLog_arduinogetsensorvalues FileLog /opt/fhem/log/arduinogetsensorvalues-%Y.log arduinogetsensorvalues:.*<br />
attr FileLog_arduinogetsensorvalues room Arduino<br />
define weblink_getsensorvalues weblink fileplot FileLog_arduinogetsensorvalues:arduino:CURRENT<br />
attr weblink_getsensorvalues label &quot;Arduino Sensorvalues Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvalues room Arduino<br />
define arduinogetsensorvaluesD at +*00:05:35 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_digital_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvaluesD $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvaluesD room Arduino<br />
define FileLog_arduinogetsensorvaluesD FileLog /opt/fhem/log/arduinogetsensorvaluesD-%Y.log arduinogetsensorvaluesD:.*<br />
attr FileLog_arduinogetsensorvaluesD room Arduino<br />
define weblink_getsensorvaluesD weblink fileplot FileLog_arduinogetsensorvaluesD:arduino:CURRENT<br />
attr weblink_getsensorvaluesD label &quot;Arduino Digital Values Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvaluesD room Arduino</nowiki><br />
<br />
<br />
=== WLAN ===<br />
Die Anbindung von Arduinos über WLAN ist möglich, indem z.B. ein [[ESP8266]] mit dem Arduino verbunden wird. In der Regel ist es aber zielführender, direkt den Microcontroller auf dem ESP-Board auch für die Auswertung der anzuschließenden Sensoren zu nutzen und so auf den Arduino zu verzichten. Die entsprechenden Sketche für Arduino laufen in der Regel mit geringen Überarbeitungen auch auf diesen Boards.<br />
<br />
=== ToDo ===<br />
Kommunikation via Bluetooth<br />
<br />
=== Bekannte Probleme ===<br />
==== FTDI-Resets ====<br />
[[Bild:FTDI_PINS.png|100px|thumb|right|FTDI-Pinbelegung]]<br />
Bei Arduinos Nanos mit FTDI-USB-seriell-Wandlern kann es vorkommen, dass diese immer wieder scheinbar grundlos rebooten und keine stabile Kommunikation entsteht. In diesesem Fall sollte geprüft werden, ob der TEST-Pin (26) auf Ground liegt. Ist dies nicht der Fall, kann der Fehler dadurch behoben werden, dass der TEST-Pin mit AGND (25) zusammengelötet wird:<br />
<br />
[https://ketturi.kapsi.fi/2014/04/how-to-fix-moody-arduino-nano/ How to fix moody Arduino nano]<br />
<br />
(via [https://forum.fhem.de/index.php/topic,88440.msg810659.html#msg810659 Antw:CUL -Device empfängt nach Neustart keine Daten])<br />
<br />
[[Kategorie:Arduino]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=CUL&diff=37489CUL2022-07-05T18:17:13Z<p>AndreasMohr: /* Harter Lockup des CUL */</p>
<hr />
<div>Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8&nbsp;bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433&nbsp;MHz sind weitere Protokolle zugänglich, z.&nbsp;B. Intertechno, viele Baumarkt-Funksteckdosen. <br />
<br />
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.<br />
<br />
Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1&nbsp;kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.<br />
<br />
Das CUL kann mittels des CULModuls von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.<br />
<br />
Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version&#160;3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}<br />
<br />
Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z.&nbsp;B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.<br />
<br />
Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.<br />
<br />
Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.<br />
<br />
Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.<br />
<br />
Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen. <br />
<br />
* Ist Empfang eingeschaltet ?<br />
*: <code> get myCUL raw C35</code> (13 = ja, z.&nbsp;b.: C35 = 0D / 13)<br />
* Auslesen der culfw Version:<br />
*: <code>get myCUL raw V</code><br />
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)<br />
*: <code>set myCUL raw l00</code><br />
* LED einschalten<br />
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen<br />
* LED soll blinken (einmal in der Sekunde)<br />
*: <code>set myCUL raw l02</code><br />
* Reboot / Reset des CUL:<br />
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=&gt; neue Firmware)<br />
* Freie CUL Sendezeit ([[1% Regel]]):<br />
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots<br />
* Freie Kapazität des FHT Buffers<br />
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a<br />
* Inhalt des FHT Buffers<br />
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes gross, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer<br />
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]<br />
*: <code> get myCUL raw T01</code> <br />
* Eingestellte Frequenz, Bandbreite etc. Ausgeben<br />
*: <code> get myCUL ccconf</code>. <br>Rückgabe z.&nbsp;B.: <br><code><nowiki>myCUL ccconf =&gt; freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code><br />
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):<br />
*:<code>set myCUL bWidth 464</code><br />
* Einstellen der Sendestärke:<br />
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.<br />
<br />
Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen<br />
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. <br />
<br />
Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z.&nbsp;B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl). <br />
<br />
'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).<br />
<br />
Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit&#160;:<br />
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt<br />
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet<br />
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet<br />
* <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet<br />
* <code>set CUL1 raw X21</code> normal Modus<br />
<br />
Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!<br />
<br />
Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.<br />
<br />
== Versionen ==<br />
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.<br />
<br />
* CUL V1 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.<br />
* CUL V2 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.<br />
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kByte EEPROM). Voll einsatzfähig.<br />
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM 32 kB Flashmemory, 1 kByte EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.<br />
<br />
Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.<br />
<br />
== Firmware {{Anker|FW}} ==<br />
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der<br />
* [http://culfw.de CUL Firmware Homepage]<br />
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.<br />
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der<br />
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]<br />
Hier kann man sich z.B. mit<br />
<syntaxhighlight lang="bash"><br />
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw<br />
</syntaxhighlight><br />
die aktuelle Version laden.<br />
<br />
Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:<br />
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.<br />
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.<br />
<br />
Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).<br />
<br />
Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.<br />
<br />
== Sendefrequenz ==<br />
Das CUL gibt es in Ausführungen für 868 und 433 MHz. <br />
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.<br />
<br />
Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.<br />
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.<br />
<br />
== Antenne ==<br />
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.<br />
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.<br />
<br />
Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik. <br />
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.<br />
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.<br />
<br />
Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne. <br />
<br />
Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene. <br />
<br />
Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.<br />
<br />
Weitere Informationen sind im {{Link2Forum|Topic=93021|LinkText=Antennenthread}} des Forums zu finden. <br />
<br />
Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar ("Lambda") lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").<br />
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.<br />
<br />
Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser. <br />
<br />
Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.<br />
<br />
Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4&nbsp;GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.<br />
<br />
== Antennenlänge ==<br />
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch eine Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.<br />
<br />
Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:<br />
868,35 MHz (z.B. HM, FS20, FHT …)<br />
1/4 Lambda = 8,63 Zentimeter <br />
1/2 Lambda = 17,26 Zentimeter <br />
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)<br />
<br />
433,92 MHz (z.B. Intertechno …)<br />
1/4 Lambda = 17,27 Zentimeter <br />
1/2 Lambda = 34,54 Zentimeter <br />
<br />
Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:<br />
<br />
8,6 Zentimeter als 1/4 Lambda für 868,35 MHz<br />
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz<br />
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz<br />
<br />
== Bekannte Probleme ==<br />
<br />
=== RF-Tuning ===<br />
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z.&nbsp;B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern z.&nbsp;B. der FHT Raumregler zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.<br />
<br />
Bei Empfangsproblemen von z.&nbsp;B. HEM-Sensoren oder dem S300TH kann man folgendes testen:<br />
<br />
* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.<br />
*: <code>set CUL freq 868.350</code><br />
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.<br />
*: <code>set CUL sens 8</code><br />
* Oft hilft auch, die Bandbreite auf z.&nbsp;B. 464 kHz aufzuweiten.<br />
*: <code>set CUL bWidth 464</code><br />
<br />
=== Übertragungs-Stall nach zu vielen Einträgen in der Queue ===<br />
<br />
Ich habe mich ewig damit rumgeärgert, dass die Übertragung zu bestimmten häufig angesprochenen Geräten zusammenbrach, sobald die Queue zu lang wurde (FHEM: 'list CUL').<br />
Irgendwann habe ich dann zufällig herausgefunden, dass dieses sehr fragwürdige Anwachsen der Queue an einer krassen [[Sendpool]]-Fehlkonfiguration lag: ich hatte dort ein Transceiver-Device mit angegeben, welches den [[Sendpool]]-Mechanismus (noch) gar nicht unterstützt!<br />
Sobald ich dieses falsche Gerät aus der Sendpool-Element-Liste entfernt hatte, war Ruhe --> BUG im Modul (es kann nicht sein, dass ein Device ohne [[Sendpool]]-Support das Queue-Handling so zerschießt). Dieser Bug existiert allerdings wohl weiterhin (das Perl-Handling war mir etwas zu verwirrend, um direkt zu sehen, wo das Problem ist) --> sollte nachgestellt und gefixt werden.<br />
<br />
=== Harter Lockup des CUL ===<br />
<br />
Trotz behobenem (erkanntem) Queue-Problem gibt es weiterhin Probleme ("Problem #2"): es passiert - recht selten -, dass sich der nanoCUL komplett aufhängt, mit hektisch blinkender LED.<br />
Es ist in diesem Fall noch nicht einmal mit dem Reset-Taster möglich, den Stick zu resetten - es ist also tatsächlich nötig, das USB-Kabel komplett zu ziehen. Wenigstens automatisieren lassen würde sich dieser Workaround wohl per [https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux uhubctl].<br />
Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.<br />
<br />
Device-Attribute wie <code>version</code> etc. könnten evt. den Zeitpunkt der letzten Aktivität verdeutlichen; dann im FHEM-Log um diesen Zeitpunkt herum suchen, um Auffälligkeiten/Spezialitäten zu erkennen. Und dann muss man, wenn man Pech hat, eine custom culfw bauen, die entsprechendes Reporting mit eingebaut hat...<br />
<br />
(nanoCUL; V 1.26.00 a-culfw Build: 267).<br />
<br />
UPDATE: die Lösung des Problems steht evtl. im Forum (Lockup beseitigt durch Optiboot bootloader): <br />
: {{Link2Forum|Topic=73144|Message=977406|LinkText=[Gelöst] Nanocul LED blinkt schnell}}.<br />
[https://www.ebay.de/itm/1-3-mal-Flash-Service-fur-ZigBee-nanoCUL-JeeLink-Shelly-Sonoff-Blitzwolf-Gosund/264472055531] scheint das zu bestätigen:<br />
"Weiterhin bieten wir beim nanoCUL an, einen alternativen Bootloader (Optiboot Bootloader) zu flashen.<br />
Dieser verhindert das Abstürzen des nanoCUL's im Betrieb z.B. bei FHEM. (Stichwort: opened)"<br />
<br />
--> Empfehlung: Redundanz für nahtlosen Weiterbetrieb schaffen: weiteren CUL kaufen, dessen Inbetriebnahme erfolgreich testen, dann einen der CULs auf optiboot umflashen (...lassen? Siehe bekanntes Online-Auktionshaus...), und testen.<br />
(Idee: dreckiger Workaround: mit mehreren CULs könnte man sich auch ein Script schreiben, das zwischen ihnen umschalten kann, sobald es mal wieder Probleme gibt)<br />
<br />
Ein weiterer Bericht über CUL-Lockups (dort reproduzierbar/deterministisch, und Regression-Bug): [https://github.com/heliflieger/a-culfw/issues/23 Selfmade Cul freezing with blinking LED when sending ITv3 messages #23]<br />
<br />
Randnotiz: interessante Optiboot-Modifikation, die es trotz Hardware-Sperren erreicht, per Software den Bootloader-Bereich zu flashen: [https://hackaday.com/2015/07/03/arduinos-and-other-avrs-write-to-own-flash/ Arduinos (and Other AVRs) Write To Own Flash]<br />
<br />
Evt. ist auch ein USB-Port-Reset ein funktionierender Workaround (bitte Text als bestätigt umformulieren, falls das hilft): [https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html], erwähnt in diesem {{Link2Forum|Topic=77380|Message=783352|LinkText=Forenbeitrag}}.<br />
UPDATE: ein erster Test (Device herausfinden [https://unix.stackexchange.com/questions/81754/how-to-match-a-ttyusbx-device-to-a-usb-serial-device] via fhem log infos etc., fhem shutdown, usbreset, start fhem) hat bei mir nicht funktioniert ("get ccconf" --> "No FD").<br />
<br />
==== Ständige Lockups ====<br />
Falls Lockups gefühlt "ständig" passieren sollten (alle paar Tage, oder fast täglich insb. bei warmem Wetter), dann könnte es z.B. an einem schlechten/kaputten Kabel liegen (bei mir: dünne USB-2-"Drachenschnur", mit Bissmarken o.ä. - durch ein gutes dickes USB-3-Kabel ersetzt und sofort dramatisch robuster - UPDATE: das war der erste Eindruck innerhalb weniger Tage, aber längerfristig war es gefühlt nicht wirklich besser).<br />
<br />
== Selbstbau-/Bastelprojekte ==<br />
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:<br />
* [[Selbstbau CUL]]<br />
* [[FHEMduino]]<br />
* [[SIGNALduino]]<br />
* [[MapleCUN]] mit STM32 Mikrocontroller<br />
<br />
== Links ==<br />
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]<br />
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:CUL|!]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=CUL&diff=37463CUL2022-06-01T06:38:41Z<p>AndreasMohr: CUL device lockup, further ideas</p>
<hr />
<div>Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8&nbsp;bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433&nbsp;MHz sind weitere Protokolle zugänglich, z.&nbsp;B. Intertechno, viele Baumarkt-Funksteckdosen. <br />
<br />
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.<br />
<br />
Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1&nbsp;kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.<br />
<br />
Das CUL kann mittels des CULModuls von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.<br />
<br />
Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version&#160;3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}<br />
<br />
Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z.&nbsp;B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.<br />
<br />
Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.<br />
<br />
Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.<br />
<br />
Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.<br />
<br />
Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen. <br />
<br />
* Ist Empfang eingeschaltet ?<br />
*: <code> get myCUL raw C35</code> (13 = ja, z.&nbsp;b.: C35 = 0D / 13)<br />
* Auslesen der culfw Version:<br />
*: <code>get myCUL raw V</code><br />
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)<br />
*: <code>set myCUL raw l00</code><br />
* LED einschalten<br />
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen<br />
* LED soll blinken (einmal in der Sekunde)<br />
*: <code>set myCUL raw l02</code><br />
* Reboot / Reset des CUL:<br />
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=&gt; neue Firmware)<br />
* Freie CUL Sendezeit ([[1% Regel]]):<br />
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots<br />
* Freie Kapazität des FHT Buffers<br />
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a<br />
* Inhalt des FHT Buffers<br />
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes gross, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer<br />
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]<br />
*: <code> get myCUL raw T01</code> <br />
* Eingestellte Frequenz, Bandbreite etc. Ausgeben<br />
*: <code> get myCUL ccconf</code>. <br>Rückgabe z.&nbsp;B.: <br><code><nowiki>myCUL ccconf =&gt; freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code><br />
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):<br />
*:<code>set myCUL bWidth 464</code><br />
* Einstellen der Sendestärke:<br />
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.<br />
<br />
Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen<br />
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. <br />
<br />
Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z.&nbsp;B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl). <br />
<br />
'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).<br />
<br />
Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit&#160;:<br />
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt<br />
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet<br />
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet<br />
* <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet<br />
* <code>set CUL1 raw X21</code> normal Modus<br />
<br />
Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!<br />
<br />
Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.<br />
<br />
== Versionen ==<br />
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.<br />
<br />
* CUL V1 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.<br />
* CUL V2 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.<br />
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kByte EEPROM). Voll einsatzfähig.<br />
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM 32 kB Flashmemory, 1 kByte EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.<br />
<br />
Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.<br />
<br />
== Firmware {{Anker|FW}} ==<br />
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der<br />
* [http://culfw.de CUL Firmware Homepage]<br />
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.<br />
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der<br />
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]<br />
Hier kann man sich z.B. mit<br />
<syntaxhighlight lang="bash"><br />
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw<br />
</syntaxhighlight><br />
die aktuelle Version laden.<br />
<br />
Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:<br />
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.<br />
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.<br />
<br />
Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).<br />
<br />
Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.<br />
<br />
== Sendefrequenz ==<br />
Das CUL gibt es in Ausführungen für 868 und 433 MHz. <br />
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.<br />
<br />
Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.<br />
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.<br />
<br />
== Antenne ==<br />
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.<br />
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.<br />
<br />
Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik. <br />
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.<br />
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.<br />
<br />
Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne. <br />
<br />
Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene. <br />
<br />
Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.<br />
<br />
Weitere Informationen sind im {{Link2Forum|Topic=93021|LinkText=Antennenthread}} des Forums zu finden. <br />
<br />
Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar ("Lambda") lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").<br />
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.<br />
<br />
Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser. <br />
<br />
Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.<br />
<br />
Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4&nbsp;GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.<br />
<br />
== Antennenlänge ==<br />
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch eine Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.<br />
<br />
Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:<br />
868,35 MHz (z.B. HM, FS20, FHT …)<br />
1/4 Lambda = 8,63 Zentimeter <br />
1/2 Lambda = 17,26 Zentimeter <br />
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)<br />
<br />
433,92 MHz (z.B. Intertechno …)<br />
1/4 Lambda = 17,27 Zentimeter <br />
1/2 Lambda = 34,54 Zentimeter <br />
<br />
Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:<br />
<br />
8,6 Zentimeter als 1/4 Lambda für 868,35 MHz<br />
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz<br />
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz<br />
<br />
== Bekannte Probleme ==<br />
<br />
=== RF-Tuning ===<br />
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z.&nbsp;B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern z.&nbsp;B. der FHT Raumregler zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.<br />
<br />
Bei Empfangsproblemen von z.&nbsp;B. HEM-Sensoren oder dem S300TH kann man folgendes testen:<br />
<br />
* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.<br />
*: <code>set CUL freq 868.350</code><br />
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.<br />
*: <code>set CUL sens 8</code><br />
* Oft hilft auch, die Bandbreite auf z.&nbsp;B. 464 kHz aufzuweiten.<br />
*: <code>set CUL bWidth 464</code><br />
<br />
=== Übertragungs-Stall nach zu vielen Einträgen in der Queue ===<br />
<br />
Ich habe mich ewig damit rumgeärgert, dass die Übertragung zu bestimmten häufig angesprochenen Geräten zusammenbrach, sobald die Queue zu lang wurde (FHEM: 'list CUL').<br />
Irgendwann habe ich dann zufällig herausgefunden, dass dieses sehr fragwürdige Anwachsen der Queue an einer krassen [[Sendpool]]-Fehlkonfiguration lag: ich hatte dort ein Transceiver-Device mit angegeben, welches den [[Sendpool]]-Mechanismus (noch) gar nicht unterstützt!<br />
Sobald ich dieses falsche Gerät aus der Sendpool-Element-Liste entfernt hatte, war Ruhe --> BUG im Modul (es kann nicht sein, dass ein Device ohne [[Sendpool]]-Support das Queue-Handling so zerschießt). Dieser Bug existiert allerdings wohl weiterhin (das Perl-Handling war mir etwas zu verwirrend, um direkt zu sehen, wo das Problem ist) --> sollte nachgestellt und gefixt werden.<br />
<br />
=== Harter Lockup des CUL ===<br />
<br />
Trotz behobenem (erkanntem) Queue-Problem gibt es weiterhin Probleme ("Problem #2"): es passiert - recht selten -, dass sich der nanoCUL komplett aufhängt, mit hektisch blinkender LED.<br />
Es ist in diesem Fall noch nicht einmal mit dem Reset-Taster möglich, den Stick zu resetten - es ist also tatsächlich nötig, das USB-Kabel komplett zu ziehen. Wenigstens automatisieren lassen würde sich dieser Workaround wohl per [https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux uhubctl].<br />
Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.<br />
<br />
Device-Attribute wie <code>version</code> etc. könnten evt. den Zeitpunkt der letzten Aktivität verdeutlichen; dann im FHEM-Log um diesen Zeitpunkt herum suchen, um Auffälligkeiten/Spezialitäten zu erkennen. Und dann muss man, wenn man Pech hat, eine custom culfw bauen, die entsprechendes Reporting mit eingebaut hat...<br />
<br />
(nanoCUL; V 1.26.00 a-culfw Build: 267).<br />
<br />
UPDATE: die Lösung des Problems steht evtl. im Forum (Lockup beseitigt durch Optiboot bootloader): <br />
: {{Link2Forum|Topic=73144|Message=977406|LinkText=[Gelöst] Nanocul LED blinkt schnell}}.<br />
[https://www.ebay.de/itm/1-3-mal-Flash-Service-fur-ZigBee-nanoCUL-JeeLink-Shelly-Sonoff-Blitzwolf-Gosund/264472055531] scheint das zu bestätigen:<br />
"Weiterhin bieten wir beim nanoCUL an, einen alternativen Bootloader (Optiboot Bootloader) zu flashen.<br />
Dieser verhindert das Abstürzen des nanoCUL's im Betrieb z.B. bei FHEM. (Stichwort: opened)"<br />
<br />
--> Empfehlung: Redundanz für nahtlosen Weiterbetrieb schaffen: weiteren CUL kaufen, dessen Inbetriebnahme erfolgreich testen, dann einen der CULs auf optiboot umflashen (...lassen? Siehe bekanntes Online-Auktionshaus...), und testen.<br />
(Idee: dreckiger Workaround: mit mehreren CULs könnte man sich auch ein Script schreiben, das zwischen ihnen umschalten kann, sobald es mal wieder Probleme gibt)<br />
<br />
Ein weiterer Bericht über CUL-Lockups (dort reproduzierbar/deterministisch, und Regression-Bug): [https://github.com/heliflieger/a-culfw/issues/23 Selfmade Cul freezing with blinking LED when sending ITv3 messages #23]<br />
<br />
Evt. ist auch ein USB-Port-Reset ein funktionierender Workaround (bitte Text als bestätigt umformulieren, falls das hilft): [https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html], erwähnt in diesem {{Link2Forum|Topic=77380|Message=783352|LinkText=Forenbeitrag}}.<br />
UPDATE: ein erster Test (Device herausfinden [https://unix.stackexchange.com/questions/81754/how-to-match-a-ttyusbx-device-to-a-usb-serial-device] via fhem log infos etc., fhem shutdown, usbreset, start fhem) hat bei mir nicht funktioniert ("get ccconf" --> "No FD").<br />
<br />
==== Ständige Lockups ====<br />
Falls Lockups gefühlt "ständig" passieren sollten (alle paar Tage, oder fast täglich insb. bei warmem Wetter), dann könnte es z.B. an einem schlechten/kaputten Kabel liegen (bei mir: dünne USB-2-"Drachenschnur", mit Bissmarken o.ä. - durch ein gutes dickes USB-3-Kabel ersetzt und sofort dramatisch robuster - UPDATE: das war der erste Eindruck innerhalb weniger Tage, aber längerfristig war es gefühlt nicht wirklich besser).<br />
<br />
== Selbstbau-/Bastelprojekte ==<br />
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:<br />
* [[Selbstbau CUL]]<br />
* [[FHEMduino]]<br />
* [[SIGNALduino]]<br />
* [[MapleCUN]] mit STM32 Mikrocontroller<br />
<br />
== Links ==<br />
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]<br />
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:CUL|!]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=CUL&diff=37462CUL2022-06-01T06:27:30Z<p>AndreasMohr: Add device lockup current status details</p>
<hr />
<div>Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8&nbsp;bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433&nbsp;MHz sind weitere Protokolle zugänglich, z.&nbsp;B. Intertechno, viele Baumarkt-Funksteckdosen. <br />
<br />
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.<br />
<br />
Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1&nbsp;kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.<br />
<br />
Das CUL kann mittels des CULModuls von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.<br />
<br />
Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version&#160;3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}<br />
<br />
Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z.&nbsp;B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.<br />
<br />
Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.<br />
<br />
Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.<br />
<br />
Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.<br />
<br />
Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen. <br />
<br />
* Ist Empfang eingeschaltet ?<br />
*: <code> get myCUL raw C35</code> (13 = ja, z.&nbsp;b.: C35 = 0D / 13)<br />
* Auslesen der culfw Version:<br />
*: <code>get myCUL raw V</code><br />
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)<br />
*: <code>set myCUL raw l00</code><br />
* LED einschalten<br />
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen<br />
* LED soll blinken (einmal in der Sekunde)<br />
*: <code>set myCUL raw l02</code><br />
* Reboot / Reset des CUL:<br />
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=&gt; neue Firmware)<br />
* Freie CUL Sendezeit ([[1% Regel]]):<br />
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots<br />
* Freie Kapazität des FHT Buffers<br />
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a<br />
* Inhalt des FHT Buffers<br />
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes gross, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer<br />
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]<br />
*: <code> get myCUL raw T01</code> <br />
* Eingestellte Frequenz, Bandbreite etc. Ausgeben<br />
*: <code> get myCUL ccconf</code>. <br>Rückgabe z.&nbsp;B.: <br><code><nowiki>myCUL ccconf =&gt; freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code><br />
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):<br />
*:<code>set myCUL bWidth 464</code><br />
* Einstellen der Sendestärke:<br />
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.<br />
<br />
Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen<br />
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. <br />
<br />
Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z.&nbsp;B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl). <br />
<br />
'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).<br />
<br />
Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit&#160;:<br />
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt<br />
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet<br />
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet<br />
* <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet<br />
* <code>set CUL1 raw X21</code> normal Modus<br />
<br />
Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!<br />
<br />
Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.<br />
<br />
== Versionen ==<br />
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.<br />
<br />
* CUL V1 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.<br />
* CUL V2 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.<br />
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kByte EEPROM). Voll einsatzfähig.<br />
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM 32 kB Flashmemory, 1 kByte EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.<br />
<br />
Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.<br />
<br />
== Firmware {{Anker|FW}} ==<br />
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der<br />
* [http://culfw.de CUL Firmware Homepage]<br />
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.<br />
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der<br />
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]<br />
Hier kann man sich z.B. mit<br />
<syntaxhighlight lang="bash"><br />
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw<br />
</syntaxhighlight><br />
die aktuelle Version laden.<br />
<br />
Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:<br />
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.<br />
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.<br />
<br />
Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).<br />
<br />
Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.<br />
<br />
== Sendefrequenz ==<br />
Das CUL gibt es in Ausführungen für 868 und 433 MHz. <br />
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.<br />
<br />
Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.<br />
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.<br />
<br />
== Antenne ==<br />
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.<br />
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.<br />
<br />
Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik. <br />
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.<br />
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.<br />
<br />
Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne. <br />
<br />
Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene. <br />
<br />
Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.<br />
<br />
Weitere Informationen sind im {{Link2Forum|Topic=93021|LinkText=Antennenthread}} des Forums zu finden. <br />
<br />
Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar ("Lambda") lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").<br />
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.<br />
<br />
Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser. <br />
<br />
Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.<br />
<br />
Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4&nbsp;GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.<br />
<br />
== Antennenlänge ==<br />
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch eine Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.<br />
<br />
Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:<br />
868,35 MHz (z.B. HM, FS20, FHT …)<br />
1/4 Lambda = 8,63 Zentimeter <br />
1/2 Lambda = 17,26 Zentimeter <br />
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)<br />
<br />
433,92 MHz (z.B. Intertechno …)<br />
1/4 Lambda = 17,27 Zentimeter <br />
1/2 Lambda = 34,54 Zentimeter <br />
<br />
Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:<br />
<br />
8,6 Zentimeter als 1/4 Lambda für 868,35 MHz<br />
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz<br />
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz<br />
<br />
== Bekannte Probleme ==<br />
<br />
=== RF-Tuning ===<br />
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z.&nbsp;B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern z.&nbsp;B. der FHT Raumregler zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.<br />
<br />
Bei Empfangsproblemen von z.&nbsp;B. HEM-Sensoren oder dem S300TH kann man folgendes testen:<br />
<br />
* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.<br />
*: <code>set CUL freq 868.350</code><br />
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.<br />
*: <code>set CUL sens 8</code><br />
* Oft hilft auch, die Bandbreite auf z.&nbsp;B. 464 kHz aufzuweiten.<br />
*: <code>set CUL bWidth 464</code><br />
<br />
=== Übertragungs-Stall nach zu vielen Einträgen in der Queue ===<br />
<br />
Ich habe mich ewig damit rumgeärgert, dass die Übertragung zu bestimmten häufig angesprochenen Geräten zusammenbrach, sobald die Queue zu lang wurde (FHEM: 'list CUL').<br />
Irgendwann habe ich dann zufällig herausgefunden, dass dieses sehr fragwürdige Anwachsen der Queue an einer krassen [[Sendpool]]-Fehlkonfiguration lag: ich hatte dort ein Transceiver-Device mit angegeben, welches den [[Sendpool]]-Mechanismus (noch) gar nicht unterstützt!<br />
Sobald ich dieses falsche Gerät aus der Sendpool-Element-Liste entfernt hatte, war Ruhe --> BUG im Modul (es kann nicht sein, dass ein Device ohne [[Sendpool]]-Support das Queue-Handling so zerschießt). Dieser Bug existiert allerdings wohl weiterhin (das Perl-Handling war mir etwas zu verwirrend, um direkt zu sehen, wo das Problem ist) --> sollte nachgestellt und gefixt werden.<br />
<br />
=== Harter Lockup des CUL ===<br />
<br />
Trotz behobenem (erkanntem) Queue-Problem gibt es weiterhin Probleme ("Problem #2"): es passiert - recht selten -, dass sich der nanoCUL komplett aufhängt, mit hektisch blinkender LED.<br />
Es ist in diesem Fall noch nicht einmal mit dem Reset-Taster möglich, den Stick zu resetten - es ist also tatsächlich nötig, das USB-Kabel komplett zu ziehen. Wenigstens automatisieren lassen würde sich dieser Workaround wohl per [https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux uhubctl].<br />
Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.<br />
<br />
Device-Attribute wie <code>version</code> etc. könnten evt. den Zeitpunkt der letzten Aktivität verdeutlichen; dann im FHEM-Log um diesen Zeitpunkt herum suchen, um Auffälligkeiten/Spezialitäten zu erkennen. Und dann muss man, wenn man Pech hat, eine custom culfw bauen, die entsprechendes Reporting mit eingebaut hat...<br />
<br />
(nanoCUL; V 1.26.00 a-culfw Build: 267).<br />
<br />
UPDATE: die Lösung des Problems steht evtl. im Forum (Lockup beseitigt durch Optiboot bootloader): <br />
: {{Link2Forum|Topic=73144|Message=977406|LinkText=[Gelöst] Nanocul LED blinkt schnell}}.<br />
[https://www.ebay.de/itm/1-3-mal-Flash-Service-fur-ZigBee-nanoCUL-JeeLink-Shelly-Sonoff-Blitzwolf-Gosund/264472055531] scheint das zu bestätigen:<br />
"Weiterhin bieten wir beim nanoCUL an, einen alternativen Bootloader (Optiboot Bootloader) zu flashen.<br />
Dieser verhindert das Abstürzen des nanoCUL's im Betrieb z.B. bei FHEM. (Stichwort: opened)"<br />
<br />
Ein weiterer Bericht über CUL-Lockups (dort reproduzierbar/deterministisch, und Regression-Bug): [https://github.com/heliflieger/a-culfw/issues/23 Selfmade Cul freezing with blinking LED when sending ITv3 messages #23]<br />
<br />
Evt. ist auch ein USB-Port-Reset ein funktionierender Workaround (bitte Text als bestätigt umformulieren, falls das hilft): [https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html], erwähnt in diesem {{Link2Forum|Topic=77380|Message=783352|LinkText=Forenbeitrag}}.<br />
UPDATE: ein erster Test (Device herausfinden [https://unix.stackexchange.com/questions/81754/how-to-match-a-ttyusbx-device-to-a-usb-serial-device] via fhem log infos etc., fhem shutdown, usbreset, start fhem) hat bei mir nicht funktioniert ("get ccconf" --> "No FD").<br />
<br />
==== Ständige Lockups ====<br />
Falls Lockups gefühlt "ständig" passieren sollten (alle paar Tage, oder fast täglich insb. bei warmem Wetter), dann könnte es z.B. an einem schlechten/kaputten Kabel liegen (bei mir: dünne USB-2-"Drachenschnur", mit Bissmarken o.ä. - durch ein gutes dickes USB-3-Kabel ersetzt und sofort dramatisch robuster - UPDATE: das war der erste Eindruck innerhalb weniger Tage, aber längerfristig war es gefühlt nicht wirklich besser).<br />
<br />
== Selbstbau-/Bastelprojekte ==<br />
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:<br />
* [[Selbstbau CUL]]<br />
* [[FHEMduino]]<br />
* [[SIGNALduino]]<br />
* [[MapleCUN]] mit STM32 Mikrocontroller<br />
<br />
== Links ==<br />
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]<br />
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:CUL|!]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Weblink&diff=37161Weblink2022-01-27T23:09:21Z<p>AndreasMohr: /* Anwendungsbeispiele */ Konkretes, hilfreiches Beispiel für weblink in htmlCode-Variante</p>
<hr />
<div>{{SEITENTITEL:weblink}}<br />
{{Infobox Modul<br />
|ModPurpose=Platzhalter zur Anzeige benutzerdefinierter Links <br />
|ModType=h<br />
|ModCmdRef=weblink<br />
|ModForumArea=Frontends<br />
|ModTechName=98_weblink.pm<br />
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])<br />
}}<br />
<br />
Das (Hilfs-)Modul [[weblink]] ermöglicht es, eigene Links in die [[FHEMWEB|Fhem Oberfläche]] einzubinden.<br />
<br />
== Voraussetzungen ==<br />
Keine.<br />
<br />
== Anwendung ==<br />
=== Define ===<br />
Details in der {{Link2CmdRef|Anker=weblinkdefine}}. <br />
<br />
=== Attribute ===<br />
Details in der {{Link2CmdRef|Anker=weblink}}. <br />
<br />
=== Bearbeitung ===<br />
Da ''weblinks'' in der FHEM-Oberfläche keine einfache Möglichkeit bieten, in den Bearbeitungsmodus zu wechseln, empfiehlt es sich, z.B. den Weg über <br />
* <code>list TYPE=weblink</code> (listet alle definierten ''weblinks'' auf) oder<br />
* <code>list name_des_weblinks</code> (sofern der Name des gewünschten ''weblinks'' bekannt ist)<br />
zu gehen.<br />
<br />
== Anwendungsbeispiele ==<br />
Die Anwendung von Weblinks ist erläutert und bebildert z.B. auf der Seite [[UWZ]]. Des Weiteren werden auch [[SVG|Diagramme]] in der Regel als ''weblink'' des Typs '''''fileplot''''' definiert und eingebunden.<br />
<br />
=== htmlCode-Typ, für simple aber wichtige Formatierungs-Ergänzungen ===<br />
<br />
<code>define weblink_test_web_archive_org weblink htmlCode { '<a href="https://web.archive.org">web.archive.org test</a><br>' }</code><br />
<br />
(weil die Usability von weblink durchaus ein Buch mit sieben Siegeln sein kann - siehe exemplarische Foren-Diskussion...)<br />
<br />
== Links ==<br />
* Forenthema {{Link2Forum|Topic=75172|LinkText=weblink - wie editieren?}}</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=JUDO_iSoft_Plus&diff=37135JUDO iSoft Plus2022-01-20T22:26:32Z<p>AndreasMohr: Typos / language</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=judo-soft-plus.jpg|200px<br />
|Bildbeschreibung=JUDO i-soft plus Wasserenthärtungsanlage<br />
|HWProtocol=IP<br />
|HWType=Wasserenthärter<br />
|HWCategory=IP<br />
|HWVoltage=230&nbsp;V<br />
|HWPoweredBy=AC<br />
|HWSize=39x67x45 cm (BxHxT)<br />
|HWComm=n/a<br />
|HWChannels=n/a<br />
|HWPowerConsumption=?<br />
|HWDeviceFHEM=[[HTTPMOD]]<br />
<!-- |ModOwner= --><br />
|HWManufacturer=JUDO GmbH<br />
}}<br />
__TOC__<br />
<br />
Die JUDO i-soft plus Enthärtungsanlage [https://judo.eu/produkt/judo-i-soft-plus-vollautomatische-enthaertungsanlage/] ist eine Wasserenthärtungsanlage mit IP-Konnektivität. <br />
Sie verfügt über LAN- und WLAN-Anschluss und ist auf die Steuerung via App des Herstellers ausgelegt.<br />
<br />
== Geräte-Registrierung ==<br />
<br />
Für eine erfolgreiche Integration in FHEM muss die Anlage über das Menü beim Hersteller registriert werden (wohl nur i-soft plus; z.B. i-soft safe kann das wohl nicht, schlechtere Display-Ausstattung - hier gilt dann [https://www.ju-control.app/] oder die Handy-Apps).<br />
Die folgenden Informationen sind erforderlich:<br />
<br />
* Benutzername: Selbst gewählter Login-Name auf der i-soft plus (vgl. Gerätehandbuch)<br />
* Kennwort: Selbst gewähltes Kennwort<br />
* Seriennummer: Seriennummer des Geräts. Diese ist entweder über das Menü auslesbar oder alternativ auch über die APP des Herstellers.<br />
* IP-Adresse: Die IP-Adresse des Geräts im Heimnetz. <br />
<br />
Bei den Registrier-Prozessen ist zwingend zu beachten, dass es '''mehrere''' Labels mit QR-Codes / Gerätedaten geben kann (zumindest bei i-soft safe): auf den Gehäuse-Seite'''n''' und auf dem Connectivity Module - man sollte also tunlichst die '''richtige''' Referenz erwischen, sonst Fehlschlag!<br />
(Ich hatte mehrere Prozess-Probleme, somit in Beschwerdemail mehrere momentan existierende gravierende Registrier-Prozess-Impräzisionen angem***t, daraufhin INSTANTAN (8 Uhr) Rückruf durch Kundendienst! *daumenhoch*)<br />
<br />
Bei Geräten neuerer Generation scheint es so zu sein, dass die Schnittstelle über Port 8124 nur den Login erlaubt, wenn bei der Geräteregistrierung die Datenschutzerklärung '''nicht''' akzeptiert wird. Falls also trotz korrekter Einstellungen "login failed" kommt, versuchen bei der Registrierung die Datenschutzeinstellungen zu ändern.<br />
<br />
== Einbindung in FHEM ==<br />
<br />
Das Gerät wird mittels des Moduls HTTPMOD eingebunden. Dazu gilt zunächst die folgende Konfiguration als Basis.<br />
Zunächst legen wir die Standardanfrage an das Modul fest. Die Portnummer 8124 ist vom Hersteller vorgegeben. Wir vergeben gleich ein paar Platzhalter, die später in den Aufrufen und den Antworten ersetzt werden, damit wir die Werte nur an einer zentralen Stelle konfigurieren müssen.<br />
<br />
<pre><br />
define JUDO_iSoft HTTPMOD https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=4&token=%token% 300<br />
</pre><br />
Mit dieser Definition wird als Standard-Anfrage die Statusabfrage nach dem Wasserstop gesendet. Diese wird zyklisch alle 300 Sekunden wiederholt. <br />
Wem das nicht reicht, der kann den Zyklus herunter setzen oder auch nach anderen Standard-Werten abfragen. Wer das kontinuierliche Pollen vermeiden will, setzt den Wert auf 0.<br />
<br />
Nach erfolgreicher Authentifizierung wird von der i-soft ein Token generiert, welches bei jedem Aufruf übergeben werden muss:<br />
<br />
<pre><br />
attr JUDO_iSoft replacement01Mode reading<br />
attr JUDO_iSoft replacement01Regex %token%<br />
attr JUDO_iSoft replacement01Value token<br />
</pre><br />
<br />
Anschließend legen wir die Ersetzungen für die anderen Platzhalter fest: <br />
<br />
<pre><br />
attr JUDO_iSoft replacement02Mode text<br />
attr JUDO_iSoft replacement02Regex %JUDO_ipaddress%<br />
attr JUDO_iSoft replacement02Value <hier eigene IP Adresse im lokalen Netz eintragen><br />
attr JUDO_iSoft replacement03Mode text<br />
attr JUDO_iSoft replacement03Regex %JUDO_password%<br />
attr JUDO_iSoft replacement03Value <hier Kennwort eintragen><br />
attr JUDO_iSoft replacement04Mode text<br />
attr JUDO_iSoft replacement04Regex %JUDO_username%<br />
attr JUDO_iSoft replacement04Value <hier Benutzername eintragen><br />
attr JUDO_iSoft replacement05Mode text<br />
attr JUDO_iSoft replacement05Regex %JUDO_serial%<br />
attr JUDO_iSoft replacement05Value <hier Seriennummer eintragen><br />
</pre><br />
<br />
Die Authentifizierung der Anlage erfolgt zweistufig. Zunächst muss ein Aufruf mit Benutzername und Kennwort erfolgen. Als Antwort erhält man einen JSON-String, der das Token beinhaltet. Mit diesem Token wird anschließend die Funktion connect aufgerufen und die Seriennummer des Geräts mit übergeben. <br />
HTTPMOD erkennt, wenn ein neues Login erforderlich ist, wenn die JUDO die Rückmeldung "no token" oder "not logged in" liefert.<br />
<br />
Achtung: Als Parameter muss ebenfalls der Typ "i-soft plus" übergeben werden. Vermutlich ist dieser bei anderen Geräten des Herstellers anders. Ich habe ihn hier fix eingetragen, da ich keine Möglichkeit zum Testen anderer Geräte habe. <br />
<br />
<pre><br />
attr JUDO_iSoft showError 1<br />
attr JUDO_iSoft authRetries 2<br />
attr JUDO_iSoft reAuthRegex (no token)|(not logged in)<br />
attr JUDO_iSoft sid01ParseResponse 1<br />
attr JUDO_iSoft sid01URL https://%JUDO_ipaddress%:8124/?group=register&command=login&msgnumber=1&name=login&user=%JUDO_username%&password=%JUDO_password%&role=customer<br />
attr JUDO_iSoft sid02URL https://%JUDO_ipaddress%:8124/?group=register&command=connect&msgnumber=6&token=%token%&parameter=i-soft%20plus&serial%20number=%JUDO_serial%<br />
</pre><br />
<br />
Damit ist die Grundkonfiguration hergestellt und die Anlage kann sich connecten. <br />
In den einzelnen JSON-Rückantworten der Anlage werden die Werte zur jeweilige Anfrage immer als "data" zurückgeliefert. Mit der Standard-Konfiguration<br />
<br />
<pre><br />
attr JUDO_iSoft extractAllJSON 1<br />
</pre><br />
<br />
werden daraus automatisch entsprechende Readings angelegt. Da wir aber dann immer das Reading "data" überschreiben würden, kommt eine weitere Ersetzung zum Einsatz. In der Antwort steht neben einer Kaskadierung (group) auch der zugehörige Befehl (command). Ich habe mich dafür entschieden, ein neues Reading mit dem jeweiligen Command-Namen anzulegen. Die zugehörigen Ersetzungen sind wie folgt.<br />
Erklärung zum Ausdruck reading03OExpr: Zunächst werden die Leerzeichen im Rückgabewert ($val) durch "-" ersetzt. Mit dem so veränderten String erzeugen wir ein neues Reading mit dem Wert aus dem Reading data. <br />
<br />
<pre><br />
attr JUDO_iSoft reading01JSON data<br />
attr JUDO_iSoft reading01Name token<br />
attr JUDO_iSoft reading01Regex "token":"([^"]+)"<br />
attr JUDO_iSoft reading02JSON group<br />
attr JUDO_iSoft reading03JSON command<br />
attr JUDO_iSoft reading03OExpr $val =~ s/\s/-/;; $val;; readingsBulkUpdate($hash,$val,ReadingsVal("JUDO_iSoft","data",""))<br />
</pre><br />
Noch ein paar ergänzende Attribute gesetzt:<br />
<pre><br />
attr JUDO_iSoft enableControlSet 1<br />
attr JUDO_iSoft getHeader1 Content-Type: application/json<br />
attr JUDO_iSoft getHeader2 Accept: */*<br />
attr JUDO_iSoft room 10_Räume->UG->Keller,<br />
attr JUDO_iSoft showError 1<br />
attr JUDO_iSoft timeout 5<br />
</pre><br />
<br />
Damit sind alle Voraussetzungen erledigt. Ab jetzt können wir die einzelnen Get-Befehle implementieren:<br />
<br />
<pre><br />
attr JUDO_iSoft get01Name SerialNumber<br />
attr JUDO_iSoft get01URL https://%JUDO_ipaddress%:8124/?group=spare%20part&command=serial%20number&msgnumber=5&token=%token%<br />
<br />
attr JUDO_iSoft get02Name WaterCurrent<br />
attr JUDO_iSoft get02URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20current&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get03Name SaltRange<br />
attr JUDO_iSoft get03URL https://%JUDO_ipaddress%:8124/?group=consumption&command=salt%20range&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get04Name SaltQuantity<br />
attr JUDO_iSoft get04URL https://%JUDO_ipaddress%:8124/?group=consumption&command=salt%20quantity&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get05Name ResidualHardness<br />
attr JUDO_iSoft get05URL https://%JUDO_ipaddress%:8124/?group=settings&command=residual%20hardness&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get06Name NaturalHardness<br />
attr JUDO_iSoft get06URL https://%JUDO_ipaddress%:8124/?group=info&command=natural%20hardness&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get07Name WaterStop<br />
attr JUDO_iSoft get07URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get08Name FlowRate<br />
attr JUDO_iSoft get08URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=flow%20rate&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get09Name SoftwareVersion<br />
attr JUDO_iSoft get09URL https://%JUDO_ipaddress%:8124/?group=version&command=software%20version&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get10Name HardwareVersion<br />
attr JUDO_iSoft get10URL https://%JUDO_ipaddress%:8124/?group=version&command=hardware%20version&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get11Name InstallationDate<br />
attr JUDO_iSoft get11URL https://%JUDO_ipaddress%:8124/?group=contract&command=init%20date&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get12Name ServiceDate<br />
attr JUDO_iSoft get12URL https://%JUDO_ipaddress%:8124/?group=contract&command=service%20date&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get13Name WaterTotal<br />
attr JUDO_iSoft get13URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20total&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get14Name WaterAverage<br />
attr JUDO_iSoft get14URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20average&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get15Name Vacation<br />
attr JUDO_iSoft get15URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=vacation&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get16Name Quantity<br />
attr JUDO_iSoft get16URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=quantity&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get17Name WaterDaily<br />
attr JUDO_iSoft get17URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20daily&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get18Name ValveState<br />
attr JUDO_iSoft get18URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=4&&token=%token%<br />
<br />
</pre><br />
<br />
Zum Setzen einiger Werte werden die folgenden Kommandos zum Schließen und Öffnen des Wasserstopps sowie das Setzen der Wunschwasserhärte implementiert<br />
<br />
<pre><br />
attr JUDO_iSoft set01Name CloseValve<br />
attr JUDO_iSoft set01URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%&parameter=close<br />
attr JUDO_iSoft set02Name OpenValve<br />
attr JUDO_iSoft set02URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%&parameter=open<br />
attr JUDO_iSoft set03Name residual-hardness<br />
attr JUDO_iSoft set03URL https://%JUDO_ipaddress%:8124/?group=settings&command=residual%20hardness&msgnumber=1&token=%token%&parameter=$val<br />
</pre><br />
<br />
<br />
<br />
'''Userreadings'''<br />
<br />
Um die Originalwerte aus der Anlage benutzerfreundlicher darzustellen, werden noch Userreadings angelegt.<br />
<br />
Die Salzrestdauer soll in Wochen angegeben (rückgemeldet werden Tage) werden, die verbleibende Salzmenge in Prozent. <br />
Die Salzmenge wird in Gramm angegeben, 50.000 entsprechen 100%.<br />
Wichtig: Bei den Userreadings muss darauf geachtet werden, dass diese mit Komma separiert und in einer Zeile geschrieben werden. <br />
<pre><br />
<br />
attr JUDO_iSoft saltRangeInWeeks { int( (ReadingsVal("JUDO_iSoft","salt-range",0)/7))} , saltQuantityInPercent { int( (ReadingsVal("JUDO_iSoft","salt-quantity",0)/50000)*100)}<br />
</pre><br />
<br />
== Readings auslesen ==<br />
Die Art der Anbindung liefert veränderte Readings nur, wenn man sie regelmäßig abfragt. Dazu habe ich dazu einen Timer aufgesetzt, der 1x am Tag die relevanten Werte abfragt. Das ist eigentlich nur wichtig, falls man ab und an doch noch über einen anderen Weg z.B. die Apps des Herstellers auf die JUDO zugreift und Werte verändert. Bei mir sieht das dann so aus:<br />
<pre><br />
Internals:<br />
COMMAND get JUDO_iSoft SaltQuantity;<br />
get JUDO_iSoft SaltRange;<br />
get JUDO_iSoft WaterDaily;<br />
get JUDO_iSoft WaterTotal;<br />
get JUDO_iSoft WaterAverage;<br />
get JUDO_iSoft FlowRate;<br />
get JUDO_iSoft ResidualHardness;<br />
<br />
DEF *23:55:00 <br />
get JUDO_iSoft SaltQuantity;<br />
get JUDO_iSoft SaltRange;<br />
get JUDO_iSoft WaterDaily;<br />
get JUDO_iSoft WaterTotal;<br />
get JUDO_iSoft WaterAverage;<br />
get JUDO_iSoft FlowRate;<br />
get JUDO_iSoft ResidualHardness;<br />
NAME at_Judo_DailyStats<br />
NR 1595<br />
PERIODIC yes<br />
RELATIVE no<br />
REP -1<br />
STATE Next: 23:55:00<br />
TIMESPEC 23:55:00<br />
TRIGGERTIME 1538862900<br />
TRIGGERTIME_FMT 2018-10-06 23:55:00<br />
TYPE at<br />
READINGS:<br />
2018-10-06 06:06:14 state Next: 23:55:00<br />
Attributes:<br />
room ,00_Masterswitches,10_Räume->UG->Keller<br />
<br />
</pre><br />
<br />
Um 1x pro Stunde gegen Ende der vollen Stunde den Wasserbrauch der aktuellen Stunde abzugreifen, setze ich einen weiteren Timer auf. Bei mir jeweils um :58 der aktuellen Stunde. Das ist natürlich nicht ganz exakt. Wenn die Uhr der JUDO und von FHEM auseinander driften bekommt man ggf. schon wieder den Wert der nächsten Stunde. <br />
<pre><br />
Internals:<br />
CFGFN <br />
COMMAND get JUDO_iSoft WaterCurrent<br />
DEF +*01:00:00 get JUDO_iSoft WaterCurrent<br />
NAME at_Judo_HourlyStats<br />
NR 34559<br />
NTM 06:58:00<br />
PERIODIC yes<br />
RELATIVE yes<br />
REP -1<br />
STATE Next: 06:58:00<br />
TIMESPEC 01:00:00<br />
TRIGGERTIME 1538801880<br />
TRIGGERTIME_FMT 2018-10-06 06:58:00<br />
TYPE at<br />
READINGS:<br />
2018-10-06 06:20:53 state Next: 06:58:00<br />
Attributes:<br />
alignTime 00:58<br />
room ,00_Masterswitches,10_Räume->UG->Keller<br />
</pre><br />
<br />
== Statistiken ==<br />
Die i-soft plus liefert verschiedene Statistiken zum Wasserverbrauch zurück. Die werden allerdings etwas eigentümlich zurückgemeldet.<br />
Unter water-current ist der jeweilige Verbrauch je Stunde zusammengefasst. Ich hole kurz vor der vollen Stunde diesen Wert ab, damit er danach im Logfile landet.<br />
Unter water-daily werden Tagesstatistiken geliefert. Kurioserweise in 3-Stunden-Paketen, d.h. 8 Werte. Die ersten Werte sind von 0h-3h, 3h-6h usw.<br />
Ich habe mich aktuell darauf beschränkt, den stündlichen Verbrauch zu erfassen und zu protokollieren. Es lassen sich aber auch bei Bedarf detaillierte Datumsbezogene Statistiken abrufen. Ich habe noch keinen sinnvollen Weg gefunden, das mit FHEM zu verbinden. <br />
<br />
<br />
== Darstellung in Tablet UI ==<br />
Ich nutze Tablet UI für die Visualisierung. <br />
Zur Darstellung der Restmengen Salz nutze ich das knob-widget, für das Setzen des Härtegrades den spinner.<br />
<br />
[[Datei:Screenshot judo 2.jpg|mini|Visualisierung der JUDO im TabletUI|200px]]<br />
<br />
<pre><br />
<div class="hbox"><br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Zustand Salz</header><br />
<div class="sheet"><br />
<br />
<div class="row"><br />
<div class="cell-50 top-align center-align left-space"><br />
<div class="big">Restmenge</div><br />
<div data-type="knob" data-device="JUDO_iSoft"<br />
data-get="saltQuantityInPercent"<br />
data-unit="%"<br />
data-step="1"<br />
data-min="0"<br />
data-max="100"<br />
data-bgcolor="#FF0000"<br />
data-fgcolor="#00FF1A"<br />
class="small readonly"><br />
</div><br />
<br />
<br />
</div><br />
<div class="cell-50 top-align center-align left-space"><br />
<div class="big">Reichweite</div><br />
<br />
<div data-type="knob" data-device="JUDO_iSoft"<br />
data-get="saltRangeInWeeks"<br />
data-unit="w"<br />
data-step="1"<br />
data-min="0"<br />
data-max="52"<br />
data-bgcolor="#FF0000"<br />
data-fgcolor="#00FF1A"<br />
class="small readonly"><br />
</div><br />
<br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserstopp</header><br />
<div class="sheet"> <br />
<div class="row top-space"><br />
<br />
<div class="cell left-align top-align left-space"><br />
<div data-type="symbol" data-device="JUDO_iSoft" data-get="valve"<br />
data-icons='["fa-close","fa-close","oa-sani_water_tap","oa-sani_water_tap"]'<br />
data-get-on='["closed","closing","opening","opened"]'<br />
data-on-colors='["#ad3333","#ff6633","#3399ff","#33ad33"]' class="big compressed"></div><br />
</div><br />
<div class="cell-60 top-align center-align"><br />
<div class="big"><br />
<br />
<div data-type="label"<br />
data-get="valve"<br />
class="valueonly"<br />
data-substitution='["opened","geöffnet","opening","öffnet gerade","closed","geschlossen","closing","schließt gerade"]'<br />
data-device="JUDO_iSoft"<br />
data-color="lightgrey"><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div class="cell left-align top-align left-space"><br />
<div data-type="push" data-device="JUDO_iSoft" data-set-on="CloseValve 1" data-get-on="valve" data-background-icon="fa-stop-circle-o" data-icon="" class="small"></div><br />
<br />
</div><br />
<div class="cell right-align top-align right-space"><br />
<br />
<div data-type="push" data-device="JUDO_iSoft" data-set-on="OpenValve 1" data-get-on="valve" data-background-icon="mi-play_circle_filled" data-icon="" class="small"></div> <br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserhärtegrad</header><br />
<br />
<div class="sheet"><br />
<div class="row"> <br />
<br />
<div class="cell-20 center-align top-align left-space"><br />
<div data-type="symbol"<br />
data-device="JUDO_iSoft"<br />
data-icon="none"<br />
data-color='none'<br />
data-height="100"<br />
data-background-icon="fa-circle"<br />
data-background-colors='["red","blue"]'<br />
data-limits='["0","1"]'><br />
<div data-type="label"<br />
data-get="natural-hardness"<br />
data-unit="&deg;h"<br />
class="valueonly"<br />
data-device="JUDO_iSoft"<br />
data-color="lightgrey"><br />
</div><br />
</div><br />
</div><br />
<br />
<div class="cell-20 top-align center-align left-space"><br />
<div data-type="image" data-size="50%" data-url="images/judo.png"></div><br />
</div><br />
<br />
<div class="cell-60 top-align center-align left-space"><br />
<br />
<div data-type="spinner"<br />
data-device="JUDO_iSoft"<br />
data-get="residual-hardness"<br />
data-set="residual-hardness"<br />
data-min=5"<br />
data-max="12"<br />
data-step="1"<br />
data-unit="&deg;h"<br />
data-longdelay="800"<br />
data-width="200"<br />
data-height="60"<br />
data-icon-left-color="blue"<br />
data-icon-right-color="red"<br />
<br />
class="valueonly"><br />
<br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserverbrauch</header><br />
<section> <br />
<div id="JUDO_iSoft"<br />
data-type="highchart"<br />
data-device="JUDO_iSoft"<br />
data-logdevice="FileLog_JUDO_ISoft"<br />
data-columnspec="4:water-current"<br />
data-style="ftui l0fill"<br />
data-linenames="Verbrauch"<br />
data-linetypes="line"<br />
data-yaxis="0,1"<br />
data-height="300"<br />
data-xunit="Uhrzeit"<br />
data-yunit="l"<br />
data-tooltip="{series.name} <b>{point.y:,.1f}</b>"<br />
data-daysago="7"<br />
data-yticks="auto"<br />
data-legendalign="right"><br />
<br />
</section><br />
<br />
</div<br />
</div><br />
</div><br />
</pre><br />
<br />
== Problemlösung ==<br />
=== DHCP (keine IP-Adress-Zuweisung) ===<br />
<br />
Ich hatte bei der Inbetriebnahme erstaunliche Probleme, erfolgreich eine IP-Adresse zu bekommen.<br />
Das hat bei mir nur einmal initial funktioniert (und die Verbindung hab ich dann verloren), und dann "nie wieder".<br />
<br />
Diagnose z.B. per DHCP-Status-Seite im Router (verbundene Geräte).<br />
<br />
Es hat bei mir NICHT geholfen, das Netzwerk-Kabel abzuziehen (--> link state change == Wink mit dem Zaunpfahl, dass es erneuert werden sollte), und auch NICHT, das i-soft stromlos zu machen.<br />
<br />
Erst nach Entfernen aller Backup-9V-Blocks '''und''' stromlos machen (--> jetzt waren alle Status-LEDs des Connectivity Module erfolgreich aus!) hat er sich endlich wieder eine IP geholt.<br />
<br />
Weitere Diagnose-Möglichkeiten:<br />
* anderes Netzwerkkabel verwenden<br />
* Netzwerkkabel mit Kabel-Tester durchklingeln (z.B. COMMUNICATION CABLE TESTER S1007)<br />
<br />
Bitte hier weiter updaten, falls klarer wird, wie der Sachverhalt ist.<br />
<br />
=== Salzbehälter ===<br />
<br />
Der Salzbehälter kann an der Boden-Platten-Naht undicht sein (vermutlich seltener Fall; jedenfalls möglich bei Systemen ~ <= 08/2019, danach hoffentlich besser), somit Leckage, mit daraus folgenden schwerwiegenden Problemen (mglw. Versalzung der - evt. auch etwas weiteren: Luftströmungen! - Umgebung; hygroskopisch / kapillar - AUA! Salpeter-Reiniger scheint eine ziemlich gute Behandlung zu sein).<br />
Wenn man auf ganz sicher gehen will hinsichtlich Leckage-Vermeidung, dann ist es wohl empfehlenswert, Entkalker-Systeme in eine Wanne zu stellen, z.B. Baumarkt-Mörtelkübel (80l? 90l?).<br />
<br />
Der Behälterrand an der Oberkante hat zu scharfen Rand / ist nicht entgratet (Kunststoff-Spritzform?) --> Pulli-Ärmel-Killer --> aufpassen.<br />
<br />
== Ähnliche Systeme ==<br />
=== JUDO iSoft Safe ===<br />
<br />
Auch auf der IP Adresse der iSoft Safe im lokalen Netzwerk bekommt man eine Übersichtsseite mit einigen Daten, die besten Ergebnisse hatte ich allerdings, als ich Requests an #myJudo [[https://www.myjudo.eu/]] geschickt habe. Ich habe hier nur die Änderungen zur Anleitung der JUDO iSoft Plus notiert.<br />
<br />
Das Grundkonzept ist hier sehr ähnlich. Die Adresse ist allerdings nicht lokal.<br />
Ein weiterer Unterschied ist, dass das Passwort als Hash(MD5) des Passwortes erwartet wird.<br />
<pre> <br />
attr JUDO_iSoft reAuthRegex (error)|(login failed)<br />
attr JUDO_iSoft replacement02Value www.myjudo.eu<br />
attr JUDO_iSoft replacement03Regex %JUDO_password%<br />
attr JUDO_iSoft replacement03Value <hier MD5 geHashtes Kennwort eintragen><br />
attr JUDO_iSoft replacement05Regex %JUDO_serial%<br />
attr JUDO_iSoft replacement05Value <hier Seriennummer (MAC Adresse) eintragen><br />
</pre> <br />
<br />
Der Login ist nur einstufig:<br />
<pre><br />
attr JUDO_iSoft sid01URL https://%JUDO_ipaddress%/interface/?group=register&command=login&name=login&user=%JUDO_username%&password=%JUDO_password%&nohash=Service&role=customer<br />
</pre><br />
<br />
Die URL um eine JSON File mit im Prinzip allen wichtigen Informationen zu bekommen habe ich so definiert. Der Request liefert ein JSON mit vermutlich allen registrierten Geräten zurück die über die "serialnumber" (MAC Adresse) identifiziert werden können. Ich habe leider nur ein Gerät und kann das daher nicht mit Sicherheit verifizieren.<br />
<br />
<pre> <br />
attr JUDO_iSoft get01JSON data<br />
attr JUDO_iSoft get01Name DeviceData<br />
attr JUDO_iSoft get01URL https:///%JUDO_ipaddress%/interface/?token=%token%&group=register&command=get%20device%20data<br />
</pre><br />
<br />
Da ich auf dem JSON / FHEM Gebiet noch wenig Erfahrung habe, habe ich keinen extra Konvertierer gebaut. Das JSON File wird vom HTTPMOD Modul automatisch angelegt und ich konnte mir über UserReadings die Informationen herauslesen (sie werden "verschlüsselt" im JSON abgelegt daher die seltsamen Abfragen).<br />
Hier einige Beispiele:<br />
<pre><br />
waterTotal { ( hex ( substr(ReadingsVal("JUDO_iSoft","DeviceData-41", ''), 6, 2).substr(ReadingsVal("JUDO_iSoft","DeviceData-41", ''), 4, 2).substr(ReadingsVal("JUDO_iSoft","DeviceData-41", ''), 2, 2).substr(ReadingsVal("JUDO_iSoft","DeviceData-41", ''), 0, 2)) / 1000 ). ' m³'},<br />
waterProcessed { ( hex ( substr(ReadingsVal("JUDO_iSoft","DeviceData-53", ''), 6, 2).substr(ReadingsVal("JUDO_iSoft","DeviceData-53", ''), 4, 2).substr(ReadingsVal("JUDO_iSoft","DeviceData-53", ''), 2, 2).substr(ReadingsVal("JUDO_iSoft","DeviceData-53", ''), 0, 2)) / 1000 ). ' m³'},<br />
saltLevel { ( hex ( substr(ReadingsVal("JUDO_iSoft","DeviceData-50", ''), 2, 2).substr(ReadingsVal("JUDO_iSoft","data_01_data_01_data_94_data", ''), 0, 2)) ). ' g'},<br />
saltRange { hex ( substr(ReadingsVal("JUDO_iSoft","DeviceData-50", ''), 6, 2).substr(ReadingsVal("JUDO_iSoft","DeviceData-50", ''), 4, 2)). " Tage" }<br />
</pre><br />
<br />
Es gibt auch die Möglichkeit, den Tagesverbrauch in 3h Paketen zu ermitteln - dazu müsste man folgendes definieren<br />
User Reading:<br />
<pre><br />
date {(strftime '%d%m%Y', localtime)},<br />
</pre><br />
<br />
und folgende Attribute:<br />
<pre><br />
attr JUDO_iSoft replacement05Mode reading<br />
attr JUDO_iSoft replacement05Regex %date%<br />
attr JUDO_iSoft replacement05Value date<br />
attr JUDO_iSoft get02JSON data<br />
attr JUDO_iSoft get02Name WaterConsumptionDay<br />
attr JUDO_iSoft get02URL https://%JUDO_ipaddress%/interface/?token=%token%&group=register&command=get_chart_data&serialnumber=%JUDO_serial%date=%date%&parameter=day<br />
</pre><br />
<br />
Hier bekommt man eine Zeile zurück wobei immer 8 Zeichen zusammen die LiterZahl (als Hex) bilden.<br />
Zeichen 0-8 - Verbrauch von 0-3 Uhr<br />
Zeichen 9-16 - Verbrauch von 3-6 Uhr usw.<br />
<br />
== Projekte der FHEM-Community ==<br />
[[https://forum.fhem.de/index.php/topic,112147.msg1064693.html#msg1064693|JUDO isoft Plus - Eine andere Definition]]<br />
<br />
== Links ==<br />
* {{Link2Forum|Topic=56455|Message=800960}}<br />
* [https://blog.muwave.de/2017/06/monitoring-and-controlling-a-judo-i-soft-plus-water-softening-device-via-lan/ ursprünglicher Beitrag bzgl. des verwendeten Protokolls]<br />
<br />
[[Kategorie:IP Components]]<br />
[[Kategorie:Other Components]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Unbekannte_Funkprotokolle&diff=36107Unbekannte Funkprotokolle2021-10-10T09:47:03Z<p>AndreasMohr: /* Ansatz 1 - Versuchen */</p>
<hr />
<div>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?<br />
<br />
Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.<br />
<br />
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>, vielleicht via BenutzerSeite (oder natürlich einfach direkt verbessern) - die Usability dieses Projekts sollte sehr gut werden...<br />
<br />
Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:<br />
<br />
Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).<br />
<br />
== Basics ==<br />
<br />
==== Hardware ====<br />
<br />
Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink. <br />
<br />
Diese unterscheiden sich in verschiedener Hinsicht:<br />
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]<br />
* Modulationsverfahren (OOK, ASK/FSK)<br />
* Frequenzband (433 MHz, 868 MHz)<br />
<br />
(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 Support für SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)<br />
<br />
==== Frequenzbereich ====<br />
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.<br />
<br />
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.<br />
<br />
==== Modulationsverfahren ====<br />
<br />
So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren. <br />
<br />
* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]<br />
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln. <br />
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]<br />
: 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]).<br />
<br />
==== Encoding oder auch Leitungscode ====<br />
<br />
Die Art und Weise wie dieses Signal interpretiert wird, hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.<br />
<br />
* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]<br />
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]<br />
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]<br />
<br />
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 <br />
* 100 (short high, long low) wird als 0<br />
* 110 (long high, short low) wird als 1<br />
interpretiert.<br />
<br />
Im FHEM-Forum gibt es viele freundliche Helfer, die Euch bei Bedarf den richtigen Weg weisen.<br />
<br />
==== Signalstruktur ====<br />
<br />
Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus<br />
<br />
| Pause | Sync | Pause | Daten |<br />
<br />
* eine größere Pause zur Trennung der Sequenzen <br />
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt<br />
* eine Pause um Sync und Daten zu trennen<br />
* die eigentlichen, zu übertragenden Daten.<br />
<br />
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]).<br />
<br />
Die Sequenz wird ggf. mehrfach wiederholt <br />
<br />
| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...<br />
<br />
==== Protokoll ====<br />
<br />
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). <br />
<br />
Mit etwas Glück erkennt z.B. SIGNALduino bereits 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.").<br />
<br />
== Wie fange ich an? ==<br />
<br />
==== Recherche ====<br />
<br />
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.<br />
<br />
Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:<br />
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]<br />
<br />
Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.<br />
<br />
==== Ansatz 1 - Versuchen ====<br />
<br />
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.<br />
<br />
Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn [[Autocreate|autocreate]] aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).<br />
<br />
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]]). <br />
<br />
Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.<br />
<br />
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<br />
* 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)<br />
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)<br />
<br />
==== Ansatz 2 - Aufschrauben ====<br />
<br />
Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.<br />
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.<br />
<br />
Das Teil ist zu klein? Folgende Möglichkeiten:<br />
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann<br />
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt<br />
<br />
Danach folgt dann Internet-Suchmaschine und das Studium der zugehörigen Data Sheets der Chips.<br />
<br />
Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen welche diese Chips unterstützen.<br />
<br />
Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen<br />
* OOK-Modulation -> [[SIGNALduino]]<br />
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]<br />
<br />
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 (Frequenzteiler, ...) im Datenblatt des daneben verbauten Chips lässt sich dann die tatsächliche Sende- bzw. Empfangsfrequenz errechnen.<br />
<br />
==== Ansatz 3 - Messen ====<br />
<br />
Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze. <br />
<br />
* 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.<br />
* 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 Internet-Suchmaschine-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].<br />
* 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.<br />
<br />
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.<br />
<br />
Die Spektrumanalyse gibt Aufschluss über<br />
* das Modulationsverfahren (OOK vs. FSK) sowie<br />
* die relevante(n) Frequenz(en)<br />
<br />
== SIGNALduino - OOK ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.<br />
<br />
==== Log-Meldungen ====<br />
<br />
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.<br />
<br />
Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.<br />
<br />
<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code><br />
<br />
Was bedeutet D=012323...?<br />
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause<br />
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal<br />
: 2 -> P2=-398 => 398 Mikrosekunden Pause<br />
: 3 -> P3=415 => 415 Mikrosekunden Signal<br />
: 2 -> P2=-398 => 398 Mikrosekunden Pause<br />
: 3 -> P3=415 => 415 Mikrosekunden Signal<br />
: ...<br />
<br />
<br />
Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:<br />
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:<br />
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:<br />
* Log-Zeitstempelmäßig genau erkennbar ist<br />
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage<br />
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.<br />
<br />
==== Frequenz ermitteln ====<br />
<br />
Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.<br />
<br />
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 <code>get ccconf</code>. 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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Eingrenzung - Selektiver Empfang ====<br />
<br />
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.<br />
<br />
Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.<br />
<br />
Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.<br />
<br />
==== Eingrenzung - Log-Analyse via regex ====<br />
<br />
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:<br />
z.B.:<br />
<br />
<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code><br />
<br />
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:<br />
<br />
<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code><br />
<br />
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.<br />
<br />
==== Variationen ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Signal analysieren ====<br />
<br />
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).<br />
<br />
Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.<br />
<br />
Gehen wir wieder von unserem Beispiel aus:<br />
<br />
<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code><br />
<br />
Wie ist diese Sequenz zu interpretieren?<br />
<br />
Anhand der anfänglich gelisteten Puls-Beschreibungen Px= (Aktiv-Indikator/Dauer):<br />
<br />
* Es startet mit einer Pause D='''0'''123232323232<br />
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms (15916 µs).<br />
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.<br />
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265<br />
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....<br />
<br />
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 Aktiv-Indikator (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.<br />
<br />
Beispiel: Den Vorspann<br />
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> (bestehend aus Puls-Beschreibungen und initialer Puls-Aktivität) lassen wir mal außen vor und konzentrieren uns auf den nachfolgenden echten Nutz-Daten-Teil (hinsichtlich dessen logischer Protokoll-Umformung hin zur finalen Nutz-Datenwort-Sequenz):<br />
<br />
<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626 (rohe Abfolge der Puls-Typen)<br />
<br />
lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL (als sSlL-Notation)<br />
<br />
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 (als Bitfolge)<br />
<br />
10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100 (Gruppierung auf Bit-Datenworte)<br />
<br />
AD99 79A2 9FBC B7FC (als Hex-Datenworte)</code><br />
<br />
Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)<br />
* 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"...<br />
* 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)<br />
<br />
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.<br />
<br />
Weitere wichtige Tips:<br />
* 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<br />
* 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<br />
* 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 <code>reload 00_SIGNALduino</code> gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!! - hoher Platzbedarf...) Attribute verbose 5 und debug 1 setzen!)<br />
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen<br />
* 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<br />
* 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:<br />
<code>define sduino_dummy SIGNALduino none</code><br />
<br />
In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:<br />
<br />
<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code><br />
<br />
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.<br />
<br />
Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.<br />
<br />
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.<br />
<br />
==== Steuern ====<br />
<br />
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].<br />
<br />
==== Signal-Protokoll-Beschreibung verfeinern ====<br />
<br />
Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:<br />
<br />
Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:<br />
<br />
wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann<br />
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:<br />
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung<br />
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen<br />
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.<br />
<br />
Daher sollte man folgendes beachten:<br />
* 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)<br />
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)<br />
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln<br />
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))<br />
<br />
Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:<br />
* einige Geräte-Pattern aus dem Log fischen<br />
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)<br />
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht<br />
* 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<br />
* evt. ist es auch hilfreich, den im Gerät verbauten Quarz 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:<br />
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code><br />
); 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ß...)<br />
<br />
==== Development / patch submission ====<br />
<br />
Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:<br />
* Änderungen durchführen (im korrekten Branch)<br />
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!<br />
* alles committen<br />
* 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<br />
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig<br />
* 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.<br />
<br />
== SIGNALduino - FSK ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt. <br />
<br />
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)<br />
<br />
Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].<br />
<br />
=== FSK Senden ===<br />
<br />
Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:<br />
000 = 2-FSK<br />
001 = GFSK<br />
011 = ASK/OOK<br />
100 = 4-FSK<br />
<br />
Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über <br />
<code>get <mysduino> ccreg 99</code><br />
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.<br />
Das Register wird über <br />
<code>set <mysduino> raw W1410</code><br />
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).<br />
<br />
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.<br />
<br />
=== Sendefrequenz und Frequenzhub ===<br />
<br />
<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div><br />
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div><br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Ermittlung der Frequenzen ===<br />
<br />
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 vorgegebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnt Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.<br />
<br />
=== Hub ===<br />
<br />
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 <br />
<code>set <mysduino> raw W1740</code><br />
an den CC1101 des SDUINO übermittelt wird.<br />
<br />
Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.<br />
<br />
<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div><br />
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div><br />
<div style="clear:both"></div><br />
<br />
=== Baudrate ===<br />
<br />
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 eine Fülle weiterer Optionen (Sync, FIFO etc.), die aber eher für Spezialisten geeignet sind.<br />
<br />
Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:<br />
FHEM <-> Arduino <-> CC1101 <-> Sendesignal<br />
<br />
Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels <code>get <myduino> ccconf</code> ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.<br />
<br />
Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittelt und einem Parameter ('''P'''uls?) 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.<br />
<br />
<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div><br />
<div style="clear:both"></div><br />
<br />
Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.<br />
<br />
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 reale Darstellung zu kommen, gebe ich 402 Samples/Symbol (Symbol=bit) ein.<br />
<br />
Das Ergebnis:<br />
<br />
<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div><br />
<div style="clear:both"></div><br />
<br />
=== Codesequenzen ===<br />
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 anders 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. <br />
<br />
Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.<br />
<br />
=== Konfiguration ===<br />
<br />
Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12<br />
<br />
Register-Settings:<br />
<br />
* Trägerfrequenz: 868.302 MHz<br />
* Deviation: 25 kHz<br />
* Bandwidth: 58 kHz<br />
* Baudrate: 24.795 kBaud<br />
* Modulation: GFSK<br />
<br />
<pre>ccregAll: <br />
<br />
ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F<br />
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B<br />
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B <br />
<br />
Configuration Register Detail (address, name, value):<br />
0x00 IOCFG2 - 0x0D<br />
0x01 IOCFG1 - 0x2E<br />
0x02 IOCFG0 - 0x2D<br />
0x03 FIFOTHR - 0x47<br />
0x04 SYNC1 - 0xD3<br />
0x05 SYNC0 - 0x91<br />
0x06 PKTLEN - 0x3D<br />
0x07 PKTCTRL1 - 0x04<br />
0x08 PKTCTRL0 - 0x32<br />
0x09 ADDR - 0x00<br />
0x0A CHANNR - 0x00<br />
0x0B FSCTRL1 - 0x06<br />
0x0C FSCTRL0 - 0x00<br />
0x0D FREQ2 - 0x21<br />
0x0E FREQ1 - 0x65<br />
0x0F FREQ0 - 0x6F<br />
0x10 MDMCFG4 - 0xF9<br />
0x11 MDMCFG3 - 0xF4<br />
0x12 MDMCFG2 - 0x18<br />
0x13 MDMCFG1 - 0x23<br />
0x14 MDMCFG0 - 0xB9<br />
0x15 DEVIATN - 0x40<br />
0x16 MCSM2 - 0x07<br />
0x17 MCSM1 - 0x00<br />
0x18 MCSM0 - 0x18<br />
0x19 FOCCFG - 0x14<br />
0x1A BSCFG - 0x6C<br />
0x1B AGCCTRL2 - 0x07<br />
0x1C AGCCTRL1 - 0x00<br />
0x1D AGCCTRL0 - 0x91<br />
0x1E WOREVT1 - 0x87<br />
0x1F WOREVT0 - 0x6B<br />
0x20 WORCTRL - 0xF8<br />
0x21 FREND1 - 0x56<br />
0x22 FREND0 - 0x11<br />
0x23 FSCAL3 - 0xEF<br />
0x24 FSCAL2 - 0x2D<br />
0x25 FSCAL1 - 0x12<br />
0x26 FSCAL0 - 0x1F<br />
0x27 RCCTRL1 - 0x41<br />
0x28 RCCTRL0 - 0x00<br />
0x29 FSTEST - 0x59<br />
0x2A PTEST - 0x7F<br />
0x2B AGCTEST - 0x3F<br />
0x2C TEST2 - 0x88<br />
0x2D TEST1 - 0x31<br />
0x2E TEST0 - 0x0B<br />
</pre><br />
<br />
=== Finale ===<br />
<br />
Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.<br />
<br />
Der SIGNALduino erkennt <br />
<pre><br />
2020.01.12 14:33:03 4: mySIGNALduino: Parse_MS, Decoded matched MS Protocol id 88 dmsg P88#74D21B18008B48058 length 68 RSSI = -32<br />
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, test ungleich: disabled<br />
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, -32 dB, dispatch<br />
2020.01.12 14:33:03 5: mySIGNALduino: dispatch P88#74D21B18008B48058<br />
2020.01.12 14:33:04 2: mySIGNALduino: SD_Keeloq_Parse Unknown device unknown with Code 012D100 detected, please define (rawdate=74D21B18008B48058)<br />
2020.01.12 14:33:04 2: autocreate: define SD_Keeloq_012D100 SD_Keeloq 012D100<br />
2020.01.12 14:33:04 2: autocreate: define FileLog_SD_Keeloq_012D100 FileLog ./log/SD_Keeloq_012D100-%Y.log SD_Keeloq_012D100<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 91.1 -> Atlantic security<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=2 reconstructed, last bit=0<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 87 -> JAROLIFT<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=1 reconstructed, last bit=1<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 88 -> HCS300/HCS301<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2<br />
</pre><br />
und routet die Requests 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.<br />
<br />
Mittlerweile ist das Protokoll als '''model enjoy_motors_HS''' in das Modul '''SD_Keeloq''' aufgenommen.<br />
<br />
== CUL - FSK und Co. ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt. <br />
<br />
Es befindet sich aber noch im Aufbau....<br />
<br />
== FAQ ==<br />
<br />
=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===<br />
<br />
Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.<br />
<br />
Die Bestimmung short High / Low erfolgt einfach dadurch, ob gesendet wird oder ob gerade eine Pause eingelegt wird.<br />
<br />
Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.<br />
<br />
Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.<br />
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.<br />
<br />
Beispiel einer empfangenen Sequenz<br />
<br />
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code><br />
<br />
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.<br />
<br />
Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.<br />
<br />
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.<br />
<br />
Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).<br />
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.<br />
<br />
== Links ==<br />
<br />
* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)<br />
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]<br />
* [https://github.com/jopohl/urh Universal Radio Hacker]<br />
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]<br />
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]<br />
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]<br />
* [[Intertechno Code Berechnung]]<br />
* [[Funksignalanalyse mit DVB-T Stick]]<br />
<br />
[[Kategorie:Intertechno]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=At&diff=36052At2021-09-24T20:26:37Z<p>AndreasMohr: defmod</p>
<hr />
<div>{{SEITENTITEL:at}}<br />
{{Infobox Modul<br />
|ModPurpose=Setzt einen Fhem-Befehl zu einem späteren Zeitpunkt ab.<br />
|ModType=h<br />
<!-- |ModCategory= (noch?) nicht verwendet --><br />
|ModCmdRef=at<br />
|ModTechName=90_at.pm<br />
|ModOwner=rudolfkoenig / [http://forum.fhem.de/index.php?action=profile;u=8 rudolfkoenig]<br />
}}<br />
<br />
[[at]] ist ein Erweiterungsmodul, mit dessen Hilfe FHEM-Befehle/-Aktionen zu einem späteren Zeitpunkt ausgeführt werden können. Es läßt sich sowohl einmalige Ausführung, als auch regelmäßige Wiederholung erzielen, Zeitangaben können relativ oder absolut erfolgen.<br />
<br />
== Voraussetzungen ==<br />
<!-- AUSKOMMENTIERT wegen derzeitiger Funktionsproblemen iZm codemirror {{Randnotiz|RNTyp=[g|Info|RNText=FHEM enthält für at eine eingebaute Perl-Syntax-Prüfung. Diese ist nach [http://fhem.de/commandref.html#perlSyntaxCheck Aktivierung] aber nur aktiv, wenn die [[Konfiguration]] -wie empfohlen- nicht direkt bearbeitet wird. ({{Link2Forum|Topic=51744}}) }} --><br />
Keine.<br />
<br />
== Anwendung ==<br />
=== Define ===<br />
<code>define <name> at <timespec|datespec> <command></code><br />
=== Besonderheit ===<br />
*timespec - '''nur Zeit''' im Format HH:MM:SS '''kann eine''' Perlfunktion sein. <br />
*datespec - '''Datum und Zeit''' ISO 8601 oder "number of sec since 1970" '''darf keine''' Perlfunktion sein.<br />
Siehe {{Link2Forum|Topic=91625|Message=168475}} <br />
<br />
=== Beispiele ===<br />
*<code>define MeineAktion at 02:02:00 set lamp on</code> → das nächste Mal um zwei Minuten nach 2 Uhr "lamp" einschalten<br />
*<code>define MeineAktion at *02:02:00 set lamp on</code> → jeden Tag um zwei Minuten nach 2 Uhr "lamp" einschalten<br />
*<code>define MeineAktion at {ReadingsVal("Dummy","Zeit","")} set lamp on</code> → das nächste Mal um (Perlfunktion liest Zeit aus dem Dummy) "lamp" einschalten<br />
*<code>define MeineAktion at 2016-01-25T02:02:00 set lamp on</code> → das nächste Mal am 25.01.2016 um zwei Minuten nach 2 Uhr "lamp" einschalten (ISO 8601)<br />
*<code>define MeineAktion at 1453683720 set lamp on</code> → das nächste Mal am 25.01.2016 um zwei Minuten nach 2 Uhr "lamp" einschalten (number of sec since 1970)<br />
*<code>define MeineAktion at +02:02:00 set lamp on</code> → in zwei Stunden und 2 Minuten "lamp" einschalten<br />
*<code>define MeineAktion at +*02:02:00 set lamp on</code> → alle zwei Stunden und 2 Minuten "lamp" einschalten<br />
Um datespec auch variabel mit setzen zu können gibt es einen Workaround: Perlebene, Perlfunktion und Übergabe in Variable. <br />
<br />
Beispiele für "number of seconds since 1970"<br />
<syntaxhighlight lang="perl"><br />
{my $time=time_str2num("2019-09-14 23:00:00");;fhem("define MeineAktion at $time set lamp on")}<br />
{my $time=1568494800;;fhem("define MeineAktion at $time set lamp on")}<br />
</syntaxhighlight><br />
Beispiel im ISO 8601 Format<br />
<syntaxhighlight lang="perl">{my $time="2019-09-14T23:00:00";;fhem("define MeineAktion at $time set lamp on")}</syntaxhighlight><br />
<br />
=== Mehrere Aktionen ausführen ===<br />
Die Verwendung der Semikolon erfordert immer besondere Aufmerksamkeit!<br />
*<code>set lampe1 on ; set lampe2 on </code> → Schaltet sofort beide Lampen ein ( ein bisschen OT, weil kein at)<br />
*<code>define morgens at *7:00:00 set lampe1 on ; set lampe2 on</code> → schaltet lampe 1 immer um 7 an, aber lampe2 sofort. Der erste Befehl landet in der config (im at) der zweite Befehl wird genau wie der define Befehl einfach sofort ausgeführt. <br />
*<code>define morgens at *7:00:00 set lampe1 on ;; set lampe2 on</code> → schaltet BEIDE Lampen immer um 7 an. Beide Befehle landen in der config (im at), nur der define Befehl wird ausgeführt<br />
*<code>define morgens at *7:00:00 set lampe1,lampe2 on</code> → schaltet BEIDE Lampen immer um 7 an. Geht nur wenn der gleiche Befehl an 2 oder mehr Geräte gesendet werden soll<br />
<br />
=== Attribute ===<br />
...<br />
<br />
=== Testen ===<br />
{{Randnotiz|RNText='''Versionsspezifisch:''' Der Befehl ''execNow'' ist in FHEM 5.7/90_at.pm ab 30.4.2016 verfügbar.}}<br />
Mit dem Befehl <br />
:<code>set <devspec> execNow</code><br />
lässt sich eine ''at''-Definition (einmalig, beispielsweise zu Testzwecken) unabhängig vom Erreichen der angegebenen Zeitspezifikation ausführen.<br />
<br />
=== Ändern / Modifizieren ===<br />
<br />
Das Zeit-Attribut eines existierenden Timers sollte via <code>modifyTimeSpec</code> (Befehls-Syntax via Web-Interface ermitteln) geändert werden können.<br />
Details: [https://forum.fhem.de/index.php?topic=76227.0 modifyTimeSpec fehlerhaft!?] , [https://forum.fhem.de/index.php?topic=36326.0 defmod]<br />
<br />
== Anwendungsbeispiele ==<br />
* [[AT an einem bestimmten Wochentag ausführen|at an einem bestimmten Wochentag ausführen]]<br />
* [[AT um eine Temperaturabhängige Nachtabsenkung zu realisieren|at um eine Temperaturabhängige Nachtabsenkung zu realisieren]]<br />
* [[AT zu einem absoluten Datum ausführen|at zu einem absoluten Datum ausführen]]<br />
* [[SUNRISE_EL|at in Verbindung mit SUNRISE_EL]] <br />
<br />
== Links ==<br />
* Abfrage, ob at definiert ist: {{Link2Forum|Topic=23584|Message=841269}}</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=At&diff=36051At2021-09-24T20:10:59Z<p>AndreasMohr: modifyTimeSpec</p>
<hr />
<div>{{SEITENTITEL:at}}<br />
{{Infobox Modul<br />
|ModPurpose=Setzt einen Fhem-Befehl zu einem späteren Zeitpunkt ab.<br />
|ModType=h<br />
<!-- |ModCategory= (noch?) nicht verwendet --><br />
|ModCmdRef=at<br />
|ModTechName=90_at.pm<br />
|ModOwner=rudolfkoenig / [http://forum.fhem.de/index.php?action=profile;u=8 rudolfkoenig]<br />
}}<br />
<br />
[[at]] ist ein Erweiterungsmodul, mit dessen Hilfe FHEM-Befehle/-Aktionen zu einem späteren Zeitpunkt ausgeführt werden können. Es läßt sich sowohl einmalige Ausführung, als auch regelmäßige Wiederholung erzielen, Zeitangaben können relativ oder absolut erfolgen.<br />
<br />
== Voraussetzungen ==<br />
<!-- AUSKOMMENTIERT wegen derzeitiger Funktionsproblemen iZm codemirror {{Randnotiz|RNTyp=[g|Info|RNText=FHEM enthält für at eine eingebaute Perl-Syntax-Prüfung. Diese ist nach [http://fhem.de/commandref.html#perlSyntaxCheck Aktivierung] aber nur aktiv, wenn die [[Konfiguration]] -wie empfohlen- nicht direkt bearbeitet wird. ({{Link2Forum|Topic=51744}}) }} --><br />
Keine.<br />
<br />
== Anwendung ==<br />
=== Define ===<br />
<code>define <name> at <timespec|datespec> <command></code><br />
=== Besonderheit ===<br />
*timespec - '''nur Zeit''' im Format HH:MM:SS '''kann eine''' Perlfunktion sein. <br />
*datespec - '''Datum und Zeit''' ISO 8601 oder "number of sec since 1970" '''darf keine''' Perlfunktion sein.<br />
Siehe {{Link2Forum|Topic=91625|Message=168475}} <br />
<br />
=== Beispiele ===<br />
*<code>define MeineAktion at 02:02:00 set lamp on</code> → das nächste Mal um zwei Minuten nach 2 Uhr "lamp" einschalten<br />
*<code>define MeineAktion at *02:02:00 set lamp on</code> → jeden Tag um zwei Minuten nach 2 Uhr "lamp" einschalten<br />
*<code>define MeineAktion at {ReadingsVal("Dummy","Zeit","")} set lamp on</code> → das nächste Mal um (Perlfunktion liest Zeit aus dem Dummy) "lamp" einschalten<br />
*<code>define MeineAktion at 2016-01-25T02:02:00 set lamp on</code> → das nächste Mal am 25.01.2016 um zwei Minuten nach 2 Uhr "lamp" einschalten (ISO 8601)<br />
*<code>define MeineAktion at 1453683720 set lamp on</code> → das nächste Mal am 25.01.2016 um zwei Minuten nach 2 Uhr "lamp" einschalten (number of sec since 1970)<br />
*<code>define MeineAktion at +02:02:00 set lamp on</code> → in zwei Stunden und 2 Minuten "lamp" einschalten<br />
*<code>define MeineAktion at +*02:02:00 set lamp on</code> → alle zwei Stunden und 2 Minuten "lamp" einschalten<br />
Um datespec auch variabel mit setzen zu können gibt es einen Workaround: Perlebene, Perlfunktion und Übergabe in Variable. <br />
<br />
Beispiele für "number of seconds since 1970"<br />
<syntaxhighlight lang="perl"><br />
{my $time=time_str2num("2019-09-14 23:00:00");;fhem("define MeineAktion at $time set lamp on")}<br />
{my $time=1568494800;;fhem("define MeineAktion at $time set lamp on")}<br />
</syntaxhighlight><br />
Beispiel im ISO 8601 Format<br />
<syntaxhighlight lang="perl">{my $time="2019-09-14T23:00:00";;fhem("define MeineAktion at $time set lamp on")}</syntaxhighlight><br />
<br />
=== Mehrere Aktionen ausführen ===<br />
Die Verwendung der Semikolon erfordert immer besondere Aufmerksamkeit!<br />
*<code>set lampe1 on ; set lampe2 on </code> → Schaltet sofort beide Lampen ein ( ein bisschen OT, weil kein at)<br />
*<code>define morgens at *7:00:00 set lampe1 on ; set lampe2 on</code> → schaltet lampe 1 immer um 7 an, aber lampe2 sofort. Der erste Befehl landet in der config (im at) der zweite Befehl wird genau wie der define Befehl einfach sofort ausgeführt. <br />
*<code>define morgens at *7:00:00 set lampe1 on ;; set lampe2 on</code> → schaltet BEIDE Lampen immer um 7 an. Beide Befehle landen in der config (im at), nur der define Befehl wird ausgeführt<br />
*<code>define morgens at *7:00:00 set lampe1,lampe2 on</code> → schaltet BEIDE Lampen immer um 7 an. Geht nur wenn der gleiche Befehl an 2 oder mehr Geräte gesendet werden soll<br />
<br />
=== Attribute ===<br />
...<br />
<br />
=== Testen ===<br />
{{Randnotiz|RNText='''Versionsspezifisch:''' Der Befehl ''execNow'' ist in FHEM 5.7/90_at.pm ab 30.4.2016 verfügbar.}}<br />
Mit dem Befehl <br />
:<code>set <devspec> execNow</code><br />
lässt sich eine ''at''-Definition (einmalig, beispielsweise zu Testzwecken) unabhängig vom Erreichen der angegebenen Zeitspezifikation ausführen.<br />
<br />
=== Ändern / Modifizieren ===<br />
<br />
Das Zeit-Attribut eines existierenden Timers sollte via <code>modifyTimeSpec</code> (Befehls-Syntax via Web-Interface ermitteln) geändert werden können.<br />
Details: [https://forum.fhem.de/index.php?topic=76227.0 modifyTimeSpec fehlerhaft!?]<br />
<br />
== Anwendungsbeispiele ==<br />
* [[AT an einem bestimmten Wochentag ausführen|at an einem bestimmten Wochentag ausführen]]<br />
* [[AT um eine Temperaturabhängige Nachtabsenkung zu realisieren|at um eine Temperaturabhängige Nachtabsenkung zu realisieren]]<br />
* [[AT zu einem absoluten Datum ausführen|at zu einem absoluten Datum ausführen]]<br />
* [[SUNRISE_EL|at in Verbindung mit SUNRISE_EL]] <br />
<br />
== Links ==<br />
* Abfrage, ob at definiert ist: {{Link2Forum|Topic=23584|Message=841269}}</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=CUL&diff=36050CUL2021-09-24T19:59:02Z<p>AndreasMohr: Minor typos/corrections</p>
<hr />
<div>Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8&nbsp;bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433&nbsp;MHz sind weitere Protokolle zugänglich, z.&nbsp;B. Intertechno, viele Baumarkt-Funksteckdosen. <br />
<br />
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.<br />
<br />
Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1&nbsp;kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.<br />
<br />
Das CUL kann mittels des CULModuls von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.<br />
<br />
Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version&#160;3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}<br />
<br />
Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z.&nbsp;B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.<br />
<br />
Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.<br />
<br />
Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.<br />
<br />
Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.<br />
<br />
Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen. <br />
<br />
* Ist Empfang eingeschaltet ?<br />
*: <code> get myCUL raw C35</code> (13 = ja, z.&nbsp;b.: C35 = 0D / 13)<br />
* Auslesen der culfw Version:<br />
*: <code>get myCUL raw V</code><br />
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)<br />
*: <code>set myCUL raw l00</code><br />
* LED einschalten<br />
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen<br />
* LED soll blinken (einmal in der Sekunde)<br />
*: <code>set myCUL raw l02</code><br />
* Reboot / Reset des CUL:<br />
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=&gt; neue Firmware)<br />
* Freie CUL Sendezeit ([[1% Regel]]):<br />
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots<br />
* Freie Kapazität des FHT Buffers<br />
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a<br />
* Inhalt des FHT Buffers<br />
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes gross, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer<br />
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]<br />
*: <code> get myCUL raw T01</code> <br />
* Eingestellte Frequenz, Bandbreite etc. Ausgeben<br />
*: <code> get myCUL ccconf</code>. <br>Rückgabe z.&nbsp;B.: <br><code><nowiki>myCUL ccconf =&gt; freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code><br />
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):<br />
*:<code>set myCUL bWidth 464</code><br />
* Einstellen der Sendestärke:<br />
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.<br />
<br />
Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen<br />
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. <br />
<br />
Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z.&nbsp;B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl). <br />
<br />
'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).<br />
<br />
Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit&#160;:<br />
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt<br />
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet<br />
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet<br />
* <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet<br />
* <code>set CUL1 raw X21</code> normal Modus<br />
<br />
Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!<br />
<br />
Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.<br />
<br />
== Versionen ==<br />
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.<br />
<br />
* CUL V1 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.<br />
* CUL V2 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.<br />
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kByte EEPROM). Voll einsatzfähig.<br />
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM 32 kB Flashmemory, 1 kByte EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.<br />
<br />
Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.<br />
<br />
== Firmware {{Anker|FW}} ==<br />
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der<br />
* [http://culfw.de CUL Firmware Homepage]<br />
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.<br />
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der<br />
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]<br />
Hier kann man sich z.B. mit<br />
<syntaxhighlight lang="bash"><br />
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw<br />
</syntaxhighlight><br />
die aktuelle Version laden.<br />
<br />
Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:<br />
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.<br />
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.<br />
<br />
Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).<br />
<br />
Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.<br />
<br />
== Sendefrequenz ==<br />
Das CUL gibt es in Ausführungen für 868 und 433 MHz. <br />
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.<br />
<br />
Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.<br />
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.<br />
<br />
== Antenne ==<br />
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.<br />
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.<br />
<br />
Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik. <br />
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.<br />
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.<br />
<br />
Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne. <br />
<br />
Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene. <br />
<br />
Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.<br />
<br />
Weitere Informationen sind im Antennenthread des Forums zu finden: [https://forum.fhem.de/index.php/topic,93021.0.html Link]<br />
<br />
Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar ("Lambda") lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").<br />
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.<br />
<br />
Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser. <br />
<br />
Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.<br />
<br />
Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4&nbsp;GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.<br />
<br />
== Antennenlänge ==<br />
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch eine Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.<br />
<br />
Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:<br />
868,35 MHz (z.B. HM, FS20, FHT …)<br />
1/4 Lambda = 8,63 Zentimeter <br />
1/2 Lambda = 17,26 Zentimeter <br />
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)<br />
<br />
433,92 MHz (z.B. Intertechno …)<br />
1/4 Lambda = 17,27 Zentimeter <br />
1/2 Lambda = 34,54 Zentimeter <br />
<br />
Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:<br />
<br />
8,6 Zentimeter als 1/4 Lambda für 868,35 MHz<br />
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz<br />
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz<br />
<br />
== Bekannte Probleme ==<br />
<br />
=== RF-Tuning ===<br />
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z.&nbsp;B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern z.&nbsp;B. der FHT Raumregler zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.<br />
<br />
Bei Empfangsproblemen von z.&nbsp;B. HEM-Sensoren oder dem S300TH kann man folgendes testen:<br />
<br />
* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.<br />
*: <code>set CUL freq 868.350</code><br />
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.<br />
*: <code>set CUL sens 8</code><br />
* Oft hilft auch, die Bandbreite auf z.&nbsp;B. 464 kHz aufzuweiten.<br />
*: <code>set CUL bWidth 464</code><br />
<br />
=== Übertragungs-Stall nach zu vielen Einträgen in der Queue ===<br />
<br />
Ich habe mich ewig damit rumgeärgert, dass die Übertragung zu bestimmten häufig angesprochenen Geräten zusammenbrach, sobald die Queue zu lang wurde (FHEM: 'list CUL').<br />
Irgendwann habe ich dann zufällig herausgefunden, dass dieses sehr fragwürdige Anwachsen der Queue an einer krassen [[Sendpool]]-Fehlkonfiguration lag: ich hatte dort ein Transceiver-Device mit angegeben, welches den [[Sendpool]]-Mechanismus (noch) gar nicht unterstützt!<br />
Sobald ich dieses falsche Gerät aus der Sendpool-Element-Liste entfernt hatte, war Ruhe --> BUG im Modul (es kann nicht sein, dass ein Device ohne [[Sendpool]]-Support das Queue-Handling so zerschießt). Dieser Bug existiert allerdings wohl weiterhin (das Perl-Handling war mir etwas zu verwirrend, um direkt zu sehen, wo das Problem ist) --> sollte nachgestellt und gefixt werden.<br />
<br />
=== Harter Lockup des CUL ===<br />
<br />
Trotz behobenem (erkanntem) Queue-Problem gibt es weiterhin Probleme ("Problem #2"): es passiert - recht selten -, dass sich der nanoCUL komplett aufhängt, mit hektisch blinkender LED.<br />
Es ist in diesem Fall noch nicht einmal mit dem Reset-Taster möglich, den Stick zu resetten - es ist also tatsächlich nötig, das USB-Kabel komplett zu ziehen. Wenigstens automatisieren lassen würde sich dieser Workaround wohl per [https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux uhubctl].<br />
Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.<br />
<br />
Device-Attribute wie <code>version</code> etc. könnten evt. den Zeitpunkt der letzten Aktivität verdeutlichen; dann im FHEM-Log um diesen Zeitpunkt herum suchen, um Auffälligkeiten/Spezialitäten zu erkennen. Und dann muss man, wenn man Pech hat, eine custom culfw bauen, die entsprechendes Reporting mit eingebaut hat...<br />
<br />
(nanoCUL; V 1.26.00 a-culfw Build: 267).<br />
<br />
UPDATE: die Lösung des Problems steht evt. im Forum (Lockup beseitigt durch Optiboot bootloader): [https://forum.fhem.de/index.php/topic,73144.msg977406.html?PHPSESSID=2lj93g4vn277qhm2bfpvfpgntr#msg977406 {Gelöst} Nanocul LED blinkt schnell].<br />
[https://www.ebay.de/itm/1-3-mal-Flash-Service-fur-ZigBee-nanoCUL-JeeLink-Shelly-Sonoff-Blitzwolf-Gosund/264472055531] scheint das zu bestätigen:<br />
"Weiterhin bieten wir beim nanoCUL an, einen alternativen Bootloader (Optiboot Bootloader) zu flashen.<br />
Dieser verhindert das Abstürzen des nanoCUL's im Betrieb z.B. bei FHEM. (Stichwort: opened)"<br />
<br />
Ein weiterer Bericht über CUL-Lockups (dort reproduzierbar/deterministisch, und Regression-Bug): [https://github.com/heliflieger/a-culfw/issues/23 Selfmade Cul freezing with blinking LED when sending ITv3 messages #23]<br />
<br />
Evt. ist auch ein USB-Port-Reset ein funktionierender Workaround (bitte Text als bestätigt umformulieren, falls das hilft): [https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html], erwähnt von [https://forum.fhem.de/index.php/topic,77380.msg783352.html#msg783352].<br />
<br />
==== Ständige Lockups ====<br />
Falls Lockups gefühlt "ständig" passieren sollten (alle paar Tage, oder fast täglich insb. bei warmem Wetter), dann liegt es z.B. an einem schlechten/kaputten Kabel (bei mir: dünne USB-2-"Drachenschnur", mit Bissmarken o.ä. - durch ein gutes dickes USB-3-Kabel ersetzt und sofort dramatisch robuster).<br />
<br />
== Selbstbau-/Bastelprojekte ==<br />
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:<br />
* [[Selbstbau CUL]]<br />
* [[FHEMduino]]<br />
* [[SIGNALduino]]<br />
* [[MapleCUN]] mit STM32 Mikrocontroller<br />
<br />
== Links ==<br />
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]<br />
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im [http://forum.fhem.de/index.php FHEM Forum] ergänzt/ersetzt<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:CUL|!]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=CUL&diff=36049CUL2021-09-24T19:38:22Z<p>AndreasMohr: /* Harter Lockup des CUL */ Erwähne Ursache für sehr häufige Lockups</p>
<hr />
<div>Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8&nbsp;bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433&nbsp;MHz sind weitere Protokolle zugänglich, z.&nbsp;B. Intertechno, viele Baumarkt-Funksteckdosen. <br />
<br />
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.<br />
<br />
Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1&nbsp;kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.<br />
<br />
Das CUL kann mittels des CULModuls von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.<br />
<br />
Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version&#160;3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}<br />
<br />
Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z.&nbsp;B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.<br />
<br />
Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.<br />
<br />
Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.<br />
<br />
Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.<br />
<br />
Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen. <br />
<br />
* Ist Empfang eingeschaltet ?<br />
*: <code> get myCUL raw C35</code> (13 = ja, z.&nbsp;b.: C35 = 0D / 13)<br />
* Auslesen der culfw Version:<br />
*: <code>get myCUL raw V</code><br />
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)<br />
*: <code>set myCUL raw l00</code><br />
* LED einschalten<br />
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen<br />
* LED soll blinken (einmal in der Sekunde)<br />
*: <code>set myCUL raw l02</code><br />
* Reboot / Reset des CUL:<br />
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=&gt; neue Firmware)<br />
* Freie CUL Sendezeit ([[1% Regel]]):<br />
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots<br />
* Freie Kapazität des FHT Buffers<br />
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a<br />
* Inhalt des FHT Buffers<br />
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes gross, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer<br />
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]<br />
*: <code> get myCUL raw T01</code> <br />
* Eingestellte Frequenz, Bandbreite etc. Ausgeben<br />
*: <code> get myCUL ccconf</code>. <br>Rückgabe z.&nbsp;B.: <br><code><nowiki>myCUL ccconf =&gt; freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code><br />
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):<br />
*:<code>set myCUL bWidth 464</code><br />
* Einstellen der Sendestärke:<br />
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.<br />
<br />
Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen<br />
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. <br />
<br />
Werte x00-x04 sind '''mit''' Ramping (''sanften'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z.&nbsp;B. [[RFR CUL]], da die CULs Rampingsingnale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl). <br />
<br />
'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).<br />
<br />
Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit&#160;:<br />
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt<br />
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet<br />
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet<br />
* <code>set CUL1 raw X80</code> RSSI / Signalstaerke jeder Flanke wird gemeldet<br />
* <code>set CUL1 raw X21</code> normal Modus<br />
<br />
Achtung: Auf Gross- und Kleinschreibung des "x,X" achten!<br />
<br />
Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.<br />
<br />
== Versionen ==<br />
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.<br />
<br />
* CUL V1 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.<br />
* CUL V2 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.<br />
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kByte EEPROM). Voll einsatzfähig.<br />
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM 32 kB Flashmemory, 1 kByte EEPROM. Voll einsatzfähig. Genau genommen ein "Sparmodell" des V3, um Lieferengpässe des atmega32u4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.<br />
<br />
Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.<br />
<br />
== Firmware {{Anker|FW}} ==<br />
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der<br />
* [http://culfw.de CUL Firmware Homepage]<br />
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.<br />
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der<br />
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]<br />
Hier kann man sich z.B. mit<br />
<syntaxhighlight lang="bash"><br />
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw<br />
</syntaxhighlight><br />
die aktuelle Version laden.<br />
<br />
Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:<br />
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.<br />
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.<br />
<br />
Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).<br />
<br />
Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.<br />
<br />
== Sendefrequenz ==<br />
Das CUL gibt es in Ausführungen für 868 und 433 MHz. <br />
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.<br />
<br />
Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.<br />
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.<br />
<br />
== Antenne ==<br />
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.<br />
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.<br />
<br />
Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik. <br />
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.<br />
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.<br />
<br />
Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne. <br />
<br />
Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene. <br />
<br />
Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.<br />
<br />
Weitere Informationen sind im Antennenthread des Forums zu finden: [https://forum.fhem.de/index.php/topic,93021.0.html Link]<br />
<br />
Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar ("Lambda") lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").<br />
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.<br />
<br />
Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser. <br />
<br />
Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.<br />
<br />
Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4&nbsp;GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.<br />
<br />
== Antennenlänge ==<br />
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch eine Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.<br />
<br />
Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:<br />
868,35 MHz (z.B. HM, FS20, FHT …)<br />
1/4 Lambda = 8,63 Zentimeter <br />
1/2 Lambda = 17,26 Zentimeter <br />
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)<br />
<br />
433,92 MHz (z.B. Intertechno …)<br />
1/4 Lambda = 17,27 Zentimeter <br />
1/2 Lambda = 34,54 Zentimeter <br />
<br />
Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:<br />
<br />
8,6 Zentimeter als 1/4 Lambda für 868,35 MHz<br />
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz<br />
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz<br />
<br />
== Bekannte Probleme ==<br />
<br />
=== RF-Tuning ===<br />
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z.&nbsp;B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern z.&nbsp;B. der FHT Raumregler zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.<br />
<br />
Bei Empfangsproblemen von z.&nbsp;B. HEM-Sensoren oder dem S300TH kann man folgendes testen:<br />
<br />
* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.<br />
*: <code>set CUL freq 868.350</code><br />
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.<br />
*: <code>set CUL sens 8</code><br />
* Oft hilft auch, die Bandbreite auf z.&nbsp;B. 464 kHz aufzuweiten.<br />
*: <code>set CUL bWidth 464</code><br />
<br />
=== Übertragungs-Stall nach zu vielen Einträgen in der Queue ===<br />
<br />
Ich habe mich ewig damit rumgeärgert, dass die Übertragung zu bestimmten häufig angesprochenen Geräten zusammenbrach, sobald die Queue zu lang wurde (FHEM: 'list CUL').<br />
Irgendwann habe ich dann zufällig herausgefunden, dass dieses sehr fragwürdige Anwachsen der Queue an einer krassen [[Sendpool]]-Fehlkonfiguration lag: ich hatte dort ein Transceiver-Device mit angegeben, welches den [[Sendpool]]-Mechanismus (noch) gar nicht unterstützt!<br />
Sobald ich dieses falsche Gerät aus der Sendpool-Element-Liste entfernt hatte, war Ruhe --> BUG im Modul (es kann nicht sein, dass ein Device ohne [[Sendpool]]-Support das Queue-Handling so zerschießt). Dieser Bug existiert allerdings wohl weiterhin (das Perl-Handling war mir etwas zu verwirrend, um direkt zu sehen, wo das Problem ist) --> sollte nachgestellt und gefixt werden.<br />
<br />
=== Harter Lockup des CUL ===<br />
<br />
Trotz behobenem (erkanntem) Queue-Problem gibt es weiterhin Probleme ("Problem #2"): es passiert - recht selten -, dass sich der nanoCUL komplett aufhängt, mit hektisch blinkender LED.<br />
Es ist in diesem Fall noch nicht einmal mit dem Reset-Taster möglich, den Stick zu resetten - es ist also tatsächlich nötig, das USB-Kabel komplett zu ziehen. Wenigstens automatisieren lassen würde sich dieser Workaround wohl per uhubctl ([https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux]).<br />
Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.<br />
<br />
Device-Attribute wie version etc. könnten evt. den Zeitpunkt der letzten Aktivität verdeutlichen; dann im FHEM-Log um diesen Zeitpunkt herum suchen, um Auffälligkeiten/Spezialitäten zu erkennen. Und dann muss man, wenn man Pech hat, eine custom culfw bauen, die entsprechendes Reporting mit eingebaut hat...<br />
<br />
(nanoCUL; V 1.26.00 a-culfw Build: 267).<br />
<br />
UPDATE: die Lösung des Problems steht evt. im Forum (Lockup beseitigt durch Optiboot bootloader): [https://forum.fhem.de/index.php/topic,73144.msg977406.html?PHPSESSID=2lj93g4vn277qhm2bfpvfpgntr#msg977406 {Gelöst} Nanocul LED blinkt schnell].<br />
[https://www.ebay.de/itm/1-3-mal-Flash-Service-fur-ZigBee-nanoCUL-JeeLink-Shelly-Sonoff-Blitzwolf-Gosund/264472055531] scheint das zu bestätigen:<br />
"Weiterhin bieten wir beim nanoCUL an, einen alternativen Bootloader (Optiboot Bootloader) zu flashen.<br />
Dieser verhindert das Abstürzen des nanoCUL's im Betrieb z.B. bei FHEM. (Stichwort: opened)"<br />
<br />
Ein weiterer Bericht über CUL-Lockups (dort reproduzierbar/deterministisch, und Regression-Bug): [https://github.com/heliflieger/a-culfw/issues/23 Selfmade Cul freezing with blinking LED when sending ITv3 messages #23]<br />
<br />
Evt. ist auch ein USB-Port-Reset ein funktionierender Workaround (bitte Text als bestätigt umformulieren, falls das hilft): [https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html], erwähnt von [https://forum.fhem.de/index.php/topic,77380.msg783352.html#msg783352].<br />
<br />
==== Ständige Lockups ====<br />
Falls Lockups gefühlt "ständig" passieren sollten (alle paar Tage, oder fast täglich insb. bei warmem Wetter), dann liegt es z.B. an einem schlechten/kaputten Kabel (bei mir: dünne USB-2-"Drachenschnur", mit Bissmarken o.ä. - durch ein gutes dickes USB-3-Kabel ersetzt und sofort dramatisch robuster).<br />
<br />
== Selbstbau-/Bastelprojekte ==<br />
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:<br />
* [[Selbstbau CUL]]<br />
* [[FHEMduino]]<br />
* [[SIGNALduino]]<br />
* [[MapleCUN]] mit STM32 Mikrocontroller<br />
<br />
== Links ==<br />
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]<br />
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im [http://forum.fhem.de/index.php FHEM Forum] ergänzt/ersetzt<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:CUL|!]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=SIGNALduino&diff=35977SIGNALduino2021-08-25T23:54:00Z<p>AndreasMohr: Cleanup</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Empfang und Verarbeitung von digitalen Signalen<br />
|ModType=d<br />
|ModFTopic=38402<br />
|ModCmdRef=SIGNALduino<br />
|ModForumArea=Sonstige Systeme<br />
|ModTechName=00_SIGNALduino.pm<br />
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])<br />
}}<br />
<br />
== Einleitung ==<br />
=== Übersicht ===<br />
Unter den Namen SIGNALduino versteht man sowohl den Low-Cost Empfänger für digitale Signale (vergleichbar dem [[CUL]]) als auch das gleichnamige Modul mit dem Dateinamen 00_SIGNALduino.pm. Mit dem SIGNALduino kann man entweder 433 oder 868 MHz-Geräte auslesen und ansprechen. Der SIGNALduino funktioniert auch mit anderen Medien wie Infrarot oder direkter Kabelverbindung.<br />
<br />
Der SIGNALduino(-Stick) erkennt Signale anhand von Mustern und gibt sie (als maximal detaillierte Beschreibung einer Signalabfolge) dann schlicht sofort nur noch an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben.<br />
Aufgabe des SIGNALduino (Firmware/Stick) ist es also nur, Signal-Aktivitäten zu erfassen und maximal präzise (als kurzer Text-String) zu beschreiben.<br />
Alles weitere (echte, finale Auswertung / Zuweisung dieser Signal-Daten) wird dann auf einer großen Box (z.B. Raspberry) gemacht.<br />
<br />
=== Vorteil gegenüber einem CUL/FHEMduino ===<br />
Der SIGNALduino hat den Vorteil einer sehr schnellen Demodulation des Funksignals. Sollen weitere Protokolle dekodiert werden, so muss dazu nur ein passendes FHEM Modul entwickelt oder ein universelles Modul erweitert werden (also auf flexibel direkt änderbarer/updatebarer Rechner-Seite!!). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung auf Stick-Firmware-Seite korrekt funktioniert - leider nicht immer, z.B.: [https://github.com/RFD-FHEM/SIGNALDuino/issues/65 MU-Nachrichten werden z.T. als MC erkannt]).<br />
<br />
Ein großer Vorteil des SIGNALduino besteht darin, dass auch Geräte mit leicht abweichenden Frequenzen steuerbar sind; so empfangen die ''Somfy''-Rolladenmotoren beispielsweise auf 433.42 MHz und nicht, wie bei anderen Geräten sehr oft üblich, auf 433.92 MHz. Die Frequenzumstellung stellt für den SIGNALduino kein Problem dar.<br />
<br />
Ebenso kann man den SIGNALduino direkt an den Sendeausgang eines Sensors anbinden und die digitalen Signale empfangen, dabei bitte aber auf die passenden Spannungen achten, denn ein Arduino Nano verträgt nur 5V.<br />
<br />
<br />
=== Entwicklungsversion ===<br />
Der SIGNALduino wird derzeit aktiv weiterentwickelt, siehe dazu https://github.com/RFD-FHEM. Die offizielle Version wird {{Link2Forum|Topic=58396|LinkText=hier}} genauer beschrieben. Es existieren im Forum diverse angepasste Versionen, auf die hier nicht näher eingegangen wird.<br />
<br />
== Hardware ==<br />
=== Controller ===<br />
Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden. Bei Einbindung via ESP muss man beachten, dass der ESP nach 5 Minuten Inaktivität seine TCP-Verbindung unterbricht (siehe [[ESP8266#Bekannte_Probleme|diesen Hinweis]]). Zu diesem Zweck gibt es einen Signalduino-eigenen Ping-Befehl ('get signalduino ping'), der diese Aktivität wieder aufbaut. Ping-Befehle sind auch auf Betriebssystemebene bekannt - allerdings beachte man, dass der ping-Befehl auf Betriebssystemebene ICMP verwendet, zum "Aufwachen" des ESP aber auf TCP-Ebene aktiviert werden muss (zum Unterschied siehe [https://www.tippscout.de/internet-was-sind-tcp-ip-udp-und-icmp_tipp_2268.html hier]) und man daher besser den Signalduino-eigenen Befehl und nicht das Betriebssystem verwendet.<br />
<br />
Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht dem [[Selbstbau_CUL]] (eine frühere Version ist der nicht mehr weiterentwickelte [[FHEMduino]]):<br />
* Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum [[FHEMduino]] <br />
* Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum [[Selbstbau_CUL]]. Dieser Aufbau wird derzeit empfohlen.<br />
* Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, Link zum [http://shop.in-circuit.de/index.php Hersteller]. <br />
<br />
Achten Sie beim Selbstbau auf die entsprechenden Sender-Empfänger. Der sehr preiswert angebotene XY-MK-5V hat sich als zu unzuverlässig erwiesen, während anscheinend beim CC1101 (insbesondere der "grünen Version") keine Probleme auftreten. <br />
<br />
Es stehen auch für den [https://www.arduino.cc/en/Main/arduinoBoardUno UNO] und [https://www.arduino.cc/en/Main/ArduinoBoardProMini PRO Mini] Firmware-Dateien zur Verfügung. Die ausgelieferte Firmware läuft nur auf Mikrocontrollern mit 16 MHz; wer einen Mikrocontroller mit 8 MHz verwenden möchte, muss die Firmware selbst compilieren. Die SW ist auf [https://github.com/RFD-FHEM/SIGNALDuino github]. Vorgesehen ist momentan (für ordentlich breiten Support müsste man wohl eine CMake-Build-Config hinzufügen - ich sollte hier mal in die Pötte kommen...) nur die Übersetzung unter Windows mit Visual Studio und dem Visual Micro Zusatz. Es gibt aber auch eine Anleitung, wie man mit der [[Arduino]] IDE oder einem Makefile [[SIGNALduino Compilieren]] kann.<br />
<br />
Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] nativ läuft, diese funktioniert seit Anfang 2018 annehmbar, allerdings befindet diese sich noch in einer Entwicklungsphase.<br />
<br />
An den "SIGNALESP" kann auch ein CC1101 via SPI angebunden werden:<br />
<br />
{| |<br />
!CC1101 Bezeichnung<br />
!ESP Pin<br />
|-<br />
|CLK||GPIO14<br />
|-<br />
|MOSI||GPIO13<br />
|-<br />
|MISO||GPIO12<br />
|-<br />
|CSN||GPIO15<br />
|-<br />
|GDO0||GPIO4<br />
|-<br />
|GDO2||GPIO5<br />
|}<br />
<br />
Wird eine einfache Empfänger / Sender Kombination verwendet, dann über die Pins:<br />
<br />
{| |<br />
! Bezeichnung <br />
! ESP Pin<br />
|-<br />
|Transmitter||GPIO4<br />
|-<br />
|Receiver||GPIO5<br />
|}<br />
<br />
=== Sendemodule ===<br />
{{Randnotiz|RNTyp=r|RNText=Viele user berichten über Empfangsprobleme bei Nutzung des XY-MK-5V; es wird ausdrücklich empfohlen, ein anderes Empfangsmodul zu nutzen!}}<br />
[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]] <br />
<br />
Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:<br />
* FS1000A Dies ist das Sendemodul (TX) - es wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€). <br />
* RXB6 Das ist das empfohlene Empfangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.<br />
<br />
Die Verkabelung erfolgt analog zum [[FHEMduino]] und das bedeutet (Arduino -> Modul):<br />
* PIN D2 an DATA des RX-Moduls<br />
* PIN D11 an DATA des TX-Moduls (PIN links mit Beschriftung ATAD)<br />
<br />
Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.<br />
<br />
Jetzt fehlen noch die Antennen. Dafür braucht man ein 17,2 cm langes Stück Kupferdraht, das wird beim Anschluss "ANT" jeweils am Modul angelötet (anfängergeeignet).<br />
<br />
== Software ==<br />
<br />
=== USB-ID ermitteln ===<br />
Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) verbunden werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl<br />
<pre> ls -l /dev/serial/by-id </pre><br />
ausführen. Beispielhaft sieht das Ergebnis etwa so aus:<br />
<br />
''lrwxrwxrwx 1 root root 13 Jan 31 00:02 '''usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port''' -> ../../ttyUSB0''<br />
<br />
Damit ist der Anschluss des SIGNALduino bestimmt und das Gerät kann wie im nächsten Abschnitt beschrieben definiert werden. Zuvor muss noch das Modul geladen werden.<br />
<br />
=== FHEM-Modul laden ===<br />
Die SIGNALduino Module werden über das FHEM [[update]] verteilt, sobald die Änderungen einen "stabilen" und alltagstauglichen Zustand haben. Aktuell wird dort die Version 3.4.2 seit 08.04.2020 verteilt.<br />
<br />
Die in der Entwicklung befindliche Version (3.5.x, bringt z.B. Unterstützung für Geräte mit FSK-Modulation) kann mit folgenden Befehlen geladen werden:<br />
<br />
* FHEM aktualisieren: <code>update</code> <br />
* SIGNALduino Modul aktualisieren: <code>update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master<nowiki/>/controls_signalduino.txt</code> Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet.<br />
* Es empfiehlt sich, die Github-Quelle dauerhaft einzutragen: <code>update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt</code>, um weitere Entwicklungs-Updates zu bekommen, und damit das nächste Standard-<code>update</code> nicht die alte Version wieder einspielt.<br />
<br />
Das Gerät kann wie folgt definiert werden (die Spezifikation des USB-Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):<br />
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code><br />
* Solltet Ihr einen SIGNALESP via IP einbinden wollen, ist die Syntax (ebenso wird auch vorgegangen wenn der SIGNALduino beispielsweise über ser2net freigeben wird):<br />
:<code>define <eigener-SIGNALESP-Name> SIGNALduino <ip-adresse>:23</code><br />
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt. Die Baudrate beim SIGNALduino beträgt 57600 - via telnet muss dann dieselbe Baudrate eingestellt werden. <br />
<br />
Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.<br />
<br />
==== Flashen des Arduino mit der SIGNALduino Firmware ====<br />
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:<br />
:<code>sudo apt-get install avrdude</code><br />
<br />
In FHEM ist der SIGNALduino mit dem Status "Open" vorhanden. Jetzt müssen wir FHEM noch mitteilen, welche Hardware wir angeschlossen haben. Über das Attribut ''hardware'' lässt sich zwischen den mitgelieferten Firmware-Dateien wechseln. Solltet ihr einen Nano mit cc1101 Transceiver verwenden, so wählt bitte folgende Hardware<br />
:<code>attr sduino hardware nanoCC1101</code><br />
sonst üblicherweise<br />
:<code>attr sduino hardware nano328</code><br />
<br />
Dann muss mitgeteilt werden, welche Version man geladen haben will: stable oder testing. <br />
:<code>attr sduino updateChannelFW testing</code><br />
Nun wird die entsprechende Firmware heruntergeladen. Dies geschieht durch den Befehl<br />
:<code>get sduino availableFirmware</code><br />
Anschließend kann der ''flash'' Befehl abgesetzt werden: <br />
:<code>set sduino flash <und-dann-auswaehlen></code><br />
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.<br />
<br />
Alternativ kann auch der Flash-Befehl mit einem Dateinamen aufgerufen werden. Diese Möglichkeit sollte jedoch nur verwendet werden, wenn die SIGNALduino Firmware selbst compiliert wurde und eine andere Hardware verwendet wird. Der Flash-Befehl wird wie folgt aufgerufen:<br />
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code><br />
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)<br />
<br />
Wenn ein miniCUL geflasht werden soll, sind einige Besonderheiten zu beachten. Details dazu in {{Link2Forum|Topic=114413|LinkText=diesem Forenthema}}.<br />
<br />
==== Flashen einer Firmware über HTTP ====<br />
Die Firmware wird nicht mehr über den FHEM Update Mechanismus verteilt. <br />
Damit die passende Firmware auf den SIGNALduino geladen werden kann, wird diese dann über HTTP aus den Github Releases geladen.<br />
<br />
==== Vorabversion einer Firmware ====<br />
Die Firmware des SIGNALduino wird ebenso wie das FHEM Modul auch weiter entwickelt.<br />
Die Entwickler sind auf Tests und Rückmeldungen der Nutzer angewiesen, da leider nicht alle Sensoren vorher getestet werden können.<br />
<br />
Die Version 3.4 ist die aktuell stabile Version.<br />
<br />
Für die folgenden Microcontroller kann man die Firmware seit 21.02.2019 auch direkt downloaden und teilweise flashen. <br />
Dazu muss das Attribut <code>hardware</code> auf einen gültigen Wert angepasst werden!<br />
Über den GET Befehl <code>availableFirmware</code> werden dann für die hinterlegte Hardware die passenden Versionen gesucht. Über das Attribut <code>updateChannelFW</code> kann zwischen "stable" und "testing" definiert werden, welche Art von Firmware angeboten werden soll.<br />
<br />
Nachdem die Firmwareversion erfragt wurde, bietet der set flash Befehl eine Auswahlliste an. Wird ein Flash Befehl mit einer der Versionen ausgewählt, wird diese Version zunächst heruntergeladen und bei den AVR Versionen auch versucht diese mittels avrdude zu flashen.<br />
Die Firmware für den ESP8266 kann aktuell leider noch nicht über diesen Befehl aktualisiert werden.<br />
<br />
Alternativ funktioniert aber auch die Option, dem Flash Befehl eine URL zu übergeben. Dann wird die Datei aus der URL heruntergeladen und auch versucht diese zu Flashen. z.B.<br />
SIGNALDuino_nanocc1101.hex für einen Nano mit CC1101<br />
<br />
<code>set sduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_radinocc11013.3.1.hex<br />
<br />
oder<br />
SIGNALESP_.hex (mit cc1101) für einen ESP8266 <br />
<code>set ipduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_ESP8266cc11013.3.1.hex<br />
<br />
!Achtung, aktuell wird die Firmware für den ESP dadurch nur herunter geladen. Flashen müsst ihr leider immer noch über ein passendes Tool <br />
z.B. [https://github.com/nodemcu/nodemcu-flasher ESP8266Flasher.exe] oder Esptool und einer seriellen Konsole.<br />
Auch ist zu beachten, es handelt sich hierbei tatsächlich um ein Binary und nicht um ein Hex File. <br />
<br />
Nach dem Booten des ESPs spannt dieser ein eigenes WLAN auf. Habt ihr euch damit verbunden, könnt ihr den ESP mit eurem vorhandenen WLAN nach Eingabe der Daten verbinden.<br />
<br />
Die Hauptseite für Firmware-Releases findet sich unter https://github.com/RFD-FHEM/SIGNALDuino/releases/ .<br />
Dort kann auch eine Änderungshistorie eingesehen werden.<br />
==== Flashen eines radino Boards mit ATmega32U4 ====<br />
<br />
Diese Funktion steht seit 21.02.2019 nun auch in der via FHEM aktualisierten Version zur Verfügung:<br />
<br />
Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird.<br />
Weiterhin ist zu beachten, dass der Bootloader eine andere USB ID bekommt und diese im Attribut <code>flashCommand</code> hinterlegt werden muss.<br />
<br />
==== Fehler beim Flashen ====<br />
Sollte bei einem Flash Vorgang ein Fehler auftreten, solltet ihr zunächst im Logfile mit Verbose 5 nachsehen.<br />
<br />
Findet ihr dort keine Fehlermeldung, gibt es noch ein separates Flashlog, welches ihr über einen Browser aufrufen könnt. Dazu müsst ihr nur den folgenden Pfad an euren Servernamen anhängen:<br />
<code><br />
/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=SIGNALduino-Flash.log<br />
</code><br />
<br />
=== Geräteerkennung ===<br />
==== Unterstützte Geräte ====<br />
Für die folgenden Geräte gibt es derzeit (2017) eine Unterstützung für den Betrieb mit FHEM. Die Geräte werden [[autocreate|automatisch erkannt]] und in der Konfiguration eingetragen, wenn der SIGNALduino läuft.<br />
Bitte Geräte mit sehr präzisen Referenzen hier listen (Produktnummer, Protokoll-Variantenname etc.), damit eine globale Suche/Verifikation maximal erfolgreich ist. In der detaillierten Liste [[Geprüfte_Geräte]] lassen sich die Geräte näher identifizieren.<br />
{| class="wikitable"<br />
! style="text-align:left;" | Produkt <br />
! (E)mpfangen<br />(S)enden <br />
! Hinweise <br />
! Verwendetes Modul <br />
! Protokoll ID<br />
|-<br />
|Conrad Wetterstation KW9110||E S||Sensor: KW9010, neben Temperatur u. Luftfeuchte werden auch Trend, Batterie u. Kanal erfasst|| CUL_TCM97001 || 0.3<br />
|-<br />
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0 <br />
|-<br />
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17<br />
|-<br />
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL || <br />
|-<br />
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10<br />
|-<br />
|Bresser Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12<br />
|-<br />
|TFA Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8<br />
|-<br />
|TFA 30320902||E || || SD_WS07 || 7<br />
|-<br />
|Eurochron eas800z||E || || SD_WS07 || 7<br />
|-<br />
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7<br />
|-<br />
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7<br />
|-<br />
|CTW600||E || || SD_WS09 || 9<br />
|-<br />
|CTW602||E ||neuere Version des CTW600 mit 868.35 MHz || SD_WS09 || 9<br />
|-<br />
|WH1080||E || || SD_WS09 || 9<br />
|-<br />
|Visivon remote pt4450||E || || none || 24<br />
|-<br />
|Einhell HS 434/6||E || || none || 21<br />
|-<br />
|Flamingo FA20RF / FA21RF / FA22RF Rauchmelder||E || || FLAMINGO || 13,13.1,13.2<br />
|-<br />
|mumbi m-FS300||E || || none || 26,27<br />
|-<br />
|TFA 30.3200||E || || none || 33<br />
|-<br />
|Livolo||E|| || none || 20<br />
|-<br />
|Smartwares RM174RF/2 (RM174RF-001CPR) 4500177571 ||E [S?]|| IT EV1527; TODO herausfinden: Alarmierung (wie Alarmton getriggered werden kann); Batterieinfo? || IT || 3<br />
|-<br />
|Smartwares SH5-TSO-A||E S|| || IT || ?<br />
|-<br />
|X10 Security Devices||E|| || || 39<br />
|-<br />
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43<br />
|}<br />
Bei einigen ''Intertechno''-Funksteckdosen (''Brennenstuhl'') kann es zu Empfangsproblemen kommen. Hier muss die Taktrate, mit der gesendet wird, angepasst werden. Dazu muss für ''Funksteckdose'' (also sauber per-Client-Instanz-spezifisch, NICHT SIGNALduino-Transceiver-global) das Attribut <br />
:<code>attr <Funksteckdose> ITclock 300</code> <br />
gesetzt werden, der Standardwert ist 250.<br />
<br />
==== Mein Gerät wird in FHEM nicht erkannt ====<br />
1. Prüfen, ob vom Sensor die Signaldaten (<code>verbose</code> >=4) erkannt werden. Sobald ihr die empfangenen Signaldaten im Logfile zuordnen könnt, geht es weiter mit:<br />
<br />
2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues/new?template=sensor---device-feature.md github]:<br />
<!-- <syntaxhighlight lang="md"> ... markdown lexer not yet available; use pre instead --><br />
<pre><br />
## Specifications for new sensor / switch / or other device ... <br />
<br />
- manufacturer:<br />
- model name:<br />
- pictures of the device / the board (very helpful)<br />
<br />
<br />
## Specifications <br />
<br />
- Microcontroller:<br />
- Version (Firmware):<br />
<br />
<!-- ( can be found here devicename -> Internals -> version ) --><br />
- Versionmodul (FHEM Module):<br />
</pre><br />
<br />
3. Auszug aus dem Logfile, welches zum Gerät gehört.<br />
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.''<br />
<br />
Im Forum solltet ihr solche Fragen besser nicht posten, wenn das Gerät noch nicht unterstützt wird, dazu ist Github besser geeignet. Inzwischen wurde im Wiki eine eigene Seite eröffnet, die sich mit der Erkennung unbekannter Protokolle beschäftigt: [[Unbekannte_Funkprotokolle#Ansatz_1_-_Versuchen|Unbekannte_Funkprotokolle]].<br />
<br />
==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ====<br />
Im SIGNALduino sind >70 Protokolle implementiert. Jedoch gibt es nicht immer ein logisches Modul, welches diese Protokolle verarbeitet.<br />
Teilweise ist das auch nicht zwingend notwendig, um seine Anforderungen zu erfüllen. Insbesondere für Schalter bzw. Sensoren, die nur zwei Zustände kennen, geht es meist auch kurz und knapp manuell (also ohne Modul und automatisch angelegtem Gerät).<br />
<br />
Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden.<br />
Im FHEM Log (und, insbesondere, im FHEMWEB Event Monitor) tauchen Meldungen ähnlich dieser auf<br />
<br />
<code><br />
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081<br />
</code><br />
<br />
Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:<br />
<br />
Entweder, wenn wir den Inhalt der Nachricht nur zu Teilen wissen, da er sich ändert:<br />
<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)<br />
attr mydoif do always<br />
</code><br />
<br />
Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring<br />
<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on)<br />
attr mydoif do always<br />
</code><br />
<br />
Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.<br />
<br />
Als Alternative zu DOIF hier ein regex-verwendendes [[Notify]]-Beispiel für einen Sender, der meint, zwei Codes alternierend senden zu müssen:<br />
<br />
<code><br />
define n_sender_trigger notify sduino:UNKNOWNCODE.*u41#(13B72253|163873B3) { my_sender_trigger_indicate();; }<br />
</code><br />
<br />
Selbstverständlich muss in diesem Moment auch eine <code>sub my_sender_trigger_indicate()</code> definiert werden (z.B. in <code>FHEM/99_myUtils.pm</code>), die dort z.B. als Test eine Log-Ausgabe (<code>Log3()</code>) machen kann.<br />
<br />
=== Das Logfile ===<br />
Im Logfile ab [[Verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (<code>verbose</code> 3 unterdrückt diese Meldungen).<br />
<br />
UPDATE: der folgende Bereich ist von einem weniger erfahrenen Zeitgenossen früher nach Kräften erweitert/geschrieben worden. Mittlerweile existiert aber ein neuer Inhalt [[Unbekannte_Funkprotokolle]] (siehe auch Erwähnung weiter oben), der als sehr gut beschrieben und unvergleichlich detailreicher bezeichnet werden muss ("endlich gibt es sowas!"). Der Bereich hier dürfte somit zwar für grundlegende Verdeutlichungen noch recht sinnvoll sein, der Inhalt sollte allerdings evt. in eine konsistente Dokumentation überarbeitet (verlagert/dedupliziert/reduziert) werden.<br />
<br />
Die Protokolle (von der SIGNALDuino-Firmware gesendete Signal-Beschreibungs-Strings) können wie folgt unterschieden werden:<br />
<br />
*MS - Nachricht mit Sync Puls: Hierzu ein Beispiel<br />
:<code>MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;</code> P0-P6 sind die Signalpegel (Dauer und positiv/negativ). Hinter D= befindet sich die Abfolge der Signale. Die ersten beiden Ziffern 15 in D sind wie folgt zu lesen. Zuerst wurde ein Signal "1" also P1 mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal "5" also P5 mit 8916 Mikrosekunden low (die Zeitdauer ergibt sich aufgrund der Mitteilung "P5=-8916") gemessen. CP=1 ist die Referenz auf den Takt des Signales - der Basistakt ist in diesem Fall ~395 Mikrosekunden. SP=5 gibt die Referenz zum Syncpuls an, der das gesamte Signal einleitet. Welche Signalfolge nun eine binäre 1 bzw. 0 bedeutet, wird im SIGNALduino über die integrierte Protokoll Liste realisiert.<br />
<br />
*MC - Nachricht vom Typ Manchester: Manchesterkodierte Signale können bereits sehr einfach im Arduino in eine Binärform umgewandelt werden. Es wird hier nach IEEE 802.3 umgewandelt. In Manchester Signalen gibt es lange und kurze Pulse. Deren Durchschnittswert wird mit LL (long low), LH (long high), SL (short low) und SH (short high) übermittelt. Zusätzlich, um das Protokoll schneller erkennen zu können, wird die Taktfrequenz mit übermittelt (C=429 Mikrosekunden). Die Daten befinden sich hinter D= und werden in HEX Form übergeben.<br />
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code><br />
<br />
*MU - Message unsynced: Diese Art von Nachrichten sind nicht nach Manchester codiert und haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht. Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist. Wie bei MS sind P0-P6 die Signalpegel und in D= wird die Abfolge der Signalpegel referenziert. CP=2 gibt auch hier die Referenz zum Takt an, allerdings muss dieser nicht korrekt erkannt worden sein.<br />
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code><br />
<br />
Es erscheinen viele Meldungen dieser Art:<br />
<br />
<pre><br />
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate<br />
</pre><br />
<br />
Dies sind nun Bemühungen, anhand der von der SIGNALDuino-Firmware gelieferten rohen aber detaillierten Signal-Strings eine Vor-Analyse / Fingerprinting vorzunehmen.<br />
Man könnte nun z.B. bei solchen Fingerprinting-Analysen erkennen:<br />
* dass der Basis-Takt-Wert innerhalb eines charakteristischen Zeit-Bereichs liegt<br />
* dass die Anzahl der Sync-Pulse eine präzise Zahl ist<br />
* dass Längen erkannter Puls-Typen innerhalb eines Bereichs liegen<br />
<br />
Mittels solcher Untersuchungen kann man also final hoffentlich hinreichend plausibel feststellen, "dass diese Aktivitäten offensichtlich(?) zu einer Funk-Komponente Rauchmelder von Hersteller XYZ gehören müssen, und man somit weiterleiten muss an ein (möglicherweise bereits existierendes) Userdaten-Dekodier-Modul für diese Herstellerkomponente".<br />
<br />
<br />
Bei einer dann erfolgenden Demodulation des noch rohen SIGNALDuino-Strings könnte man z.B. (hoffentlich richtigerweise) annehmen, dass eine Signalpegel-Typ-Folge "13" eine binäre 1 bedeuten soll, während eine Folge "12" eine binäre 0 bedeuten soll. Man erhält aus dem Gesamt-Puls-String also nach vollständiger Demodulation eine Abfolge von vielen 0/1 Bits, die insgesamt ein Datenwort darstellen, mit einer gewissen Länge von NN bits (diese Längen-Angabe könnte übrigens - neben Namenssuche nach Hersteller oder Produkt etc. - ein wichtiges Internet-Such-Merkmal sein, ob andere Frameworks tatsächlich bereits wissen, wie Daten dieser Funk-Komponente zu dekodieren sind!). Dieses demodulierte Datenwort ist nun das finale Datenwort, welches einen Container für die Funk-Komponenten-Informationen darstellt (in diesem Container also beispielsweise folgende Bits-Bereiche enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Daten-Container erst einmal CRC- oder Crypto-verschlüsselt ist...).<br />
<br />
Man muss an dieser Stelle unbedingt sagen, dass dieses Userdaten-Datenwort (einer bestimmten Hersteller-Funk-Komponente!) natürlich bei ''jeglichen'' Transceiver-Systemen ''immer'' gleich (identisch) erkannt werden ''muss'' - an dieser Stelle ist also ganz klar, dass diese Daten an ''allgemeine'' FHEM-Module weitergeleitet (Dispatched) werden müssen, die nach Übernahme von Daten von ''jeglichen'' Transceiver-Systemen diese Daten immer auf die gleiche Weise ('''''generisch/zentral''''') für die jeweilige Hersteller-Funk-Komponente erledigen.<br />
<br />
'''Die Abfolge ist also ganz klar:'''<br />
Funk-Aktivität --> Transceiver-Gerät/Firmware (SIGNALDuino) --> maximal detailreich beschreibender Rx-Analyse-Output-String --> Fingerprinting-Grobzuordnung des (SIGNALDuino-Firmware-)Outputs (durch 00_SIGNALduino.pm) auf gerätespezifisches Verhalten --> ''generische/zentrale'' Dekodierung des gerätespezifischen Protokoll-Datenworts, in zentralen Grundsatz-Modulen wie z.B. <code>14_SD_WS.pm</code>).<br />
<br />
Und wenn dann bei einer solchen Schritte-Abfolge irgendetwas noch fehlen/unpassend sein sollte, dann muss eben entsprechendes Development an gewissen Stellen erfolgen ;-)<br />
<br />
====Minimieren (whitelist/blacklist) von unerwünschter Kommunikations-Aktivität/Einträgen====<br />
<br />
"Unknown Code" bedeutet, dass der SIGNALduino Signaldaten empfangen und diese binär interpretiert hat. Diese Meldung soll uns nun aber mitteilen, dass es dann nicht weiter verarbeitet werden kann, da kein Modul existiert (oder kein Weiterleitungs-Dispatch zu einem bereits existierenden), welches diese Daten jetzt in ihre Bedeutung umwandeln kann. <br />
:<code>sduino: Unknown code u1FFFFF0, help me!</code><br />
<br />
Außerdem kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:<br />
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code><br />
<br />
Mittlerweile sind über 50 Protokolle für den SIGNALduino definiert. Dadurch kommt es vor, dass sich ein Signal mit mehr als einem Protokoll demodulieren lässt. Meist führt dies dann zu zusätzlichen "Unknown code"-Einträgen.<br />
<br />
Derartige Einträge können mit dem Attribut <code>WhitelistID</code> minimiert werden. Dabei werden die Geräte, die nach Daten-Empfang tatsächlich verarbeitet werden sollen (also welche Protokolle vom FHEM Modul berücksichtigt werden), mit ihrer Protokollnummer in die <code>WhitelistID</code> aufgenommen.<br />
Für Protokolle, die nicht berücksichtigt werden, gibt es weder Logeinträge noch Events. Diese werden im Programmablauf nicht berücksichtigt. Das spart zum einen Ressourcen und trägt auch zur Übersichtlichkeit bei. <br />
Die Protokollnummer kann Tabelle [[#Unterst.C3.BCtzte_Ger.C3.A4te|Unterstützte Geräte]] entnommen werden (hilfreich ist es auch, wenn in den verwendeten Geräten im Internal <gerätename>_DMSG nachgesehen wird). So bedeutet beispielsweise ein Eintrag der Form <code>W50#FF553335FFBC</code> dass dann das Protokoll #50 in die Whitelist aufzunehmen wäre (<code>attr sduino whitelist_IDs 50</code>).<br />
{{Randnotiz|RNTyp=r|RNText=Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!!<br />
}}<br />
Die Angabe erfolgt durch Komma getrennt: z.B.:<br />
:<code>1,2,5,10</code><br />
<br />
=== Senden mit dem SIGNALduino ===<br />
Der SIGNALduino kann etwas "raw senden", indem ihm das Signal so übermittelt wird, wie er es moduliert. Hierzu muss der Befehl wie folgt eingegeben werden:<br />
<br />
<code><br />
set sduino sendMsg P3#00111010#R4<br />
</code><br />
<br />
Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.<br />
Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits.<br />
<code><br />
sduino: extracted data 00111010 (bin)<br />
sduino: Found Protocol id 3 <br />
</code><br />
<br />
Alternativ kann das Signal auch in einer "Rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig:<br />
<code><br />
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;<br />
</code><br />
<br />
R=3 bedeutet, das Signal wird 3x gesendet.<br />
Die Übertragung besteht aus den in D angegebenen Pulsen, welche in P0-P5 definiert werden.<br />
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.<br />
<br />
Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.<br />
<br />
====Fehlersuche====<br />
(Zielgerät reagiert nicht, etc.)<br />
<br />
* Nachrichtenwiederholungsanzahl muss evt. für manche Geräte entsprechend groß eingestellt sein<br />
{{Randnotiz|RNTyp=r|RNText=VORSICHT blöder Schreibweisen-Mismatch ITClock vs. ITclock!!}}<br />
* Sende-Takt-Wert (Clock) passt evt. nicht ganz, siehe z.B. Thread-Antwort {{Link2Forum|Topic=58397|Message=775434|LinkText=Signalduino Version 3.3.1}}, wo für IT-Geräte ein Attribut anhand der CP= des Empfangsdaten-Logs modifiziert wird. ACHTUNG: dies kann entweder global das Internal-Attribut <code>ITClock</code> eines SIGNALduino-Transceiver-Devices sein, oder (viel besser da korrekt Geräte-Instanz-spezifische Konfiguration) das <code>ITclock</code> eines IT-Client-Devices.<br />
<br />
== Fehlerbehandlung ==<br />
<br />
=== Modul-Initialisierung ===<br />
<br />
==== Perl-Modul Digest::CRC fehlt ====<br />
<br />
Das FHEM-Log kann (bei neueren SIGNALduino-Modulen?) folgendes enthalten:<br />
<br />
<code>Can't locate Digest/CRC.pm in @INC (you may need to install the Digest::CRC module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib /opt/fhem . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870.<br />
BEGIN failed--compilation aborted at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870.</code><br />
<br />
In diesem Fall ist der Transceiver nicht funktionsfähig - es muss erst Perl-Modul <code>Digest::CRC</code> (Ubuntu: Package <code>libdigest-crc-perl</code>) installiert werden und fhem neu gestartet werden.<br />
<br />
=== Konfiguration von Firmware/Hardware (Reset usw.) ===<br />
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:<br />
:<code>set raw e</code><br />
Ob ein solcher Reset nötig ist, erkennt man an dem Inhalt vom Reading <code>cc1101_config</code>, dort unsinnige Werte angezeigt werden oder dem Reading <code>config</code> welches durch den Befehl "get config" aktualisiert wird, was im Standard auf "MS=1;MU=1;MC=1" entspricht.<br />
<br />
In der Firmware sind diverse Befehle eingebaut, welche über einen <code>set raw</code> Befehl im Modul direkt ausgeführt werden können. Sofern möglich, sollte die Abfrage von Werten aus dem Modul allerdings mit den dafür vorgesehenen Kommandos erfolgen, da die Rückmeldungen des <code>set raw</code> Befehls nur im Logfile ab [[Verbose]] 4 erscheinen. Die Befehle sind nützlich, wenn direkt auf den Microcontroller zugegriffen wird: <br />
<br />
:<code>C<reg></code> <reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers. Example: <code>set raw C35</code> führt ab [[Verbose]] 4 zu einer Logausgabe folgender Art: <code>Read, msg: C35 = 0D</code><br />
:<code>e</code> EEPROM / factory reset. resets all eeprom values without reboot<br />
:<code>W<AA><XX></code> Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die EEPROM Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2 des CC1101)<br />
<br />
Die Sendeleistung lässt sich mit <br />
:<code>get sduino ccpatable</code> <br />
<br />
prüfen, wobei die Rückmeldung wie folgt zu lesen ist: <br />
"-10_dBm" => '34',<br />
"-5_dBm" => '68',<br />
"0_dBm" => '60',<br />
"5_dBm" => '84',<br />
"7_dBm" => 'C8',<br />
"10_dBm" => 'C0' <br />
Dabei wird die Sendeleistung dauerhaft mit dem Befehl<br />
:<code>set sduino cc1101_patable <value></code><br />
hochgeschaltet (<value> durch den Wert ersetzen).<br />
<br />
Weitere Firmware-Befehle sind im Thread-Beitrag {{Link2Forum|Topic=58396|Message=497921}} zu finden.<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=82379|Message=1033374|LinkText=SIGNALDuino Schaltplan}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.rflink.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]]<br />
* [[Somfy via SIGNALduino]]<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=SIGNALduino&diff=35976SIGNALduino2021-08-25T23:41:25Z<p>AndreasMohr: Mention CMake config, clarifications, formatting, cleanup</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Empfang und Verarbeitung von digitalen Signalen<br />
|ModType=d<br />
|ModFTopic=38402<br />
|ModCmdRef=SIGNALduino<br />
|ModForumArea=Sonstige Systeme<br />
|ModTechName=00_SIGNALduino.pm<br />
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])<br />
}}<br />
<br />
== Einleitung ==<br />
=== Übersicht ===<br />
Unter den Namen SIGNALduino versteht man sowohl den Low-Cost Empfänger für digitale Signale (vergleichbar dem [[CUL]]) als auch das gleichnamige Modul mit dem Dateinamen 00_SIGNALduino.pm. Mit dem SIGNALduino kann man entweder 433 oder 868 MHz-Geräte auslesen und ansprechen. Der SIGNALduino funktioniert auch mit anderen Medien wie Infrarot oder direkter Kabelverbindung.<br />
<br />
Der SIGNALduino(-Stick) erkennt Signale anhand von Mustern und gibt sie (als maximal detaillierte Beschreibung einer Signalabfolge) dann schlicht sofort nur noch an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben.<br />
Aufgabe des SIGNALduino (Firmware/Stick) ist es also nur, Signal-Aktivitäten zu erfassen und maximal präzise (als kurzer Text-String) zu beschreiben.<br />
Alles weitere (echte, finale Auswertung / Zuweisung dieser Signal-Daten) wird dann auf einer großen Box (z.B. Raspberry) gemacht.<br />
<br />
=== Vorteil gegenüber einem CUL/FHEMduino ===<br />
Der SIGNALduino hat den Vorteil einer sehr schnellen Demodulation des Funksignals. Sollen weitere Protokolle dekodiert werden, so muss dazu nur ein passendes FHEM Modul entwickelt oder ein universelles Modul erweitert werden (also auf flexibel direkt updatebarer Rechner-Seite!!). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung der Stick-Firmware korrekt funktioniert - leider nicht immer, z.B.: [https://github.com/RFD-FHEM/SIGNALDuino/issues/65 MU-Nachrichten werden z.T. als MC erkannt]).<br />
<br />
Ein großer Vorteil des SIGNALduino besteht darin, dass auch Geräte mit leicht abweichenden Frequenzen steuerbar sind; so empfangen die Somfy-Rolladenmotoren beispielsweise auf 433.42 und nicht, wie bei anderen Geräten sehr oft üblich, auf 433.92 MHz. Die Frequenzumstellung stellt für den SIGNALduino kein Problem dar.<br />
<br />
Ebenso kann man den SIGNALduino direkt an den Sendeausgang eines Sensors anbinden und die digitalen Signale empfangen, dabei bitte aber auf die passenden Spannungen achten, denn ein Arduino Nano verträgt nur 5V.<br />
<br />
<br />
=== Entwicklungsversion ===<br />
Der SIGNALduino wird derzeit aktiv weiterentwickelt, siehe dazu https://github.com/RFD-FHEM. Die offizielle Version wird {{Link2Forum|Topic=58396|LinkText=hier}} genauer beschrieben. Es existieren im Forum diverse angepasste Versionen, auf die hier nicht näher eingegangen wird.<br />
<br />
== Hardware ==<br />
=== Controller ===<br />
Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden. Bei Einbindung via ESP muss man beachten, dass der ESP nach 5 Minuten Inaktivität seine TCP-Verbindung unterbricht (siehe [[ESP8266#Bekannte_Probleme|diesen Hinweis]]). Zu diesem Zweck gibt es einen Signalduino-eigenen Ping-Befehl ('get signalduino ping'), der diese Aktivität wieder aufbaut. Ping-Befehle sind auch auf Betriebssystemebene bekannt - allerdings beachte man, dass der ping-Befehl auf Betriebssystemebene ICMP verwendet, zum "Aufwachen" des ESP aber auf TCP-Ebene aktiviert werden muss (zum Unterschied siehe [https://www.tippscout.de/internet-was-sind-tcp-ip-udp-und-icmp_tipp_2268.html hier]) und man daher besser den Signalduino-eigenen Befehl und nicht das Betriebssystem verwendet.<br />
<br />
Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht dem [[Selbstbau_CUL]] (eine frühere Version ist der nicht mehr weiterentwickelte [[FHEMduino]]):<br />
* Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum [[FHEMduino]] <br />
* Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum [[Selbstbau_CUL]]. Dieser Aufbau wird derzeit empfohlen.<br />
* Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, Link zum [http://shop.in-circuit.de/index.php Hersteller]. <br />
<br />
Achten Sie beim Selbstbau auf die entsprechenden Sender-Empfänger. Der sehr preiswert angebotene XY-MK-5V hat sich als zu unzuverlässig erwiesen, während anscheinend beim CC1101 (insbesondere der "grünen Version") keine Probleme auftreten. <br />
<br />
Es stehen auch für den [https://www.arduino.cc/en/Main/arduinoBoardUno UNO] und [https://www.arduino.cc/en/Main/ArduinoBoardProMini PRO Mini] Firmware-Dateien zur Verfügung. Die ausgelieferte Firmware läuft nur auf Mikrocontrollern mit 16 MHz; wer einen Mikrocontroller mit 8 MHz verwenden möchte, muss die Firmware selbst compilieren. Die SW ist auf [https://github.com/RFD-FHEM/SIGNALDuino github]. Vorgesehen ist momentan (für ordentlich breiten Support müsste man wohl eine CMake-Build-Config hinzufügen - ich sollte hier mal in die Pötte kommen...) nur die Übersetzung unter Windows mit Visual Studio und dem Visual Micro Zusatz. Es gibt aber auch eine Anleitung, wie man mit der [[Arduino]] IDE oder einem Makefile [[SIGNALduino Compilieren]] kann.<br />
<br />
Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] nativ läuft, diese funktioniert seit Anfang 2018 annehmbar, allerdings befindet diese sich noch in einer Entwicklungsphase.<br />
<br />
An den "SIGNALESP" kann auch ein CC1101 via SPI angebunden werden:<br />
<br />
{| |<br />
!CC1101 Bezeichnung<br />
!ESP Pin<br />
|-<br />
|CLK||GPIO14<br />
|-<br />
|MOSI||GPIO13<br />
|-<br />
|MISO||GPIO12<br />
|-<br />
|CSN||GPIO15<br />
|-<br />
|GDO0||GPIO4<br />
|-<br />
|GDO2||GPIO5<br />
|}<br />
<br />
Wird eine einfache Empfänger / Sender Kombination verwendet, dann über die Pins:<br />
<br />
{| |<br />
! Bezeichnung <br />
! ESP Pin<br />
|-<br />
|Transmitter||GPIO4<br />
|-<br />
|Receiver||GPIO5<br />
|}<br />
<br />
=== Sendemodule ===<br />
{{Randnotiz|RNTyp=r|RNText=Viele user berichten über Empfangsprobleme bei Nutzung des XY-MK-5V; es wird ausdrücklich empfohlen, ein anderes Empfangsmodul zu nutzen!}}<br />
[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]] <br />
<br />
Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:<br />
* FS1000A Dies ist das Sendemodul (TX) - es wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€). <br />
* RXB6 Das ist das empfohlene Empfangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.<br />
<br />
Die Verkabelung erfolgt analog zum [[FHEMduino]] und das bedeutet (Arduino -> Modul):<br />
* PIN D2 an DATA des RX-Moduls<br />
* PIN D11 an DATA des TX-Moduls (PIN links mit Beschriftung ATAD)<br />
<br />
Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.<br />
<br />
Jetzt fehlen noch die Antennen. Dafür braucht man ein 17,2 cm langes Stück Kupferdraht, das wird beim Anschluss "ANT" jeweils am Modul angelötet (anfängergeeignet).<br />
<br />
== Software ==<br />
<br />
=== USB-ID ermitteln ===<br />
Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) verbunden werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl<br />
<pre> ls -l /dev/serial/by-id </pre><br />
ausführen. Beispielhaft sieht das Ergebnis etwa so aus:<br />
<br />
''lrwxrwxrwx 1 root root 13 Jan 31 00:02 '''usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port''' -> ../../ttyUSB0''<br />
<br />
Damit ist der Anschluss des SIGNALduino bestimmt und das Gerät kann wie im nächsten Abschnitt beschrieben definiert werden. Zuvor muss noch das Modul geladen werden.<br />
<br />
=== FHEM-Modul laden ===<br />
Die SIGNALduino Module werden über das FHEM [[update]] verteilt, sobald die Änderungen einen "stabilen" und alltagstauglichen Zustand haben. Aktuell wird dort die Version 3.4.2 seit 08.04.2020 verteilt.<br />
<br />
Die in der Entwicklung befindliche Version (3.5.x, bringt z.B. Unterstützung für Geräte mit FSK-Modulation) kann mit folgenden Befehlen geladen werden:<br />
<br />
* FHEM aktualisieren: <code>update</code> <br />
* SIGNALduino Modul aktualisieren: <code>update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master<nowiki/>/controls_signalduino.txt</code> Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet.<br />
* Es empfiehlt sich, die Github-Quelle dauerhaft einzutragen: <code>update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt</code>, um weitere Entwicklungs-Updates zu bekommen, und damit das nächste Standard-<code>update</code> nicht die alte Version wieder einspielt.<br />
<br />
Das Gerät kann wie folgt definiert werden (die Spezifikation des USB-Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):<br />
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code><br />
* Solltet Ihr einen SIGNALESP via IP einbinden wollen, ist die Syntax (ebenso wird auch vorgegangen wenn der SIGNALduino beispielsweise über ser2net freigeben wird):<br />
:<code>define <eigener-SIGNALESP-Name> SIGNALduino <ip-adresse>:23</code><br />
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt. Die Baudrate beim SIGNALduino beträgt 57600 - via telnet muss dann dieselbe Baudrate eingestellt werden. <br />
<br />
Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.<br />
<br />
==== Flashen des Arduino mit der SIGNALduino Firmware ====<br />
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:<br />
:<code>sudo apt-get install avrdude</code><br />
<br />
In FHEM ist der SIGNALduino mit dem Status "Open" vorhanden. Jetzt müssen wir FHEM noch mitteilen, welche Hardware wir angeschlossen haben. Über das Attribut ''hardware'' lässt sich zwischen den mitgelieferten Firmware-Dateien wechseln. Solltet ihr einen Nano mit cc1101 Transceiver verwenden, so wählt bitte folgende Hardware<br />
:<code>attr sduino hardware nanoCC1101</code><br />
sonst üblicherweise<br />
:<code>attr sduino hardware nano328</code><br />
<br />
Dann muss mitgeteilt werden, welche Version man geladen haben will: stable oder testing. <br />
:<code>attr sduino updateChannelFW testing</code><br />
Nun wird die entsprechende Firmware heruntergeladen. Dies geschieht durch den Befehl<br />
:<code>get sduino availableFirmware</code><br />
Anschließend kann der ''flash'' Befehl abgesetzt werden: <br />
:<code>set sduino flash <und-dann-auswaehlen></code><br />
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.<br />
<br />
Alternativ kann auch der Flash-Befehl mit einem Dateinamen aufgerufen werden. Diese Möglichkeit sollte jedoch nur verwendet werden, wenn die SIGNALduino Firmware selbst compiliert wurde und eine andere Hardware verwendet wird. Der Flash-Befehl wird wie folgt aufgerufen:<br />
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code><br />
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)<br />
<br />
Wenn ein miniCUL geflasht werden soll, sind einige Besonderheiten zu beachten. Details dazu in {{Link2Forum|Topic=114413|LinkText=diesem Forenthema}}.<br />
<br />
==== Flashen einer Firmware über HTTP ====<br />
Die Firmware wird nicht mehr über den FHEM Update Mechanismus verteilt. <br />
Damit die passende Firmware auf den SIGNALduino geladen werden kann, wird diese dann über HTTP aus den Github Releases geladen.<br />
<br />
==== Vorabversion einer Firmware ====<br />
Die Firmware des SIGNALduino wird ebenso wie das FHEM Modul auch weiter entwickelt.<br />
Die Entwickler sind auf Tests und Rückmeldungen der Nutzer angewiesen, da leider nicht alle Sensoren vorher getestet werden können.<br />
<br />
Die Version 3.4 ist die aktuell stabile Version.<br />
<br />
Für die folgenden Microcontroller kann man die Firmware seit 21.02.2019 auch direkt downloaden und teilweise flashen. <br />
Dazu muss das Attribut <code>hardware</code> auf einen gültigen Wert angepasst werden!<br />
Über den GET Befehl <code>availableFirmware</code> werden dann für die hinterlegte Hardware die passenden Versionen gesucht. Über das Attribut <code>updateChannelFW</code> kann zwischen "stable" und "testing" definiert werden, welche Art von Firmware angeboten werden soll.<br />
<br />
Nachdem die Firmwareversion erfragt wurde, bietet der set flash Befehl eine Auswahlliste an. Wird ein Flash Befehl mit einer der Versionen ausgewählt, wird diese Version zunächst heruntergeladen und bei den AVR Versionen auch versucht diese mittels avrdude zu flashen.<br />
Die Firmware für den ESP8266 kann aktuell leider noch nicht über diesen Befehl aktualisiert werden.<br />
<br />
Alternativ funktioniert aber auch die Option, dem Flash Befehl eine URL zu übergeben. Dann wird die Datei aus der URL heruntergeladen und auch versucht diese zu Flashen. z.B.<br />
SIGNALDuino_nanocc1101.hex für einen Nano mit CC1101<br />
<br />
<code>set sduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_radinocc11013.3.1.hex<br />
<br />
oder<br />
SIGNALESP_.hex (mit cc1101) für einen ESP8266 <br />
<code>set ipduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_ESP8266cc11013.3.1.hex<br />
<br />
!Achtung, aktuell wird die Firmware für den ESP dadurch nur herunter geladen. Flashen müsst ihr leider immer noch über ein passendes Tool <br />
z.B. [https://github.com/nodemcu/nodemcu-flasher ESP8266Flasher.exe] oder Esptool und einer seriellen Konsole.<br />
Auch ist zu beachten, es handelt sich hierbei tatsächlich um ein Binary und nicht um ein Hex File. <br />
<br />
Nach dem Booten des ESPs spannt dieser ein eigenes WLAN auf. Habt ihr euch damit verbunden, könnt ihr den ESP mit eurem vorhandenen WLAN nach Eingabe der Daten verbinden.<br />
<br />
Die Hauptseite für Firmware-Releases findet sich unter https://github.com/RFD-FHEM/SIGNALDuino/releases/ .<br />
Dort kann auch eine Änderungshistorie eingesehen werden.<br />
==== Flashen eines radino Boards mit ATmega32U4 ====<br />
<br />
Diese Funktion steht seit 21.02.2019 nun auch in der via FHEM aktualisierten Version zur Verfügung:<br />
<br />
Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird.<br />
Weiterhin ist zu beachten, dass der Bootloader eine andere USB ID bekommt und diese im Attribut <code>flashCommand</code> hinterlegt werden muss.<br />
<br />
==== Fehler beim Flashen ====<br />
Sollte bei einem Flash Vorgang ein Fehler auftreten, solltet ihr zunächst im Logfile mit Verbose 5 nachsehen.<br />
<br />
Findet ihr dort keine Fehlermeldung, gibt es noch ein separates Flashlog, welches ihr über einen Browser aufrufen könnt. Dazu müsst ihr nur den folgenden Pfad an euren Servernamen anhängen:<br />
<code><br />
/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=SIGNALduino-Flash.log<br />
</code><br />
<br />
=== Geräteerkennung ===<br />
==== Unterstützte Geräte ====<br />
Für die folgenden Geräte gibt es derzeit (2017) eine Unterstützung für den Betrieb mit FHEM. Die Geräte werden [[autocreate|automatisch erkannt]] und in der Konfiguration eingetragen, wenn der SIGNALduino läuft.<br />
Bitte Geräte mit sehr präzisen Referenzen hier listen (Produktnummer, Protokoll-Variantenname etc.), damit eine globale Suche/Verifikation maximal erfolgreich ist. In der detaillierten Liste [[Geprüfte_Geräte]] lassen sich die Geräte näher identifizieren.<br />
{| class="wikitable"<br />
! style="text-align:left;" | Produkt <br />
! (E)mpfangen<br />(S)enden <br />
! Hinweise <br />
! Verwendetes Modul <br />
! Protokoll ID<br />
|-<br />
|Conrad Wetterstation KW9110||E S||Sensor: KW9010, neben Temperatur u. Luftfeuchte werden auch Trend, Batterie u. Kanal erfasst|| CUL_TCM97001 || 0.3<br />
|-<br />
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0 <br />
|-<br />
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17<br />
|-<br />
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL || <br />
|-<br />
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10<br />
|-<br />
|Bresser Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12<br />
|-<br />
|TFA Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8<br />
|-<br />
|TFA 30320902||E || || SD_WS07 || 7<br />
|-<br />
|Eurochron eas800z||E || || SD_WS07 || 7<br />
|-<br />
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7<br />
|-<br />
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7<br />
|-<br />
|CTW600||E || || SD_WS09 || 9<br />
|-<br />
|CTW602||E ||neuere Version des CTW600 mit 868.35 MHz || SD_WS09 || 9<br />
|-<br />
|WH1080||E || || SD_WS09 || 9<br />
|-<br />
|Visivon remote pt4450||E || || none || 24<br />
|-<br />
|Einhell HS 434/6||E || || none || 21<br />
|-<br />
|Flamingo FA20RF / FA21RF / FA22RF Rauchmelder||E || || FLAMINGO || 13,13.1,13.2<br />
|-<br />
|mumbi m-FS300||E || || none || 26,27<br />
|-<br />
|TFA 30.3200||E || || none || 33<br />
|-<br />
|Livolo||E|| || none || 20<br />
|-<br />
|Smartwares RM174RF/2 (RM174RF-001CPR) 4500177571 ||E [S?]|| IT EV1527; TODO herausfinden: Alarmierung (wie Alarmton getriggered werden kann); Batterieinfo? || IT || 3<br />
|-<br />
|Smartwares SH5-TSO-A||E S|| || IT || ?<br />
|-<br />
|X10 Security Devices||E|| || || 39<br />
|-<br />
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43<br />
|}<br />
Bei einigen Intertechno-Funksteckdosen (Brennenstuhl) kann es zu Empfangsproblemen kommen. Hier muss die Taktrate, mit der gesendet wird, angepasst werden. Dazu muss für ''Funksteckdose'' (also sauber per-Client-Instanz-spezifisch, NICHT SIGNALduino-Transceiver-global) das Attribut <br />
:<code>attr <Funksteckdose> ITclock 300</code> <br />
gesetzt werden, der Standardwert ist 250.<br />
<br />
==== Mein Gerät wird in FHEM nicht erkannt ====<br />
1. Prüfen, ob vom Sensor die Signaldaten (<code>verbose</code> >=4) erkannt werden. Sobald ihr die empfangenen Signaldaten im Logfile zuordnen könnt, geht es weiter mit:<br />
<br />
2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues/new?template=sensor---device-feature.md github]:<br />
<!-- <syntaxhighlight lang="md"> ... markdown lexer not yet available; use pre instead --><br />
<pre><br />
## Specifications for new sensor / switch / or other device ... <br />
<br />
- manufacturer:<br />
- model name:<br />
- pictures of the device / the board (very helpful)<br />
<br />
<br />
## Specifications <br />
<br />
- Microcontroller:<br />
- Version (Firmware):<br />
<br />
<!-- ( can be found here devicename -> Internals -> version ) --><br />
- Versionmodul (FHEM Module):<br />
</pre><br />
<br />
3. Auszug aus dem Logfile, welches zum Gerät gehört.<br />
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.''<br />
<br />
Im Forum solltet ihr solche Fragen besser nicht posten, wenn das Gerät noch nicht unterstützt wird, dazu ist Github besser geeignet. Inzwischen wurde im Wiki eine eigene Seite eröffnet, die sich mit der Erkennung unbekannter Protokolle beschäftigt: [[Unbekannte_Funkprotokolle#Ansatz_1_-_Versuchen|Unbekannte_Funkprotokolle]].<br />
<br />
==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ====<br />
Im SIGNALduino sind >70 Protokolle implementiert. Jedoch gibt es nicht immer ein logisches Module, welche diese Protokolle verarbeiten.<br />
Teilweise ist das auch nicht zwingend notwendig, um seine Anforderungen zu erfüllen. Insbesondere für Schalter bzw. Sensoren, die nur zwei Zustände kennen, geht es meist ohne Modul und automatisch angelegtem Gerät.<br />
<br />
Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden.<br />
Im FHEM Log (und, insbesondere, im FHEMWEB Event Monitor) tauchen Meldungen ähnlich dieser auf<br />
<br />
<code><br />
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081<br />
</code><br />
<br />
Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:<br />
<br />
Entweder, wenn wir den Inhalt der Nachricht nur zu Teilen wissen, da er sich ändert:<br />
<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)<br />
attr mydoif do always<br />
</code><br />
<br />
Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring<br />
<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on)<br />
attr mydoif do always<br />
</code><br />
<br />
Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.<br />
<br />
Als Alternative zu DOIF hier ein regex-verwendendes notify-Beispiel für einen Sender, der meint, zwei Codes alternierend senden zu müssen:<br />
<br />
<code><br />
define n_sender_trigger notify sduino:UNKNOWNCODE.*u41#(13B72253|163873B3) { my_sender_trigger_indicate();; }<br />
</code><br />
<br />
Selbstverständlich muss in diesem Moment auch eine sub my_sender_trigger_indicate() definiert werden (z.B. in FHEM/99_myUtils.pm), die dort z.B. als Test eine Log-Ausgabe (Log3()) machen kann.<br />
<br />
=== Das Logfile ===<br />
Im Logfile ab [[Verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (<code>verbose</code> 3 unterdrückt diese Meldungen).<br />
<br />
UPDATE: der folgende Bereich ist von einem weniger erfahrenen Zeitgenossen früher nach Kräften erweitert/geschrieben worden. Mittlerweile existiert aber ein neuer Inhalt [[Unbekannte_Funkprotokolle]] (siehe auch Erwähnung weiter oben), der als sehr gut beschrieben und unvergleichlich detailreicher bezeichnet werden muss ("endlich gibt es sowas!"). Der Bereich hier dürfte somit zwar für grundlegende Verdeutlichungen noch recht sinnvoll sein, der Inhalt sollte allerdings evt. in eine konsistente Dokumentation überarbeitet (verlagert/dedupliziert/reduziert) werden.<br />
<br />
Die Protokolle (von der SIGNALDuino-Firmware gesendete Signal-Beschreibungs-Strings) können wie folgt unterschieden werden:<br />
<br />
*MS - Nachricht mit Sync Puls: Hierzu ein Beispiel<br />
:<code>MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;</code> P0-P6 sind die Signalpegel (Dauer und positiv/negativ). Hinter D= befindet sich die Abfolge der Signale. Die ersten beiden Ziffern 15 in D sind wie folgt zu lesen. Zuerst wurde ein Signal "1" also P1 mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal "5" also P5 mit 8916 Mikrosekunden low (die Zeitdauer ergibt sich aufgrund der Mitteilung "P5=-8916") gemessen. CP=1 ist die Referenz auf den Takt des Signales - der Basistakt ist in diesem Fall ~395 Mikrosekunden. SP=5 gibt die Referenz zum Syncpuls an, der das gesamte Signal einleitet. Welche Signalfolge nun eine binäre 1 bzw. 0 bedeutet, wird im SIGNALduino über die integrierte Protokoll Liste realisiert.<br />
<br />
*MC - Nachricht vom Typ Manchester: Manchesterkodierte Signale können bereits sehr einfach im Arduino in eine Binärform umgewandelt werden. Es wird hier nach IEEE 802.3 umgewandelt. In Manchester Signalen gibt es lange und kurze Pulse. Deren Durchschnittswert wird mit LL (long low), LH (long high), SL (short low) und SH (short high) übermittelt. Zusätzlich, um das Protokoll schneller erkennen zu können, wird die Taktfrequenz mit übermittelt (C=429 Mikrosekunden). Die Daten befinden sich hinter D= und werden in HEX Form übergeben.<br />
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code><br />
<br />
*MU - Message unsynced: Diese Art von Nachrichten sind nicht nach Manchester codiert und haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht. Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist. Wie bei MS sind P0-P6 die Signalpegel und in D= wird die Abfolge der Signalpegel referenziert. CP=2 gibt auch hier die Referenz zum Takt an, allerdings muss dieser nicht korrekt erkannt worden sein.<br />
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code><br />
<br />
Es erscheinen viele Meldungen dieser Art:<br />
<br />
<pre><br />
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate<br />
</pre><br />
<br />
Dies sind nun Bemühungen, anhand der von der SIGNALDuino-Firmware gelieferten rohen aber detaillierten Signal-Strings eine Vor-Analyse / Fingerprinting vorzunehmen.<br />
Man könnte nun z.B. bei solchen Fingerprinting-Analysen erkennen:<br />
* dass der Basis-Takt-Wert innerhalb eines charakteristischen Zeit-Bereichs liegt<br />
* dass die Anzahl der Sync-Pulse eine präzise Zahl ist<br />
* dass Längen erkannter Puls-Typen innerhalb eines Bereichs liegen<br />
<br />
Mittels solcher Untersuchungen kann man also final hoffentlich hinreichend plausibel feststellen, "dass diese Aktivitäten offensichtlich(?) zu einer Funk-Komponente Rauchmelder von Hersteller XYZ gehören müssen, und man somit weiterleiten muss an ein (möglicherweise bereits existierendes) Userdaten-Dekodier-Modul für diese Herstellerkomponente".<br />
<br />
<br />
Bei einer dann erfolgenden Demodulation des noch rohen SIGNALDuino-Strings könnte man z.B. (hoffentlich richtigerweise) annehmen, dass eine Signalpegel-Typ-Folge "13" eine binäre 1 bedeuten soll, während eine Folge "12" eine binäre 0 bedeuten soll. Man erhält aus dem Gesamt-Puls-String also nach vollständiger Demodulation eine Abfolge von vielen 0/1 Bits, die insgesamt ein Datenwort darstellen, mit einer gewissen Länge von NN bits (diese Längen-Angabe könnte übrigens - neben Namenssuche nach Hersteller oder Produkt etc. - ein wichtiges Such-Merkmal sein, ob andere Frameworks tatsächlich bereits wissen, wie Daten dieser Funk-Komponente zu dekodieren sind!). Dieses demodulierte Datenwort ist nun das finale Datenwort, welches einen Container für die Funk-Komponenten-Informationen darstellt (in diesem Container also beispielsweise folgende Bits-Bereiche enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Daten-Container erst einmal CRC- oder Crypto-verschlüsselt ist...).<br />
<br />
Man muss an dieser Stelle unbedingt sagen, dass dieses Userdaten-Datenwort (einer bestimmten Hersteller-Funk-Komponente!) natürlich bei ''jeglichen'' Transceiver-Systemen ''immer'' gleich (identisch) erkannt werden ''muss'' - an dieser Stelle ist also ganz klar, dass diese Daten an ''allgemeine'' FHEM-Module weitergeleitet (Dispatched) werden müssen, die nach Übernahme von Daten von ''jeglichen'' Transceiver-Systemen diese Daten immer auf die gleiche Weise ('''''generisch/zentral''''') für die jeweilige Hersteller-Funk-Komponente erledigen.<br />
<br />
'''Die Abfolge ist also ganz klar:'''<br />
Funk-Aktivität --> Transceiver-Gerät/Firmware (SIGNALDuino) --> maximal detailreich beschreibender Rx-Analyse-Output-String --> Fingerprinting-Grobzuordnung des (SIGNALDuino-Firmware-)Outputs (durch 00_SIGNALduino.pm) auf gerätespezifisches Verhalten --> ''generische/zentrale'' Dekodierung des gerätespezifischen Protokoll-Datenworts, in zentralen Grundsatz-Modulen wie z.B. <code>14_SD_WS.pm</code>).<br />
<br />
Und wenn dann bei einer solchen Schritte-Abfolge irgendetwas noch fehlen/unpassend sein sollte, dann muss eben entsprechendes Development an gewissen Stellen erfolgen ;-)<br />
<br />
====Minimieren (whitelist/blacklist) von unerwünschter Kommunikations-Aktivität/Einträgen====<br />
<br />
"Unknown Code" bedeutet, dass der SIGNALduino Signaldaten empfangen und diese binär interpretiert hat. Diese Meldung soll uns nun aber mitteilen, dass es dann nicht weiter verarbeitet werden kann, da kein Modul existiert (oder kein Weiterleitungs-Dispatch zu einem bereits existierenden), welches diese Daten jetzt in ihre Bedeutung umwandeln kann. <br />
:<code>sduino: Unknown code u1FFFFF0, help me!</code><br />
<br />
Außerdem kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:<br />
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code><br />
<br />
Mittlerweile sind über 50 Protokolle für den SIGNALduino definiert. Dadurch kommt es vor, dass sich ein Signal mit mehr als einem Protokoll demodulieren lässt. Meist führt dies dann zu zusätzlichen "Unknown code"-Einträgen.<br />
<br />
Derartige Einträge können mit dem Attribut <code>WhitelistID</code> minimiert werden. Dabei werden die Geräte, die nach Daten-Empfang tatsächlich verarbeitet werden sollen (also welche Protokolle vom FHEM Modul berücksichtigt werden), mit ihrer Protokollnummer in die <code>WhitelistID</code> aufgenommen.<br />
Für Protokolle, die nicht berücksichtigt werden, gibt es weder Logeinträge noch Events. Diese werden im Programmablauf nicht berücksichtigt. Das spart zum einen Ressourcen und trägt auch zur Übersichtlichkeit bei. <br />
Die Protokollnummer kann Tabelle [[#Unterst.C3.BCtzte_Ger.C3.A4te|Unterstützte Geräte]] entnommen werden (hilfreich ist es auch, wenn in den verwendeten Geräten im Internal <gerätename>_DMSG nachgesehen wird). So bedeutet beispielsweise ein Eintrag der Form <code>W50#FF553335FFBC</code> dass dann das Protokoll #50 in die Whitelist aufzunehmen wäre (<code>attr sduino whitelist_IDs 50</code>).<br />
{{Randnotiz|RNTyp=r|RNText=Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!!<br />
}}<br />
Die Angabe erfolgt durch Komma getrennt: z.B.:<br />
:<code>1,2,5,10</code><br />
<br />
=== Senden mit dem SIGNALduino ===<br />
Der SIGNALduino kann etwas "raw senden", indem ihm das Signal so übermittelt wird, wie er es moduliert. Hierzu muss der Befehl wie folgt eingegeben werden:<br />
<br />
<code><br />
set sduino sendMsg P3#00111010#R4<br />
</code><br />
<br />
Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.<br />
Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits.<br />
<code><br />
sduino: extracted data 00111010 (bin)<br />
sduino: Found Protocol id 3 <br />
</code><br />
<br />
Alternativ kann das Signal auch in einer "Rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig:<br />
<code><br />
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;<br />
</code><br />
<br />
R=3 bedeutet, das Signal wird 3x gesendet.<br />
Die Übertragung besteht aus den in D angegebenen Pulsen, welche in P0-P5 definiert werden.<br />
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.<br />
<br />
Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.<br />
<br />
====Fehlersuche====<br />
(Zielgerät reagiert nicht, etc.)<br />
<br />
* Nachrichtenwiederholungsanzahl muss evt. für manche Geräte entsprechend groß eingestellt sein<br />
{{Randnotiz|RNTyp=r|RNText=VORSICHT blöder Schreibweisen-Mismatch ITClock vs. ITclock!!}}<br />
* Sende-Takt-Wert (Clock) passt evt. nicht ganz, siehe z.B. Thread-Antwort {{Link2Forum|Topic=58397|Message=775434|LinkText=Signalduino Version 3.3.1}}, wo für IT-Geräte ein Attribut anhand der CP= des Empfangsdaten-Logs modifiziert wird. ACHTUNG: dies kann entweder global das Internal-Attribut ITClock eines SIGNALduino-Transceiver-Devices sein, oder (viel besser da korrekt geräte-instanz-spezifische Konfiguration) das ITclock eines IT-Client-Devices.<br />
<br />
== Fehlerbehandlung ==<br />
<br />
=== Modul-Initialisierung ===<br />
<br />
==== Perl-Modul Digest::CRC fehlt ====<br />
<br />
Das FHEM-Log kann (bei neueren SIGNALduino-Modulen?) folgendes enthalten:<br />
<br />
<code>Can't locate Digest/CRC.pm in @INC (you may need to install the Digest::CRC module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib /opt/fhem . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870.<br />
BEGIN failed--compilation aborted at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870.</code><br />
<br />
In diesem Fall ist der Transceiver nicht funktionsfähig - es muss erst Perl-Modul Digest::CRC (Ubuntu: package <code>libdigest-crc-perl</code>) installiert werden und fhem neu gestartet werden.<br />
<br />
=== Konfiguration von Firmware/Hardware (Reset usw.) ===<br />
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:<br />
:<code>set raw e</code><br />
Ob ein solcher Reset nötig ist, erkennt man an dem Inhalt vom Reading <code>cc1101_config</code>, dort unsinnige Werte angezeigt werden oder dem Reading <code>config</code> welches durch den Befehl "get config" aktualisiert wird, was im Standard auf "MS=1;MU=1;MC=1" entspricht.<br />
<br />
In der Firmware sind diverse Befehle eingebaut, welche über einen <code>set raw</code> Befehl im Modul direkt ausgeführt werden können. Sofern möglich, sollte die Abfrage von Werten aus dem Modul allerdings mit den dafür vorgesehenen Kommandos erfolgen, da die Rückmeldungen des <code>set raw</code> Befehls nur im Logfile ab [[Verbose]] 4 erscheinen. Die Befehle sind nützlich, wenn direkt auf den Microcontroller zugegriffen wird: <br />
<br />
:<code>C<reg></code> <reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers. Example: <code>set raw C35</code> führt ab Verbose 4 zu einer Logausgabe folgender Art <code>Read, msg: C35 = 0D</code><br />
:<code>e</code> EEPROM / factory reset. resets all eeprom values without reboot<br />
:<code>W<AA><XX></code> Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die EEPROM Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2 des CC1101)<br />
<br />
Die Sendeleistung lässt sich mit <br />
:<code>get sduino ccpatable</code> <br />
<br />
prüfen, wobei die Rückmeldung wie folgt zu lesen ist: <br />
"-10_dBm" => '34',<br />
"-5_dBm" => '68',<br />
"0_dBm" => '60',<br />
"5_dBm" => '84',<br />
"7_dBm" => 'C8',<br />
"10_dBm" => 'C0' <br />
Dabei wird die Sendeleistung dauerhaft mit dem Befehl<br />
:<code>set sduino cc1101_patable <value></code><br />
hochgeschaltet (<value> durch den Wert ersetzen).<br />
<br />
Weitere Firmware-Befehle sind im Thread-Beitrag {{Link2Forum|Topic=58396|Message=497921}} zu finden.<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=82379|Message=1033374|LinkText=SIGNALDuino Schaltplan}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.rflink.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]]<br />
* [[Somfy via SIGNALduino]]<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=SIGNALduino&diff=35975SIGNALduino2021-08-25T23:22:58Z<p>AndreasMohr: Mention Perl Digest::CRC module issues</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Empfang und Verarbeitung von digitalen Signalen<br />
|ModType=d<br />
|ModFTopic=38402<br />
|ModCmdRef=SIGNALduino<br />
|ModForumArea=Sonstige Systeme<br />
|ModTechName=00_SIGNALduino.pm<br />
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])<br />
}}<br />
<br />
== Einleitung ==<br />
=== Übersicht ===<br />
Unter den Namen SIGNALduino versteht man sowohl den Low-Cost Empfänger für digitale Signale (vergleichbar dem [[CUL]]) als auch das gleichnamige Modul mit dem Dateinamen 00_SIGNALduino.pm. Mit dem SIGNALduino kann man entweder 433 oder 868 MHz-Geräte auslesen und ansprechen. Der SIGNALduino funktioniert auch mit anderen Medien wie Infrarot oder direkter Kabelverbindung.<br />
<br />
Der SIGNALduino(-Stick) erkennt Signale anhand von Mustern und gibt sie (als maximal detaillierte Beschreibung einer Signalabfolge) dann schlicht sofort nur noch an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben.<br />
Aufgabe des SIGNALduino (Firmware/Stick) ist es also nur, Signal-Aktivitäten zu erfassen und maximal präzise (als kurzer Text-String) zu beschreiben.<br />
Alles weitere (echte, finale Auswertung / Zuweisung dieser Signal-Daten) wird dann auf einer großen Box (z.B. Raspberry) gemacht.<br />
<br />
=== Vorteil gegenüber einem CUL/FHEMduino ===<br />
Der SIGNALduino hat den Vorteil einer sehr schnellen Demodulation des Funksignals. Sollen weitere Protokolle dekodiert werden, so muss dazu nur ein passendes FHEM Modul entwickelt oder ein universelles Modul erweitert werden (also auf flexibel direkt updatebarer Rechner-Seite!!). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung des Sticks korrekt funktioniert - leider nicht immer, z.B.: [https://github.com/RFD-FHEM/SIGNALDuino/issues/65 MU-Nachrichten werden z.T. als MC erkannt]).<br />
<br />
Ein großer Vorteil des SIGNALduino besteht darin, dass auch Geräte mit leicht abweichenden Frequenzen steuerbar sind; so empfangen die Somfy-Rolladenmotoren beispielsweise auf 433.42 und nicht, wie bei anderen Geräten sehr oft üblich, auf 433.92 MHz. Die Frequenzumstellung stellt für den SIGNALduino kein Problem dar.<br />
<br />
Ebenso kann man den SIGNALduino direkt an den Sendeausgang eines Sensors anbinden und die digitalen Signale empfangen, dabei bitte aber auf die passenden Spannungen achten, denn ein Arduino Nano verträgt nur 5V.<br />
<br />
<br />
=== Entwicklungsversion ===<br />
Der SIGNALduino wird derzeit aktiv weiterentwickelt, siehe dazu https://github.com/RFD-FHEM. Die offizielle Version wird {{Link2Forum|Topic=58396|LinkText=hier}} genauer beschrieben. Es existieren im Forum diverse angepasste Versionen, auf die hier nicht näher eingegangen wird.<br />
<br />
== Hardware ==<br />
=== Controller ===<br />
Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden. Bei Einbindung via ESP muss man beachten, dass der ESP nach 5 Minuten Inaktivität seine TCP-Verbindung unterbricht (siehe [[ESP8266#Bekannte_Probleme|diesen Hinweis]]). Zu diesem Zweck gibt es einen Signalduino-eigenen Ping-Befehl ('get signalduino ping'), der diese Aktivität wieder aufbaut. Ping-Befehle sind auch auf Betriebssystemebene bekannt - allerdings beachte man, dass der ping-Befehl auf Betriebssystemebene ICMP verwendet, zum "Aufwachen" des ESP aber auf TCP-Ebene aktiviert werden muss (zum Unterschied siehe [https://www.tippscout.de/internet-was-sind-tcp-ip-udp-und-icmp_tipp_2268.html hier]) und man daher besser den Signalduino-eigenen Befehl und nicht das Betriebssystem verwendet.<br />
<br />
Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht dem [[Selbstbau_CUL]] (eine frühere Version ist der nicht mehr weiterentwickelte [[FHEMduino]]):<br />
* Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum [[FHEMduino]] <br />
* Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum [[Selbstbau_CUL]]. Dieser Aufbau wird derzeit empfohlen.<br />
* Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, Link zum [http://shop.in-circuit.de/index.php Hersteller]. <br />
<br />
Achten Sie beim Selbstbau auf die entsprechenden Sender-Empfänger. Der sehr preiswert angebotene XY-MK-5V hat sich als zu unzuverlässig erwiesen, während anscheinend beim CC1101 (insbesondere der "grünen Version") keine Probleme auftreten. <br />
<br />
Es stehen auch für den [https://www.arduino.cc/en/Main/arduinoBoardUno UNO] und [https://www.arduino.cc/en/Main/ArduinoBoardProMini PRO Mini] Firmware-Dateien zur Verfügung. Die ausgelieferte Firmware läuft nur auf Mikrocontrollern mit 16 MHz; wer einen Mikrocontroller mit 8 MHz verwenden möchte, muss die Firmware selbst compilieren. Die SW ist auf [https://github.com/RFD-FHEM/SIGNALDuino github]. Vorgesehen ist nur die Übersetzung unter Windows mit Visual Studio und dem Visual Micro Zusatz. Es gibt aber auch eine Anleitung, wie man mit der [[Arduino]] IDE oder einem Makefile [[SIGNALduino Compilieren]] kann.<br />
<br />
Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] nativ läuft, diese funktioniert seit Anfang 2018 annehmbar, allerdings befindet diese sich noch in einer Entwicklungsphase.<br />
<br />
An den "SIGNALESP" kann auch ein CC1101 via SPI angebunden werden:<br />
<br />
{| |<br />
!CC1101 Bezeichnung<br />
!ESP Pin<br />
|-<br />
|CLK||GPIO14<br />
|-<br />
|MOSI||GPIO13<br />
|-<br />
|MISO||GPIO12<br />
|-<br />
|CSN||GPIO15<br />
|-<br />
|GDO0||GPIO4<br />
|-<br />
|GDO2||GPIO5<br />
|}<br />
<br />
Wird eine einfache Empfänger / Sender Kombination verwendet, dann über die PINs:<br />
<br />
{| |<br />
! Bezeichnung <br />
! ESP Pin<br />
|-<br />
|Transmitter||GPIO4<br />
|-<br />
|Receiver||GPIO5<br />
|}<br />
<br />
=== Sendemodule ===<br />
{{Randnotiz|RNTyp=r|RNText=Viele user berichten über Empfangsprobleme bei Nutzung des XY-MK-5V; es wird ausdrücklich empfohlen, ein anderes Empfangsmodul zu nutzen!}}<br />
[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]] <br />
<br />
Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:<br />
* FS1000A Dies ist das Sendemodul (TX) und wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€). <br />
* RXB6 Das ist das empfohlene Empfangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.<br />
<br />
Die Verkabelung erfolgt analog zum [[FHEMduino]] und das bedeutet (Arduino -> Modul):<br />
* PIN D2 an DATA des RX-Moduls<br />
* PIN D11 an DATA des TX-Moduls (PIN links mit Beschriftung ATAD)<br />
<br />
Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.<br />
<br />
Jetzt fehlen noch die Antennen. Dafür braucht man ein 17,2 cm langes Stück Kupferdraht, das wird beim Anschluss "ANT" jeweils am Modul angelötet (anfängergeeignet).<br />
<br />
== Software ==<br />
<br />
=== USB-ID ermitteln ===<br />
Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) verbunden werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl<br />
<pre> ls -l /dev/serial/by-id </pre><br />
ausführen. Beispielhaft sieht das Ergebnis etwa so aus:<br />
<br />
''lrwxrwxrwx 1 root root 13 Jan 31 00:02 '''usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port''' -> ../../ttyUSB0''<br />
<br />
Damit ist der Anschluss des SIGNALduino bestimmt und das Gerät kann wie im nächsten Abschnitt beschrieben definiert werden. Zuvor muss noch das Modul geladen werden.<br />
<br />
=== FHEM-Modul laden ===<br />
Die SIGNALduino Module werden über das FHEM [[update]] verteilt, sobald die Änderungen einen "stabilen" und alltagstauglichen Zustand haben. Aktuell wird dort die Version 3.4.2 seit 08.04.2020 verteilt.<br />
<br />
Die in der Entwicklung befindliche Version (3.5.x, bringt z.B. Unterstützung für Geräte mit FSK-Modulation) kann mit folgenden Befehlen geladen werden:<br />
<br />
* FHEM aktualisieren: <code>update</code> <br />
* SIGNALduino Modul aktualisieren: <code>update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master<nowiki/>/controls_signalduino.txt</code> Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet.<br />
* Es empfiehlt sich, die Github-Quelle dauerhaft einzutragen: <code>update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt</code>, um weitere Entwicklungs-Updates zu bekommen und damit das nächste Standard-<code>update</code> nicht die alte Version wieder einspielt.<br />
<br />
Das Gerät kann wie folgt definiert werden (die Spezifikation des USB-Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):<br />
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code><br />
* Solltet Ihr einen SIGNALESP via IP einbinden wollen, ist die Syntax (ebenso wird auch vorgegangen wenn der SIGNALduino beispielsweise über ser2net freigeben wird):<br />
:<code>define <eigener-SIGNALESP-Name> SIGNALduino <ip-adresse>:23</code><br />
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt. Die Baudrate beim SIGNALduino beträgt 57600 - via telnet muss dann dieselbe Baudrate eingestellt werden. <br />
<br />
Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.<br />
<br />
==== Flashen des Arduino mit der SIGNALduino Firmware ====<br />
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:<br />
:<code>sudo apt-get install avrdude</code><br />
<br />
In FHEM ist der SIGNALduino mit dem Status "Open" vorhanden. Jetzt müssen wir FHEM noch mitteilen, welche Hardware wir angeschlossen haben. Über das Attribut ''hardware'' lässt sich zwischen den mitgelieferten Firmware-Dateien wechseln. Solltet ihr einen Nano mit cc1101 Transceiver verwenden, so wählt bitte folgende Hardware<br />
:<code>attr sduino hardware nanoCC1101</code><br />
sonst üblicherweise<br />
:<code>attr sduino hardware nano328</code><br />
<br />
Dann muss mitgeteilt werden, welche Version man geladen haben will: stable oder testing. <br />
:<code>attr sduino updateChannelFW testing</code><br />
Nun wird die entsprechende Firmware heruntergeladen. Dies geschieht durch den Befehl<br />
:<code>get sduino availableFirmware</code><br />
Anschließend kann der ''flash'' Befehl abgesetzt werden: <br />
:<code>set sduino flash <und-dann-auswaehlen></code><br />
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.<br />
<br />
Alternativ kann auch der Flash-Befehl mit einem Dateinamen aufgerufen werden. Diese Möglichkeit sollte jedoch nur verwendet werden, wenn die SIGNALduino Firmware selbst compiliert wurde und eine andere Hardware verwendet wird. Der Flash-Befehl wird wie folgt aufgerufen:<br />
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code><br />
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)<br />
<br />
Wenn ein miniCUL geflasht werden soll, sind einige Besonderheiten zu beachten. Details dazu in {{Link2Forum|Topic=114413|LinkText=diesem Forenthema}}.<br />
<br />
==== Flashen einer Firmware über HTTP ====<br />
Die Firmware wird nicht mehr über den FHEM Update Mechanismus verteilt. <br />
Damit die passende Firmware auf den SIGNALduino geladen werden kann, wird diese dann über HTTP aus den Github Releases geladen.<br />
<br />
==== Vorabversion einer Firmware ====<br />
Die Firmware des SIGNALduino wird ebenso wie das FHEM Modul auch weiter entwickelt.<br />
Die Entwickler sind auf Tests und Rückmeldungen der Nutzer angewiesen, da leider nicht alle Sensoren vorher getestet werden können.<br />
<br />
Die Version 3.4 ist die aktuell stabile Version.<br />
<br />
Für die folgenden Microcontroller kann man die Firmware seit 21.02.2019 auch direkt downloaden und teilweise flashen. <br />
Dazu muss das Attribut hardware auf einen gültigen Wert angepasst werden!<br />
Über den GET Befehl availableFirmware werden dann für die hinterlegte Hardware die passenden Versionen gesucht. Über das Attribut updateChannelFW kann zwischen "stable" und "testing" definiert werden, welche Art von Firmware angeboten werden soll.<br />
<br />
Nachdem die Firmwareversion erfragt wurde, bietet der set flash Befehl eine Auswahlliste an. Wird ein Flash Befehl mit einer der Versionen ausgewählt, wird diese Version zunächst heruntergeladen und bei den AVR Versionen auch versucht diese mittels avrdude zu flashen.<br />
Die Firmware für den ESP8266 kann aktuell leider noch nicht über diesen Befehl aktualisiert werden.<br />
<br />
Alternativ funktioniert aber auch die Option, dem Flash Befehl eine URL zu übergeben. Dann wird die Datei aus der URL heruntergeladen und auch versucht diese zu Flashen. z.B.<br />
SIGNALDuino_nanocc1101.hex für einen Nano mit CC1101<br />
<br />
<code>set sduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_radinocc11013.3.1.hex<br />
<br />
oder<br />
SIGNALESP_.hex (mit cc1101) für einen ESP8266 <br />
<code>set ipduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_ESP8266cc11013.3.1.hex<br />
<br />
!Achtung, aktuell wird die Firmware für den ESP dadurch nur herunter geladen. Flashen müsst ihr leider immer noch über ein passendes Tool <br />
z.B. [https://github.com/nodemcu/nodemcu-flasher ESP8266Flasher.exe] oder Esptool und einer seriellen Konsole.<br />
Auch ist zu beachten, es handelt sich hierbei tatsächlich um ein Binary und nicht um ein Hex File. <br />
<br />
Nach dem Booten des ESPs spannt dieser ein eigenes WLAN auf. Habt ihr euch damit verbunden, könnt ihr den ESP mit eurem vorhandenen WLAN nach Eingabe der Daten verbinden.<br />
<br />
Die Hauptseite für Firmware-Releases findet sich unter https://github.com/RFD-FHEM/SIGNALDuino/releases/ .<br />
Dort kann auch eine Änderungshistorie eingesehen werden.<br />
==== Flashen eines radino Boards mit ATmega32U4 ====<br />
<br />
Diese Funktion steht seit 21.02.2019 nun auch in der via FHEM aktualisierten Version zur Verfügung:<br />
<br />
Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird.<br />
Weiterhin ist zu beachten, dass der Bootloader eine andere USB ID bekommt und diese im Attribut flashCommand hinterlegt werden muss.<br />
<br />
==== Fehler beim Flashen ====<br />
Sollte bei einem Flash Vorgang ein Fehler auftreten, solltet ihr zunächst im Logfile mit Verbose 5 nachsehen.<br />
<br />
Findet ihr dort keine Fehlermeldung, gibt es noch ein separates Flashlog, welches ihr über einen Browser aufrufen könnt. Dazu müsst ihr nur den folgenden Pfad an euren Servernamen anhängen:<br />
<code><br />
/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=SIGNALduino-Flash.log<br />
</code><br />
<br />
=== Geräteerkennung ===<br />
==== Unterstützte Geräte ====<br />
Für die folgenden Geräte gibt es derzeit (2017) eine Unterstützung für den Betrieb mit FHEM. Die Geräte werden [[autocreate|automatisch erkannt]] und in der Konfiguration eingetragen, wenn der SIGNALduino läuft.<br />
Bitte Geräte mit sehr präzisen Referenzen hier listen (Produktnummer, Protokoll-Variantenname etc.), damit eine globale Suche/Verifikation maximal erfolgreich ist. In der detaillierten Liste [[Geprüfte_Geräte]] lassen sich die Geräte näher identifizieren.<br />
{| class="wikitable"<br />
! style="text-align:left;" | Produkt <br />
! (E)mpfangen<br />(S)enden <br />
! Hinweise <br />
! Verwendetes Modul <br />
! Protokoll ID<br />
|-<br />
|Conrad Wetterstation KW9110||E S||Sensor: KW9010, neben Temperatur u. Luftfeuchte werden auch Trend, Batterie u. Kanal erfasst|| CUL_TCM97001 || 0.3<br />
|-<br />
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0 <br />
|-<br />
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17<br />
|-<br />
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL || <br />
|-<br />
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10<br />
|-<br />
|Bresser Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12<br />
|-<br />
|TFA Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8<br />
|-<br />
|TFA 30320902||E || || SD_WS07 || 7<br />
|-<br />
|Eurochron eas800z||E || || SD_WS07 || 7<br />
|-<br />
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7<br />
|-<br />
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7<br />
|-<br />
|CTW600||E || || SD_WS09 || 9<br />
|-<br />
|CTW602||E ||neuere Version des CTW600 mit 868.35 MHz || SD_WS09 || 9<br />
|-<br />
|WH1080||E || || SD_WS09 || 9<br />
|-<br />
|Visivon remote pt4450||E || || none || 24<br />
|-<br />
|Einhell HS 434/6||E || || none || 21<br />
|-<br />
|Flamingo FA20RF / FA21RF / FA22RF Rauchmelder||E || || FLAMINGO || 13,13.1,13.2<br />
|-<br />
|mumbi m-FS300||E || || none || 26,27<br />
|-<br />
|TFA 30.3200||E || || none || 33<br />
|-<br />
|Livolo||E|| || none || 20<br />
|-<br />
|Smartwares RM174RF/2 (RM174RF-001CPR) 4500177571 ||E [S?]|| IT EV1527; TODO herausfinden: Alarmierung (wie Alarmton getriggered werden kann); Batterieinfo? || IT || 3<br />
|-<br />
|Smartwares SH5-TSO-A||E S|| || IT || ?<br />
|-<br />
|X10 Security Devices||E|| || || 39<br />
|-<br />
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43<br />
|}<br />
Bei einigen Intertechno-Funksteckdosen (Brennenstuhl) kann es zu Empfangsproblemen kommen. Hier muss die Taktrate, mit der gesendet wird, angepasst werden. Dazu muss für ''Funksteckdose'' (also sauber per-Client-Instanz-spezifisch, NICHT SIGNALduino-Transceiver-global) das Attribut <br />
:<code>attr <Funksteckdose> ITclock 300</code> <br />
gesetzt werden, der Standardwert ist 250.<br />
<br />
==== Mein Gerät wird in FHEM nicht erkannt ====<br />
1. Prüfen, ob vom Sensor die Signaldaten (verbose >=4) erkannt werden. Sobald ihr die empfangenen Signaldaten im Logfile zuordnen könnt, geht es weiter mit:<br />
<br />
2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues/new?template=sensor---device-feature.md github]:<br />
<!-- <syntaxhighlight lang="md"> ... markdown lexer not yet available; use pre instead --><br />
<pre><br />
## Specifications for new sensor / switch / or other device ... <br />
<br />
- manufacturer:<br />
- model name:<br />
- pictures of the device / the board (very helpful)<br />
<br />
<br />
## Specifications <br />
<br />
- Microcontroller:<br />
- Version (Firmware):<br />
<br />
<!-- ( can be found here devicename -> Internals -> version ) --><br />
- Versionmodul (FHEM Module):<br />
</pre><br />
<br />
3. Auszug aus dem Logfile, welches zum Gerät gehört.<br />
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.''<br />
<br />
Im Forum solltet ihr solche Fragen besser nicht posten, wenn das Gerät noch nicht unterstützt wird, dazu ist Github besser geeignet. Inzwischen wurde im Wiki eine eigene Seite eröffnet, die sich mit der Erkennung unbekannter Protokolle beschäftigt: [[Unbekannte_Funkprotokolle#Ansatz_1_-_Versuchen|Unbekannte_Funkprotokolle]].<br />
<br />
==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ====<br />
Im SIGNALduino sind >70 Protokolle implementiert. Jedoch gibt es nicht immer ein logisches Module, welche diese Protokolle verarbeiten.<br />
Teilweise ist das auch nicht zwingend notwendig, um seine Anforderungen zu erfüllen. Insbesondere für Schalter bzw. Sensoren, die nur zwei Zustände kennen, geht es meist ohne Modul und automatisch angelegtem Gerät.<br />
<br />
Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden.<br />
Im FHEM Log (und, insbesondere, im FHEMWEB Event Monitor) tauchen Meldungen ähnlich dieser auf<br />
<br />
<code><br />
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081<br />
</code><br />
<br />
Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:<br />
<br />
Entweder, wenn wir den Inhalt der Nachricht nur zu Teilen wissen, da er sich ändert:<br />
<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)<br />
attr mydoif do always<br />
</code><br />
<br />
Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring<br />
<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on)<br />
attr mydoif do always<br />
</code><br />
<br />
Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.<br />
<br />
Als Alternative zu DOIF hier ein regex-verwendendes notify-Beispiel für einen Sender, der meint, zwei Codes alternierend senden zu müssen:<br />
<br />
<code><br />
define n_sender_trigger notify sduino:UNKNOWNCODE.*u41#(13B72253|163873B3) { my_sender_trigger_indicate();; }<br />
</code><br />
<br />
Selbstverständlich muss in diesem Moment auch eine sub my_sender_trigger_indicate() definiert werden (z.B. in FHEM/99_myUtils.pm), die dort z.B. als Test eine Log-Ausgabe (Log3()) machen kann.<br />
<br />
=== Das Logfile ===<br />
Im Logfile ab [[Verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (verbose 3 unterdrückt diese Meldungen).<br />
<br />
UPDATE: der folgende Bereich ist von einem weniger erfahrenen Zeitgenossen früher nach Kräften erweitert/geschrieben worden. Mittlerweile existiert aber ein neuer Inhalt [[Unbekannte_Funkprotokolle]] (siehe auch Erwähnung weiter oben), der als sehr gut beschrieben und unvergleichlich detailreicher bezeichnet werden muss ("endlich gibt es sowas!"). Der Bereich hier dürfte somit zwar für grundlegende Verdeutlichungen noch recht sinnvoll sein, der Inhalt sollte allerdings evt. in eine konsistente Dokumentation überarbeitet (verlagert/dedupliziert/reduziert) werden.<br />
<br />
Die Protokolle (von der SIGNALDuino-Firmware gesendete Signal-Beschreibungs-Strings) können wie folgt unterschieden werden:<br />
<br />
*MS - Nachricht mit Sync Puls: Hierzu ein Beispiel<br />
:<code>MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;</code> P0-P6 sind die Signalpegel (Dauer und positiv/negativ). Hinter D= befindet sich die Abfolge der Signale. Die ersten beiden Ziffern 15 in D sind wie folgt zu lesen. Zuerst wurde ein Signal "1" also P1 mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal "5" also P5 mit 8916 Mikrosekunden low (die Zeitdauer ergibt sich aufgrund der Mitteilung "P5=-8916") gemessen. CP=1 ist die Referenz auf den Takt des Signales - der Basistakt ist in diesem Fall ~395 Mikrosekunden. SP=5 gibt die Referenz zum Syncpuls an, der das gesamte Signal einleitet. Welche Signalfolge nun eine binäre 1 bzw. 0 bedeutet, wird im SIGNALduino über die integrierte Protokoll Liste realisiert.<br />
<br />
*MC - Nachricht vom Typ Manchester: Manchesterkodierte Signale können bereits sehr einfach im Arduino in eine Binärform umgewandelt werden. Es wird hier nach IEEE 802.3 umgewandelt. In Manchester Signalen gibt es lange und kurze Pulse. Deren Durchschnittswert wird mit LL (long low), LH (long high), SL (short low) und SH (short high) übermittelt. Zusätzlich, um das Protokoll schneller erkennen zu können, wird die Taktfrequenz mit übermittelt (C=429 Mikrosekunden). Die Daten befinden sich hinter D= und werden in HEX Form übergeben.<br />
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code><br />
<br />
*MU - Message unsynced: Diese Art von Nachrichten sind nicht nach Manchester codiert und haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht. Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist. Wie bei MS sind P0-P6 die Signalpegel und in D= wird die Abfolge der Signalpegel referenziert. CP=2 gibt auch hier die Referenz zum Takt an, allerdings muss dieser nicht korrekt erkannt worden sein.<br />
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code><br />
<br />
Es erscheinen viele Meldungen dieser Art:<br />
<br />
<pre><br />
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate<br />
</pre><br />
<br />
Dies sind nun Bemühungen, anhand der von der SIGNALDuino-Firmware gelieferten rohen aber detaillierten Signal-Strings eine Vor-Analyse / Fingerprinting vorzunehmen.<br />
Man könnte nun z.B. bei solchen Fingerprinting-Analysen erkennen:<br />
* dass der Basis-Takt-Wert innerhalb eines charakteristischen Zeit-Bereichs liegt<br />
* dass die Anzahl der Sync-Pulse eine präzise Zahl ist<br />
* dass Längen erkannter Puls-Typen innerhalb eines Bereichs liegen<br />
<br />
Mittels solcher Untersuchungen kann man also final hoffentlich hinreichend plausibel feststellen, "dass diese Aktivitäten offensichtlich(?) zu einer Funk-Komponente Rauchmelder von Hersteller XYZ gehören müssen, und man somit weiterleiten muss an ein (möglicherweise bereits existierendes) Userdaten-Dekodier-Modul für diese Herstellerkomponente".<br />
<br />
<br />
Bei einer dann erfolgenden Demodulation des noch rohen SIGNALDuino-Strings könnte man z.B. (hoffentlich richtigerweise) annehmen, dass eine Signalpegel-Typ-Folge "13" eine binäre 1 bedeuten soll, während eine Folge "12" eine binäre 0 bedeuten soll. Man erhält aus dem Gesamt-Puls-String also nach vollständiger Demodulation eine Abfolge von vielen 0/1 Bits, die insgesamt ein Datenwort darstellen, mit einer gewissen Länge von NN bits (diese Längen-Angabe könnte übrigens - neben Namenssuche nach Hersteller oder Produkt etc. - ein wichtiges Such-Merkmal sein, ob andere Frameworks tatsächlich bereits wissen, wie Daten dieser Funk-Komponente zu dekodieren sind!). Dieses demodulierte Datenwort ist nun das finale Datenwort, welches einen Container für die Funk-Komponenten-Informationen darstellt (in diesem Container also beispielsweise enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Container erst einmal CRC- oder Crypto-verschlüsselt ist...).<br />
<br />
Man muss an dieser Stelle unbedingt sagen, dass dieses Userdaten-Datenwort (einer bestimmten Hersteller-Funk-Komponente!) natürlich bei ''jeglichen'' Transceiver-Systemen ''immer'' gleich (identisch) erkannt werden ''muss'' - an dieser Stelle ist also ganz klar, dass diese Daten an ''allgemeine'' FHEM-Module weitergeleitet (Dispatched) werden müssen, die nach Übernahme von Daten von ''jeglichen'' Transceiver-Systemen diese Daten immer auf die gleiche Weise ('''''generisch/zentral''''') für die jeweilige Hersteller-Funk-Komponente erledigen.<br />
<br />
'''Die Abfolge ist also ganz klar:'''<br />
Funk-Aktivität --> Transceiver-Gerät/Firmware (SIGNALDuino) --> maximal detailreich beschreibender Rx-Analyse-Output-String --> Fingerprinting-Grobzuordnung des (SIGNALDuino-Firmware-)Outputs (durch 00_SIGNALduino.pm) auf gerätespezifisches Verhalten --> ''generische/zentrale'' Dekodierung des gerätespezifischen Protokoll-Datenworts, in zentralen Grundsatz-Modulen wie z.B. <code>14_SD_WS.pm</code>).<br />
<br />
Und wenn dann bei einer solchen Schritte-Abfolge irgendetwas noch fehlen/unpassend sein sollte, dann muss eben entsprechendes Development an gewissen Stellen erfolgen ;-)<br />
<br />
====Minimieren (whitelist/blacklist) von unerwünschter Kommunikations-Aktivität/Einträgen====<br />
<br />
"Unknown Code" bedeutet, dass der SIGNALduino Signaldaten empfangen und diese binär interpretiert hat. Diese Meldung soll uns nun aber mitteilen, dass es dann nicht weiter verarbeitet werden kann, da kein Modul existiert (oder kein Weiterleitungs-Dispatch zu einem bereits existierenden), welches diese Daten jetzt in ihre Bedeutung umwandeln kann. <br />
:<code>sduino: Unknown code u1FFFFF0, help me!</code><br />
<br />
Außerdem kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:<br />
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code><br />
<br />
Mittlerweile sind über 50 Protokolle für den SIGNALduino definiert. Dadurch kommt es vor, dass sich ein Signal mit mehr als einem Protokoll demodulieren lässt. Meist führt dies dann zu zusätzlichen "Unknown code"-Einträgen.<br />
<br />
Derartige Einträge können mit dem Attribut WhitelistID minimiert werden. Dabei werden die Geräte, die nach Daten-Empfang tatsächlich verarbeitet werden sollen (also welche Protokolle vom FHEM Modul berücksichtigt werden), mit ihrer Protokollnummer in die WhitelistID aufgenommen.<br />
Für Protokolle, die nicht berücksichtigt werden, gibt es weder Logeinträge noch Events. Diese werden im Programmablauf nicht berücksichtigt. Das spart zum einen Ressourcen und trägt auch zur Übersichtlichkeit bei. <br />
Die Protokollnummer kann Tabelle [[#Unterst.C3.BCtzte_Ger.C3.A4te|Unterstützte Geräte]] entnommen werden (hilfreich ist es auch, wenn in den verwendeten Geräten im Internal <gerätename>_DMSG nachgesehen wird). So bedeutet beispielsweise ein Eintrag der Form <code>W50#FF553335FFBC</code> dass dann das Protokoll #50 in die Whitelist aufzunehmen wäre (<code>attr sduino whitelist_IDs 50</code>).<br />
{{Randnotiz|RNTyp=r|RNText=Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!!<br />
}}<br />
Die Angabe erfolgt durch Komma getrennt: z.B.:<br />
:<code>1,2,5,10</code><br />
<br />
=== Senden mit dem SIGNALduino ===<br />
Der SIGNALduino kann etwas "raw senden", indem ihm das SIGNAL so übermittelt wird, wie er es moduliert. Hierzu muss der Befehl wie folgt eingegeben werden:<br />
<br />
<code><br />
set sduino sendMsg P3#00111010#R4<br />
</code><br />
<br />
Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.<br />
Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits.<br />
<code><br />
sduino: extracted data 00111010 (bin)<br />
sduino: Found Protocol id 3 <br />
</code><br />
<br />
Alternativ kann das Signal auch in einer "rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig:<br />
<code><br />
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;<br />
</code><br />
<br />
R=3 bedeutet, das Signal wird 3x gesendet.<br />
Die Übertragung besteht aus den in D angegeben Pulsen, welche in P0-P5 definiert werden.<br />
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.<br />
<br />
Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.<br />
<br />
====Fehlersuche====<br />
(Zielgerät reagiert nicht, etc.)<br />
<br />
* Nachrichtenwiederholungsanzahl muss evt. für manche Geräte entsprechend groß eingestellt sein<br />
{{Randnotiz|RNTyp=r|RNText=VORSICHT blöder Schreibweisen-Mismatch ITClock vs. ITclock!!}}<br />
* Sende-Takt-Wert (Clock) passt evt. nicht ganz, siehe z.B. Thread-Antwort {{Link2Forum|Topic=58397|Message=775434|LinkText=Signalduino Version 3.3.1}}, wo für IT-Geräte ein Attribut anhand der CP= des Empfangsdaten-Logs modifiziert wird. ACHTUNG: dies kann entweder global das Internal-Attribut ITClock eines SIGNALduino-Transceiver-Devices sein, oder (viel besser da korrekt geräte-instanz-spezifische Konfiguration) das ITclock eines IT-Client-Devices.<br />
<br />
== Fehlerbehandlung ==<br />
<br />
=== Modul-Initialisierung ===<br />
<br />
==== Perl-Modul Digest::CRC fehlt ====<br />
<br />
Das FHEM-Log kann (bei neueren SIGNALduino-Modulen?) folgendes enthalten:<br />
<br />
<code>Can't locate Digest/CRC.pm in @INC (you may need to install the Digest::CRC module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib /opt/fhem . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870.<br />
BEGIN failed--compilation aborted at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870.</code><br />
<br />
In diesem Fall ist der Transceiver nicht funktionsfähig - es muss erst Perl-Modul Digest::CRC (Ubuntu: package <code>libdigest-crc-perl</code>) installiert werden und fhem neu gestartet werden.<br />
<br />
=== Konfiguration von Firmware/Hardware (Reset usw.) ===<br />
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:<br />
:<code>set raw e</code><br />
Ob ein solcher Reset nötig ist, erkennt man an dem Inhalt vom Reading <code>cc1101_config</code>, dort unsinnige Werte angezeigt werden oder dem Reading <code>config</code> welches durch den Befehl "get config" aktualisiert wird, was im Standard auf "MS=1;MU=1;MC=1" entspricht.<br />
<br />
In der Firmware sind die diverse Befehle eingebaut, welche über einen <code>set raw</code> Befehl im Modul direkt ausgeführt werden können. Sofern möglich, sollten die Abfrage von Werten aus dem Modul allerdings mit den dafür vorgesehenen Kommandos erfolgen, da die Rückmeldungen des <code>set raw</code> Befehls nur im Logfile ab Verbose 4 erscheinen. Die Befehle sind nützlich, wenn direkt auf den Microcontroller zugegriffen wird: <br />
<br />
:<code>C<reg></code> <reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers. Example: <code>set raw C35</code> führt ab Verbose 4 zu einer Logausgabe folgender Art <code>Read, msg: C35 = 0D</code><br />
:<code>e</code> EEPROM / factory reset. resets all eeprom values without reboot<br />
:<code>W<AA><XX></code> Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die eeprom Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2 des CC1101)<br />
<br />
Die Sendeleistung lässt sich mit <br />
:<code>get sduino ccpatable</code> <br />
<br />
prüfen, wobei die Rückmeldung wie folgt zu lesen ist: <br />
"-10_dBm" => '34',<br />
"-5_dBm" => '68',<br />
"0_dBm" => '60',<br />
"5_dBm" => '84',<br />
"7_dBm" => 'C8',<br />
"10_dBm" => 'C0' <br />
Dabei wird die Sendeleistung dauerhaft mit dem Befehl<br />
:<code>set sduino cc1101_patable <value></code><br />
hochgeschaltet (<value> durch den Wert ersetzen).<br />
<br />
Weitere Firmware-Befehle sind im Thread-Beitrag {{Link2Forum|Topic=58396|Message=497921}} zu finden.<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=82379|Message=1033374|LinkText=SIGNALDuino Schaltplan}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.rflink.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]]<br />
* [[Somfy via SIGNALduino]]<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=CUL&diff=35956CUL2021-08-15T14:42:21Z<p>AndreasMohr: /* Harter Lockup des CUL */ Referenziere externe Issue</p>
<hr />
<div>Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8&nbsp;bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433&nbsp;MHz sind weitere Protokolle zugänglich, z.&nbsp;B. Intertechno, viele Baumarkt-Funksteckdosen. <br />
<br />
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.<br />
<br />
Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1&nbsp;kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.<br />
<br />
Das CUL kann mittels des CULModuls von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.<br />
<br />
Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version&#160;3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}<br />
<br />
Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z.&nbsp;B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.<br />
<br />
Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.<br />
<br />
Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.<br />
<br />
Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.<br />
<br />
Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen. <br />
<br />
* Ist Empfang eingeschaltet ?<br />
*: <code> get myCUL raw C35</code> (13 = ja, z.&nbsp;b.: C35 = 0D / 13)<br />
* Auslesen der culfw Version:<br />
*: <code>get myCUL raw V</code><br />
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)<br />
*: <code>set myCUL raw l00</code><br />
* LED einschalten<br />
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen<br />
* LED soll blinken (einmal in der Sekunde)<br />
*: <code>set myCUL raw l02</code><br />
* Reboot / Reset des CUL:<br />
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=&gt; neue Firmware)<br />
* Freie CUL Sendezeit ([[1% Regel]]):<br />
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots<br />
* Freie Kapazität des FHT Buffers<br />
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a<br />
* Inhalt des FHT Buffers<br />
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes gross, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer<br />
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]<br />
*: <code> get myCUL raw T01</code> <br />
* Eingestellte Frequenz, Bandbreite etc. Ausgeben<br />
*: <code> get myCUL ccconf</code>. <br>Rückgabe z.&nbsp;B.: <br><code><nowiki>myCUL ccconf =&gt; freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code><br />
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):<br />
*:<code>set myCUL bWidth 464</code><br />
* Einstellen der Sendestärke:<br />
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.<br />
<br />
Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen<br />
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. <br />
<br />
Werte x00-x04 sind '''mit''' Ramping (''sanften'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z.&nbsp;B. [[RFR CUL]], da die CULs Rampingsingnale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl). <br />
<br />
'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).<br />
<br />
Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit&#160;:<br />
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt<br />
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet<br />
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet<br />
* <code>set CUL1 raw X80</code> RSSI / Signalstaerke jeder Flanke wird gemeldet<br />
* <code>set CUL1 raw X21</code> normal Modus<br />
<br />
Achtung: Auf Gross- und Kleinschreibung des "x,X" achten!<br />
<br />
Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.<br />
<br />
== Versionen ==<br />
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.<br />
<br />
* CUL V1 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.<br />
* CUL V2 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.<br />
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kByte EEPROM). Voll einsatzfähig.<br />
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM 32 kB Flashmemory, 1 kByte EEPROM. Voll einsatzfähig. Genau genommen ein "Sparmodell" des V3, um Lieferengpässe des atmega32u4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.<br />
<br />
Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.<br />
<br />
== Firmware {{Anker|FW}} ==<br />
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der<br />
* [http://culfw.de CUL Firmware Homepage]<br />
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.<br />
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der<br />
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]<br />
Hier kann man sich z.B. mit<br />
<syntaxhighlight lang="bash"><br />
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw<br />
</syntaxhighlight><br />
die aktuelle Version laden.<br />
<br />
Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:<br />
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.<br />
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.<br />
<br />
Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).<br />
<br />
Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.<br />
<br />
== Sendefrequenz ==<br />
Das CUL gibt es in Ausführungen für 868 und 433 MHz. <br />
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.<br />
<br />
Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.<br />
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.<br />
<br />
== Antenne ==<br />
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.<br />
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.<br />
<br />
Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik. <br />
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.<br />
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.<br />
<br />
Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne. <br />
<br />
Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene. <br />
<br />
Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.<br />
<br />
Weitere Informationen sind im Antennenthread des Forums zu finden: [https://forum.fhem.de/index.php/topic,93021.0.html Link]<br />
<br />
Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar ("Lambda") lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").<br />
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.<br />
<br />
Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser. <br />
<br />
Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.<br />
<br />
Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4&nbsp;GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.<br />
<br />
== Antennenlänge ==<br />
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch eine Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.<br />
<br />
Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:<br />
868,35 MHz (z.B. HM, FS20, FHT …)<br />
1/4 Lambda = 8,63 Zentimeter <br />
1/2 Lambda = 17,26 Zentimeter <br />
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)<br />
<br />
433,92 MHz (z.B. Intertechno …)<br />
1/4 Lambda = 17,27 Zentimeter <br />
1/2 Lambda = 34,54 Zentimeter <br />
<br />
Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:<br />
<br />
8,6 Zentimeter als 1/4 Lambda für 868,35 MHz<br />
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz<br />
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz<br />
<br />
== Bekannte Probleme ==<br />
<br />
=== RF-Tuning ===<br />
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z.&nbsp;B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern z.&nbsp;B. der FHT Raumregler zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.<br />
<br />
Bei Empfangsproblemen von z.&nbsp;B. HEM-Sensoren oder dem S300TH kann man folgendes testen:<br />
<br />
* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.<br />
*: <code>set CUL freq 868.350</code><br />
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.<br />
*: <code>set CUL sens 8</code><br />
* Oft hilft auch, die Bandbreite auf z.&nbsp;B. 464 kHz aufzuweiten.<br />
*: <code>set CUL bWidth 464</code><br />
<br />
=== Übertragungs-Stall nach zu vielen Einträgen in der Queue ===<br />
<br />
Ich habe mich ewig damit rumgeärgert, dass die Übertragung zu bestimmten häufig angesprochenen Geräten zusammenbrach, sobald die Queue zu lang wurde (FHEM: 'list CUL').<br />
Irgendwann habe ich dann zufällig herausgefunden, dass dieses sehr fragwürdige Anwachsen der Queue an einer krassen [[Sendpool]]-Fehlkonfiguration lag: ich hatte dort ein Transceiver-Device mit angegeben, welches den [[Sendpool]]-Mechanismus (noch) gar nicht unterstützt!<br />
Sobald ich dieses falsche Gerät aus der Sendpool-Element-Liste entfernt hatte, war Ruhe --> BUG im Modul (es kann nicht sein, dass ein Device ohne [[Sendpool]]-Support das Queue-Handling so zerschießt). Dieser Bug existiert allerdings wohl weiterhin (das Perl-Handling war mir etwas zu verwirrend, um direkt zu sehen, wo das Problem ist) --> sollte nachgestellt und gefixt werden.<br />
<br />
=== Harter Lockup des CUL ===<br />
<br />
Trotz behobenem (erkanntem) Queue-Problem gibt es weiterhin Probleme ("Problem #2"): es passiert - recht selten -, dass sich der nanoCUL komplett aufhängt, mit hektisch blinkender LED.<br />
Es ist in diesem Fall noch nicht einmal mit dem Reset-Taster möglich, den Stick zu resetten - es ist also tatsächlich nötig, das USB-Kabel komplett zu ziehen. Wenigstens automatisieren lassen würde sich dieser Workaround wohl per uhubctl ([https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux]).<br />
Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.<br />
<br />
Device-Attribute wie version etc. könnten evt. den Zeitpunkt der letzten Aktivität verdeutlichen; dann im FHEM-Log um diesen Zeitpunkt herum suchen, um Auffälligkeiten/Spezialitäten zu erkennen. Und dann muss man, wenn man Pech hat, eine custom culfw bauen, die entsprechendes Reporting mit eingebaut hat...<br />
<br />
(nanoCUL; V 1.26.00 a-culfw Build: 267).<br />
<br />
UPDATE: die Lösung des Problems steht evt. im Forum (Lockup beseitigt durch Optiboot bootloader): [https://forum.fhem.de/index.php/topic,73144.msg977406.html?PHPSESSID=2lj93g4vn277qhm2bfpvfpgntr#msg977406 {Gelöst} Nanocul LED blinkt schnell].<br />
[https://www.ebay.de/itm/1-3-mal-Flash-Service-fur-ZigBee-nanoCUL-JeeLink-Shelly-Sonoff-Blitzwolf-Gosund/264472055531] scheint das zu bestätigen:<br />
"Weiterhin bieten wir beim nanoCUL an, einen alternativen Bootloader (Optiboot Bootloader) zu flashen.<br />
Dieser verhindert das Abstürzen des nanoCUL's im Betrieb z.B. bei FHEM. (Stichwort: opened)"<br />
<br />
Ein weiterer Bericht über CUL-Lockups (dort reproduzierbar/deterministisch, und Regression-Bug): [https://github.com/heliflieger/a-culfw/issues/23 Selfmade Cul freezing with blinking LED when sending ITv3 messages #23]<br />
<br />
Evt. ist auch ein USB-Port-Reset ein funktionierender Workaround (bitte Text als bestätigt umformulieren, falls das hilft): [https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html], erwähnt von [https://forum.fhem.de/index.php/topic,77380.msg783352.html#msg783352].<br />
<br />
== Selbstbau-/Bastelprojekte ==<br />
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:<br />
* [[Selbstbau CUL]]<br />
* [[FHEMduino]]<br />
* [[SIGNALduino]]<br />
* [[MapleCUN]] mit STM32 Mikrocontroller<br />
<br />
== Links ==<br />
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]<br />
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im [http://forum.fhem.de/index.php FHEM Forum] ergänzt/ersetzt<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:CUL|!]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Unbekannte_Funkprotokolle&diff=35955Unbekannte Funkprotokolle2021-08-15T14:17:49Z<p>AndreasMohr: /* SIGNALduino - OOK */</p>
<hr />
<div>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?<br />
<br />
Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.<br />
<br />
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>, vielleicht via BenutzerSeite (oder natürlich einfach direkt verbessern) - die Usability dieses Projekts sollte sehr gut werden...<br />
<br />
Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:<br />
<br />
Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).<br />
<br />
== Basics ==<br />
<br />
==== Hardware ====<br />
<br />
Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink. <br />
<br />
Diese unterscheiden sich in verschiedener Hinsicht:<br />
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]<br />
* Modulationsverfahren (OOK, ASK/FSK)<br />
* Frequenzband (433 MHz, 868 MHz)<br />
<br />
(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 Support für SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)<br />
<br />
==== Frequenzbereich ====<br />
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.<br />
<br />
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.<br />
<br />
==== Modulationsverfahren ====<br />
<br />
So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren. <br />
<br />
* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]<br />
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln. <br />
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]<br />
: 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]).<br />
<br />
==== Encoding oder auch Leitungscode ====<br />
<br />
Die Art und Weise wie dieses Signal interpretiert wird, hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.<br />
<br />
* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]<br />
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]<br />
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]<br />
<br />
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 <br />
* 100 (short high, long low) wird als 0<br />
* 110 (long high, short low) wird als 1<br />
interpretiert.<br />
<br />
Im FHEM-Forum gibt es viele freundliche Helfer, die Euch bei Bedarf den richtigen Weg weisen.<br />
<br />
==== Signalstruktur ====<br />
<br />
Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus<br />
<br />
| Pause | Sync | Pause | Daten |<br />
<br />
* eine größere Pause zur Trennung der Sequenzen <br />
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt<br />
* eine Pause um Sync und Daten zu trennen<br />
* die eigentlichen, zu übertragenden Daten.<br />
<br />
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]).<br />
<br />
Die Sequenz wird ggf. mehrfach wiederholt <br />
<br />
| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...<br />
<br />
==== Protokoll ====<br />
<br />
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). <br />
<br />
Mit etwas Glück erkennt z.B. SIGNALduino bereits 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.").<br />
<br />
== Wie fange ich an? ==<br />
<br />
==== Recherche ====<br />
<br />
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.<br />
<br />
Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:<br />
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]<br />
<br />
Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.<br />
<br />
==== Ansatz 1 - Versuchen ====<br />
<br />
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.<br />
<br />
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).<br />
<br />
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]]). <br />
<br />
Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.<br />
<br />
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<br />
* 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)<br />
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)<br />
<br />
==== Ansatz 2 - Aufschrauben ====<br />
<br />
Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.<br />
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.<br />
<br />
Das Teil ist zu klein? Folgende Möglichkeiten:<br />
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann<br />
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt<br />
<br />
Danach folgt dann Internet-Suchmaschine und das Studium der zugehörigen Data Sheets der Chips.<br />
<br />
Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen welche diese Chips unterstützen.<br />
<br />
Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen<br />
* OOK-Modulation -> [[SIGNALduino]]<br />
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]<br />
<br />
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 (Frequenzteiler, ...) im Datenblatt des daneben verbauten Chips lässt sich dann die tatsächliche Sende- bzw. Empfangsfrequenz errechnen.<br />
<br />
==== Ansatz 3 - Messen ====<br />
<br />
Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze. <br />
<br />
* 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.<br />
* 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 Internet-Suchmaschine-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].<br />
* 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.<br />
<br />
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.<br />
<br />
Die Spektrumanalyse gibt Aufschluss über<br />
* das Modulationsverfahren (OOK vs. FSK) sowie<br />
* die relevante(n) Frequenz(en)<br />
<br />
== SIGNALduino - OOK ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.<br />
<br />
==== Log-Meldungen ====<br />
<br />
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.<br />
<br />
Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.<br />
<br />
<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code><br />
<br />
Was bedeutet D=012323...?<br />
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause<br />
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal<br />
: 2 -> P2=-398 => 398 Mikrosekunden Pause<br />
: 3 -> P3=415 => 415 Mikrosekunden Signal<br />
: 2 -> P2=-398 => 398 Mikrosekunden Pause<br />
: 3 -> P3=415 => 415 Mikrosekunden Signal<br />
: ...<br />
<br />
<br />
Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:<br />
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:<br />
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:<br />
* Log-Zeitstempelmäßig genau erkennbar ist<br />
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage<br />
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.<br />
<br />
==== Frequenz ermitteln ====<br />
<br />
Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.<br />
<br />
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 <code>get ccconf</code>. 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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Eingrenzung - Selektiver Empfang ====<br />
<br />
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.<br />
<br />
Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.<br />
<br />
Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.<br />
<br />
==== Eingrenzung - Log-Analyse via regex ====<br />
<br />
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:<br />
z.B.:<br />
<br />
<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code><br />
<br />
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:<br />
<br />
<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code><br />
<br />
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.<br />
<br />
==== Variationen ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Signal analysieren ====<br />
<br />
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).<br />
<br />
Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.<br />
<br />
Gehen wir wieder von unserem Beispiel aus:<br />
<br />
<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code><br />
<br />
Wie ist diese Sequenz zu interpretieren?<br />
<br />
Anhand der anfänglich gelisteten Puls-Beschreibungen Px= (Aktiv-Indikator/Dauer):<br />
<br />
* Es startet mit einer Pause D='''0'''123232323232<br />
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms (15916 µs).<br />
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.<br />
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265<br />
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....<br />
<br />
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 Aktiv-Indikator (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.<br />
<br />
Beispiel: Den Vorspann<br />
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> (bestehend aus Puls-Beschreibungen und initialer Puls-Aktivität) lassen wir mal außen vor und konzentrieren uns auf den nachfolgenden echten Nutz-Daten-Teil (hinsichtlich dessen logischer Protokoll-Umformung hin zur finalen Nutz-Datenwort-Sequenz):<br />
<br />
<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626 (rohe Abfolge der Puls-Typen)<br />
<br />
lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL (als sSlL-Notation)<br />
<br />
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 (als Bitfolge)<br />
<br />
10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100 (Gruppierung auf Bit-Datenworte)<br />
<br />
AD99 79A2 9FBC B7FC (als Hex-Datenworte)</code><br />
<br />
Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)<br />
* 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"...<br />
* 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)<br />
<br />
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.<br />
<br />
Weitere wichtige Tips:<br />
* 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<br />
* 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<br />
* 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 <code>reload 00_SIGNALduino</code> gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!! - hoher Platzbedarf...) Attribute verbose 5 und debug 1 setzen!)<br />
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen<br />
* 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<br />
* 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:<br />
<code>define sduino_dummy SIGNALduino none</code><br />
<br />
In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:<br />
<br />
<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code><br />
<br />
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.<br />
<br />
Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.<br />
<br />
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.<br />
<br />
==== Steuern ====<br />
<br />
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].<br />
<br />
==== Signal-Protokoll-Beschreibung verfeinern ====<br />
<br />
Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:<br />
<br />
Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:<br />
<br />
wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann<br />
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:<br />
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung<br />
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen<br />
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.<br />
<br />
Daher sollte man folgendes beachten:<br />
* 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)<br />
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)<br />
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln<br />
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))<br />
<br />
Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:<br />
* einige Geräte-Pattern aus dem Log fischen<br />
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)<br />
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht<br />
* 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<br />
* evt. ist es auch hilfreich, den im Gerät verbauten Quarz 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:<br />
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code><br />
); 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ß...)<br />
<br />
==== Development / patch submission ====<br />
<br />
Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:<br />
* Änderungen durchführen (im korrekten Branch)<br />
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!<br />
* alles committen<br />
* 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<br />
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig<br />
* 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.<br />
<br />
== SIGNALduino - FSK ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt. <br />
<br />
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)<br />
<br />
Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].<br />
<br />
=== FSK Senden ===<br />
<br />
Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:<br />
000 = 2-FSK<br />
001 = GFSK<br />
011 = ASK/OOK<br />
100 = 4-FSK<br />
<br />
Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über <br />
<code>get <mysduino> ccreg 99</code><br />
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.<br />
Das Register wird über <br />
<code>set <mysduino> raw W1410</code><br />
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).<br />
<br />
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.<br />
<br />
=== Sendefrequenz und Frequenzhub ===<br />
<br />
<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div><br />
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div><br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Ermittlung der Frequenzen ===<br />
<br />
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 vorgegebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnt Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.<br />
<br />
=== Hub ===<br />
<br />
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 <br />
<code>set <mysduino> raw W1740</code><br />
an den CC1101 des SDUINO übermittelt wird.<br />
<br />
Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.<br />
<br />
<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div><br />
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div><br />
<div style="clear:both"></div><br />
<br />
=== Baudrate ===<br />
<br />
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 eine Fülle weiterer Optionen (Sync, FIFO etc.), die aber eher für Spezialisten geeignet sind.<br />
<br />
Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:<br />
FHEM <-> Arduino <-> CC1101 <-> Sendesignal<br />
<br />
Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels <code>get <myduino> ccconf</code> ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.<br />
<br />
Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittelt und einem Parameter ('''P'''uls?) 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.<br />
<br />
<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div><br />
<div style="clear:both"></div><br />
<br />
Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.<br />
<br />
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 reale Darstellung zu kommen, gebe ich 402 Samples/Symbol (Symbol=bit) ein.<br />
<br />
Das Ergebnis:<br />
<br />
<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div><br />
<div style="clear:both"></div><br />
<br />
=== Codesequenzen ===<br />
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 anders 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. <br />
<br />
Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.<br />
<br />
=== Konfiguration ===<br />
<br />
Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12<br />
<br />
Register-Settings:<br />
<br />
* Trägerfrequenz: 868.302 MHz<br />
* Deviation: 25 kHz<br />
* Bandwidth: 58 kHz<br />
* Baudrate: 24.795 kBaud<br />
* Modulation: GFSK<br />
<br />
<pre>ccregAll: <br />
<br />
ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F<br />
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B<br />
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B <br />
<br />
Configuration Register Detail (address, name, value):<br />
0x00 IOCFG2 - 0x0D<br />
0x01 IOCFG1 - 0x2E<br />
0x02 IOCFG0 - 0x2D<br />
0x03 FIFOTHR - 0x47<br />
0x04 SYNC1 - 0xD3<br />
0x05 SYNC0 - 0x91<br />
0x06 PKTLEN - 0x3D<br />
0x07 PKTCTRL1 - 0x04<br />
0x08 PKTCTRL0 - 0x32<br />
0x09 ADDR - 0x00<br />
0x0A CHANNR - 0x00<br />
0x0B FSCTRL1 - 0x06<br />
0x0C FSCTRL0 - 0x00<br />
0x0D FREQ2 - 0x21<br />
0x0E FREQ1 - 0x65<br />
0x0F FREQ0 - 0x6F<br />
0x10 MDMCFG4 - 0xF9<br />
0x11 MDMCFG3 - 0xF4<br />
0x12 MDMCFG2 - 0x18<br />
0x13 MDMCFG1 - 0x23<br />
0x14 MDMCFG0 - 0xB9<br />
0x15 DEVIATN - 0x40<br />
0x16 MCSM2 - 0x07<br />
0x17 MCSM1 - 0x00<br />
0x18 MCSM0 - 0x18<br />
0x19 FOCCFG - 0x14<br />
0x1A BSCFG - 0x6C<br />
0x1B AGCCTRL2 - 0x07<br />
0x1C AGCCTRL1 - 0x00<br />
0x1D AGCCTRL0 - 0x91<br />
0x1E WOREVT1 - 0x87<br />
0x1F WOREVT0 - 0x6B<br />
0x20 WORCTRL - 0xF8<br />
0x21 FREND1 - 0x56<br />
0x22 FREND0 - 0x11<br />
0x23 FSCAL3 - 0xEF<br />
0x24 FSCAL2 - 0x2D<br />
0x25 FSCAL1 - 0x12<br />
0x26 FSCAL0 - 0x1F<br />
0x27 RCCTRL1 - 0x41<br />
0x28 RCCTRL0 - 0x00<br />
0x29 FSTEST - 0x59<br />
0x2A PTEST - 0x7F<br />
0x2B AGCTEST - 0x3F<br />
0x2C TEST2 - 0x88<br />
0x2D TEST1 - 0x31<br />
0x2E TEST0 - 0x0B<br />
</pre><br />
<br />
=== Finale ===<br />
<br />
Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.<br />
<br />
Der SIGNALduino erkennt <br />
<pre><br />
2020.01.12 14:33:03 4: mySIGNALduino: Parse_MS, Decoded matched MS Protocol id 88 dmsg P88#74D21B18008B48058 length 68 RSSI = -32<br />
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, test ungleich: disabled<br />
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, -32 dB, dispatch<br />
2020.01.12 14:33:03 5: mySIGNALduino: dispatch P88#74D21B18008B48058<br />
2020.01.12 14:33:04 2: mySIGNALduino: SD_Keeloq_Parse Unknown device unknown with Code 012D100 detected, please define (rawdate=74D21B18008B48058)<br />
2020.01.12 14:33:04 2: autocreate: define SD_Keeloq_012D100 SD_Keeloq 012D100<br />
2020.01.12 14:33:04 2: autocreate: define FileLog_SD_Keeloq_012D100 FileLog ./log/SD_Keeloq_012D100-%Y.log SD_Keeloq_012D100<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 91.1 -> Atlantic security<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=2 reconstructed, last bit=0<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 87 -> JAROLIFT<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=1 reconstructed, last bit=1<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 88 -> HCS300/HCS301<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2<br />
</pre><br />
und routet die Requests 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.<br />
<br />
Mittlerweile ist das Protokoll als '''model enjoy_motors_HS''' in das Modul '''SD_Keeloq''' aufgenommen.<br />
<br />
== CUL - FSK und Co. ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt. <br />
<br />
Es befindet sich aber noch im Aufbau....<br />
<br />
== FAQ ==<br />
<br />
=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===<br />
<br />
Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.<br />
<br />
Die Bestimmung short High / Low erfolgt einfach dadurch, ob gesendet wird oder ob gerade eine Pause eingelegt wird.<br />
<br />
Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.<br />
<br />
Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.<br />
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.<br />
<br />
Beispiel einer empfangenen Sequenz<br />
<br />
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code><br />
<br />
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.<br />
<br />
Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.<br />
<br />
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.<br />
<br />
Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).<br />
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.<br />
<br />
== Links ==<br />
<br />
* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)<br />
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]<br />
* [https://github.com/jopohl/urh Universal Radio Hacker]<br />
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]<br />
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]<br />
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]<br />
* [[Intertechno Code Berechnung]]<br />
* [[Funksignalanalyse mit DVB-T Stick]]<br />
<br />
[[Kategorie:Intertechno]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Unbekannte_Funkprotokolle&diff=35954Unbekannte Funkprotokolle2021-08-15T14:10:43Z<p>AndreasMohr: /* Ansatz 2 - Aufschrauben */</p>
<hr />
<div>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?<br />
<br />
Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.<br />
<br />
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>, vielleicht via BenutzerSeite (oder natürlich einfach direkt verbessern) - die Usability dieses Projekts sollte sehr gut werden...<br />
<br />
Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:<br />
<br />
Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).<br />
<br />
== Basics ==<br />
<br />
==== Hardware ====<br />
<br />
Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink. <br />
<br />
Diese unterscheiden sich in verschiedener Hinsicht:<br />
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]<br />
* Modulationsverfahren (OOK, ASK/FSK)<br />
* Frequenzband (433 MHz, 868 MHz)<br />
<br />
(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 Support für SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)<br />
<br />
==== Frequenzbereich ====<br />
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.<br />
<br />
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.<br />
<br />
==== Modulationsverfahren ====<br />
<br />
So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren. <br />
<br />
* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]<br />
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln. <br />
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]<br />
: 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]).<br />
<br />
==== Encoding oder auch Leitungscode ====<br />
<br />
Die Art und Weise wie dieses Signal interpretiert wird, hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.<br />
<br />
* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]<br />
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]<br />
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]<br />
<br />
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 <br />
* 100 (short high, long low) wird als 0<br />
* 110 (long high, short low) wird als 1<br />
interpretiert.<br />
<br />
Im FHEM-Forum gibt es viele freundliche Helfer, die Euch bei Bedarf den richtigen Weg weisen.<br />
<br />
==== Signalstruktur ====<br />
<br />
Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus<br />
<br />
| Pause | Sync | Pause | Daten |<br />
<br />
* eine größere Pause zur Trennung der Sequenzen <br />
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt<br />
* eine Pause um Sync und Daten zu trennen<br />
* die eigentlichen, zu übertragenden Daten.<br />
<br />
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]).<br />
<br />
Die Sequenz wird ggf. mehrfach wiederholt <br />
<br />
| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...<br />
<br />
==== Protokoll ====<br />
<br />
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). <br />
<br />
Mit etwas Glück erkennt z.B. SIGNALduino bereits 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.").<br />
<br />
== Wie fange ich an? ==<br />
<br />
==== Recherche ====<br />
<br />
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.<br />
<br />
Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:<br />
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]<br />
<br />
Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.<br />
<br />
==== Ansatz 1 - Versuchen ====<br />
<br />
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.<br />
<br />
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).<br />
<br />
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]]). <br />
<br />
Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.<br />
<br />
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<br />
* 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)<br />
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)<br />
<br />
==== Ansatz 2 - Aufschrauben ====<br />
<br />
Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.<br />
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.<br />
<br />
Das Teil ist zu klein? Folgende Möglichkeiten:<br />
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann<br />
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt<br />
<br />
Danach folgt dann Internet-Suchmaschine und das Studium der zugehörigen Data Sheets der Chips.<br />
<br />
Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen welche diese Chips unterstützen.<br />
<br />
Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen<br />
* OOK-Modulation -> [[SIGNALduino]]<br />
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]<br />
<br />
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 (Frequenzteiler, ...) im Datenblatt des daneben verbauten Chips lässt sich dann die tatsächliche Sende- bzw. Empfangsfrequenz errechnen.<br />
<br />
==== Ansatz 3 - Messen ====<br />
<br />
Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze. <br />
<br />
* 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.<br />
* 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 Internet-Suchmaschine-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].<br />
* 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.<br />
<br />
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.<br />
<br />
Die Spektrumanalyse gibt Aufschluss über<br />
* das Modulationsverfahren (OOK vs. FSK) sowie<br />
* die relevante(n) Frequenz(en)<br />
<br />
== SIGNALduino - OOK ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.<br />
<br />
==== Log-Meldungen ====<br />
<br />
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.<br />
<br />
Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.<br />
<br />
<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code><br />
<br />
Was bedeutet D=012323...?<br />
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause<br />
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal<br />
: 2 -> P2=-398 => 398 Mikrosekunden Pause<br />
: 3 -> P3=415 => 415 Mikrosekunden Signal<br />
: 2 -> P2=-398 => 398 Mikrosekunden Pause<br />
: 3 -> P3=415 => 415 Mikrosekunden Signal<br />
: ...<br />
<br />
<br />
Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:<br />
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:<br />
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:<br />
* Log-Zeitstempelmäßig genau erkennbar ist<br />
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage<br />
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.<br />
<br />
==== Frequenz ermitteln ====<br />
<br />
Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.<br />
<br />
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 <code>get ccconf</code>. 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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Eingrenzung - Selektiver Empfang ====<br />
<br />
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.<br />
<br />
Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.<br />
<br />
Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.<br />
<br />
==== Eingrenzung - Log-Analyse via regex ====<br />
<br />
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:<br />
z.B.:<br />
<br />
<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code><br />
<br />
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:<br />
<br />
<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code><br />
<br />
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.<br />
<br />
==== Variationen ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Signal analysieren ====<br />
<br />
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).<br />
<br />
Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.<br />
<br />
Gehen wir wieder von unserem Beispiel aus:<br />
<br />
<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code><br />
<br />
Wie ist diese Sequenz zu interpretieren?<br />
<br />
Anhand der anfänglich gelisteten Puls-Beschreibungen Px= (Vorzeichen/Dauer):<br />
<br />
* Es startet mit einer Pause D='''0'''123232323232<br />
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.<br />
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.<br />
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265<br />
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....<br />
<br />
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.<br />
<br />
Beispiel: Den Vorspann<br />
<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 den Daten-Teil (hinsichtlich dessen logischer Protokoll-Umformung hin zur finalen Nutz-Datenwort-Sequenz):<br />
<br />
<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626 (rohe Abfolge der Puls-Typen)<br />
<br />
lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL (als sSlL-Notation)<br />
<br />
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 (als Bitfolge)<br />
<br />
10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100 (Gruppierung auf Bit-Datenworte)<br />
<br />
AD99 79A2 9FBC B7FC (als Hex-Datenworte)</code><br />
<br />
Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)<br />
* 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"...<br />
* 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)<br />
<br />
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.<br />
<br />
Weitere wichtige Tips:<br />
* 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<br />
* 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<br />
* 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 <code>reload 00_SIGNALduino</code> gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!! - hoher Platzbedarf...) Attribute verbose 5 und debug 1 setzen!)<br />
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen<br />
* 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<br />
* 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:<br />
<code>define sduino_dummy SIGNALduino none</code><br />
<br />
In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:<br />
<br />
<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code><br />
<br />
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.<br />
<br />
Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.<br />
<br />
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.<br />
<br />
==== Steuern ====<br />
<br />
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].<br />
<br />
==== Signal-Protokoll-Beschreibung verfeinern ====<br />
<br />
Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:<br />
<br />
Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:<br />
<br />
wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann<br />
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:<br />
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung<br />
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen<br />
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.<br />
<br />
Daher sollte man folgendes beachten:<br />
* 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)<br />
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)<br />
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln<br />
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))<br />
<br />
Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:<br />
* einige Geräte-Pattern aus dem Log fischen<br />
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)<br />
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht<br />
* 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<br />
* evt. ist es auch hilfreich, den im Gerät verbauten Quarz 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:<br />
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code><br />
); 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ß...)<br />
<br />
==== Development / patch submission ====<br />
<br />
Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:<br />
* Änderungen durchführen (im korrekten Branch)<br />
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!<br />
* alles committen<br />
* 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<br />
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig<br />
* 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.<br />
<br />
== SIGNALduino - FSK ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt. <br />
<br />
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)<br />
<br />
Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].<br />
<br />
=== FSK Senden ===<br />
<br />
Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:<br />
000 = 2-FSK<br />
001 = GFSK<br />
011 = ASK/OOK<br />
100 = 4-FSK<br />
<br />
Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über <br />
<code>get <mysduino> ccreg 99</code><br />
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.<br />
Das Register wird über <br />
<code>set <mysduino> raw W1410</code><br />
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).<br />
<br />
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.<br />
<br />
=== Sendefrequenz und Frequenzhub ===<br />
<br />
<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div><br />
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div><br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Ermittlung der Frequenzen ===<br />
<br />
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 vorgegebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnt Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.<br />
<br />
=== Hub ===<br />
<br />
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 <br />
<code>set <mysduino> raw W1740</code><br />
an den CC1101 des SDUINO übermittelt wird.<br />
<br />
Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.<br />
<br />
<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div><br />
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div><br />
<div style="clear:both"></div><br />
<br />
=== Baudrate ===<br />
<br />
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 eine Fülle weiterer Optionen (Sync, FIFO etc.), die aber eher für Spezialisten geeignet sind.<br />
<br />
Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:<br />
FHEM <-> Arduino <-> CC1101 <-> Sendesignal<br />
<br />
Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels <code>get <myduino> ccconf</code> ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.<br />
<br />
Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittelt und einem Parameter ('''P'''uls?) 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.<br />
<br />
<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div><br />
<div style="clear:both"></div><br />
<br />
Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.<br />
<br />
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 reale Darstellung zu kommen, gebe ich 402 Samples/Symbol (Symbol=bit) ein.<br />
<br />
Das Ergebnis:<br />
<br />
<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div><br />
<div style="clear:both"></div><br />
<br />
=== Codesequenzen ===<br />
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 anders 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. <br />
<br />
Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.<br />
<br />
=== Konfiguration ===<br />
<br />
Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12<br />
<br />
Register-Settings:<br />
<br />
* Trägerfrequenz: 868.302 MHz<br />
* Deviation: 25 kHz<br />
* Bandwidth: 58 kHz<br />
* Baudrate: 24.795 kBaud<br />
* Modulation: GFSK<br />
<br />
<pre>ccregAll: <br />
<br />
ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F<br />
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B<br />
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B <br />
<br />
Configuration Register Detail (address, name, value):<br />
0x00 IOCFG2 - 0x0D<br />
0x01 IOCFG1 - 0x2E<br />
0x02 IOCFG0 - 0x2D<br />
0x03 FIFOTHR - 0x47<br />
0x04 SYNC1 - 0xD3<br />
0x05 SYNC0 - 0x91<br />
0x06 PKTLEN - 0x3D<br />
0x07 PKTCTRL1 - 0x04<br />
0x08 PKTCTRL0 - 0x32<br />
0x09 ADDR - 0x00<br />
0x0A CHANNR - 0x00<br />
0x0B FSCTRL1 - 0x06<br />
0x0C FSCTRL0 - 0x00<br />
0x0D FREQ2 - 0x21<br />
0x0E FREQ1 - 0x65<br />
0x0F FREQ0 - 0x6F<br />
0x10 MDMCFG4 - 0xF9<br />
0x11 MDMCFG3 - 0xF4<br />
0x12 MDMCFG2 - 0x18<br />
0x13 MDMCFG1 - 0x23<br />
0x14 MDMCFG0 - 0xB9<br />
0x15 DEVIATN - 0x40<br />
0x16 MCSM2 - 0x07<br />
0x17 MCSM1 - 0x00<br />
0x18 MCSM0 - 0x18<br />
0x19 FOCCFG - 0x14<br />
0x1A BSCFG - 0x6C<br />
0x1B AGCCTRL2 - 0x07<br />
0x1C AGCCTRL1 - 0x00<br />
0x1D AGCCTRL0 - 0x91<br />
0x1E WOREVT1 - 0x87<br />
0x1F WOREVT0 - 0x6B<br />
0x20 WORCTRL - 0xF8<br />
0x21 FREND1 - 0x56<br />
0x22 FREND0 - 0x11<br />
0x23 FSCAL3 - 0xEF<br />
0x24 FSCAL2 - 0x2D<br />
0x25 FSCAL1 - 0x12<br />
0x26 FSCAL0 - 0x1F<br />
0x27 RCCTRL1 - 0x41<br />
0x28 RCCTRL0 - 0x00<br />
0x29 FSTEST - 0x59<br />
0x2A PTEST - 0x7F<br />
0x2B AGCTEST - 0x3F<br />
0x2C TEST2 - 0x88<br />
0x2D TEST1 - 0x31<br />
0x2E TEST0 - 0x0B<br />
</pre><br />
<br />
=== Finale ===<br />
<br />
Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.<br />
<br />
Der SIGNALduino erkennt <br />
<pre><br />
2020.01.12 14:33:03 4: mySIGNALduino: Parse_MS, Decoded matched MS Protocol id 88 dmsg P88#74D21B18008B48058 length 68 RSSI = -32<br />
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, test ungleich: disabled<br />
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, -32 dB, dispatch<br />
2020.01.12 14:33:03 5: mySIGNALduino: dispatch P88#74D21B18008B48058<br />
2020.01.12 14:33:04 2: mySIGNALduino: SD_Keeloq_Parse Unknown device unknown with Code 012D100 detected, please define (rawdate=74D21B18008B48058)<br />
2020.01.12 14:33:04 2: autocreate: define SD_Keeloq_012D100 SD_Keeloq 012D100<br />
2020.01.12 14:33:04 2: autocreate: define FileLog_SD_Keeloq_012D100 FileLog ./log/SD_Keeloq_012D100-%Y.log SD_Keeloq_012D100<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 91.1 -> Atlantic security<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=2 reconstructed, last bit=0<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 87 -> JAROLIFT<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=1 reconstructed, last bit=1<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 88 -> HCS300/HCS301<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2<br />
</pre><br />
und routet die Requests 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.<br />
<br />
Mittlerweile ist das Protokoll als '''model enjoy_motors_HS''' in das Modul '''SD_Keeloq''' aufgenommen.<br />
<br />
== CUL - FSK und Co. ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt. <br />
<br />
Es befindet sich aber noch im Aufbau....<br />
<br />
== FAQ ==<br />
<br />
=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===<br />
<br />
Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.<br />
<br />
Die Bestimmung short High / Low erfolgt einfach dadurch, ob gesendet wird oder ob gerade eine Pause eingelegt wird.<br />
<br />
Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.<br />
<br />
Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.<br />
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.<br />
<br />
Beispiel einer empfangenen Sequenz<br />
<br />
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code><br />
<br />
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.<br />
<br />
Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.<br />
<br />
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.<br />
<br />
Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).<br />
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.<br />
<br />
== Links ==<br />
<br />
* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)<br />
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]<br />
* [https://github.com/jopohl/urh Universal Radio Hacker]<br />
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]<br />
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]<br />
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]<br />
* [[Intertechno Code Berechnung]]<br />
* [[Funksignalanalyse mit DVB-T Stick]]<br />
<br />
[[Kategorie:Intertechno]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Unbekannte_Funkprotokolle&diff=35953Unbekannte Funkprotokolle2021-08-15T14:06:29Z<p>AndreasMohr: "Friends don't let friends use Google." :(</p>
<hr />
<div>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?<br />
<br />
Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.<br />
<br />
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>, vielleicht via BenutzerSeite (oder natürlich einfach direkt verbessern) - die Usability dieses Projekts sollte sehr gut werden...<br />
<br />
Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:<br />
<br />
Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).<br />
<br />
== Basics ==<br />
<br />
==== Hardware ====<br />
<br />
Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink. <br />
<br />
Diese unterscheiden sich in verschiedener Hinsicht:<br />
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]<br />
* Modulationsverfahren (OOK, ASK/FSK)<br />
* Frequenzband (433 MHz, 868 MHz)<br />
<br />
(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 Support für SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)<br />
<br />
==== Frequenzbereich ====<br />
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.<br />
<br />
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.<br />
<br />
==== Modulationsverfahren ====<br />
<br />
So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren. <br />
<br />
* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]<br />
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln. <br />
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]<br />
: 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]).<br />
<br />
==== Encoding oder auch Leitungscode ====<br />
<br />
Die Art und Weise wie dieses Signal interpretiert wird, hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.<br />
<br />
* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]<br />
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]<br />
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]<br />
<br />
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 <br />
* 100 (short high, long low) wird als 0<br />
* 110 (long high, short low) wird als 1<br />
interpretiert.<br />
<br />
Im FHEM-Forum gibt es viele freundliche Helfer, die Euch bei Bedarf den richtigen Weg weisen.<br />
<br />
==== Signalstruktur ====<br />
<br />
Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus<br />
<br />
| Pause | Sync | Pause | Daten |<br />
<br />
* eine größere Pause zur Trennung der Sequenzen <br />
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt<br />
* eine Pause um Sync und Daten zu trennen<br />
* die eigentlichen, zu übertragenden Daten.<br />
<br />
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]).<br />
<br />
Die Sequenz wird ggf. mehrfach wiederholt <br />
<br />
| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...<br />
<br />
==== Protokoll ====<br />
<br />
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). <br />
<br />
Mit etwas Glück erkennt z.B. SIGNALduino bereits 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.").<br />
<br />
== Wie fange ich an? ==<br />
<br />
==== Recherche ====<br />
<br />
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.<br />
<br />
Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:<br />
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]<br />
<br />
Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.<br />
<br />
==== Ansatz 1 - Versuchen ====<br />
<br />
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.<br />
<br />
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).<br />
<br />
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]]). <br />
<br />
Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.<br />
<br />
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<br />
* 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)<br />
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)<br />
<br />
==== Ansatz 2 - Aufschrauben ====<br />
<br />
Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.<br />
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.<br />
<br />
Das Teil ist zu klein? Folgende Möglichkeiten:<br />
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann<br />
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt<br />
<br />
Danach folgt dann Internet-Suchmaschine und das Studium der zugehörigen Data Sheets der Chips.<br />
<br />
Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen welche diese Chips unterstützen.<br />
<br />
Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen<br />
* OOK-Modulation -> [[SIGNALduino]]<br />
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]<br />
<br />
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.<br />
<br />
==== Ansatz 3 - Messen ====<br />
<br />
Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze. <br />
<br />
* 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.<br />
* 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 Internet-Suchmaschine-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].<br />
* 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.<br />
<br />
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.<br />
<br />
Die Spektrumanalyse gibt Aufschluss über<br />
* das Modulationsverfahren (OOK vs. FSK) sowie<br />
* die relevante(n) Frequenz(en)<br />
<br />
== SIGNALduino - OOK ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.<br />
<br />
==== Log-Meldungen ====<br />
<br />
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.<br />
<br />
Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.<br />
<br />
<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code><br />
<br />
Was bedeutet D=012323...?<br />
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause<br />
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal<br />
: 2 -> P2=-398 => 398 Mikrosekunden Pause<br />
: 3 -> P3=415 => 415 Mikrosekunden Signal<br />
: 2 -> P2=-398 => 398 Mikrosekunden Pause<br />
: 3 -> P3=415 => 415 Mikrosekunden Signal<br />
: ...<br />
<br />
<br />
Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:<br />
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:<br />
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:<br />
* Log-Zeitstempelmäßig genau erkennbar ist<br />
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage<br />
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.<br />
<br />
==== Frequenz ermitteln ====<br />
<br />
Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.<br />
<br />
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 <code>get ccconf</code>. 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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Eingrenzung - Selektiver Empfang ====<br />
<br />
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.<br />
<br />
Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.<br />
<br />
Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.<br />
<br />
==== Eingrenzung - Log-Analyse via regex ====<br />
<br />
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:<br />
z.B.:<br />
<br />
<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code><br />
<br />
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:<br />
<br />
<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code><br />
<br />
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.<br />
<br />
==== Variationen ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Signal analysieren ====<br />
<br />
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).<br />
<br />
Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.<br />
<br />
Gehen wir wieder von unserem Beispiel aus:<br />
<br />
<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code><br />
<br />
Wie ist diese Sequenz zu interpretieren?<br />
<br />
Anhand der anfänglich gelisteten Puls-Beschreibungen Px= (Vorzeichen/Dauer):<br />
<br />
* Es startet mit einer Pause D='''0'''123232323232<br />
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.<br />
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.<br />
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265<br />
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....<br />
<br />
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.<br />
<br />
Beispiel: Den Vorspann<br />
<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 den Daten-Teil (hinsichtlich dessen logischer Protokoll-Umformung hin zur finalen Nutz-Datenwort-Sequenz):<br />
<br />
<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626 (rohe Abfolge der Puls-Typen)<br />
<br />
lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL (als sSlL-Notation)<br />
<br />
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 (als Bitfolge)<br />
<br />
10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100 (Gruppierung auf Bit-Datenworte)<br />
<br />
AD99 79A2 9FBC B7FC (als Hex-Datenworte)</code><br />
<br />
Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)<br />
* 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"...<br />
* 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)<br />
<br />
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.<br />
<br />
Weitere wichtige Tips:<br />
* 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<br />
* 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<br />
* 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 <code>reload 00_SIGNALduino</code> gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!! - hoher Platzbedarf...) Attribute verbose 5 und debug 1 setzen!)<br />
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen<br />
* 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<br />
* 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:<br />
<code>define sduino_dummy SIGNALduino none</code><br />
<br />
In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:<br />
<br />
<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code><br />
<br />
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.<br />
<br />
Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.<br />
<br />
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.<br />
<br />
==== Steuern ====<br />
<br />
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].<br />
<br />
==== Signal-Protokoll-Beschreibung verfeinern ====<br />
<br />
Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:<br />
<br />
Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:<br />
<br />
wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann<br />
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:<br />
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung<br />
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen<br />
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.<br />
<br />
Daher sollte man folgendes beachten:<br />
* 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)<br />
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)<br />
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln<br />
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))<br />
<br />
Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:<br />
* einige Geräte-Pattern aus dem Log fischen<br />
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)<br />
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht<br />
* 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<br />
* evt. ist es auch hilfreich, den im Gerät verbauten Quarz 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:<br />
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code><br />
); 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ß...)<br />
<br />
==== Development / patch submission ====<br />
<br />
Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:<br />
* Änderungen durchführen (im korrekten Branch)<br />
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!<br />
* alles committen<br />
* 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<br />
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig<br />
* 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.<br />
<br />
== SIGNALduino - FSK ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt. <br />
<br />
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)<br />
<br />
Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].<br />
<br />
=== FSK Senden ===<br />
<br />
Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:<br />
000 = 2-FSK<br />
001 = GFSK<br />
011 = ASK/OOK<br />
100 = 4-FSK<br />
<br />
Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über <br />
<code>get <mysduino> ccreg 99</code><br />
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.<br />
Das Register wird über <br />
<code>set <mysduino> raw W1410</code><br />
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).<br />
<br />
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.<br />
<br />
=== Sendefrequenz und Frequenzhub ===<br />
<br />
<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div><br />
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div><br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Ermittlung der Frequenzen ===<br />
<br />
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 vorgegebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnt Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.<br />
<br />
=== Hub ===<br />
<br />
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 <br />
<code>set <mysduino> raw W1740</code><br />
an den CC1101 des SDUINO übermittelt wird.<br />
<br />
Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.<br />
<br />
<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div><br />
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div><br />
<div style="clear:both"></div><br />
<br />
=== Baudrate ===<br />
<br />
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 eine Fülle weiterer Optionen (Sync, FIFO etc.), die aber eher für Spezialisten geeignet sind.<br />
<br />
Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:<br />
FHEM <-> Arduino <-> CC1101 <-> Sendesignal<br />
<br />
Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels <code>get <myduino> ccconf</code> ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.<br />
<br />
Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittelt und einem Parameter ('''P'''uls?) 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.<br />
<br />
<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div><br />
<div style="clear:both"></div><br />
<br />
Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.<br />
<br />
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 reale Darstellung zu kommen, gebe ich 402 Samples/Symbol (Symbol=bit) ein.<br />
<br />
Das Ergebnis:<br />
<br />
<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div><br />
<div style="clear:both"></div><br />
<br />
=== Codesequenzen ===<br />
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 anders 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. <br />
<br />
Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.<br />
<br />
=== Konfiguration ===<br />
<br />
Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12<br />
<br />
Register-Settings:<br />
<br />
* Trägerfrequenz: 868.302 MHz<br />
* Deviation: 25 kHz<br />
* Bandwidth: 58 kHz<br />
* Baudrate: 24.795 kBaud<br />
* Modulation: GFSK<br />
<br />
<pre>ccregAll: <br />
<br />
ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F<br />
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B<br />
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B <br />
<br />
Configuration Register Detail (address, name, value):<br />
0x00 IOCFG2 - 0x0D<br />
0x01 IOCFG1 - 0x2E<br />
0x02 IOCFG0 - 0x2D<br />
0x03 FIFOTHR - 0x47<br />
0x04 SYNC1 - 0xD3<br />
0x05 SYNC0 - 0x91<br />
0x06 PKTLEN - 0x3D<br />
0x07 PKTCTRL1 - 0x04<br />
0x08 PKTCTRL0 - 0x32<br />
0x09 ADDR - 0x00<br />
0x0A CHANNR - 0x00<br />
0x0B FSCTRL1 - 0x06<br />
0x0C FSCTRL0 - 0x00<br />
0x0D FREQ2 - 0x21<br />
0x0E FREQ1 - 0x65<br />
0x0F FREQ0 - 0x6F<br />
0x10 MDMCFG4 - 0xF9<br />
0x11 MDMCFG3 - 0xF4<br />
0x12 MDMCFG2 - 0x18<br />
0x13 MDMCFG1 - 0x23<br />
0x14 MDMCFG0 - 0xB9<br />
0x15 DEVIATN - 0x40<br />
0x16 MCSM2 - 0x07<br />
0x17 MCSM1 - 0x00<br />
0x18 MCSM0 - 0x18<br />
0x19 FOCCFG - 0x14<br />
0x1A BSCFG - 0x6C<br />
0x1B AGCCTRL2 - 0x07<br />
0x1C AGCCTRL1 - 0x00<br />
0x1D AGCCTRL0 - 0x91<br />
0x1E WOREVT1 - 0x87<br />
0x1F WOREVT0 - 0x6B<br />
0x20 WORCTRL - 0xF8<br />
0x21 FREND1 - 0x56<br />
0x22 FREND0 - 0x11<br />
0x23 FSCAL3 - 0xEF<br />
0x24 FSCAL2 - 0x2D<br />
0x25 FSCAL1 - 0x12<br />
0x26 FSCAL0 - 0x1F<br />
0x27 RCCTRL1 - 0x41<br />
0x28 RCCTRL0 - 0x00<br />
0x29 FSTEST - 0x59<br />
0x2A PTEST - 0x7F<br />
0x2B AGCTEST - 0x3F<br />
0x2C TEST2 - 0x88<br />
0x2D TEST1 - 0x31<br />
0x2E TEST0 - 0x0B<br />
</pre><br />
<br />
=== Finale ===<br />
<br />
Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.<br />
<br />
Der SIGNALduino erkennt <br />
<pre><br />
2020.01.12 14:33:03 4: mySIGNALduino: Parse_MS, Decoded matched MS Protocol id 88 dmsg P88#74D21B18008B48058 length 68 RSSI = -32<br />
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, test ungleich: disabled<br />
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, -32 dB, dispatch<br />
2020.01.12 14:33:03 5: mySIGNALduino: dispatch P88#74D21B18008B48058<br />
2020.01.12 14:33:04 2: mySIGNALduino: SD_Keeloq_Parse Unknown device unknown with Code 012D100 detected, please define (rawdate=74D21B18008B48058)<br />
2020.01.12 14:33:04 2: autocreate: define SD_Keeloq_012D100 SD_Keeloq 012D100<br />
2020.01.12 14:33:04 2: autocreate: define FileLog_SD_Keeloq_012D100 FileLog ./log/SD_Keeloq_012D100-%Y.log SD_Keeloq_012D100<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 91.1 -> Atlantic security<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=2 reconstructed, last bit=0<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 87 -> JAROLIFT<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=1 reconstructed, last bit=1<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 88 -> HCS300/HCS301<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2<br />
</pre><br />
und routet die Requests 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.<br />
<br />
Mittlerweile ist das Protokoll als '''model enjoy_motors_HS''' in das Modul '''SD_Keeloq''' aufgenommen.<br />
<br />
== CUL - FSK und Co. ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt. <br />
<br />
Es befindet sich aber noch im Aufbau....<br />
<br />
== FAQ ==<br />
<br />
=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===<br />
<br />
Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.<br />
<br />
Die Bestimmung short High / Low erfolgt einfach dadurch, ob gesendet wird oder ob gerade eine Pause eingelegt wird.<br />
<br />
Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.<br />
<br />
Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.<br />
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.<br />
<br />
Beispiel einer empfangenen Sequenz<br />
<br />
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code><br />
<br />
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.<br />
<br />
Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.<br />
<br />
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.<br />
<br />
Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).<br />
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.<br />
<br />
== Links ==<br />
<br />
* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)<br />
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]<br />
* [https://github.com/jopohl/urh Universal Radio Hacker]<br />
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]<br />
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]<br />
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]<br />
* [[Intertechno Code Berechnung]]<br />
* [[Funksignalanalyse mit DVB-T Stick]]<br />
<br />
[[Kategorie:Intertechno]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Unbekannte_Funkprotokolle&diff=35952Unbekannte Funkprotokolle2021-08-15T14:04:48Z<p>AndreasMohr: Verbesserungen (Analyse-Beschreibung, Code-Block etc.)</p>
<hr />
<div>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?<br />
<br />
Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.<br />
<br />
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>, vielleicht via BenutzerSeite (oder natürlich einfach direkt verbessern) - die Usability dieses Projekts sollte sehr gut werden...<br />
<br />
Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:<br />
<br />
Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).<br />
<br />
== Basics ==<br />
<br />
==== Hardware ====<br />
<br />
Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink. <br />
<br />
Diese unterscheiden sich in verschiedener Hinsicht:<br />
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]<br />
* Modulationsverfahren (OOK, ASK/FSK)<br />
* Frequenzband (433 MHz, 868 MHz)<br />
<br />
(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 Support für SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)<br />
<br />
==== Frequenzbereich ====<br />
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.<br />
<br />
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.<br />
<br />
==== Modulationsverfahren ====<br />
<br />
So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren. <br />
<br />
* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]<br />
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln. <br />
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]<br />
: 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]).<br />
<br />
==== Encoding oder auch Leitungscode ====<br />
<br />
Die Art und Weise wie dieses Signal interpretiert wird, hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.<br />
<br />
* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]<br />
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]<br />
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]<br />
<br />
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 <br />
* 100 (short high, long low) wird als 0<br />
* 110 (long high, short low) wird als 1<br />
interpretiert.<br />
<br />
Im FHEM-Forum gibt es viele freundliche Helfer, die Euch bei Bedarf den richtigen Weg weisen.<br />
<br />
==== Signalstruktur ====<br />
<br />
Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus<br />
<br />
| Pause | Sync | Pause | Daten |<br />
<br />
* eine größere Pause zur Trennung der Sequenzen <br />
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt<br />
* eine Pause um Sync und Daten zu trennen<br />
* die eigentlichen, zu übertragenden Daten.<br />
<br />
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]).<br />
<br />
Die Sequenz wird ggf. mehrfach wiederholt <br />
<br />
| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...<br />
<br />
==== Protokoll ====<br />
<br />
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). <br />
<br />
Mit etwas Glück erkennt z.B. SIGNALduino bereits 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.").<br />
<br />
== Wie fange ich an? ==<br />
<br />
==== Recherche ====<br />
<br />
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.<br />
<br />
Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:<br />
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]<br />
<br />
Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.<br />
<br />
==== Ansatz 1 - Versuchen ====<br />
<br />
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.<br />
<br />
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).<br />
<br />
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]]). <br />
<br />
Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.<br />
<br />
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<br />
* 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)<br />
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)<br />
<br />
==== Ansatz 2 - Aufschrauben ====<br />
<br />
Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.<br />
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.<br />
<br />
Das Teil ist zu klein? Folgende Möglichkeiten:<br />
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann<br />
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt<br />
<br />
Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.<br />
<br />
Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen welche diese Chips unterstützen.<br />
<br />
Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen<br />
* OOK-Modulation -> [[SIGNALduino]]<br />
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]<br />
<br />
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.<br />
<br />
==== Ansatz 3 - Messen ====<br />
<br />
Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze. <br />
<br />
* 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.<br />
* 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].<br />
* 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.<br />
<br />
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.<br />
<br />
Die Spektrumanalyse gibt Aufschluss über<br />
* das Modulationsverfahren (OOK vs. FSK) sowie<br />
* die relevante(n) Frequenz(en)<br />
<br />
== SIGNALduino - OOK ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.<br />
<br />
==== Log-Meldungen ====<br />
<br />
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.<br />
<br />
Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.<br />
<br />
<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code><br />
<br />
Was bedeutet D=012323...?<br />
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause<br />
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal<br />
: 2 -> P2=-398 => 398 Mikrosekunden Pause<br />
: 3 -> P3=415 => 415 Mikrosekunden Signal<br />
: 2 -> P2=-398 => 398 Mikrosekunden Pause<br />
: 3 -> P3=415 => 415 Mikrosekunden Signal<br />
: ...<br />
<br />
<br />
Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:<br />
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:<br />
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:<br />
* Log-Zeitstempelmäßig genau erkennbar ist<br />
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage<br />
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.<br />
<br />
==== Frequenz ermitteln ====<br />
<br />
Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.<br />
<br />
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 <code>get ccconf</code>. 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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Eingrenzung - Selektiver Empfang ====<br />
<br />
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.<br />
<br />
Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.<br />
<br />
Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.<br />
<br />
==== Eingrenzung - Log-Analyse via regex ====<br />
<br />
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:<br />
z.B.:<br />
<br />
<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code><br />
<br />
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:<br />
<br />
<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code><br />
<br />
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.<br />
<br />
==== Variationen ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Signal analysieren ====<br />
<br />
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).<br />
<br />
Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.<br />
<br />
Gehen wir wieder von unserem Beispiel aus:<br />
<br />
<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code><br />
<br />
Wie ist diese Sequenz zu interpretieren?<br />
<br />
Anhand der anfänglich gelisteten Puls-Beschreibungen Px= (Vorzeichen/Dauer):<br />
<br />
* Es startet mit einer Pause D='''0'''123232323232<br />
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.<br />
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.<br />
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265<br />
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....<br />
<br />
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.<br />
<br />
Beispiel: Den Vorspann<br />
<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 den Daten-Teil (hinsichtlich dessen logischer Protokoll-Umformung hin zur finalen Nutz-Datenwort-Sequenz):<br />
<br />
<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626 (rohe Abfolge der Puls-Typen)<br />
<br />
lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL (als sSlL-Notation)<br />
<br />
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 (als Bitfolge)<br />
<br />
10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100 (Gruppierung auf Bit-Datenworte)<br />
<br />
AD99 79A2 9FBC B7FC (als Hex-Datenworte)</code><br />
<br />
Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)<br />
* 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"...<br />
* 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)<br />
<br />
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.<br />
<br />
Weitere wichtige Tips:<br />
* 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<br />
* 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<br />
* 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 <code>reload 00_SIGNALduino</code> gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!! - hoher Platzbedarf...) Attribute verbose 5 und debug 1 setzen!)<br />
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen<br />
* 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<br />
* 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:<br />
<code>define sduino_dummy SIGNALduino none</code><br />
<br />
In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:<br />
<br />
<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code><br />
<br />
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.<br />
<br />
Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.<br />
<br />
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.<br />
<br />
==== Steuern ====<br />
<br />
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].<br />
<br />
==== Signal-Protokoll-Beschreibung verfeinern ====<br />
<br />
Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:<br />
<br />
Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:<br />
<br />
wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann<br />
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:<br />
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung<br />
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen<br />
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.<br />
<br />
Daher sollte man folgendes beachten:<br />
* 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)<br />
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)<br />
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln<br />
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))<br />
<br />
Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:<br />
* einige Geräte-Pattern aus dem Log fischen<br />
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)<br />
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht<br />
* 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<br />
* evt. ist es auch hilfreich, den im Gerät verbauten Quarz 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:<br />
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code><br />
); 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ß...)<br />
<br />
==== Development / patch submission ====<br />
<br />
Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:<br />
* Änderungen durchführen (im korrekten Branch)<br />
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!<br />
* alles committen<br />
* 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<br />
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig<br />
* 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.<br />
<br />
== SIGNALduino - FSK ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt. <br />
<br />
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)<br />
<br />
Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].<br />
<br />
=== FSK Senden ===<br />
<br />
Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:<br />
000 = 2-FSK<br />
001 = GFSK<br />
011 = ASK/OOK<br />
100 = 4-FSK<br />
<br />
Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über <br />
<code>get <mysduino> ccreg 99</code><br />
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.<br />
Das Register wird über <br />
<code>set <mysduino> raw W1410</code><br />
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).<br />
<br />
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.<br />
<br />
=== Sendefrequenz und Frequenzhub ===<br />
<br />
<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div><br />
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div><br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Ermittlung der Frequenzen ===<br />
<br />
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 vorgegebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnt Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.<br />
<br />
=== Hub ===<br />
<br />
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 <br />
<code>set <mysduino> raw W1740</code><br />
an den CC1101 des SDUINO übermittelt wird.<br />
<br />
Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.<br />
<br />
<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div><br />
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div><br />
<div style="clear:both"></div><br />
<br />
=== Baudrate ===<br />
<br />
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 eine Fülle weiterer Optionen (Sync, FIFO etc.), die aber eher für Spezialisten geeignet sind.<br />
<br />
Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:<br />
FHEM <-> Arduino <-> CC1101 <-> Sendesignal<br />
<br />
Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels <code>get <myduino> ccconf</code> ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.<br />
<br />
Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittelt und einem Parameter ('''P'''uls?) 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.<br />
<br />
<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div><br />
<div style="clear:both"></div><br />
<br />
Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.<br />
<br />
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 reale Darstellung zu kommen, gebe ich 402 Samples/Symbol (Symbol=bit) ein.<br />
<br />
Das Ergebnis:<br />
<br />
<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div><br />
<div style="clear:both"></div><br />
<br />
=== Codesequenzen ===<br />
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 anders 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. <br />
<br />
Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.<br />
<br />
=== Konfiguration ===<br />
<br />
Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12<br />
<br />
Register-Settings:<br />
<br />
* Trägerfrequenz: 868.302 MHz<br />
* Deviation: 25 kHz<br />
* Bandwidth: 58 kHz<br />
* Baudrate: 24.795 kBaud<br />
* Modulation: GFSK<br />
<br />
<pre>ccregAll: <br />
<br />
ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F<br />
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B<br />
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B <br />
<br />
Configuration Register Detail (address, name, value):<br />
0x00 IOCFG2 - 0x0D<br />
0x01 IOCFG1 - 0x2E<br />
0x02 IOCFG0 - 0x2D<br />
0x03 FIFOTHR - 0x47<br />
0x04 SYNC1 - 0xD3<br />
0x05 SYNC0 - 0x91<br />
0x06 PKTLEN - 0x3D<br />
0x07 PKTCTRL1 - 0x04<br />
0x08 PKTCTRL0 - 0x32<br />
0x09 ADDR - 0x00<br />
0x0A CHANNR - 0x00<br />
0x0B FSCTRL1 - 0x06<br />
0x0C FSCTRL0 - 0x00<br />
0x0D FREQ2 - 0x21<br />
0x0E FREQ1 - 0x65<br />
0x0F FREQ0 - 0x6F<br />
0x10 MDMCFG4 - 0xF9<br />
0x11 MDMCFG3 - 0xF4<br />
0x12 MDMCFG2 - 0x18<br />
0x13 MDMCFG1 - 0x23<br />
0x14 MDMCFG0 - 0xB9<br />
0x15 DEVIATN - 0x40<br />
0x16 MCSM2 - 0x07<br />
0x17 MCSM1 - 0x00<br />
0x18 MCSM0 - 0x18<br />
0x19 FOCCFG - 0x14<br />
0x1A BSCFG - 0x6C<br />
0x1B AGCCTRL2 - 0x07<br />
0x1C AGCCTRL1 - 0x00<br />
0x1D AGCCTRL0 - 0x91<br />
0x1E WOREVT1 - 0x87<br />
0x1F WOREVT0 - 0x6B<br />
0x20 WORCTRL - 0xF8<br />
0x21 FREND1 - 0x56<br />
0x22 FREND0 - 0x11<br />
0x23 FSCAL3 - 0xEF<br />
0x24 FSCAL2 - 0x2D<br />
0x25 FSCAL1 - 0x12<br />
0x26 FSCAL0 - 0x1F<br />
0x27 RCCTRL1 - 0x41<br />
0x28 RCCTRL0 - 0x00<br />
0x29 FSTEST - 0x59<br />
0x2A PTEST - 0x7F<br />
0x2B AGCTEST - 0x3F<br />
0x2C TEST2 - 0x88<br />
0x2D TEST1 - 0x31<br />
0x2E TEST0 - 0x0B<br />
</pre><br />
<br />
=== Finale ===<br />
<br />
Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.<br />
<br />
Der SIGNALduino erkennt <br />
<pre><br />
2020.01.12 14:33:03 4: mySIGNALduino: Parse_MS, Decoded matched MS Protocol id 88 dmsg P88#74D21B18008B48058 length 68 RSSI = -32<br />
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, test ungleich: disabled<br />
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, -32 dB, dispatch<br />
2020.01.12 14:33:03 5: mySIGNALduino: dispatch P88#74D21B18008B48058<br />
2020.01.12 14:33:04 2: mySIGNALduino: SD_Keeloq_Parse Unknown device unknown with Code 012D100 detected, please define (rawdate=74D21B18008B48058)<br />
2020.01.12 14:33:04 2: autocreate: define SD_Keeloq_012D100 SD_Keeloq 012D100<br />
2020.01.12 14:33:04 2: autocreate: define FileLog_SD_Keeloq_012D100 FileLog ./log/SD_Keeloq_012D100-%Y.log SD_Keeloq_012D100<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 91.1 -> Atlantic security<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=2 reconstructed, last bit=0<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 87 -> JAROLIFT<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=1 reconstructed, last bit=1<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 88 -> HCS300/HCS301<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2<br />
</pre><br />
und routet die Requests 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.<br />
<br />
Mittlerweile ist das Protokoll als '''model enjoy_motors_HS''' in das Modul '''SD_Keeloq''' aufgenommen.<br />
<br />
== CUL - FSK und Co. ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt. <br />
<br />
Es befindet sich aber noch im Aufbau....<br />
<br />
== FAQ ==<br />
<br />
=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===<br />
<br />
Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.<br />
<br />
Die Bestimmung short High / Low erfolgt einfach dadurch, ob gesendet wird oder ob gerade eine Pause eingelegt wird.<br />
<br />
Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.<br />
<br />
Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.<br />
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.<br />
<br />
Beispiel einer empfangenen Sequenz<br />
<br />
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code><br />
<br />
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.<br />
<br />
Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.<br />
<br />
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.<br />
<br />
Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).<br />
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.<br />
<br />
== Links ==<br />
<br />
* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)<br />
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]<br />
* [https://github.com/jopohl/urh Universal Radio Hacker]<br />
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]<br />
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]<br />
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]<br />
* [[Intertechno Code Berechnung]]<br />
* [[Funksignalanalyse mit DVB-T Stick]]<br />
<br />
[[Kategorie:Intertechno]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Unbekannte_Funkprotokolle&diff=35951Unbekannte Funkprotokolle2021-08-15T13:25:25Z<p>AndreasMohr: Typos / language</p>
<hr />
<div>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?<br />
<br />
Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.<br />
<br />
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...<br />
<br />
Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:<br />
<br />
Einführung ... erste Schritte ... Tests ... Analyse ... stabiler Betrieb ... Verfeinerung / letzte Schritte (Expertise-Details).<br />
<br />
== Basics ==<br />
<br />
==== Hardware ====<br />
<br />
Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink. <br />
<br />
Diese unterscheiden sich in verschiedener Hinsicht:<br />
* Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [https://de.wikipedia.org/wiki/Amplitudenumtastung]<br />
* Modulationsverfahren (OOK, ASK/FSK)<br />
* Frequenzband (433 MHz, 868 MHz)<br />
<br />
(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)<br />
<br />
==== Frequenzbereich ====<br />
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.<br />
<br />
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.<br />
<br />
==== Modulationsverfahren ====<br />
<br />
So, wie vom Rundfunk (AM/FM) her bekannt, kennt man auch bei 433/868 MHz verschiedene Modulationsverfahren. <br />
<br />
* [https://de.wikipedia.org/wiki/Amplitudenumtastung OOK/ASK/Amplitudenabtastung]<br />
: Das Signal des Senders wird auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln. <br />
* [https://de.wikipedia.org/wiki/Frequenzumtastung FSK/Frequenzumtastung]<br />
: 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]).<br />
<br />
==== Encoding oder auch Leitungscode ====<br />
<br />
Die Art und Weise wie dieses Signal interpretiert wird, hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.<br />
<br />
* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]<br />
* [https://de.wikipedia.org/wiki/Non_Return_to_Zero NRZ]<br />
* [https://de.wikipedia.org/wiki/Manchester-Code Manchester]<br />
<br />
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 <br />
* 100 (short high, long low) wird als 0<br />
* 110 (long high, short low) wird als 1<br />
interpretiert.<br />
<br />
Im FHEM-Forum gibt es viele freundliche Helfer, die Euch bei Bedarf den richtigen Weg weisen.<br />
<br />
==== Signalstruktur ====<br />
<br />
Ein typischer Aufbau einer Signalstruktur sieht z.B. so aus<br />
<br />
| Pause | Sync | Pause | Daten |<br />
<br />
* eine größere Pause zur Trennung der Sequenzen <br />
* ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt<br />
* eine Pause um Sync und Daten zu trennen<br />
* die eigentlichen, zu übertragenden Daten.<br />
<br />
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]).<br />
<br />
Die Sequenz wird ggf. mehrfach wiederholt <br />
<br />
| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...<br />
<br />
==== Protokoll ====<br />
<br />
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). <br />
<br />
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.").<br />
<br />
== Wie fange ich an? ==<br />
<br />
==== Recherche ====<br />
<br />
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.<br />
<br />
Evt. haben auch konkrete verwandte Projekte bereits Protokoll-Informationen über das Gerät, z.B.:<br />
* [https://github.com/merbanan/rtl_433/tree/master/src/devices rtl_433: Geräte-Verzeichnis]<br />
<br />
Wenn sich nichts Verwertbares finden lässt, geht's mit dem nächsten Abschnitt weiter.<br />
<br />
==== Ansatz 1 - Versuchen ====<br />
<br />
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.<br />
<br />
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).<br />
<br />
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]]). <br />
<br />
Solltet Ihr mit diesem Ansatz Erfolg haben, ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.<br />
<br />
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<br />
* 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)<br />
* es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)<br />
<br />
==== Ansatz 2 - Aufschrauben ====<br />
<br />
Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist.<br />
Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.<br />
<br />
Das Teil ist zu klein? Folgende Möglichkeiten:<br />
* so im Winkel gegen ein Lampenlicht halten, dass man die Schrift besonders gut lesen kann<br />
* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt<br />
<br />
Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.<br />
<br />
Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.<br />
<br />
Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen<br />
* OOK-Modulation -> [[SIGNALduino]]<br />
* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]<br />
<br />
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.<br />
<br />
==== Ansatz 3 - Messen ====<br />
<br />
Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze. <br />
<br />
* 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.<br />
* 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].<br />
* 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.<br />
<br />
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.<br />
<br />
Die Spektrumanalyse gibt Aufschluss über<br />
* das Modulationsverfahren (OOK vs. FSK) sowie<br />
* die relevante(n) Frequenz(en)<br />
<br />
== SIGNALduino - OOK ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.<br />
<br />
==== Log-Meldungen ====<br />
<br />
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.<br />
<br />
Die folgenden Pulslängen-Zahlen stehen für Mikrosekunden.<br />
<br />
<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code><br />
<br />
Was bedeutet D=012323...?<br />
: 0 -> P0=-13020 => 13.020 Mikrosekunden Pause<br />
: 1 -> P1=15916 => 15.916 Mikrosekunden Signal<br />
: 2 -> P2=-398 => 398 Mikrosekunden Pause<br />
: 3 -> P3=415 => 415 Mikrosekunden Signal<br />
: 2 -> P2=-398 => 398 Mikrosekunden Pause<br />
: 3 -> P3=415 => 415 Mikrosekunden Signal<br />
: ...<br />
<br />
<br />
Tip: um hier schnell zu einem guten Analyse-Ergebnis zu kommen, sind einige verfügbare Beispiel-Zeilen sinnvoll - hier könnte folgendes hilfreich sein:<br />
Bei Geräten, die nicht on-demand (Knopfdruck) Funk-Aktivität generieren können:<br />
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:<br />
* Log-Zeitstempelmäßig genau erkennbar ist<br />
* hoffentlich immer gleich/ähnlich ist --> gute Analyse-Grundlage<br />
Damit dürfte die Funk-Aktivität hinsichtlich Empfangsstärke, Trägerfrequenz etc. leichter festnagelbar sein.<br />
<br />
==== Frequenz ermitteln ====<br />
<br />
Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Eingrenzung - Selektiver Empfang ====<br />
<br />
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.<br />
<br />
Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.<br />
<br />
Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.<br />
<br />
==== Eingrenzung - Log-Analyse via regex ====<br />
<br />
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:<br />
z.B.:<br />
<br />
<code>tail -f log/fhem-2018-11.log|grep "sduino.*msg READ: .*=-4...;"</code><br />
<br />
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:<br />
<br />
<code>sduino433/msg READ: MU;P0=-956;P1=450;P2=-1987;P3=-4212;P4=96;P6=-304;D=01212121212121312131212131312121213131312131313431316;CP=1;R=224;</code><br />
<br />
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.<br />
<br />
==== Variationen ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Signal analysieren ====<br />
<br />
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).<br />
<br />
Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.<br />
<br />
Gehen wir wieder von unserem Beispiel aus:<br />
<br />
<code>P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;</code><br />
<br />
Wie ist diese Sequenz zu interpretieren?<br />
<br />
* Es startet mit einer Pause D='''0'''123232323232<br />
* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.<br />
* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.<br />
* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265<br />
* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....<br />
<br />
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.<br />
<br />
Beispiel: Den Vorspann<br />
<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<br />
<br />
<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626<br />
<br />
lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL<br />
<br />
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<br />
<br />
10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100<br />
<br />
AD99 79A2 9FBC B7FC</code><br />
<br />
Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)<br />
* 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"...<br />
* 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)<br />
<br />
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.<br />
<br />
Weitere wichtige Tips:<br />
* 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<br />
* 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<br />
* 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!)<br />
* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links|RFFHEM git repository]] ansehen<br />
* 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<br />
* 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:<br />
<code>define sduino_dummy SIGNALduino none</code><br />
<br />
In diesen kann man dann die gewünschten zu unterstützenden Pattern einimpfen:<br />
<br />
<code>get sduino_dummy raw MC;;LL=-653;;LH=665;;SL=-317;;SH=348;;D=D55B58;;C=330;;L=21;;</code><br />
<br />
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.<br />
<br />
Weitere für einen Test verwendbare Beispiel-Pattern siehe [[#Links|RFFHEM git repository]], in Datei: <code>FHEM/14_SD_BELL.pm</code>.<br />
<br />
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.<br />
<br />
==== Steuern ====<br />
<br />
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].<br />
<br />
==== Signal-Protokoll-Beschreibung verfeinern ====<br />
<br />
Sobald man bei einem Gerät initial erfolgreich empfangen / dekodieren (/ senden?) konnte, sollte man folgendes noch beachten:<br />
<br />
Es ist recht wichtig, dass jede Protokoll-Beschreibung eines Geräte-Signals '''möglichst präzise Geräte-konforme''' Werte aufführt:<br />
<br />
wenn mehrere Protokoll-Beschreibungen aufgrund von zu ungenauen Werten jeweils als passend betrachtet werden, dann<br />
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:<br />
* evt. ganz fehlgeschlagen aufgrund von Falsch-Zuordnung<br />
* viel sinnlose Noise im Log, weil gleich mehrere Pfade angeblich passen und dann "noch nicht supported"-Fehlermeldungen werfen<br />
Mit stark steigender Anzahl von bekannten Protokoll-Beschreibungen dürfte dieses Problem immer schlimmer werden.<br />
<br />
Daher sollte man folgendes beachten:<br />
* 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)<br />
* ''length_min'' , ''length_max'' möglichst passend restriktiv spezifizieren (also z.B. 12 , 12)<br />
* ''clockabs''-Basistakt-Mittelwert möglichst präzise ermitteln<br />
* ((die Perl-Demodulations-Implementierung - in <code>00_SIGNALduino.pm</code> etc. - ebenfalls auf möglichst restriktive Checks / Wertebereiche trimmen))<br />
<br />
Ermittlung eines präzisen ''clockabs''-Basistakt-Mittelwerts dürfte folgendermaßen gut machbar sein:<br />
* einige Geräte-Pattern aus dem Log fischen<br />
* dort die ''clockabs''-Werte suchen (<code>CP=x</code> verweist darauf)<br />
* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht<br />
* 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<br />
* evt. ist es auch hilfreich, den im Gerät verbauten Quarz 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:<br />
<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code><br />
); 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ß...)<br />
<br />
==== Development / patch submission ====<br />
<br />
Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:<br />
* Änderungen durchführen (im korrekten Branch)<br />
* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!<br />
* alles committen<br />
* 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<br />
* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig<br />
* 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.<br />
<br />
== SIGNALduino - FSK ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt. <br />
<br />
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)<br />
<br />
Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].<br />
<br />
=== FSK Senden ===<br />
<br />
Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:<br />
000 = 2-FSK<br />
001 = GFSK<br />
011 = ASK/OOK<br />
100 = 4-FSK<br />
<br />
Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über <br />
''get <mysduino> ccreg 99''<br />
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.<br />
Das Register wird über <br />
''set <mysduino> raw W1410'' <br />
abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).<br />
<br />
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.<br />
<br />
=== Sendefrequenz und Frequenzhub ===<br />
<br />
<div class="tright" style="clear:none">[[Datei:PeakLow.png|mini|ohne|300px|FSK, Trägerfrequenz minus Hub]]</div><br />
<div class="tright" style="clear:none">[[Datei:PeakHigh.png|mini|links|300px|FSK, Trägerfrequenz plus Hub]]</div><br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Ermittlung der Frequenzen ===<br />
<br />
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 vorgegebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnt Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.<br />
<br />
=== Hub ===<br />
<br />
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 <br />
''set <mysduino> raw W1740''<br />
an den CC1101 des SDUINO übermittelt wird.<br />
<br />
Wenn Ihr soweit seid, sollten die Funksignale der Original-Fernbedienung und Eures SDUINO ähneln.<br />
<br />
<div class="tleft" style="clear:none">[[Datei:RIO FB-Signal.png|mini|Spektrum Original-Fernbedienung]]</div><br />
<div class="tleft" style="clear:none">[[Datei:Signal des SDUINO GFSK .png|mini|Spektrum SDUINO GFSK ]]</div><br />
<div style="clear:both"></div><br />
<br />
=== Baudrate ===<br />
<br />
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 eine Fülle weiterer Optionen (Sync, FIFO etc.), die aber eher für Spezialisten geeignet sind.<br />
<br />
Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:<br />
FHEM <-> Arduino <-> CC1101 <-> Sendesignal<br />
<br />
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.<br />
<br />
Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittelt und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.<br />
<br />
<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png|mini|600px|RIO-Signal decodiert]]</div><br />
<div style="clear:both"></div><br />
<br />
Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.<br />
<br />
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 reale Darstellung zu kommen, gebe ich 402 Samples/Symbol (Symbol=bit) ein.<br />
<br />
Das Ergebnis:<br />
<br />
<div class="tleft" style="clear:both">[[Datei:Vergleich RIO-SDUINO-Signale.png|mini|600px|Vergleich RIO/SDUINO-Signale]]</div><br />
<div style="clear:both"></div><br />
<br />
=== Codesequenzen ===<br />
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 anders 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. <br />
<br />
Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.<br />
<br />
=== Konfiguration ===<br />
<br />
Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12<br />
<br />
Register-Settings:<br />
<br />
* Trägerfrequenz: 868.302 MHz<br />
* Deviation: 25 kHz<br />
* Bandwidth: 58 kHz<br />
* Baudrate: 24.795 kBaud<br />
* Modulation: GFSK<br />
<br />
<pre>ccregAll: <br />
<br />
ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F<br />
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B<br />
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B <br />
<br />
Configuration Register Detail (address, name, value):<br />
0x00 IOCFG2 - 0x0D<br />
0x01 IOCFG1 - 0x2E<br />
0x02 IOCFG0 - 0x2D<br />
0x03 FIFOTHR - 0x47<br />
0x04 SYNC1 - 0xD3<br />
0x05 SYNC0 - 0x91<br />
0x06 PKTLEN - 0x3D<br />
0x07 PKTCTRL1 - 0x04<br />
0x08 PKTCTRL0 - 0x32<br />
0x09 ADDR - 0x00<br />
0x0A CHANNR - 0x00<br />
0x0B FSCTRL1 - 0x06<br />
0x0C FSCTRL0 - 0x00<br />
0x0D FREQ2 - 0x21<br />
0x0E FREQ1 - 0x65<br />
0x0F FREQ0 - 0x6F<br />
0x10 MDMCFG4 - 0xF9<br />
0x11 MDMCFG3 - 0xF4<br />
0x12 MDMCFG2 - 0x18<br />
0x13 MDMCFG1 - 0x23<br />
0x14 MDMCFG0 - 0xB9<br />
0x15 DEVIATN - 0x40<br />
0x16 MCSM2 - 0x07<br />
0x17 MCSM1 - 0x00<br />
0x18 MCSM0 - 0x18<br />
0x19 FOCCFG - 0x14<br />
0x1A BSCFG - 0x6C<br />
0x1B AGCCTRL2 - 0x07<br />
0x1C AGCCTRL1 - 0x00<br />
0x1D AGCCTRL0 - 0x91<br />
0x1E WOREVT1 - 0x87<br />
0x1F WOREVT0 - 0x6B<br />
0x20 WORCTRL - 0xF8<br />
0x21 FREND1 - 0x56<br />
0x22 FREND0 - 0x11<br />
0x23 FSCAL3 - 0xEF<br />
0x24 FSCAL2 - 0x2D<br />
0x25 FSCAL1 - 0x12<br />
0x26 FSCAL0 - 0x1F<br />
0x27 RCCTRL1 - 0x41<br />
0x28 RCCTRL0 - 0x00<br />
0x29 FSTEST - 0x59<br />
0x2A PTEST - 0x7F<br />
0x2B AGCTEST - 0x3F<br />
0x2C TEST2 - 0x88<br />
0x2D TEST1 - 0x31<br />
0x2E TEST0 - 0x0B<br />
</pre><br />
<br />
=== Finale ===<br />
<br />
Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.<br />
<br />
Der SIGNALduino erkennt <br />
<pre><br />
2020.01.12 14:33:03 4: mySIGNALduino: Parse_MS, Decoded matched MS Protocol id 88 dmsg P88#74D21B18008B48058 length 68 RSSI = -32<br />
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, test ungleich: disabled<br />
2020.01.12 14:33:03 5: mySIGNALduino: Dispatch, P88#74D21B18008B48058, -32 dB, dispatch<br />
2020.01.12 14:33:03 5: mySIGNALduino: dispatch P88#74D21B18008B48058<br />
2020.01.12 14:33:04 2: mySIGNALduino: SD_Keeloq_Parse Unknown device unknown with Code 012D100 detected, please define (rawdate=74D21B18008B48058)<br />
2020.01.12 14:33:04 2: autocreate: define SD_Keeloq_012D100 SD_Keeloq 012D100<br />
2020.01.12 14:33:04 2: autocreate: define FileLog_SD_Keeloq_012D100 FileLog ./log/SD_Keeloq_012D100-%Y.log SD_Keeloq_012D100<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 91.1 -> Atlantic security<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=2 reconstructed, last bit=0<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 87 -> JAROLIFT<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, last part pair=1 reconstructed, last bit=1<br />
2020.01.12 14:33:04 4: mySIGNALduino: Parse_MS, Matched MS Protocol id 88 -> HCS300/HCS301<br />
2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2<br />
</pre><br />
und routet die Requests 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.<br />
<br />
Mittlerweile ist das Protokoll als '''model enjoy_motors_HS''' in das Modul '''SD_Keeloq''' aufgenommen.<br />
<br />
== CUL - FSK und Co. ==<br />
<br />
Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt. <br />
<br />
Es befindet sich aber noch im Aufbau....<br />
<br />
== FAQ ==<br />
<br />
=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===<br />
<br />
Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.<br />
<br />
Die Bestimmung short High / Low erfolgt einfach dadurch, ob gesendet wird oder ob gerade eine Pause eingelegt wird.<br />
<br />
Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.<br />
<br />
Die Dauer eines short Intervalles ist in der Regel halb so lang wie die von einem long und entspricht der Taktrate.<br />
Bei der ganzen Berechnung müssen natürlich Toleranzen berücksichtigt werden.<br />
<br />
Beispiel einer empfangenen Sequenz<br />
<br />
<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code><br />
<br />
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.<br />
<br />
Generell sind die absoluten, gemessenen low-Werte bei Signalduino kürzer als die high-Werte.<br />
<br />
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.<br />
<br />
Das Umwandeln der Pulse in den Daten in eine "sSlL-Notation" vereinfacht die Erkennung von Mustern (in mehreren Nachrichten variieren auch die Pulse).<br />
Dass ein lS=1 und sL=0 entspricht, ist nur eine willkürlich angenommene Arbeitshypothese, die bis dato ganz gute Ergebnisse produziert hat.<br />
<br />
== Links ==<br />
<br />
* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)<br />
* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]<br />
* [https://github.com/jopohl/urh Universal Radio Hacker]<br />
* [https://www.elttam.com.au/blog/intro-sdr-and-rf-analysis/ Intro SDR and RF Analysis]<br />
* [https://www.sigidwiki.com/wiki/Signal_Identification_Guide Signal Identification Guide]<br />
* [https://www.rtl-sdr.com/tag/fsk/ Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial]<br />
* [[Intertechno Code Berechnung]]<br />
* [[Funksignalanalyse mit DVB-T Stick]]<br />
<br />
[[Kategorie:Intertechno]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=SIGNALduino&diff=35950SIGNALduino2021-08-15T13:02:45Z<p>AndreasMohr: Typo, Mini-Verbesserungen</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Empfang und Verarbeitung von digitalen Signalen<br />
|ModType=d<br />
|ModFTopic=38402<br />
|ModCmdRef=SIGNALduino<br />
|ModForumArea=Sonstige Systeme<br />
|ModTechName=00_SIGNALduino.pm<br />
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])<br />
}}<br />
<br />
== Einleitung ==<br />
=== Übersicht ===<br />
Unter den Namen SIGNALduino versteht man sowohl den Low-Cost Empfänger für digitale Signale (vergleichbar dem [[CUL]]) als auch das gleichnamige Modul mit dem Dateinamen 00_SIGNALduino.pm. Mit dem SIGNALduino kann man entweder 433 oder 868 MHz-Geräte auslesen und ansprechen. Der SIGNALduino funktioniert auch mit anderen Medien wie Infrarot oder direkter Kabelverbindung.<br />
<br />
Der SIGNALduino(-Stick) erkennt Signale anhand von Mustern und gibt sie (als maximal detaillierte Beschreibung einer Signalabfolge) dann schlicht sofort nur noch an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben.<br />
Aufgabe des SIGNALduino (Firmware/Stick) ist es also nur, Signal-Aktivitäten zu erfassen und maximal präzise (als kurzer Text-String) zu beschreiben.<br />
Alles weitere (echte, finale Auswertung / Zuweisung dieser Signal-Daten) wird dann auf einer großen Box (z.B. Raspberry) gemacht.<br />
<br />
=== Vorteil gegenüber einem CUL/FHEMduino ===<br />
Der SIGNALduino hat den Vorteil einer sehr schnellen Demodulation des Funksignals. Sollen weitere Protokolle dekodiert werden, so muss dazu nur ein passendes FHEM Modul entwickelt oder ein universelles Modul erweitert werden (also auf flexibel direkt updatebarer Rechner-Seite!!). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung des Sticks korrekt funktioniert - leider nicht immer, z.B.: [https://github.com/RFD-FHEM/SIGNALDuino/issues/65 MU-Nachrichten werden z.T. als MC erkannt]).<br />
<br />
Ein großer Vorteil des SIGNALduino besteht darin, dass auch Geräte mit leicht abweichenden Frequenzen steuerbar sind; so empfangen die Somfy-Rolladenmotoren beispielsweise auf 433.42 und nicht, wie bei anderen Geräten sehr oft üblich, auf 433.92 MHz. Die Frequenzumstellung stellt für den SIGNALduino kein Problem dar.<br />
<br />
Ebenso kann man den SIGNALduino direkt an den Sendeausgang eines Sensors anbinden und die digitalen Signale empfangen, dabei bitte aber auf die passenden Spannungen achten, denn ein Arduino Nano verträgt nur 5V.<br />
<br />
<br />
=== Entwicklungsversion ===<br />
Der SIGNALduino wird derzeit aktiv weiterentwickelt, siehe dazu https://github.com/RFD-FHEM. Die offizielle Version wird {{Link2Forum|Topic=58396|LinkText=hier}} genauer beschrieben. Es existieren im Forum diverse angepasste Versionen, auf die hier nicht näher eingegangen wird.<br />
<br />
== Hardware ==<br />
=== Controller ===<br />
Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden. Bei Einbindung via ESP muss man beachten, dass der ESP nach 5 Minuten Inaktivität seine TCP-Verbindung unterbricht (siehe [[ESP8266#Bekannte_Probleme|diesen Hinweis]]). Zu diesem Zweck gibt es einen Signalduino-eigenen Ping-Befehl ('get signalduino ping'), der diese Aktivität wieder aufbaut. Ping-Befehle sind auch auf Betriebssystemebene bekannt - allerdings beachte man, dass der ping-Befehl auf Betriebssystemebene ICMP verwendet, zum "Aufwachen" des ESP aber auf TCP-Ebene aktiviert werden muss (zum Unterschied siehe [https://www.tippscout.de/internet-was-sind-tcp-ip-udp-und-icmp_tipp_2268.html hier]) und man daher besser den Signalduino-eigenen Befehl und nicht das Betriebssystem verwendet.<br />
<br />
Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht dem [[Selbstbau_CUL]] (eine frühere Version ist der nicht mehr weiterentwickelte [[FHEMduino]]):<br />
* Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum [[FHEMduino]] <br />
* Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum [[Selbstbau_CUL]]. Dieser Aufbau wird derzeit empfohlen.<br />
* Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, Link zum [http://shop.in-circuit.de/index.php Hersteller]. <br />
<br />
Achten Sie beim Selbstbau auf die entsprechenden Sender-Empfänger. Der sehr preiswert angebotene XY-MK-5V hat sich als zu unzuverlässig erwiesen, während anscheinend beim CC1101 (insbesondere der "grünen Version") keine Probleme auftreten. <br />
<br />
Es stehen auch für den [https://www.arduino.cc/en/Main/arduinoBoardUno UNO] und [https://www.arduino.cc/en/Main/ArduinoBoardProMini PRO Mini] Firmware-Dateien zur Verfügung. Die ausgelieferte Firmware läuft nur auf Mikrocontrollern mit 16 MHz; wer einen Mikrocontroller mit 8 MHz verwenden möchte, muss die Firmware selbst compilieren. Die SW ist auf [https://github.com/RFD-FHEM/SIGNALDuino github]. Vorgesehen ist nur die Übersetzung unter Windows mit Visual Studio und dem Visual Micro Zusatz. Es gibt aber auch eine Anleitung, wie man mit der [[Arduino]] IDE oder einem Makefile [[SIGNALduino Compilieren]] kann.<br />
<br />
Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] nativ läuft, diese funktioniert seit Anfang 2018 annehmbar, allerdings befindet diese sich noch in einer Entwicklungsphase.<br />
<br />
An den "SIGNALESP" kann auch ein CC1101 via SPI angebunden werden:<br />
<br />
{| |<br />
!CC1101 Bezeichnung<br />
!ESP Pin<br />
|-<br />
|CLK||GPIO14<br />
|-<br />
|MOSI||GPIO13<br />
|-<br />
|MISO||GPIO12<br />
|-<br />
|CSN||GPIO15<br />
|-<br />
|GDO0||GPIO4<br />
|-<br />
|GDO2||GPIO5<br />
|}<br />
<br />
Wird eine einfache Empfänger / Sender Kombination verwendet, dann über die PINs:<br />
<br />
{| |<br />
! Bezeichnung <br />
! ESP Pin<br />
|-<br />
|Transmitter||GPIO4<br />
|-<br />
|Receiver||GPIO5<br />
|}<br />
<br />
=== Sendemodule ===<br />
{{Randnotiz|RNTyp=r|RNText=Viele user berichten über Empfangsprobleme bei Nutzung des XY-MK-5V; es wird ausdrücklich empfohlen, ein anderes Empfangsmodul zu nutzen!}}<br />
[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]] <br />
<br />
Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:<br />
* FS1000A Dies ist das Sendemodul (TX) und wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€). <br />
* RXB6 Das ist das empfohlene Empfangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.<br />
<br />
Die Verkabelung erfolgt analog zum [[FHEMduino]] und das bedeutet (Arduino -> Modul):<br />
* PIN D2 an DATA des RX-Moduls<br />
* PIN D11 an DATA des TX-Moduls (PIN links mit Beschriftung ATAD)<br />
<br />
Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.<br />
<br />
Jetzt fehlen noch die Antennen. Dafür braucht man ein 17,2 cm langes Stück Kupferdraht, das wird beim Anschluss "ANT" jeweils am Modul angelötet (anfängergeeignet).<br />
<br />
== Software ==<br />
<br />
=== USB-ID ermitteln ===<br />
Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) verbunden werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl<br />
<pre> ls -l /dev/serial/by-id </pre><br />
ausführen. Beispielhaft sieht das Ergebnis etwa so aus:<br />
<br />
''lrwxrwxrwx 1 root root 13 Jan 31 00:02 '''usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port''' -> ../../ttyUSB0''<br />
<br />
Damit ist der Anschluss des SIGNALduino bestimmt und das Gerät kann wie im nächsten Abschnitt beschrieben definiert werden. Zuvor muss noch das Modul geladen werden.<br />
<br />
=== FHEM-Modul laden ===<br />
Die SIGNALduino Module werden über das FHEM [[update]] verteilt, sobald die Änderungen einen "stabilen" und alltagstauglichen Zustand haben. Aktuell wird dort die Version 3.4.2 seit 08.04.2020 verteilt.<br />
<br />
Die in der Entwicklung befindliche Version (3.5.x, bringt z.B. Unterstützung für Geräte mit FSK-Modulation) kann mit folgenden Befehlen geladen werden:<br />
<br />
* FHEM aktualisieren: <code>update</code> <br />
* SIGNALduino Modul aktualisieren: <code>update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master<nowiki/>/controls_signalduino.txt</code> Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet.<br />
* Es empfiehlt sich, die Github-Quelle dauerhaft einzutragen: <code>update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt</code>, um weitere Entwicklungs-Updates zu bekommen und damit das nächste Standard-<code>update</code> nicht die alte Version wieder einspielt.<br />
<br />
Das Gerät kann wie folgt definiert werden (die Spezifikation des USB-Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):<br />
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code><br />
* Solltet Ihr einen SIGNALESP via IP einbinden wollen, ist die Syntax (ebenso wird auch vorgegangen wenn der SIGNALduino beispielsweise über ser2net freigeben wird):<br />
:<code>define <eigener-SIGNALESP-Name> SIGNALduino <ip-adresse>:23</code><br />
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt. Die Baudrate beim SIGNALduino beträgt 57600 - via telnet muss dann dieselbe Baudrate eingestellt werden. <br />
<br />
Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.<br />
<br />
==== Flashen des Arduino mit der SIGNALduino Firmware ====<br />
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:<br />
:<code>sudo apt-get install avrdude</code><br />
<br />
In FHEM ist der SIGNALduino mit dem Status "Open" vorhanden. Jetzt müssen wir FHEM noch mitteilen, welche Hardware wir angeschlossen haben. Über das Attribut ''hardware'' lässt sich zwischen den mitgelieferten Firmware-Dateien wechseln. Solltet ihr einen Nano mit cc1101 Transceiver verwenden, so wählt bitte folgende Hardware<br />
:<code>attr sduino hardware nanoCC1101</code><br />
sonst üblicherweise<br />
:<code>attr sduino hardware nano328</code><br />
<br />
Dann muss mitgeteilt werden, welche Version man geladen haben will: stable oder testing. <br />
:<code>attr sduino updateChannelFW testing</code><br />
Nun wird die entsprechende Firmware heruntergeladen. Dies geschieht durch den Befehl<br />
:<code>get sduino availableFirmware</code><br />
Anschließend kann der ''flash'' Befehl abgesetzt werden: <br />
:<code>set sduino flash <und-dann-auswaehlen></code><br />
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.<br />
<br />
Alternativ kann auch der Flash-Befehl mit einem Dateinamen aufgerufen werden. Diese Möglichkeit sollte jedoch nur verwendet werden, wenn die SIGNALduino Firmware selbst compiliert wurde und eine andere Hardware verwendet wird. Der Flash-Befehl wird wie folgt aufgerufen:<br />
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code><br />
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)<br />
<br />
Wenn ein miniCUL geflasht werden soll, sind einige Besonderheiten zu beachten. Details dazu in {{Link2Forum|Topic=114413|LinkText=diesem Forenthema}}.<br />
<br />
==== Flashen einer Firmware über HTTP ====<br />
Die Firmware wird nicht mehr über den FHEM Update Mechanismus verteilt. <br />
Damit die passende Firmware auf den SIGNALduino geladen werden kann, wird diese dann über HTTP aus den Github Releases geladen.<br />
<br />
==== Vorabversion einer Firmware ====<br />
Die Firmware des SIGNALduino wird ebenso wie das FHEM Modul auch weiter entwickelt.<br />
Die Entwickler sind auf Tests und Rückmeldungen der Nutzer angewiesen, da leider nicht alle Sensoren vorher getestet werden können.<br />
<br />
Die Version 3.4 ist die aktuell stabile Version.<br />
<br />
Für die folgenden Microcontroller kann man die Firmware seit 21.02.2019 auch direkt downloaden und teilweise flashen. <br />
Dazu muss das Attribut hardware auf einen gültigen Wert angepasst werden!<br />
Über den GET Befehl availableFirmware werden dann für die hinterlegte Hardware die passenden Versionen gesucht. Über das Attribut updateChannelFW kann zwischen "stable" und "testing" definiert werden, welche Art von Firmware angeboten werden soll.<br />
<br />
Nachdem die Firmwareversion erfragt wurde, bietet der set flash Befehl eine Auswahlliste an. Wird ein Flash Befehl mit einer der Versionen ausgewählt, wird diese Version zunächst heruntergeladen und bei den AVR Versionen auch versucht diese mittels avrdude zu flashen.<br />
Die Firmware für den ESP8266 kann aktuell leider noch nicht über diesen Befehl aktualisiert werden.<br />
<br />
Alternativ funktioniert aber auch die Option, dem Flash Befehl eine URL zu übergeben. Dann wird die Datei aus der URL heruntergeladen und auch versucht diese zu Flashen. z.B.<br />
SIGNALDuino_nanocc1101.hex für einen Nano mit CC1101<br />
<br />
<code>set sduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_radinocc11013.3.1.hex<br />
<br />
oder<br />
SIGNALESP_.hex (mit cc1101) für einen ESP8266 <br />
<code>set ipduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_ESP8266cc11013.3.1.hex<br />
<br />
!Achtung, aktuell wird die Firmware für den ESP dadurch nur herunter geladen. Flashen müsst ihr leider immer noch über ein passendes Tool <br />
z.B. [https://github.com/nodemcu/nodemcu-flasher ESP8266Flasher.exe] oder Esptool und einer seriellen Konsole.<br />
Auch ist zu beachten, es handelt sich hierbei tatsächlich um ein Binary und nicht um ein Hex File. <br />
<br />
Nach dem Booten des ESPs spannt dieser ein eigenes WLAN auf. Habt ihr euch damit verbunden, könnt ihr den ESP mit eurem vorhandenen WLAN nach Eingabe der Daten verbinden.<br />
<br />
Die Hauptseite für Firmware-Releases findet sich unter https://github.com/RFD-FHEM/SIGNALDuino/releases/ .<br />
Dort kann auch eine Änderungshistorie eingesehen werden.<br />
==== Flashen eines radino Boards mit ATmega32U4 ====<br />
<br />
Diese Funktion steht seit 21.02.2019 nun auch in der via FHEM aktualisierten Version zur Verfügung:<br />
<br />
Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird.<br />
Weiterhin ist zu beachten, dass der Bootloader eine andere USB ID bekommt und diese im Attribut flashCommand hinterlegt werden muss.<br />
<br />
==== Fehler beim Flashen ====<br />
Sollte bei einem Flash Vorgang ein Fehler auftreten, solltet ihr zunächst im Logfile mit Verbose 5 nachsehen.<br />
<br />
Findet ihr dort keine Fehlermeldung, gibt es noch ein separates Flashlog, welches ihr über einen Browser aufrufen könnt. Dazu müsst ihr nur den folgenden Pfad an euren Servernamen anhängen:<br />
<code><br />
/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=SIGNALduino-Flash.log<br />
</code><br />
<br />
=== Geräteerkennung ===<br />
==== Unterstützte Geräte ====<br />
Für die folgenden Geräte gibt es derzeit (2017) eine Unterstützung für den Betrieb mit FHEM. Die Geräte werden [[autocreate|automatisch erkannt]] und in der Konfiguration eingetragen, wenn der SIGNALduino läuft.<br />
Bitte Geräte mit sehr präzisen Referenzen hier listen (Produktnummer, Protokoll-Variantenname etc.), damit eine globale Suche/Verifikation maximal erfolgreich ist. In der detaillierten Liste [[Geprüfte_Geräte]] lassen sich die Geräte näher identifizieren.<br />
{| class="wikitable"<br />
! style="text-align:left;" | Produkt <br />
! (E)mpfangen<br />(S)enden <br />
! Hinweise <br />
! Verwendetes Modul <br />
! Protokoll ID<br />
|-<br />
|Conrad Wetterstation KW9110||E S||Sensor: KW9010, neben Temperatur u. Luftfeuchte werden auch Trend, Batterie u. Kanal erfasst|| CUL_TCM97001 || 0.3<br />
|-<br />
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0 <br />
|-<br />
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17<br />
|-<br />
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL || <br />
|-<br />
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10<br />
|-<br />
|Bresser Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12<br />
|-<br />
|TFA Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8<br />
|-<br />
|TFA 30320902||E || || SD_WS07 || 7<br />
|-<br />
|Eurochron eas800z||E || || SD_WS07 || 7<br />
|-<br />
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7<br />
|-<br />
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7<br />
|-<br />
|CTW600||E || || SD_WS09 || 9<br />
|-<br />
|CTW602||E ||neuere Version des CTW600 mit 868.35 MHz || SD_WS09 || 9<br />
|-<br />
|WH1080||E || || SD_WS09 || 9<br />
|-<br />
|Visivon remote pt4450||E || || none || 24<br />
|-<br />
|Einhell HS 434/6||E || || none || 21<br />
|-<br />
|Flamingo FA20RF / FA21RF / FA22RF Rauchmelder||E || || FLAMINGO || 13,13.1,13.2<br />
|-<br />
|mumbi m-FS300||E || || none || 26,27<br />
|-<br />
|TFA 30.3200||E || || none || 33<br />
|-<br />
|Livolo||E|| || none || 20<br />
|-<br />
|Smartwares RM174RF/2 (RM174RF-001CPR) 4500177571 ||E [S?]|| IT EV1527; TODO herausfinden: Alarmierung (wie Alarmton getriggered werden kann); Batterieinfo? || IT || 3<br />
|-<br />
|Smartwares SH5-TSO-A||E S|| || IT || ?<br />
|-<br />
|X10 Security Devices||E|| || || 39<br />
|-<br />
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43<br />
|}<br />
Bei einigen Intertechno-Funksteckdosen (Brennenstuhl) kann es zu Empfangsproblemen kommen. Hier muss die Taktrate, mit der gesendet wird, angepasst werden. Dazu muss für ''Funksteckdose'' (also sauber per-Client-Instanz-spezifisch, NICHT SIGNALduino-Transceiver-global) das Attribut <br />
:<code>attr <Funksteckdose> ITclock 300</code> <br />
gesetzt werden, der Standardwert ist 250.<br />
<br />
==== Mein Gerät wird in FHEM nicht erkannt ====<br />
1. Prüfen, ob vom Sensor die Signaldaten (verbose >=4) erkannt werden. Sobald ihr die empfangenen Signaldaten im Logfile zuordnen könnt, geht es weiter mit:<br />
<br />
2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues/new?template=sensor---device-feature.md github]:<br />
<!-- <syntaxhighlight lang="md"> ... markdown lexer not yet available; use pre instead --><br />
<pre><br />
## Specifications for new sensor / switch / or other device ... <br />
<br />
- manufacturer:<br />
- model name:<br />
- pictures of the device / the board (very helpful)<br />
<br />
<br />
## Specifications <br />
<br />
- Microcontroller:<br />
- Version (Firmware):<br />
<br />
<!-- ( can be found here devicename -> Internals -> version ) --><br />
- Versionmodul (FHEM Module):<br />
</pre><br />
<br />
3. Auszug aus dem Logfile, welches zum Gerät gehört.<br />
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.''<br />
<br />
Im Forum solltet ihr solche Fragen besser nicht posten, wenn das Gerät noch nicht unterstützt wird, dazu ist Github besser geeignet. Inzwischen wurde im Wiki eine eigene Seite eröffnet, die sich mit der Erkennung unbekannter Protokolle beschäftigt: [[Unbekannte_Funkprotokolle#Ansatz_1_-_Versuchen|Unbekannte_Funkprotokolle]].<br />
<br />
==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ====<br />
Im SIGNALduino sind >70 Protokolle implementiert. Jedoch gibt es nicht immer ein logisches Module, welche diese Protokolle verarbeiten.<br />
Teilweise ist das auch nicht zwingend notwendig, um seine Anforderungen zu erfüllen. Insbesondere für Schalter bzw. Sensoren, die nur zwei Zustände kennen, geht es meist ohne Modul und automatisch angelegtem Gerät.<br />
<br />
Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden.<br />
Im FHEM Log (und, insbesondere, im FHEMWEB Event Monitor) tauchen Meldungen ähnlich dieser auf<br />
<br />
<code><br />
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081<br />
</code><br />
<br />
Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:<br />
<br />
Entweder, wenn wir den Inhalt der Nachricht nur zu Teilen wissen, da er sich ändert:<br />
<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)<br />
attr mydoif do always<br />
</code><br />
<br />
Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring<br />
<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on)<br />
attr mydoif do always<br />
</code><br />
<br />
Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.<br />
<br />
Als Alternative zu DOIF hier ein regex-verwendendes notify-Beispiel für einen Sender, der meint, zwei Codes alternierend senden zu müssen:<br />
<br />
<code><br />
define n_sender_trigger notify sduino:UNKNOWNCODE.*u41#(13B72253|163873B3) { my_sender_trigger_indicate();; }<br />
</code><br />
<br />
Selbstverständlich muss in diesem Moment auch eine sub my_sender_trigger_indicate() definiert werden (z.B. in FHEM/99_myUtils.pm), die dort z.B. als Test eine Log-Ausgabe (Log3()) machen kann.<br />
<br />
=== Das Logfile ===<br />
Im Logfile ab [[Verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (verbose 3 unterdrückt diese Meldungen).<br />
<br />
UPDATE: der folgende Bereich ist von einem weniger erfahrenen Zeitgenossen früher nach Kräften erweitert/geschrieben worden. Mittlerweile existiert aber ein neuer Inhalt [[Unbekannte_Funkprotokolle]] (siehe auch Erwähnung weiter oben), der als sehr gut beschrieben und unvergleichlich detailreicher bezeichnet werden muss ("endlich gibt es sowas!"). Der Bereich hier dürfte somit zwar für grundlegende Verdeutlichungen noch recht sinnvoll sein, der Inhalt sollte allerdings evt. in eine konsistente Dokumentation überarbeitet (verlagert/dedupliziert/reduziert) werden.<br />
<br />
Die Protokolle (von der SIGNALDuino-Firmware gesendete Signal-Beschreibungs-Strings) können wie folgt unterschieden werden:<br />
<br />
*MS - Nachricht mit Sync Puls: Hierzu ein Beispiel<br />
:<code>MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;</code> P0-P6 sind die Signalpegel (Dauer und positiv/negativ). Hinter D= befindet sich die Abfolge der Signale. Die ersten beiden Ziffern 15 in D sind wie folgt zu lesen. Zuerst wurde ein Signal "1" also P1 mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal "5" also P5 mit 8916 Mikrosekunden low (die Zeitdauer ergibt sich aufgrund der Mitteilung "P5=-8916") gemessen. CP=1 ist die Referenz auf den Takt des Signales - der Basistakt ist in diesem Fall ~395 Mikrosekunden. SP=5 gibt die Referenz zum Syncpuls an, der das gesamte Signal einleitet. Welche Signalfolge nun eine binäre 1 bzw. 0 bedeutet, wird im SIGNALduino über die integrierte Protokoll Liste realisiert.<br />
<br />
*MC - Nachricht vom Typ Manchester: Manchesterkodierte Signale können bereits sehr einfach im Arduino in eine Binärform umgewandelt werden. Es wird hier nach IEEE 802.3 umgewandelt. In Manchester Signalen gibt es lange und kurze Pulse. Deren Durchschnittswert wird mit LL (long low), LH (long high), SL (short low) und SH (short high) übermittelt. Zusätzlich, um das Protokoll schneller erkennen zu können, wird die Taktfrequenz mit übermittelt (C=429 Mikrosekunden). Die Daten befinden sich hinter D= und werden in HEX Form übergeben.<br />
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code><br />
<br />
*MU - Message unsynced: Diese Art von Nachrichten sind nicht nach Manchester codiert und haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht. Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist. Wie bei MS sind P0-P6 die Signalpegel und in D= wird die Abfolge der Signalpegel referenziert. CP=2 gibt auch hier die Referenz zum Takt an, allerdings muss dieser nicht korrekt erkannt worden sein.<br />
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code><br />
<br />
Es erscheinen viele Meldungen dieser Art:<br />
<br />
<pre><br />
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate<br />
</pre><br />
<br />
Dies sind nun Bemühungen, anhand der von der SIGNALDuino-Firmware gelieferten rohen aber detaillierten Signal-Strings eine Vor-Analyse / Fingerprinting vorzunehmen.<br />
Man könnte nun z.B. bei solchen Fingerprinting-Analysen erkennen:<br />
* dass der Basis-Takt-Wert innerhalb eines charakteristischen Zeit-Bereichs liegt<br />
* dass die Anzahl der Sync-Pulse eine präzise Zahl ist<br />
* dass Längen erkannter Puls-Typen innerhalb eines Bereichs liegen<br />
<br />
Mittels solcher Untersuchungen kann man also final hoffentlich hinreichend plausibel feststellen, "dass diese Aktivitäten offensichtlich(?) zu einer Funk-Komponente Rauchmelder von Hersteller XYZ gehören müssen, und man somit weiterleiten muss an ein (möglicherweise bereits existierendes) Userdaten-Dekodier-Modul für diese Herstellerkomponente".<br />
<br />
<br />
Bei einer dann erfolgenden Demodulation des noch rohen SIGNALDuino-Strings könnte man z.B. (hoffentlich richtigerweise) annehmen, dass eine Signalpegel-Typ-Folge "13" eine binäre 1 bedeuten soll, während eine Folge "12" eine binäre 0 bedeuten soll. Man erhält aus dem Gesamt-Puls-String also nach vollständiger Demodulation eine Abfolge von vielen 0/1 Bits, die insgesamt ein Datenwort darstellen, mit einer gewissen Länge von NN bits (diese Längen-Angabe könnte übrigens - neben Namenssuche nach Hersteller oder Produkt etc. - ein wichtiges Such-Merkmal sein, ob andere Frameworks tatsächlich bereits wissen, wie Daten dieser Funk-Komponente zu dekodieren sind!). Dieses demodulierte Datenwort ist nun das finale Datenwort, welches einen Container für die Funk-Komponenten-Informationen darstellt (in diesem Container also beispielsweise enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Container erst einmal CRC- oder Crypto-verschlüsselt ist...).<br />
<br />
Man muss an dieser Stelle unbedingt sagen, dass dieses Userdaten-Datenwort (einer bestimmten Hersteller-Funk-Komponente!) natürlich bei ''jeglichen'' Transceiver-Systemen ''immer'' gleich (identisch) erkannt werden ''muss'' - an dieser Stelle ist also ganz klar, dass diese Daten an ''allgemeine'' FHEM-Module weitergeleitet (Dispatched) werden müssen, die nach Übernahme von Daten von ''jeglichen'' Transceiver-Systemen diese Daten immer auf die gleiche Weise ('''''generisch/zentral''''') für die jeweilige Hersteller-Funk-Komponente erledigen.<br />
<br />
'''Die Abfolge ist also ganz klar:'''<br />
Funk-Aktivität --> Transceiver-Gerät/Firmware (SIGNALDuino) --> maximal detailreich beschreibender Rx-Analyse-Output-String --> Fingerprinting-Grobzuordnung des (SIGNALDuino-Firmware-)Outputs (durch 00_SIGNALduino.pm) auf gerätespezifisches Verhalten --> ''generische/zentrale'' Dekodierung des gerätespezifischen Protokoll-Datenworts, in zentralen Grundsatz-Modulen wie z.B. <code>14_SD_WS.pm</code>).<br />
<br />
Und wenn dann bei einer solchen Schritte-Abfolge irgendetwas noch fehlen/unpassend sein sollte, dann muss eben entsprechendes Development an gewissen Stellen erfolgen ;-)<br />
<br />
====Minimieren (whitelist/blacklist) von unerwünschter Kommunikations-Aktivität/Einträgen====<br />
<br />
"Unknown Code" bedeutet, dass der SIGNALduino Signaldaten empfangen und diese binär interpretiert hat. Diese Meldung soll uns nun aber mitteilen, dass es dann nicht weiter verarbeitet werden kann, da kein Modul existiert (oder kein Weiterleitungs-Dispatch zu einem bereits existierenden), welches diese Daten jetzt in ihre Bedeutung umwandeln kann. <br />
:<code>sduino: Unknown code u1FFFFF0, help me!</code><br />
<br />
Außerdem kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:<br />
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code><br />
<br />
Mittlerweile sind über 50 Protokolle für den SIGNALduino definiert. Dadurch kommt es vor, dass sich ein Signal mit mehr als einem Protokoll demodulieren lässt. Meist führt dies dann zu zusätzlichen "Unknown code"-Einträgen.<br />
<br />
Derartige Einträge können mit dem Attribut WhitelistID minimiert werden. Dabei werden die Geräte, die nach Daten-Empfang tatsächlich verarbeitet werden sollen (also welche Protokolle vom FHEM Modul berücksichtigt werden), mit ihrer Protokollnummer in die WhitelistID aufgenommen.<br />
Für Protokolle, die nicht berücksichtigt werden, gibt es weder Logeinträge noch Events. Diese werden im Programmablauf nicht berücksichtigt. Das spart zum einen Ressourcen und trägt auch zur Übersichtlichkeit bei. <br />
Die Protokollnummer kann Tabelle [[#Unterst.C3.BCtzte_Ger.C3.A4te|Unterstützte Geräte]] entnommen werden (hilfreich ist es auch, wenn in den verwendeten Geräten im Internal <gerätename>_DMSG nachgesehen wird). So bedeutet beispielsweise ein Eintrag der Form <code>W50#FF553335FFBC</code> dass dann das Protokoll #50 in die Whitelist aufzunehmen wäre (<code>attr sduino whitelist_IDs 50</code>).<br />
{{Randnotiz|RNTyp=r|RNText=Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!!<br />
}}<br />
Die Angabe erfolgt durch Komma getrennt: z.B.:<br />
:<code>1,2,5,10</code><br />
<br />
=== Senden mit dem SIGNALduino ===<br />
Der SIGNALduino kann etwas "raw senden", indem ihm das SIGNAL so übermittelt wird, wie er es moduliert. Hierzu muss der Befehl wie folgt eingegeben werden:<br />
<br />
<code><br />
set sduino sendMsg P3#00111010#R4<br />
</code><br />
<br />
Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.<br />
Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits.<br />
<code><br />
sduino: extracted data 00111010 (bin)<br />
sduino: Found Protocol id 3 <br />
</code><br />
<br />
Alternativ kann das Signal auch in einer "rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig:<br />
<code><br />
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;<br />
</code><br />
<br />
R=3 bedeutet, das Signal wird 3x gesendet.<br />
Die Übertragung besteht aus den in D angegeben Pulsen, welche in P0-P5 definiert werden.<br />
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.<br />
<br />
Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.<br />
<br />
====Fehlersuche====<br />
(Zielgerät reagiert nicht, etc.)<br />
<br />
* Nachrichtenwiederholungsanzahl muss evt. für manche Geräte entsprechend groß eingestellt sein<br />
{{Randnotiz|RNTyp=r|RNText=VORSICHT blöder Schreibweisen-Mismatch ITClock vs. ITclock!!}}<br />
* Sende-Takt-Wert (Clock) passt evt. nicht ganz, siehe z.B. Thread-Antwort {{Link2Forum|Topic=58397|Message=775434|LinkText=Signalduino Version 3.3.1}}, wo für IT-Geräte ein Attribut anhand der CP= des Empfangsdaten-Logs modifiziert wird. ACHTUNG: dies kann entweder global das Internal-Attribut ITClock eines SIGNALduino-Transceiver-Devices sein, oder (viel besser da korrekt geräte-instanz-spezifische Konfiguration) das ITclock eines IT-Client-Devices.<br />
<br />
== Fehlerbehandlung ==<br />
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:<br />
:<code>set raw e</code><br />
Ob ein solcher Reset nötig ist, erkennt man an dem Inhalt vom Reading <code>cc1101_config</code>, dort unsinnige Werte angezeigt werden oder dem Reading <code>config</code> welches durch den Befehl "get config" aktualisiert wird, was im Standard auf "MS=1;MU=1;MC=1" entspricht.<br />
<br />
In der Firmware sind die diverse Befehle eingebaut, welche über einen <code>set raw</code> Befehl im Modul direkt ausgeführt werden können. Sofern möglich, sollten die Abfrage von Werten aus dem Modul allerdings mit den dafür vorgesehenen Kommandos erfolgen, da die Rückmeldungen des <code>set raw</code> Befehls nur im Logfile ab Verbose 4 erscheinen. Die Befehle sind nützlich, wenn direkt auf den Microcontroller zugegriffen wird: <br />
<br />
:<code>C<reg></code> <reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers. Example: <code>set raw C35</code> führt ab Verbose 4 zu einer Logausgabe folgender Art <code>Read, msg: C35 = 0D</code><br />
:<code>e</code> EEPROM / factory reset. resets all eeprom values without reboot<br />
:<code>W<AA><XX></code> Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die eeprom Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2 des CC1101)<br />
<br />
Die Sendeleistung lässt sich mit <br />
:<code>get sduino ccpatable</code> <br />
<br />
prüfen, wobei die Rückmeldung wie folgt zu lesen ist: <br />
"-10_dBm" => '34',<br />
"-5_dBm" => '68',<br />
"0_dBm" => '60',<br />
"5_dBm" => '84',<br />
"7_dBm" => 'C8',<br />
"10_dBm" => 'C0' <br />
Dabei wird die Sendeleistung dauerhaft mit dem Befehl<br />
:<code>set sduino cc1101_patable <value></code><br />
hochgeschaltet (<value> durch den Wert ersetzen).<br />
<br />
Weitere Firmware-Befehle sind im Thread-Beitrag {{Link2Forum|Topic=58396|Message=497921}} zu finden.<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=82379|Message=1033374|LinkText=SIGNALDuino Schaltplan}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.rflink.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]]<br />
* [[Somfy via SIGNALduino]]<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=SIGNALduino&diff=35949SIGNALduino2021-08-15T12:58:56Z<p>AndreasMohr: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Empfang und Verarbeitung von digitalen Signalen<br />
|ModType=d<br />
|ModFTopic=38402<br />
|ModCmdRef=SIGNALduino<br />
|ModForumArea=Sonstige Systeme<br />
|ModTechName=00_SIGNALduino.pm<br />
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])<br />
}}<br />
<br />
== Einleitung ==<br />
=== Übersicht ===<br />
Unter den Namen SIGNALduino versteht man sowohl den Low-Cost Empfänger für digitale Signale (vergleichbar dem [[CUL]]) als auch das gleichnamige Modul mit dem Dateinamen 00_SIGNALduino.pm. Mit dem SIGNALduino kann man entweder 433 oder 868 MHz-Geräte auslesen und ansprechen. Der SIGNALduino funktioniert auch mit anderen Medien wie Infrarot oder direkter Kabelverbindung.<br />
<br />
Der SIGNALduino(-Stick) erkennt Signale anhand von Mustern und gibt sie (als maximal detaillierte Beschreibung einer Signalabfolge) dann schlicht sofort nur noch an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben.<br />
Aufgabe des SIGNALduino (Firmware/Stick) ist es also nur, Signal-Aktivitäten zu erfassen und maximal präzise (als kurzer Text-String) zu beschreiben.<br />
Alles weitere (echte, finale Auswertung / Zuweisung dieser Signal-Daten) wird dann auf einer großen Box (Raspberry o.ä.) gemacht.<br />
<br />
=== Vorteil gegenüber einem CUL/FHEMduino ===<br />
Der SIGNALduino hat den Vorteil einer sehr schnellen Demodulation des Funksignals. Sollen weitere Protokolle dekodiert werden, so muss dazu nur ein passendes FHEM Modul entwickelt oder ein universelles Modul erweitert werden (also auf flexibel direkt updatebarer Rechner-Seite!!). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung des Sticks korrekt funktioniert - leider nicht immer, z.B.: [https://github.com/RFD-FHEM/SIGNALDuino/issues/65 MU-Nachrichten werden z.T. als MC erkannt]).<br />
<br />
Ein großer Vorteil des SIGNALduino besteht darin, dass auch Geräte mit leicht abweichenden Frequenzen steuerbar sind; so empfangen die Somfy-Rolladenmotoren beispielsweise auf 433.42 und nicht, wie bei anderen Geräten sehr oft üblich, auf 433.92 MHz. Die Frequenzumstellung stellt für den SIGNALduino kein Problem dar.<br />
<br />
Ebenso kann man den SIGNALduino direkt an den Sendeausgang eines Sensors anbinden und die digitalen Signale empfangen, dabei bitte aber auf die passenden Spannungen achten, denn ein Arduino Nano verträgt nur 5V.<br />
<br />
<br />
=== Entwicklungsversion ===<br />
Der SIGNALduino wird derzeit aktiv weiterentwickelt, siehe dazu https://github.com/RFD-FHEM. Die offizielle Version wird {{Link2Forum|Topic=58396|LinkText=hier}} genauer beschrieben. Es existieren im Forum diverse angepasste Versionen, auf die hier nicht näher eingegangen wird.<br />
<br />
== Hardware ==<br />
=== Controller ===<br />
Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden. Bei Einbindung via ESP muss man beachten, dass der ESP nach 5 Minuten Inaktivität seine TCP-Verbindung unterbricht (siehe [[ESP8266#Bekannte_Probleme|diesen Hinweis]]). Zu diesem Zweck gibt es einen Signalduino-eigenen Ping-Befehl ('get signalduino ping'), der diese Aktivität wieder aufbaut. Ping-Befehle sind auch auf Betriebssystemebene bekannt - allerdings beachte man, dass der ping-Befehl auf Betriebssystemebene ICMP verwendet, zum "Aufwachen" des ESP aber auf TCP-Ebene aktiviert werden muss (zum Unterschied siehe [https://www.tippscout.de/internet-was-sind-tcp-ip-udp-und-icmp_tipp_2268.html hier]) und man daher besser den Signalduino-eigenen Befehl und nicht das Betriebssystem verwendet.<br />
<br />
Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht dem [[Selbstbau_CUL]] (eine frühere Version ist der nicht mehr weiterentwickelte [[FHEMduino]]):<br />
* Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum [[FHEMduino]] <br />
* Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum [[Selbstbau_CUL]]. Dieser Aufbau wird derzeit empfohlen.<br />
* Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, Link zum [http://shop.in-circuit.de/index.php Hersteller]. <br />
<br />
Achten Sie beim Selbstbau auf die entsprechenden Sender-Empfänger. Der sehr preiswert angebotene XY-MK-5V hat sich als zu unzuverlässig erwiesen, während anscheinend beim CC1101 (insbesondere der "grünen Version") keine Probleme auftreten. <br />
<br />
Es stehen auch für den [https://www.arduino.cc/en/Main/arduinoBoardUno UNO] und [https://www.arduino.cc/en/Main/ArduinoBoardProMini PRO Mini] Firmware-Dateien zur Verfügung. Die ausgelieferte Firmware läuft nur auf Mikrocontrollern mit 16 MHz; wer einen Mikrocontroller mit 8 MHz verwenden möchte, muss die Firmware selbst compilieren. Die SW ist auf [https://github.com/RFD-FHEM/SIGNALDuino github]. Vorgesehen ist nur die Übersetzung unter Windows mit Visual Studio und dem Visual Micro Zusatz. Es gibt aber auch eine Anleitung, wie man mit der [[Arduino]] IDE oder einem Makefile [[SIGNALduino Compilieren]] kann.<br />
<br />
Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] nativ läuft, diese funktioniert seit Anfang 2018 annehmbar, allerdings befindet diese sich noch in einer Entwicklungsphase.<br />
<br />
An den "SIGNALESP" kann auch ein CC1101 via SPI angebunden werden:<br />
<br />
{| |<br />
!CC1101 Bezeichnung<br />
!ESP Pin<br />
|-<br />
|CLK||GPIO14<br />
|-<br />
|MOSI||GPIO13<br />
|-<br />
|MISO||GPIO12<br />
|-<br />
|CSN||GPIO15<br />
|-<br />
|GDO0||GPIO4<br />
|-<br />
|GDO2||GPIO5<br />
|}<br />
<br />
Wird eine einfache Empfänger / Sender Kombination verwendet, dann über die PINs:<br />
<br />
{| |<br />
! Bezeichnung <br />
! ESP Pin<br />
|-<br />
|Transmitter||GPIO4<br />
|-<br />
|Receiver||GPIO5<br />
|}<br />
<br />
=== Sendemodule ===<br />
{{Randnotiz|RNTyp=r|RNText=Viele user berichten über Empfangsprobleme bei Nutzung des XY-MK-5V; es wird ausdrücklich empfohlen, ein anderes Empfangsmodul zu nutzen!}}<br />
[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]] <br />
<br />
Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:<br />
* FS1000A Dies ist das Sendemodul (TX) und wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€). <br />
* RXB6 Das ist das empfohlene Empfangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.<br />
<br />
Die Verkabelung erfolgt analog zum [[FHEMduino]] und das bedeutet (Arduino -> Modul):<br />
* PIN D2 an DATA des RX-Moduls<br />
* PIN D11 an DATA des TX-Moduls (PIN links mit Beschriftung ATAD)<br />
<br />
Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.<br />
<br />
Jetzt fehlen noch die Antennen. Dafür braucht man ein 17,2 cm langes Stück Kupferdraht, das wird beim Anschluss "ANT" jeweils am Modul angelötet (anfängergeeignet).<br />
<br />
== Software ==<br />
<br />
=== USB-ID ermitteln ===<br />
Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) verbunden werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl<br />
<pre> ls -l /dev/serial/by-id </pre><br />
ausführen. Beispielhaft sieht das Ergebnis etwa so aus:<br />
<br />
''lrwxrwxrwx 1 root root 13 Jan 31 00:02 '''usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port''' -> ../../ttyUSB0''<br />
<br />
Damit ist der Anschluss des SIGNALduino bestimmt und das Gerät kann wie im nächsten Abschnitt beschrieben definiert werden. Zuvor muss noch das Modul geladen werden.<br />
<br />
=== FHEM-Modul laden ===<br />
Die SIGNALduino Module werden über das FHEM [[update]] verteilt, sobald die Änderungen einen "stabilen" und alltagstauglichen Zustand haben. Aktuell wird dort die Version 3.4.2 seit 08.04.2020 verteilt.<br />
<br />
Die in der Entwicklung befindliche Version (3.5.x, bringt z.B. Unterstützung für Geräte mit FSK-Modulation) kann mit folgenden Befehlen geladen werden:<br />
<br />
* FHEM aktualisieren: <code>update</code> <br />
* SIGNALduino Modul aktualisieren: <code>update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master<nowiki/>/controls_signalduino.txt</code> Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet.<br />
* Es empfiehlt sich, die Github-Quelle dauerhaft einzutragen: <code>update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt</code>, um weitere Entwicklungs-Updates zu bekommen und damit das nächste Standard-<code>update</code> nicht die alte Version wieder einspielt.<br />
<br />
Das Gerät kann wie folgt definiert werden (die Spezifikation des USB-Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):<br />
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code><br />
* Solltet Ihr einen SIGNALESP via IP einbinden wollen, ist die Syntax (ebenso wird auch vorgegangen wenn der SIGNALduino beispielsweise über ser2net freigeben wird):<br />
:<code>define <eigener-SIGNALESP-Name> SIGNALduino <ip-adresse>:23</code><br />
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt. Die Baudrate beim SIGNALduino beträgt 57600 - via telnet muss dann dieselbe Baudrate eingestellt werden. <br />
<br />
Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.<br />
<br />
==== Flashen des Arduino mit der SIGNALduino Firmware ====<br />
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:<br />
:<code>sudo apt-get install avrdude</code><br />
<br />
In FHEM ist der SIGNALduino mit dem Status "Open" vorhanden. Jetzt müssen wir FHEM noch mitteilen, welche Hardware wir angeschlossen haben. Über das Attribut ''hardware'' lässt sich zwischen den mitgelieferten Firmware-Dateien wechseln. Solltet ihr einen Nano mit cc1101 Transceiver verwenden, so wählt bitte folgende Hardware<br />
:<code>attr sduino hardware nanoCC1101</code><br />
sonst üblicherweise<br />
:<code>attr sduino hardware nano328</code><br />
<br />
Dann muss mitgeteilt werden, welche Version man geladen haben will: stable oder testing. <br />
:<code>attr sduino updateChannelFW testing</code><br />
Nun wird die entsprechende Firmware heruntergeladen. Dies geschieht durch den Befehl<br />
:<code>get sduino availableFirmware</code><br />
Anschließend kann der ''flash'' Befehl abgesetzt werden: <br />
:<code>set sduino flash <und-dann-auswaehlen></code><br />
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.<br />
<br />
Alternativ kann auch der Flash-Befehl mit einem Dateinamen aufgerufen werden. Diese Möglichkeit sollte jedoch nur verwendet werden, wenn die SIGNALduino Firmware selbst compiliert wurde und eine andere Hardware verwendet wird. Der Flash-Befehl wird wie folgt aufgerufen:<br />
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code><br />
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)<br />
<br />
Wenn ein miniCUL geflasht werden soll, sind einige Besonderheiten zu beachten. Details dazu in {{Link2Forum|Topic=114413|LinkText=diesem Forenthema}}.<br />
<br />
==== Flashen einer Firmware über HTTP ====<br />
Die Firmware wird nicht mehr über den FHEM Update Mechanismus verteilt. <br />
Damit die passende Firmware auf den SIGNALduino geladen werden kann, wird diese dann über HTTP aus den Github Releases geladen.<br />
<br />
==== Vorabversion einer Firmware ====<br />
Die Firmware des SIGNALduino wird ebenso wie das FHEM Modul auch weiter entwickelt.<br />
Die Entwickler sind auf Tests und Rückmeldungen der Nutzer angewiesen, da leider nicht alle Sensoren vorher getestet werden können.<br />
<br />
Die Version 3.4 ist die aktuell stabile Version.<br />
<br />
Für die folgenden Microcontroller kann man die Firmware seit 21.02.2019 auch direkt downloaden und teilweise flashen. <br />
Dazu muss das Attribut hardware auf einen gültigen Wert angepasst werden!<br />
Über den GET Befehl availableFirmware werden dann für die hinterlegte Hardware die passenden Versionen gesucht. Über das Attribut updateChannelFW kann zwischen "stable" und "testing" definiert werden, welche Art von Firmware angeboten werden soll.<br />
<br />
Nachdem die Firmwareversion erfragt wurde, bietet der set flash Befehl eine Auswahlliste an. Wird ein Flash Befehl mit einer der Versionen ausgewählt, wird diese Version zunächst heruntergeladen und bei den AVR Versionen auch versucht diese mittels avrdude zu flashen.<br />
Die Firmware für den ESP8266 kann aktuell leider noch nicht über diesen Befehl aktualisiert werden.<br />
<br />
Alternativ funktioniert aber auch die Option, dem Flash Befehl eine URL zu übergeben. Dann wird die Datei aus der URL heruntergeladen und auch versucht diese zu Flashen. z.B.<br />
SIGNALDuino_nanocc1101.hex für einen Nano mit CC1101<br />
<br />
<code>set sduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_radinocc11013.3.1.hex<br />
<br />
oder<br />
SIGNALESP_.hex (mit cc1101) für einen ESP8266 <br />
<code>set ipduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_ESP8266cc11013.3.1.hex<br />
<br />
!Achtung, aktuell wird die Firmware für den ESP dadurch nur herunter geladen. Flashen müsst ihr leider immer noch über ein passendes Tool <br />
z.B. [https://github.com/nodemcu/nodemcu-flasher ESP8266Flasher.exe] oder Esptool und einer seriellen Konsole.<br />
Auch ist zu beachten, es handelt sich hierbei tatsächlich um ein Binary und nicht um ein Hex File. <br />
<br />
Nach dem Booten des ESPs spannt dieser ein eigenes WLAN auf. Habt ihr euch damit verbunden, könnt ihr den ESP mit eurem vorhandenen WLAN nach Eingabe der Daten verbinden.<br />
<br />
Die Hauptseite für Firmware-Releases findet sich unter https://github.com/RFD-FHEM/SIGNALDuino/releases/ .<br />
Dort kann auch eine Änderungshistorie eingesehen werden.<br />
==== Flashen eines radino Boards mit ATmega32U4 ====<br />
<br />
Diese Funktion steht seit 21.02.2019 nun auch in der via FHEM aktualisierten Version zur Verfügung:<br />
<br />
Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird.<br />
Weiterhin ist zu beachten, dass der Bootloader eine andere USB ID bekommt und diese im Attribut flashCommand hinterlegt werden muss.<br />
<br />
==== Fehler beim Flashen ====<br />
Sollte bei einem Flash Vorgang ein Fehler auftreten, solltet ihr zunächst im Logfile mit Verbose 5 nachsehen.<br />
<br />
Findet ihr dort keine Fehlermeldung, gibt es noch ein separates Flashlog, welches ihr über einen Browser aufrufen könnt. Dazu müsst ihr nur den folgenden Pfad an euren Servernamen anhängen:<br />
<code><br />
/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=SIGNALduino-Flash.log<br />
</code><br />
<br />
=== Geräteerkennung ===<br />
==== Unterstützte Geräte ====<br />
Für die folgenden Geräte gibt es derzeit (2017) eine Unterstützung für den Betrieb mit FHEM. Die Geräte werden [[autocreate|automatisch erkannt]] und in der Konfiguration eingetragen, wenn der SIGNALduino läuft.<br />
Bitte Geräte mit sehr präzisen Referenzen hier listen (Produktnummer, Protokoll-Variantenname etc.), damit eine globale Suche/Verifikation maximal erfolgreich ist. In der detaillierten Liste [[Geprüfte_Geräte]] lassen sich die Geräte näher identifizieren.<br />
{| class="wikitable"<br />
! style="text-align:left;" | Produkt <br />
! (E)mpfangen<br />(S)enden <br />
! Hinweise <br />
! Verwendetes Modul <br />
! Protokoll ID<br />
|-<br />
|Conrad Wetterstation KW9110||E S||Sensor: KW9010, neben Temperatur u. Luftfeuchte werden auch Trend, Batterie u. Kanal erfasst|| CUL_TCM97001 || 0.3<br />
|-<br />
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0 <br />
|-<br />
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17<br />
|-<br />
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL || <br />
|-<br />
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10<br />
|-<br />
|Bresser Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12<br />
|-<br />
|TFA Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8<br />
|-<br />
|TFA 30320902||E || || SD_WS07 || 7<br />
|-<br />
|Eurochron eas800z||E || || SD_WS07 || 7<br />
|-<br />
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7<br />
|-<br />
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7<br />
|-<br />
|CTW600||E || || SD_WS09 || 9<br />
|-<br />
|CTW602||E ||neuere Version des CTW600 mit 868.35 MHz || SD_WS09 || 9<br />
|-<br />
|WH1080||E || || SD_WS09 || 9<br />
|-<br />
|Visivon remote pt4450||E || || none || 24<br />
|-<br />
|Einhell HS 434/6||E || || none || 21<br />
|-<br />
|Flamingo FA20RF / FA21RF / FA22RF Rauchmelder||E || || FLAMINGO || 13,13.1,13.2<br />
|-<br />
|mumbi m-FS300||E || || none || 26,27<br />
|-<br />
|TFA 30.3200||E || || none || 33<br />
|-<br />
|Livolo||E|| || none || 20<br />
|-<br />
|Smartwares RM174RF/2 (RM174RF-001CPR) 4500177571 ||E [S?]|| IT EV1527; TODO herausfinden: Alarmierung (wie Alarmton getriggered werden kann); Batterieinfo? || IT || 3<br />
|-<br />
|Smartwares SH5-TSO-A||E S|| || IT || ?<br />
|-<br />
|X10 Security Devices||E|| || || 39<br />
|-<br />
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43<br />
|}<br />
Bei einigen Intertechno-Funksteckdosen (Brennenstuhl) kann es zu Empfangsproblemen kommen. Hier muss die Taktrate, mit der gesendet wird, angepasst werden. Dazu muss für ''Funksteckdose'' (also sauber per-Client-Instanz-spezifisch, NICHT SIGNALduino-Transceiver-global) das Attribut <br />
:<code>attr <Funksteckdose> ITclock 300</code> <br />
gesetzt werden, der Standardwert ist 250.<br />
<br />
==== Mein Gerät wird in FHEM nicht erkannt ====<br />
1. Prüfen, ob vom Sensor die Signaldaten (verbose >=4) erkannt werden. Sobald ihr die empfangenen Signaldaten im Logfile zuordnen könnt, geht es weiter mit:<br />
<br />
2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues/new?template=sensor---device-feature.md github]:<br />
<!-- <syntaxhighlight lang="md"> ... markdown lexer not yet available; use pre instead --><br />
<pre><br />
## Specifications for new sensor / switch / or other device ... <br />
<br />
- manufacturer:<br />
- model name:<br />
- pictures of the device / the board (very helpful)<br />
<br />
<br />
## Specifications <br />
<br />
- Microcontroller:<br />
- Version (Firmware):<br />
<br />
<!-- ( can be found here devicename -> Internals -> version ) --><br />
- Versionmodul (FHEM Module):<br />
</pre><br />
<br />
3. Auszug aus dem Logfile, welches zum Gerät gehört.<br />
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.''<br />
<br />
Im Forum solltet ihr solche Fragen besser nicht posten, wenn das Gerät noch nicht unterstützt wird, dazu ist Github besser geeignet. Inzwischen wurde im Wiki eine eigene Seite eröffnet, die sich mit der Erkennung unbekannter Protokolle beschäftigt: [[Unbekannte_Funkprotokolle#Ansatz_1_-_Versuchen|Unbekannte_Funkprotokolle]].<br />
<br />
==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ====<br />
Im SIGNALduino sind >70 Protokolle implementiert. Jedoch gibt es nicht immer ein logisches Module, welche diese Protokolle verarbeiten.<br />
Teilweise ist das auch nicht zwingend notwendig, um seine Anforderungen zu erfüllen. Insbesondere für Schalter bzw. Sensoren, die nur zwei Zustände kennen, geht es meist ohne Modul und automatisch angelegtem Gerät.<br />
<br />
Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden.<br />
Im FHEM Log (und, insbesondere, im FHEMWEB Event Monitor) tauchen Meldungen ähnlich dieser auf<br />
<br />
<code><br />
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081<br />
</code><br />
<br />
Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:<br />
<br />
Entweder, wenn wir den Inhalt der Nachricht nur zu Teilen wissen, da er sich ändert:<br />
<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)<br />
attr mydoif do always<br />
</code><br />
<br />
Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring<br />
<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on)<br />
attr mydoif do always<br />
</code><br />
<br />
Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.<br />
<br />
Als Alternative zu DOIF hier ein regex-verwendendes notify-Beispiel für einen Sender, der meint, zwei Codes alternierend senden zu müssen:<br />
<br />
<code><br />
define n_sender_trigger notify sduino:UNKNOWNCODE.*u41#(13B72253|163873B3) { my_sender_trigger_indicate();; }<br />
</code><br />
<br />
Selbstverständlich muss in diesem Moment auch eine sub my_sender_trigger_indicate() definiert werden (z.B. in FHEM/99_myUtils.pm), die dort z.B. als Test eine Log-Ausgabe (Log3()) machen kann.<br />
<br />
=== Das Logfile ===<br />
Im Logfile ab [[Verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (verbose 3 unterdrückt diese Meldungen).<br />
<br />
UPDATE: der folgende Bereich ist von einem weniger erfahrenen Zeitgenossen früher nach Kräften erweitert/geschrieben worden. Mittlerweile existiert aber ein neuer Inhalt [[Unbekannte_Funkprotokolle]] (siehe auch Erwähnung weiter oben), der als sehr gut beschrieben und unvergleichlich detailreicher bezeichnet werden muss ("endlich gibt es sowas!"). Der Bereich hier dürfte somit zwar für grundlegende Verdeutlichungen noch recht sinnvoll sein, der Inhalt sollte allerdings evt. in eine konsistente Dokumentation überarbeitet (verlagert/dedupliziert/reduziert) werden.<br />
<br />
Die Protokolle (von der SIGNALDuino-Firmware gesendete Signal-Beschreibungs-Strings) können wie folgt unterschieden werden:<br />
<br />
*MS - Nachricht mit Sync Puls: Hierzu ein Beispiel<br />
:<code>MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;</code> P0-P6 sind die Signalpegel (Dauer und positiv/negativ). Hinter D= befindet sich die Abfolge der Signale. Die ersten beiden Ziffern 15 in D sind wie folgt zu lesen. Zuerst wurde ein Signal "1" also P1 mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal "5" also P5 mit 8916 Mikrosekunden low (die Zeitdauer ergibt sich aufgrund der Mitteilung "P5=-8916") gemessen. CP=1 ist die Referenz auf den Takt des Signales - der Basistakt ist in diesem Fall ~395 Mikrosekunden. SP=5 gibt die Referenz zum Syncpuls an, der das gesamte Signal einleitet. Welche Signalfolge nun eine binäre 1 bzw. 0 bedeutet, wird im SIGNALduino über die integrierte Protokoll Liste realisiert.<br />
<br />
*MC - Nachricht vom Typ Manchester: Manchesterkodierte Signale können bereits sehr einfach im Arduino in eine Binärform umgewandelt werden. Es wird hier nach IEEE 802.3 umgewandelt. In Manchester Signalen gibt es lange und kurze Pulse. Deren Durchschnittswert wird mit LL (long low), LH (long high), SL (short low) und SH (short high) übermittelt. Zusätzlich, um das Protokoll schneller erkennen zu können, wird die Taktfrequenz mit übermittelt (C=429 Mikrosekunden). Die Daten befinden sich hinter D= und werden in HEX Form übergeben.<br />
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code><br />
<br />
*MU - Message unsynced: Diese Art von Nachrichten sind nicht nach Manchester codiert und haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht. Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist. Wie bei MS sind P0-P6 die Signalpegel und in D= wird die Abfolge der Signalpegel referenziert. CP=2 gibt auch hier die Referenz zum Takt an, allerdings muss dieser nicht korrekt erkannt worden sein.<br />
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code><br />
<br />
Es erscheinen viele Meldungen dieser Art:<br />
<br />
<pre><br />
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate<br />
</pre><br />
<br />
Dies sind nun Bemühungen, anhand der von der SIGNALDuino-Firmware gelieferten rohen aber detaillierten Signal-Strings eine Vor-Analyse / Fingerprinting vorzunehmen.<br />
Man könnte nun z.B. bei solchen Fingerprinting-Analysen erkennen:<br />
* dass der Basis-Takt-Wert innerhalb eines charakteristischen Zeit-Bereichs liegt<br />
* dass die Anzahl der Sync-Pulse eine präzise Zahl ist<br />
* dass Längen erkannter Puls-Typen innerhalb eines Bereichs liegen<br />
<br />
Mittels solcher Untersuchungen kann man also final hoffentlich hinreichend plausibel feststellen, "dass diese Aktivitäten offensichtlich(?) zu einer Funk-Komponente Rauchmelder von Hersteller XYZ gehören müssen, und man somit weiterleiten muss an ein (möglicherweise bereits existierendes) Userdaten-Dekodier-Modul für diese Herstellerkomponente".<br />
<br />
<br />
Bei einer dann erfolgenden Demodulation des noch rohen SIGNALDuino-Strings könnte man z.B. (hoffentlich richtigerweise) annehmen, dass eine Signalpegel-Typ-Folge "13" eine binäre 1 bedeuten soll, während eine Folge "12" eine binäre 0 bedeuten soll. Man erhält aus dem Gesamt-Puls-String also nach vollständiger Demodulation eine Abfolge von vielen 0/1 Bits, die insgesamt ein Datenwort darstellen, mit einer gewissen Länge von NN bits (diese Längen-Angabe könnte übrigens - neben Namenssuche nach Hersteller oder Produkt etc. - ein wichtiges Such-Merkmal sein, ob andere Frameworks tatsächlich bereits wissen, wie Daten dieser Funk-Komponente zu dekodieren sind!). Dieses demodulierte Datenwort ist nun das finale Datenwort, welches einen Container für die Funk-Komponenten-Informationen darstellt (in diesem Container also beispielsweise enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Container erst einmal CRC- oder Crypto-verschlüsselt ist...).<br />
<br />
Man muss an dieser Stelle unbedingt sagen, dass dieses Userdaten-Datenwort (einer bestimmten Hersteller-Funk-Komponente!) natürlich bei ''jeglichen'' Transceiver-Systemen ''immer'' gleich erkannt werden ''muss'' - an dieser Stelle ist also ganz klar, dass diese Daten an ''allgemeine'' FHEM-Module weitergeleitet (Dispatched) werden müssen, die nach Übernahme von Daten von ''jeglichen'' Transceiver-Systemen diese Daten immer auf die gleiche Weise ('''''generisch/zentral''''') für die jeweilige Hersteller-Funk-Komponente erledigen.<br />
<br />
'''Die Abfolge ist also ganz klar:'''<br />
Funk-Aktivität --> Transceiver-Gerät/Firmware (SIGNALDuino) --> maximal detailreich beschreibender Rx-Analyse-Output-String --> Fingerprinting-Grobzuordnung des (SIGNALDuino-Firmware-)Outputs (durch 00_SIGNALduino.pm) auf gerätespezifisches Verhalten --> ''generische/zentrale'' Dekodierung des gerätespezifischen Protokoll-Datenworts, in zentralen Grundsatz-Modulen wie z.B. <code>14_SD_WS.pm</code>).<br />
<br />
Und wenn dann bei einer solchen Schritte-Abfolge irgendetwas noch fehlen/unpassend sein sollte, dann muss eben entsprechendes Development an gewissen Stellen erfolgen ;-)<br />
<br />
====Minimieren (whitelist/blacklist) von unerwünschter Kommunikations-Aktivität/Einträgen====<br />
<br />
"Unknown Code" bedeutet, dass der SIGNALduino Signaldaten empfangen und diese binär interpretiert hat. Diese Meldung soll uns nun aber mitteilen, dass es dann nicht weiter verarbeitet werden kann, da kein Modul existiert (oder kein Weiterleitungs-Dispatch zu einem bereits existierenden), welches diese Daten jetzt in ihre Bedeutung umwandeln kann. <br />
:<code>sduino: Unknown code u1FFFFF0, help me!</code><br />
<br />
Außerdem kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:<br />
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code><br />
<br />
Mittlerweile sind über 50 Protokolle für den SIGNALduino definiert. Dadurch kommt es vor, dass sich ein Signal mit mehr als einem Protokoll demodulieren lässt. Meist führt dies dann zu zusätzlichen "Unknown code"-Einträgen.<br />
<br />
Derartige Einträge können mit dem Attribut WhitelistID minimiert werden. Dabei werden die Geräte, die nach Daten-Empfang tatsächlich verarbeitet werden sollen (also welche Protokolle vom FHEM Modul berücksichtigt werden), mit ihrer Protokollnummer in die WhitelistID aufgenommen.<br />
Für Protokolle, die nicht berücksichtigt werden, gibt es weder Logeinträge noch Events. Diese werden im Programmablauf nicht berücksichtigt. Das spart zum einen Ressourcen und trägt auch zur Übersichtlichkeit bei. <br />
Die Protokollnummer kann Tabelle [[#Unterst.C3.BCtzte_Ger.C3.A4te|Unterstützte Geräte]] entnommen werden (hilfreich ist es auch, wenn in den verwendeten Geräten im Internal <gerätename>_DMSG nachgesehen wird). So bedeutet beispielsweise ein Eintrag der Form <code>W50#FF553335FFBC</code> dass dann das Protokoll #50 in die Whitelist aufzunehmen wäre (<code>attr sduino whitelist_IDs 50</code>).<br />
{{Randnotiz|RNTyp=r|RNText=Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!!<br />
}}<br />
Die Angabe erfolgt durch Komma getrennt: z.B.:<br />
:<code>1,2,5,10</code><br />
<br />
=== Senden mit dem SIGNALduino ===<br />
Der SIGNALduino kann etwas "raw senden", indem ihm das SIGNAL so übermittelt wird, wie er es moduliert. Hierzu muss der Befehl wie folgt eingegeben werden:<br />
<br />
<code><br />
set sduino sendMsg P3#00111010#R4<br />
</code><br />
<br />
Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.<br />
Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits.<br />
<code><br />
sduino: extracted data 00111010 (bin)<br />
sduino: Found Protocol id 3 <br />
</code><br />
<br />
Alternativ kann das Signal auch in einer "rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig:<br />
<code><br />
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;<br />
</code><br />
<br />
R=3 bedeutet, das Signal wird 3x gesendet.<br />
Die Übertragung besteht aus den in D angegeben Pulsen, welche in P0-P5 definiert werden.<br />
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.<br />
<br />
Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.<br />
<br />
====Fehlersuche====<br />
(Zielgerät reagiert nicht, etc.)<br />
<br />
* Nachrichtenwiederholungsanzahl muss evt. für manche Geräte entsprechend groß eingestellt sein<br />
{{Randnotiz|RNTyp=r|RNText=VORSICHT blöder Schreibweisen-Mismatch ITClock vs. ITclock!!}}<br />
* Sende-Takt-Wert (Clock) passt evt. nicht ganz, siehe z.B. Thread-Antwort {{Link2Forum|Topic=58397|Message=775434|LinkText=Signalduino Version 3.3.1}}, wo für IT-Geräte ein Attribut anhand der CP= des Empfangsdaten-Logs modifiziert wird. ACHTUNG: dies kann entweder global das Internal-Attribut ITClock eines SIGNALduino-Transceiver-Devices sein, oder (viel besser da korrekt geräte-instanz-spezifische Konfiguration) das ITclock eines IT-Client-Devices.<br />
<br />
== Fehlerbehandlung ==<br />
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:<br />
:<code>set raw e</code><br />
Ob ein solcher Reset nötig ist, erkennt man an dem Inhalt vom Reading <code>cc1101_config</code>, dort unsinnige Werte angezeigt werden oder dem Reading <code>config</code> welches durch den Befehl "get config" aktualisiert wird, was im Standard auf "MS=1;MU=1;MC=1" entspricht.<br />
<br />
In der Firmware sind die diverse Befehle eingebaut, welche über einen <code>set raw</code> Befehl im Modul direkt ausgeführt werden können. Sofern möglich, sollten die Abfrage von Werten aus dem Modul allerdings mit den dafür vorgesehenen Kommandos erfolgen, da die Rückmeldungen des <code>set raw</code> Befehls nur im Logfile ab Verbose 4 erscheinen. Die Befehle sind nützlich, wenn direkt auf den Microcontroller zugegriffen wird: <br />
<br />
:<code>C<reg></code> <reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers. Example: <code>set raw C35</code> führt ab Verbose 4 zu einer Logausgabe folgender Art <code>Read, msg: C35 = 0D</code><br />
:<code>e</code> EEPROM / factory reset. resets all eeprom values without reboot<br />
:<code>W<AA><XX></code> Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die eeprom Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2 des CC1101)<br />
<br />
Die Sendeleistung lässt sich mit <br />
:<code>get sduino ccpatable</code> <br />
<br />
prüfen, wobei die Rückmeldung wie folgt zu lesen ist: <br />
"-10_dBm" => '34',<br />
"-5_dBm" => '68',<br />
"0_dBm" => '60',<br />
"5_dBm" => '84',<br />
"7_dBm" => 'C8',<br />
"10_dBm" => 'C0' <br />
Dabei wird die Sendeleistung dauerhaft mit dem Befehl<br />
:<code>set sduino cc1101_patable <value></code><br />
hochgeschaltet (<value> durch den Wert ersetzen).<br />
<br />
Weitere Firmware-Befehle sind im Thread-Beitrag {{Link2Forum|Topic=58396|Message=497921}} zu finden.<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=82379|Message=1033374|LinkText=SIGNALDuino Schaltplan}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.rflink.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]]<br />
* [[Somfy via SIGNALduino]]<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=CUL&diff=33322CUL2020-06-01T14:53:26Z<p>AndreasMohr: /* Harter Lockup des CUL */</p>
<hr />
<div>'''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist ein RF-Gerät im Formfaktor eines USB-Dongles mit externer [[CUL Ausstattung|Antenne]]. Die über das ISM/SRD Band empfangenen Daten werden durch einen Onboard 8&nbsp;bit Atmel Prozessor vorverarbeitet. Mit verfügbarer quelloffener [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS sowie durch kurzfristige Umschaltung auf 433&nbsp;MHz Intertechno (z.&nbsp;B. viele Baumarkt Funksteckdosen) Protokolle. <br />
<br />
Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") wird die Dekodierung der per AM in 1&nbsp;kHz übertragenen Signale per [[#FW|culfw]] auf dem Atmel Prozessor direkt erledigt und dann per USB an den Hostrechner weitergegeben.<br />
<br />
Das CUL kann mittels des CULModuls von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.<br />
<br />
Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version&#160;3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}<br />
<br />
Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z.&nbsp;B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.<br />
<br />
Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.<br />
<br />
Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.<br />
<br />
Obwohl die eigentliche Betriebsfrequenz der FHT und FS20-Komponenten 868,35 MHz ist, ist bei den aktuellen CUL Firmwareversionen zum Betrieb mit FHEM die Frequenz auf 868,30 MHz eingestellt. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.<br />
<br />
Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen. Da diese Funktionen durch die culfw (Firmware) bereitgestellt werden, funktionieren sie auf allen Geräten, die die culfw verwenden ([[CUNO]], [[COC]], CSM):<br />
<br />
* Ist Empfang eingeschaltet ?<br />
*: <code> get myCUL raw C35</code> (13 = ja, z.&nbsp;b.: C35 = 0D / 13)<br />
* Auslesen der culfw Version:<br />
*: <code>get myCUL raw V</code><br />
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)<br />
*: <code>set myCUL raw l00</code><br />
* LED einschalten<br />
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen<br />
* LED soll blinken (einmal in der Sekunde)<br />
*: <code>set myCUL raw l02</code><br />
* Reboot / Reset des CUL:<br />
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=&gt; neue Firmware)<br />
* Freie CUL Sendezeit ([[1% Regel]]):<br />
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots<br />
* Freie Kapazität des FHT Buffers<br />
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a<br />
* Inhalt des FHT Buffers<br />
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes gross, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer<br />
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]<br />
*: <code> get myCUL raw T01</code> <br />
* Eingestellte Frequenz, Bandbreite etc. Ausgeben<br />
*: <code> get myCUL ccconf</code>. <br>Rückgabe z.&nbsp;B.: <br><code><nowiki>myCUL ccconf =&gt; freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code><br />
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):<br />
*:<code>set myCUL bWidth 464</code><br />
* Einstellen der Sendestärke:<br />
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.<br />
<br />
Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen<br />
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. <br />
<br />
Werte x00-x04 sind '''mit''' Ramping (''sanften'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z.&nbsp;B. [[RFR CUL]], da die CULs Rampingsingnale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl). <br />
<br />
<br />
<br />
<br />
'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).<br />
<br />
Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit&#160;:<br />
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt<br />
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet<br />
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet<br />
* <code>set CUL1 raw X80</code> RSSI / Signalstaerke jeder Flanke wird gemeldet<br />
* <code>set CUL1 raw X21</code> normal Modus<br />
<br />
Achtung: Auf Gross- und Kleinschreibung des "x,X" achten!<br />
<br />
Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.<br />
<br />
== Versionen ==<br />
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.<br />
<br />
* CUL V1 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.<br />
* CUL V2 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.<br />
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kByte EEPROM). Voll einsatzfähig.<br />
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM 32 kB Flashmemory, 1 kByte EEPROM. Voll einsatzfähig. Genau genommen ein "Sparmodell" des V3, um Lieferengpässe des atmega32u4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.<br />
<br />
Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.<br />
<br />
== Firmware {{Anker|FW}} ==<br />
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der<br />
* [http://culfw.de CUL Firmware Homepage]<br />
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.<br />
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der<br />
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]<br />
Hier kann man sich z.B. mit<br />
<syntaxhighlight lang=bash><br />
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw<br />
</syntaxhighlight><br />
die aktuelle Version laden.<br />
<br />
Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:<br />
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.<br />
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.<br />
<br />
Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).<br />
<br />
Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.<br />
<br />
== Sendefrequenz ==<br />
Das CUL gibt es in Ausführungen für 868 und 433 MHz. <br />
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der wesentliche Unterschied der 868 und 433 MHz CULs ist ein auf die Frequenz richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.<br />
<br />
Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.<br />
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.<br />
<br />
== Antenne ==<br />
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.<br />
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.<br />
<br />
Wichtig ist nur die Länge. Diese muss vorteilhafterweise so groß sein wie ein Viertel der Wellenlänge der Frequenz ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Leistung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.<br />
<br />
Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar ("Lambda") lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").<br />
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.<br />
<br />
Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser. <br />
<br />
Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.<br />
<br />
Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4&nbsp;GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.<br />
<br />
== Antennenlänge ==<br />
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch eine Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.<br />
<br />
Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:<br />
868,35 MHz (z.B. HM, FS20, FHT …)<br />
1/4 Lambda = 8,63 Zentimeter <br />
1/2 Lambda = 17,26 Zentimeter <br />
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)<br />
<br />
433,92 MHz (z.B. Intertechno …)<br />
1/4 Lambda = 17,27 Zentimeter <br />
1/2 Lambda = 34,54 Zentimeter <br />
<br />
Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:<br />
<br />
8,6 Zentimeter als 1/4 Lambda für 868,35 MHz<br />
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz<br />
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz<br />
<br />
== Bekannte Probleme ==<br />
<br />
=== RF-Tuning ===<br />
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z.&nbsp;B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern z.&nbsp;B. der FHT Raumregler zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.<br />
<br />
Bei Empfangsproblemen von z.&nbsp;B. HEM-Sensoren oder dem S300TH kann man folgendes testen:<br />
<br />
* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.<br />
*: <code>set CUL freq 868.350</code><br />
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.<br />
*: <code>set CUL sens 8</code><br />
* Oft hilft auch, die Bandbreite auf z.&nbsp;B. 464 kHz aufzuweiten.<br />
*: <code>set CUL bWidth 464</code><br />
<br />
=== Übertragungs-Stall nach zu vielen Einträgen in der Queue ===<br />
<br />
Ich habe mich ewig damit rumgeärgert, dass die Übertragung zu bestimmten häufig angesprochenen Geräten zusammenbrach, sobald die Queue zu lang wurde (FHEM: 'list CUL').<br />
Irgendwann habe ich dann zufällig herausgefunden, dass dieses sehr fragwürdige Anwachsen der Queue an einer krassen [[Sendpool]]-Fehlkonfiguration lag: ich hatte dort ein Transceiver-Device mit angegeben, welches den [[Sendpool]]-Mechanismus (noch) gar nicht unterstützt!<br />
Sobald ich dieses falsche Gerät aus der Sendpool-Element-Liste entfernt hatte, war Ruhe --> BUG im Modul (es kann nicht sein, dass ein Device ohne [[Sendpool]]-Support das Queue-Handling so zerschießt). Dieser Bug existiert allerdings wohl weiterhin (das Perl-Handling war mir etwas zu verwirrend, um direkt zu sehen, wo das Problem ist) --> sollte nachgestellt und gefixt werden.<br />
<br />
=== Harter Lockup des CUL ===<br />
<br />
Trotz behobenem (erkanntem) Queue-Problem gibt es weiterhin Probleme ("Problem #2"): es passiert - recht selten -, dass sich der nanoCUL komplett aufhängt, mit hektisch blinkender LED.<br />
Es ist in diesem Fall noch nicht einmal mit dem Reset-Taster möglich, den Stick zu resetten - es ist also tatsächlich nötig, das USB-Kabel komplett zu ziehen. Wenigstens automatisieren lassen würde sich dieser Workaround wohl per uhubctl ([https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux]).<br />
Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.<br />
<br />
Device-Attribute wie version etc. könnten evt. den Zeitpunkt der letzten Aktivität verdeutlichen; dann im FHEM-Log um diesen Zeitpunkt herum suchen, um Auffälligkeiten/Spezialitäten zu erkennen. Und dann muss man, wenn man Pech hat, eine custom culfw bauen, die entsprechendes Reporting mit eingebaut hat...<br />
<br />
(nanoCUL; V 1.26.00 a-culfw Build: 267).<br />
<br />
UPDATE: die Lösung des Problems steht evt. im Forum (Lockup beseitigt durch Optiboot bootloader): [https://forum.fhem.de/index.php/topic,73144.msg977406.html?PHPSESSID=2lj93g4vn277qhm2bfpvfpgntr#msg977406 {Gelöst} Nanocul LED blinkt schnell].<br />
[https://www.ebay.de/itm/1-3-mal-Flash-Service-fur-ZigBee-nanoCUL-JeeLink-Shelly-Sonoff-Blitzwolf-Gosund/264472055531] scheint das zu bestätigen:<br />
"Weiterhin bieten wir beim nanoCUL an, einen alternativen Bootloader (Optiboot Bootloader) zu flashen.<br />
Dieser verhindert das Abstürzen des nanoCUL's im Betrieb z.B. bei FHEM. (Stichwort: opened)"<br />
<br />
Evt. ist auch ein USB-Port-Reset ein funktionierender Workaround (bitte Text als bestätigt umformulieren, falls das hilft): [https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html], erwähnt von [https://forum.fhem.de/index.php/topic,77380.msg783352.html#msg783352].<br />
<br />
== Selbstbau-/Bastelprojekte ==<br />
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:<br />
* [[Selbstbau CUL]]<br />
* [[FHEMduino]]<br />
* [[SIGNALduino]]<br />
* [[MapleCUN]] mit STM32 Mikrocontroller<br />
<br />
== Links ==<br />
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]<br />
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im [http://forum.fhem.de/index.php FHEM Forum] ergänzt/ersetzt<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:CUL|!]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Update&diff=33111Update2020-05-02T08:28:40Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>{{SEITENTITEL:update}}<br />
{{Infobox Modul<br />
|ModPurpose=Befehl zur Aktualisierung der FHEM-Installation<br />
|ModType=cmd<br />
|ModCmdRef=update<br />
|ModForumArea=Sonstiges<br />
|ModTechName=98_update.pm<br />
|ModOwner=rudolfkoenig ([http://forum.fhem.de/index.php?action=profile;u=8 Forum] / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])<br />
}}<br />
[[update]] ist ein Befehl zur Aktualisierung der FHEM-Installation direkt über das FHEM [[FHEMWEB|Webfrontend]]. Von den Entwicklern bis zu einem bestimmten Zeitpunkt freigegebene Änderungen sind jeweils morgens ab 8:00 Uhr über die Update Funktion verfügbar. Änderungen, die später freigegeben werden, werden dementsprechend erst am nächsten Tag verfügbar.<br />
<br />
== Syntax ==<br />
:<code><nowiki>update [<fileName>|all|check|force] [http://.../controlfile]</nowiki></code><br />
oder<br />
:<code><nowiki>update [add source|delete source|list|reset]</nowiki></code><br />
<br />
'''Hinweise:'''<br />
* FHEM sichert mit den Standardeinstellungen während des Updates "nur" die aktualisierten Modul(Installations-)dateien und bei Standardinstallationen ({{Link2Forum|Topic=59669|Message=511367}}) ab Updatestand 29.10.2016 die [[Konfiguration]] und fhem.save, aber beispielsweise nicht [[Plots erzeugen|Plots]] oder [[FileLog]]s. Soll vor dem Update ein vollständiges Backup von FHEM erstellt werden, muss das mit dem Attribut <code>[[#backup_before_update|backup_before_update]]</code> eingeschaltet werden.<br />
* Lesen Sie aufmerksam die nach dem Update auf dem Monitor erscheinenden Meldungen zu Neuerungen und Änderungen.<br />
* Nach einem Update ist immer ein ''shutdown restart'' erforderlich.<br />
* geänderte und neu eingecheckte Module werden grundsätzlich erst am Folgetag ab ca. 8.00 Uhr durch den Update-Befehl verteilt.<br />
* Mit dem Befehl [[version]] lässt sich die Version einzelner oder aller benutzten Module bestimmen.<br />
<br />
== Parameter ==<br />
Details zu Parametern des update Befehls:<br />
<br />
=== Standardaufrufe ===<br />
==== update ====<br />
Die ganze FHEM-Installation wird auf die neueste Version gebracht. Vorhandene Module werden akualisiert und neue Module installiert.<br />
<br />
==== update check ====<br />
Es werden alle Module aufgelistet, von denen eine neuere als die bereits installierte Version verfügbar ist. Es wird nicht installiert.<br />
<br />
==== update force ====<br />
Das Update wird erzwungen (falls es beim regulären ''update'' Probleme geben sollte). Dieser Befehl ist nur mit Bedacht und ausschließlich im Notfall einzusetzen. Sollte ein reproduzierbares Problem existieren, dies bitte im FHEM-Forum berichten, damit dem nachgegangen werden kann.<br />
<br />
==== update &lt;Dateiname&gt; ====<br />
Mit z.B. <code>update 02_HTTPSRV.pm</code> wird nur von der Datei ''02_HTTPSRV.pm'' eine neue Version installiert. Alle anderen FHEM-Dateien werden nicht angetastet.<br />
<br />
==== update all ====<br />
Alle [[Systemübersicht#Module|offiziellen Module]] von FHEM sind in einem gemeinsamen Repository gespeichert. Nur diese Module werden in der Standardeinstellung durch den update-Befehl mit den bisher aufgeführten [[#Standardaufrufe|Standardaufrufen]] aktualisiert bzw. installiert. Einige Entwickler stellen ihre Module jedoch aus verschiedensten Gründen nicht im gemeinsamen Repository zur Verfügung, sondern nutzen eigene, separate Repositorys. Diese sogenannten "Thirdparty-Module" (auch bezeichnet als inoffizielle Module) können ebenfalls über update installiert und aktualisiert werden, wenn der Entwickler eine sogenannte Kontrolldatei (controlfile) in seinem Repository zur Verfügung stellt.<br />
<br />
Zur Installation bzw. Update jedes einzelnen Thirdparty-Moduls ist nachfolgender Befehl aufzurufen (Webadresse und Kontrolldateiname sind modulabhängig passend zu ersetzen):<br />
<code><nowiki>update all http://thirdparty.com/controls_funnymodule.txt</nowiki></code><br />
<br />
Die in den vorherigen Abschnitten erläuterten Standardaufruf (bis auf <code>update</code>) können durch Ergänzung um Webadresse und Kontrolldateiname (<nowiki>http://.../controlfile</nowiki> beim Befehls-Aufruf für das Update von einzelnen Thirdparty-Modulen genutzt werden.<br />
<br />
=== Repository-Verwaltung ===<br />
In den Standardeinstellungen von FHEM ist für jedes einzelne Repository ein separater Aufruf der [[#Standardaufrufe|Standardaufrufe]] zur Aktualiserung/Installation notwendig. Zur Vereinfachung des Update-Prozesses hat der update-Befehl eine eingebaute Repository-Verwaltung. Mittels der Repository-Verwaltung lassen sich die Standardaufrufe so beeinflussen, dass mit einem einzigen Aufruf sowohl die Module aus dem FHEM-Repository als auch aus verschiedenen Thirdparty-Repositorys beim Update berücksichtigt werden.<br />
<br />
==== update add ====<br />
Fügt ein zusätzliches Repository zur vereinfachten Nutzung über die Standardaufrufe hinzu. Ein Aufruf von <code><nowiki>update <Dateiname>|all|check|force</nowiki></code> berücksichtigt dann automatisch neben dem FHEM-eigenen Repository auch das hinzugefügte "Thirdparty-Repository". <br />
<br />
Nach dem Hinzufügen durch beispielsweise <code><nowiki>update add http://thirdparty.com/controls_funnymodule.txt</nowiki></code> entfällt somit der manuelle Aufruf der Form <code><nowiki>update all http://thirdparty.com/controls_funnymodule.txt</nowiki></code> zur Aktualiserung. Er kann aber weiterhin genutzt werden, um ausschließlich für ein bestimmtes Repository ein Update zu erhalten und und nicht für alle.<br />
<br />
Die Liste der Repositorys wird in der Verwaltungsdatei FHEM/controls.txt gespeichert.<br />
<br />
==== update delete ====<br />
Entfernt eine Repository aus der Verwaltungsdatei.<br />
<br />
==== update list ====<br />
Listet alle in der Verwaltungsdatei enthaltenen Repositorys auf.<br />
<br />
==== update reset ====<br />
Entfernt alle Fremd-Repositorys aus der Verwaltungsdatei. Nur das eigene Repository von FHEM wird noch von den Standardparametern berücksichtigt.<br />
<br />
==== Syntax controlfile ====<br />
Das Controlfile für thirdparty Module unterliegt einer festen Syntax. In jeder Zeile steht ein Dateiname und ein Befehl, was damit passieren soll. Ein Zeilenumbruch wird durch ein \n dargestellt.<br />
<br />
Es können drei Befehle verwendet werden: CRE, MOV und UPD.<br />
<br />
===== CRE - Anlegen einer Datei =====<br />
<br />
Hiermit können vom Entwickler Dateinamen festgelegt und entsprechende Initial-Dateien verteilt werden; der Inhalt der Datei liegt nach dem ''ersten'' Verteilen in Anwenderhänden (z.B. nützlich bei *-user.css-Dateien).<br />
<br />
<code>CRE <Datum> <Dateigröße> <Datei inkl. Pfad> </code><br />
<br />
Das Anlegen wird nur ausgeführt, wenn <br />
* die Datei noch nicht vorhanden ist.<br />
<br />
===== MOV - Verschieben oder Umbenennen einer Datei =====<br />
<br />
<code>MOV <Quelldatei inkl. Pfad> <Zieldatei inkl. Pfad> </code><br />
<br />
Da Dateien nicht vollständig gelöscht werden können, kann eine Datei mit dem MOV Befehl in einen speziellen Ordner namens "unused" verschoben werden:<br />
<br />
<code>MOV <Quelldatei inkl. Pfad> unused </code><br />
<br />
===== UPD - Aktualisieren einer Datei =====<br />
<br />
<code>UPD <Datum> <Dateigröße> <Datei inkl. Pfad> </code><br />
<br />
Die Aktualisierung wird nur ausgeführt, wenn <br />
* das Datum der lokalen Datei sich vom Datum der Update-Datei unterscheidet.<br />
* die Dateigröße der Update-Datei mit der Dateigröße im UPD Eintrag übereinstimmt.<br />
<br />
Beispiel:<br />
<br />
<code><br />
UPD 2018-10-04_20:17:35 55143 FHEM/55_MyFirstFile.pm<br />
<br />
UPD 2018-09-27_23:26:21 17121 FHEM/55_MySecondFile.pm<br />
</code><br />
<br />
Beispiel für die Erzeugung der UPD Einträge:<br />
<br />
<syntaxhighlight lang="perl"><br />
#!/usr/bin/perl<br />
<br />
use File::Basename;<br />
use POSIX qw(strftime);<br />
use strict;<br />
<br />
my @filenames = ( "55_MyFirstFile.pm",<br />
"55_MySecondFile.pm");<br />
<br />
my $prefix = "FHEM";<br />
my $filename = "";<br />
foreach $filename (@filenames)<br />
{<br />
my @statOutput = stat($prefix."/".$filename);<br />
<br />
if (scalar @statOutput != 13)<br />
{<br />
printf("error: stat has unexpected return value for ".$prefix."/".$filename."\n");<br />
next;<br />
}<br />
<br />
my $mtime = $statOutput[9];<br />
my $date = POSIX::strftime("%Y-%m-%d", localtime($mtime));<br />
my $time = POSIX::strftime("%H:%M:%S", localtime($mtime));<br />
my $filetime = $date."_".$time;<br />
<br />
my $filesize = $statOutput[7];<br />
<br />
printf("UPD ".$filetime." ".$filesize." ".$prefix."/".$filename."\n");<br />
}<br />
</syntaxhighlight><br />
<br />
== Attribute ==<br />
Zur weiteren Beeinflussung der Funktionsweise des update Befehls können Attribute verwendet werden. Diese müssen für das Objekt ''global'' gesetzt werden, also mit einem Konfigurationsbefehl der Art<br />
:<code>attr global ...</code><br />
<br />
=== backup_before_update ===<br />
siehe auch [[backup]]<br />
<br />
=== restoreDirs ===<br />
siehe [[#Rücksichern beim Update überschriebener Dateien|Rücksichern beim Update überschriebener Dateien]]<br />
<br />
=== exclude_from_update ===<br />
Mit der Definition <br />
:<code>attr global exclude_from_update ...</code><br />
kann eine Liste von Dateien spezifiziert werden, die bei der Ausführung des update Befehls '''nicht''' aktualisiert werden sollen. Dateien können auch über reguläre Ausdrücke definiert werden, die einzelnen Einträge werden durch Leerzeichen voneinander getrennt.<br />
<br />
Einen Spezialfall stellt die ''commandref'' dar, die seit einer Modifikation des Update Prozesses (März 2015, beschrieben in dieser {{Link2Forum|Topic=34450|LinkText=Forendiskussion}}) nicht mehr heruntergeladen wird, sondern auf dem Benutzersystem durch Extraktion der Dokumentation aus den einzelnen Modulen generiert wird, angezeigt durch die Meldung im fhem.log: <br />
:''Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while''. <br />
Sollte dieser Prozess (z.B. auf einem langsamen Rechner) zu lange dauern, bleibt die Meldung <br />
:''update finished, "shutdown restart" is needed to activate the changes.'' <br />
aus. Wird ''commandref'' in das <code>exclude_from_update</code> Attribut eingetragen, entfällt dieser Schritt, die lokale ''commandref'' wird allerdings dann auch nicht mehr aktualisiert. Die modulspezifische Hilfe, die z.B. über <code>help modulname</code> aufgerufen werden kann, ist davon nicht betroffen.<br />
<br />
== Anwendungsbeispiel / Problembehebung ==<br />
=== Durchführung eines Updates ===<br />
Zunächst kann mit dem Befehl<br />
:<code>update check</code><br />
überprüft werden, ob es überhaupt ein neues Update gibt und welche Dateien hierbei ausgetauscht würden (die angezeigten Infos sollten in einer Textdatei gesichert werden. Mit diesen Infos kann gezielter nach Problemen, die vielleicht nach einem Update auftreten, gesucht werden). Anschließend kann mittels:<br />
:<code>update</code><br />
das Update eingespielt werden. Hierbei ist zu beachten, dass die Befehle auf der FHEM Webseite oben ([[Konfiguration|Befehls-Eingabefeld]]) eingegeben werden und anschließend die "Enter" Taste auf der Tastatur gedrückt werden muss.<br />
<br />
Gibt es kein Update für FHEM, sieht die Ausgabe z.B. nach "update check" wie folgt aus:<br />
<br />
:<code>List of new / modified files since last update:</code><br />
:<code>nothing to do...</code><br />
<br />
=== Rücksichern beim Update überschriebener Dateien ===<br />
Per default werden vor dem Überschreiben durch update alle Dateien in einem neuen Verzeichnis (restoreDir/update/YYYY-MM-DD) gesichert. Diese Dateien kann man einzeln oder komplett mit dem Befehl {{Link2CmdRef|Anker=restore|Label=restore}} zurücksichern (z.Bsp.: <code>restore update/2014-08-19</code> oder <code>restore update/2014-08-19/fhem.pl</code>) . Mit dem restoreDirs Attribut kann man die Anzahl der aufgehobenen Sicherungen (== Datum-Verzeichnisse) bestimmen, die Voreinstellung ist 3. Mit 0 kann man das Feature komplett abschalten.<br />
<br />
Ab Updatestand 29.10.2016 können bei Standardinstallationen ({{Link2Forum|Topic=59669|Message=511367}}) die fhem.cfg und fhem.save mit der Option -a des restore-Befehl wiederhergestellt werden.<br />
<br />
Zu Neuerungen ab Updatestand 18.03.2018 siehe {{Link2Forum|Topic=85801|Message=782640}}.<br />
<br />
=== Update ging schief - restore letzte funktionierende Version ===<br />
Sollte der Fall eintreten, dass FHEM nach dem Update nicht mehr startet, kann das restore des letzten Standes auch auf Systemebene durchgeführt werden. Anzeigen der vorhandenen Sicherungen:<syntaxhighlight lang="bash"><br />
ls /opt/fhem/restoreDir/update<br />
</syntaxhighlight>Die Pfad-Angabe YYYY-MM-DD durch das gewünschte Datum ersetzen:<syntaxhighlight lang="bash"><br />
sudo -su fhem cp -R /opt/fhem/restoreDir/update/YYYY-MM-DD/* /opt/fhem/<br />
</syntaxhighlight>Die Berechtigungen bleiben durch die Verwendung des Users fhem erhalten. Danach sollte sich FHEM normal starten lassen. Im Zweifelsfall ist ein reboot des Systems die einfachste Lösung.<br />
<br />
=== Einzelne Dateien aus dem SVN holen ===<br />
Manchmal wird im Forum die Empfehlung gegeben: Die Fehler-bereinigte Datei bitte direkt aus dem SVN holen. Dies kann mit der Perlfunktion { Svn_GetFile('from SVN Path', 'to local Path') } direkt in der FHEM Kommandozeile erfolgen, hier ein paar Beispiele:<syntaxhighlight lang="perl"><br />
{ Svn_GetFile('FHEM/DevIo.pm', 'FHEM/DevIo.pm') }<br />
{ Svn_GetFile('contrib/86_FS10.pm', 'FHEM/86_FS10.pm') }<br />
{ Svn_GetFile('fhem.cfg', 'minimal.cfg') }<br />
</syntaxhighlight>Wie man sieht, kann man sich damit auch aktuelle Dateien aus dem SVN contrib Pfad in den lokalen FHEM Pfad holen. Der lokale contrib Pfad wird beim update NICHT aktualisiert und befindet sich damit immer auf dem Stand der Erstinstallation!</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=CUL&diff=33110CUL2020-05-02T08:25:17Z<p>AndreasMohr: Referenz auf vermutete Problemlösung</p>
<hr />
<div>'''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist ein RF-Gerät im Formfaktor eines USB-Dongles mit externer [[CUL Ausstattung|Antenne]]. Die über das ISM/SRD Band empfangenen Daten werden durch einen Onboard 8&nbsp;bit Atmel Prozessor vorverarbeitet. Mit verfügbarer quelloffener [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS sowie durch kurzfristige Umschaltung auf 433&nbsp;MHz Intertechno (z.&nbsp;B. viele Baumarkt Funksteckdosen) Protokolle. <br />
<br />
Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") wird die Dekodierung der per AM in 1&nbsp;kHz übertragenen Signale per [[#FW|culfw]] auf dem Atmel Prozessor direkt erledigt und dann per USB an den Hostrechner weitergegeben.<br />
<br />
Das CUL kann mittels des CULModuls von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.<br />
<br />
Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version&#160;3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}<br />
<br />
Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z.&nbsp;B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.<br />
<br />
Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.<br />
<br />
Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.<br />
<br />
Obwohl die eigentliche Betriebsfrequenz der FHT und FS20-Komponenten 868,35 MHz ist, ist bei den aktuellen CUL Firmwareversionen zum Betrieb mit FHEM die Frequenz auf 868,30 MHz eingestellt. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.<br />
<br />
Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen. Da diese Funktionen durch die culfw (Firmware) bereitgestellt werden, funktionieren sie auf allen Geräten, die die culfw verwenden ([[CUNO]], [[COC]], CSM):<br />
<br />
* Ist Empfang eingeschaltet ?<br />
*: <code> get myCUL raw C35</code> (13 = ja, z.&nbsp;b.: C35 = 0D / 13)<br />
* Auslesen der culfw Version:<br />
*: <code>get myCUL raw V</code><br />
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)<br />
*: <code>set myCUL raw l00</code><br />
* LED einschalten<br />
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen<br />
* LED soll blinken (einmal in der Sekunde)<br />
*: <code>set myCUL raw l02</code><br />
* Reboot / Reset des CUL:<br />
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=&gt; neue Firmware)<br />
* Freie CUL Sendezeit ([[1% Regel]]):<br />
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots<br />
* Freie Kapazität des FHT Buffers<br />
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a<br />
* Inhalt des FHT Buffers<br />
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes gross, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer<br />
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]<br />
*: <code> get myCUL raw T01</code> <br />
* Eingestellte Frequenz, Bandbreite etc. Ausgeben<br />
*: <code> get myCUL ccconf</code>. <br>Rückgabe z.&nbsp;B.: <br><code><nowiki>myCUL ccconf =&gt; freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code><br />
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):<br />
*:<code>set myCUL bWidth 464</code><br />
* Einstellen der Sendestärke:<br />
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.<br />
<br />
Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen<br />
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. <br />
<br />
Werte x00-x04 sind '''mit''' Ramping (''sanften'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z.&nbsp;B. [[RFR CUL]], da die CULs Rampingsingnale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl). <br />
<br />
<br />
<br />
<br />
'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).<br />
<br />
Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit&#160;:<br />
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt<br />
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet<br />
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet<br />
* <code>set CUL1 raw X80</code> RSSI / Signalstaerke jeder Flanke wird gemeldet<br />
* <code>set CUL1 raw X21</code> normal Modus<br />
<br />
Achtung: Auf Gross- und Kleinschreibung des "x,X" achten!<br />
<br />
Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.<br />
<br />
== Versionen ==<br />
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.<br />
<br />
* CUL V1 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.<br />
* CUL V2 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.<br />
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kByte EEPROM). Voll einsatzfähig.<br />
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM 32 kB Flashmemory, 1 kByte EEPROM. Voll einsatzfähig. Genau genommen ein "Sparmodell" des V3, um Lieferengpässe des atmega32u4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.<br />
<br />
Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.<br />
<br />
== Firmware {{Anker|FW}} ==<br />
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der<br />
* [http://culfw.de CUL Firmware Homepage]<br />
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.<br />
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der<br />
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]<br />
Hier kann man sich z.B. mit<br />
<syntaxhighlight lang=bash><br />
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw<br />
</syntaxhighlight><br />
die aktuelle Version laden.<br />
<br />
Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:<br />
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.<br />
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.<br />
<br />
Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).<br />
<br />
Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.<br />
<br />
== Sendefrequenz ==<br />
Das CUL gibt es in Ausführungen für 868 und 433 MHz. <br />
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der wesentliche Unterschied der 868 und 433 MHz CULs ist ein auf die Frequenz richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.<br />
<br />
Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.<br />
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.<br />
<br />
== Antenne ==<br />
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.<br />
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.<br />
<br />
Wichtig ist nur die Länge. Diese muss vorteilhafterweise so groß sein wie ein Viertel der Wellenlänge der Frequenz ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Leistung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.<br />
<br />
Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar ("Lambda") lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").<br />
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.<br />
<br />
Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser. <br />
<br />
Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.<br />
<br />
Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4&nbsp;GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.<br />
<br />
== Antennenlänge ==<br />
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch eine Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.<br />
<br />
Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:<br />
868,35 MHz (z.B. HM, FS20, FHT …)<br />
1/4 Lambda = 8,63 Zentimeter <br />
1/2 Lambda = 17,26 Zentimeter <br />
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)<br />
<br />
433,92 MHz (z.B. Intertechno …)<br />
1/4 Lambda = 17,27 Zentimeter <br />
1/2 Lambda = 34,54 Zentimeter <br />
<br />
Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:<br />
<br />
8,6 Zentimeter als 1/4 Lambda für 868,35 MHz<br />
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz<br />
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz<br />
<br />
== Bekannte Probleme ==<br />
<br />
=== RF-Tuning ===<br />
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z.&nbsp;B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern z.&nbsp;B. der FHT Raumregler zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.<br />
<br />
Bei Empfangsproblemen von z.&nbsp;B. HEM-Sensoren oder dem S300TH kann man folgendes testen:<br />
<br />
* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.<br />
*: <code>set CUL freq 868.350</code><br />
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.<br />
*: <code>set CUL sens 8</code><br />
* Oft hilft auch, die Bandbreite auf z.&nbsp;B. 464 kHz aufzuweiten.<br />
*: <code>set CUL bWidth 464</code><br />
<br />
=== Übertragungs-Stall nach zu vielen Einträgen in der Queue ===<br />
<br />
Ich habe mich ewig damit rumgeärgert, dass die Übertragung zu bestimmten häufig angesprochenen Geräten zusammenbrach, sobald die Queue zu lang wurde (FHEM: 'list CUL').<br />
Irgendwann habe ich dann zufällig herausgefunden, dass dieses sehr fragwürdige Anwachsen der Queue an einer krassen [[Sendpool]]-Fehlkonfiguration lag: ich hatte dort ein Transceiver-Device mit angegeben, welches den [[Sendpool]]-Mechanismus (noch) gar nicht unterstützt!<br />
Sobald ich dieses falsche Gerät aus der Sendpool-Element-Liste entfernt hatte, war Ruhe --> BUG im Modul (es kann nicht sein, dass ein Device ohne [[Sendpool]]-Support das Queue-Handling so zerschießt). Dieser Bug existiert allerdings wohl weiterhin (das Perl-Handling war mir etwas zu verwirrend, um direkt zu sehen, wo das Problem ist) --> sollte nachgestellt und gefixt werden.<br />
<br />
=== Harter Lockup des CUL ===<br />
<br />
Trotz behobenem (erkanntem) Queue-Problem gibt es weiterhin Probleme ("Problem #2"): es passiert - recht selten -, dass sich der nanoCUL komplett aufhängt, mit hektisch blinkender LED.<br />
Es ist in diesem Fall noch nicht einmal mit dem Reset-Taster möglich, den Stick zu resetten - es ist also tatsächlich nötig, das USB-Kabel komplett zu ziehen. Wenigstens automatisieren lassen würde sich dieser Workaround wohl per uhubctl ([https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux]).<br />
Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.<br />
<br />
Device-Attribute wie version etc. könnten evt. den Zeitpunkt der letzten Aktivität verdeutlichen; dann im FHEM-Log um diesen Zeitpunkt herum suchen, um Auffälligkeiten/Spezialitäten zu erkennen. Und dann muss man, wenn man Pech hat, eine custom culfw bauen, die entsprechendes Reporting mit eingebaut hat...<br />
<br />
(nanoCUL; V 1.26.00 a-culfw Build: 267).<br />
<br />
UPDATE: die Lösung des Problems steht evt. im Forum: [https://forum.fhem.de/index.php/topic,73144.msg977406.html?PHPSESSID=2lj93g4vn277qhm2bfpvfpgntr#msg977406 {Gelöst} Nanocul LED blinkt schnell].<br />
<br />
== Selbstbau-/Bastelprojekte ==<br />
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:<br />
* [[Selbstbau CUL]]<br />
* [[FHEMduino]]<br />
* [[SIGNALduino]]<br />
* [[MapleCUN]] mit STM32 Mikrocontroller<br />
<br />
== Links ==<br />
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]<br />
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im [http://forum.fhem.de/index.php FHEM Forum] ergänzt/ersetzt<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:CUL|!]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=JUDO_iSoft_Plus&diff=31348JUDO iSoft Plus2019-10-13T19:38:08Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=judo-soft-plus.jpg|200px<br />
|Bildbeschreibung=JUDO i-soft plus Wasserenthärtungsanlage<br />
|HWProtocol=IP<br />
|HWType=Wasserenthärter<br />
|HWCategory=IP<br />
|HWVoltage=230&nbsp;V<br />
|HWPoweredBy=AC<br />
|HWSize=39x67x45 cm (BxHxT)<br />
|HWComm=n/a<br />
|HWChannels=n/a<br />
|HWPowerConsumption=?<br />
|HWDeviceFHEM=[[HTTPMOD]]<br />
<!-- |ModOwner= --><br />
|HWManufacturer=Judo GmbH<br />
}}<br />
__TOC__<br />
<br />
Die JUDO i-soft plus Enthärtungsanlage [https://judo.eu/produkt/judo-i-soft-plus-vollautomatische-enthaertungsanlage/] ist eine Wasserenthärtungsanlage mit IP-Konnektivität. <br />
Sie verfügt über LAN- und WLAN-Anschluss und ist auf die Steuerung via App des Herstellers ausgelegt.<br />
<br />
== Geräte-Registrierung ==<br />
<br />
Für eine erfolgreiche Integration in FHEM muss die Anlage über das Menü beim Hersteller registriert werden (wohl nur i-soft plus; z.B. i-soft safe kann das wohl nicht, schlechtere Display-Ausstattung - hier gilt dann [https://www.ju-control.app/] oder die Handy-Apps).<br />
Die folgenden Informationen sind erforderlich:<br />
<br />
* Benutzername: Selbst gewählter Login-Name auf der i-soft plus (vgl. Gerätehandbuch)<br />
* Kennwort: Selbst gewähltes Kennwort<br />
* Seriennummer: Seriennummer des Geräts. Diese ist entweder über das Menü auslesbar oder alternativ auch über die APP des Herstellers.<br />
* IP-Adresse: Die IP-Adresse des Geräts im Heimnetz. <br />
<br />
Bei den Registrier-Prozessen ist zwingend zu beachten, dass es '''mehrere''' Labels mit QR-Codes / Gerätedaten geben kann (zumindest bei i-soft safe): auf den Gehäuse-Seite'''n''' und auf dem Connectivity Module - man sollte also tunlichst die '''richtige''' Referenz erwischen, sonst Fehlschlag!<br />
(Ich hatte mehrere Prozess-Probleme, somit in Beschwerdemail mehrere momentan existierende gravierende Registrier-Prozess-Impräzisionen angem***t, daraufhin INSTANTAN (8 Uhr) Rückruf durch Kundendienst! *daumenhoch*)<br />
<br />
== Einbindung in FHEM ==<br />
<br />
Das Gerät wird mittels des Moduls HTTPMOD eingebunden. Dazu gilt zunächst die folgende Konfiguration als Basis.<br />
Zunächst legen wir die Standardanfrage an das Modul fest. Die Portnummer 8124 ist vom Hersteller vorgegeben. Wir vergeben gleich ein paar Platzhalter, die später in den Aufrufen und den Antworten ersetzt werden, damit wir die Werte nur an einer zentralen Stelle konfigurieren müssen.<br />
<br />
<pre><br />
define JUDO_iSoft HTTPMOD https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=4&token=%token% 300<br />
</pre><br />
Mit dieser Definition wird als Standard-Anfrage die Statusabfrage nach dem Wasserstop gesendet. Diese wird zyklisch alle 300 Sekunden wiederholt. <br />
Wem das nicht reicht, der kann den Zyklus herunter setzen oder auch nach anderen Standard-Werten abfragen. Wer das kontinuierliche Pollen vermeiden will, setzt den Wert auf 0.<br />
<br />
Nach erfolgreicher Authentifizierung wird von der i-soft ein Token generiert, welches bei jedem Aufruf übergeben werden muss:<br />
<br />
<pre><br />
attr JUDO_iSoft replacement01Mode reading<br />
attr JUDO_iSoft replacement01Regex %token%<br />
attr JUDO_iSoft replacement01Value token<br />
</pre><br />
<br />
Anschließend legen wir die Ersetzungen für die anderen Platzhalter fest: <br />
<br />
<pre><br />
attr JUDO_iSoft replacement02Mode text<br />
attr JUDO_iSoft replacement02Regex %JUDO_ipaddress%<br />
attr JUDO_iSoft replacement02Value <hier eigene IP Adresse im lokalen Netz eintragen><br />
attr JUDO_iSoft replacement03Mode text<br />
attr JUDO_iSoft replacement03Regex %JUDO_password%<br />
attr JUDO_iSoft replacement03Value <hier Kennwort eintragen><br />
attr JUDO_iSoft replacement04Mode text<br />
attr JUDO_iSoft replacement04Regex %JUDO_username%<br />
attr JUDO_iSoft replacement04Value <hier Benutzername eintragen><br />
attr JUDO_iSoft replacement05Mode text<br />
attr JUDO_iSoft replacement05Regex %JUDO_serial%<br />
attr JUDO_iSoft replacement05Value <hier Seriennummer eintragen><br />
</pre><br />
<br />
Die Authentifizierung der Anlage erfolgt zweistufig. Zunächst muss ein Aufruf mit Benutzername und Kennwort erfolgen. Als Antwort erhält man einen JSON-String, der das Token beinhaltet. Mit diesem Token wird anschließend die Funktion connect aufgerufen und die Seriennummer des Geräts mit übergeben. <br />
HTTPMOD erkennt, wenn ein neues Login erforderlich ist, wenn die JUDO die Rückmeldung "no token" oder "not logged in" liefert.<br />
<br />
Achtung: Als Parameter muss ebenfalls der Typ "i-soft plus" übergeben werden. Vermutlich ist dieser bei anderen Geräten des Herstellers anders. Ich habe ihn hier fix eingetragen, da ich keine Möglichkeit zum Testen anderer Geräte habe. <br />
<br />
<pre><br />
attr JUDO_iSoft showError 1<br />
attr JUDO_iSoft authRetries 2<br />
attr JUDO_iSoft reAuthRegex (no token)|(not logged in)<br />
attr JUDO_iSoft sid01ParseResponse 1<br />
attr JUDO_iSoft sid01URL https://%JUDO_ipaddress%:8124/?group=register&command=login&msgnumber=1&name=login&user=%JUDO_username%&password=%JUDO_password%&role=customer<br />
attr JUDO_iSoft sid02URL https://%JUDO_ipaddress%:8124/?group=register&command=connect&msgnumber=6&token=%token%&parameter=i-soft%20plus&serial%20number=%JUDO_serial%<br />
</pre><br />
<br />
Damit ist die Grundkonfiguration hergestellt und die Anlage kann sich connecten. <br />
In den einzelnen JSON-Rückantworten der Anlage werden die Werte zur jeweilige Anfrage immer als "data" zurückgeliefert. Mit der Standard-Konfiguration<br />
<br />
<pre><br />
attr JUDO_iSoft extractAllJSON 1<br />
</pre><br />
<br />
werden daraus automatisch entsprechende Readings angelegt. Da wir aber dann immer das Reading "data" überschreiben würden, kommt eine weitere Ersetzung zum Einsatz. In der Antwort steht neben einer Kaskadierung (group) auch der zugehörige Befehl (command). Ich habe mich dafür entschieden, ein neues Reading mit dem jeweiligen Command-Namen anzulegen. Die zugehörigen Ersetzungen sind wie folgt.<br />
Erklärung zum Ausdruck reading03OExpr: Zunächst werden die Leerzeichen im Rückgabewert ($val) durch "-" ersetzt. Mit dem so veränderten String erzeugen wir ein neues Reading mit dem Wert aus dem Reading data. <br />
<br />
<pre><br />
attr JUDO_iSoft reading01JSON data<br />
attr JUDO_iSoft reading01Name token<br />
attr JUDO_iSoft reading01Regex "token":"([^"]+)"<br />
attr JUDO_iSoft reading02JSON group<br />
attr JUDO_iSoft reading03JSON command<br />
attr JUDO_iSoft reading03OExpr $val =~ s/\s/-/;; $val; readingsBulkUpdate($hash,$val,ReadingsVal("JUDO_iSoft","data",""))<br />
</pre><br />
Noch ein paar ergänzende Attribute gesetzt:<br />
<pre><br />
attr JUDO_iSoft enableControlSet 1<br />
attr JUDO_iSoft getHeader1 Content-Type: application/json<br />
attr JUDO_iSoft getHeader2 Accept: */*<br />
attr JUDO_iSoft room 10_Räume->UG->Keller,<br />
attr JUDO_iSoft showError <br />
attr JUDO_iSoft timeout 5<br />
</pre><br />
<br />
Damit sind alle Voraussetzungen erledigt. Ab jetzt können wir die einzelnen Get-Befehle implementieren:<br />
<br />
<pre><br />
attr JUDO_iSoft get01Name SerialNumber<br />
attr JUDO_iSoft get01URL https://%JUDO_ipaddress%:8124/?group=spare%20part&command=serial%20number&msgnumber=5&token=%token%<br />
<br />
attr JUDO_iSoft get02Name WaterCurrent<br />
attr JUDO_iSoft get02URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20current&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get03Name SaltRange<br />
attr JUDO_iSoft get03URL https://%JUDO_ipaddress%:8124/?group=consumption&command=salt%20range&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get04Name SaltQuantity<br />
attr JUDO_iSoft get04URL https://%JUDO_ipaddress%:8124/?group=consumption&command=salt%20quantity&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get05Name ResidualHardness<br />
attr JUDO_iSoft get05URL https://%JUDO_ipaddress%:8124/?group=settings&command=residual%20hardness&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get06Name NaturalHardness<br />
attr JUDO_iSoft get06URL https://%JUDO_ipaddress%:8124/?group=info&command=natural%20hardness&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get07Name WaterStop<br />
attr JUDO_iSoft get07URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get08Name FlowRate<br />
attr JUDO_iSoft get08URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=flow%20rate&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get09Name SoftwareVersion<br />
attr JUDO_iSoft get09URL https://%JUDO_ipaddress%:8124/?group=version&command=software%20version&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get10Name HardwareVersion<br />
attr JUDO_iSoft get10URL https://%JUDO_ipaddress%:8124/?group=version&command=hardware%20version&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get11Name InstallationDate<br />
attr JUDO_iSoft get11URL https://%JUDO_ipaddress%:8124/?group=contract&command=init%20date&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get12Name ServiceDate<br />
attr JUDO_iSoft get12URL https://%JUDO_ipaddress%:8124/?group=contract&command=service%20date&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get13Name WaterTotal<br />
attr JUDO_iSoft get13URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20total&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get14Name WaterAverage<br />
attr JUDO_iSoft get14URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20average&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get15Name Vacation<br />
attr JUDO_iSoft get15URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=vacation&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get16Name Quantity<br />
attr JUDO_iSoft get16URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=quantity&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get17Name WaterDaily<br />
attr JUDO_iSoft get17URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20daily&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get18Name ValveState<br />
attr JUDO_iSoft get18URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=4&&token=%token%<br />
<br />
</pre><br />
<br />
Zum Setzen einiger Werte werden die folgenden Kommandos zum Schließen und Öffnen des Wasserstopps sowie das Setzen der Wunschwasserhärte implementiert<br />
<br />
<pre><br />
attr JUDO_iSoft set01Name CloseValve<br />
attr JUDO_iSoft set01URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%&parameter=close<br />
attr JUDO_iSoft set02Name OpenValve<br />
attr JUDO_iSoft set02URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%&parameter=open<br />
attr JUDO_iSoft set03Name residual-hardness<br />
attr JUDO_iSoft set03URL https://%JUDO_ipaddress%:8124/?group=settings&command=residual%20hardness&msgnumber=1&token=%token%&parameter=$val<br />
</pre><br />
<br />
<br />
<br />
'''Userreadings'''<br />
<br />
Um die Originalwerte aus der Anlage benutzerfreundlicher darzustellen, werden noch Userreadings angelegt.<br />
<br />
Die Salzrestdauer soll in Wochen angegeben (rückgemeldet werden Tage) werden, die verbleibende Salzmenge in Prozent. <br />
Die Salzmenge wird in Gramm angegeben, 50.000 entsprechen 100%.<br />
Wichtig: Bei den Userreadings muss darauf geachtet werden, dass diese mit Komma separiert und in einer Zeile geschrieben werden. <br />
<pre><br />
<br />
attr JUDO_iSoft saltRangeInWeeks { int( (ReadingsVal("JUDO_iSoft","salt-range",0)/7))} , saltQuantityInPercent { int( (ReadingsVal("JUDO_iSoft","salt-quantity",0)/50000)*100)}<br />
</pre><br />
<br />
== Readings auslesen ==<br />
Die Art der Anbindung liefert veränderte Readings nur, wenn man sie regelmäßig abfragt. Dazu habe ich dazu einen Timer aufgesetzt, der 1x am Tag die relevanten Werte abfragt. Das ist eigentlich nur wichtig, falls man ab und an doch noch über einen anderen Weg z.B. die Apps des Herstellers auf die JUDO zugreift und Werte verändert. Bei mir sieht das dann so aus:<br />
<pre><br />
Internals:<br />
COMMAND get JUDO_iSoft SaltQuantity;<br />
get JUDO_iSoft SaltRange;<br />
get JUDO_iSoft WaterDaily;<br />
get JUDO_iSoft WaterTotal;<br />
get JUDO_iSoft WaterAverage;<br />
get JUDO_iSoft FlowRate;<br />
get JUDO_iSoft ResidualHardness;<br />
<br />
DEF *23:55:00 <br />
get JUDO_iSoft SaltQuantity;<br />
get JUDO_iSoft SaltRange;<br />
get JUDO_iSoft WaterDaily;<br />
get JUDO_iSoft WaterTotal;<br />
get JUDO_iSoft WaterAverage;<br />
get JUDO_iSoft FlowRate;<br />
get JUDO_iSoft ResidualHardness;<br />
NAME at_Judo_DailyStats<br />
NR 1595<br />
PERIODIC yes<br />
RELATIVE no<br />
REP -1<br />
STATE Next: 23:55:00<br />
TIMESPEC 23:55:00<br />
TRIGGERTIME 1538862900<br />
TRIGGERTIME_FMT 2018-10-06 23:55:00<br />
TYPE at<br />
READINGS:<br />
2018-10-06 06:06:14 state Next: 23:55:00<br />
Attributes:<br />
room ,00_Masterswitches,10_Räume->UG->Keller<br />
<br />
</pre><br />
<br />
Um 1x pro Stunde gegen Ende der vollen Stunde den Wasserbrauch der aktuellen Stunde abzugreifen setze ich einen weiteren Timer auf. Bei mir jeweils um :58 der aktuellen Stunde. Das ist natürlich nicht ganz exakt. Wenn sich die Uhr der JUDO und von FHEM auseinander driften bekommt man ggf. schon wieder den Wert der nächsten Stunde. <br />
<pre><br />
Internals:<br />
CFGFN <br />
COMMAND get JUDO_iSoft WaterCurrent<br />
DEF +*01:00:00 get JUDO_iSoft WaterCurrent<br />
NAME at_Judo_HourlyStats<br />
NR 34559<br />
NTM 06:58:00<br />
PERIODIC yes<br />
RELATIVE yes<br />
REP -1<br />
STATE Next: 06:58:00<br />
TIMESPEC 01:00:00<br />
TRIGGERTIME 1538801880<br />
TRIGGERTIME_FMT 2018-10-06 06:58:00<br />
TYPE at<br />
READINGS:<br />
2018-10-06 06:20:53 state Next: 06:58:00<br />
Attributes:<br />
alignTime 00:58<br />
room ,00_Masterswitches,10_Räume->UG->Keller<br />
</pre><br />
<br />
== Statistiken ==<br />
Die i-soft plus liefert verschiedene Statistiken zum Wasserverbrauch zurück. Die werden allerdings etwas eigentümlich zurückgemeldet.<br />
Unter water-current ist der jeweilige Verbrauch je Stunde zusammengefasst. Ich hole kurz vor der vollen Stunde diesen Wert ab, damit er danach im Logfile landet.<br />
Unter water-daily werden Tagesstatistiken geliefert. Kurioserweise in 3-Stunden-Paketen, d.h. 8 Werte. Die ersten Werte sind von 0h-3h, 3h-6h usw.<br />
Ich habe mich aktuell darauf beschränkt, den stündlichen Verbrauch zu erfassen und zu protokollieren. Es lassen sich aber auch bei Bedarf detaillierte Datumsbezogene Statistiken abrufen. Ich habe noch keinen sinnvollen Weg gefunden, das mit FHEM zu verbinden. <br />
<br />
<br />
== Darstellung in Tablet UI ==<br />
Ich nutze Tablet UI für die Visualisierung. <br />
Zur Darstellung der Restmengen Salz nutze ich das knob-widget, für das Setzen des Härtegrades den spinner.<br />
<br />
[[Datei:Screenshot judo 2.jpg|mini|Visualisierung der JUDO im TabletUI|200px]]<br />
<br />
<pre><br />
<div class="hbox"><br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Zustand Salz</header><br />
<div class="sheet"><br />
<br />
<div class="row"><br />
<div class="cell-50 top-align center-align left-space"><br />
<div class="big">Restmenge</div><br />
<div data-type="knob" data-device="JUDO_iSoft"<br />
data-get="saltQuantityInPercent"<br />
data-unit="%"<br />
data-step="1"<br />
data-min="0"<br />
data-max="100"<br />
data-bgcolor="#FF0000"<br />
data-fgcolor="#00FF1A"<br />
class="small readonly"><br />
</div><br />
<br />
<br />
</div><br />
<div class="cell-50 top-align center-align left-space"><br />
<div class="big">Reichweite</div><br />
<br />
<div data-type="knob" data-device="JUDO_iSoft"<br />
data-get="saltRangeInWeeks"<br />
data-unit="w"<br />
data-step="1"<br />
data-min="0"<br />
data-max="52"<br />
data-bgcolor="#FF0000"<br />
data-fgcolor="#00FF1A"<br />
class="small readonly"><br />
</div><br />
<br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserstopp</header><br />
<div class="sheet"> <br />
<div class="row top-space"><br />
<br />
<div class="cell left-align top-align left-space"><br />
<div data-type="symbol" data-device="JUDO_iSoft" data-get="valve"<br />
data-icons='["fa-close","fa-close","oa-sani_water_tap","oa-sani_water_tap"]'<br />
data-get-on='["closed","closing","opening","opened"]'<br />
data-on-colors='["#ad3333","#ff6633","#3399ff","#33ad33"]' class="big compressed"></div><br />
</div><br />
<div class="cell-60 top-align center-align"><br />
<div class="big"><br />
<br />
<div data-type="label"<br />
data-get="valve"<br />
class="valueonly"<br />
data-substitution='["opened","geöffnet","opening","öffnet gerade","closed","geschlossen","closing","schließt gerade"]'<br />
data-device="JUDO_iSoft"<br />
data-color="lightgrey"><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div class="cell left-align top-align left-space"><br />
<div data-type="push" data-device="JUDO_iSoft" data-set-on="CloseValve 1" data-get-on="valve" data-background-icon="fa-stop-circle-o" data-icon="" class="small"></div><br />
<br />
</div><br />
<div class="cell right-align top-align right-space"><br />
<br />
<div data-type="push" data-device="JUDO_iSoft" data-set-on="OpenValve 1" data-get-on="valve" data-background-icon="mi-play_circle_filled" data-icon="" class="small"></div> <br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserhärtegrad</header><br />
<br />
<div class="sheet"><br />
<div class="row"> <br />
<br />
<div class="cell-20 center-align top-align left-space"><br />
<div data-type="symbol"<br />
data-device="JUDO_iSoft"<br />
data-icon="none"<br />
data-color='none'<br />
data-height="100"<br />
data-background-icon="fa-circle"<br />
data-background-colors='["red","blue"]'<br />
data-limits='["0","1"]'><br />
<div data-type="label"<br />
data-get="natural-hardness"<br />
data-unit="&deg;h"<br />
class="valueonly"<br />
data-device="JUDO_iSoft"<br />
data-color="lightgrey"><br />
</div><br />
</div><br />
</div><br />
<br />
<div class="cell-20 top-align center-align left-space"><br />
<div data-type="image" data-size="50%" data-url="images/judo.png"></div><br />
</div><br />
<br />
<div class="cell-60 top-align center-align left-space"><br />
<br />
<div data-type="spinner"<br />
data-device="JUDO_iSoft"<br />
data-get="residual-hardness"<br />
data-set="residual-hardness"<br />
data-min=5"<br />
data-max="12"<br />
data-step="1"<br />
data-unit="&deg;h"<br />
data-longdelay="800"<br />
data-width="200"<br />
data-height="60"<br />
data-icon-left-color="blue"<br />
data-icon-right-color="red"<br />
<br />
class="valueonly"><br />
<br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserverbrauch</header><br />
<section> <br />
<div id="JUDO_iSoft"<br />
data-type="highchart"<br />
data-device="JUDO_iSoft"<br />
data-logdevice="FileLog_JUDO_ISoft"<br />
data-columnspec="4:water-current"<br />
data-style="ftui l0fill"<br />
data-linenames="Verbrauch"<br />
data-linetypes="line"<br />
data-yaxis="0,1"<br />
data-height="300"<br />
data-xunit="Uhrzeit"<br />
data-yunit="l"<br />
data-tooltip="{series.name} <b>{point.y:,.1f}</b>"<br />
data-daysago="7"<br />
data-yticks="auto"<br />
data-legendalign="right"><br />
<br />
</section><br />
<br />
</div<br />
</div><br />
</div><br />
</pre><br />
<br />
== Problemlösung ==<br />
=== DHCP (keine IP-Adress-Zuweisung) ===<br />
<br />
Ich hatte bei der Inbetriebnahme erstaunliche Probleme, erfolgreich eine IP-Adresse zu bekommen.<br />
Das hat bei mir nur einmal initial funktioniert (und die Verbindung hab ich dann verloren), und dann "nie wieder".<br />
<br />
Diagnose z.B. per DHCP-Status-Seite im Router (verbundene Geräte).<br />
<br />
Es hat bei mir NICHT geholfen, das Netzwerk-Kabel abzuziehen (--> link state change == Wink mit dem Zaunpfahl, dass es erneuert werden sollte), und auch NICHT, das i-soft stromlos zu machen.<br />
<br />
Erst nach Entfernen aller Backup-9V-Blocks '''und''' stromlos machen (--> jetzt waren alle Status-LEDs des Connectivity Module erfolgreich aus!) hat er sich endlich wieder eine IP geholt.<br />
<br />
Weitere Diagnose-Möglichkeiten:<br />
* anderes Netzwerkkabel verwenden<br />
* Netzwerkkabel mit Kabel-Tester durchklingeln (z.B. COMMUNICATION CABLE TESTER S1007)<br />
<br />
Bitte hier weiter updaten, falls klarer wird, wie der Sachverhalt ist.<br />
<br />
=== Salzbehälter ===<br />
<br />
Der Salzbehälter kann an der Boden-Platten-Naht undicht sein (vermutlich seltener Fall; jedenfalls möglich bei Systemen ~ <= 08/2019, danach hoffentlich besser), somit Leckage, mit daraus folgenden schwerwiegenden Problemen (mglw. Versalzung der - evt. auch etwas weiteren: Luftströmungen! - Umgebung; hygroskopisch / kapillar - AUA! Salpeter-Reiniger scheint eine ziemlich gute Behandlung zu sein).<br />
Wenn man auf ganz sicher gehen will hinsichtlich Leckage-Vermeidung, dann ist es wohl empfehlenswert, Entkalker-Systeme in eine Wanne zu stellen, z.B. Baumarkt-Mörtelkübel (80l? 90l?).<br />
<br />
Der Behälterrand an der Oberkante hat zu scharfen Rand / ist nicht entgratet (Kunststoff-Spritzform?) --> Pulli-Ärmel-Killer --> aufpassen.<br />
<br />
== Ähnliche Systeme ==<br />
<br />
== Projekte der FHEM-Community ==<br />
<br />
== Links ==<br />
* {{Link2Forum|Topic=56455|Message=800960}}<br />
* [https://blog.muwave.de/2017/06/monitoring-and-controlling-a-judo-i-soft-plus-water-softening-device-via-lan/ ursprünglicher Beitrag bzgl. des verwendeten Protokolls]<br />
<br />
<br />
[[Kategorie:IP Components]]<br />
[[Kategorie:Other Components]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=CUL&diff=31347CUL2019-10-13T19:21:04Z<p>AndreasMohr: /* Bekannte Probleme */ Abschnitte Stall / Lockup hinzugefügt</p>
<hr />
<div>'''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist ein RF-Gerät im Formfaktor eines USB-Dongles mit externer [[CUL Ausstattung|Antenne]]. Die über das ISM/SRD Band empfangenen Daten werden durch einen Onboard 8&nbsp;bit Atmel Prozessor vorverarbeitet. Mit verfügbarer quelloffener [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS sowie durch kurzfristige Umschaltung auf 433&nbsp;MHz Intertechno (z.&nbsp;B. viele Baumarkt Funksteckdosen) Protokolle. <br />
<br />
Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") wird die Dekodierung der per AM in 1&nbsp;kHz übertragenen Signale per [[#FW|culfw]] auf dem Atmel Prozessor direkt erledigt und dann per USB an den Hostrechner weitergegeben.<br />
<br />
Das CUL kann mittels des CULModuls von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.<br />
<br />
Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version&#160;3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}<br />
<br />
Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z.&nbsp;B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.<br />
<br />
Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.<br />
<br />
Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.<br />
<br />
Obwohl die eigentliche Betriebsfrequenz der FHT und FS20-Komponenten 868,35 MHz ist, ist bei den aktuellen CUL Firmwareversionen zum Betrieb mit FHEM die Frequenz auf 868,30 MHz eingestellt. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.<br />
<br />
Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen. Da diese Funktionen durch die culfw (Firmware) bereitgestellt werden, funktionieren sie auf allen Geräten, die die culfw verwenden ([[CUNO]], [[COC]], CSM):<br />
<br />
* Ist Empfang eingeschaltet ?<br />
*: <code> get myCUL raw C35</code> (13 = ja, z.&nbsp;b.: C35 = 0D / 13)<br />
* Auslesen der culfw Version:<br />
*: <code>get myCUL raw V</code><br />
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)<br />
*: <code>set myCUL raw l00</code><br />
* LED einschalten<br />
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen<br />
* LED soll blinken (einmal in der Sekunde)<br />
*: <code>set myCUL raw l02</code><br />
* Reboot / Reset des CUL:<br />
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=&gt; neue Firmware)<br />
* Freie CUL Sendezeit ([[1% Regel]]):<br />
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots<br />
* Freie Kapazität des FHT Buffers<br />
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a<br />
* Inhalt des FHT Buffers<br />
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes gross, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer<br />
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]<br />
*: <code> get myCUL raw T01</code> <br />
* Eingestellte Frequenz, Bandbreite etc. Ausgeben<br />
*: <code> get myCUL ccconf</code>. <br>Rückgabe z.&nbsp;B.: <br><code><nowiki>myCUL ccconf =&gt; freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code><br />
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):<br />
*:<code>set myCUL bWidth 464</code><br />
* Einstellen der Sendestärke:<br />
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.<br />
<br />
Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen<br />
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. <br />
<br />
Werte x00-x04 sind '''mit''' Ramping (''sanften'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z.&nbsp;B. [[RFR CUL]], da die CULs Rampingsingnale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl). <br />
<br />
<br />
<br />
<br />
'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).<br />
<br />
Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit&#160;:<br />
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt<br />
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet<br />
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet<br />
* <code>set CUL1 raw X80</code> RSSI / Signalstaerke jeder Flanke wird gemeldet<br />
* <code>set CUL1 raw X21</code> normal Modus<br />
<br />
Achtung: Auf Gross- und Kleinschreibung des "x,X" achten!<br />
<br />
Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.<br />
<br />
== Versionen ==<br />
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.<br />
<br />
* CUL V1 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.<br />
* CUL V2 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.<br />
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kByte EEPROM). Voll einsatzfähig.<br />
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM 32 kB Flashmemory, 1 kByte EEPROM. Voll einsatzfähig. Genau genommen ein "Sparmodell" des V3, um Lieferengpässe des atmega32u4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.<br />
<br />
Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.<br />
<br />
== Firmware {{Anker|FW}} ==<br />
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der<br />
* [http://culfw.de CUL Firmware Homepage]<br />
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.<br />
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der<br />
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]<br />
Hier kann man sich z.B. mit<br />
<syntaxhighlight lang=bash><br />
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw<br />
</syntaxhighlight><br />
die aktuelle Version laden.<br />
<br />
Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:<br />
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.<br />
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.<br />
<br />
Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).<br />
<br />
Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.<br />
<br />
== Sendefrequenz ==<br />
Das CUL gibt es in Ausführungen für 868 und 433 MHz. <br />
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der wesentliche Unterschied der 868 und 433 MHz CULs ist ein auf die Frequenz richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.<br />
<br />
Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.<br />
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.<br />
<br />
== Antenne ==<br />
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.<br />
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.<br />
<br />
Wichtig ist nur die Länge. Diese muss vorteilhafterweise so groß sein wie ein Viertel der Wellenlänge der Frequenz ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Leistung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.<br />
<br />
Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar ("Lambda") lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").<br />
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.<br />
<br />
Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser. <br />
<br />
Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.<br />
<br />
Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4&nbsp;GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.<br />
<br />
== Antennenlänge ==<br />
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch eine Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.<br />
<br />
Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:<br />
868,35 MHz (z.B. HM, FS20, FHT …)<br />
1/4 Lambda = 8,63 Zentimeter <br />
1/2 Lambda = 17,26 Zentimeter <br />
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)<br />
<br />
433,92 MHz (z.B. Intertechno …)<br />
1/4 Lambda = 17,27 Zentimeter <br />
1/2 Lambda = 34,54 Zentimeter <br />
<br />
Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:<br />
<br />
8,6 Zentimeter als 1/4 Lambda für 868,35 MHz<br />
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz<br />
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz<br />
<br />
== Bekannte Probleme ==<br />
<br />
=== RF-Tuning ===<br />
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z.&nbsp;B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern z.&nbsp;B. der FHT Raumregler zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.<br />
<br />
Bei Empfangsproblemen von z.&nbsp;B. HEM-Sensoren oder dem S300TH kann man folgendes testen:<br />
<br />
* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.<br />
*: <code>set CUL freq 868.350</code><br />
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.<br />
*: <code>set CUL sens 8</code><br />
* Oft hilft auch, die Bandbreite auf z.&nbsp;B. 464 kHz aufzuweiten.<br />
*: <code>set CUL bWidth 464</code><br />
<br />
=== Übertragungs-Stall nach zu vielen Einträgen in der Queue ===<br />
<br />
Ich habe mich ewig damit rumgeärgert, dass die Übertragung zu bestimmten häufig angesprochenen Geräten zusammenbrach, sobald die Queue zu lang wurde (FHEM: 'list CUL').<br />
Irgendwann habe ich dann zufällig herausgefunden, dass dieses sehr fragwürdige Anwachsen der Queue an einer krassen [[Sendpool]]-Fehlkonfiguration lag: ich hatte dort ein Transceiver-Device mit angegeben, welches den [[Sendpool]]-Mechanismus (noch) gar nicht unterstützt!<br />
Sobald ich dieses falsche Gerät aus der Sendpool-Element-Liste entfernt hatte, war Ruhe --> BUG im Modul (es kann nicht sein, dass ein Device ohne [[Sendpool]]-Support das Queue-Handling so zerschießt). Dieser Bug existiert allerdings wohl weiterhin (das Perl-Handling war mir etwas zu verwirrend, um direkt zu sehen, wo das Problem ist) --> sollte nachgestellt und gefixt werden.<br />
<br />
=== Harter Lockup des CUL ===<br />
<br />
Trotz behobenem (erkanntem) Queue-Problem gibt es weiterhin Probleme ("Problem #2"): es passiert - recht selten -, dass sich der nanoCUL komplett aufhängt, mit hektisch blinkender LED.<br />
Es ist in diesem Fall noch nicht einmal mit dem Reset-Taster möglich, den Stick zu resetten - es ist also tatsächlich nötig, das USB-Kabel komplett zu ziehen. Wenigstens automatisieren lassen würde sich dieser Workaround wohl per uhubctl ([https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux]).<br />
Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.<br />
<br />
Device-Attribute wie version etc. könnten evt. den Zeitpunkt der letzten Aktivität verdeutlichen; dann im FHEM-Log um diesen Zeitpunkt herum suchen, um Auffälligkeiten/Spezialitäten zu erkennen. Und dann muss man, wenn man Pech hat, eine custom culfw bauen, die entsprechendes Reporting mit eingebaut hat...<br />
<br />
(nanoCUL; V 1.26.00 a-culfw Build: 267).<br />
<br />
== Selbstbau-/Bastelprojekte ==<br />
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:<br />
* [[Selbstbau CUL]]<br />
* [[FHEMduino]]<br />
* [[SIGNALduino]]<br />
* [[MapleCUN]] mit STM32 Mikrocontroller<br />
<br />
== Links ==<br />
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]<br />
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im [http://forum.fhem.de/index.php FHEM Forum] ergänzt/ersetzt<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:CUL|!]]<br />
[[Kategorie:433MHz]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=DWD_OpenData&diff=31191DWD OpenData2019-09-08T19:47:46Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>{{Hinweis|Versionsänderung: Die Vorhersagedaten wurden Mitte September 2018 von CSV auf KML umgestellt. Diese Umstellung ist inkompatibel: das DWD_OpenData-Modul muss aktualisiert werden, einige Reading-Namen haben sich geändert und der Weblink muss deinstalliert und neu installiert werden (siehe diesen {{Link2Forum|Topic=83097|Message=840270|Linktext=Beitrag im Forum}}).}}<br />
<br />
{{<br />
Infobox Modul<br />
|ModPurpose=Daten vom DWD OpenData Server abrufen<br />
|ModType=d<br />
|ModCmdRef=DWD_OpenData<br />
|ModForumArea=Unterstützende Dienste/Wettermodule<br />
|ModTechName=55_DWD_OpenData.pm<br />
|ModOwner=JensB ({{Link2FU|14024|Forum}}/[[Benutzer Diskussion:JensB|Wiki]])<br />
}}<br />
<br />
Der Deutsche Wetterdienst (DWD) stellt Wetterdaten über den [https://www.dwd.de/DE/leistungen/opendata/opendata.html Open Data Server] zur Verfügung. Die Verwendung dieses Dienstes und der vom DWD zur Verfügung gestellten Daten unterliegt den auf der OpenData Webseite beschriebenen Bedingungen. Einen Überblick über die verfügbaren Daten findet man in der Tabelle [https://www.dwd.de/DE/leistungen/opendata/help/inhalt_allgemein/opendata_content_de_en_xls.xls OpenData_weather_content.xls].<br />
<br />
== Anwendung ==<br />
Aufgrund der unterschiedlichen vom DWD bereitgestellten Datenformate benötigt das Modul zur Dekodierung je nach gewünschtem Funktionsumfang zusätzliche Perl-Module, die nicht standardmäßig vorinstalliert sind und je nach Systemkonfiguration nachinstalliert werden müssen. Außerdem unterstützt das Modul Zeitzonen, um z.B. die Wettervorhersage internationaler Stationen in Ortszeit darstellen zu können. Hierfür sind je nach Systemkonfiguration weitere Einstellungen erforderlich. Auch die Sprache der Wochentage für die Wettervorhersage ist frei wählbar. Je nach Systemkonfiguration ist aber die Standardsprache u.U. auf Englisch eingestellt, was weitere Anpassungen der Systemkonfiguration erforderlich macht.<br />
<br />
=== Vorbereitung ===<br />
Im folgenden wird z.T. von einem System mit Rasbian oder Debian mit System-V Startsystem ausgegangen. Auf anderen Betriebssystemen und auf Systemen mit System-D müssen die Installationsschritte ggf. angepasst werden.<br />
<br />
1. Für die Wettervorhersage und die Wetterwarnungen:<br />
Installation des Perl-Moduls ''XML::LibXML'' über die System-Kommandozeile mit<br />
<source lang="bash"><br />
sudo apt-get install libxml-libxml-perl<br />
</source> <br />
oder mit CPAN.<br />
<br />
2. Falls man einen eigenen Internet-Proxy nutzt:<br />
Die Konfiguration des Proxies für FHEM erfolgt z.B. durch Eintrag von<br />
<pre><br />
attr global proxy <myProxyHost>:<myProxyPort><br />
</pre> <br />
in die [[Konfiguration]], wobei ''myProxyHost'' durch den Namen oder die IP-Adresse des Proxy-Servers ersetzt werden muss und für ''myProxyPort'' der Port des Proxy-Servers eingetragen werden muss (oft 3128).<br />
<br />
3. FHEM Uhrzeit und Zeitzone:<br />
Durch Eingabe von <br />
<pre><br />
{localtime()}<br />
</pre><br />
in die FHEM-Kommandozeile überprüfen, ob die FHEM-Uhrzeit plausibel ist. Ist dies nicht der Fall sollten die Uhrzeit auf Systemebene überprüft werden und ggf. die Systemeinstellungen angepasst werden.<br />
Ermitteln der Bezeichnung der eigenen Zeitzone über die System-Kommandozeile mit<br />
<pre><br />
tzselect<br />
</pre><br />
und diese Bezeichnung in die Datei ''/etc/timezone'' eintragen und <br />
<pre><br />
export TZ=`cat /etc/timezone`<br />
</pre><br />
der Datei ''/etc/profile'' hinzufügen und dann das System neu starten. Nun muss die Zeitanzeige in FHEM korrekt sein.<br />
<br />
4. FHEM Sprache:<br />
Durch Eingabe von <br />
<pre><br />
{localtime()}<br />
</pre> in die FHEM-Kommandozeile überprüfen, in welcher Sprache der Wochentag angezeigt wird. Stimmt die Sprache nicht, dann auf der System-Kommandozeile<br />
<pre><br />
dpkg-reconfigure locales<br />
</pre> eingeben und aus der Liste z.B. ''de_DE.UTF-8'' zusätzlich auswählen. Dieser Befehl gilt für Debian-basierte Betriebssysteme - für andere Betriebssysteme ist eine analoge Funktion zu verwenden. Mit Eingabe von <br />
<pre><br />
locale -a<br />
</pre> auf der System-Kommandozeile überprüfen, ob die ausgewählte Sprache nun zur Verfügung steht. Sollte FHEM nach einem Neustart noch immer nicht die gewünschte Sprache verwenden, kann man auf einem System V Linux durch Hinzufügen von z.B.<br />
<pre><br />
export LANG=de_DE.UTF-8<br />
</pre> in die Datei ''/etc/init.d/fhem'' (irgendwo zwischen ''start'' und ''perl'') und erneutem Neustart von FHEM die Sprache für FHEM erzwingen. Bei einem Systemd Linux kann man die Einstellungen mit ''systemctl edit --full fhem.service'' bearbeiten. Spätestes jetzt muss die Wochentagsanzeige in FHEM korrekt sein.<br />
<br />
5. Nur für den Weblink erforderlich:<br />
Installation des Perl-Moduls ''DateTime'' über die System-Kommandozeile mit<br />
<pre><br />
sudo apt-get install libdatetime-perl<br />
</pre> <br />
oder mit CPAN.<br />
<br />
=== Define ===<br />
Siehe {{Link2CmdRef|Anker=DWD_OpenDatadefine|Label=Commandref}}.<br />
<br />
=== Attributes ===<br />
Siehe {{Link2CmdRef|Anker=DWD_OpenDataattr|Label=Commandref}}.<br />
<br />
== Anwendungsbeispiele ==<br />
=== Beispiel zur Modul-Einrichtung ===<br />
<br />
* Wettervorhersage<br />
Für die Wettervorhersage muss der Stationscode ermittelt werden. Dazu den [https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/mosmix_stationskatalog.pdf MOSMIX Stationskatalog] herunterladen, öffnen und die gewünschte Station heraussuchen (Spalte ''id''). Einen Teil der deutschen Stationen kann man auch der [https://www.dwd.de/DE/derdwd/messnetz/bodenbeobachtung/messnetzkarte_boden.pdf Bodenmessnetzkarte] entnehmen. Den ermittelten Stationscode kann man dann entweder für eine Einzelabfrage als Parameter für das Kommando ''get forecast'' verwenden oder für die automatische Aktualisierung als Attribut ''forecastStation'' hinterlegen. Insgesamt werden vom DWD mehr als 70 Merkmale zur Verfügung gestellt. Eine Auflistung findet sich im Dokument [https://opendata.dwd.de/weather/lib/MetElementDefinition.xml MetElementDefinition]. Nur ein kleiner Teil der Merkmale wird in der Standardeinstellung des Moduls als Reading zur Verfügung gestellt. Wer andere Merkmale benötigt muss sie mit Komma getrennt dem Attribut ''forecastProperties'' zuweisen. Es empfiehlt sich zur Performance-Optimierung sowohl das Attribut ''forecastDays'' als auch das Attribut ''forecastProperties'' auf den tatsächlichen Bedarf einzustellen.<br />
<br />
* Wetterwarnungen<br />
Für die Wetterwarnungen muss die Warnzelle ermittelt werden. Dazu [https://www.dwd.de/DE/leistungen/opendata/help/warnungen/cap_warncellids_csv.csv Warnzellen-ID Katalog] herunterladen, öffnen und die gewünschte Warnzelle heraussuchen. Unterstützt werden Gemeinden (beginnen mit 8), Landkreise (beginnen mit 1 oder 9) oder Küste (beginnen mit 5). Die Warnzellen-ID kann man dann entweder für eine Einzelabfrage als Parameter für das Kommando ''get alerts'' verwenden oder für die automatische Aktualisierung als Attribut ''alertArea'' hinterlegen. Die Warnzellen-ID ist ab der 2. Stelle identisch mit den ersten Ziffern des amtlichen Gemeindeschlüssels. Man kann z.B. den Namen von Gemeinde oder Landkreis bei den [https://www.statistik-bw.de/Statistik-Portal/gemeindeverz.asp Statistischen Ämtern des Bundes und der Länder] eingeben, den amtlichen Gemeindeschlüssel ermitteln und dann mit vorangestellter 1, 8 oder 9 im Warnzellen-ID Katalog des DWD nach einem Eintrag mit exakter oder weitgehender Übereinstimmung suchen. Wem das zu kompliziert vorkommt, der kann bei mehrdeutigen Gemeinde- bzw. Landkreisbezeichnungen auch versuchen auszuprobieren, welche die richtige Warnzellen-ID ist.<br />
<br />
Um das Modul mit automatisch Aktualisierung von Vorhersage und Wetterwarnungen zu nutzen, kann z.B. folgendes in die [[Konfiguration]] eingetragen werden:<br />
<br />
<pre><br />
define DWD DWD_OpenData<br />
attr DWD alertArea 111000000<br />
attr DWD forecastStation 99810<br />
attr DWD forecastDays 3<br />
attr DWD forecastWW2Text 1<br />
</pre><br />
<br />
* Performance<br />
Das DWD_OpenData-Modul ist ein Datenmodul mit relativ vielen Readings. In der Standardkonfiguration wird, wie bei jedem anderen FHEM Modul, bei jeder Änderung jedes Readings ein FHEM internes Ereignis erzeugt, damit andere FHEM Devices auf diese Änderungen reagieren können. Diese Ereignisse sorgen auch dafür, dass man Änderungen in der Weboberfläche sofort angezeigt bekommt, ohne die Webseite neu aufzurufen. Interessiert sich aber kein FHEM Device für die Änderungsbenachrichtigung bestimmter Readings, entsteht unnötiger Verarbeitungs-Overhead, der je nach FHEM Konfiguration und verfügbarer CPU-Leistung auch mehrere Sekunden benötigen kann und in dieser Zeit andere Abläufe blockiert. Um die Performance zu optimieren, empfiehlt es sich, mit [[event-on-update-reading]] für eine angepasste und dadurch effizientere Verarbeitung zu sorgen, indem man nur für jene Readings Ereignisse zulässt, welche man für die Weiterverarbeitung braucht. Der DWD_OpenData_Weblink braucht z.B. gar keine Ereignisse, um zu funktionieren. Hier eine minimalistische Beispielkonfiguration:<br />
<br />
<pre><br />
attr DWD event-on-update-reading state,fc_state,a_state<br />
</pre><br />
<br />
Weitere Details zur Installation und Konfiguration des Moduls finden sich in der<br />
{{Link2CmdRef|Anker=DWD_OpenData|Label=Commandref}}.<br />
<br />
=== Beispiel für die Einrichtung eines Meteogramms ===<br />
Um den vorhergesagten Wetterverlauf als Meteogramm in Kurvenform mit [[SVG]] darzustellen, kann man wie folgt vorgehen:<br />
<br />
1. 99_myUtils.pm<br />
<br />
Für die Bestimmung der Werte für den SVG-Plot wird eine Perl-Funktion benötigt, die in die Datei 99_myUtils.pm vor dem Ende eingefügt wird. Wer diese FHEM-Datei noch nicht nutzt, legt sie einfach an (siehe [[99_myUtils_anlegen]]).<br />
<source lang="perl"><br />
package main;<br />
<br />
use strict;<br />
use warnings;<br />
<br />
...<br />
<br />
#<br />
# (c) mumpitzstuff 19.12.2018<br />
#<br />
# see https://forum.fhem.de/index.php/topic,83097.msg874150.html#msg874150<br />
#<br />
sub logProxy_dwd2Plot($$$$;$$$)<br />
{<br />
my ($device, $fcValue, $from, $to, $fcHour, $expMode, $shiftTime) = @_;<br />
my $regex;<br />
my @rl;<br />
<br />
return undef if(!$device);<br />
<br />
if ($fcValue =~ s/_$//)<br />
{<br />
$regex = "^fc[\\d]+_[\\d]+_".$fcValue."\$";<br />
}<br />
else<br />
{<br />
$regex = "^fc[\\d]+_".$fcValue."\$";<br />
}<br />
<br />
$fcHour = 12 if(!defined($fcHour));<br />
$expMode = "point" if(!defined($expMode));<br />
#Log3 undef,2, "Regex: ".$regex;<br />
<br />
# ermitteln aller relevanten Readings<br />
if ( defined($defs{$device}) )<br />
{<br />
if ( $defs{$device}{TYPE} eq "DWD_OpenData" )<br />
{<br />
@rl = sort<br />
{<br />
my ($an) = ($a =~ m/fc(\d+)_.*/);<br />
my ($bn) = ($b =~ m/fc(\d+)_.*/);<br />
my ($ao) = ($a =~ m/fc\d+_(\d+).*/);<br />
my ($bo) = ($b =~ m/fc\d+_(\d+).*/);<br />
$an <=> $bn or $ao <=> $bo or $a cmp $b;<br />
} ( grep /${regex}/,keys %{$defs{$device}{READINGS}} );<br />
return undef if ( !@rl );<br />
}<br />
else<br />
{<br />
Log3 undef, 2, "logProxy_dwd2Plot: $device is not a DWD_OpenData device";<br />
return undef;<br />
}<br />
}<br />
<br />
my $fromsec = SVG_time_to_sec($from);<br />
my $tosec = SVG_time_to_sec($to);<br />
my $sec = $fromsec;<br />
my ($h, $hp, $fcDay, $mday, $mon, $year);<br />
my $timestamp;<br />
<br />
my $reading;<br />
my $value;<br />
my $prev_value;<br />
my $min = 999999;<br />
my $max = -999999;<br />
my $ret = "";<br />
<br />
# while not end of plot range reached<br />
while (($sec < $tosec) && @rl)<br />
{<br />
#remember previous value for start of plot range<br />
$prev_value = $value;<br />
<br />
$reading = shift @rl;<br />
($fcDay) = $reading =~ m/^fc(\d+).*/;<br />
($hp) = $reading =~ m/^fc\d+_(\d+).*/;<br />
#Log 1, "hp: ".$hp;<br />
<br />
if ($hp)<br />
{<br />
$h = ReadingsVal($device, "fc".$fcDay."_".$hp."_time", $fcHour);<br />
if ($h =~ m/^(\d+):\d+/)<br />
{<br />
$h = $1;<br />
}<br />
}<br />
else<br />
{<br />
$h = $fcHour;<br />
}<br />
<br />
$value = ReadingsVal($device, $reading, undef);<br />
<br />
# calculate minutes of sunshine per hour<br />
if ($fcValue =~ /^SunD(\d+)/)<br />
{<br />
if (defined($1))<br />
{<br />
$value = $value / ($1 * 36);<br />
}<br />
else<br />
{<br />
$value = $value / (12 * 36);<br />
}<br />
}<br />
<br />
# calculate amount of rain per hour<br />
if ($fcValue =~ /^RR(\d+)c$/)<br />
{<br />
if (defined($1))<br />
{<br />
$value /= $1;<br />
}<br />
}<br />
<br />
($year, $mon, $mday) = split('\-',ReadingsVal($device, "fc".$fcDay."_date",undef));<br />
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, $h, 0, 0);<br />
$sec = SVG_time_to_sec($timestamp);<br />
if (defined($shiftTime))<br />
{<br />
$sec += $shiftTime;<br />
$timestamp = logProxy_shiftTime($timestamp, $shiftTime);<br />
}<br />
<br />
# skip all values before start of plot range<br />
next if ( $sec < $fromsec );<br />
<br />
# add first value at start of plot range<br />
if ( !$ret && $prev_value )<br />
{<br />
$min = $prev_value if ( $prev_value < $min );<br />
$max = $prev_value if ( $prev_value > $max );<br />
$ret .= "$from $prev_value\n";<br />
}<br />
<br />
# done if after end of plot range<br />
last if ($sec > $tosec);<br />
<br />
$min = $value if ( $value < $min );<br />
$max = $value if ( $value > $max );<br />
<br />
# add actual control point<br />
$ret .= "$timestamp $value\n";<br />
}<br />
<br />
if (($sec < $tosec) && !@rl && ($expMode eq "day"))<br />
{<br />
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, 23, 59, 59);<br />
$_ = SVG_time_to_sec($timestamp);<br />
if (defined($shiftTime))<br />
{<br />
$_ += $shiftTime;<br />
$timestamp = logProxy_shiftTime($timestamp, $shiftTime);<br />
}<br />
<br />
if ($_ < $tosec)<br />
{<br />
$ret .= "$timestamp $value\n";<br />
}<br />
else<br />
{<br />
$ret .= "$to $value\n";<br />
}<br />
}<br />
elsif (($sec > $tosec) && ($expMode eq "day"))<br />
{<br />
$value = $prev_value + ($value - $prev_value) * (86400 + ($tosec - $sec)) / 86400;<br />
$ret .= "$to $value\n";<br />
}<br />
<br />
return ($ret, $min, $max, $prev_value);<br />
} <br />
<br />
1;<br />
</source><br />
<br />
2. LogProxy<br />
<br />
Wer bereits ein [[logProxy]]-Device hat, muss den Namen seines logProxy-Devices in die weiter unter aufgeführte GPlot-Konfiguration eintragen. Ansonsten wird es wie folgt neu erstellt:<br />
<pre><br />
define LogProxy logProxy<br />
</pre><br />
<br />
3. FileLog<br />
<br />
Das Meteogramm kennt anders als andere FHEM-Plots keine Vergangenheit außer heute. Trotzdem wird aus formalen Gründen ein [[FileLog]]-Device benötigt. Dazu kann ein beliebiges vorhandenes FileLog-Device verwendet werden. Wer will, kann hierfür aber auch ein neues FileLog Device für das DWD_OpenData-Device anlegen (Achtung: wird schnell umfangreich):<br />
<pre><br />
define FileLog_DWD FileLog ./log/DWD-%Y-%m.log DWD<br />
</pre><br />
<br />
Im folgenden wird für das FileLog-Device der Platzhalter ''FileLog_Dummy'' verwendet, der mit dem Namen des gewählten FileLog-Devices zu ersetzen ist.<br />
<br />
4. SVG Plot<br />
<br />
Das eigentliche Meteogramm ist ein SVG-Device. Will man mehrere Tage darstellen bietet sich die folgende Definition an:<br />
<pre><br />
define SVG_DWD SVG FileLog_Dummy:SVG_DWD:CURRENT<br />
attr SVG_DWD fixedoffset 6<br />
attr SVG_DWD fixedrange 7days<br />
attr SVG_DWD nrAxis 1,2<br />
</pre><br />
<br />
Dabei muss das SVG-Attribut ''fixedoffset'' entweder gleich oder kleiner als die Einstellung des DWD_OpenData-Attributs ''forecastDays'' (Standardwert: 6 Tage) gewählt werden und das SVG-Attribut ''fixedrange'' um eins größer als ''fixedoffset'' eingestellt werden.<br />
<br />
Will man stattdessen nur die nächsten 24 Stunden anzeigen, nimmt man folgende Einstellungen:<br />
<pre><br />
define SVG_DWD SVG FileLog_Dummy:SVG_DWD:CURRENT<br />
attr SVG_DWD endPlotNow 1<br />
attr SVG_DWD fixedoffset 1<br />
attr SVG_FileLog_WETTER_DWD_3 label "Tmin: $data{max1} °C, Tmax: $data{min1} °C"<br />
attr SVG_DWD nrAxis 1,2<br />
</pre><br />
<br />
Um die DWD_OpenData-Readings mit dem Plot zu verknüpfen, muss man nun die GPlot-Konfigurationsdatei des SVG-Plots manuell bearbeiten. Dazu auf den Link klicken, der im SVG_DWD-Device am Internal ''GPLOTFILE'' steht. Die y-Wertebereiche für die Regenmenge und die Temperaturen sind im Beispiel auskommentiert (Autorange). Das kann man so lassen oder man stellt sie nach den eigenen Wetter-Gegebenheiten ein. Je nach Konfiguration des DWD_OpenData-Attributs ''forecastResolution'' sind aber noch einige weitere Einstellungen anzupassen. Das folgende Beispiel ist für die 3h-Auflösung:<br />
<pre><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel " "<br />
set title 'Wettervorhersage'<br />
set ytics <br />
set y2tics <br />
set grid ytics<br />
set ylabel "Regen [mm]"<br />
#set yrange [0:4]<br />
set y2label "Temperatur [°C]"<br />
#set y2range [-5:35]<br />
set y3label "Wolken/Regen/Sonne [%]"<br />
set y3range [0:100]<br />
<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","TTT_",$from,$to,0,"day")<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","Tx",$from,$to,18,"day")<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","Tn",$from,$to,6,"day")<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","SunD3_",$from,$to,0,"day",(-3*3600))<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","RR3c_",$from,$to,0,"day",(-3*3600))<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","FX1_",$from,$to,0,"day")<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","R600_",$from,$to,0,"day",(-3*3600))<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","Neff_",$from,$to,0,"day")<br />
#LogProxy ConstX:TimeNow(),0,100<br />
#LogProxy ConstY:0<br />
<br />
plot "<IN>" using 1:2 axes x1y2 title 'T' ls l0 lw 2 with quadraticSmooth,\<br />
"<IN>" using 1:2 axes x1y2 title 'Tmax' ls l0dot lw 2 with quadraticSmooth,\<br />
"<IN>" using 1:2 axes x1y2 title 'Tmin' ls l0dot lw 2 with quadraticSmooth,\<br />
"<IN>" using 1:2 axes x1y3 title 'Sonne' ls l4fill lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Regenmenge' ls l2fill lw 1 with steps,\<br />
"<IN>" using 1:2 axes x1y3 title 'Wind' ls l1 lw 1 with quadraticSmooth,\<br />
"<IN>" using 1:2 axes x1y3 title 'Regen' ls l5fill lw 1 with quadraticSmooth,\<br />
"<IN>" using 1:2 axes x1y3 title 'Wolken' ls l6fill lw 1 with quadraticSmooth,\<br />
"<IN>" using 1:2 axes x1y3 notitle ls l5 lw 4 with lines,\<br />
"<IN>" using 1:2 axes x1y2 notitle ls l5 lw 1 with lines<br />
</pre><br />
<br />
Verwendet man dagegen eine Auflösung von 1 Stunde, sind folgende LogProxy-Einträge erforderlich:<br />
<pre><br />
#LogProxy Func:logProxy_dwd2Plot("DWD","TTT_",$from,$to,0,"day")<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","Tx",$from,$to,18,"day")<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","Tn",$from,$to,6,"day")<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","SunD1_",$from,$to,0,"day",(-1*3600))<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","RR1c_",$from,$to,0,"day",(-1*3600))<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","FX1_",$from,$to,0,"day")<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","R101_",$from,$to,0,"day",(-0.5*3600))<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","Neff_",$from,$to,0,"day")<br />
#LogProxy ConstX:TimeNow(),0,100<br />
#LogProxy ConstY:0<br />
</pre><br />
<br />
Für die Darstellung der nächsten 24 Stunden mit einer Auflösung von 1 Stunde nimmt man folgende GPlot-Konfiguration:<br />
<pre><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel " "<br />
set title '<L1>'<br />
set ytics<br />
set y2tics<br />
set y3tics<br />
set grid xtics y2tics<br />
set ylabel "Regen [mm]"<br />
set y2label "Temperatur [°C]"<br />
set y3label "Wolken/Regen/Sonne [%]"<br />
set y3range [0:100]<br />
<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","TTT_",$from,$to,0,"day")<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","SunD1_",$from,$to,0,"day",(-1*3600))<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","RR1c_",$from,$to,0,"day",(-1*3600))<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","FX1_",$from,$to,0,"day")<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","R101_",$from,$to,0,"day",(-0.5*3600))<br />
#LogProxy Func:logProxy_dwd2Plot("DWD","Neff_",$from,$to,0,"day")<br />
#LogProxy ConstY:0<br />
<br />
plot "<IN>" using 1:2 axes x1y2 title 'T' ls l0 lw 2 with quadraticSmooth,\<br />
"<IN>" using 1:2 axes x1y3 title 'Sonne' ls l4fill lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Regenmenge' ls l2fill lw 1 with steps,\<br />
"<IN>" using 1:2 axes x1y3 title 'Wind' ls l1 lw 1 with quadraticSmooth,\<br />
"<IN>" using 1:2 axes x1y3 title 'Regen' ls l5fill lw 1 with quadraticSmooth,\<br />
"<IN>" using 1:2 axes x1y3 title 'Wolken' ls l6fill lw 1 with quadraticSmooth,\<br />
"<IN>" using 1:2 axes x1y2 notitle ls l2 lw 2 with lines<br />
</pre><br />
<br />
Je nachdem, welche Auflösung man verwendet, werden unterschiedliche Readings des DWD_OpenData-Devices benötigt. Diese sind in den LogProxy-Zeilen in der GPlot-Konfigurationsdatei zu finden und müssen auf jeden Fall dem Attribut ''forecastProperties'' des DWD_OpenData-Device hinzugefügt werden.<br />
<br />
Viele Detaileinstellungen des Meteogramms lassen sich individualisieren. Man kann z.B. mehr oder weniger Daten anzeigen und zumindest für ''heute'' auch aktuelle Messwerte hinzufügen.<br />
<br />
Hier ein Beispiel für ein Meteogramm über 4 Tage mit 3 Stunden Auflösung:<br />
<br />
[[File:DWDODmeteogram4d3h.png|500px]]<br />
<br />
<br />
=== Beispiel für die Einrichtung eines Weblinks ===<br />
Zur graphischen Darstellung der Vorhersage und der Wetterwarnungen mit [[FHEMWEB]] steht das Modul [https://raw.githubusercontent.com/jnsbyr/fhem/master/FHEM/99_DWD_OpenData_Weblink.pm 99_DWD_OpenData_Weblink.pm] zur Verfügung.<br />
<br />
Zunächst die Moduldatei herunterladen und in das Modulverzeichnis ''fhem/FHEM'' kopieren. Entweder die Datei direkt auf den FHEM-Server herunterladen (z.B. mit ''wget'') oder beim indirekten Herunterladen darauf achten, dass dabei das Encoding nicht verändert wird (also z.B. bei WinSCP den Binär-Modus und nicht den Text-Modus verwenden). Ansonsten werden später z.B. Sonderzeichen wie ''°C'' falsch angezeigt. <br />
<br />
Anschließend kann in die [[Konfiguration]] z.B. folgendes eingetragen werden:<br />
<br />
<pre><br />
define DWD_Weblink_Generator DWD_OpenData_Weblink<br />
attr DWD_Weblink_Generator IODev DWD<br />
attr DWD_Weblink_Generator forecastDays 4<br />
# refreshRate nur dann setzten, wenn der Browser Java-Script beherrscht:<br />
attr DWD_Weblink_Generator refreshRate 900<br />
<br />
define DWD_Weblink weblink htmlCode { DWD_OpenData_Weblink::AsHtmlH("DWD_Weblink_Generator") } <br />
</pre><br />
<br />
Damit legt man das Weblink-Generator-Device an und verknüpft es mit dem DWD_OpenData-Device. Außerdem wird der [[weblink ]] selbst angelegt, der seinerseits mit dem Weblink-Generator-Device verknüpft wird. Der Weblink benötigt für seine Funktion eine bestimmte Auswahl der Vorhersage-Merkmale. Wer das Attribut ''forecastProperties'' des DWD_OpenData-Moduls anpassen will, muss diese Merkmale auf jeden Fall mit berücksichtigen. <br />
<br />
Wenn vom Weblink nichts im Browser zu sehen ist, kann das daran liegen, dass der Browser kein aktuelles JavaScript verwendet oder JavaScript deaktiviert ist. Dann sollte das Attribut ''refreshRate'' auf 0 Sekunden eingestellt oder gelöscht werden. Mit aktiviertem Refresh werden die Daten auch ohne Seitenneuaufbau regelmäßig und bei Tab-Wechsel aktualisiert.<br />
<br />
Die Liste der erforderlichen Vorhersage-Merkmale finden sich zusammen mit allen weiteren Details zur Installation und Konfiguration in der Modulhilfe von ''99_DWD_OpenData_Weblink.pm'', die man z.B. nach dem Anlegen des Weblink-Generator-Devices über die Weboberfläche abrufen kann.<br />
<br />
Hier ein Ausschnitt aus der Darstellung des Weblinks mit [[FHEMWEB]]:<br />
<br />
[[File:DWDODweblink.png|500px]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Luftdaten.info/Feinstaub&diff=31190Luftdaten.info/Feinstaub2019-09-08T19:40:53Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Collect data from the Lufdaten.info project<br />
|ModType=d<br />
|ModCmdRef=LuftdatenInfo<br />
|ModForumArea=Bastelecke<br />
|ModFTopic=66674<br />
|ModTechName=59_LuftdatenInfo.pm<br />
|ModOwner=igami ({{Link2FU|4106|Forum}} / [[Benutzer:no_Legend|Wiki]])<br />
}}<br />
'''LuftdatenInfo''' ist ein Modul, das Sensor-Daten des Projektes [http://luftdaten.info/ luftdaten.info] in FHEM abrufbar macht.<br />
Es können lokale oder entfernte Sensoren abgefragt werden.<br />
<br />
== Sensor bauen ==<br />
Der Bau eines Sensors wird auf der [http://luftdaten.info/feinstaubsensor-bauen/ Projektseite] beschrieben.<br />
Die Kosten belaufen sich - je nach Bezugsquelle der einzelnen Bauteile und Bauform - auf ca. 30-50 €.<br />
<br />
Zwei kurze Videos zum Aufbau und Flashen des Sensors sind u.a. auf Youtube zu finden:<br />
* [https://youtu.be/8oLCTeCfabU Luftdaten.info Feinstaubsensor selber bauen]<br />
* [https://youtu.be/NK3E083WayM luftdaten.info Feinstaubsensor NodeMCU flashen unter Windows]<br />
<br />
== Datenschutz ==<br />
In der Standard-Einstellung der Software werden die Messwerte zu der Projektseite hochgeladen und dort, nachdem man den Maintainern des Projekts eine E-Mail mit weiteren Daten hat zukommen lassen, auf einer [http://deutschland.maps.luftdaten.info/ Karte] dargestellt. Dazu sind die "letzten Schritte" auf der [https://luftdaten.info/feinstaubsensor-bauen/ Anleitungsseite] ganz unten zu befolgen.<br />
<br />
Sollte keine Übertragung der Daten gewünscht sein, lassen sich die Geräte auch ausschließlich lokal betreiben und nicht von Fremden auslesen. Zumindest den Betreibern der Seite ist die Verknüpfung von Gerät zu Standort bekannt, ggf. lassen sich über die ermittelten Sensordaten auch genauere Standortdaten ermitteln.<br />
<br />
== Daten nutzen ==<br />
'''LuftdatenInfo''' unterstützt folgende drei Betriebsmodi:<br />
<br />
=== Entfernte Abfrage ===<br />
Mit <code>defmod <name> LuftdatenInfo remote <SensorID1> [<SensorID2> ..]</code> können - auch fremde - entfernte Geräte von luftdaten.info abgefragt werden. Angelegt werden neben den Werten für PM2.5 und PM10 auch Ortsdaten (ungefähre Latitude, ungefähre Longitude und Postleitzahl + Stadt). Weitere Sensoren eines Gerätes kann man ggf. durch Hochzählen der SensorID einbinden, z.B. liefert die SensorID 17382 Feinstaubdaten, SensorID 17383 liefert darüber hinaus auch noch Temperatur, Luftdruck und Luftfeuchte zurück. Andere Sensoren als der Feinstaubsensor werden aktuell auf luftdaten.info nicht angezeigt, müssen also erprobt werden.<br />
<br />
=== Lokale Abfrage ===<br />
Ein Gerät, welches Daten nicht an luftdaten.info oder eine der anderen Plattformen melden soll, kann trotzdem lokal abgefragt werden. Dazu ist mit <code>defmod <name> LuftdatenInfo local <IP></code> das Gerät anzulegen. Es muss hier keine SensorID angegeben werden. Ohne weitere Einstellungen (<code>rawReadings</code>) liefert der Sensor hier allerdings keine Sensordaten! Diese kann man über den Slave-Modus einbinden. [Das ist nicht unbedingt richtig, siehe Diskussion]<br />
<br />
=== Lokaler Slave-Modus ===<br />
Im Slave-Modus können zu einem lokalen Gerät die einzelnen Sensoren als FHEM-Devices angelegt werden. Um den Slave-Modus nutzen zu können muss wie oben beschrieben ein lokales (Master-)Gerät angelegt werden. Einen Slave legt man mit <code>define <slave-name> LuftdatenInfo slave <master-name> [name-sensor1, name-sensor2]</code> an. Die Namen der Sensoren enthält man, indem man <code>get <master-name> sensors</code> ausführt. Das Ergebnis könnte eine Liste ähnlich wie diese sein:<br />
<br />
BME680_air_quality<br />
BME680_humidity<br />
BME680_pressure<br />
BME680_pressure_nn<br />
BME680_quality_data<br />
BME680_temperature<br />
DHT22_humidity<br />
DHT22_temperature<br />
SDS011_P1<br />
SDS011_P2<br />
max_micro<br />
min_micro<br />
samples<br />
sensor_start_date<br />
sensor_start_time<br />
signal<br />
<br />
In diesem Gerät ist ein SDS011-Feinstaubsensor (vergebene Bezeichnung ''SDS011''), ein BME680-Umweltsensor (vergebene Bezeichnung ''BME680'') und ein DHT22-Luftfeuchte-/Temperatursensor (vergebene Bezeichnung ''DHT22'') verbaut. <br />
<br />
Möchte man nun die Werte des BME680 in ein Slave-Gerät umleiten, muss man dieses wie folgt definieren:<br />
defmod <slave-bme680> LuftdatenInfo slave <master-name> BME680_air_quality BME680_humidity BME680_pressure BME680_pressure_nn BME680_quality_data BME680_temperature<br />
<br />
Die anderen gelisteten "Sensoren" sind keine, sondern Datenpunkte:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Wert !! Bedeutung<br />
|-<br />
| max_micro || unbekannt<br />
|-<br />
| min_micro || unbekannt<br />
|-<br />
| sensor_start_date || Datum an dem das Gerät gestartet wurde<br />
|-<br />
| sensor_start_time || Zeitpunkt zu dem das Gerät gestartet wurde<br />
|-<br />
| signal || WiFi-Leistungspegel (Signalstärke) in dBm<br />
|}<br />
<br />
[[Kategorie:Other Components]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=JUDO_iSoft_Plus&diff=31112JUDO iSoft Plus2019-08-13T06:38:36Z<p>AndreasMohr: Abschnitt Geräte-Registrierung; Erwähnung von QR-Code-Problemen</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=judo-soft-plus.jpg|200px<br />
|Bildbeschreibung=JUDO i-soft plus Wasserenthärtungsanlage<br />
|HWProtocol=IP<br />
|HWType=Wasserenthärter<br />
|HWCategory=IP<br />
|HWVoltage=230&nbsp;V<br />
|HWPoweredBy=AC<br />
|HWSize=39x67x45 cm (BxHxT)<br />
|HWComm=n/a<br />
|HWChannels=n/a<br />
|HWPowerConsumption=?<br />
|HWDeviceFHEM=[[HTTPMOD]]<br />
<!-- |ModOwner= --><br />
|HWManufacturer=Judo GmbH<br />
}}<br />
__TOC__<br />
<br />
Die JUDO i-soft plus Enthärtungsanlage [https://judo.eu/produkt/judo-i-soft-plus-vollautomatische-enthaertungsanlage/] ist eine Wasserenthärtungsanlage mit IP-Konnektivität. <br />
Sie verfügt über LAN und WLAN-Anschluss und ist auf die Steuerung via App des Herstellers ausgelegt.<br />
<br />
== Geräte-Registrierung ==<br />
<br />
Für eine erfolgreiche Integration in FHEM muss die Anlage über das Menü beim Hersteller registriert werden (wohl nur i-soft plus; z.B. i-soft safe kann das wohl nicht, schlechtere Display-Ausstattung - hier gilt dann [https://www.ju-control.app/] oder die Handy-Apps).<br />
Die folgenden Informationen sind erforderlich:<br />
<br />
* Benutzername: Selbst gewählter Login-Name auf der i-soft plus (vgl. Gerätehandbuch)<br />
* Kennwort: Selbst gewähltes Kennwort<br />
* Seriennummer: Seriennummer des Geräts. Diese ist entweder über das Menü auslesbar oder alternativ auch über die APP des Herstellers.<br />
* IP-Adresse: Die IP-Adresse des Geräts im Heimnetz. <br />
<br />
Bei den Registrier-Prozessen ist zwingend zu beachten, dass es '''mehrere''' Labels mit QR-Codes / Gerätedaten geben kann (zumindest bei i-soft safe): auf den Gehäuse-Seite'''n''' und auf dem Connectivity Module - man sollte also tunlichst die '''richtige''' Referenz erwischen, sonst Fehlschlag!<br />
(Ich hatte mehrere Prozess-Probleme, somit in Beschwerdemail mehrere momentan existierende gravierende Registrier-Prozess-Impräzisionen angem***t, daraufhin INSTANTAN (8 Uhr) Rückruf durch Kundendienst! *daumenhoch*)<br />
<br />
== Einbindung in FHEM ==<br />
<br />
Das Gerät wird mittels des Moduls HTTPMOD eingebunden. Dazu gilt zunächst die folgende Konfiguration als Basis.<br />
Zunächst legen wir die Standardanfrage an das Modul fest. Die Portnummer 8124 ist vom Hersteller vorgegeben. Wir vergeben gleich ein paar Platzhalter, die später in den Aufrufen und den Antworten ersetzt werden, damit wir die Werte nur an einer zentralen Stelle konfigurieren müssen.<br />
<br />
<pre><br />
define JUDO_iSoft HTTPMOD https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=4&token=%token% 300<br />
</pre><br />
Mit dieser Definition wird als Standard-Anfrage die Statusabfrage nach dem Wasserstop gesendet. Diese wird zyklisch alle 300 Sekunden wiederholt. <br />
Wem das nicht reicht, der kann den Zyklus herunter setzen oder auch nach anderen Standard-Werten abfragen. Wer das kontinuierliche Pollen vermeiden will, setzt den Wert auf 0.<br />
<br />
Nach erfolgreicher Authentifizierung wird von der i-soft ein Token generiert und muss bei jedem Aufruf übergeben werden:<br />
<br />
<pre><br />
attr JUDO_iSoft replacement01Mode reading<br />
attr JUDO_iSoft replacement01Regex %token%<br />
attr JUDO_iSoft replacement01Value token<br />
</pre><br />
<br />
Anschließend legen wir die Ersetzungen für die anderen Platzhalter fest: <br />
<br />
<pre><br />
attr JUDO_iSoft replacement02Mode text<br />
attr JUDO_iSoft replacement02Regex %JUDO_ipaddress%<br />
attr JUDO_iSoft replacement02Value <hier eigene IP Adresse im lokalen Netz eintragen><br />
attr JUDO_iSoft replacement03Mode text<br />
attr JUDO_iSoft replacement03Regex %JUDO_password%<br />
attr JUDO_iSoft replacement03Value <hier Kennwort eintragen><br />
attr JUDO_iSoft replacement04Mode text<br />
attr JUDO_iSoft replacement04Regex %JUDO_username%<br />
attr JUDO_iSoft replacement04Value <hier Benutzername eintragen><br />
attr JUDO_iSoft replacement05Mode text<br />
attr JUDO_iSoft replacement05Regex %JUDO_serial%<br />
attr JUDO_iSoft replacement05Value <hier Seriennummer eintragen><br />
</pre><br />
<br />
Die Authentifizierung der Anlage erfolgt zwei-stufig. Zunächst muss ein Aufruf mit Benutzername und Kennwort erfolgen. Als Antwort erhält man einen JSON-String, der das Token beinhaltet. Mit diesem Token wird anschließend die Funktion connect aufgerufen und die Seriennummer des Geräts mit übergeben. <br />
HTTPMOD erkennt, wenn ein neues Login erforderlich ist, wenn die Judo die Rückmeldung "no token" oder "not logged in" liefert.<br />
<br />
Achtung: Als Parameter muss ebenfalls der Typ "i-soft plus" übergeben werden. Vermutlich ist dieser bei anderen Geräten des Herstellers anders. Ich habe ihn hier fix eingetragen, da ich keine Möglichkeit zum Testen anderer Geräte habe. <br />
<br />
<pre><br />
attr JUDO_iSoft showError 1<br />
attr JUDO_iSoft authRetries 2<br />
attr JUDO_iSoft reAuthRegex (no token)|(not logged in)<br />
attr JUDO_iSoft sid01ParseResponse 1<br />
attr JUDO_iSoft sid01URL https://%JUDO_ipaddress%:8124/?group=register&command=login&msgnumber=1&name=login&user=%JUDO_username%&password=%JUDO_password%&role=customer<br />
attr JUDO_iSoft sid02URL https://%JUDO_ipaddress%:8124/?group=register&command=connect&msgnumber=6&token=%token%&parameter=i-soft%20plus&serial%20number=%JUDO_serial%<br />
</pre><br />
<br />
Damit ist die Grundkonfiguration hergestellt und die Anlage kann sich connecten. <br />
In den einzelnen JSON-Rückantworten der Anlage werden die Werte zur jeweilige Anfrage immer als "data" zurück geliefert. Mit der Standard-Konfiguration<br />
<br />
<pre><br />
attr JUDO_iSoft extractAllJSON 1<br />
</pre><br />
<br />
werden daraus automatisch entsprechende Readings angelegt. Da wir aber dann immer das Reading "data" überschreiben würden, kommt eine weitere Ersetzung zum Einsatz. In der Antwort steht neben einer Kaskadierung (group) auch der zugehörige Befehl (command). Ich habe mich dafür entschieden, ein neues Reading mit dem jeweiligen Command-Namen anzulegen. Die zugehörigen Ersetzungen sind wie folgt.<br />
Erklärung zum Ausdruck reading03OExpr: Zunächst werden die Leerzeichen im Rückgabewert ($val) durch "-" ersetzt. Mit dem so veränderten String erzeugen wir ein neues Reading mit dem Wert aus dem Reading data. <br />
<br />
<pre><br />
attr JUDO_iSoft reading01JSON data<br />
attr JUDO_iSoft reading01Name token<br />
attr JUDO_iSoft reading01Regex "token":"([^"]+)"<br />
attr JUDO_iSoft reading02JSON group<br />
attr JUDO_iSoft reading03JSON command<br />
attr JUDO_iSoft reading03OExpr $val =~ s/\s/-/;; $val; readingsBulkUpdate($hash,$val,ReadingsVal("JUDO_iSoft","data",""))<br />
</pre><br />
Noch ein paar ergänzende Attribute gesetzt:<br />
<pre><br />
attr JUDO_iSoft enableControlSet 1<br />
attr JUDO_iSoft getHeader1 Content-Type: application/json<br />
attr JUDO_iSoft getHeader2 Accept: */*<br />
attr JUDO_iSoft room 10_Räume->UG->Keller,<br />
attr JUDO_iSoft showError <br />
attr JUDO_iSoft timeout 5<br />
</pre><br />
<br />
Damit sind alle Voraussetzungen erledigt. Ab jetzt können wir die einzelnen Get-Befehle implementieren:<br />
<br />
<pre><br />
attr JUDO_iSoft get01Name SerialNumber<br />
attr JUDO_iSoft get01URL https://%JUDO_ipaddress%:8124/?group=spare%20part&command=serial%20number&msgnumber=5&token=%token%<br />
<br />
attr JUDO_iSoft get02Name WaterCurrent<br />
attr JUDO_iSoft get02URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20current&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get03Name SaltRange<br />
attr JUDO_iSoft get03URL https://%JUDO_ipaddress%:8124/?group=consumption&command=salt%20range&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get04Name SaltQuantity<br />
attr JUDO_iSoft get04URL https://%JUDO_ipaddress%:8124/?group=consumption&command=salt%20quantity&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get05Name ResidualHardness<br />
attr JUDO_iSoft get05URL https://%JUDO_ipaddress%:8124/?group=settings&command=residual%20hardness&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get06Name NaturalHardness<br />
attr JUDO_iSoft get06URL https://%JUDO_ipaddress%:8124/?group=info&command=natural%20hardness&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get07Name WaterStop<br />
attr JUDO_iSoft get07URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get08Name FlowRate<br />
attr JUDO_iSoft get08URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=flow%20rate&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get09Name SoftwareVersion<br />
attr JUDO_iSoft get09URL https://%JUDO_ipaddress%:8124/?group=version&command=software%20version&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get10Name HardwareVersion<br />
attr JUDO_iSoft get10URL https://%JUDO_ipaddress%:8124/?group=version&command=hardware%20version&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get11Name InstallationDate<br />
attr JUDO_iSoft get11URL https://%JUDO_ipaddress%:8124/?group=contract&command=init%20date&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get12Name ServiceDate<br />
attr JUDO_iSoft get12URL https://%JUDO_ipaddress%:8124/?group=contract&command=service%20date&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get13Name WaterTotal<br />
attr JUDO_iSoft get13URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20total&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get14Name WaterAverage<br />
attr JUDO_iSoft get14URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20average&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get15Name Vacation<br />
attr JUDO_iSoft get15URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=vacation&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get16Name Quantity<br />
attr JUDO_iSoft get16URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=quantity&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get17Name WaterDaily<br />
attr JUDO_iSoft get17URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20daily&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get18Name ValveState<br />
attr JUDO_iSoft get18URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=4&&token=%token%<br />
<br />
</pre><br />
<br />
Zum Setzen einiger Werte werden die folgenden Kommandos zum Schließen und Öffnen des Wasserstopps sowie das Setzen der Wunschwasserhärte implementiert<br />
<br />
<pre><br />
attr JUDO_iSoft set01Name CloseValve<br />
attr JUDO_iSoft set01URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%&parameter=close<br />
attr JUDO_iSoft set02Name OpenValve<br />
attr JUDO_iSoft set02URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%&parameter=open<br />
attr JUDO_iSoft set03Name residual-hardness<br />
attr JUDO_iSoft set03URL https://%JUDO_ipaddress%:8124/?group=settings&command=residual%20hardness&msgnumber=1&token=%token%&parameter=$val<br />
</pre><br />
<br />
<br />
<br />
'''Userreadings'''<br />
<br />
Um die Originalwerte aus der Anlage benutzerfreundlicher darzustellen, werden noch Userreadings angelegt.<br />
<br />
Die Salzrestdauer soll in Wochen angegeben (rückgemeldet werden Tage) werden, die verbleibende Salzmenge in Prozent. <br />
Die Salzmenge wird in Gramm angegeben, 50.000 entsprechen 100%.<br />
Wichtig: Bei den Userreadings muss darauf geachtet werden, dass diese mit Komma separiert und in einer Zeile geschrieben werden. <br />
<pre><br />
<br />
attr JUDO_iSoft saltRangeInWeeks { int( (ReadingsVal("JUDO_iSoft","salt-range",0)/7))} , saltQuantityInPercent { int( (ReadingsVal("JUDO_iSoft","salt-quantity",0)/50000)*100)}<br />
</pre><br />
<br />
== Readings auslesen ==<br />
Die Art der Anbindung liefert veränderte Readings nur, wenn man sie regelmäßig abfragt. Dazu habe ich dazu einen Timer aufgesetzt, der 1x am Tag die relevanten Werte abfragt. Das ist eigentlich nur wichtig, falls man ab und an doch noch über einen anderen Weg z.B. die Apps des Herstellers auf die JUDO zugreift und Werte verändert. Bei mir sieht das dann so aus:<br />
<pre><br />
Internals:<br />
COMMAND get JUDO_iSoft SaltQuantity;<br />
get JUDO_iSoft SaltRange;<br />
get JUDO_iSoft WaterDaily;<br />
get JUDO_iSoft WaterTotal;<br />
get JUDO_iSoft WaterAverage;<br />
get JUDO_iSoft FlowRate;<br />
get JUDO_iSoft ResidualHardness;<br />
<br />
DEF *23:55:00 <br />
get JUDO_iSoft SaltQuantity;<br />
get JUDO_iSoft SaltRange;<br />
get JUDO_iSoft WaterDaily;<br />
get JUDO_iSoft WaterTotal;<br />
get JUDO_iSoft WaterAverage;<br />
get JUDO_iSoft FlowRate;<br />
get JUDO_iSoft ResidualHardness;<br />
NAME at_Judo_DailyStats<br />
NR 1595<br />
PERIODIC yes<br />
RELATIVE no<br />
REP -1<br />
STATE Next: 23:55:00<br />
TIMESPEC 23:55:00<br />
TRIGGERTIME 1538862900<br />
TRIGGERTIME_FMT 2018-10-06 23:55:00<br />
TYPE at<br />
READINGS:<br />
2018-10-06 06:06:14 state Next: 23:55:00<br />
Attributes:<br />
room ,00_Masterswitches,10_Räume->UG->Keller<br />
<br />
</pre><br />
<br />
Um 1x pro Stunde gegen Ende der vollen Stunde den Wasserbrauch der aktuellen Stunde abzugreifen setze ich einen weiteren Timer auf. Bei mir jeweils um :58 der aktuellen Stunde. Das ist natürlich nicht ganz exakt. Wenn sich die Uhr der Judo und von FHEM auseinander driften bekommt man ggf. schon wieder den Wert der nächsten Stunde. <br />
<pre><br />
Internals:<br />
CFGFN <br />
COMMAND get JUDO_iSoft WaterCurrent<br />
DEF +*01:00:00 get JUDO_iSoft WaterCurrent<br />
NAME at_Judo_HourlyStats<br />
NR 34559<br />
NTM 06:58:00<br />
PERIODIC yes<br />
RELATIVE yes<br />
REP -1<br />
STATE Next: 06:58:00<br />
TIMESPEC 01:00:00<br />
TRIGGERTIME 1538801880<br />
TRIGGERTIME_FMT 2018-10-06 06:58:00<br />
TYPE at<br />
READINGS:<br />
2018-10-06 06:20:53 state Next: 06:58:00<br />
Attributes:<br />
alignTime 00:58<br />
room ,00_Masterswitches,10_Räume->UG->Keller<br />
</pre><br />
<br />
== Statistiken ==<br />
Die i-soft plus liefert verschiedene Statistiken zum Wasserverbrauch zurück. Die werden allerdings etwas eigentümlich zurückgemeldet.<br />
Unter water-current ist der jeweilige Verbrauch je Stunde zusammengefasst. Ich hole kurz vor der vollen Stunde diesen Wert ab, damit er danach im Logfile landet.<br />
Unter water-daily werden Tagesstatistiken geliefert. Kurioserweise in 3-Stunden-Paketen, d.h. 8 Werte. Die ersten Werte sind von 0h-3h, 3h-6h usw.<br />
Ich habe mich aktuell darauf beschränkt, den stündlichen Verbrauch zu erfassen und zu protokollieren. Es lassen sich aber auch bei Bedarf detaillierte Datumsbezogene Statistiken abrufen. Ich habe noch keinen sinnvollen Weg gefunden, das mit FHEM zu verbinden. <br />
<br />
<br />
== Darstellung in Tablet UI ==<br />
Ich nutze Tablet UI für die Visualisierung. <br />
Zur Darstellung der Restmengen Salz nutze ich das knob-widget, für das Setzen des Härtegrades den spinner.<br />
<br />
[[Datei:Screenshot judo 2.jpg|mini|Visualisierung der Judo im TabletUI|200px]]<br />
<br />
<pre><br />
<div class="hbox"><br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Zustand Salz</header><br />
<div class="sheet"><br />
<br />
<div class="row"><br />
<div class="cell-50 top-align center-align left-space"><br />
<div class="big">Restmenge</div><br />
<div data-type="knob" data-device="JUDO_iSoft"<br />
data-get="saltQuantityInPercent"<br />
data-unit="%"<br />
data-step="1"<br />
data-min="0"<br />
data-max="100"<br />
data-bgcolor="#FF0000"<br />
data-fgcolor="#00FF1A"<br />
class="small readonly"><br />
</div><br />
<br />
<br />
</div><br />
<div class="cell-50 top-align center-align left-space"><br />
<div class="big">Reichweite</div><br />
<br />
<div data-type="knob" data-device="JUDO_iSoft"<br />
data-get="saltRangeInWeeks"<br />
data-unit="w"<br />
data-step="1"<br />
data-min="0"<br />
data-max="52"<br />
data-bgcolor="#FF0000"<br />
data-fgcolor="#00FF1A"<br />
class="small readonly"><br />
</div><br />
<br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserstopp</header><br />
<div class="sheet"> <br />
<div class="row top-space"><br />
<br />
<div class="cell left-align top-align left-space"><br />
<div data-type="symbol" data-device="JUDO_iSoft" data-get="valve"<br />
data-icons='["fa-close","fa-close","oa-sani_water_tap","oa-sani_water_tap"]'<br />
data-get-on='["closed","closing","opening","opened"]'<br />
data-on-colors='["#ad3333","#ff6633","#3399ff","#33ad33"]' class="big compressed"></div><br />
</div><br />
<div class="cell-60 top-align center-align"><br />
<div class="big"><br />
<br />
<div data-type="label"<br />
data-get="valve"<br />
class="valueonly"<br />
data-substitution='["opened","geöffnet","opening","öffnet gerade","closed","geschlossen","closing","schließt gerade"]'<br />
data-device="JUDO_iSoft"<br />
data-color="lightgrey"><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div class="cell left-align top-align left-space"><br />
<div data-type="push" data-device="JUDO_iSoft" data-set-on="CloseValve 1" data-get-on="valve" data-background-icon="fa-stop-circle-o" data-icon="" class="small"></div><br />
<br />
</div><br />
<div class="cell right-align top-align right-space"><br />
<br />
<div data-type="push" data-device="JUDO_iSoft" data-set-on="OpenValve 1" data-get-on="valve" data-background-icon="mi-play_circle_filled" data-icon="" class="small"></div> <br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserhärtegrad</header><br />
<br />
<div class="sheet"><br />
<div class="row"> <br />
<br />
<div class="cell-20 center-align top-align left-space"><br />
<div data-type="symbol"<br />
data-device="JUDO_iSoft"<br />
data-icon="none"<br />
data-color='none'<br />
data-height="100"<br />
data-background-icon="fa-circle"<br />
data-background-colors='["red","blue"]'<br />
data-limits='["0","1"]'><br />
<div data-type="label"<br />
data-get="natural-hardness"<br />
data-unit="&deg;h"<br />
class="valueonly"<br />
data-device="JUDO_iSoft"<br />
data-color="lightgrey"><br />
</div><br />
</div><br />
</div><br />
<br />
<div class="cell-20 top-align center-align left-space"><br />
<div data-type="image" data-size="50%" data-url="images/judo.png"></div><br />
</div><br />
<br />
<div class="cell-60 top-align center-align left-space"><br />
<br />
<div data-type="spinner"<br />
data-device="JUDO_iSoft"<br />
data-get="residual-hardness"<br />
data-set="residual-hardness"<br />
data-min=5"<br />
data-max="12"<br />
data-step="1"<br />
data-unit="&deg;h"<br />
data-longdelay="800"<br />
data-width="200"<br />
data-height="60"<br />
data-icon-left-color="blue"<br />
data-icon-right-color="red"<br />
<br />
class="valueonly"><br />
<br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserverbrauch</header><br />
<section> <br />
<div id="JUDO_iSoft"<br />
data-type="highchart"<br />
data-device="JUDO_iSoft"<br />
data-logdevice="FileLog_JUDO_ISoft"<br />
data-columnspec="4:water-current"<br />
data-style="ftui l0fill"<br />
data-linenames="Verbrauch"<br />
data-linetypes="line"<br />
data-yaxis="0,1"<br />
data-height="300"<br />
data-xunit="Uhrzeit"<br />
data-yunit="l"<br />
data-tooltip="{series.name} <b>{point.y:,.1f}</b>"<br />
data-daysago="7"<br />
data-yticks="auto"<br />
data-legendalign="right"><br />
<br />
</section><br />
<br />
</div<br />
</div><br />
</div><br />
</pre><br />
<br />
== Problemlösung ==<br />
=== DHCP (keine IP-Adress-Zuweisung) ===<br />
<br />
Ich hatte bei der Inbetriebnahme erstaunliche Probleme, erfolgreich eine IP-Adresse zu bekommen.<br />
Das hat bei mir nur einmal initial funktioniert (und die Verbindung hab ich dann verloren), und dann "nie wieder".<br />
<br />
Diagnose z.B. per DHCP-Status-Seite im Router (verbundene Geräte).<br />
<br />
Es hat bei mir NICHT geholfen, das Netzwerk-Kabel abzuziehen (--> link state change == Wink mit dem Zaunpfahl, dass es erneuert werden sollte), und auch NICHT, das i-soft stromlos zu machen.<br />
<br />
Erst nach Entfernen aller Backup-9V-Blocks '''und''' stromlos machen (--> jetzt waren alle Status-LEDs des Connectivity Module erfolgreich aus!) hat er sich endlich wieder eine IP geholt.<br />
<br />
Weitere Diagnose-Möglichkeiten:<br />
* anderes Netzwerkkabel verwenden<br />
* Netzwerkkabel mit Kabel-Tester durchklingeln (z.B. COMMUNICATION CABLE TESTER S1007)<br />
<br />
Bitte hier weiter updaten, falls klarer wird, wie der Sachverhalt ist.<br />
<br />
=== Salzbehälter ===<br />
<br />
Der Salzbehälter kann an der Boden-Platten-Naht undicht sein (vermutlich seltener Fall; jedenfalls möglich bei Systemen ~ <= 08/2019, danach hoffentlich besser), somit Leckage, mit daraus folgenden schwerwiegenden Problemen (mglw. Versalzung der - evt. auch etwas weiteren: Luftströmungen! - Umgebung; hygroskopisch / kapillar - AUA! Salpeter-Reiniger scheint eine ziemlich gute Behandlung zu sein).<br />
Wenn man auf ganz sicher gehen will hinsichtlich Leckage-Vermeidung, dann ist es wohl empfehlenswert, Entkalker-Systeme in eine Wanne zu stellen, z.B. Baumarkt-Mörtelkübel (80l? 90l?).<br />
<br />
Der Behälterrand an der Oberkante hat zu scharfen Rand / ist nicht entgratet (Kunststoff-Spritzform?) --> Pulli-Ärmel-Killer --> aufpassen.<br />
<br />
== Ähnliche Systeme ==<br />
<br />
== Projekte der FHEM-Community ==<br />
<br />
== Links ==<br />
* {{Link2Forum|Topic=56455|Message=800960}}<br />
* [https://blog.muwave.de/2017/06/monitoring-and-controlling-a-judo-i-soft-plus-water-softening-device-via-lan/ ursprünglicher Beitrag bzgl. des verwendeten Protokolls]<br />
<br />
<br />
[[Kategorie:IP Components]]<br />
[[Kategorie:Other Components]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=JUDO_iSoft_Plus&diff=31107JUDO iSoft Plus2019-08-12T06:33:48Z<p>AndreasMohr: Neuer Abschnitt Problemlösung: DHCP / Salzbehälter</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=judo-soft-plus.jpg|200px<br />
|Bildbeschreibung=JUDO i-soft plus Wasserenthärtungsanlage<br />
|HWProtocol=IP<br />
|HWType=Wasserenthärter<br />
|HWCategory=IP<br />
|HWVoltage=230&nbsp;V<br />
|HWPoweredBy=AC<br />
|HWSize=39x67x45 cm (BxHxT)<br />
|HWComm=n/a<br />
|HWChannels=n/a<br />
|HWPowerConsumption=?<br />
|HWDeviceFHEM=[[HTTPMOD]]<br />
<!-- |ModOwner= --><br />
|HWManufacturer=Judo GmbH<br />
}}<br />
__TOC__<br />
<br />
Die JUDO i-soft plus Enthärtungsanlage [https://judo.eu/produkt/judo-i-soft-plus-vollautomatische-enthaertungsanlage/] ist eine Wasserenthärtungsanlage mit IP-Konnektivität. <br />
Sie verfügt über LAN und WLAN-Anschluss und ist auf die Steuerung via App des Herstellers ausgelegt.<br />
<br />
Für eine erfolgreiche Integration in FHEM muss die Anlage über das Menü beim Hersteller registriert werden.<br />
Die folgenden Informationen sind erforderlich:<br />
<br />
* Benutzername: Selbst gewählter Login-Name auf der i-soft plus (vgl. Gerätehandbuch)<br />
* Kennwort: Selbst gewähltes Kennwort<br />
* Seriennummer: Seriennummer des Geräts. Diese ist entweder über das Menü auslesbar oder alternativ auch über die APP des Herstellers.<br />
* IP-Adresse: Die IP-Adresse des Geräts im Heimnetz. <br />
<br />
== Einbindung in FHEM ==<br />
<br />
Das Gerät wird mittels des Moduls HTTPMOD eingebunden. Dazu gilt zunächst die folgende Konfiguration als Basis.<br />
Zunächst legen wir die Standardanfrage an das Modul fest. Die Portnummer 8124 ist vom Hersteller vorgegeben. Wir vergeben gleich ein paar Platzhalter, die später in den Aufrufen und den Antworten ersetzt werden, damit wir die Werte nur an einer zentralen Stelle konfigurieren müssen.<br />
<br />
<pre><br />
define JUDO_iSoft HTTPMOD https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=4&token=%token% 300<br />
</pre><br />
Mit dieser Definition wird als Standard-Anfrage die Statusabfrage nach dem Wasserstop gesendet. Diese wird zyklisch alle 300 Sekunden wiederholt. <br />
Wem das nicht reicht, der kann den Zyklus herunter setzen oder auch nach anderen Standard-Werten abfragen. Wer das kontinuierliche Pollen vermeiden will, setzt den Wert auf 0.<br />
<br />
Nach erfolgreicher Authentifizierung wird von der i-soft ein Token generiert und muss bei jedem Aufruf übergeben werden:<br />
<br />
<pre><br />
attr JUDO_iSoft replacement01Mode reading<br />
attr JUDO_iSoft replacement01Regex %token%<br />
attr JUDO_iSoft replacement01Value token<br />
</pre><br />
<br />
Anschließend legen wir die Ersetzungen für die anderen Platzhalter fest: <br />
<br />
<pre><br />
attr JUDO_iSoft replacement02Mode text<br />
attr JUDO_iSoft replacement02Regex %JUDO_ipaddress%<br />
attr JUDO_iSoft replacement02Value <hier eigene IP Adresse im lokalen Netz eintragen><br />
attr JUDO_iSoft replacement03Mode text<br />
attr JUDO_iSoft replacement03Regex %JUDO_password%<br />
attr JUDO_iSoft replacement03Value <hier Kennwort eintragen><br />
attr JUDO_iSoft replacement04Mode text<br />
attr JUDO_iSoft replacement04Regex %JUDO_username%<br />
attr JUDO_iSoft replacement04Value <hier Benutzername eintragen><br />
attr JUDO_iSoft replacement05Mode text<br />
attr JUDO_iSoft replacement05Regex %JUDO_serial%<br />
attr JUDO_iSoft replacement05Value <hier Seriennummer eintragen><br />
</pre><br />
<br />
Die Authentifizierung der Anlage erfolgt zwei-stufig. Zunächst muss ein Aufruf mit Benutzername und Kennwort erfolgen. Als Antwort erhält man einen JSON-String, der das Token beinhaltet. Mit diesem Token wird anschließend die Funktion connect aufgerufen und die Seriennummer des Geräts mit übergeben. <br />
HTTPMOD erkennt, wenn ein neues Login erforderlich ist, wenn die Judo die Rückmeldung "no token" oder "not logged in" liefert.<br />
<br />
Achtung: Als Parameter muss ebenfalls der Typ "i-soft plus" übergeben werden. Vermutlich ist dieser bei anderen Geräten des Herstellers anders. Ich habe ihn hier fix eingetragen, da ich keine Möglichkeit zum Testen anderer Geräte habe. <br />
<br />
<pre><br />
attr JUDO_iSoft showError 1<br />
attr JUDO_iSoft authRetries 2<br />
attr JUDO_iSoft reAuthRegex (no token)|(not logged in)<br />
attr JUDO_iSoft sid01ParseResponse 1<br />
attr JUDO_iSoft sid01URL https://%JUDO_ipaddress%:8124/?group=register&command=login&msgnumber=1&name=login&user=%JUDO_username%&password=%JUDO_password%&role=customer<br />
attr JUDO_iSoft sid02URL https://%JUDO_ipaddress%:8124/?group=register&command=connect&msgnumber=6&token=%token%&parameter=i-soft%20plus&serial%20number=%JUDO_serial%<br />
</pre><br />
<br />
Damit ist die Grundkonfiguration hergestellt und die Anlage kann sich connecten. <br />
In den einzelnen JSON-Rückantworten der Anlage werden die Werte zur jeweilige Anfrage immer als "data" zurück geliefert. Mit der Standard-Konfiguration<br />
<br />
<pre><br />
attr JUDO_iSoft extractAllJSON 1<br />
</pre><br />
<br />
werden daraus automatisch entsprechende Readings angelegt. Da wir aber dann immer das Reading "data" überschreiben würden, kommt eine weitere Ersetzung zum Einsatz. In der Antwort steht neben einer Kaskadierung (group) auch der zugehörige Befehl (command). Ich habe mich dafür entschieden, ein neues Reading mit dem jeweiligen Command-Namen anzulegen. Die zugehörigen Ersetzungen sind wie folgt.<br />
Erklärung zum Ausdruck reading03OExpr: Zunächst werden die Leerzeichen im Rückgabewert ($val) durch "-" ersetzt. Mit dem so veränderten String erzeugen wir ein neues Reading mit dem Wert aus dem Reading data. <br />
<br />
<pre><br />
attr JUDO_iSoft reading01JSON data<br />
attr JUDO_iSoft reading01Name token<br />
attr JUDO_iSoft reading01Regex "token":"([^"]+)"<br />
attr JUDO_iSoft reading02JSON group<br />
attr JUDO_iSoft reading03JSON command<br />
attr JUDO_iSoft reading03OExpr $val =~ s/\s/-/;; $val; readingsBulkUpdate($hash,$val,ReadingsVal("JUDO_iSoft","data",""))<br />
</pre><br />
Noch ein paar ergänzende Attribute gesetzt:<br />
<pre><br />
attr JUDO_iSoft enableControlSet 1<br />
attr JUDO_iSoft getHeader1 Content-Type: application/json<br />
attr JUDO_iSoft getHeader2 Accept: */*<br />
attr JUDO_iSoft room 10_Räume->UG->Keller,<br />
attr JUDO_iSoft showError <br />
attr JUDO_iSoft timeout 5<br />
</pre><br />
<br />
Damit sind alle Voraussetzungen erledigt. Ab jetzt können wir die einzelnen Get-Befehle implementieren:<br />
<br />
<pre><br />
attr JUDO_iSoft get01Name SerialNumber<br />
attr JUDO_iSoft get01URL https://%JUDO_ipaddress%:8124/?group=spare%20part&command=serial%20number&msgnumber=5&token=%token%<br />
<br />
attr JUDO_iSoft get02Name WaterCurrent<br />
attr JUDO_iSoft get02URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20current&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get03Name SaltRange<br />
attr JUDO_iSoft get03URL https://%JUDO_ipaddress%:8124/?group=consumption&command=salt%20range&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get04Name SaltQuantity<br />
attr JUDO_iSoft get04URL https://%JUDO_ipaddress%:8124/?group=consumption&command=salt%20quantity&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get05Name ResidualHardness<br />
attr JUDO_iSoft get05URL https://%JUDO_ipaddress%:8124/?group=settings&command=residual%20hardness&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get06Name NaturalHardness<br />
attr JUDO_iSoft get06URL https://%JUDO_ipaddress%:8124/?group=info&command=natural%20hardness&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get07Name WaterStop<br />
attr JUDO_iSoft get07URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get08Name FlowRate<br />
attr JUDO_iSoft get08URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=flow%20rate&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get09Name SoftwareVersion<br />
attr JUDO_iSoft get09URL https://%JUDO_ipaddress%:8124/?group=version&command=software%20version&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get10Name HardwareVersion<br />
attr JUDO_iSoft get10URL https://%JUDO_ipaddress%:8124/?group=version&command=hardware%20version&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get11Name InstallationDate<br />
attr JUDO_iSoft get11URL https://%JUDO_ipaddress%:8124/?group=contract&command=init%20date&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get12Name ServiceDate<br />
attr JUDO_iSoft get12URL https://%JUDO_ipaddress%:8124/?group=contract&command=service%20date&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get13Name WaterTotal<br />
attr JUDO_iSoft get13URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20total&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get14Name WaterAverage<br />
attr JUDO_iSoft get14URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20average&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get15Name Vacation<br />
attr JUDO_iSoft get15URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=vacation&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get16Name Quantity<br />
attr JUDO_iSoft get16URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=quantity&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get17Name WaterDaily<br />
attr JUDO_iSoft get17URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20daily&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get18Name ValveState<br />
attr JUDO_iSoft get18URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=4&&token=%token%<br />
<br />
</pre><br />
<br />
Zum Setzen einiger Werte werden die folgenden Kommandos zum Schließen und Öffnen des Wasserstopps sowie das Setzen der Wunschwasserhärte implementiert<br />
<br />
<pre><br />
attr JUDO_iSoft set01Name CloseValve<br />
attr JUDO_iSoft set01URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%&parameter=close<br />
attr JUDO_iSoft set02Name OpenValve<br />
attr JUDO_iSoft set02URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%&parameter=open<br />
attr JUDO_iSoft set03Name residual-hardness<br />
attr JUDO_iSoft set03URL https://%JUDO_ipaddress%:8124/?group=settings&command=residual%20hardness&msgnumber=1&token=%token%&parameter=$val<br />
</pre><br />
<br />
<br />
<br />
'''Userreadings'''<br />
<br />
Um die Originalwerte aus der Anlage benutzerfreundlicher darzustellen, werden noch Userreadings angelegt.<br />
<br />
Die Salzrestdauer soll in Wochen angegeben (rückgemeldet werden Tage) werden, die verbleibende Salzmenge in Prozent. <br />
Die Salzmenge wird in Gramm angegeben, 50.000 entsprechen 100%.<br />
Wichtig: Bei den Userreadings muss darauf geachtet werden, dass diese mit Komma separiert und in einer Zeile geschrieben werden. <br />
<pre><br />
<br />
attr JUDO_iSoft saltRangeInWeeks { int( (ReadingsVal("JUDO_iSoft","salt-range",0)/7))} , saltQuantityInPercent { int( (ReadingsVal("JUDO_iSoft","salt-quantity",0)/50000)*100)}<br />
</pre><br />
<br />
== Readings auslesen ==<br />
Die Art der Anbindung liefert veränderte Readings nur, wenn man sie regelmäßig abfragt. Dazu habe ich dazu einen Timer aufgesetzt, der 1x am Tag die relevanten Werte abfragt. Das ist eigentlich nur wichtig, falls man ab und an doch noch über einen anderen Weg z.B. die Apps des Herstellers auf die JUDO zugreift und Werte verändert. Bei mir sieht das dann so aus:<br />
<pre><br />
Internals:<br />
COMMAND get JUDO_iSoft SaltQuantity;<br />
get JUDO_iSoft SaltRange;<br />
get JUDO_iSoft WaterDaily;<br />
get JUDO_iSoft WaterTotal;<br />
get JUDO_iSoft WaterAverage;<br />
get JUDO_iSoft FlowRate;<br />
get JUDO_iSoft ResidualHardness;<br />
<br />
DEF *23:55:00 <br />
get JUDO_iSoft SaltQuantity;<br />
get JUDO_iSoft SaltRange;<br />
get JUDO_iSoft WaterDaily;<br />
get JUDO_iSoft WaterTotal;<br />
get JUDO_iSoft WaterAverage;<br />
get JUDO_iSoft FlowRate;<br />
get JUDO_iSoft ResidualHardness;<br />
NAME at_Judo_DailyStats<br />
NR 1595<br />
PERIODIC yes<br />
RELATIVE no<br />
REP -1<br />
STATE Next: 23:55:00<br />
TIMESPEC 23:55:00<br />
TRIGGERTIME 1538862900<br />
TRIGGERTIME_FMT 2018-10-06 23:55:00<br />
TYPE at<br />
READINGS:<br />
2018-10-06 06:06:14 state Next: 23:55:00<br />
Attributes:<br />
room ,00_Masterswitches,10_Räume->UG->Keller<br />
<br />
</pre><br />
<br />
Um 1x pro Stunde gegen Ende der vollen Stunde den Wasserbrauch der aktuellen Stunde abzugreifen setze ich einen weiteren Timer auf. Bei mir jeweils um :58 der aktuellen Stunde. Das ist natürlich nicht ganz exakt. Wenn sich die Uhr der Judo und von FHEM auseinander driften bekommt man ggf. schon wieder den Wert der nächsten Stunde. <br />
<pre><br />
Internals:<br />
CFGFN <br />
COMMAND get JUDO_iSoft WaterCurrent<br />
DEF +*01:00:00 get JUDO_iSoft WaterCurrent<br />
NAME at_Judo_HourlyStats<br />
NR 34559<br />
NTM 06:58:00<br />
PERIODIC yes<br />
RELATIVE yes<br />
REP -1<br />
STATE Next: 06:58:00<br />
TIMESPEC 01:00:00<br />
TRIGGERTIME 1538801880<br />
TRIGGERTIME_FMT 2018-10-06 06:58:00<br />
TYPE at<br />
READINGS:<br />
2018-10-06 06:20:53 state Next: 06:58:00<br />
Attributes:<br />
alignTime 00:58<br />
room ,00_Masterswitches,10_Räume->UG->Keller<br />
</pre><br />
<br />
== Statistiken ==<br />
Die i-soft plus liefert verschiedene Statistiken zum Wasserverbrauch zurück. Die werden allerdings etwas eigentümlich zurückgemeldet.<br />
Unter water-current ist der jeweilige Verbrauch je Stunde zusammengefasst. Ich hole kurz vor der vollen Stunde diesen Wert ab, damit er danach im Logfile landet.<br />
Unter water-daily werden Tagesstatistiken geliefert. Kurioserweise in 3-Stunden-Paketen, d.h. 8 Werte. Die ersten Werte sind von 0h-3h, 3h-6h usw.<br />
Ich habe mich aktuell darauf beschränkt, den stündlichen Verbrauch zu erfassen und zu protokollieren. Es lassen sich aber auch bei Bedarf detaillierte Datumsbezogene Statistiken abrufen. Ich habe noch keinen sinnvollen Weg gefunden, das mit FHEM zu verbinden. <br />
<br />
<br />
== Darstellung in Tablet UI ==<br />
Ich nutze Tablet UI für die Visualisierung. <br />
Zur Darstellung der Restmengen Salz nutze ich das knob-widget, für das Setzen des Härtegrades den spinner.<br />
<br />
[[Datei:Screenshot judo 2.jpg|mini|Visualisierung der Judo im TabletUI|200px]]<br />
<br />
<pre><br />
<div class="hbox"><br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Zustand Salz</header><br />
<div class="sheet"><br />
<br />
<div class="row"><br />
<div class="cell-50 top-align center-align left-space"><br />
<div class="big">Restmenge</div><br />
<div data-type="knob" data-device="JUDO_iSoft"<br />
data-get="saltQuantityInPercent"<br />
data-unit="%"<br />
data-step="1"<br />
data-min="0"<br />
data-max="100"<br />
data-bgcolor="#FF0000"<br />
data-fgcolor="#00FF1A"<br />
class="small readonly"><br />
</div><br />
<br />
<br />
</div><br />
<div class="cell-50 top-align center-align left-space"><br />
<div class="big">Reichweite</div><br />
<br />
<div data-type="knob" data-device="JUDO_iSoft"<br />
data-get="saltRangeInWeeks"<br />
data-unit="w"<br />
data-step="1"<br />
data-min="0"<br />
data-max="52"<br />
data-bgcolor="#FF0000"<br />
data-fgcolor="#00FF1A"<br />
class="small readonly"><br />
</div><br />
<br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserstopp</header><br />
<div class="sheet"> <br />
<div class="row top-space"><br />
<br />
<div class="cell left-align top-align left-space"><br />
<div data-type="symbol" data-device="JUDO_iSoft" data-get="valve"<br />
data-icons='["fa-close","fa-close","oa-sani_water_tap","oa-sani_water_tap"]'<br />
data-get-on='["closed","closing","opening","opened"]'<br />
data-on-colors='["#ad3333","#ff6633","#3399ff","#33ad33"]' class="big compressed"></div><br />
</div><br />
<div class="cell-60 top-align center-align"><br />
<div class="big"><br />
<br />
<div data-type="label"<br />
data-get="valve"<br />
class="valueonly"<br />
data-substitution='["opened","geöffnet","opening","öffnet gerade","closed","geschlossen","closing","schließt gerade"]'<br />
data-device="JUDO_iSoft"<br />
data-color="lightgrey"><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div class="cell left-align top-align left-space"><br />
<div data-type="push" data-device="JUDO_iSoft" data-set-on="CloseValve 1" data-get-on="valve" data-background-icon="fa-stop-circle-o" data-icon="" class="small"></div><br />
<br />
</div><br />
<div class="cell right-align top-align right-space"><br />
<br />
<div data-type="push" data-device="JUDO_iSoft" data-set-on="OpenValve 1" data-get-on="valve" data-background-icon="mi-play_circle_filled" data-icon="" class="small"></div> <br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserhärtegrad</header><br />
<br />
<div class="sheet"><br />
<div class="row"> <br />
<br />
<div class="cell-20 center-align top-align left-space"><br />
<div data-type="symbol"<br />
data-device="JUDO_iSoft"<br />
data-icon="none"<br />
data-color='none'<br />
data-height="100"<br />
data-background-icon="fa-circle"<br />
data-background-colors='["red","blue"]'<br />
data-limits='["0","1"]'><br />
<div data-type="label"<br />
data-get="natural-hardness"<br />
data-unit="&deg;h"<br />
class="valueonly"<br />
data-device="JUDO_iSoft"<br />
data-color="lightgrey"><br />
</div><br />
</div><br />
</div><br />
<br />
<div class="cell-20 top-align center-align left-space"><br />
<div data-type="image" data-size="50%" data-url="images/judo.png"></div><br />
</div><br />
<br />
<div class="cell-60 top-align center-align left-space"><br />
<br />
<div data-type="spinner"<br />
data-device="JUDO_iSoft"<br />
data-get="residual-hardness"<br />
data-set="residual-hardness"<br />
data-min=5"<br />
data-max="12"<br />
data-step="1"<br />
data-unit="&deg;h"<br />
data-longdelay="800"<br />
data-width="200"<br />
data-height="60"<br />
data-icon-left-color="blue"<br />
data-icon-right-color="red"<br />
<br />
class="valueonly"><br />
<br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserverbrauch</header><br />
<section> <br />
<div id="JUDO_iSoft"<br />
data-type="highchart"<br />
data-device="JUDO_iSoft"<br />
data-logdevice="FileLog_JUDO_ISoft"<br />
data-columnspec="4:water-current"<br />
data-style="ftui l0fill"<br />
data-linenames="Verbrauch"<br />
data-linetypes="line"<br />
data-yaxis="0,1"<br />
data-height="300"<br />
data-xunit="Uhrzeit"<br />
data-yunit="l"<br />
data-tooltip="{series.name} <b>{point.y:,.1f}</b>"<br />
data-daysago="7"<br />
data-yticks="auto"<br />
data-legendalign="right"><br />
<br />
</section><br />
<br />
</div<br />
</div><br />
</div><br />
</pre><br />
<br />
== Problemlösung ==<br />
=== DHCP (keine IP-Adress-Zuweisung) ===<br />
<br />
Ich hatte bei der Inbetriebnahme erstaunliche Probleme, erfolgreich eine IP-Adresse zu bekommen.<br />
Das hat bei mir nur einmal initial funktioniert (und die Verbindung hab ich dann verloren), und dann "nie wieder".<br />
<br />
Diagnose z.B. per DHCP-Status-Seite im Router (verbundene Geräte).<br />
<br />
Es hat bei mir NICHT geholfen, das Netzwerk-Kabel abzuziehen (--> link state change == Wink mit dem Zaunpfahl, dass es erneuert werden sollte), und auch NICHT, das i-soft stromlos zu machen.<br />
<br />
Erst nach Entfernen aller Backup-9V-Blocks '''und''' stromlos machen (--> jetzt waren alle Status-LEDs des Connectivity Module erfolgreich aus!) hat er sich endlich wieder eine IP geholt.<br />
<br />
Weitere Diagnose-Möglichkeiten:<br />
* anderes Netzwerkkabel verwenden<br />
* Netzwerkkabel mit Kabel-Tester durchklingeln (z.B. COMMUNICATION CABLE TESTER S1007)<br />
<br />
Bitte hier weiter updaten, falls klarer wird, wie der Sachverhalt ist.<br />
<br />
=== Salzbehälter ===<br />
<br />
Der Salzbehälter kann an der Boden-Platten-Naht undicht sein (vermutlich seltener Fall; jedenfalls möglich bei Systemen ~ <= 08/2019, danach hoffentlich besser), somit Leckage, mit daraus folgenden schwerwiegenden Problemen (mglw. Versalzung der - evt. auch etwas weiteren: Luftströmungen! - Umgebung; hygroskopisch / kapillar - AUA! Salpeter-Reiniger scheint eine ziemlich gute Behandlung zu sein).<br />
Wenn man auf ganz sicher gehen will hinsichtlich Leckage-Vermeidung, dann ist es wohl empfehlenswert, Entkalker-Systeme in eine Wanne zu stellen, z.B. Baumarkt-Mörtelkübel (80l? 90l?).<br />
<br />
Der Behälterrand an der Oberkante hat zu scharfen Rand / ist nicht entgratet (Kunststoff-Spritzform?) --> Pulli-Ärmel-Killer --> aufpassen.<br />
<br />
== Ähnliche Systeme ==<br />
<br />
== Projekte der FHEM-Community ==<br />
<br />
== Links ==<br />
* {{Link2Forum|Topic=56455|Message=800960}}<br />
* [https://blog.muwave.de/2017/06/monitoring-and-controlling-a-judo-i-soft-plus-water-softening-device-via-lan/ ursprünglicher Beitrag bzgl. des verwendeten Protokolls]<br />
<br />
<br />
[[Kategorie:IP Components]]<br />
[[Kategorie:Other Components]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=TelegramBot&diff=30874TelegramBot2019-06-30T17:25:02Z<p>AndreasMohr: /* Benachrichtigungen über Ereignisse */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Senden und Empfangen von Nachrichten (Text und Fotos) mit dem freien Messagingdienst Telegram<br />
|ModType=d<br />
|ModForumArea=Unterstützende Dienste<br />
|ModFTopic=38328<br />
|ModTechName=[https://github.com/viegener/Telegram-fhem/blob/master/50_TelegramBot.pm 50_TelegramBot.pm]<br />
|ModOwner=[[Benutzer:Viegener|Viegener]] ({{Link2FU|12772|Forum}} / [[Benutzer Diskussion:Viegener|Wiki]])}}<br />
<br />
Das [[TelegramBot]]-Modul ermöglicht das Senden und Empfangen von Nachrichten über den Telegram-instant messaging Dienst (https://telegram.org/). <br />
Es entsteht eine Möglichkeit Benachrichtungen aus FHEM zu versenden, zum Beispiel Alarmmeldungen.<br />
Ausserdem können auch Kommandos über Telegram an FHEM gesendet werden um Steuerungsbefehle in FHEM auszulösen.<br />
<br />
Das TelegramBot-Modul benötigt keine Zusatzsoftware auf dem FHEM-Server (anders als die Variante [[Telegram]]), sondern verwendet das [https://core.telegram.org/bots/api TelegramBot-API] über https-Aufrufe. Es muss jedoch das [http://www.fhemwiki.de/wiki/Raspberry_Pi#N.C3.BCtzliche_Zusatzpakete perl JSON modul] installiert sein. <br />
<br />
== Über Telegram Instant Messaging ==<br />
Telegram-IDs und Versand/Empfang von Nachrichten sind kostenfrei. <br />
Clients sind für gängige Smartphonesysteme erhältlich (iOS iPhone und Tablet, Android, Windows Phone) und <br />
können auch aus dem WebBrowser verwendet werden. <br />
Es gibt auch einen Kommandozeilen-Client für Linux, der die Grundlage dieses Moduls darstellt. <br />
Mehrfachanmeldungen, auch parallel mit verschiedenen Geräten (z.B. Tablet und Smartphone), sind möglich.<br />
Gruppenchats und Chats mit End-2-End-Verschlüsselung werden ebenfalls unterstützt.<br />
<br />
Für die Unterstützung von ''WhatsApp'' siehe Modul [[yowsup]].<br />
<br />
== Features ==<br />
Unterstützt werden:<br />
<br />
* Versand von Textnachrichten <br />
* Versand und Empfang von Bildern/Audio/etc <br />
* Empfang von Textnachrichten von beliebigen Kontakten<br />
* Kommandos in FHEM über Telegram-Nachrichten von aussen auslösen<br />
* Ergebnisse der Kommandos zusenden lassen<br />
<br />
Eine detaillierte Beschreibung des Moduls ist im FHEM Forum und in der (englischen) Dokumentation zum Modul in der {{Link2CmdRef|Anker=TelegramBot}} und in diesem {{Link2Forum|Topic=38328|LinkText=Diskussionsthread}} zu finden. Seit Oktober 2015 wird das Modul offiziell über FHEM-Update verteilt.<br />
<br />
Die jeweils aktuellste Entwicklungs-Version des Moduls ist in Github [https://github.com/viegener/Telegram-fhem/blob/master/50_TelegramBot.pm 50_TelegramBot.pm] verfügbar.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
{{Randnotiz|RNTyp=Info|RNText=Achtung: Dieses Authtoken ist die einzige Authentifizierung für den Bot und sollte deshalb nicht aus der Hand gegeben werden. Die verwendeten Urls sind deshalb auch in den Log-Files nicht enthalten, da diese das Authtoken in Klartext enthalten. Auch im Forum sollte dieses Token nicht aufgenommen werden.<br />
}}<br />
<br />
Für die Anlage eines TelegramBot Devices in FHEM ist ein Authtoken erforderlich. Dieses Token wird über Anlegen eines neuen Bots im [https://core.telegram.org/bots#6-botfather BotFather] erzeugt. Dafür muss der BotFather mit einem Telegram-Client kontaktiert werden. Dort mit dem Telegram-Befehl <code>/newbot</code> einen neuen Bot anlegen und mit einem Namen versehen. Hinweis: Die Namen für Bots müssen auf "Bot" enden.<br><br />
<br />
Das Anlegen eines TelegramBot devices erfolgt durch die Angabe dieses Tokens:<br />
<br />
<code>define &lt;name&gt; TelegramBot &lt;token&gt; </code><br />
<br />
Beispiel: <code>define teleBot TelegramBot 110201543:AAHdqTcvCH1vGWJxfSeofSAs0K5PALDsaw</code><br />
<br />
'''Das Empfangen von Nachrichten (polling) erfordert die Einstellung des Attributes''' <br />
<code>pollingTimeout</code> '''auf einen Wert der grösser als Null ist. Beim Wert 0 oder ohne Setzen des Attributes findet kein Polling und damit auch kein Empfang statt.''' <br />
<br />
Beispiel: <code>attr teleBot pollingTimeout 120</code><br />
<br />
'''Der TelegramBot kann erst dann Nachrichten an einen telegram user schicken, wenn dieser zuerst an den telegram bot eine Nachricht gesendet hat.'''<br />
Dafür muss man in seinem Telegram-Client den Kontakt @botName suchen und dann eine Nachricht daran versenden.<br />
<br />
'''Der TelegramBot kann keine Nachrichten an andere Bots senden. Ein anderer Bot erhält die Nachrichten auch nicht wenn er in einer Gruppe enthalten ist.''' Dies ist eine Beschränkung in der Bot-Funktion bei Telegram. Das Versenden an einen anderen Bot (wenn man den Kontakt manuell hinzugefügt hat) führt zur Fehlermeldung<br />
<code>sentMsgResult - Callback returned error :Bad Request: chat not found:</code><br />
<br />
{{Randnotiz|RNTyp=Info|RNText=TelegramBot setzt eine aktuelle Version von FHEM voraus, insbesondere Versionen weit vor der Umstellung auf 5.7 (also vor Herbst 2015) können mit einem TelegramBot-Modul nicht funktionieren, da insbesondere das HTTPSRV-Modul dann veraltet ist. Am besten auch den TelegramBot über den offiziellen Update mit dem Rest von FHEM installieren/aktualisieren.<br />
}}<br />
<br />
== Registrierung eines neuen Bot ==<br />
Zur Registrierung wird ein funktionierender Telegram-Client (egal ob Web, App oder Programm)benötigt. Hier wird ein Chat zum BotFather gestartet und der Befehl /newbot gesendet. Nun fragt der BotFather die benötigten Angaben ab und liefert am Ende des Dialogs die Informationen für den neuen Bot.<br />
Hier ein Beispiel, wie so ein Chat aussehen könnte:<br />
<pre>Client: <br />
/newbot<br />
----------------<br />
BotFather:<br />
Alright, a new bot. How are we going to call it? Please choose a name for your bot. <br />
----------------<br />
Client: <br />
Mein Name <br />
----------------<br />
BotFather: <br />
Good. Now let's choose a username for your bot. It must end in `bot`. Like this, for example: TetrisBot or tetris_bot.<br />
----------------<br />
Client: <br />
fhem_bot<br />
----------------<br />
BotFather: <br />
Sorry, this username is already taken. Think of something different.<br />
----------------<br />
Client: <br />
fhem1234_bot<br />
----------------<br />
BotFather: <br />
Done! Congratulations on your new bot.<br />
You will find it at telegram.me/fhem1234_bot.<br />
You can now add a description, about section and profile picture for your bot, see /help for a list of commands.<br />
----------------<br />
Use this token to access the HTTP API:<br />
1234567890:AbCdefgHIJklmnOPQRst-uvwxyz <br />
<br />
For a description of the Bot API, see this page: https://core.telegram.org/bots/api <br />
</pre><br />
Um einen Chat an einen "Contact" versenden zu können, muss zuerst in Contacts (bei Readings) ein Kontakt auftauchen. Wenn man sich zum allerersten Mal bei Telegram angemeldet hat, gibt es noch keinen Chat mit irgendjemanden. Man muss sich zuerstmal selbst eine Nachricht im Smartphone zusenden, dann taucht unter Readings der Eintrag Contacts auf. Erst dann kann man eine Nachricht mit @msgPeerId (das ist Ziffernfolge des Contacts ) oder mit @msgPeer (das ist der Name nach dem Doppelpunkt) vom TelegramBot auf sein Smartphone senden.<br />
<br />
== Tipps ==<br />
<br />
=== Privacyeinstellungen ===<br />
<br />
Damit der TelegramBot auch Meldungen in Gruppen sieht, müssen über den BotFather die Privacy-Einstellungen geändert werden.<br>Beispielchat:<pre>Client:<br />
/setprivacy<br />
----------------<br />
BotFather:<br />
Choose a bot to change group messages settings.<br />
----------------<br />
Client:<br />
@fhem1234_bot<br />
----------------<br />
BotFather:<br />
'Enable' - your bot will only receive messages that either start with the '/' symbol or mention the bot by username.<br />
'Disable' - your bot will receive all messages that people send to groups.<br />
Current status is: ENABLED<br />
----------------<br />
Client:<br />
Disable<br />
----------------<br />
BotFather:<br />
Success! The new status is: DISABLED. /help</pre><br />
<br />
=== Kontakte ===<br />
<br />
Der Bot merkt sich die bereits bekannten Kontakte im Reading <code>Contacts</code>. Dabei werden die einzelnen Kontakte jeweils als 3-teilige Einträge gespeichert - bestehend aus UserID, Vor- und Nachname des Benutzers (mit _ verbunden) und dem Username (mit vorangestelltem @). <br />
<br />
Beispiel: <code>123456:Ralf_Mustermann:@ralf</code><br />
<br />
Verschiedene Einträge werden durch Leerzeichen getrennt.<br />
<br />
Man kann die Kontakte auch manuell überschreiben (z.B. wenn das Reading fehlerhaft oder verloren sein sollte). Dazu gibt es den Set-Befehl <code>replaceContacts</code>. Dieser nimmt die Kontakte ebenfalls in der gleichen Form wie oben beschrieben entgegen.<br />
<br />
Die Kontaktliste wird ansonsten nur durch den Empfang von Nachrichten erweitert, da es im TelegramBot-API keine Möglichkeit gibt Kontaktdaten von Telegram abzufragen (siehe auch pollingTimeout)<br />
<br />
=== Reset ===<br />
<br />
Es ist möglich den Bot im laufenden Betrieb zurückzusetzen (Set-Befehl <code>reset</code>). Dabei werden noch nicht abgeschlossene Übetragungen entfernt und die internen Zustände des Devices zurückgesetzt. <br />
<br />
=== Gruppen ===<br />
<br />
Um eine Nachricht von FHEM an eine Gruppe zu senden, muss der BOT in die Gruppe aufgenommen werden. Nach dem Senden einer Nachricht an die Gruppe kann im Modul die Gruppen-ID ermittelt werden und zum Senden von Nachrichten verwendet werden. Die Gruppen-ID ist eine negative Zahl. Wenn die Privacy-Einstellungen nicht auf 'Disabled' gesetzt wurden, muss die Nachricht mit einem Slash (/) beginnen.<br />
<br />
==== Supergroups / Supergruppen ====<br />
<br />
Auch die neuen Supergruppen werden mit dem Bot unterstützt, es ist allerdings zu beachten, dass bei der Umwandlung einer Gruppe in eine Supergruppe eine neue ID in den Kontakten von Telegram vergeben wird. Wenn man also wie empfohlen IDs zur Identifikation von Benutzern einsetzt, muss entsprechend angepasst werden.<br />
<br />
== Beispielszenarien ==<br />
<br />
=== Benachrichtigungen über Ereignisse ===<br />
<br />
Das einfachste Szenario für die Integration von Messaging-Diensten mit FHEM ist zur Benachrichtigung über Ereignisse. Diese Funktion kann zum Beispiel verwendet werden, um über einen erfolgten Neustart von FHEM zu informieren:<br />
<br />
<code>define notify_fhem_reload notify global:INITIALIZED set telebotdevice message fhem newly started - just now !</code><br />
<br />
In diesem Beispiel wird der Nachrichtentext "fhem newly started - just now !" an den als default eingestellten Kontakt (Attribut: defaultPeer) gesendet, sobald FHEM neu gestartet wurde. Natürlich kann man auch beliebige andere Benachrichtigungen einführen.<br />
<br />
Nebenbemerkung: hier ist eine erweiterte Strukturierung evt. empfehlenswert: statt jede Notify-Syntax o.ä. direkt auf TelegramBot-Spezifika gehen zu lassen, kann man sich eine Helper-Funktion (zur Vermittlung all solcher "Alarmtexte") bauen ([[99_myUtils_anlegen]]), die entsprechende Alarm-Meldungen dann nur intern auf (u.a.) einen Messaging-Service wie (momentan!) Telegram schickt.<br />
<br />
=== Versand von Bildern ===<br />
<br />
Es ist auch möglich Bilder auf dem FHEM-Server, die zum Beispiel von einer Kamera oder einem Wettermodul stammen über Telegram zu versenden. So wäre es z.B. möglich jeweils morgens die aktuelle Wetterkarte zu erhalten.<br />
<br />
ACHTUNG: TelegramBot verwendet das HTTPUtils-Modul zur Kommunikation mit dem TelegramBot-API. Erst mit der Version, die seit 22.10.2015 <br />
([r9576] HttpUtils.pm: Async write for POST Requests {{Link2Forum|Topic=41583|LinkText=FHEM-Forum}}) verteilt wird, erlaubt auch den Transfer grösserer Bilder. Die Grenze liegt ansonsten bei ca. 14kb auf Raspberries (Plattformspezifische Grenze).<br />
<br />
<br />
<code>define notify_fhem_reload notify wetter:report set telebotdevice sendImage /opt/fhem/wetter.jpg</code><br />
<br />
Bei Erreichen des entsprechenden Status am Wetter-Modul wird ein Image über Telegram versendet. Hier sind lokale Pfade (relativ zu fhem) oder absolute Pfade wie oben möglich.<br />
<br />
=== Versand von SVG-Plots ===<br />
<br />
SVG-Plots können mit dem Befehl <br />
<code>cmdSend [ @<peer1> ... @<peerN> ] <fhem command></code><br />
verschickt werden.<br />
<br />
Das angegebene FHEM-Kommando wird ausgeführt und das Ergebnis an die angegebenen Peers bzw. den Standard-Peer verschickt.<br />
<br />
Mit dem folgenden Befehl wird der SVG-Plot SVG_FileLog_Aussen an den Standard-Peer geschickt: <br />
<code>set mein_telegramBot cmdSend { plotAsPng('SVG_FileLog_Aussen') }</code><br />
<br />
Nach <code>define cmd_sendTelegramSVG cmdalias TGSVG .* AS set mein_telegramBot cmdSend { plotAsPng("$EVENT") }</code><br />
kann man mit einem kurzen <br />
<code>TGSVG SVG_Garten</code><br />
ein beliebiges SVG über die Kommandozeile per Telegram versenden.<br />
<br />
Um das SVG nun noch mit einem Text zu versehen, muss eine Textnachricht dazu gesendet werden, was sich am einfachsten durch das Ausführen eines FHEM-Befehls auf Perl-Ebene realisieren lässt:<br />
<br />
<code>{fhem "set mein_telegramBot message Bildbeschreibung;; set mein_telegramBot cmdSend { plotAsPng('mein_SVG') }" }</code><br />
<br />
'''Hinweis:''' früher wurde zum Verschicken von Plots auch die interne Funktion TelegramBot_ExecuteCommand verwendet; mit dem Update Ende Februar 2017 hat diese Funktion einen zusätzlichen Parameter erhalten und lautet nun <br />
<code>TelegramBot_ExecuteCommand($defs{"mein_telegramBot"}, meine_ZielID, undef, '{plotAsPng("mein_SVG")}');</code><br />
<br />
<br />
==== Voraussetzungen für den Versand von SVG-Plots ====<br />
Es muss das Modul libimage-librsvg-perl installiert sein:<br />
<br />
<code>sudo apt-get install libimage-librsvg-perl</code><br />
<br />
Evtl. sind weitere Module erforderlich:<br />
<br />
<code>sudo apt-get install libgd-graph-perl<br />
<br />
sudo apt-get install libgd-text-perl</code><br />
<br />
=== Empfang von Bildern oder ähnlichem ===<br />
<br />
Beim Empfang von Bildern wird zuerst nur eine ID vom Telegram-Server empfangen, diese befindet sich im Reading <code>msgFileId</code> angelegt (<code>123456:xxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxx</code>) und im Reading <code>msgText</code> steht dann so etwas wie<br />
<code>received photo # Size: 107701</code><br />
<br />
Über das Get-Kommando <code>urlForFile</code> mit der ID aus dem msgFileId Reading lässt sich dann daraus ein URL ableiten, der dann zur eigentlichen Datei führt: <br />
<br />
<code>https://api.telegram.org/file/bot123456:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/photo/file_25.jpg</code><br />
<br />
<br />
=== Versand von Emojis (Smileys) ===<br />
<br />
Es ist auch möglich Emojis mit den (Text-)Nachrichten zu versenden. Die entsprechenden (Unicode-)Zeichen werden einfach direkt mit in den Text der Nachricht aufgenommen. Um das zu vereinfachen kann man das einfach per Copy und Paste von dieser Seite <br />
<br />
http://apps.timwhitlock.info/emoji/tables/unicode (Spalte "Native") <br />
<br />
übernehmen und mit der Nachricht verschicken. <br />
<br />
Die Emojis können auch empfangen werden und werden so auch in FHEM / FHEMWeb angezeigt. Plattformspezifische (z.B. von iOS oder Android) Emojis werden dabei nicht unterstützt (gerade mit iOS sind viele neue farbige Emojis hinzugekommen, die wohl leider nur auf Apple-devices funktionieren).<br />
<br />
=== Kommandos auslösen ===<br />
<br />
Ein wichtiges Szenario ist die Möglichkeit Kommandos in FHEM ausführen zu können, ohne einen Zugang durch die Firewall einrichten zu müssen. Dazu ist die Definition eines Schlüsselwortes (Attribut: "cmdKeyword")erforderlich, mit dem man die Nachrichten beginnen muss, damit der TelegramBot die Kommandos erkennt.<br />
<br />
<code>attr telebotdevice cmdKeyword doit</code><br />
<br />
Somit kann man dann durch Nachrichten die mit "doit" beginnen Kommandos an FHEM senden, die ähnlich wie im Kommandoeingabefeld von FHEMweb dann von FHEM ausgeführt werden. Das Ergebnis der Ausführung wird zurück an den Sender (und an den definierten defaultPeer) geschickt.<br />
<br />
Somit können nicht nur Aktionen angestossen werden, sondern auch Infos abgefragt werden.<br />
<br />
Beispiele<br />
<br />
<code>doit set schalter on</code><br />
<br />
<code>doit list telegrambot</code><br />
<br />
{{Randnotiz|RNTyp=Warn|RNText=Achtung: Bei den Kommandos sollten man unbedingt das Attribut "cmdRestrictedPeer" setzen, damit nicht jeder Kommandos auf dem FHEM-Server ausführen kann. Dazu sollten die BenutzerIDs der erlaubten Benutzer (durch Leerzeichen getrennt angeben). Da Benutzernamen selber vergeben werden und nicht unbedingt eindeutig sind, sollten hier auch NUR BenutzerIDs verwendet werden.<br />
}}<br />
<br />
==== Favoriten für Kommandos anlegen ====<br />
Grundidee bei den Favoriten ist, dass man lange Befehle, die man häufig braucht auf "Kurzwahl" legt.<br />
<br />
Beispiel-Kommandos wie z.B. <code>set TYPE=ROLLLADEN pos 100</code> und <code>set TYPE=ROLLLADEN pos 0</code>, die man immer wieder braucht. Um nicht jedes mal dieses Kommando eintippen zu müssen auf dem Smartphone, kann man auch dafür Favoriten anlegen.<br />
<br />
Dazu gibt man erst mal die beiden Kommandos getrennt durch Semikolon im Attribut favorites an:<br />
<br />
<code>attr telegrambotdevice favorites set TYPE=ROLLLADEN pos 100;set TYPE=ROLLLADEN pos 0</code><br />
<br />
Um die Favorites jetzt ausführen zu können braucht man noch ein Schlüsselwort dafür.<br />
Nehmen wir mal an man möchte die Favoriten mit <code>/short</code> ausführen können. Dazu muss dann das Attribut "cmdFavorites" setzen<br />
<br />
<code>attr telegrambotdevice cmdFavorites /short</code><br />
<br />
Wenn man nun im Telegram Client <br />
<code>/short 1</code> an den Bot schickt führt der Bot den ersten Favoriten aus und das Ergebnis der Ausführung wird zurückgeschickt.<br />
<br />
Ausserdem kann man im Telegram Client <br />
<code>/short</code> an den Bot schicken, dann antwortet der Bot mit<br />
<br />
<pre><br />
Favorites<br />
<br />
/short1 = set TYPE=ROLLLADEN pos 100<br />
<br />
/short2 = set TYPE=ROLLLADEN pos 0<br />
<br />
</pre><br />
<br />
Die Antworten werden als Schaltflächen dargestellt (Telegram inline Keyboard) und können am Mobile-Client direkt angeklickt werden um sie auszuführen.<br />
Um die Beschriftung der Schaltflächen zu optimieren, können die Befehle im Attribut favorites mit Beschreibungen versehen werden:<br />
<br />
<code>/[Rolllaeden zu ]=set TYPE=ROLLLADEN pos 100;/[Rolllaeden auf]=set TYPE=ROLLLADEN pos 0</code><br />
<br />
Nun antwortet der Bot auf das Schlüsselwort für die Favoriten mit:<br />
<br />
<pre><br />
Favorites<br />
<br />
/short1 = Rolllaeden zu<br />
<br />
/short2 = Rolllaeden auf<br />
<br />
</pre><br />
<br />
== Links ==<br />
* Github Repository für die Telegram-FHEM Entwicklung: https://github.com/viegener/Telegram-fhem<br />
* Infos zum Telegram BotFather: https://core.telegram.org/bots#6-botfather<br />
<br />
* Source code für das 50_TelegramBot.pm-Modul: https://github.com/viegener/Telegram-fhem/blob/master/50_TelegramBot.pm<br />
<br />
* Forum-Thread in dem das Modul vorgestellt wurde {{Link2Forum|Topic=38328|LinkText=FHEM-Forum}}<br />
* Telegram messaging system https://telegram.org/<br />
* TelegramBot API https://core.telegram.org/bots/api<br />
<br />
[[Kategorie:Telegram]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Yowsup&diff=30873Yowsup2019-06-30T17:14:15Z<p>AndreasMohr: Symmetrie: wenn TelegramBot yowsup referenziert [meint, referenzieren zu müssen?], dann sollte yowsup wiederum TelegramBot referenzieren.</p>
<hr />
<div>{{SEITENTITEL:yowsup}}<br />
{{Infobox Modul<br />
|ModPurpose=Schnittstelle, um WhatsApp-Nachrichten empfangen und senden zu können. <br />
|ModType=d<br />
|ModCmdRef=yowsup<br />
|ModFTopic=27543<br />
|ModForumArea=Unterstuetzende Dienste<br />
|ModTechName=32_yowsup.pm<br />
|ModOwner=André / justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:justme|Wiki]])<br />
}}<br />
<br />
Das Modul [[yowsup]] dient dazu, WhatsApp-Nachrichten zu empfangen und zu senden. Nachrichten können sein:<br />
* '''Text''': senden und empfangen, z.b.: Infonachrichten senden, FHEM-Kommandos empfangen<br />
* '''Bilder''': senden und empfangen, z.b.: Webcambilder nach Bewegungserkennung versenden<br />
* '''Audio''': empfangen, z.b.: Sprachdurchsagen empfangen und über SONOS abspielen<br />
<br />
== WARNUNG ==<br />
<br />
Momentan wird beim Registrierungsprozess anscheinend erkannt, dass es sich um yowsup handelt. Dies führt dann nach Versand des des Registrierungscodes per SMS/Voice zur direkten Sperrung der Rufnummer. Bis auf weiteres ist es also nicht empfehlenswert, Registrierungen vorzunehmen. Der Status dazu kann auf Github verfolgt werden: https://github.com/tgalal/yowsup/issues/2829<br />
<br />
Diese Warnung wird wieder entfernt, wenn das Problem gelöst ist.<br />
<br />
== Alternativen ==<br />
<br />
Für die Unterstützung von Telegram siehe Modul [[TelegramBot]].<br />
<br />
== Voraussetzungen ==<br />
* Die Funktionalität ist vermutlich auf Linux/Unix Systeme beschränkt.<br />
* Nach der Erstinstallation/-einrichtung '''muss''' zwingend das ''cmd'' Attribut korrekt gesetzt werden. <br />
<br />
== Installation == <br />
Die ursprüngliche Einrichtung wurde {{Link2Forum|Topic=27543|Message=204426|LinkText=hier beschrieben}}, jedoch sind noch einige wichtige Dinge zu setzen. Mit der Version 3.0.0 vom 24. April 2019 hat sich einiges in der Kommunikation mit WhatsApp geändert. Diese Änderungen führen dazu, dass alles komplett neu installiert und registriert werden muss.<br />
<br />
=== Yowsup Installation ===<br />
Bevor man loslegt sollte man wie immer sicherstellen, dass Debian auf dem aktuellen Stand ist:<br><br />
<code>sudo apt-get update</code><br><br />
<code>sudo apt-get upgrade</code><br><br />
<code>sudo apt-get dist-upgrade</code><br><br />
<br />
Will man Bilder verarbeiten, so braucht man noch ein paar Pakete mehr:<br />
* Paketinstallationen:<br />
** Unter Debian Wheezy: <code>sudo apt-get install libtiff4-dev libjpeg8-dev zlib1g-dev libfreetype6-dev liblcms2-dev libwebp-dev tcl8.5-dev tk8.5-dev python-tk</code><br />
** Unter Debian Jessie: <code>sudo apt-get install libtiff5-dev libjpeg-dev zlib1g-dev libfreetype6-dev liblcms2-dev libwebp-dev tcl8.5-dev tk8.5-dev python-tk</code><br />
** Unter Debian Stretch: <code>sudo apt-get install libtiff5-dev libjpeg-dev zlib1g-dev libfreetype6-dev liblcms2-dev libwebp-dev tcl8.5-dev tk8.5-dev python-tk</code><br />
<br />
==== Python 2.7 ==== <br />
Los gehts mit den Paketen:<br><br />
<code>sudo apt-get install python-soappy python-dateutil python-pip python-dev build-essential libssl-dev libffi-dev libncurses5-dev</code><br><br />
<br />
Nun erstmal pip updaten:<br><br />
<code>sudo pip install --upgrade pip</code><br><br />
<br />
yowsup benötigt zwingend von six die Version 1.10 (unter /usr/local/lib/python2.7/dist-packages prüfen, ob eine andere Version von six installiert ist. Diese erst löschen):<br><br />
<code>sudo pip uninstall six</code><br><br />
<code>sudo pip install six==1.10</code><br />
<br />
Und dann Axolotl, argparse, readline installieren (das dauert ne Weile):<br><br />
(eventuell wird auch noch appdirs benötigt)<br><br />
<code>sudo pip install argparse</code><br><br />
<code>sudo pip install setuptools</code><br><br />
<code>sudo pip install readline</code><br><br />
<code>sudo pip install appdirs</code><br><br />
<code>sudo pip install python-axolotl</code><br><br />
<code>sudo pip install pillow</code><br><br />
<br />
Zudem wird neben den Python Modulen noch eine Lib's von tgalal benötigt:<br />
<pre>cd /opt/fhem/yowsup<br />
sudo wget https://github.com/tgalal/python-axolotl/archive/master.zip<br />
sudo unzip master.zip<br />
cd python-axolotl-master<br />
sudo python setup.py install<br />
cd ..<br />
rm master.zip</pre><br />
<br />
<pre>cd /opt/fhem/yowsup<br />
sudo wget https://github.com/tgalal/dissononce/archive/master.zip<br />
sudo unzip master.zip<br />
cd dissononce-master<br />
sudo python setup.py install<br />
cd ..<br />
rm master.zip</pre><br />
<br />
<pre>cd /opt/fhem/yowsup<br />
sudo wget https://github.com/tgalal/consonance/archive/master.zip<br />
sudo unzip master.zip<br />
cd consonance-master<br />
sudo python setup.py install<br />
cd ..<br />
rm master.zip</pre><br />
<br />
Desweiteren muss man nun yowsup installieren:<br />
<pre><br />
cd /opt<br />
sudo mkdir yowsup-config<br />
sudo wget -N https://github.com/tgalal/yowsup/archive/master.zip<br />
sudo unzip -o master.zip<br />
cd yowsup-master<br />
sudo python setup.py install<br />
cd ..<br />
rm master.zip</pre><br />
<br />
==== Python 3.5 ====<br />
Bevor man loslegt sollte man wie immer sicherstellen, dass Debian auf dem aktuellen Stand ist:<br><br />
<code>sudo apt-get update</code><br><br />
<code>sudo apt-get upgrade</code><br><br />
<code>sudo apt-get dist-upgrade</code><br><br />
<br />
Los gehts mit den Paketen:<br><br />
<code>sudo apt-get install python3-pip python3-dev python3-setuptools python-soappy python-dateutil build-essential libssl-dev libffi-dev libncurses5-dev</code><br><br />
<br />
Nun erstmal pip updaten:<br><br />
<code>sudo pip3 install --upgrade pip</code><br><br />
<br />
yowsup benötigt zwingend von six die Version 1.10 (unter /usr/local/lib/python3.5/dist-packages prüfen, ob eine andere Version von six installiert ist. Diese erst löschen):<br><br />
<code>sudo pip3 uninstall six</code><br><br />
<code>sudo pip3 install six==1.10</code><br />
<br />
Und dann Axolotl, argparse, readline installieren (das dauert ne Weile):<br><br />
(eventuell wird auch noch appdirs benötigt)<br><br />
<code>sudo pip3 install argparse</code><br><br />
<code>sudo pip3 install setuptools</code><br><br />
<code>sudo pip3 install readline</code><br><br />
<code>sudo pip3 install appdirs</code><br><br />
<code>sudo pip3 install python-axolotl</code><br><br />
<code>sudo pip3 install pillow</code><br><br />
<br />
Zudem wird neben den Python Modulen noch Lib's von tgalal benötigt:<br />
<pre>cd /opt/fhem/yowsup<br />
sudo wget https://github.com/tgalal/python-axolotl/archive/master.zip<br />
sudo unzip master.zip<br />
cd python-axolotl-master<br />
sudo python3 setup.py install<br />
cd ..<br />
rm master.zip</pre><br />
<br />
<pre>cd /opt/fhem/yowsup<br />
sudo wget https://github.com/tgalal/dissononce/archive/master.zip<br />
sudo unzip master.zip<br />
cd dissononce-master<br />
sudo python3 setup.py install<br />
cd ..<br />
rm master.zip</pre><br />
<br />
<pre>cd /opt/fhem/yowsup<br />
sudo wget https://github.com/tgalal/consonance/archive/master.zip<br />
sudo unzip master.zip<br />
cd consonance-master<br />
sudo python3 setup.py install<br />
cd ..<br />
rm master.zip</pre><br />
<br />
Desweiteren muss man nun yowsup installieren:<br />
<pre><br />
cd /opt<br />
sudo mkdir yowsup-config<br />
sudo wget -N https://github.com/tgalal/yowsup/archive/master.zip<br />
sudo unzip -o master.zip<br />
cd yowsup-master<br />
sudo python3 setup.py install<br />
cd ..<br />
rm master.zip<br />
</pre><br />
<br />
==== Fhem vorbereiten ====<br />
Vor den weiteren Schritten sollte geprüft werden, ob dem User fhem eine Loginshell zugewiesen ist:<br />
:<code>getent passwd fhem</code><br />
Wird hier am Ende /bin/false ausgegeben, so muss dies angepasst werden:<br />
:<code>sudo chsh -s /bin/bash fhem</code><br />
<br />
Mittels ''getent passwd fhem'' kann auch bereits das Home-Verzeichnis ausgelesen werden, dies steht in der ausgegebenen Doppelpunkt-separierten Liste an vorletzter Stelle. <br />
<br />
Nun loggt man sich unter dem User ein, unter dem fhem läuft (in den folgenden Beispielen werden die vom fhem-Setup-Script generierten Defaults verwendet: User=fhem , home=/opt/fhem Gruppe=dialout) und liest dort die $HOME-Variable aus und prüft das Home-Verzeichnis:<br />
<pre>sudo su - fhem<br />
echo $HOME<br />
cd $HOME<br />
logout</pre><br />
Diesen Wert braucht man später - gut merken. Sollte hier ein Fehler auftreten (z.B. das home nicht vorhanden), so muss dies zuerst korrigiert werden.<br />
<br />
Vor den weiteren Schritten sollte man nun erstmal die yowsup Verzeichnisse dem fhem-user zugängig machen:<br />
<pre>sudo chown -R fhem:dialout /opt/yowsup-master /opt/yowsup-config</pre><br />
<br />
Für die folgenden Schritte würde ich auf den FHEM-Nutzer wechseln:<br />
<pre>sudo su - fhem<br />
cd /opt/yowsup-master</pre><br />
<br />
==== WhatsApp einrichten ====<br />
Bitte daran denken...<br />
<pre>sudo su - fhem<br />
cd /opt/yowsup-master</pre><br />
<br />
Nun erfolgt die Anmeldung am WhatsApp-Server. Dies kann man nun via <code>voice</code> oder <code>sms</code> machen. Bei einem Handy bietet sich SMS an, bei Festnetzanschlüssen sollte voice gewählt werden, wenn man sich nicht sicher ist, dass der Anschluss die Funktion 'SMS im Festnetz' unterstützt. Dann wird der Bestätigungscode zwar auf Englisch vorgelesen, dafür ist die Zuverlässigkeit des Registrierungsvorganges zuverlässiger. Bei Festnetznummern sollte man unbedingt etwas zum Schreiben bereit halten! (49XXXXXXXX durch Eure Telefonnummer ersetzen.)<br><br />
<br />
'''Python 2.5'''<br />
<pre>yowsup-cli registration --requestcode sms --config-phone 49XXXXXXXX --config-cc 49</pre><br />
<br />
'''Python 3.5'''<br />
<pre>python3 yowsup-cli registration --requestcode sms --config-phone 49XXXXXXXX --config-cc 49</pre><br />
<br />
Die Rückmeldung ist nun entscheidend. Wenn man diese zurückbekommt:<br />
<pre>de sms<br />
status: fail<br />
retry_after: 3600<br />
reason: no_routes</pre><br />
Dann ist die Nummer so nicht kompatibel. Was man dann noch probieren kann, ist die registration via voice - meistens ist das aber vergebene Liebesmüh'.<br />
<br />
Wenn man folgende Rückmeldung bekommt:<br />
<pre>I 2019-04-24 15:05:22,368 yowsup.common.http.warequest - {"login":"49xxxxxxxxxx","status":"sent","length":6,"method":"sms","retry_after":65,"sms_wait":65,"voice_wait":65}<br />
<br />
status: sent<br />
voice_wait: 65<br />
retry_after: 65<br />
sms_wait: 65<br />
length: 6<br />
login: 49xxxxxxxxxx<br />
method: sms</pre><br />
<br />
So ist alles gut gelaufen und man sollte kurz später eine SMS bekommen. Darin ist ein Text, der am Ende z.B. 123-456 lautet. Diesen fügt man ohne Bindestrich am Ende des folgenden Befehls ein (49XXXXXXXX durch Eure Telefonnummer ersetzen.):<br><br />
<br />
'''Python 2.5'''<br />
<pre>python3 yowsup-cli registration --config-phone 49XXXXXXXX -R 123456</pre><br />
<br />
'''Python 3.5'''<br />
<pre>python3 yowsup-cli registration --config-phone 49XXXXXXXX -R 123456</pre><br />
<br />
Dann kommt ein Text der etwa so aussehen sollte:<br />
<pre>I 2019-04-24 15:15:09,118 yowsup.common.http.warequest - {"status":"ok","login":"49xxxxxxxxxx","type":"existing","edge_routing_info":"CAUIAg==","chat_dns_domain":"fb","security_code_set":false}<br />
<br />
{<br />
"__version__": 1,<br />
"cc": "49",<br />
"client_static_keypair": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",<br />
"expid": "xxxxxxxxxxxxxxxxxxxxxxxx",<br />
"fdid": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",<br />
"id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxx",<br />
"mcc": "000",<br />
"mnc": "000",<br />
"phone": "49xxxxxxxxxx",<br />
"sim_mcc": "000",<br />
"sim_mnc": "000"<br />
}</pre><br><br />
<br />
Yowsup legt eine neue Konfigurationsdatei im unter $HOME/.config/49xxxxxxxxxx/. Diese wird automatisch herangezogen, wenn die entsprechende Telefonnummer mit --config-phone 49XXXXXXXX angegeben wird.<br />
<br />
Nun mal ein schneller Test an die eigene Nummer (im Beispiel 491751234567):<br />
<pre>python[3] yowsup-cli demos --config-phone 49XXXXXXXX -s 491751234567 "Das ist ein Test"</pre><br />
<br />
Hier seht ihr nun einen Status (die Anzahl prekeys wird hoch gezählt):<br />
<pre>I 2019-04-24 15:33:58,647 yowsup.layers.network.layer - Connecting to e7.whatsapp.net:443<br />
I 2019-04-24 15:33:59,230 yowsup.axolotl.manager - Generating 812 prekeys<br />
I 2019-04-24 15:34:15,590 yowsup.axolotl.manager - Storing 812 prekeys<br />
I 2019-04-24 15:35:03,100 yowsup.axolotl.manager - Loaded 812 unsent prekeys</pre><br />
<br />
Das sollte dir eine Nachricht einbringen. Wenn du darauf antwortest, kommt diese allerdings noch nicht an - der Client hat sich nach dem Befehl sofort beendet. Damit dieser dauerhaft im Hintergrund läuft legen wir nun in FHEM ein Gerät an, welches dies steuert.<br />
<br />
=== FHEM Define ===<br />
* FHEM Device anlegen: <code> define <name> yowsup</code>, also z.B. <code>define WhatsApp yowsup</code><br />
* Nun muss man den Pfad zu yowsup anpassen: <br />
* Python 2.7<br />
* <code>attr WhatsApp cmd /opt/yowsup-master/yowsup-cli demos --config-phone 49XXXXXXXX --yowsup</code><br />
* Python 3.5<br />
* <code>attr WhatsApp cmd python3 /opt/yowsup-master/yowsup-cli demos --config-phone 49XXXXXXXX --yowsup</code><br />
* Und das Home directory mit dem Pfad zum Home des fhem users: <code>attr WhatsApp home PWD</code><br />
* Wenn alles gut geht, gibt es danach im Device ein internal PID und das Reading ''state''<br />
* Im Whatsapp Client auf dem Handy sollte man sehen, dass FHEM online ist<br />
* Zum Senden aus FHEM kann man das Kommando <code>set WhatsApp send <nummer> <text></code> verwenden<br />
<br />
== Attribute ==<br />
Bitte sieh immer in der {{Link2CmdRef|Anker=yowsup}} nach - diese hier könnten veraltet sein.<br />
<br />
* <code>cmd</code><br />komplettes Kommando, um den yowsup Client zu starten. z.B.: <code>attr WhatsApp cmd /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup</code>. Wenn die ab yowsup-Version 2.4 standartmässig aktivierte Verschlüsselung abgeschaltet werden muss weil die entsprechenden Libs nicht installiert sind: <code>attr WhatsApp cmd /opt/local/bin/yowsup-cli demos -c /root/yowsup-config --yowsup -M</code>.<br />
* <code>acceptFrom</code><br />kommagetrennte Liste von Kontakten (Nummern), von denen Nachrichten akzeptiert werden. Ist das Attribut nicht gesetzt, so werden die Nachrichten von jedem akzeptiert.<br />
* <code>commandPrefix</code><br />nicht gesetzt -> es werden keine Befehle akzeptiert.<br />0 -> es werden keine Befehle akzeptiert.<br />1 -> erlaubt Befehle, jede Nachricht wird als FHEM-Befehl interpretiert.<br />alles andere -> Wenn die Nachricht mit diesem Prefix startet, wird alles weitere als Befehle interpretiert.<br />
{{Randnotiz|RNTyp=Warn|RNText='''allowedCommands''' should work as intended, but no guarantee can be given, that there is no way to circumvent it.}}<br />
* <code>allowedCommands</code><br />Eine Komma-getrennte Liste von zulässigen Befehlen für diesen Kontakt. Wenn die Liste leer ist (z.B. nur ein Komma), dann werden keine Befehle akzeptiert.<br />
* <code>home</code><br />Setzt das Home-directory welches für yowsup verwendet werden soll.<br />
<br />
== Befehle ==<br />
* image -> Über diesen Befehl können Bilder gesendet werden.<br />
<br />
* raw -> Status ändern : <br />
<code>set WhatsApp raw /profile setStatus 'mein Status' <--- die ' ' müssen bleiben</code><br />
<br />
Name der angezeigt werden soll, wenn eine Nachricht z.B. ans iPhone geschickt wird:<br />
<br />
<code>set WhatsApp raw /presence name <DeinNick></code><br />
<br />
Anzeige online :<br />
<br />
<code>set WhatsApp raw /presence available</code><br />
<br />
Profilbild ändern :<br />
<br />
<code>set WhatsApp raw /profile setPicture '/opt/fhem/fhem_logo.png'</code><br />
<--- der gesamte Pfad zum Bild muss angegeben werden und Rechte müssen ggfs. bei fhem liegen<br />
<br />
Falls es nicht funktioniert disconnect/connect probieren.<br />
<br />
== Update ==<br />
Da am WhatsApp ständig geschraubt wird, bedarf es eines Updates des Yowsup, wenn keine Funktion mehr gegeben ist:<br />
<pre>cd /opt<br />
sudo rm master.zip<br />
sudo mv yowsup-master yowsup-master-alt<br />
sudo wget -N https://github.com/tgalal/yowsup/archive/master.zip<br />
#alternativ sudo wget https://github.com/jlguardi/yowsup/archive/master.zip (Stand März 2016 aktueller)<br />
sudo unzip master.zip<br />
sudo chown fhem yowsup-master -R<br />
sudo chgrp dialout yowsup-master -R</pre>Danach muss FHEM mittels 'shutdown restart' neu gestartet werden.<br />
<br />
== Anwendungsbeispiele ==<br />
=== Beispielnachricht ===<br />
Beim Empfang einer Nachricht wird automatisch ein FHEM Device für diesen Kontakt angelegt. In diesem Device gibt es das Reading '''message''' für die empfangene Nachricht und ab der ersten Nachricht auch das Reading '''chatstate''', in dem zu sehen ist, ob gerade getippt wird.<br />
Nachdem ein Device für einen Kontakt angelegt ist, lässt sich auch direkt dieses Device zum Senden verwenden: <br />
:<code>set <device> send <text></code>, <br />
d.h., man spart sich die Angabe der Nummer.<br />
<br />
=== Gruppen ===<br />
Gruppen müssen über die App (Smartphone / Tablet) angelegt werden. Nach dem Empfang einer entsprechenden Nachricht werden Gruppen genauso behandelt, wie einfache Teilnehmer.<br />
<br />
=== Broadcast ===<br />
Beim Senden über das Masterdevice lassen sich mehrere Empfänger mit Komma (und ohne Leerzeichen) getrennt angeben. Die entsprechenden Nachrichten werden dann per Broadcast an alle Teilnehmer gesendet. Die Broadcastempfänger müssen zuvor mindestens eine normale Nachricht erhalten haben.<br />
<br />
=== Komponenten steuern ===<br />
Um ein [[notify]] anlegen zu können, müssen wir zuerst eine Nachricht vom Handy an FHEM senden. Dadurch wird ein Device mit der Nummer als Namen angelegt. Danach sollte das Device umbenannt werden, da einige Befehle einen Namen ausschließlich aus Ziffern nicht akzeptieren. Dies geschieht wie folgt:<br />
<br />
:<code>rename 49123456789 HandySeppel</code><br />
<br />
Danach kann ein ''notify'' angelegt werden:<br />
<br />
<syntaxhighlight lang="perl"><br />
define notifySeppelLicht notify HandySeppel:message.* {<br />
if( $EVENT eq 'message: Licht an' ) {<br />
fhem "set HandySeppel send Licht ist nun an...";<br />
fhem "set FS20_a5d800 dim100%";<br />
<br />
} elsif( $EVENT eq 'message: Licht aus' ) {<br />
fhem "set HandySeppel send Licht ist nun aus...";<br />
fhem "set FS20_a5d800 dim0%";<br />
<br />
} else {<br />
fhem "set HandySeppel send Wie bitte?"<br />
<br />
}<br />
}</syntaxhighlight><br />
<br />
Natürlich ist dieses ''notify'' noch auf die eigenen Wünsche anzupassen.<br />
<br />
=== Autoresponder ===<br />
Nachdem man nun seine Festnetznummer bei WhatsApp registriert hat, wird auch diese natürlich als erreichbares Ziel auf jedem Gerät angezeigt, auf dem sie gespeichert ist. So kann es passieren, dass WhatsApp-Nachrichten nicht gelesen werden. Hier schafft ein Autoresponder Abhilfe:<br />
:<code>define not_WhatsApp_Autoresponder notify 491.*:message.* set $NAME send Hallo, Du hast eine Nachricht an unsere Festnetznummer geschickt. Da ist aber nur ein kleiner Computer auf Empfang, der Dir nur diese Antwort schicken kann. Bitte benutze unsere Mobilnummern, wenn Du willst, dass Deine Nachricht auch gelesen wird!</code><br />
Das Problem hierbei ist, dass noch nicht bekannt ist, wer etwas sendet und so der Kontakt u.U. noch nicht angelegt ist. Daher wird im obigen Beispiel auf 491*:message.* reagiert. So bekommen nur deutsche Mobilrufnummern die Antwort. Um das noch globaler zu fassen, könnte z.B. auf \d*.*:message.* reagiert werden, was aber voraussetzt, dass keine weiteren Modulnamen (die das Reading message haben) mit einer Ziffer beginnen.<br />
Alle Kontakte, welche nicht den Autoresponder erhalten sollen, müssen wie oben beschrieben entspr. umbenannt werden:<br />
:<code>rename 49123456789 HandySeppel</code><br />
<br />
== Probleme und Lösungen ==<br />
=== Immer wieder offline ===<br />
Das WhatsApp Device geht immer wieder offline und im Log wird folgendes protokolliert:<br />
<br />
... yowsup.layers.axolotl.layer_receive:invalidmessage or keyid for ...<br />
<br />
Lösung:<br />
<br />
Verzeichnis .yowsup in /root löschen.<br />
Das Verzeichnis entsteht durch das Testen auf der Konsole und verträgt sich dann nicht mit dem im Attribut home hinterlegten Verzeichnis.<br />
<br />
=== UTF-8 Fehler ===<br />
<br />
Lösung: https://forum.fhem.de/index.php/topic,27543.msg773746.html#msg773746<br />
<br />
<br />
== Links ==<br />
* {{Link2Forum|Topic=27543|LinkText=Forenthread}}, in dem die Whatsapp Anwendung beschrieben wird<br />
* {{Link2Forum|Topic=27543|Message=299292|LinkText=Foreneintrag}}, ab dem das yowsup Modul beschrieben wird<br />
* Die Python Whatsapp Library auf [https://github.com/tgalal/yowsup github]<br />
* Imagehandling Bugfix [https://github.com/tgalal/yowsup/issues/901 github]<br />
<br />
[[Kategorie:WhatsApp]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Kategorie:433MHz&diff=30370Kategorie:433MHz2019-05-03T10:05:17Z<p>AndreasMohr: /* Nachteile */</p>
<hr />
<div>Sammlung aller Informationen zu Geräten, die auf 433MHz senden und empfangen.<br />
<br />
Die Träger Frequenz von 433MHz wird zwar von sehr vielen Geräten verwendet, es existieren aber - mit Ausnahme von [[Intertechno Code Berechnung|Intertechno]] wenig Standards bei der tatsächlichen Gestaltung der Funksignale. Daher ist die Einbindung derartiger Geräte häufig Glückssache. Oft gelingt dies ohne größere Probleme durch Verwendung eines [[CUL]] oder [[SIGNALduino]]. Sobald jedoch die Signale des Geräts bzw. der mitgelieferten Fernbedienungen nicht von diesen Geräten erkannt werden können, kann die Einbindung sehr aufwendig werden. Ein guter Einstieg in die theoretischen Grundlagen ist [[Unbekannte Funkprotokolle#Basics|hier]] zu finden.<br />
<br />
== Nachteile ==<br />
Bitte bedenken Sie vor dem Einsatz von 433MHz-Komponenten, dass diese zwar in der Regel recht günstig sind, aber auch häufig Eigenschaften aufweisen, die Sie kennen sollten:<br />
* Soweit bekannt, gibt es im Bereich der 433MHz-Geräte keine Geräte, die über einen Rückkanal verfügen, also eine Rückmeldung darüber geben, ob ein Aktor eine an ihn gerichtete Nachricht auch erhalten hat.<br />
* Sobald ein bestimmtes Protokoll bekannt ist, kann im Prinzip jeder in Funkreichweite die entsprechenden Geräte auch schalten. Etwas besser sind daher Geräte, die einen sog. [https://de.wikipedia.org/wiki/Rollingcode Rolling Code] verwenden, wie z.B. [[SOMFY]]. Diese Art der Protokolle sind daher auch schwerer zu dekodieren. Gerade in dicht besiedelten Gebieten sind bei einfachsten Komponenten auch unbeabsichtigte Fernschaltungen denkbar.<br />
* Störungen im Frequenzband sind nicht auszuschließen. Bekannte Fehlerursachen sind z.B. annähernd leere Batterien, z.B. von Außentemperatursensoren (auch von Nachbarn) oder in Schubladen vergessene Fernbedienungen, deren Tasten versehentlich dauer-gedrückt werden.<br />
* Abgesehen von Markenherstellern wie InterTechno sind die Geräte häufig nicht nur im Preis günstig, sondern auch - insbesondere bei Funksteckdosen "aus dem Baumarkt" - intern mit billigsten Komponenten aufgebaut - folgende Nachteile sind hier möglich:<br />
** Dies kann einen hohen Eigenverbrauch bedingen, im schlimmsten Fall besteht Brandgefahr!<br />
** Re-Initialisierung (State-Reset) nach Batteriewechsel funktioniert evt. nicht zuverlässig, wegen vorhandener Rest-Ladung (--> Gerät hängt sich auf, weil es sich nicht korrekt initialisiert); in diesem Fall hilft es, kurz die beiden relevanten Batteriefach-Pole (Haupt-Spannungs-Klemmen) kurzzuschließen (z.B. mit einer Schere), um eine vollständige Entladung des Geräts zu erreichen und somit nach Batteriewechsel korrekt "frisch" anzufangen<br />
<br />
[[Kategorie:Hardware]]<br />
[[Kategorie:Other Components]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=JUDO_iSoft_Plus&diff=29920JUDO iSoft Plus2019-03-16T17:15:54Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=judo-soft-plus.jpg|200px<br />
|Bildbeschreibung=JUDO i-soft plus Wasserenthärtungsanlage<br />
|HWProtocol=IP<br />
|HWType=Wasserenthärter<br />
|HWCategory=IP<br />
|HWVoltage=230&nbsp;V<br />
|HWPoweredBy=AC<br />
|HWSize=39x67x45 cm (BxHxT)<br />
|HWComm=n/a<br />
|HWChannels=n/a<br />
|HWPowerConsumption=?<br />
|HWDeviceFHEM=[[HTTPMOD]]<br />
<!-- |ModOwner= --><br />
|HWManufacturer=Judo GmbH<br />
}}<br />
__TOC__<br />
<br />
Die JUDO i-soft plus Enthärtungsanlage [https://judo.eu/produkt/judo-i-soft-plus-vollautomatische-enthaertungsanlage/] ist eine Wasserenthärtungsanlage mit IP-Konnektivität. <br />
Sie verfügt über LAN und WLAN-Anschluss und ist auf die Steuerung via App des Herstellers ausgelegt.<br />
<br />
Für eine erfolgreiche Integration in FHEM muss die Anlage über das Menü beim Hersteller registriert werden.<br />
Die folgenden Informationen sind erforderlich:<br />
<br />
* Benutzername: Selbst gewählter Login-Name auf der i-soft plus (vgl. Gerätehandbuch)<br />
* Kennwort: Selbst gewähltes Kennwort<br />
* Seriennummer: Seriennummer des Geräts. Diese ist entweder über das Menü auslesbar oder alternativ auch über die APP des Herstellers.<br />
* IP-Adresse: Die IP-Adresse des Geräts im Heimnetz. <br />
<br />
== Einbindung in FHEM ==<br />
<br />
Das Gerät wird mittels des Moduls HTTPMOD eingebunden. Dazu gilt zunächst die folgende Konfiguration als Basis.<br />
Zunächst legen wir die Standardanfrage an das Modul fest. Die Portnummer 8124 ist vom Hersteller vorgegeben. Wir vergeben gleich ein paar Platzhalter, die später in den Aufrufen und den Antworten ersetzt werden, damit wir die Werte nur an einer zentralen Stelle konfigurieren müssen.<br />
<br />
<pre><br />
define JUDO_iSoft HTTPMOD https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=4&token=%token% 300<br />
</pre><br />
Mit dieser Definition wird als Standard-Anfrage die Statusabfrage nach dem Wasserstop gesendet. Diese wird zyklisch alle 300 Sekunden wiederholt. <br />
Wem das nicht reicht, der kann den Zyklus herunter setzen oder auch nach anderen Standard-Werten abfragen. Wer das kontinuierliche Pollen vermeiden will, setzt den Wert auf 0.<br />
<br />
Nach erfolgreicher Authentifizierung wird von der i-soft ein Token generiert und muss bei jedem Aufruf übergeben werden:<br />
<br />
<pre><br />
attr JUDO_iSoft replacement01Mode reading<br />
attr JUDO_iSoft replacement01Regex %token%<br />
attr JUDO_iSoft replacement01Value token<br />
</pre><br />
<br />
Anschließend legen wir die Ersetzungen für die anderen Platzhalter fest: <br />
<br />
<pre><br />
attr JUDO_iSoft replacement02Mode text<br />
attr JUDO_iSoft replacement02Regex %JUDO_ipaddress%<br />
attr JUDO_iSoft replacement02Value <hier eigene IP Adresse im lokalen Netz eintragen><br />
attr JUDO_iSoft replacement03Mode text<br />
attr JUDO_iSoft replacement03Regex %JUDO_password%<br />
attr JUDO_iSoft replacement03Value <hier Kennwort eintragen><br />
attr JUDO_iSoft replacement04Mode text<br />
attr JUDO_iSoft replacement04Regex %JUDO_username%<br />
attr JUDO_iSoft replacement04Value <hier Benutzername eintragen><br />
attr JUDO_iSoft replacement05Mode text<br />
attr JUDO_iSoft replacement05Regex %JUDO_serial%<br />
attr JUDO_iSoft replacement05Value <hier Seriennummer eintragen><br />
</pre><br />
<br />
Die Authentifizierung der Anlage erfolgt zwei-stufig. Zunächst muss ein Aufruf mit Benutzername und Kennwort erfolgen. Als Antwort erhält man einen JSON-String, der das Token beinhaltet. Mit diesem Token wird anschließend die Funktion connect aufgerufen und die Seriennummer des Geräts mit übergeben. <br />
HTTPMOD erkennt, wenn ein neues Login erforderlich ist, wenn die Judo die Rückmeldung "no token" oder "not logged in" liefert.<br />
<br />
Achtung: Als Parameter muss ebenfalls der Typ "i-soft plus" übergeben werden. Vermutlich ist dieser bei anderen Geräten des Herstellers anders. Ich habe ihn hier fix eingetragen, da ich keine Möglichkeit zum Testen anderer Geräte habe. <br />
<br />
<pre><br />
attr JUDO_iSoft showError 1<br />
attr JUDO_iSoft authRetries 2<br />
attr JUDO_iSoft reAuthRegex (no token)|(not logged in)<br />
attr JUDO_iSoft sid01ParseResponse 1<br />
attr JUDO_iSoft sid01URL https://%JUDO_ipaddress%:8124/?group=register&command=login&msgnumber=1&name=login&user=%JUDO_username%&password=%JUDO_password%&role=customer<br />
attr JUDO_iSoft sid02URL https://%JUDO_ipaddress%:8124/?group=register&command=connect&msgnumber=6&token=%token%&parameter=i-soft%20plus&serial%20number=%JUDO_serial%<br />
</pre><br />
<br />
Damit ist die Grundkonfiguration hergestellt und die Anlage kann sich connecten. <br />
In den einzelnen JSON-Rückantworten der Anlage werden die Werte zur jeweilige Anfrage immer als "data" zurück geliefert. Mit der Standard-Konfiguration<br />
<br />
<pre><br />
attr JUDO_iSoft extractAllJSON 1<br />
</pre><br />
<br />
werden daraus automatisch entsprechende Readings angelegt. Da wir aber dann immer das Reading "data" überschreiben würden, kommt eine weitere Ersetzung zum Einsatz. In der Antwort steht neben einer Kaskadierung (group) auch der zugehörige Befehl (command). Ich habe mich dafür entschieden, ein neues Reading mit dem jeweiligen Command-Namen anzulegen. Die zugehörigen Ersetzungen sind wie folgt.<br />
Erklärung zum Ausdruck reading03OExpr: Zunächst werden die Leerzeichen im Rückgabewert ($val) durch "-" ersetzt. Mit dem so veränderten String erzeugen wir ein neues Reading mit dem Wert aus dem Reading data. <br />
<br />
<pre><br />
attr JUDO_iSoft reading01JSON data<br />
attr JUDO_iSoft reading01Name token<br />
attr JUDO_iSoft reading01Regex "token":"([^"]+)"<br />
attr JUDO_iSoft reading02JSON group<br />
attr JUDO_iSoft reading03JSON command<br />
attr JUDO_iSoft reading03OExpr $val =~ s/\s/-/;; $val; readingsBulkUpdate($hash,$val,ReadingsVal("JUDO_iSoft","data",""))<br />
</pre><br />
Noch ein paar ergänzende Attribute gesetzt:<br />
<pre><br />
attr JUDO_iSoft enableControlSet 1<br />
attr JUDO_iSoft getHeader1 Content-Type: application/json<br />
attr JUDO_iSoft getHeader2 Accept: */*<br />
attr JUDO_iSoft room 10_Räume->UG->Keller,<br />
attr JUDO_iSoft showError <br />
attr JUDO_iSoft timeout 5<br />
</pre><br />
<br />
Damit sind alle Voraussetzungen erledigt. Ab jetzt können wir die einzelnen Get-Befehle implementieren:<br />
<br />
<pre><br />
attr JUDO_iSoft get01Name SerialNumber<br />
attr JUDO_iSoft get01URL https://%JUDO_ipaddress%:8124/?group=spare%20part&command=serial%20number&msgnumber=5&token=%token%<br />
<br />
attr JUDO_iSoft get02Name WaterCurrent<br />
attr JUDO_iSoft get02URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20current&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get03Name SaltRange<br />
attr JUDO_iSoft get03URL https://%JUDO_ipaddress%:8124/?group=consumption&command=salt%20range&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get04Name SaltQuantity<br />
attr JUDO_iSoft get04URL https://%JUDO_ipaddress%:8124/?group=consumption&command=salt%20quantity&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get05Name ResidualHardness<br />
attr JUDO_iSoft get05URL https://%JUDO_ipaddress%:8124/?group=settings&command=residual%20hardness&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get06Name NaturalHardness<br />
attr JUDO_iSoft get06URL https://%JUDO_ipaddress%:8124/?group=info&command=natural%20hardness&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get07Name WaterStop<br />
attr JUDO_iSoft get07URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get08Name FlowRate<br />
attr JUDO_iSoft get08URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=flow%20rate&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get09Name SoftwareVersion<br />
attr JUDO_iSoft get09URL https://%JUDO_ipaddress%:8124/?group=version&command=software%20version&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get10Name HardwareVersion<br />
attr JUDO_iSoft get10URL https://%JUDO_ipaddress%:8124/?group=version&command=hardware%20version&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get11Name InstallationDate<br />
attr JUDO_iSoft get11URL https://%JUDO_ipaddress%:8124/?group=contract&command=init%20date&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get12Name ServiceDate<br />
attr JUDO_iSoft get12URL https://%JUDO_ipaddress%:8124/?group=contract&command=service%20date&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get13Name WaterTotal<br />
attr JUDO_iSoft get13URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20total&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get14Name WaterAverage<br />
attr JUDO_iSoft get14URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20average&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get15Name Vacation<br />
attr JUDO_iSoft get15URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=vacation&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get16Name Quantity<br />
attr JUDO_iSoft get16URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=quantity&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get17Name WaterDaily<br />
attr JUDO_iSoft get17URL https://%JUDO_ipaddress%:8124/?group=consumption&command=water%20daily&msgnumber=1&token=%token%<br />
<br />
attr JUDO_iSoft get18Name ValveState<br />
attr JUDO_iSoft get18URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=4&&token=%token%<br />
<br />
</pre><br />
<br />
Zum Setzen einiger Werte werden die folgenden Kommandos zum Schließen und Öffnen des Wasserstopps sowie das Setzen der Wunschwasserhärte implementiert<br />
<br />
<pre><br />
attr JUDO_iSoft set01Name CloseValve<br />
attr JUDO_iSoft set01URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%&parameter=close<br />
attr JUDO_iSoft set02Name OpenValve<br />
attr JUDO_iSoft set02URL https://%JUDO_ipaddress%:8124/?group=waterstop&command=valve&msgnumber=1&token=%token%&parameter=open<br />
attr JUDO_iSoft set03Name residual-hardness<br />
attr JUDO_iSoft set03URL https://%JUDO_ipaddress%:8124/?group=settings&command=residual%20hardness&msgnumber=1&token=%token%&parameter=$val<br />
</pre><br />
<br />
<br />
<br />
'''Userreadings'''<br />
<br />
Um die Originalwerte aus der Anlage benutzerfreundlicher darzustellen, werden noch Userreadings angelegt.<br />
<br />
Die Salzrestdauer soll in Wochen angegeben (rückgemeldet werden Tage) werden, die verbleibende Salzmenge in Prozent. <br />
Die Salzmenge wird in Gramm angegeben, 50.000 entsprechen 100%.<br />
Wichtig: Bei den Userreadings muss darauf geachtet werden, dass diese mit Komma separiert und in einer Zeile geschrieben werden. <br />
<pre><br />
<br />
attr JUDO_iSoft saltRangeInWeeks { int( (ReadingsVal("JUDO_iSoft","salt-range",0)/7))} , saltQuantityInPercent { int( (ReadingsVal("JUDO_iSoft","salt-quantity",0)/50000)*100)}<br />
</pre><br />
<br />
== Readings auslesen ==<br />
Die Art der Anbindung liefert veränderte Readings nur, wenn man sie regelmäßig abfragt. Dazu habe ich dazu einen Timer aufgesetzt, der 1x am Tag die relevanten Werte abfragt. Das ist eigentlich nur wichtig, falls man ab und an doch noch über einen anderen Weg z.B. die Apps des Herstellers auf die JUDO zugreift und Werte verändert. Bei mir sieht das dann so aus:<br />
<pre><br />
Internals:<br />
COMMAND get JUDO_iSoft SaltQuantity;<br />
get JUDO_iSoft SaltRange;<br />
get JUDO_iSoft WaterDaily;<br />
get JUDO_iSoft WaterTotal;<br />
get JUDO_iSoft WaterAverage;<br />
get JUDO_iSoft FlowRate;<br />
get JUDO_iSoft ResidualHardness;<br />
<br />
DEF *23:55:00 <br />
get JUDO_iSoft SaltQuantity;<br />
get JUDO_iSoft SaltRange;<br />
get JUDO_iSoft WaterDaily;<br />
get JUDO_iSoft WaterTotal;<br />
get JUDO_iSoft WaterAverage;<br />
get JUDO_iSoft FlowRate;<br />
get JUDO_iSoft ResidualHardness;<br />
NAME at_Judo_DailyStats<br />
NR 1595<br />
PERIODIC yes<br />
RELATIVE no<br />
REP -1<br />
STATE Next: 23:55:00<br />
TIMESPEC 23:55:00<br />
TRIGGERTIME 1538862900<br />
TRIGGERTIME_FMT 2018-10-06 23:55:00<br />
TYPE at<br />
READINGS:<br />
2018-10-06 06:06:14 state Next: 23:55:00<br />
Attributes:<br />
room ,00_Masterswitches,10_Räume->UG->Keller<br />
<br />
</pre><br />
<br />
Um 1x pro Stunde gegen Ende der vollen Stunde den Wasserbrauch der aktuellen Stunde abzugreifen setze ich einen weiteren Timer auf. Bei mir jeweils um :58 der aktuellen Stunde. Das ist natürlich nicht ganz exakt. Wenn sich die Uhr der Judo und von FHEM auseinander driften bekommt man ggf. schon wieder den Wert der nächsten Stunde. <br />
<pre><br />
Internals:<br />
CFGFN <br />
COMMAND get JUDO_iSoft WaterCurrent<br />
DEF +*01:00:00 get JUDO_iSoft WaterCurrent<br />
NAME at_Judo_HourlyStats<br />
NR 34559<br />
NTM 06:58:00<br />
PERIODIC yes<br />
RELATIVE yes<br />
REP -1<br />
STATE Next: 06:58:00<br />
TIMESPEC 01:00:00<br />
TRIGGERTIME 1538801880<br />
TRIGGERTIME_FMT 2018-10-06 06:58:00<br />
TYPE at<br />
READINGS:<br />
2018-10-06 06:20:53 state Next: 06:58:00<br />
Attributes:<br />
alignTime 00:58<br />
room ,00_Masterswitches,10_Räume->UG->Keller<br />
</pre><br />
<br />
== Statistiken ==<br />
Die i-soft plus liefert verschiedene Statistiken zum Wasserverbrauch zurück. Die werden allerdings etwas eigentümlich zurückgemeldet.<br />
Unter water-current ist der jeweilige Verbrauch je Stunde zusammengefasst. Ich hole kurz vor der vollen Stunde diesen Wert ab, damit er danach im Logfile landet.<br />
Unter water-daily werden Tagesstatistiken geliefert. Kurioserweise in 3-Stunden-Paketen, d.h. 8 Werte. Die ersten Werte sind von 0h-3h, 3h-6h usw.<br />
Ich habe mich aktuell darauf beschränkt, den stündlichen Verbrauch zu erfassen und zu protokollieren. Es lassen sich aber auch bei Bedarf detaillierte Datumsbezogene Statistiken abrufen. Ich habe noch keinen sinnvollen Weg gefunden, das mit FHEM zu verbinden. <br />
<br />
<br />
== Darstellung in Tablet UI ==<br />
Ich nutze Tablet UI für die Visualisierung. <br />
Zur Darstellung der Restmengen Salz nutze ich das knob-widget, für das Setzen des Härtegrades den spinner.<br />
<br />
[[Datei:Screenshot judo 2.jpg|mini|Visualisierung der Judo im TabletUI|200px]]<br />
<br />
<pre><br />
<div class="hbox"><br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Zustand Salz</header><br />
<div class="sheet"><br />
<br />
<div class="row"><br />
<div class="cell-50 top-align center-align left-space"><br />
<div class="big">Restmenge</div><br />
<div data-type="knob" data-device="JUDO_iSoft"<br />
data-get="saltQuantityInPercent"<br />
data-unit="%"<br />
data-step="1"<br />
data-min="0"<br />
data-max="100"<br />
data-bgcolor="#FF0000"<br />
data-fgcolor="#00FF1A"<br />
class="small readonly"><br />
</div><br />
<br />
<br />
</div><br />
<div class="cell-50 top-align center-align left-space"><br />
<div class="big">Reichweite</div><br />
<br />
<div data-type="knob" data-device="JUDO_iSoft"<br />
data-get="saltRangeInWeeks"<br />
data-unit="w"<br />
data-step="1"<br />
data-min="0"<br />
data-max="52"<br />
data-bgcolor="#FF0000"<br />
data-fgcolor="#00FF1A"<br />
class="small readonly"><br />
</div><br />
<br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserstopp</header><br />
<div class="sheet"> <br />
<div class="row top-space"><br />
<br />
<div class="cell left-align top-align left-space"><br />
<div data-type="symbol" data-device="JUDO_iSoft" data-get="valve"<br />
data-icons='["fa-close","fa-close","oa-sani_water_tap","oa-sani_water_tap"]'<br />
data-get-on='["closed","closing","opening","opened"]'<br />
data-on-colors='["#ad3333","#ff6633","#3399ff","#33ad33"]' class="big compressed"></div><br />
</div><br />
<div class="cell-60 top-align center-align"><br />
<div class="big"><br />
<br />
<div data-type="label"<br />
data-get="valve"<br />
class="valueonly"<br />
data-substitution='["opened","geöffnet","opening","öffnet gerade","closed","geschlossen","closing","schließt gerade"]'<br />
data-device="JUDO_iSoft"<br />
data-color="lightgrey"><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div class="cell left-align top-align left-space"><br />
<div data-type="push" data-device="JUDO_iSoft" data-set-on="CloseValve 1" data-get-on="valve" data-background-icon="fa-stop-circle-o" data-icon="" class="small"></div><br />
<br />
</div><br />
<div class="cell right-align top-align right-space"><br />
<br />
<div data-type="push" data-device="JUDO_iSoft" data-set-on="OpenValve 1" data-get-on="valve" data-background-icon="mi-play_circle_filled" data-icon="" class="small"></div> <br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserhärtegrad</header><br />
<br />
<div class="sheet"><br />
<div class="row"> <br />
<br />
<div class="cell-20 center-align top-align left-space"><br />
<div data-type="symbol"<br />
data-device="JUDO_iSoft"<br />
data-icon="none"<br />
data-color='none'<br />
data-height="100"<br />
data-background-icon="fa-circle"<br />
data-background-colors='["red","blue"]'<br />
data-limits='["0","1"]'><br />
<div data-type="label"<br />
data-get="natural-hardness"<br />
data-unit="&deg;h"<br />
class="valueonly"<br />
data-device="JUDO_iSoft"<br />
data-color="lightgrey"><br />
</div><br />
</div><br />
</div><br />
<br />
<div class="cell-20 top-align center-align left-space"><br />
<div data-type="image" data-size="50%" data-url="images/judo.png"></div><br />
</div><br />
<br />
<div class="cell-60 top-align center-align left-space"><br />
<br />
<div data-type="spinner"<br />
data-device="JUDO_iSoft"<br />
data-get="residual-hardness"<br />
data-set="residual-hardness"<br />
data-min=5"<br />
data-max="12"<br />
data-step="1"<br />
data-unit="&deg;h"<br />
data-longdelay="800"<br />
data-width="200"<br />
data-height="60"<br />
data-icon-left-color="blue"<br />
data-icon-right-color="red"<br />
<br />
class="valueonly"><br />
<br />
</div><br />
</div><br />
</div><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div class="vbox phone-width"><br />
<div class="card lift"><br />
<header>Wasserverbrauch</header><br />
<section> <br />
<div id="JUDO_iSoft"<br />
data-type="highchart"<br />
data-device="JUDO_iSoft"<br />
data-logdevice="FileLog_JUDO_ISoft"<br />
data-columnspec="4:water-current"<br />
data-style="ftui l0fill"<br />
data-linenames="Verbrauch"<br />
data-linetypes="line"<br />
data-yaxis="0,1"<br />
data-height="300"<br />
data-xunit="Uhrzeit"<br />
data-yunit="l"<br />
data-tooltip="{series.name} <b>{point.y:,.1f}</b>"<br />
data-daysago="7"<br />
data-yticks="auto"<br />
data-legendalign="right"><br />
<br />
</section><br />
<br />
</div<br />
</div><br />
</div><br />
</pre><br />
== Ähnliche Systeme ==<br />
<br />
== Projekte der FHEM-Community ==<br />
<br />
== Links ==<br />
* {{Link2Forum|Topic=56455|Message=800960}}<br />
* [https://blog.muwave.de/2017/06/monitoring-and-controlling-a-judo-i-soft-plus-water-softening-device-via-lan/ ursprünglicher Beitrag bzgl. des verwendeten Protokolls]<br />
<br />
<br />
[[Kategorie:IP Components]]<br />
[[Kategorie:Other Components]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Trick_der_Woche&diff=29919Trick der Woche2019-03-16T17:10:07Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>Diese Seite enthält Tipps und Tricks, die zu unbedeutend sind, einen eigenen Artikel zu rechtfertigen, alternative Schreibweisen/Lösungen für eine Problem darstellen, Ungenauigkeiten oder unklare Formulierungen in den offiziellen Dokumenten ergänzen und ähnliches. Jeder Eintrag ist typischerweise sehr kurz (wenige Zeilen lang) und beleuchtet vielleicht nur einen Aspekt von FHEM, er kann allgemeiner Natur sein, oder sich auf ein spezielles Gerät oder einen speziellen Anwendungsfall beziehen.<br />
<br />
== Februar 2019 ==<br />
=== Unterräume anlegen ===<br />
[[Datei:Unterraeume.png|350px|thumb|right|Beispiel für einen gegliederten Raum "Steuerung"]]<br />
In [[FHEMWEB]] besteht neben der Möglichkeit, Geräte dadurch übersichtlich anzuordnen, indem diese Gruppen und einfachen Räumen zugeordnet werden, auch die Möglichkeit, Räume weiter zu gliedern und Unterräume zu verwenden. Dazu wird nach der Angabe des Hauptraums der Unterraum, getrennt durch ein "->" angegeben. Beispiele:<br />
attr <DEVICENAME> room Steuerung->Logik<br />
attr <DEVICENAME> room Steuerung->Heizung<br />
== Januar 2019 ==<br />
=== HomeMatic IP ===<br />
Das [[HomeMatic IP]]-Protokoll unterscheidet sich deutlich vom bisherigen HomeMatic Protokoll, im Grunde ist es ein anderes System, das nur dem Namen nach dem älteren HomeMatic gleicht. HM-IP Geräte können aktuell (Anfang 2019) nur über eine systemeigene Zentrale CCU2 (als physisch vorhandenes Interface) und die HomeMatic-Module in FHEM integriert werden, sind in FHEM jedoch '''nicht''' unmittelbar als Homematic-Geräte ansprechbar.<br />
<br />
<br />
== Dezember 2018 ==<br />
===HomeMatic Heizungsregler Uhrzeit einstellen===<br />
HomeMatic Thermostate / Heizungsregler wie der HM-CC-TC der der HM-TC-IT-WM-W-EU etc. synchronisieren ihre Uhrzeit täglich etwa gegen Mitternacht mit der Zentrale. Man kann dieses Update aber jederzeit erzingen durch den Befehl <br />
set <DEVICENAME> sysTime<br />
<br />
== November 2018 ==<br />
===HomeMatic Heizunggeräte gebraucht gekauft===<br />
HomeMatic Heizunggeräte gebraucht gekauft und jetzt lassen sie sich nicht richtig peeren oder pairen?<br />
Das Problem ist meistens, dass die Geräte noch mit der Zentrale des Verkäufers gepairt oder mit anderen Geräten gepeert sind. <br />
Mit Thermostaten wie der [[HM-CC-TC Funk-Wandthermostat]] oder der Nachfolger [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] können mit Ventilantrieben wie dem [[HM-CC-VD Funk-Stellantrieb]] nur gepeert werden, wenn <br />
* die Thermostaten nicht selbst schon mit einer Zentrale (im FHEM Umfeld also z.b. einer [[Virtueller Controller VCCU]] oder [[HM-[[HM-CFG-LAN LAN Konfigurations-Adapter]] oder ähnliches) gepairt wurden<br />
* die Ventilantriebe nicht selbst mit einer Zentrale gepairt oder mit einem Thermostaten gepeert wurden.<br />
<br />
Es ist daher sinnvoll zuerst alle Geräte zurückzusetzen, da viele Verkäufer dies vergessen. Wie das geht steht in der Anleitung.<br />
Beispiele:<br />
* HM-CC-TC -> MENU lange drücken, dann Sonderfunktion "RES" anwählen, mit OK-Taste bestätigen<br />
* HM-CC-VD -> Anlernknopf 10 Sekunden lang drücken. Der Antrieb geht in Zustand A2, nachdem er das Ventil 1x auf- und zugefahren hat geht er in A3, Knopf nochmals drücken.<br />
* HM-TC-IT-WM-W-EU -> Batterien entfernen, alle 3 Tasten gedrückt halten, Batterien einlegen, warten bis "rES" im Display erscheint, Tasten loslassen<br />
<br />
== Januar 2018 ==<br />
=== at absolutem Datum ===<br />
Vielen ist nicht klar, dass man mit dem "define … at" auch einfach ein absolutes Datum definieren kann (obwohl es in der Commandref steht). Anstatt umfangreicher DOIF Konstrukte oder "define … at" die täglich ablaufen und testen ob der gewünschte Tag schon erreicht ist, geht auch ein einfaches:<br />
<br />
define Licht_Neujahr_2019 at 2019-01-03T06:01:01 set Licht1 on<br />
<br />
<br />
Allgemein: <br />
define <name> at [<datespec>] <command> <br />
wobei <datespec> = (YYYY-MM-DDTHH:MM:SS) (also in ISO8601 Schreibweise).<br />
Wichtig ist die Angabe mit Sekunden, die nicht weggelassen werden können.<br />
<br />
== Dezember 2017 ==<br />
=== perl Version ===<br />
Gelegentlich taucht die Frage auf, welche perl Version zum Betrieb von FHEM minimal erforderlich ist. Bedauerlicherweise lässt sich das aber aktuell nicht definitiv bestimmen.<br />
Rudolf König testet zur Zeit (Ende 2017) mit v5.16 (5 Jahre alt) und v5.24 (ca. 1 Jahr alt). <br />
Sollte sich herausstellen, dass eines seiner Module (vor allem fhem.pl selbst) nicht mit der jeweils ''aktuellen'' perl Version funktioniert, so wird das Modul entsprechend kompatibel gemacht.<br />
Andererseits verwendet Rudolf König nach eigener Aussage (bewusst) keine Features, die eine höhere Version als perl 5.8.3 (immerhin älter als 13 Jahre) voraussetzen. Tatsächlich zeigen aktuelle Installation auf relativ alten BuffaloLinkstation Systemen, dass FEHM mit perl 5.8.3 prinzipiell lauffähig ist.<br />
<br />
Rudolf König prüft als Maintainer von fhem.pl aber nicht, welche Mindestversionen andere Entwickler in Ihren Modulen benötigen. Es ist daher möglich oder sogar wahrscheinlich, das einzelne Module höhere Versionen als 5.8.3 benötigen.<br />
<br />
Es gibt aktuell keinen Weg, die Mindestanforderungen z.b. automatisiert zu ermitteln.<br />
<br />
== November 2017 ==<br />
=== Grundlastmodul ===<br />
Mit einem Grundlastmodul ist es möglich, LED Leuchtmittel an einem Schaltaktor / Dimmer zu betreiben. Dies ist bei manchen nicht möglich, da einige LEDs nachglimmen oder flackern. Das Grundlastmodul, welches parallel zum Verbraucher angeschlossen wird, kann diesen Effekt aufheben, da ein Verbraucher mit ohmscher Last simuliert wird.<br />
Eventuell ermöglicht das Modul auch den Betrieb eines [[RSL 2-Draht Einbauschalter]]s, der bei LED Leuchtmitteln ansonsten nicht eingesetzt werden kann.<br />
<br />
== Februar 2017 ==<br />
=== at Zeiten ===<br />
at 03:00 -> 1x um 3 Uhr (wann immer das nächste mal 3 Uhr ist)<br />
at *03:00 -> jeden Tag um 3 Uhr<br />
at +03:00 -> in 3 Stunden<br />
at +*03:00 -> in 3 Stunden und dann alle 3 Stunden erneut<br />
<br />
== Oktober 2016 ==<br />
=== Grundlagen der Heizungssteuerung ===<br />
Der Artikel [[Grundlagen der Heizungssteuerung]] soll einen zentralen Einstiegspunkt und eine Übersicht der Möglichkeiten insb. für Neulinge in FHEM bieten.<br />
<br />
=== Batterieüberwachung für Geräte ohne Batteriestatus ===<br />
Es gibt Möglichkeiten um auch bei Geräten ohne Batteriestatus-Reading eine schwache Batterie erkennen zu können: [[Batterie%C3%BCberwachung#Ger.C3.A4te_ohne_Batteriestatus|Geräte ohne Batteriestatus]].<br />
<br />
== Mai 2016 ==<br />
=== DbLog reparieren ===<br />
Sollte ein fhem mit DbLog Probleme machen, oder auf der SQL-Konsole Fehler werfen, so ist eine Reparatur der DB fällig. Das ist auf der Kommandozeile verhältnismäßig einfach möglich und wird im Kapitel [[DbLog#Datenbank reparieren]] beschrieben.<br />
<br />
=== DbLog bearbeiten ===<br />
Unerwünschte Einträge in den Loggings treten immer wieder mal auf. Wie man dies in einer Datenbank korrigiert, dazu gibt das Kapitel [[DbLog#Bearbeitung von Datenbank-Einträgen]] eine erste Einführung.<br />
<br />
=== Pollenflug ===<br />
In dieser schönen Jahreszeit werden manche durch Heuschnupfen geplagt. Auf der Seite [[Pollenflug]] wird beschrieben, wie man eine Pollenvorhersage in fhem einbinden kann - hilft zwar nicht gegen das Niesen, ist aber trotzdem ganz informativ... ;-)<br />
<br />
== April 2016 ==<br />
=== HomeMatic und VCCU ===<br />
HomeMatic Nutzer sollten unbedingt eine [[Virtueller Controller VCCU|VCCU]] einrichten und nutzen.<br />
Die Einrichtung ist unaufwändig und schafft jede Menge Vorteile, auch beim Einsetzen nur einer Schnittstelle wie z.B. einem [[HM-CFG-LAN LAN Konfigurations-Adapter]]. Auch die nachträglich Einrichtung ist problemlos, sofern vorher nur ein I/O Gerät ("Funkschnittstelle") verwendet wurde.<br />
<br />
== Dezember 2015 ==<br />
===defmod===<br />
In vielen Fällen will man mit einer Aktion gleichzeitig eine andere Aktion bereits für später festlegen, z.b. nach Einschalten einer Heizung durch einen Bewegungsmelder diese eine Stunde später wieder ausschalten.<br />
<br />
Dies kann z.B. durch ein Konstrukt dieser Art erledigt werden:<br />
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code><br />
<br />
Nachteilig ist, dass bei einer weiteren Auslösung des Bewegungsmelders die Heizzeit nicht verlängert wird, da eine Neudefinition von '''reset_Heizung''' mit der Fehlermeldung '''reset_Heizung already exists, delete it first''' quittiert wird. Die Lösung bisher war, das alte '''reset_Heizung''' zunächst zu löschen und dann erneut mit neuem Zeitstempel anzulegen:<br />
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; delete reset_Heizung ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code><br />
Aber auch dieses umständliche Konstrukt hat noch einen Nachteil: Es erzeugt bei einer ersten Auslösung eine Fehlermeldung, weil '''reset_Heizung''' noch nicht exisitert und daher nicht gelöscht werden kann. Dies liesse sich abfangen, was die Konstruktion weiter verkomplizieren würde.<br />
<br />
Daher hat Rudolf König mit FHEM 5.6 den neuen Befehel "defmod" eingeführt, der ein noch nicht existieredendes define neu anlegt (wie "define"), eine bereits vorhandenes aber direkt ändert (wie "delete" und danach "define")<br />
<br />
Dadurch lässt sich verkürzt schreiben:<br />
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; defmod reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code><br />
<br />
<br />
<br />
== April 2015 ==<br />
===FS20 Timer===<br />
FS20 Aktoren beherrschen zwei verschiedene Timer-Methoden.<br />
<br />
Angenommen ein FS20 Device heisse "Lampe" und sei z.B. ein [[FS20_SU_Unterputz-Funk-Schalter|FS20 SU]] (Unterputzschalter), dann kann man mit FHEM sowohl <br />
:<code> set Lampe on-for-timer 30</code><br />
verwenden um die Lampe 30 Sekunden einzuschalten, aber auch zunächst in den FS20 SU die maximale Einschaltdauer einprogrammieren:<br />
:<code> set Lampe timer 30</code><br />
Dannach wird jedes normale<br />
:<code> set Lampe on</code><br />
die Lampe für nur 30 Sekunden einschalten.<br />
<br />
Als Timerwerte kommen in beiden Fällen die bekannten [[Trick_der_Woche#FS20_Timerzeiten|128 Sekundenwerte]] von 0,25 Sekunden bis Etwa 4,5 Stunden in Frage.<br />
<br />
Es ist offenbar nicht bei allen Aktoren möglich einen einmal eingestellten Timer zu löschen, neue Werte eingeben aber sehr wohl.<br />
<br />
Mehr hier: [[FS20_Allgemein#Gerätetimer setzen / löschen|FS20 timer]].<br />
<br />
== Februar 2015 ==<br />
=== 1-wire am GPIO4-Port des RaspberryPi funktioniert nicht mehr nach Systemupdate ===<br />
Es kann passieren, dass nach einem Systemupdate (apt-get update oder apt-get dist-upgrade) die 1-wire-Geräte am GPIO4-Port plötzlich nicht mehr funktionieren. Eine Problemlösung dazu ist im Artikel "[[Raspberry Pi und 1-Wire#1-wire am GPIO4-Port funktioniert nicht mehr nach Systemupdate]]" beschrieben.<br />
<br />
=== Backup der Konfiguration (fhem.cfg und fhem.state) bei jedem "save" ===<br />
Der nachfolgende Codeschnipsel erstellt bei jedem "save" eine Kopie der aktuellen [[Konfiguration]] (fhem.cfg und fhem.state) in ein Verzeichnis "backup_cfg-state" welches unter /opt/fhem/ zu finden ist. Somit kann bei einem Fehler jederzeit auf den letzten Stand zurückgegangen werden.<br />
Zuerst ins FHEM Befehlsfeld den folgenden Befehl eingeben:<br />
:<code>{ `mkdir backup_cfg-state` } </code><br />
<br />
Danach folgendes [[notify]] anlegen:<br />
define backupCfg notify global:SAVE {\<br />
my $now = TimeNow();; $now =~ s/ /_/g;; \<br />
`cp $attr{global}{configfile} ./backup_cfg-state/fhem.cfg.$now`;;\<br />
`cp $attr{global}{statefile} ./backup_cfg-state/fhem.state.$now`;;\<br />
} <br />
<br />
Quelle: {{Link2Forum|Topic=30873|Message=234412|LinkText=FHEM-Forum}}<br />
<br />
== Januar 2015 ==<br />
=== CUL & CO über Serial ID-einbinden ===<br />
Bei mehreren USB-Geräten kann es vorkommen, dass sie vertauscht werden z.B. ''/dev/ttyUSB0'' zu'' /dev/ttyUSB1'' oder ''/dev/ttyACM0'' zu ''/dev/ttyACM1''.<br />
<br />
Um dies zu umgehen, kann man sie über ihre Serial-ID in FHEM einbinden.<br />
<br />
Dieser Befehl zeigt die Serial-ID:<br />
<br />
:<code>ls -l /dev/serial/by-id</code><br />
<br />
Hier die Beispielausgabe eines CUL868, JeeLink, RFXtrx und eines CUL433<br />
<br />
user@xxxx:~# ls -l /dev/serial/by-id<br />
lrwxrwxrwx 1 root root 13 Jan 9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0<br />
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0-> ../../ttyUSB0<br />
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-RFXCOM_RFXtrx433_A1WZWL5Y-if00-port0-> ../../ttyUSB1<br />
lrwxrwxrwx 1 root root 13 Jan 9 21:29 usb-busware.de_CUL433-if00 -> ../../ttyACM1 <br />
<br />
Damit lässt sich folgende Definition erstellen:<br />
<br />
z.B. für einen CUL868<br />
<br />
:<code>define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134</code><br />
<br />
oder einen JeeLink<br />
<br />
:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code><br />
<br />
'''Einschränkung:''' Bei CULs von Busware lassen sich nur CUL433 und CUL868 unterscheiden. Zwei CUL868 haben z.B. immer die gleiche Serial-ID.<br />
<br />
=== HM LAN Konfig-Adapter Antenne verbessern===<br />
Die Antenne des [[HM-CFG-LAN LAN Konfigurations-Adapter]] kann man mit etwas Bastelgeschick verlängern um den Empfang zu verbessern. <br />
<br />
Sinnvoll ist die Verlängerung auf 1/2 Lambda (868MHz = 17,27 cm) oder gar 1 Lambda.<br />
1 Lambda Antennen haben starke Richtwirkung in Form eines gedachten Zylinders, dessen Mittelachse die Antenne ist.<br />
D.h., Alles was sich in Richtung des Anfangs und des Endes des Antennedrahtes befindet, hat schlechteren Empfang als mit einer kurzen Antenne. Daher muss man die Antenne ggf. genauer ausrichten.<br />
<br />
Anleitungen dazu werden an verschiedenen Stellen veröffentlicht, z.B. in <br />
[http://www.ip-symcon.de/forum/threads/18411-Umbau-HM-LAN-Adapter-auf-Lambda-1-2-Dipol-Antenne diesem Beitrag] im IP-Symcon Forum (anders als der Namen der Anleitung vermuten lässt, liegt hier kein Dipol vor, sondern eine "normale" 1 Lambda Antenne.)<br />
<br />
Prinzipiell so dünnen Draht wie möglich verwenden.<br />
<br />
Wer noch mehr rausholen will, kann auch zusätzlichen Aufwand betreiben und die Antenne etwas von der Elektronik entfernen, die nämlich Störstrahlung in die Antenne einkoppelt. Oder eine Groundplane bauen.<br />
Ein Anleitung für die CCU (analog auch für den HM LAN Konfig-Adapter einsetzbar) gibt es [http://www.techwriter.de/beispiel/funkeige.htm hier].<br />
<br />
== Dezember 2014 ==<br />
=== FHT80TF als "Prüfsender" einsetzen ===<br />
Da der [[FHT80TF-2]] günstig ist und seinen Zustand ca. alle zwei Minuten sendet, kann er gut zum Ermitteln der Funklage von [[SlowRF]] Komponenten genutzt werden, auch wenn diese nicht senden. Den RSSI einer FS20 Schaltsteckdose kann man z.B. nicht wissen, da die Dose nur ein Empfänger ist. Wenn eine Dose nicht gut funktioniert und man den Verdacht hat, dass sie funktechnisch ungünstig liegt, kann man einen [[FHT80TF-2]] neben die Steckdose legen und man bekommt nach zwei Minuten einen Wert, der (trotz umgekehrter Funkrichtung) gut genug ist, um einem Hinweise zu geben.<br />
<br />
<br />
== November 2014 ==<br />
=== FS20 Adressschema und die Rolle des Hauscodes ===<br />
[[FS20_Allgemein#FS20_Adressierungsschema_.28Vorschlag.29]]<br />
<br />
<br />
== Oktober 2014 ==<br />
=== Aktor für Wanddosen ohne Nulleiter ===<br />
Es gibt es viele Aktoren die man in Einbaudosen hinter Schaltern einbauen kann. Oft scheitert deren Nutzung aber daran, dass in vielen Elektroinstalltionen in der Einbaudose eines (Licht)schalters kein Neutralleiter (Nulleiter) verlegt ist, den die meisten Aktoren zur eigenen Stromversorgung brauchen. Hier kann der [[RSL 2-Draht Einbauschalter]] helfen, der auch ohne Neutraleiter funktioniert und kompatibel zu InterTechno ist. Er lässt sich z.B. mit einem CUL(433) schalten. Problematisch ist damit allerdings das Schalten von LED Lampen.<br />
<br />
== August 2014 ==<br />
=== Perl-Skripte Online testen ===<br />
Im Internet existieren Webseiten auf denen man Perl-Code online testen kann. Beispielsweise auf [http://www.tutorialspoint.com/execute_perl_online.php codingground] kann man Code zum Testen eingeben und die Auswirkungen betrachten. Dies eignet sich zur schnellen Fehleranalyse oder um Perl zu lernen. Natürlich lassen sich keine FHEM-Besonderheiten nutzen.<br />
<br />
== Juli 2014 ==<br />
=== Funklast reduzieren===<br />
Bewegungsmelder erzeugen in der Regel eine recht hohe Funklast, wenn sie oft ausgelöst werden, also z.B. Licht in einem Zimmer schalten sollen.<br />
<br />
Konstruktionen der Art:<br />
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* set Licht_Flur on-for-timer 256</code><br />
haben daher den Nachteil bei viel Bewegung im Flur und je nach Einstellung des Sendeabstandes des Bewegungsmelders mindestens alle 120 Sekunde oder öfter ein <br />
:<code>on-for-timer 256</code><br />
zu senden. Das erzeugt eine hohe Funklast, speziell wenn der Aktor ein SlowRF Gerät ist (z.B. FS20 Unterputzschalter).<br />
In solchen Fällen kann es helfen, nur dann einen Befehl zu senden, wenn das Licht nicht schon an ist:<br />
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur") eq "off") { fhem ("set Licht_Flur1 on-for-timer 256") } }</code><br />
Nachteilig ist aber, dass eine Auslösung innerhalb 256 Sekunden die Einschaltzeit nicht verlängert. Dies kann man umgehen, indem man nicht on-for-timer verwendet, sondern den Aktor selber verzögert auschaltet und bei weiteren Auslösungen nur die Verzögerung erneut anlegt:<br />
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur1") eq "off") { fhem ("set Licht_Flur on ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") } else { fhem ("delete FlurLicht_aus ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") }}</code><br />
Durch den relativ neuen Befehl "defmod" kann ausserdem das Löschen und neu Anlegen zusammengefasst werden, sieh Tipp Dezember 2015<br />
<br />
== Juni 2014 ==<br />
=== Batteriestatus bei HomeMatic Devices aktivieren===<br />
Zumindest einige (wenn nicht alle) batteriegespeisten HM-Geräte können Batteriemeldungen senden, tun dies in der normalen Konfiguration aber nicht.<br />
Dazu muss das Register cyclicInfoMsg auf on gesetzt werden. <br />
<br />
Wie man das macht steht z.B. hier<br />
[[HM-SEC-SC_Tür-Fensterkontakt#Batteriestatus_aktivieren]]<br />
und hier<br />
[[HomeMatic_Type_ThreeState]]<br />
<br />
== Mai 2014 ==<br />
=== Dummywert mit aktueller Uhrzeit versehen in anderen Dummy kopieren===<br />
Der Inhalt von Dummy1 soll erweitert um Uhrzeit und Datum in Dummy2 kopiert werden (z.B. um die Urzeit der letzten Auslösung einer Alarmanlage anzuzeigen)<br />
:<code>{ fhem("set dummy2 " . (Value("Dummy1")." ".TimeNow()) ) } </code><br />
<br />
=== Zwei Dummywerte in einen anderen Dummy kopieren ===<br />
Der String in Dummy1 soll um den String in Dummy2 erweitert und nach Dummy3 kopiert werden:<br />
:<code>{ fhem("set Dummy3 ".(Value("Dummy1")+Value("Dummy2"))) } </code><br />
(Achtung: "+" ist Zahlen addieren, "." ist String konkatenieren / verketten)<br />
<br />
== April 2014==<br />
=== Code sparen ===<br />
Wer Definitionen wie die aus dem März zum [[Trick der Woche#Zuverlässigkeit von FS20 Schaltungen erhöhen|Abfangen von Fehlbedienungen]] verwendet, kann durch eine ELSE Erweiterung auch gleich das Auschalten erledigen.<br />
:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") } else { fhem("set TV off") } }</code><br />
<br />
Hierdurch schaltet ON oder versehentlich zu langes Drücken (also DIMUP) den Fernseher ein, jeder ''andere'' Tastendruck (also insbesondere die OFF Taste oder zu langes Drücken der OFF Taste -> DIMDOWN) den Fernseher aus.<br />
<br />
Voraussetzung ist, dass die Fernbedienung standardkonfiguriert ist, siehe auch nächster Tip.<br />
<br />
=== Konfiguration eines FS20 Senders prüfen ===<br />
Gelegentlich reagieren bestimmte notifys nicht, die von Sendern (Fernbedienungen, Sensoren oder Schaltern) ausgelöst werden sollen. Speziell bei FS20 aber auch bei HomeMatic kann das daran liegen, dass der Sender nicht sendet was man denkt. So gut wie alle FS20 Sender kennen nämlich nicht nur ON und OFF, sondern über ein Dutzend Schaltzustände. Dimmen ist einem noch hinreichend bewusst, es gibt aber auch exotische Dinge wie Ein-für-Zeitdauer, Ein-auf-alte-Helligkeit, Aus-für-Zeitdauer (nur FS20), Ein-für-Zeitdauer-dannach-alter-Zustand und vieles mehr.<br />
<br />
Was also ein Infrarot-Bewegungsmelder bei Auslösung sendet und auch was eine Fernbedienungstaste sendet ist einstellbar. Wenn jetzt zum Beispiel an einer Fernbedienung auf Tastendruck nicht ON sondern Ein-für-Zeitdauer (ON-FOR-TIMER) gesendet wird, wird<br />
:<code>define act_on_TV_on notify TV:on set TV on</code><br />
seltsamerweise nicht auslösen, obwohl die richtige Taste (und diese auch nicht zu lang) gedrückt wurde.<br />
<br />
Auch wenn man sich sicher ist, das Richtige in die Fernbedienung/Sensoren einprogramiert zu haben, ist ein einfacher Test immer, dies mit<br />
:<code>define act_on_TV notify TV set TV on</code><br />
zu prüfen. Dieses notify löst immer aus, wenn "TV" ''irgendetwas'' sendet, egal was. (Beachte: Man kann dann den Fernseher aber nicht mehr ausschalten, da auch die Austaste das notify auslöst und zum TV-Aktor nur "on" sendet). <br />
<br />
Geht die Schaltung jetzt (kann man den Fernseher also jetzt EINschalten), liegt der Verdacht nahe, dass die Konfiguration des Senders / Sensors anders ist, als man denkt. Das Logfile, der EventMonitor oder ein Beobachtung von FHEM per Telnet mittels "inform" gibt Aufschluss, welcher Befehl tatsächlich empfangen wurde.<br />
<br />
=== Alles in FHEM, nichts in der Fernbedienung ===<br />
Versuche in deiner FHEM Umgebung nicht, das Verhalten von Aktoren durch entsprechende Befehle aus Sensoren oder Fernbedienungen zu steuern. An Besten senden die nur ON und OFF oder DIM, den Rest möglichst immer in FHEM erledigen. <br />
<br />
Wer eine Lampe immer für vier Minuten einschalten will, programmiert seinen Schalter (Fernbedienung) also so, das nur "on" gesendet wird und erledigt den Rest in FHEM:<br />
:<code>define act_on_Schalter notify Schalter set Lampe on-for-timer 240</code><br />
<br />
Vielfach wird argumentiert, das eine dirkete Kopplung die Zuverlässigkeit erhöht, da bei einem Ausfall von FHEM der Aktor totzdem schaltbar sei.<br />
Überlege, ob es hier nicht weniger komplex ist, die Zuverlässigkeit der FHEM Instanz zu erhöhen.<br />
<br />
== März 2014==<br />
=== Zuverlässigkeit von FS20 Schaltungen erhöhen ===<br />
FS20 Fernbedienungen senden bei Tastendrücken von mehr als 0,4 Sekunden anstatt ON bzw. OFF DIMUP bzw DIMDOWN.<br />
<br />
Das führt gelegentlich zu allgemein schlechter Bedienbarkeit (und schlechtem WAF), da 0,4 Sekunden relativ kurz ist und gerne aus versehen länger gedrückt wird. Das ist vor allem problematisch, wenn etwas geschaltet werden soll, was keinen Dimmer hat oder Dimmen nicht unterstützt.<br />
<br />
Eine Konfiguration wie <br />
:<code>define act_on_TV_on notify TV:on set TV on</code><br />
hat also dann den Nachteil, dass bei versehentlich zu langem Tastendruck das TV nicht angeht. Da die meisten Nutzer unbewusst dazu neigen, bei Misserfolg die selbe Taste erneut aber länger zu drücken (was erneut keinen Erfolg zeigt) ist Frustration zu erwarten.<br />
<br />
Es kann daher speziell bei nicht dimmbaren Aktoren von Vorteil sein, auch dimmen abzufangen, z.B. durch eine zweite zusätzliche Definition:<br />
<br />
:<code>define act_on_TV_dimup notify TV:dimup set TV on</code><br />
<br />
Es ist in der Regel einfacher, einige dieser zusätzlichen Definitionen einzufügen, als allen Bedienern des Systems zu erklären, dass man keinesfalls länger als 0,4 Sekunden drücken darf.<br />
<br />
Alternativ kann man auch beide Befehle in einer Definition durch Perlbefehle {} abfangen:<br />
<br />
:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") }}</code><br />
<br />
Andere Möglichkeiten vergleiche: [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|Notify durch mehrere Ereignisse auslösen lassen]]<br />
<br />
== Februar 2014==<br />
=== Sequence nutzen ===<br />
Man kann Aktionen statt mit einem Tastedruck auch mit einer Sequenz von Tastendücken auslösen. Das Format des Befehle ist:<br />
<br />
:<code>define <name> sequence <re1> <timeout1> <re2> [<timeout2> <re3> ...] </code><br />
<br />
wobei <re1> ...<re_n> die Aktionen sind und <timeout_n> der maximale Abstand der Tastendrücke in Sekunden.<br />
<br />
Angenommen, man wolle z.B. eine Lampe dann anschalten, wenn man zuerst Taste1 EIN, dann Taste2 AUS und dann wieder Taste1 EIN einer Fernbedienung drückt, könnte das konkret so aussehen:<br />
<br />
:<code>define MeineLampenSequenz1 sequence Btn1:on 0.5 Btn2:off 0.5 Btn1:on</code><br />
<br />
Zwischen jedem der Tastendrücke darf eine halbe Sekunde Abstand sein. Diese Definition selbst löst die Lampe nicht aus, sondern definiert nur wie die Sequenz aussehen soll. Um die Lampe bei erfolgreicher Betätigung der Sequenz auch einzuschalten, bedarf es zusätzlich etwas wie:<br />
<br />
:<code>define MeineLampe notify MeineLampenSequenz1:trigger set Lampe on</code><br />
<br />
Sequence kann man gut nutzen, um mit einer Fernbedienung mehr Funktionen zu schalten als Tasten zur Verfügung stehen. Ebenso könnte man damit simple Codeschlösser für Alarmanlagen bauen, z.B. um eine Anlage auszuschalten, wenn eine bestimmte Abfolge von Tasten gedrückt wird.<br />
<br />
Je nach Funksystem nimmt die Zuverlässigkeit aber rasch ab. Angenommen im Bereich FS20 (das System ist etwas unzuverlässiger ist als z.B. HomeMatic) seien 95% aller Funktsignale ungestört übertragbar, dann würden in der Praxis von 100 Tastendrücken an einer Fernbedienung 95x Erfolg zeigen und 5x fehlschlagen; das ist sicher tolerabel. <br />
<br />
Bei einer Sequenzlänge von nur 4 Tasten würde die kombinierte Erfolgsquote der Sequenz jedoch nur noch ca. 80% sein, zum Ausschalten einer Alarmanlage vermutlich bereits unpraktisch.<br />
<br />
== Januar 2014==<br />
===isday===<br />
Bekanntlich kann man mit "isday" leicht testen ob es draussen hell ist oder nicht. isday ist eine Funktion des (automatisch geladenen) Moduls [[SUNRISE_EL]], das auch sunset und sunrise enthält.<br />
<br />
Problematisch bei isday ist die fehlende Möglichkeit, Sonnenaufgang und Untergang einzustellen (zumindest wenn man nicht 99_SUNRISE_EL.pm verändern will): isday ist wahr, wenn die Sonne im gegebenen Breitengrad sichtbar ist. Wenn örtliche Gegebenheiten eine Anpassung erfordern, kann man sich auch ein eigenes isday basteln, in dem man sunrise und sunset verwendet und dieses mit getrennten offsets versieht.<br />
<br />
Zuerst definiert man sich eine Variable ("dummy") der anstelle isday eingesetzt werden soll, z.B.:<br />
<br />
:<code>define Tageslicht dummy </code><br />
<br />
Dann wird diese mit sunset und sunrise befüllt:<br />
<br />
define SetDummy1 at *{sunset(-3600)} set Tageslicht hell <br />
define SetDummy2 at *{sunrise(+1800)} set Tageslicht dunkel <br />
<br />
Jetzt kann für jeden Wechsel ein eigener Offset gewählt werden, im Beispiel 3600 Sekunden vor Sonnenuntergang und 1800 Sekunden nach Sonnenaufgang. Anstatt das Dummy "Tageslicht" mit den Werten "hell/dunkel" zu befüllen, kann natürlich auch 1/0 oder "Tag/Nacht" etc. verwendet werden, je nachdem was bei der Anwendung besser passt.<br />
<br />
Für höhere Ansprüche könnte hingegen das [[Twilight]]-Modul verwendet werden, das Dämmerungsstufen kennt.<br />
<br />
===Struktur von "else if" Verzweigungen===<br />
define ... notify ... {\<br />
if ... {\<br />
fhem ("... ;; ...")\<br />
}\<br />
elsif ... {\<br />
fhem ("... ;; ...")\<br />
}\<br />
elsif ... {\<br />
fhem ("... ;; ...")\<br />
}\<br />
else {\<br />
if ... {\<br />
fhem ("... ;; ...")\<br />
}\<br />
}<br />
<br />
Achtung: es muss tatsächlich "elsif" heissen und nicht "elseif" oder "else if".<br />
<br />
Gilt für Perl Aufrufe. <br />
Wer aktuell in FHEM neu einsteigt kann auch den seit 2014 zur Verfügung stehenden FHEM Befehl [[DOIF]] verwenden, der bei ähnlichem Funktionsumfang wir Perl if/elsif übersichtlicher ist.<br />
<br />
== Dezember 2013==<br />
===notify durch mehrere Ereignisse auslösen lassen===<br />
Bekanntermassen löst<br />
<br />
:<code>define irgendwas notify MeinSchalter …</code><br />
<br />
aus, wenn irgendein Ereignis vom Sender "MeinSchalter" eintrifft.<br />
<br />
Mit<br />
<br />
:<code>define irgendwas notify MeinSchalter:on …</code><br />
<br />
wird das notify jedoch nur ausgelöst, wenn dieses Ereignis eine "on" ist.<br />
Wenn man aber möchte, das z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen) kann dies wie folgt erreicht werden:<br />
<br />
:<code>define irgendwas notify MeinSchalter:(on|off) …</code><br />
<br />
Die Klammern sind wichtig, vergleiche eine Lösung, bei der zwei Sender alternativ das notify auslösen können:<br />
<br />
:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter:on …</code><br />
<br />
Selbstverständlich geht z.B. auch folgendes:<br />
<br />
:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter …</code><br />
<br />
Hier wird ausgelöst wenn "MeinSchalter" das Ereignis "on" liefert oder "MeinAndererSchalter" irgendein Ereignis<br />
<br />
=== Aktoren über mehrere Funkschnittstellen ansprechen ===<br />
Falls man mehrere Funkschnittstellen zur Reichweitenverlängerung hat (CUL / CUNO etc), und ein Aktor von beiden Funkschnittstellen in etwa gleich (schlecht) erreichbar ist, mag der Wunsch aufkommen, einen Funkbefehl über beide Schnittstellen auszusenden. Dies ist bei Funkprotokollen möglich, die kein echtes Pairing der Aktoren an die Funkschnittstelle erfordern, also z.B. FS20 oder Intertechno, nicht jedoch ohne weiteres bei HomeMatic.<br />
<br />
Problematisch ist aber, dass die Funkschnittstelle über IODev eindeutige je Aktor festgelegt werden muss, eine Zuordnung mehrerer IODevs ist nicht vorgesehen.<br />
(wenn man IODev nicht setzt, wird per default die LETZTE definiert passende Schnittstelle verwendet)<br />
<br />
Dieses Problem kann mit einem Trick aber umgangen werden. Und zwar legt man den Aktor 2x mit gleicher Adresse aber abweichenden Namen und IOdevs an, z.B. so:<br />
<br />
<br />
define brenner_CUL1 FS20 11114244 11<br />
attr brenner_CUL1 IODev CUL1<br />
attr brenner_CUL2 room Keller<br />
<br />
define brenner_CUL2 FS20 11114244 11<br />
attr brenner_CUL2 IODev CUL2<br />
attr brenner_CUL2 room Keller<br />
<br />
Ein Befehl der Art:<br />
<br />
set brenner_CUL1,brenner_CUL2 on<br />
<br />
sendet den ON Befehl für den FS20 Aktor 11114244 11 jetzt tatsächlich über beide CULs aus!<br />
<br />
Achtung: Wenn die Schnittstellen gleichschnell angebunden sind, sollte vermutlich der [[Sendpool]] verwendet werden, da die Aussendungen sonst tatsächlich gleichzeitig erfolgen könnten und sich dann gegenseitig stören würden. Dieser Trick funktioniert ausserdem nur bei Befehlen, bei denen es im Zweifel egal ist, wenn sie beim Aktor 2x eintreffen. <br />
<br />
Bei HomeMatic lässt sich ein ähnlicher Effekt durch einrichten einer [[Virtueller Controller VCCU|virtuellen CCU]] erreichen.<br />
<br />
=== Retrycount bei FHTs ist überflüssig===<br />
Das von der Funktion ''autocreate'' älterer FHEM Versionen beim Anlegen von FHT80 Heizungsreglern voreingetragene attribute "retrycount" hat in den allermeisten Fällen keine Wirkung, da es NUR greift, wenn man als Funkschnittstelle eine FHZ1X00PC verwendet und dann den Softbuffer einschaltet. Selbst wenn man diese Konfiguration nutzt, will gut überlegt werden, ob die Wirkung postiv ist: Bei ungenügender Empfangslage vergrössert es Kommunikationsprobleme eventuell sogar.<br />
<br />
Es kann also in der Regel entfernt oder auf den Wert "1" gesetzt werden.<br />
<br />
define Heizung_Bad FHT 060d<br />
attr Heizung_Bad retrycount 3 <=== Diese Zeile entfernen<br />
<br />
Siehe auch:[[Kommunikationsprobleme mit FHT]]<br />
<br />
== November 2013 ==<br />
=== FS20 Funksteckdose sicherer schalten===<br />
Seltsamerweise kommt es vor, das FS20 Aktoren - insbesondere die FS20 Funksteckdose - an der Grenze der Funkreichweite bestimmte Befehle eines Typs empfängt, andere aber nicht. Z.B. lässt sich die FS20 Steckdose zwar immer einschalten, aber oft nicht mehr aus (oder umgekehrt).<br />
<br />
Gelegentlich kann man die Zuverlässigkeit erhöhen, indem man statt dem nicht funktionierenden Befehl das Gegenteil mit "for-timer 1" verwendet.<br />
<br />
Im Fall, dass eine FS20 Steckdose sich also einwandfrei EINschalten lässt:<br />
:<code>set SteckdoseA on</code><br />
aber oft ein AUSschalten mittels<br />
:<code>set SteckdoseA off</code><br />
nicht funktioniert, kann man versuchen die Dose anstelle mit "off" mit dem Befehl<br />
:<code>set SteckdoseA on-for-timer 1</code><br />
auszuschalten.<br />
<br />
Analog kann man mit off-for-timer arbeiten, wenn sich Aktoren nicht einschalten lassen, ausschalten aber geht.<br />
<br />
Achtung: Dieser Trick funtioniert ausdrücklich nur, wenn der "on/off-for-timer" Befehl im Aktor selber abgebildet wird. Daher ist der Trick vermutlich nicht auf andere Funksysteme übertragbar. z.B. unterstützt HM nur on-for-timer und Intertechno kennt keinen Timer.<br />
<br />
=== Mehrere Geräte zugleich schalten===<br />
Ein Ereignis soll mehrere Geräte schalten:<br />
<br />
:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on;;set Lampe2 on;;set FunksteckdoseA on</code><br />
<br />
Aus Übersichtlichkeitsgründen können vor und nach den Semikolons auch Leerzeichen eingefügt werden (obwohl in einigen Dokumentation behauptet wird, dies dürfe man nicht machen):<br />
<br />
:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on ;; set Lampe2 on ;; set FunksteckdoseA on</code><br />
<br />
Wenn der Schaltbefehl bei allen Geräten gleich ist, kann man wie folgt zusammenfassen:<br />
<br />
:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1,Lampe2,FunksteckdoseA on</code><br />
<br />
Das Komma wird nicht [[Escapen in Perlbefehlen|escaped]] (verdoppelt), hier darf tatsächlich KEIN Leerzeichen vor oder nach dem Komma eingefügt werden.<br />
<br />
=== Logfileinträge unterdrücken===<br />
Das Attribute "verbose 0" verhindert, dass das Gerät Logfileinträge erzeugt.<br />
<br />
Beispiel:<br />
<br />
define Funksteckdose FS20 22224222 01<br />
attr Funksteckdose verbose 0<br />
<br />
===FHT Lazy Mode benutzen===<br />
Es gibt wenig Gründe, den FHT "Lazy Mode" nicht zu verwenden<br />
define Heizung_Bad FHT 060d<br />
attr Heizung_Bad lazy<br />
<br />
Dieser sorgt dafür, dass Temperaturänderungen (genau genommen alle Änderungen, auch z.B. date) nur übertragen werden, wenn sie nicht sowieso schon am FHT eingestellt sind und veringern die Funklast dadurch deutlich. <br />
<br />
Siehe auch: [[Kommunikationsprobleme mit FHT]]<br />
<br />
== Oktober 2013 ==<br />
=== Zuverlässigkeit von Wiedereinschalten erhöhen ===<br />
Speziell bei FS20 Aktoren ist wegen des fehlenden Rückkanals nicht leicht erkennbar, ob ein Einschaltbefehl Wirkung gezeigt hat. Das bringt einen ganz schlechten WAF, wenn man z.B. mit einem FS20 Aktor eine Heizung ausschaltet und das Wiedereinschalten nach z.B. einer Stunde nicht klappt.<br />
<br />
Hier empfiehlt es sich, das Ausschalten mittels <br />
:<code>set Heizungs_schalter off-for-timer 3584</code> (= fast eine Stunde)<br />
zu erledigen. Da bei FS20 der off-for-timer Befehl im Aktor abgewickelt wird (und nicht durch FHEM), schaltet sich der Aktor auch dann garantiert wieder ein, wenn FHEM abstürzt, eine Funkstörung vorliegt oder ähnliches. Bei Bedarf kann der Befehl off-for-timer zur Verlängerung der Ausschaltzeit wiederholt werden. Dies kann z.B. nötig sein, wenn die Ausschaltung länger als 4,5 Stunden (15360 Sekunden, der Maximalwert des Timers) dauern soll.<br />
<br />
Achtung: dieser Trick funktioniert nur, wenn der Aktor "off-for-timer" selbst beherrscht. FS20 Geräte können das, HomeMatic können aber nur "on-for-timer". Man kann off-for-timer mit HomeMatic trotzdem verwenden, aber in diesem Fall sendet FHEM den Einschaltbefehl nach der Timerzeit. InterTechno, RSL etc, können gar keinen Timer, hier sendet FHEM immer 2 Befehle im passenden Abstand.<br />
<br />
=== FS20 Timerzeiten ===<br />
FS20 Timer werden in Sekunden angegeben. Es sind jedoch nicht alle Werte einstellbar. Da der Timer Wert in 7 Bit übertragen werden muss, sind nur 128 Werte möglich. Um mit diesen Werten im unteren Bereich möglichst fein aufzulösen, andererseits aber auch lange Zeiten zu ermöglichen, ist die Verteilung nicht linear. Einstellbar sind folgende Zeiten in Sekunden;<br />
<br />
0,25 0,5 0,75 1 1,25 1,5 1,75 2 2,25 2,5 2,75 3 3,25 3,5 3,75 <br />
4 4,5 5 5,5 6 6,5 7 7,5 8 9 10 11 12 13 14 15 16 18 20 22 <br />
24 26 28 30 32 36 40 44 48 52 56 60 64 72 80 88 96 104 112 <br />
120 128 144 160 176 192 208 224 240 256 288 320 352 384 416 <br />
448 480 512 576 640 704 768 832 896 960 1024 1152 1280 1408 <br />
1536 1664 1792 1920 2048 2304 2560 2816 3072 3328 3584 3840 4096 <br />
4608 5120 5632 6144 6656 7168 7680 8192 9216 10240 11264 12288 <br />
13312 14336 15360 <br />
(etwas übersichtlicher formatiert auch [[FS20 Allgemein#ON/OFF Befehle mit Time Parameter|hier]]).<br />
<br />
Andere Zeiten werden von FHEM gerundet. Ein neues Setzen des Timer für FS20 löscht den alten Wert.<br />
<br />
[[Kategorie:HOWTOS]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=HMCCU&diff=29766HMCCU2019-03-04T20:05:34Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>{{Baustelle}}<br />
{{Infobox Modul<br />
|ModPurpose=Anbindung HomeMatic CCU an FHEM<br />
|ModType=d<br />
|ModCmdRef=HMCCU<br />
|ModForumArea=HomeMatic<br />
|ModTechName=88_HMCCU.pm <br />
|ModOwner=zap ([https://forum.fhem.de/index.php?action=profile;u=10980 Forum] / [[Benutzer Diskussion:Zap|Wiki]])<br />
}}<br />
<br />
==Einführung==<br />
===Übersicht===<br />
Das Modul HMCCU ermöglicht zusammen mit den Client Modulen → [[HMCCUDEV]], HMCCUCHN und HMCCUPROCRPC eine Integration der HomeMatic CCU Zentrale sowie der dort angelernten Geräte in FHEM. Im Einzelnen werden folgende Funktionen unterstützt:<br />
<br />
* Unterstützt Hard- und Software CCUs inkl. CCU3, YAHM, piVCCU und RaspberryMatic<br />
* Unterstützung der Protokolle BidCos, Wired und [[HomeMatic IP|HM-IP]]<br />
* Unterstützung von CUxD, OSRAM und Philips Hue Devices in der CCU<br />
* Unterstützung von HVL (HomeMatic Virtual Layer)<br />
* Unterstützung von CCU Gerätegruppen bzw. virtuellen Geräten (Heizung, Rauchmelder)<br />
* Automatische Aktualisierung von Gerätezuständen in FHEM per RPC-Server<br />
* Automatische Konvertierung und Skalierung von Werten beim Lesen und Schreiben<br />
* Lesen und Schreiben von CCU Systemvariablen<br />
* Ausführen von CCU Programmen<br />
* Ausführen von HomeMatic Scripts auf der CCU<br />
<br />
Die einzelnen Module haben folgende Aufgaben:<br />
<br />
* HMCCU: Kommunikation zwischen FHEM und CCU (I/O Device)<br />
* HMCCURPCPROC: RPC-Server zum Empfang von Events der CCU<br />
* HMCCUDEV: Definition von FHEM Devices für HomeMatic Geräte<br />
* HMCCUCHN: Definition von FHEM Devices für einzelne Kanäle von HomeMatic Geräten<br />
* HMCCUConf: Templates mit Default Attributen für bestimmte HomeMatic Gerätetypen<br />
<br />
===Geräte, Kanäle und Datenpunkte===<br />
Geräte in der HomeMatic CCU bestehen aus einem oder mehreren Kanälen. Ein Kanal wiederum hat einen oder mehrere Datenpunkte. Über diese Datenpunkte kann ein Gerät gesteuert oder Statusinformationen ausgelesen werden. Sofern ein Datenpunkt lesbar ist, kann er als Reading in einem HMCCUCHN oder HMCCUDEV Device dargestellt werden. Ausgehend von dieser Abbildung in der CCU kann man nun entscheiden, ob man ein CCU Gerät mit HMCCUCHN oder HMCCUDEV definiert.<br />
<br />
Wenn alle benötigten Datenpunkte eines Gerätes über einen Kanal angesprochen werden können, sollte HMCCUCHN verwendet werden. Mit HMCCUDEV werden alle Kanäle eines Gerätes eingebunden. Außerdem unterstützt HMCCUDEV Rauchmeldergruppen sowie virtuelle Geräte wie z.B. Heizungsgruppen.<br />
<br />
Ein Sonderfall ist der Statuskanal 0, der von allen HomeMatic Geräten bereitgestellt wird. Dieser Kanal ist inklusive seiner Datenpunkte sowohl in HMCCUCHN als auch in HMCCUDEV Devices verfügbar.<br />
{{Hinweis|Im Artikel → [[HMCCU Best Practice]] gibt es einige Tipps für den Einstieg inklusive Schritt-für-Schritt Anleitungen.}}<br />
<br />
==Inbetriebnahme==<br />
===Zu beachten===<br />
<br />
* In den CCU Gerätenamen dürfen keine Umlaute verwendet werden. Leerzeichen sind zulässig, können aber u.U. bei einigen Funktionen zu Problemen führen.<br />
* Namen in der CCU müssen über alle Objekttypen hinweg eindeutig sein. Beispiel: Ein Gerät und ein Raum dürfen nicht den gleichen Namen haben.<br />
* Nach dem Neustart der CCU muss auch der RPC-Server neu gestartet werden, da die CCU2 bei einem Neustart die registrierten RPC-Server "vergisst".<br />
* Vor der Ausführung eines FHEM Updates oder vor der Installation eines CCU Firmware Updates muss der RPC-Server gestoppt werden.<br />
* Seit der CCU Firmware 2.27.7 sind die Zugriffsmöglichkeiten auf die CCU durch eine Firewall abgesichert. Der Zugriff durch FHEM muss explizit freigeschaltet werden, da HMCCU sonst nicht korrekt funktioniert (s. nächster Abschnitt).<br />
<br />
===CCU Firewall Einstellungen===<br />
Ab CCU Firmware 2.27.7 sind auf der CCU über das WebGUI folgende Einstellungen vorzunehmen:<br />
* Menü "Einstellungen > Systemsteuerung" aufrufen<br />
* Button "Firewall konfigurieren" anklicken<br />
* Bei "Firewall-Richtlinie" den Eintrag "Ports offen" auswählen, andernfalls müssen die notwendigen Ports im Feld "Port-Freigabe" explizit angegeben werden<br />
* Die Rechte für "HomeMatic XML-RPC API" und "Remote HomeMatic-Script API" auf "Vollzugriff" setzen.<br />
* Man kann die Rechte auf "Eingeschränkter Zugriff" belassen, muss dann aber im Feld "IP-Adressen für eingeschränkten Zugriff" die IP des FHEM-Servers oder das komplette Subnetz in Subnet-Notation angeben.<br />
<br />
Zusätzlich muss in der Systemsteuerung unter "Sicherheit" die Option "Authentifizierung" deaktiviert werden, da HMCCU den Zugriff per Username/Password noch nicht unterstützt.<br />
<br />
===Installation===<br />
Alle HMCCU Module sind Teil von FHEM. HMCCU benötigt die Perl Module RPC::XML::Server und RPC::XML::Client. Unter debian/raspbian kann das Paket librpc-xml-perl installiert werden<br />
<pre>sudo apt-get update && sudo apt-get install -y librpc-xml-perl</pre><br />
<br />
Der interne RPC-Server legt für den Datenaustausch zwischen CCU2 und FHEM Dateien im Verzeichnis /tmp an. Der fhem Prozess benötigt daher Schreibrechte für dieses Verzeichnis. Das Verzeichnis kann mit dem Attribut ''rpcqueue'' geändert werden. Der mit dem Modul HMCCURPCPROC bereitgestellte externe RPC-Server verwendet keine temporären Dateien. Der interne RPC-Server wird ab Version 4.4 nicht mehr unterstützt.<br />
<br />
===Definition I/O Device===<br />
Im ersten Schritt wird ein I/O Device angelegt, das für die Kommunikation zwischen FHEM und der CCU verantwortlich ist. Im folgenden Beispiel wird davon ausgegangen, dass die CCU unter der IP-Adresse 192.168.1.10 erreichbar ist. Das FHEM Device bekommt den Namen „d_ccu“.<br />
<pre>define d_ccu HMCCU 192.168.1.10</pre><br />
Falls die CCU als Software Service auf dem gleichen Rechner läuft wie FHEM, sollte bei der Definition der Parameter ''ccudelay'' angegeben werden. Die CCU Services brauchen beim Starten länger als FHEM. Durch ''ccudelay'' wird der Start von FHEM für die angegebene Anzahl Sekunden verzögert. Die Vorgabe sind 180 Sekunden. Je nach Installation kann auch ein höherer Wert notwendig sein:<br />
<pre>define d_ccu HMCCU 192.168.1.10 ccudelay=180</pre><br />
Durch diese Angabe erfolgt eine verzögerte Initialisierung des I/O Device sowie der FHEM HomeMatic Devices, wenn die CCU beim Start von FHEM nicht erreichbar ist. Der Start von FHEM wird dadurch nicht verzögert. Die verzögerte Initialisierung kann mit dem Parameter ''delayedinit'' erzwungen werden.<br />
<br />
===RPC Server konfigurieren===<br />
Im nächsten Schritt wird der RPC-Server konfiguriert und gestartet. Zunächst werden mit dem Attribut ''rpcinterfaces'' die Schnittstellen bzw. Ports festgelegt, für die sich der RPC-Server bei der CCU registrieren soll. Folgende Angaben sind möglich:<br />
* BidCos-RF<br />
* BidCos-Wired<br />
* HmIP-RF<br />
* CUxD<br />
* Homegear<br />
* HVL<br />
* VirtualDevices<br />
'''Wichtig'''! Die CCU stellt außer BidCos-RF nur die Schnittstellen bereit, für die auch Geräte vorhanden sind. Nicht verwendete Schnittstellen dürfen bei ''rpcinterfaces'' nicht angegeben werden, da sonst der RPC-Server nicht startet. Im Internal "ccuinterfaces" werden nach der Definition des I/O Device alle verfügbaren Schnittstellen angezeigt.<br />
<br />
Danach wird durch Setzen des Attributs ''ccuflags'' auf den Wert procrpc der externe RPC-Server aktiviert. Die Verwendung des internen RPC-Servers ist zwar noch möglich, wird jedoch nicht mehr offiziell unterstützt.<br />
<br />
'''Externer RPC-Server (HMCCURPCPROC)'''<br />
Beim ersten Start dieses RPC-Servers über das I/O Device wird automatisch je Schnittstelle ein Device vom Typ HMCCURPCPROC angelegt. Die Attribute room und group werden vom I/O Device übernommen.<br />
<br />
'''RPC-Server starten'''<br />
Nun kann der RPC-Server gestartet werden. Dabei wird je RPC-Schnittstelle ein separater fhem.pl Prozess mit eigenem Listening-Port gestartet. Beim ersten Start legt HMCCU für jede unter ''rpcinterfaces'' angegebene Schnittstelle ein Device vom Typ HMCCURPCPROC an. Bei aktivierter Firewall müssen die Ports (s. Attribut ''rpcserverport'') geöffnet werden.<br />
<br />
Alle RPC-Server werden über das I/O Device mit einem Befehl gestartet:<br />
<pre>set d_ccu rpcserver on</pre><br />
Während des Starts der RPC-Server und der Registrierung bei der CCU kann das I/O Device nur eingeschränkt verwendet werden. Dies wird durch den Status „starting/busy“ angezeigt. Nachdem die RPC-Server gestartet wurden, wechselt der Status zu „running/OK“. Zusätzlich werden im Internal RPCPID die Prozess-IDs der RPC-Server Prozesse gespeichert.<br />
Anschließend sollte man noch das Attribut ''rpcserver'' auf „on“ setzen, damit die RPC-Server beim Start von FHEM automatisch gestartet werden:<br />
<pre>attr d_ccu rpcserver on</pre><br />
<br />
===Vorgaben für Client Devices===<br />
Im I/O Device stehen einige Attribute zur Verfügung, über die Vorgaben für Attribute in Client-Devices eingestellt werden können:<br />
{| class="wikitable"<br />
|-<br />
! Attribut in HMCCU !! Vorgabe für Attribut in<br/>HMCCUDEV/HMCCUCHN !! Default !! Bedeutung<br />
|-<br />
| ccudef-hmstatevals || hmstatevals || '^UNREACH!(1|true):unreachable;^LOW_?BAT!(1|true):warn_battery' || Legt fest, wie der HomeMatic Status eines Client-Device ermittelt wird.<br />
|-<br />
| ccudef-readingfilter || ccureadingfilter || .* || Legt fest, welche Datenpunkte eines CCU Gerätes als Readings gespeichert werden<br />
|-<br />
| ccudef-readingname || ccureadingname || Kein Default || Ändert den Namen von Readings und/oder ergänzt neue Readings<br />
|-<br />
| ccudef-substitute || substitute || Kein Default || Ersetzt Datenpunktwerte vor der Speicherung in Readings.<br />
|}<br />
Der Inhalt der HMCCU Attribute wird an die Attribute im Client-Device angehängt. In der Datei HMCCUConf.pm ist ein Default-Template für ein HMCCU Device definiert, das über den Befehl '''set defaults''' für das I/O Device angewendet werden kann. Dabei werden die Attribute ''ccudef-*'' auf Werte gesetzt, die Readings und Werte analog zu CUL_HM erzeugen.<br />
<br />
Wichtig! Bei der Ausführung von '''set defaults''' für das I/O Device wird der Reading-Filter auf den Wert "^(LOW_?BAT|UNREACH)$" gesetzt. Dies hat zur Folge, dass in den Client-Devices nur diese beiden Datenpunkte als Readings gespeichert werden. Daher muss für jedes Client-Device über das lokale Attribut ''ccureadingfilter'' eine Liste der zusätzlich benötigten Datenpunkte definiert werden.<br />
<br />
==Synchronisation mit der CCU==<br />
Das Modul HMCCU bietet Befehle an, um Daten zwischen der CCU und FHEM zu synchronisieren. Der Befehl '''get devicelist''' liest alle Geräte aus der CCU. Er sollte immer ausgeführt werden, wenn sich an einer Gerätedefinition in der CCU etwas geändert hat, z.B. Gerät oder Kanal wurde umbenannt, neues Gerät wurde angelernt, Gerät wurde gelöscht. Bei der Definition des I/O Device wird der Befehl automatisch ausgeführt.<br />
<br />
Der Befehl '''get update''' liest die Datenpunkte aller in FHEM definierten HMCCUDEV und HMCCUCHN Devices aus der CCU und aktualisiert alle Readings aller Client Devices.<br />
<br />
==Autocreate von Client Devices==<br />
HMCCU bietet eine Möglichkeit, um automatisch Client Devices in FHEM für Geräte oder Kanäle in der CCU anzulegen. Dazu wird der Befehl '''get devicelist''' mit folgender Syntax aufgerufen:<br />
<pre>get <io-dev> devicelist create <dev-expr> [Options ...] [<attr>=<value [...]]</pre><br />
Der Parameter ''dev-expr'' spezifiziert per regulärem Ausdruck, für welche CCU Geräte oder Kanäle ein Device in FHEM angelegt werden soll. Es ist davon abzuraten, an dieser Stelle ".*" zu verwenden, da so sehr viele (meist unnütze) FHEM Devices angelegt werden.<br />
Folgende ''Options'' sind möglich:<br />
*t={chn|dev|all} - Es werden nur Kanäle (chn) oder Geräte (dev) berücksichtigt (ab 3.6).<br />
*p=<prefix> - Der Text ''prefix'' wird den Namen der neuen FHEM Devices vorangestellt.<br />
*s=<suffix> - Der Text ''suffix'' wird an die Namen der neuen FHEM Devices angehängt.<br />
*f=<format> - Mit ''format'' kann ein Template für die FHEM Devicenamen festgelegt werden. In einem Template können folgende Platzhalter verwendet werden: %n = CCU Geräte- oder Kanalname, %d = CCU Gerätename, %a = CCU Geräte- oder Kanaladresse.<br />
*defattr - Sorgt dafür, dass für die neu definierten FHEM Devices einige Defaultattribute gesetzt werden, sofern für den jeweiligen Gerätetyp vorhanden.<br />
*duplicates - Erlaubt das Anlegen von doppelten Devices. Wenn diese Option fehlt, werden in FHEM vorhandene Geräte nicht neu angelegt.<br />
*save - Nach dem Anlegen der Geräte wird die neue FHEM Konfiguration gespeichert.<br />
An den Befehl kann eine Liste von Attributen angehängt werden, die den neuen FHEM-Devices zugewiesen werden sollen.<br />
<br />
Beispiel: In FHEM Devices für alle CCU Geräte anlegen, deren Namen mit "HM-KL" beginnt. Alle neuen FHEM Devices beginnen mit "HM_". Sofern vorhanden werden Default Attribute gesetzt. Die Konfiguration wird gespeichert.<br />
<pre>get d_ccu devicelist create ^HM-KL.* t=dev f=HM_%n defattr save room=Homematic</pre><br />
<br />
==Verwaltung von Default Attributen==<br />
HMCCU bietet für FHEM Devices vom Typ HMCCUCHN und HMCCUDEV bei bestimmten HomeMatic Gerätetypen Default Attribute an. Diese können in den Client Devices mit dem Befehl '''set defaults''' definiert werden. Der Befehl '''get defaults''' zeigt die für einen Gerätetyp vorhandenen Attribute an. HMCCU bietet jedem Benutzer die Möglichkeit, zusätzlich zu den in der Datei HMCCUConf.pm mitgelieferten Attributen eigene Vorlagendateien mit Default Attributen zu definieren.<br />
<br />
===Anzeigen der Gerätetypen mit Default Attributen===<br />
Mit dem Befehl '''get defaults''' im I/O Device werden alle HomeMatic Gerätetypen angezeigt, für die Default Attribute vorhanden sind. Dabei werden auch benutzerdefinierte Attribute berücksichtigt.<br />
<br />
===Default Attribute exportieren und importieren===<br />
Der Befehl '''get exportdefaults''' schreibt die mitgelieferten Default Attribute aus HMCCUConf.pm in eine Vorlagendatei. Diese Datei kann der Benutzer nach seinen Bedürfnissen anpassen und anschließend mit dem Befehl '''set importdefaults''' in FHEM importieren. Das Anlegen von eigenen Default Attributen könnte so aussehen:<br />
<pre><br />
get d_ccu exportdefaults /opt/fhem/hmccu_defattr.txt<br />
<br />
... Datei /opt/fhem/hmccu_defattr.txt editieren ...<br />
<br />
set d_ccu importdefaults /opt/fhem/hmccu_defattr.txt<br />
</pre><br />
Beim Ausführen des Befehls '''set defaults''' in einem Client Device haben die benutzerdefinierten Attribute Priorität.<br />
<br />
===Benutzerdefinierte Attribute löschen===<br />
Mit dem Befehl '''set cleardefaults''' werden alle mit '''set importdefaults''' importierten Default Attribute gelöscht. Danach sind wieder nur die in HMCCUConf.pm enthaltenen Default Attribute verfügbar.<br />
<br />
==Weitere Funktionen des Moduls HMCCU==<br />
===Lesen und Ändern von CCU Systemvariablen===<br />
Systemvariablen der CCU können mit den Befehlen '''get vars''' und '''set var''' gelesen und geändert werden. Der Befehl '''get vars''' akzeptiert als Parameter einen regulären Ausdruck. Dadurch können mehrere Systemvariablen auf einmal gelesen werden. Nach dem Auslesen einer Systemvariable wird der Wert in einem Reading im I/O Device gespeichert. <br />
<br />
Beispiel: Lesen aller Systemvariablen, die mit A beginnen:<br />
<pre>get d_ccu vars A.*</pre><br />
<br />
Systemvariablen können in regelmäßigen Abständen gelesen werden. Dazu wird mit dem Attribut ccuGetVars ein Intervall und optional ein regulärer Ausdruck für die zu lesenden Systemvariablen festgelegt.<br />
<br />
Beispiel: Lesen aller Systemvariablen alle 60 Sekunden. Im zweiten Befehl werden nur Variablen gelesen, die mit "A" beginnen:<br />
<pre>attr d_ccu ccuGetVars 60<br />
attr d_ccu ccuGetVars 60 ^A</pre><br />
<br />
Wenn eine Systemvariable bereits in der CCU existiert, kann ihr Wert mit dem Befehl '''set var''' geändert werden.<br />
<br />
Beispiel: Setzen der Systemvariablen „Temperatur“ auf den Wert 20.5:<br />
<pre>set d_ccu var Temperatur 20.5</pre><br />
<br />
Mit dem Befehl '''set var''' kann auch eine neue Systemvariable in der CCU angelegt werden. Dazu wird als erster Parameter vor dem Variablennamen der Typ der neuen Variable angegeben. Mögliche Typen sind "bool", "list", "number" oder "text".<br />
<br />
Beispiel: Anlegen einer Textvariablen mit dem Namen "Wetter":<br />
<pre>set d_ccu var text Wetter sonnig</pre><br />
<br />
Optional können noch Attribute für eine neue Systemvariable gesetzt werden. Folgende Attribute sind erlaubt:<br />
<br />
* unit = Einheit<br />
* desc = Beschreibung<br />
* min = Kleinster erlaubter Wert bei numerischen Variablen<br />
* max = Größter erlaubter Wert bei numerischen Variablen<br />
* list = Durch Komma getrennte Liste mit zulässigen Werten bei Listen-Variablen<br />
* valtrue = Angezeigter Wert bei Variablen vom Typ bool, Default = "ist wahr"<br />
* valfalse = Angezeigter Wert bei Variablen vom Typ bool, Default = "ist falsch"<br />
<br />
Beispiel: Anlegen einer numerischen Variablen für Temperaturwerte:<br />
<pre>set d_ccu var number Temperatur 20.5 unit=Grad desc=Aussentemperatur min=-10.0 max=40.0</pre><br />
<br />
===Ausführen von CCU Programmen===<br />
Ein in der CCU2 hinterlegtes Programm kann mit dem Befehl '''set execute''' ausgeführt werden. Einziger Parameter des Befehls ist der Name des Programms. Es spielt keine Rolle, ob das Programm in der CCU aktiv oder inaktiv ist.<br />
<br />
Beispiel: Programm mit dem Namen "Schalter_Ein" ausführen:<br />
<pre>set d_ccu execute Schalter_Ein</pre><br />
<br />
===Aggregation von Gerätezuständen (ab 3.6)===<br />
Hinter diesem etwas kryptischen Begriff verbirgt sich die Zusammenfassung von Zuständen von Client-Devices. Anwendungsbeispiele sind:<br />
* Wieviele und welche Geräte haben einen niedrigen Batteriestand?<br />
* Wieviele und welche Fenster sind geöffnet?<br />
Für die Beantwortung dieser Fragen stellt HMCCU einige Befehle und Attribute bereit. Die Ergebnisse werden in Form von Readings im I/O Device bereitgestellt:<br />
*''Präfix''_count = Anzahl der FHEM Devices, die für die Aggregation ausgewertet wurden.<br />
*''Präfix''_list = Liste der FHEM Devices, die der if Bedingung Aggregationsregel entsprechen.<br />
*''Präfix''_match - Anzahl der FHEM Devices, die der if Bedingung der Aggregationsregel entsprechen.<br />
*''Präfix''_state - Ergebnis der Aggregationsregel (if oder else Wert).<br />
Aggregationen werden automatisch bei Änderung von Readings neu berechnet. Alternativ kann mit dem Befehl '''get aggregation''' eine Aggregation explizit durchgeführt werden. Als Parameter wird der Name der Aggregationsregel oder "all" für alle Aggregationen übergeben:<br />
<pre>get <io-dev> aggregation {all|<name>}</pre><br />
Die Konfiguration der Aggregationen erfolgt mit Hilfe von Regeln, die über das Attribut ''ccuaggregate'' definiert werden. Dabei werden mehrere Regeln durch ein Semikolon und optional einen Zeilenumbruch getrennt. Eine Aggregationsregel enthält mehrere, durch Komma getrennte Parameter, die das Verhalten einer Aggregation festlegen:<br />
*'''name''':<Name> - Legt den Namen einer Aggregation fest.<br />
*'''filter''':{name|alias|group|room|type}=<Incl-Expr>[!<Excl-Expr>] - Legt fest, welche Geräte in die Aggregation einbezogen werden:<br />
**name: FHEM Device Name<br />
**alias: FHEM Device Alias<br />
**group: FHEM Device ''group'' Attribut<br />
**room: FHEM Device ''room'' Attribut<br />
**type: HomeMatic Gerätetyp<br />
*'''read''':<Read-Expr> - Legt fest, welche Readings für die Aggregation verwendet werden (z.B. state oder LOWBAT).<br />
*'''if''':{any|all}=<Value> - Legt die Bedingung fest, unter der die Aggregationsregel greift:<br />
**any: Regel greift, wenn das Reading mindestens eins der über ''Filter'' selektierten FHEM Devices den Wert ''Value'' hat.<br />
**all: Regel greift, wenn die Readings aller der über ''Filter'' selektierten FHEM Devices den Wert ''Value'' haben.<br />
*'''else''':<Value><br />
*'''prefix''':{RULE|<Text>} - Legt das Präfix für die Readings fest, die das Ergebnis einer Aggregation beinhalten wobei "RULE" für den Namen der Aggregationsregel steht.<br />
*'''coll''':{NAME|<Attribute>}[!<Default>] - Legt fest, welches Attribut der FHEM Devices, die in die Aggregation einbezogen werden, in das _list Reading aufgenommen werden, sofern sie die if Bedingung erfüllen. Dabei entspricht "NAME" dem FHEM-Devicename. Der optionale Parameter Default legt den Inhalt des _list Readings fest, wenn keines der FHEM Devices die if Bedingung erfüllt. Voreingestellt ist "no match".<br />
<br />
Beispiel: Aggregation der Batteriezustände aller HomeMatic Geräte in FHEM (Annahme: Alle gehören zum Raum "Homematic"):<br />
<pre><br />
attr d_ccu ccuaggregate name:battery,filter:room=Homematic,read:(LOWBAT|LOW_BAT),if:any=yes,else:no,prefix=battery_,coll:alias<br />
</pre><br />
Diese Aggregationsregel könnte folgende Readings im I/O Device generieren (Annahme: Batterien von 2 Fenstersensoren leer):<br />
<pre><br />
battery_count: 50<br />
battery_list: Fenster Bad,Fenster Wohnzimmer<br />
battery_match: 2<br />
battery_state: yes<br />
</pre><br />
<br />
===Ausführen von HomeMatic Scripts===<br />
Mit dem Befehl '''set hmscript''' kann ein beliebiges HomeMatic Script an die CCU2 zur Ausführung gesendet werden. Wenn das Script zeilenweise Daten im Format "Parameter=Value" zurück gibt, werden diese als Readings mit dem Namen ''Parameter" im I/O Device gespeichert.<br />
<br />
Beispiel: Das folgende HomeMatic Script wertet alle CCU2 Systemvariablen aus. Das Ergebnis wird als Readings gespeichert (äquivalent zu Befehl '''get vars'''):<br />
<pre><br />
object osysvar;<br />
string ssysvarid;<br />
foreach (ssysvarid, dom.GetObject(ID_SYSTEM_VARIABLES).EnumUsedIDs())<br />
{<br />
osysvar = dom.GetObject(ssysvarid);<br />
WriteLine (osysvar.Name() # "=" # osysvar.Value());<br />
}<br />
</pre><br />
<br />
Wenn das Script auf dem FHEM-Server unter /opt/fhem/sysvars.scr gespeichert wird, kann es wie folgt ausgeführt werden:<br />
<br />
<pre>set d_ccu hmscript /opt/fhem/sysvars.scr</pre><br />
<br />
[[Kategorie:HomeMatic Components]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Notify&diff=29765Notify2019-03-04T19:58:32Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>{{SEITENTITEL:notify}}<br />
{{Infobox Modul<br />
|ModPurpose=Ausführung von Anweisung(en) als Reaktion auf Ereignisse<br />
|ModType=h<br />
|ModCmdRef=notify<br />
|ModForumArea=Automatisierung<br />
|ModTechName=91_notify.pm<br />
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])<br />
}}<br />
== Einführung ==<br />
{{Hinweis|Weitere grundlegende Informationen/Beispiele zu notify enthält [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM]}}<br />
Das Hilfsmodul notify dient dazu [[Ereignis|Ereignisse]] über ein Suchmuster zu erkennen und bei einem Treffer eine Aktion auszulösen. Mit ''notify'' und anderen [[Eventhandler|Eventhandlern]] <ref>hierzu gehören u.a. auch [[DOIF]], [[THRESHOLD]] und [[watchdog]]</ref> ist es möglich, Logikfunktionen im FHEM abzubilden.<br />
<br />
'''Beispiele:''' <br />
* Wird das Licht in der Küche eingeschaltet, soll FHEM dort auch das Radio einschalten. <br />
* Bei Druck auf einen Taster soll die Umwälzpumpe für das Warmwasser eingeschaltet werden. <br />
* Erweiterte Möglichkeiten: Aber nur, wenn das Radio aus ist bzw. die Temperatur im Rücklauf des Warmwassers unterhalb einer bestimmten Schwelle liegt<ref>vgl. hierzu z.B. {{Link2CmdRef|Anker=devspec|Label=FILTER}} und [[if-condition]]</ref>.<br />
<br />
== Syntax ==<br />
<br />
define <name> notify <Suchmuster> <command> <br />
<br />
Das ''[[Regulärer Ausdruck|Suchmuster]]'' (häufig als Regexp = regular expression = regulärer Ausdruck bezeichnet) ist sehr wichtig: Es ist entweder der Name des auslösenden ("triggernden") Gerätes oder die Kombination aus Gerät und auslösendem Ereignis (Event) <code>Gerätename:Event</code>. Die Events kann man dem [[Event_monitor|Event-Monitor]] entnehmen. Wenn dort z.B. <code>Rollo1</code> steht, dann reagiert ''notify'' auf <code>Rollo1 on</code> und <code>Rollo1 off</code> usw.<br />
<br />
Wenn man mehrere Suchmuster kombinieren möchte, kann man diese in Klammer schreiben, als Trenner wird dann Pipe (|) genutzt: <code>(Rollo1|Rollo2|Steckdose5)</code>.<br />
<br />
'''Auch die Verwendung von Platzhaltern ist möglich''':<br />
* <code>Rollo.</code> → das notify reagiert auf alles was mit Rollo und '''einem''' weiteren beliebigen Zeichen anfängt. Also auf Rollo1 wie auch auf RolloG, aber nicht auf Rollo_wischundweg<br />
* <code>Rollo.*</code> → notify reagiert auf alles das mit Rollo beginnt<br />
* <code>.*isch</code> → auf alles das mit isch aufhört (Tisch, Fisch)<br />
* <code>Schalter(1|2|3)</code> → hört auf Schalter1, Schalter2 und Schalter3<br />
* <code>dimmer:pct:.(100|7[6-9]|[89][0-9])</code> → reagiert, wenn pct einen Wert über 75 annimmt.<br />
<br />
Suchmuster/Regex kann man im Internet beispielsweise auf [http://regexpal.com/| http://regexpal.com/] testen.<br />
<br />
{{Hinweis|Das '''Suchmuster''' wird notify-intern um das Zeichen ^ (beginnt mit) und das Zeichen $ (endet mit) ergänzt<ref>Der Eventhandler [[DOIF]] verwendet die in Perl übliche Syntax für reguläre Ausdrücke als DOIF-Suchmuster.</ref>.<br />
<br />
Deshalb darf das Suchmuster nicht mit einem üblichen [[Regulärer Ausdruck|'''Regulären Ausdruck''']], wie er in Perl<ref>https://perldoc.perl.org/perlre.html</ref> verwendet wird, gleichgesetzt werden, da die Ergänzung zu einem grundsätzlich unterschiedlichen Verhalten führt, siehe nachstehendes Beispiel.}}<br />
<br />
'''Beispiel für das unterschiedliche Verhalten von ''Suchmuster'' und ''regulären Ausdruck'''''<br />
<br />
Für einen '''regulären Audruck''' gilt: Wenn der reguläre Ausdruck ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' zueinander.<br />
<br />
Für das '''Suchmuster''' gilt: Wenn das Suchmuster ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' '''nicht''' zueinander, weil das Suchmuster zu ^lampe$ ergänzt wird und damit exakt nur auf ''lampe'' matcht (passt).<br />
<br />
== FHEMWEB-unterstütztes Anlegen eines notify ==<br />
{{Hinweis|Die Erstellung eines notify und insbesondere die korrekte Angabe des Suchmusters (Regex) führt gerade bei Einsteigern immer wieder zu Schwierigkeiten. Zur Fehlerminimierung empfiehlt es sich zum einen, die [[Konfiguration]] nicht direkt zu bearbeiten, sondern die "Befehl-Eingabezeile", die "Objektdetails" oder den [[Import von Code Snippets|Import von RAW-Definitionen]] zur Bearbeitung zu nutzen.}}<br />
<br />
=== Event Monitor ===<br />
Die komfortabelste Möglichkeit, die häufigsten Event-Handler zu erstellen, bietet der [[Event monitor|Event-Monitor]]. Die Vorgehensweis ist in dem zugehörigen Artikel dargestellt.<br />
<br />
=== Regexp wizard ===<br />
Zudem enthält FHEM einen Regexp wizard mit dem Regex anhand der in FHEM vorhandenen Devices und deren Events aus einer Auswahlbox selektiert werden können. Voraussetzungen sind:<br />
* Aktivierung des Hilfsmoduls [[eventTypes]] (bei allen Neuinstallationen Standard) <br />
* das gesuchte Ereignis (Event) ist nach Aktivierung des Hilfsmoduls bereits mindestens einmal eingetreten<br />
<br />
Schrittweise Darstellung der Nutzung des Regexp wizard zur Anlage eines "notify":<br />
<br />
In das [[Konfiguration#Befehl-Eingabefeld|Befehls-Eingabefeld]] eingeben und mit {{Taste|Enter}} bestätigen:<br />
define ntest notify a b<br />
Als Beispiel wird ein notify mit <name> "ntest" angelegt. "a" und "b" sind beliebige Platzhalter für <Suchmuster> und <Command>, die bei der weiteren Bearbeitung mit dem endgültigen Werten ersetzt werden.<br />
Der Regexp wizard öffnet sich:<br />
[[Datei:Regexp wizard1.JPG|400px|thumb|center]]<br />
Nun in der Auswahlbox das auslösende Event (Ereignis) auswählen; zunächst das Device und dann das gewünschte Regex. Hier soll das notify bei jeder Veränderung der Temperatur (temperature.*) des Device BTHR918N reagieren. Abschließend mit einem Mausklick auf {{Taste|set}} bestätigen. Wählt man mehrere Regex in dieser Weise aus, so wird das "notify" bei Eintritt jedes dieser Events ausgeführt:<br />
[[Datei:Regexp wizard2.JPG|400px|thumb|center]]<br />
Anschließend den Platzhalter "a" mit Klick auf den Link "removeRegexpPart" löschen:<br />
[[Datei:Regexp wizard3.JPG|400px|thumb|center]]<br />
Den Link "DEF" anklicken, damit sich der DEF-Editor öffnet:<br />
[[Datei:Regexp wizard4.JPG|400px|thumb|center]]<br />
Jetzt den auszuführenden Befehl im "DEF"-Bereich durch Überschreiben des Platzhalters "b" eintragen und mit Klick auf {{Taste|modify ntest}} abschließen:<br />
[[Datei:Regexp wizard5.JPG|400px|thumb|center]]<br />
Das fertige und sofort aktive "notify" sieht abschließend folgendermaßen aus:<br />
[[Datei:Regexp wizard6.JPG|400px|thumb|center]]<br />
Am Schluss das Speichern über {{Taste|Save config}} nicht vergessen.<br />
<br />
== Mein notify geht nicht - wie kann ich mir selbst helfen: Debugging ==<br />
<br />
Funktioniert ein notify nicht wie gewünscht, kann es nur zwei Hauptursachen haben: <br />
* Entweder das Suchmuster paßt nicht zum gewünschten Auslöser (FHEM Device), und/oder<br />
* die Anweisung enthält einen Fehler. <br />
Sollte kein Fehler im Logfile auftauchen aber das notify ausgelöst werden, stimmt meist der Übertragungsweg zum Zieldevice nicht.<br />
Der STATE des notify zeigt normalerweise mit Datum/Uhrzeit die letzte Auslösung an.<br />
<br />
Beim Debuggen sollte man daher beide Elemente getrennt untersuchen. Hier ein Beispiel welches nicht wie gewünscht funktioniert:<br />
<source lang="perl"> define n_test notify n_test:muster Ausführungsteil</source><br />
Zum debuggen benötigen wir <br />
* den [[Event monitor]]<br />
* das [https://fhem.de/commandref.html#trigger trigger-Kommando] - kann man jederzeit verwenden um das Suchmuster als Event unabhängig vom Auslöser zu erzeugen.<br />
* die FHEM Kommandozeile<br />
* den [[DEF-Editor]]<br />
* eventuell einen Texteditor um Codeblöcke zwischen zu lagern und Notizen zu machen.<br />
<br />
Das Suchmuster im Beispiel notify triggert auf sich selbst, es soll auf jeden Event mit dem Inhalt '''muster''' ausgelöst werden, Beispiel:<br />
2018-07-14 14:31:03 notify n_test muster bild<br />
<br />
=== Suchmuster ===<br />
Sollte das notify nicht funktionieren:<br />
* keine Reaktion wie gewünscht<br />
* keine Fehlermeldung in der Weboberfläche beim Anlegen, keine Fehlermeldung im Logfile<br />
* STATE ist unverändert auf active oder einem altem Datum/Uhrzeit<br />
liegt der Fehler mit Sicherheit im Suchmuster. Man hat die Chance das Suchmuster mit dem trigger Befehl zu erzeugen und zu schauen ob die Anweisung ausgeführt wird. Dabei ist zu beachten: Der erste ":" im Suchmuster ist zusätzlich zwischen Gerät und Event als Trennung. Jeder weiter : ist, wenn vorhanden, Bestandteil des Events! Siehe dazu den Abschnitt [https://fhem.de/commandref_DE.html#notify Hinweise in der commandref]<br />
*Im Beispiel: Event: n_test muster -> Suchmuster n_test:muster<br />
Um aus dem [[Event]] ein passendes Suchmuster zu erzeugen kann der [[Event monitor|Event-Monitor]] direkt verwendet werden. Man kann ein neues notify erzeugen oder ein Bestehendes modifizieren lassen.<br />
<br />
Unser Regex im Beispiel ist zu spezifisch, es triggert nur exakt auf '''muster'''. Dieser Trigger erzeugt den folgenden Eintrag im Eventmonitor, entspricht exakt dem Suchmuster und löst das notify aus:<br />
trigger n_test muster<br />
2018-07-13 11:52:08 notify n_test muster<br />
Das Suchmuster für unsere Anforderung muss in <code>n_test:muster.*</code> geändert werden, damit jeder Event der mit muster beginnt das notify auslöst.<br />
Der . im Regex steht für jedes beliebige Zeichen und der * für eine beliebige Anzahl des Zeichens davor: also beliebig viele beliebige Zeichen nach muster.<br />
<br />
Das Suchmuster wird häufig in ein komplizierteres Regex umgewandelt um im notify mehrere Aktionen zu starten. Das eigene Regex kann z.B. mit [http://regexpal.com/| http://regexpal.com/] getestet werden.<br />
<br />
Funktioniert der Auslöser, das notify tut aber noch nicht was es soll, müssen wir die Anweisung untersuchen. In unserem korrigierten Beispiel<br />
<source lang="perl"> defmod n_test notify n_test:muster.* Ausführungsteil</source><br />
folgt beim Kommando <code>trigger n_test muster bild</code> ein Eintrag im Log:<br />
2018.07.13 11:47:57 3: n_test return value: Unknown command Ausführungsteil, try help.<br />
Das notify wurde zwar getriggert aber die Anweisung war nicht ausführbar. <br />
<br />
Ein richtiges Suchmuster und eine fehlerhafte Anweisung wird also normalerweise einen Fehlereintrag im Logfile erzeugen!<br />
<br />
=== Anweisung ===<br />
Wird das notify getriggert, oder will man ganz schnell mal ein notify testen, kann man die Anweisung durch folgenden Code ersetzen, man öffnet also einfach nur die DEF, kopiert den ursprünglichen Inhalt an einen sicheren Ort und ersetzt die Anweisung durch eine der beiden Zeilen. Die erste Zeile kann man auch einfach mal in der Kommandozeile testen:<br />
<source lang="perl">{Log 1, "Das Notify n_test hat ausgeloest."}<br />
{Log 1, "Das Device $NAME hat ausgeloest, der Event sah so aus: $EVENT"}</source><br />
Wird das notify ausgelöst, muss anschließend im Logfile ein Eintrag zu finden sein:<br />
2018.07.13 10:28:57 1: Das Notify n_test hat ausgeloest, der Event sah so aus: muster<br />
Unsere Anweisung <code>Ausführungsteil</code> liefert in der Kommandozeile selbst einen Fehler:<br />
<code>Unknown command Ausführungsteil, try help.</code><br />
Ein Versuch mit geschweiften Klammern <code>{Ausführungsteil}</code> liefert wieder einen Fehler:<br />
<code>Unrecognized character \xC3; marked by <-- HERE after {Ausf<-- HERE near column 6 at (eval 5977) line 1.</code><br />
Diese Variante <code>{"Ausführungsteil"}</code> liefert den String Ausführungsteil ohne Fehler: Das notify arbeitet fehler- aber sinnfrei.<br />
Der fertige Code:<br />
defmod n_test notify n_test:muster.* {"Ausführungsteil"}<br />
<br />
Man kann die Anweisung, normalerweise so wie sie ist, in der FHEM Kommandozeile testen. Sind im Perl Code (in geschweiften Klammern) im DEF Editor Semikolon enthalten muss man diese für den Test in der Kommandozeile (oder Raw Def) verdoppeln.<br />
Laufzeitabhängige Variablen sind in der Kommandozeile meist nicht verfügbar, diese sollte man für den Test einfach durch passende Inhalte austauschen. So kann man die komfortable Variante (loggt den Namen und das komplette Event) nicht in der Kommandozeile ausführen. <br />
<br />
Funktioniert ein FHEM Befehl in der Kommandozeile nicht (z.B. Lampe geht nicht an) kann es im notify auch nicht funktionieren, dann muss die Fehlersuche an anderer Stelle fortgeführt werden. <br />
<br />
Komplexeren Code im Ausführungsteil sollte man beim Testen in Teilabschnitte aufteilen, von der Laufzeit abhängige Variable ($NAME, $EVENT, $EVTPART) durch Strings ("TestWort") ersetzen, die Teilabschnitte separat testen und anschließend schrittweise wieder komplettieren.<br />
<br />
== Beispiele ==<br />
{{Hinweis|Für die nachfolgenden Beispiele wurden einige unterschiedliche Technologien verwendet. Sie können aber recht einfach auf alle anderen Systeme übertragen werden, dabei sollte ggf. darauf geachtet werden, dass sich Schaltbefehle und Events teilweise je nach konkret eingesetzter Technologie unterscheiden können. Dann ist ggf. eine Erweiterung, z.B. durch eine [[if-condition|if-Abfrage]] erforderlich.}}<br />
<br />
=== Etwas schalten, wenn ein anderes Gerät geschaltet wird ===<br />
<br />
==== Vorbedingungen ====<br />
Dieses Beispiel verwendet eine einfache InterTechno-kompatible Funksteckdose für das Radio und einen HM-Aktor für das Licht:<br />
<br />
define RadioKueche IT 000000FFFF 0F F0<br />
define LichtKueche CUL_HM 3A37D6<br />
Beachte: beide kennen als Event bzw. Schaltbefehle ''on'' und ''off''.<br />
<br />
==== notify Befehl ====<br />
<br />
define LichtamRadioan notify LichtKueche set RadioKueche $EVENT <br />
oder alternativ: <br />
define LichtamRadioan notify LichtKueche { fhem "set RadioKueche $EVENT" }<br />
<br />
<br />
==== Erklärung ====<br />
* Der Name des ''notify'' "LichtamRadioan" kann frei gewählt werden, er dient nur dazu, das notify in FHEM eindeutig zu identifizieren.<br />
* "$EVENT" ist ein Platzhalter für den Zustand vom Pattern. $EVENT enthält ein "off" wenn das LichtKueche aus- und ein "on" wenn das Licht eingeschaltet wird.<br />
* "{ &lt;perlcode&gt; }" alles was zwischen {} steht ist Perl code. Perl kennt das Schlüsselwort fhem. Das Schlüsselwort FHEM dient dazu, FHEM Befehle auszuführen. Es wird also der FHEM Befehl "set RadioKueche on/off" ausgeführt. on oder off ist abhängig vom Pattern. Der eigentliche FHEM Befehl muss in " " stehen.<br />
* Wann ist ein Wechsel auf die Perl-Ebene erforderlich? <br />
** einfache FHEM-Befehle sollten in der Regel direkt verwendet werden, dies ist ressourcenschonender.<br />
** Immer dann, wenn dies nicht möglich ist, weil z.B. komplexerer Code ausgeführt werden soll, (blockierende) Prozesse ausgelagert werden sollten oder Systembefehle ausgeführt werden, ist es günstiger, auf die Perl-Ebene zu wechseln <ref>In diesem {{Link2Forum|Topic=88398|Message=808685|LinkText=Forenbeitrag}} wird z.B. erläutert, wie man nichtblockierend externe Scripte aufrufen kann, die dann ihre Ergebnisse wieder an FHEM übergeben.</ref>. <br />
<br />
=== Einschalten von mehreren Geräten/Lampen, wenn das Licht eingeschaltet wird ===<br />
Dieses Beispiel verwendet einen HM-Aktor für das Licht sowie zwei Milight-Birnen, die einzeln geschaltet werden sollen<ref>Dies ist ausdrücklich keine Empfehlung für diese Technologie und der Module</ref> in den Stehlampen:<br />
==== Vorbedingungen ====<br />
<br />
FHEM:<br />
define LichtWZ CUL_HM 3A37D8<br />
define Stehlampe1 MilightDevice RGBW Milight_Wohnzimmer 5<br />
define Stehlampe2 MilightDevice RGBW Milight_Wohnzimmer 6<br />
<br />
==== notify Befehl ====<br />
<br />
define SteckdoseWZein notify LichtWZ set Stehlampe1,Stehlampe2 $EVENT<br />
oder ''in Perl''<br />
define SteckdoseWZein notify LichtWZ { fhem "set Stehlampe1 $EVENT;;set Stehlampe2 $EVENT " } <br />
==== Erklärung ====<br />
Wenn das LichtWZ eingeschaltet wird, dann werden auch die Stehlampen (1 und 2) eingeschaltet.<br />
<br />
=== Einfache ODER Funktion ===<br />
Eine einfache ODER Funktion kann sehr einfach realisiert werden<br />
<br />
==== Vorbereitung ====<br />
KNX:<br />
* 3x GAs der abzufragende Werte (0/0/40 0/0/41 0/0/42)<br />
<br />
FHEM:<br />
define Licht1 CUL_HM 3A37D8<br />
define Licht2 CUL_HM 1B7EC3<br />
define Stehlampe MilightDevice RGBW Milight_Wohnzimmer 7<br />
<br />
==== notify Befehl ====<br />
define SteckdoseWZein notify (Licht1|Licht2) set Stehlampe $EVENT <br />
oder<br />
define SteckdoseWZein notify (Licht.) set Stehlampe $EVENT<br />
<br />
==== Erklärung ====<br />
Die Werte in der Klammer (wichtig ist das »|«) sind die Rückgabewerte. Alternativ kann in diesem Beispiel auch »Licht.« (zu beachten ist der Punkt) geschrieben werden. Der Punkt ist ein Platzhalter für (genau) ein beliebiges Zeichen.<br />
<br />
Danach folgt der set Befehl.<br />
Wenn also das Licht1 oder Licht2 den Wert "on" hat, dann hat auch die Steckdose den Wert "on"<br />
<br />
Alternative: [[structure]]<br />
<br />
=== Einfache UND Funktion ===<br />
Ob man dieses Konstrukt noch als einfach bezeichnen kann, wage ich mal zu bezweifeln. In FHEM fehlen Loggingfunktionen, die man alle selber mit Perl Code erstellen kann (Danke an MAZ).<br />
Dadurch ist FHEM zwar mächtig, wird aber für viele sehr kompliziert.<br />
<br />
In diesem Beispiel soll - wenn drei Rollos geschlossen sind - am Taster eine LED eingeschaltet werden.<br />
<br />
==== Vorbereitung ====<br />
KNX:<br />
* 3x GDs für die Rückgabewert Rollo geschlossen == 1 (0/0/50 0/0/51 0/0/52)<br />
* GD LED am Lichtschalter (0/0/106)<br />
<br />
FHEM:<br />
define R1ZU KNX 0/0/50:dpt1.009<br />
attr R1ZU dummy 1<br />
define R2ZU KNX 0/0/51:dpt1.009<br />
attr R2ZU dummy 1<br />
define R3ZU KNX 0/0/52:dpt1.009<br />
attr R3ZU dummy 1<br />
define LEDalleRolloZu KNX 0/0/106:dpt1<br />
Durch das Attribut dummy werden keine Schaltfunktion angeboten. Es kann nur Werte anzeigen.<br />
<br />
==== notify Befehl ====<br />
define nt.allerolloszu notify (R1ZU|R2ZU|R3ZU) {<br />
my $r1 = Value("R1ZU");;<br />
my $r2 = Value("R2ZU");;<br />
my $r3 = Value("R3ZU");;<br />
if ($r1 eq "on" &amp;&amp; $r2 eq "on" &amp;&amp; $r3 eq "on") {<br />
fhem("set LEDalleRolloZu on");;<br />
} else {<br />
fhem("set LEDalleRolloZu off");;<br />
}<br />
}<br />
<br />
==== Erklärung ====<br />
Es werden die drei Rückgabewerte R1ZU, R2ZU und R3ZU ausgewertet. Danach folgt Perl Code, deswegen beginnt das ganze mit einer { und endet mit }<br />
<br />
my $r1 =&gt; Variable $r1 definieren<br />
= Value("R1ZU");; ==&gt; weist den Rückgabewert (on oder off) von R1ZU der Variable $r1 zu <br />
<br />
Der doppelte ;; ist ein FHEM Thema. Eigentlich würde für Perl ein ; reichen. Aber FHEM nutzt selbst das ; und daher wird ein ;; benötigt. Mit den ersten drei my Zeilen werden die Rückgabewerte den Variablen zugewiesen.<br />
<br />
Danach erfolgt ein normales "if then else" Konstrukt. Die Zeile »($r1 eq "on" &amp;&amp; $r2 eq "on" &amp;&amp; $r3 eq "on")«&#160;kann man so lesen: Wenn $r1 den Wert "on" und (&amp;&amp;) $r2 den Wert "on" und $r3 den Wert "on" dann schalte die LEDalleRolloZu ein {fhem("set LEDalleRolloZu on")}<br />
ansonsten else schalte die LED aus. {fhem("set LEDalleRolloZu off")<br />
<br />
Alternative: [[structure]]<br />
<br />
=== Zeitverzögert schalten ===<br />
{| class="wikitable"<br />
| '''Aufgabe:''' || Zeitverzögert schalten<br />
|- <br />
| '''Beschreibung:''' || Mit einem Notify zeitverzögert eine Aktion auslösen.<br />
|- <br />
| '''Vorbereitung:''' || Gerät "Lampe" ist definiert und es gibt eine Situation, die ein Ereignis "Fernbedienung:.*" generiert.<br />
|-<br />
| '''Befehl:''' || <code>define ntfy1 notify Fernbedienung:.* sleep 7.5;; set Lampe $EVENT</code><br />
|-<br />
| '''Erläuterungen:''' || Bei Eintreten eines Ereignisses "Fernbedienung*" wird nach einer Pause von siebeneinhalb Sekunden der Befehl <set Lampe ??> ausgeführt, wobei der eigentliche Befehl aus dem auslösenden Ereignis übernommen wird.<br />
:''Quelle: {{Link2Forum|Topic=17161|LinkText=FHEM Forum}}''<br />
|}<br />
<br />
<br />
=== Eine PV-Anlage (Solarstrom) zur Steuerung der Rollos nutzen (optional Zeit und Datums abhängig) ===<br />
Hier ein kleines Beispiel, wie man mit Hilfe einer PV-Anlage die Sonneneinstrahlung auf der Südseite ermittelt und dies zur Rolladensteuerung nutzt.<br />
Optional: Die Funktion soll allerdings nur zwischen 9:30 und 17:00 stattfinden. (zweites Beispiel)<br />
Optional: Die Funktion soll nur zwischen dem 6. und 9. Monat funktioneren. (drittes Beispiel)<br />
<br />
==== Vorbereitung ====<br />
PV Anlage mit SolarView abfragen.<br />
Per Hand ermitteln, ab wieviel erzeugtem Strom es sinnvoll ist die Rollos zu schließen.<br />
<br />
==== notify Syntax ====<br />
FHEM:<br />
<br />
define sv SolarView solarview 15000 wr1 wr2 wr3 wr4 <----vier Wechselrichter<br />
attr sv event-on-change-reading currentPower <br />
<br />
define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <br />
if ($EVTPART1 &lt; 3000 ) {<br />
fhem('set Flur1 Auf');<br />
}else {<br />
if ($EVTPART1 &gt; 5000 ) {<br />
fhem('set Flur1 Ab');<br />
} <br />
}<br />
}<br />
<br />
Optional 1: Zeitabhängig<br />
<br />
(sv:currentPower.*) { <br />
my $hm = sprintf("%02d:%02d", $hour, $min);<br />
if ( $hm gt "09:30" &amp;&amp; $hm lt "17:00") { <br />
if ($EVTPART1 &lt; 5000 ) {<br />
fhem('set Flur1 Auf');<br />
}else {<br />
if ($EVTPART1 &gt; 8000 ) {<br />
fhem('set Flur1 Ab');<br />
} <br />
}<br />
}<br />
}<br />
<br />
Optional 2: Zeit und Datum<br />
<br />
(sv:currentPower.*) { <br />
my $hm = sprintf("%02d:%02d", $hour, $min);<br />
if ($month >= 6 &amp;&amp; $month <= 9) {<br />
if ( $hm gt "09:30" &amp;&amp; $hm lt "17:00") { <br />
if ($EVTPART1 &lt; 5000 ) {<br />
fhem('set Flur1,RBUERO1,RBUERO2 Auf');<br />
}else {<br />
if ($EVTPART1 &gt; 8000 ) {<br />
fhem('set Flur1,Flur2,RBUERO1,RBUERO2 Ab');<br />
} <br />
}<br />
}<br />
}<br />
}<br />
<br />
==== Erklärung ====<br />
* Das define wird in der Kommandozeile im Webbrowser eingegeben.<br />
* Anschließend wird im Webbrowser die DEF bearbeitet, das erspart uns Probleme mit Perl<br />
* define sv SolarView ... <==== ist die Schnittstelle vom SolarView<br />
* define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <==== hier wird ein notify angelegt, der auf das "define sv" Wert "currentPower.*" (.* ist irgendwas) reagiert<br />
if ($EVTPART1 &lt; 3000 ) {<br />
fhem('set Flur1 Auf');<br />
}else {<br />
if ($EVTPART1 &gt; 5000 ) {<br />
fhem('set Flur1 Ab');<br />
} <br />
}<br />
}<br />
Diese if-Funktion wertet den Rückgabewert von currentPower aus. Hierbei muss man wissen, dass $EVTPART1 das Split-Ergebnis vom Rückgabewert ist<br />
<br />
Beispiel: Der Rückgabewert (wie im Beispiel) ist "currentPower: 6000".<br />
Jetzt steht im "$EVTPART0 == currentPower:" und im "$EVTPART1 == 6000"<br />
Das bedeutet, dass man sich nicht selbst den richtigen split (Perl Befehl) Aufruf ausdenken muss, dies übernimmt vielmehr FHEM.<br />
<br />
Ergebnis: <br />
Das Rollo wird abhängig von der erzeugten IST_Strommenge auf und zu gefahren.<br />
Damit dies nicht dauernd hin und her pendelt, wurde der Auf Wert sehr klein und den Ab Wert sehr groß gewählt.<br />
<br />
'''Optional 1:''' Der Block "my $hm = sprintf("%02d:%02d", $hour, $min);" erzeugt die String-Variable $hm mit dem Inhalt $hour:$min. %02d begrenzt die Ausgabe auf zwei Stellen.<br />
Danach wird mit "if ( $hm gt "09:30" && $hm lt "17:00")" mit stringvergleichenden Operatoren geprüft, ob die Uhrzeit zwischen 9:30 und 17:00 liegt (lt = kleiner als; gt = größer als). Es wäre auch ein le und ge möglich: le = kleiner/gleich als, ge = größer/gleich als.<br />
<br />
'''Optional 2:'''if( $month >= 6 && $month <= 9) {<br />
<br />
Hier wird die numerische FHEM-Standard-Variable $month (Monat) auf größer/gleich bzw kleiner/gleich mit den binären Operatoren überprüft.<br />
Die Funktion arbeitet also nur zwischen dem 6. und dem 9. Monat und dann auch nur zwischen 9:31 und 16:59.<br />
<br />
=== Status eines Kippfensters mit 2 Fensterkontakten abbilden ===<br />
<br />
==== Vorbereitung ====<br />
Es ist je ein Fensterkontakt der ''open'' oder ''closed'' meldet, oben und unten am Fenster angebracht.<br />
Die Namen der beiden FHEM-Devices sind ''fensterKontaktOben'' und ''fensterKontaktUnten''.<br />
<br />
==== notify Syntax ====<br />
FHEM:<br />
define statusFenster notify fensterKontakt(Oben|Unten):(open|closed) {<br />
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')<br />
{ fhem 'set Terrassentuer open' }<br />
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')<br />
{ fhem 'set Terrassentuer closed' }<br />
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')<br />
{ fhem 'set Terrassentuer tilted' }<br />
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')<br />
{ fhem 'set Terrassentuer undef' }<br />
}<br />
<br />
== Weitere Hinweise ==<br />
* Entsprechend zu $EVENT gibt es auch noch $NAME und $TYPE. $NAME und $TYPE enthalten den Namen bzw. Typ des Ereignis auslösenden Gerätes.<br />
* Wird der Perl-Code in einem <code>notify</code> immer länger, lagere den Code wegen der Übersichtlichkeit in eine eigene Programmdatei aus, wie in [[99_myUtils anlegen]] beschrieben.<br />
* Achtung! Wenn man das Skript für den notify-Befehl über mehrere Zeilen schreibt, muss man anscheinend darauf achten, dass keine abschließende Leerzeile mitgespeichert wird. Sonst wird der notify-Befehl ignoriert.<br />
* Dieser {{Link2Forum|Topic=38520|Message=307325}} enthält Vorschläge zur Vorgehensweise bei der Erstellung von komplexen ''notify'' Definitionen bzw. bei deren Fehlerbehebung.<br />
<br />
== Weiterführende Links ==<br />
* [[Escapen in Perlbefehlen]]<br />
* [[Klammerebenen]]<br />
<br />
== Hinweise ==<br />
<references /><br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Hilfsmodul]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=HM-PB-2-WM55_2fach-Funk-Wandtaster&diff=29764HM-PB-2-WM55 2fach-Funk-Wandtaster2019-03-04T19:56:47Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>HomeMatic HM-PB-2-WM55 2fach-Funk-Wandtaster<br />
<br />
== Features ==<br />
<br />
<bitte eintragen><br />
<br />
== Hinweise zur Hardware-Installation ==<br />
Die Integration in FHEM läuft wie mit allen Komponenten. Den LAN-Adapter in FHEM auf hmPairForSec 60 (Zahl bedeutet die Zeit des Zustands in Sekunden und kann beliebig geändert werden) setzen und den Knopf auf der Rückseite des Schalters drücken. Dann sollte der Schalter wie unten dargestellt in FHEM angelegt werden (wird in die fhem.cfg eingetragen). Je nach Einstellungen in {{Link2CmdRef|Anker=autocreate|Label=autocreate}} kann es sein, dass auch noch weitere Aktionen ausgeführt wurden.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
<br />
=== Auszug aus der fhem.cfg ===<br />
Hier der Originaleintrag aus der fhem.cfg der automatisch erstellt wird (mit den "xxx" habe ich meine Nummer erstetzt):<br />
<pre><br />
define CUL_HM_HM_PB_2_WM55_1F1xxx CUL_HM 1F1xxx<br />
attr CUL_HM_HM_PB_2_WM55_1F1xxx .devInfo 020000<br />
attr CUL_HM_HM_PB_2_WM55_1F1xxx .stc 40<br />
attr CUL_HM_HM_PB_2_WM55_1F1xxx firmware 1.1<br />
attr CUL_HM_HM_PB_2_WM55_1F1xxx model HM-PB-2-WM55<br />
attr CUL_HM_HM_PB_2_WM55_1F1xxx room Bad<br />
attr CUL_HM_HM_PB_2_WM55_1F1xxx serialNr KEQ003xxx<br />
attr CUL_HM_HM_PB_2_WM55_1F1xxx subType pushButton<br />
define FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx FileLog ./log/CUL_HM_HM_PB_2_WM55_1F1xxx-%Y.log CUL_HM_HM_PB_2_WM55_1F1xxx<br />
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx logtype text<br />
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx room CUL_HM<br />
define CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 CUL_HM 1F1xxx01<br />
attr CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 model HM-PB-2-WM55<br />
attr CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 room CUL_HM<br />
define FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 FileLog ./log/CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01-%Y.log CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01<br />
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 logtype text<br />
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 room CUL_HM<br />
define CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 CUL_HM 1F1xxx02<br />
attr CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 model HM-PB-2-WM55<br />
attr CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 room CUL_HM<br />
define FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 FileLog ./log/CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02-%Y.log CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02<br />
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 logtype text<br />
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 room CUL_HM<br />
</pre><br />
<br />
=== Bearbeiten ===<br />
Das ist der Standardeintrag, den FHEM automatisch erstellt. Es macht aber Sinn, einiges zu verändern.<br />
Zum einen sollten die Entities umbenannt werden, um sie besser finden und somit bedienen zu können. Das geht entweder manuell in der fhem.cfg (suche "CUL_HM_HM_PB_2_WM55_1F1xxx" ersetze mit neuem Begriff) oder besser per Befehl:<br />
<pre><br />
rename CUL_HM_HM_PB_2_WM55_1F1xxx LichtFlurDev<br />
rename CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 LichtFlur1<br />
rename CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 LichtFlur2<br />
</pre><br />
<br />
Auch ist es nicht sinnvoll, für jede Entity (in diesem Fall 3: Schalter und die beiden Knöpfe) je ein eigenes Logfile anzulegen, auch wenn autocreate das so macht, denn das kostet Performance und Übersichtlichkeit. Das Beispiel unten zeigt, wie die Ereignisse aller drei Entities mitgeschrieben werden - achtet auf das .* am Ende:<br />
<br />
<pre><br />
define FileLog_LichtFlur FileLog ./log/LichtFlur-%Y.log LichtFlur.*<br />
attr FileLog_LichtFlur logtype text<br />
attr FileLog_LichtFlur room CUL_HM<br />
</pre><br />
<br />
Und jetzt natürlich noch aufräumen und die alten Logfiles entsorgen:<br />
<pre><br />
delete FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx<br />
delete FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01<br />
delete FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02<br />
</pre><br />
<br />
'''Wichtig:''' Folgende Attribute solltet ihr '''nicht ändern''': .devInfo, .stc, model, firmware, serialNr, subType<br />
<br />
Weitere interessante Attribute, die man nutzen sollte (siehe auch {{Link2CmdRef}}) sind: room, group, expert, webCmd: gruppieren und darstellen auf der Webseite, autoRegRead: automatisches Lesen der Register (für push-Button sollte es auf 0 stehen)<br />
<br />
Letztendlich könnte die "gepflegte" fhem.cfg so aussehen:<br />
<pre><br />
#====== Das Device<br />
define LichtFlurDev CUL_HM 1F1xxx<br />
attr LichtFlurDev .devInfo 020000<br />
attr LichtFlurDev .stc 40<br />
attr LichtFlurDev firmware 1.1<br />
attr LichtFlurDev model HM-PB-2-WM55<br />
attr LichtFlurDev serialNr KEQ003xxx<br />
attr LichtFlurDev subType pushButton<br />
#--- user Attribute zum Device<br />
attr LichtFlurDev room Flur,Device,Licht<br />
attr LichtFlurDev group Schalter<br />
attr LichtFlurDev webCmd statusRequest:getConfig<br />
attr LichtFlurDev expert 1<br />
attr LichtFlurDev autoRegRead 0<br />
#--- erste Taste<br />
define LichtFlur1 CUL_HM 1F1xxx01<br />
attr LichtFlur1 model HM-PB-2-WM55<br />
attr LichtFlur1 room Flur,Button,Licht<br />
attr LichtFlur1 group Schalter<br />
#--- zweite Taste<br />
define LichtFlur2 CUL_HM 1F1xxx02<br />
attr LichtFlur2 model HM-PB-2-WM55<br />
attr LichtFlur2 room Flur,Button,Licht<br />
attr LichtFlur2 group Schalter<br />
<br />
define FileLog_LichtFlur FileLog ./log/LichtFlur-%Y.log LichtFlur.*<br />
attr FileLog_LichtFlur logtype text<br />
attr FileLog_LichtFlur room logfiles<br />
</pre><br />
<br />
=== Mit virtuellem Aktor verbinden ===<br />
Wenn man den Taster nicht direkt mit einem Aktor verbindet, erhält er keine Rückmeldungen, wird also immer orange und rot blinken, wenn ihr einen Befehl absetzt. Dieser wird zwar von FHEM verarbeitet, FHEM weiß aber nicht, dass es etwas zurückmelden soll. Daher solltet ihr Euch einen virtuellen Aktor anlegen und den Taster dann mit diesem verbinden:<br />
<br />
In der FHEM-Web Oberfläche gebt ihr in der Kommandozeile ein (die hmId kann freigewählt werden, darf aber in echt nicht existieren):<br />
define virtueller_Aktor CUL_HM 123456<br />
sowie:<br />
set virtueller_Aktor virtual 2<br />
<br />
Jetzt habt ihr einen Virtuellen Aktor mit einem Kanal erstellt, jetzt gilt es noch das ganze mit dem realen Taster zu verbinden. Verbunden werden zuerst die Kanäle und dann wird die ganze Konfiguration am Taster gespeichert:<br />
<br />
set LichtFlur1 peerChan 0 virtueller_Aktor_Btn1 single set<br />
set LichtFlur2 peerChan 0 virtueller_Aktor_Btn2 single set<br />
set LichtFlurDev getConfig <br />
<br />
und am Taster einmal Anlernen drücken, ggf. nochmal ein <code>set LichtFlurDev getConfig</code><br />
<br />
<br />
Nun drückt einmal einen Button eures Tasters. Wenn alles geklappt hatte, sollte bei Euren Kanälen im State ein (to virtueller_Aktor_Btn1) dahinter stehen und unter den Attributen etwas in den peerIDs auftauchen. Diesen virtuellen Aktor kann man übrigens als Gegenpart für beliebig viele Taster nehmen, ihr braucht also nicht für jeden Taster einen virtuellen Aktor erstellen. Um den virtuellen Aktor zu erweitern einfach ein <code>set virtueller_Aktor virtual <i>[Gesamtanzahl aller Kanäle]</i></code> ausführen, schon habt ihr weitere Kanäle die ihr mit euren echten Tastern peeren könnt.<br />
<br />
Am Ende unbedingt einmal "Save config" drücken, damit der virtuelle Aktor in der fhem.cfg abgespeichert wird.<br />
<br />
=== Mit Rolladenaktor verbinden (peeren) ===<br />
<br />
Der HM-PB-2-WM55 kann auch z.B. direkt mit einem [[HM-LC-BL1-FM_Funk-Jalousieaktor|HM-LC-BL1-FM Rollladenaktor]] [[Peering (HomeMatic)|gepeert]] werden. Hierdurch lässt er sich ohne FHEM nutzen. Weitere Infos dazu finden Sie [[HM-LC-BL1-FM_Funk-Jalousieaktor#Peeren_mit_einem_HM-PB-2-WM55|hier]].<br />
<br />
== Integration in bestehende Markenschalterprogramme ==<br />
<br />
Obwohl der HM-PB-2-WM55, im Gegensatz zu den Funk-Schaltaktoren für Markenschalter (HM-LC-Sw1PBU-FM, HM-LC-Dim1TPBU-FM und HM-LC-Bl1PBU-FM), eigentlich nicht für die Integration in bestehende Markenschalterprogramme geeignet ist, kann man ihn mit etwas Bastelaufwand doch optisch zumindest etwas integrieren.<br />
<br />
=== Jung CD 500 ===<br />
<br />
Mit Hilfe einer im 3D Drucker selbst gedruckten Adapterplatte und etwas dremeln lässt sich der HM-PB-2-WM55 recht gut in die Jung CD 500 Serie integrieren. Eine bebilderte Anleitung ist [http://www.instructables.com/id/HomeMatic-Wandschalter-mit-Jung-CD500-Blenden hier] zu finden.<br />
<br />
== Probleme ==<br />
<br />
=== Bausatz: Der Taster lässt sich nicht anlernen / rotes Dauerblinken ===<br />
Dann stimmt vermutlich etwas mit der Lötung nicht. Am besten insbesondere die Lötungen des Funkmoduls (8 auf jeder Seite überprüfen).<br />
Am besten mal in der fhem.cfg <br />
<pre><br />
attr LANInterface loglevel 1<br />
</pre><br />
eintragen und dann die Logdatei anschauen, was dort für Funkverkehr aufgezeichnet wird. Euren Schalter könnt ihr identifizieren, indem ihr den kleineren QR-code auf der Platine des Schalters z.B. mit einem Android Handy und Barcoo auslest. Die App zeigt Euch dann den sechsstelligen Gerätecode an (wenn der Code siebenstellig erscheint, dann die erste Ziffer / Buchtstaben weglassen), den ihr in der Logdatei suchen könnt.<br />
<br />
== Links ==<br />
<br />
*[https://files.elv.com/Assets/Produkte/13/1317/131774/Downloads/HM-PB-2-WM55-2_UM_GE_eQ-3_web.pdf: Documentation - HM-PB-2-WM55]<br />
*[http://www.instructables.com/id/HomeMatic-Wandschalter-mit-Jung-CD500-Blenden Instructables.com: Integration in Jung CD 500 Schalterprogramm]<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Schalter (Sender)]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=HM-RC-12_Funkfernbedienung_12_Tasten&diff=29763HM-RC-12 Funkfernbedienung 12 Tasten2019-03-04T19:54:16Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>HomeMatic Fernbedienung mit 12 Tasten, auch in schwarz als HM-RC-12-B .<br />
<br />
Fernbedienung mit 5 Tastenpaaren mit beleuchteten Beschriftungsfeldern. Das sechste Tastenpaar liegt etwas versteckt rechts neben dem 4. und 5. Tastenpaar.<br />
<br />
Die Fernbedienung verfügt außerdem über eine Status-LED, die in den Farben Grün, Rot und Orange leuchten bzw. blinken kann.<br />
== Bedeutung der LED-Farben und -Sequenzen / Fehlercodes ==<br />
Siehe [http://www.homematic-inside.de/tecbase/homematic/generell/item/fehlercodes-und-ihre-bedeutungen Homematic-Link]<br />
<br />
== Anbindung der Fernbedienung an FHEM ==<br />
Wie alle HomeMatic-Komponenten wird die Fernbedienung durch das Modul CUL_HM angebunden. Die Funkverbindung ist mittels einer HomeMatic-CCU, eines [[HMLAN Konfigurator]] oder eines CUL/CUNx/COC etc. im HM-Mode möglich.<br />
Im Weiteren wird 'HMLAN Konfigurator' synonym für alle diese Devices verwendet.<br />
<br />
== Anlernen der Fernbedienung an FHEM ==<br />
# Sicherstellen, dass autocreate aktiv ist.<br />
# HMLAN Konfigurator in den [[Pairing (HomeMatic)|Pairing]]-Modus bringen durch hmPairForSec oder hmPairSerial .<br />
# Den Anlerntaster an der Rückseite der Fernbedienung drücken (bei Verwendung von hmPairForSec innerhalb der angegebenen Zeitspanne). In FHEM wird nun die Fernbedienung als device angelegt. Bevor die Tasten angelernt werden, sollte man zunächst<br />
# das FHEM-device umbenennen durch Verwendung des Befehls <code>rename</code>, im Beispiel ist der neue Name <code>HMremote</code>.<br />
# In Betracht ziehen, das autocreate von ''Filelogs'' (nicht gesamt) zu deaktivieren. Es werden sonst im nächsten Schritt 12 FileLogs (eines je Taste) angelegt, deren Definition bei JEDEM FHEM-event geprüft wird - was nicht ohne Auswirkung auf die Performance bleiben kann. Alternativ kann man die FileLogs auch nach Anlage löschen.<br />
# Erst nach dem Umbenennen den Anlerntaster an der Fernbedienung ein weiteres Mal drücken. Daraufhin werden die 12 Tasten-Kanäle als weitere (Sub)devices in FHEM angelegt. Diese werden mit dem Namen des bei Schritt 3 erzeugten bzw. in Schritt 4 umbenannten devices gefolgt vom Zusatz Btn_x angelegt.<br />
<br />
Die 12 Kanäle heißen in FHEM also &lt;NameDesDevice&gt;Btn_1 .. &lt;NameDesDevice&gt;Btn_12.<br />
<br />
Im device sind diese 12 Subdevices/Kanäle verlinkt über die Attribute channel01 .. channel0C (0C hex = 0x0C = 12dez)<br />
In fhem.cfg sieht das folgendermassen aus:<br />
<br />
<nowiki>define HMremote CUL_HM 11477B<br />
attr HMremote devInfo 0C0000<br />
attr HMremote firmware 1.1<br />
attr HMremote hmClass sender<br />
attr HMremote subType remote<br />
attr HMremote loglevel 5<br />
attr HMremote model HM-RC-12-B<br />
attr HMremote serialNr xxxxxxxxxx<br />
attr HMremote channel_01 HMremoteBtn_1<br />
attr HMremote channel_02 HMremoteBtn_2<br />
attr HMremote channel_03 HMremoteBtn_3<br />
attr HMremote channel_04 HMremoteBtn_4<br />
attr HMremote channel_05 HMremoteBtn_5<br />
attr HMremote channel_06 HMremoteBtn_6<br />
attr HMremote channel_07 HMremoteBtn_7<br />
attr HMremote channel_08 HMremoteBtn_8<br />
attr HMremote channel_09 HMremoteBtn_9<br />
attr HMremote channel_0A HMremoteBtn_10<br />
attr HMremote channel_0B HMremoteBtn_11<br />
attr HMremote channel_0C HMremoteBtn_12<br />
define HMremoteBtn_1 CUL_HM 11477B01<br />
attr HMremoteBtn_1 chanNo 01<br />
attr HMremoteBtn_1 device HMremote<br />
....<br />
define HMremoteBtn_12 CUL_HM 11477B0C<br />
attr HMremoteBtn_12 chanNo 0C<br />
attr HMremoteBtn_12 device HMremote</nowiki><br />
Besonders zu beachten ist die HMid (im Beispiel 11477B). Beim primären Device ist diese 6stellig hexadezimal. Bei den Tasten/Kanälen wird der HMid der zweistellige hexadezimale Kanal angehängt (im Beispiel 11477B'''01'''). Diese HMid bzw HMid+ChannelNo sind in allen ein- und ausgehenden Funktelegrammen zu sehen bzw. bei allen raw-Messages zu verwenden.<br />
<br />
== Pairing ==<br />
Das Pairing der Remote an FHEM kann auf unterschiedlichen Ebenen vorgenommen werden. Folgend eine Übersicht der Alternativen:<br />
<br />
=== Tasten/Kanäle nicht gepaired ===<br />
Wenn die einzelnen Tasten, also die Kanäle, noch nicht gepaired sind, sind Tastendrücke bereits in FHEM sichtbar, als Empfänger erscheint dann (to broadcast):<br />
<br />
<nowiki>2012-10-29 21:57:18.580 CUL_HM HMremoteBtn_7 Short (to broadcast)</nowiki><br />
Nach einem Tastendruck leuchtet die LED an der Fernbedienung kurz orange, um das Senden einer Nachricht zu signalisieren.<br />
Wie bei allen HM-Geräten kann jeder Kanal mit 1..n Kanälen an anderen devices gepaired werden.<br />
<br />
=== Pairing an physischen HM-Aktor ===<br />
Eine RC12 hat zwölf Tasten. Diese sind aus Sicht der Fernbedienung IMMER einzelne Kanäle und kennen sich gegenseitig nicht. Es gibt aber einen Modus in dem die Tasten paarweise verwendet werden - also Taste1 = on, Taste2 = off. Die Fernbedienung weiß davon nichts, sondern nur der Aktor. Der hat dann zwei [[Peering (HomeMatic)|Peers]] auf einem Kanal. Wenn er einen Trigger vom ersten Peer bekommt (Taste 1) wird Aktion 1 ergriffen (also z.B. on). Wenn er einen Trigger von Taste 2 bekommt macht er etwas anderes (also z.B. off)<br />
<br />
Einfacher Lichtschalter:<br />
<br />
<li>Aktion: devicepair single<br />
- FHEM richtet den Aktorchannel auf den RC Kanal als Peer ein<br />
- FHEM richtet den RC channel auf dem Aktorchannel ein - und zwar nur einen<br />
=&gt; Aktion im device: Beim Pairkommando kam ein Kanal =&gt; es wird "toggle" Verhalten programmiert<br />
- Resultat: deine Taste toggelt den Aktorchannel<br />
<li>Aktion: devicepair dual<br />
- FHEM richtet den Aktorchannel auf RC Kanal1 als Peer ein<br />
- FHEM richtet den Aktorchannel auf RC Kanal2 als Peer ein (getrennte Aktion)<br />
- FHEM richtet beide RC channel auf dem Aktorchannel ein - (eine Aktion!)<br />
=&gt; Aktion im Device: Beim Pairkommando kamen 2 Kanäle =&gt; einer wird 'on' Verhalten, der andere 'off' Verhalten bekommen<br />
- Resultat: eine Taste schaltet 'on' , die 2. 'off'<br />
<br />
Das Pairing an einen physischen HM-device ist im Handbuch beschrieben.<br />
<br />
=== Pairing an HMLAN Konfigurator ===<br />
Durch das Pairing der Fernbedienung an einen HMLAN Konfigurator wird erreicht, dass der erfolgreiche Empfang der Nachricht durch den HMLAN Konfigurator mit einem ACK an die Fernbedienung bestätigt wird. Die LED an der Fernbedienung leuchtet nach einem Tastendruck erst orange (Senden des Funktelegramms), dann grün (ACK erhalten) oder rot (NACK bzw. missing ACK).<br />
Da die Fernbedienung in FHEM als 'CUL_HM' läuft, der HMLAN Konfigurator aber als 'HMLAN', ist ein Pairing der beiden Devices in FHEM nicht über einen set-Befehl möglich, da es sich um unterschiedliche Device-Typen handelt.<br />
Das pairing muss daher per raw-Befehl vorgenommen werden.<br />
<br />
<nowiki>set HMremote raw ++A0017853C311477B01017853C30100</nowiki><br />
Der Aufbau der raw-message im Einzelnen: (Erklärung unter Vorbehalt und noch unvollständig)<br />
'''++A001&lt;fhemId&gt;&lt;RCId&gt;&lt;BtnNo&gt;01&lt;fhemId&gt;&lt;Chn&gt;00'''<br />
fhemId= HMId Zentrale (HMLAN Konfigurator/CUL) z.B. 123456<br />
Chn = Channel der Zentrale 01 oder 02... 0A<br />
RCId = HMID remote control<br />
BtnNo = Rc channel (sprich Button) in hex: 01 02 03 oder 0A - bei RC12 max 0C<br />
<br />
++A0013333334444440C013333330100 # Button 12 erhaelt Peer HMLAN (333333) channel 01<br />
<br />
überprüfen mit<br />
<br />
<nowiki>set &lt;rcButtonName&gt; getdevicepair</nowiki><br />
<br />
<br />
=== Pairing an FHEM-dummy ===<br />
Ziel ist, die Fernbedienung nicht an einen HMLAN Konfigurator vom Typ HMLAN, sondern an ein virtuelles Device (dummy) in FHEM anzulernen. Dadurch kommen die Nachrichten von der Fernbedienung direkt auf diesem Device an, außerdem kann gesteuert werden, ob mit ACK oder NACK geantwortet wird, wodurch wiederum die Farbe der LED-Bestätigung gesteuert werden kann.<br />
Der Schaltvorgang auf den virtuellen FHEM Device kann per notify abgehorcht und für indirekte Schaltvorgänge o.Ä. verwendet werden.<br />
<br />
<br />
==== Anlegen des virtuellen Device ====<br />
Zunächst muss das virtuelle (Dummy)-Device in FHEM erzeugt werden:<br />
<br />
<nowiki>define HMvirtual CUL_HM ABC123<br />
attr HMvirtual hmClass receiver<br />
attr HMvirtual subType switch</nowiki><br />
Bei der Vergabe der HMID ist zu beachten, dass der code 6stellig hexadezimal ist. Werden Buchstaben als Bestandteil der HMID gewählt, müssen diese als Großbuchstaben angegeben werden.<br />
<br />
==== Pairing des Remote-Buttons ====<br />
Im Beispiel wird Button2 an das virtuelle Device HMvirtual gekoppelt:<br />
<br />
<nowiki>set HMremoteBtn_2 devicepair 0 HMvirtual single set remote</nowiki><br />
<br />
==== Erzeugen der ACK-Nachricht (work in progress) ====<br />
Zum Versenden des ACK wird ein notify definiert:<br />
<br />
<nowiki>define HManswer notify HMremote.* { HManswer(&quot;%&quot;) }</nowiki><br />
das folgende Routine zB in 99_myUtils.pm aufruft (das geht auch viel kürzer - ist bewusst als lange Version dargestellt, um den Zusammenhang zwischen eintreffender Nachricht und Struktur des zu sendenden raw-ACK zu verdeutlichen):<br />
<br />
<nowiki>## HM Anrufbeantworter für Button2<br />
sub<br />
HManswer($) {<br />
my ($cmdval) = @_;<br />
if ($cmdval =~ m,Btn_2,) {<br />
my $raw = $defs{HMremote}{HMLAN_RAWMSG};<br />
my $msgnr = substr($raw,30,2); # Nummer der eingehenden Nachricht<br />
my $flag = substr($raw,32,2); # flag der eingehenden Nachricht<br />
my $mtyp = substr($raw,34,2); # type der eingehenden Nachricht<br />
my $src = substr($raw,36,6); # Sender der eingehenden Nachricht<br />
my $dst = substr($raw,42,6); # Adressat der eingehenden Nachricht<br />
my $chnl = substr($raw,48,2); # Kanal der eingehenden Nachricht<br />
my $stat = substr($raw,50,2); # Status der eingehenden Nachricht<br />
my $rsp = $msgnr.&quot;80&quot;.&quot;02&quot;.$dst.$src.&quot;00&quot;.$chnl.&quot;000000&quot;; # ACK-message zusammenbauen<br />
Log 1, &quot;in &#160;: &quot;.substr($raw,30,22); # Log nur zum Testem<br />
Log 1, &quot;rsp &#160;: $rsp&quot;; # Log nur zum Testem<br />
fhem &quot;set HMvirtual raw $rsp&quot;; # Senden der response (ACK)<br />
}<br />
}</nowiki><br />
Einschränkungen:<br />
- Das timing der Funkkommunikation ist sehr fragil. Teilweise akzeptiert die remote das gesendete ACK (angezeigt durch grünes LED-Signal) nur, wenn HMLAN hmProtocolEvents &lt;3 hat, zeitweise nur dann, wenn hmProtocolEvents auf 3 steht. Dies ist noch näher zu untersuchen.<br />
- HMvirtual bekommt seinerseits ein missing ACK, das man einfach ignorieren muss<br />
- Vmtl. auf Grund desselben Timing-Problems funktioniert das Quittieren nicht, wenn der nächste Button-press bereits erfolgt, bevor das missing ACK von HMvirtual abgewartet wurde.<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Schalter (Sender)]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=HomeMatic_Peering_Beispiele&diff=29762HomeMatic Peering Beispiele2019-03-04T19:49:35Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>Dieser Artikel beschreibt wie mit FHEM HomeMatic Sensoren und Aktoren gepeert werden können. Peering ist nicht zu verwechseln mit Pairing, d.h. dem Verknüpfen von HomeMatic Geräten mit einer Zentrale (wie beispielsweise FHEM). Details zum Pairing findet man [[HomeMatic_Devices_pairen|'''hier''']].<br />
<br />
= Grundlagen =<br />
Beim ''Peering'' (deutsch sinngemäß: Verbindung von Gleichen) handelt es sich um das Verknüpfen von Kanälen (Channels) verschiedender HomeMatic-Geräte, um diese auch ohne Zentrale kommunizieren zu lassen. Nach dem Peering sendet meist ein Sensorkanal (remote, push-button, Bewegungsmelder,...) einen Trigger an einen Aktorkanal des anderen Gerätes. <br />
Besonderheiten:<br />
* peeren kann man nur Channels, nicht HomeMatic-Geräte. Die Peer-Listen der verschiedenen Kanäle eines Gerätes sind unabhängig voneinander.<br />
* gepeert werden immer ein oder mehrere Sensorkanäle mit einem oder mehreren Aktorkanälen<br />
* der Sensor sendet einen Trigger, evtl. mit einem Zusatzwert. Es ist ''immer'' der Aktorkanal, der festlegt, welche Aktion ergriffen wird. Ein Button kann demnach gleichzeitig ein Einschalter für einen Aktor und ein Ausschalter für einen anderen Aktor sein.<br />
<br />
<br />
{{Hinweis|'''Achtung:''' Das in vielen mitgelieferten HomeMatic-Anleitungen beschriebene Peering von Kanälen ohne Zentrale funktioniert nur, wenn keines der beiden Geräte gepairt ist. Im Folgenden gehen wir davon aus, dass beide Geräte bereits mit einer HomeMatic-Zentrale (z.B. FHEM) [[HomeMatic_Devices_pairen|gepairt]] sind.}}<br />
<br />
== Kommandos ==<br />
<br />
=== peerChan ===<br />
<br />
set <sensChan> peerChan 0 <actChan> [single|dual] [set|unset]<br />
<br />
<code>peerChan</code> peert (verbindet) einen Sensorkanal mit einem Aktorkanal.<br />
Dabei ist <code>&lt;sensChan&gt;</code> der Name des Sensorkanals und <code>&lt;actChan&gt;</code> der Name des Aktorkanals.<br />
<br />
* Mit dem Schlüsselwort ''single'' wird genau dieser Sensorkanal gepeert. <br />
* Mit dem Schlüsselwort ''dual'' werden zwei zusammengehörende Sensorkanäle mit dem Aktorkanal verknüpft. Die beiden Sensorkanäle lösen unterschiedliche Aktionen aus, beispielsweise ''an'' und ''aus''.<br />
* Das Schlüsselwort ''set'' legt das Peering an, das Schlüsselwort ''unset'' hebt es auf.<br />
<br />
Das Kommando unterliegt den allgemeinen [[HomeMatic#Kommunikation|Regeln]]. Es wirkt auf zwei Geräte gleichzeitig, weshalb beide Geräte beobachtet werden sollten – ggf. muss an einem oder beiden Geräten die Anlerntaste gedrückt werden.<br />
<br />
=== peerIODev ===<br />
<br />
set <actChan> peerIODev <IO> <chan> [set|unset]<br />
<br />
<code>peerIODev</code> peert (verbindet) einen Aktorkanal mit einem I/O-Device.<br />
Dabei ist <code>&lt;IO&gt;</code> der Namen des I/O-Devices und <code>&lt;chan&gt;</code> die Nummer des virtuellen Kanals ist. Kanäle von 1 bis 50 sind zulässig.<br />
<br />
=== peerBulk ===<br />
<br />
set <sensChan> peerBulk <peer1,peer2,...><br />
<br />
<code>peerBulk</code> dient der Wiederherstellung einer gesicherten Konfiguration.<br />
Dieser Befehlt erlaubt eine Liste von Peers en-block in ein Gerät zu schreiben. Die Gegenstelle und die Kommunikation der Beiden wird nicht berücksichtigt.<br />
<br />
==Sensoren ==<br />
Ist ein Sensorkanal mit einem Aktorkanal gepeert, gibt es meist nur wenige mögliche Einstellungen. Wichtige Beispiele sind <br />
* Notwendigkeit, den Peer mit einem burst aufzuwecken (Register peerNeedsBurst). <br />
* Erwartung von AES-Verschlüsselung/Authentifizierung (Register expectAES).<br />
<br />
===LED===<br />
Ein ungepeerter Sensorkanal signalisiert einen Tastendruck meist mit gelber LED. Ist der Kanal gepeert, wird mit einer grünen LED signalisiert, dass ALLE Peers den Empfang des Triggers bestätigt (d.h. "ACK" gesendet) haben. Sollten nicht alle Peers eine Bestätigung senden, wird mit einer rot LED quittiert. <br />
<br />
==Aktoren==<br />
Ist ein Sensorkanal mit einem Aktorkanal gepeert, muss im Aktorkanal eingestellt werden, welche Trigger gültig sind und welche Aktionen ergriffen werden sollen. Im Channel wird ein Satz Register angelegt, die als Reading mit '''R-<peername>...''' zusammengefasst sind. Meist sind 2 Gruppen je Peer vorhanden, eine für langen '''lg''' und eine für kurzen '''sh''' Tastendruck. Die Register für long und short sind deckungsgleich, bis auf das Register multiExec in der Gruppe long.<br />
<br />
Für das Setzen des Wertes im Aktorkanal gilt die Syntax<br />
set <actChan> regSet <register> <value> <peername><br />
===Condition Table===<br />
Mit den Registern der Condition Table '''CT''' kann man Trigger filtern. So sendet beispielsweise ein Fensterkontakt einen Trigger mit einem Zusatzwert open=200 oder closed=0. Die CT hat 2 Vergleichswerte, '''Hi''' und '''Lo'''. Der Zusatzwert des Triggers wird entsprechend der Einträge in der CT verglichen. Ist der Schalter z.B. an, dann wird beim Eintrag in '''CtOn''' nachgesehen. Steht dort '''geLo''' wird geprüft, ob der Zusatzwert des triggers größer oder gleich dem Lo-Wert ist. Ist dies nicht der Fall, wird keine Aktion ausgeführt.<br />
Register zur Condition Table sind:<br />
CtDlyOff | literal | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi<br />
CtDlyOn | literal | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi<br />
CtOff | literal | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi<br />
CtOn | literal | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi<br />
CtValHi |0 to 255 | Condition value high for CT table<br />
CtValLo |0 to 255 | Condition value low for CT table<br />
Remotes liefern keinen Zusatzwert. Die Condition Table wird nicht genutzt. <br />
===Jump Table===<br />
In der Jump Table wird zusammen mit ActionType festgelegt, welche Aktion ein gültiger Trigger ausführen soll. Die Aktion ist vom Gerät abhängig.<br />
<br />
===Interne Peers===<br />
Aktoren können eingebaute oder direkt angeschlossene Taster oder Tasteneingänge haben, die auch als Peers verarbeitet werden. Normalerweise sind diese nicht sichtbar, sie können aber durch Absetzen des Befehls <br />
set <device> regSet intKeyVisib visib<br />
sichtbar und einstellbar gemacht werden.<br />
<br />
==Virtuelle Entities==<br />
Soll ein FHEM-Befehl bei einem Aktor nicht nur eine Aktion auslösen, muss er mit einem Kanal einer <u>[[HomeMatic#Virtuelle_Entities|virtuellen Entität]]</u> oder einer <u>[[HomeMatic#IO_Entities|IO Entität]]</u> gepeert werden. Das Peering erfolgt wie bei realen HomeMatic-Geräten. Achtung: da diese virtuellen Peers nicht in einem realen Gerät gespeichert werden, ist nach der Definition ein '''Save config''' nötig. <br /><br />
Dadurch lassen sich nicht nur einfache Befehle je Kanal aussenden, sondern die Peering-Listen in Aktoren nutzen um mit einem Funkbefehl z.B.<br />
*Schleifen zu starten (z.B. bei Alarmauslösung ein Pulsieren der Beleuchtung, alle x Min eine kurze Unterbrechung, ...)<br />
*Abläufe zu starten (z.B. Treppenhauslicht mit Vorwarnung bei Dimmern, ...)<br />
*mehrere Aktoren gleichzeitig schalten zu lassen<br />
Sonst müsste man für jede Zustandsänderung bzw. für jeden Aktor einen eigenen Befehl senden. Somit reagieren mehrere Aktoren auf ein FHEM-Kommando gleichzeitig.<br />
<br />
===IO Entities===<br />
<u>[[HomeMatic#IO_Entities|IO Entities]]</u> sind virtuelle Kanäle eines IO-Devices (z.B. [[Virtueller Controller VCCU|VCCU]], [[HM-CFG-LAN|HMLAN]], ...) und können somit gepeert werden. Hierfür gibt es das Kommando [[Homematic Peering Beispiele#peerIODev|peerIODev]].<br />
<br />
= Beispiele=<br />
== Peering der Kanäle einer Fernbedienung mit einem Aktor ==<br />
Dabei muss beachtet werden, dass auf den Fernbedienungen immer zwei Buttons zusammengehören, also z.B. lock/unlock, open/light oder Btn01/Btn02, Btn03/Btn04. Achtung: Für ein erfolgreiches Peering muss ggf. auf der Fernbedienung die Anlerntaste gedrückt werden.<br />
<br />
Bei einem "dual" Peering werden die beiden zusammengehörenden Kanäle der Fernbedienung mit einem Aktorkanal gepeert - einer der Buttons wirkt dann als "on", der andere als "off"-Schalter.<br />
<br />
set fb_Btn03 peerChan 0 blind<br />
peert die Buttons Btn03 und Btn04 mit dem Aktorkanal ''blind''<br />
<br />
Bei einem "single" Peering wird nur einer der beiden Kanäle der Fernbedienung mit einem Aktorkanal gepeert - als Aktion wird dann im Aktorkanal ein "toggle" eingetragen.<br />
<br />
set fb_Btn07 peerChan 0 blind single<br />
peert nur den Button Btn07 mit dem Aktorkanal ''blind''<br />
<br />
Das Unpeering, also das Löschen einer Paarung, erfolgt z.B. durch den Befehl<br />
set fb_Btn07 peerChan 0 blind single unset<br />
<br />
== Peering von I/O-Entities ==<br />
<pre><br />
set blind peerIODev HMLAN1 5<br />
set blind peerIODev HMLAN1 7 unset<br />
</pre><br />
<br />
[[Kategorie:HomeMatic Components|1toolsAndWork]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Examples]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=DevelopmentModuleIntro&diff=29548DevelopmentModuleIntro2019-02-17T19:24:52Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>{{Hinweis|Dieser Text ist in Arbeit und muss noch an einigen Stellen ergänzt werden. }}<br />
<br />
<br />
== Einleitung ==<br />
<br />
Um neue Geräte, Dienste, o.ä. in FHEM verfügbar zu machen, kann man ein eigenes Modul in Perl schreiben. Ein Modul wird in FHEM automatisch geladen, wenn ein entsprechendes Device in FHEM definiert wird. Das Modul ermöglicht eine spezifische Kommunikation mit einem physikalischen Gerät, stellt Ergebnisse ("Readings") und Events innerhalb von FHEM zur Verfügung und erlaubt es, das Gerät mit "Set"-/"Get"-Befehlen zu beeinflussen. Dieser Artikel soll den Einstieg in die Entwicklung eigener Module erleichtern.<br />
<br />
Mit dem FHEM-Befehl <code>define</code> werden Devices in FHEM basierend auf einem Modul definiert. Dieser Befehl sorgt dafür, dass ein neues Modul bei Bedarf geladen und initialisiert wird. Ein gutes Beispiel ist hierbei die zentrale Konfigurationsdatei "fhem.cfg" in der sämtliche Devices in Form von <code>define</code>-Statements gespeichert sind.<br />
<br />
Damit das funktioniert müssen der Name des Moduls und der Name der [[#X_Initialize|Initialisierungsfunktion]] identisch sein. Das folgende Beispiel soll dies verdeutlichen:<br />
<br />
Ein Jeelink USB-Stick könnte beispielsweise mit dem Befehl <code>define JeeLink1 ''JeeLink'' /dev/ttyUSB0@57600</code> definiert werden.<br />
<br />
In fhem.pl wird der <code>define</code>-Befehl verarbeitet und geprüft, ob ein Modul mit dem Namen "JeeLink" schon geladen ist. Falls nicht, wird ein Modul mit Namen XY_JeeLink.pm im Modulverzeichnis (z.B. /opt/fhem/FHEM) gesucht und, falls vorhanden, anschließend geladen. <br />
Danach wird die Funktion <code>''JeeLink''_Initialize()</code> aufgerufen um das Modul in FHEM zu registrieren. Eine Moduldatei muss dazu eine Funktion <code>''&lt;Modulname&gt;''_Initialize()</code> enthalten. Durch den Aufruf dieser Funktion wird FHEM mitgeteilt, welche Funktionalitäten dieses Modul unterstützt und durch welche Perl-Funktionen im Modul selbst diese ausimplementiert werden.<br />
<br />
In der Initialisierungsfunktion des Moduls werden die Namen aller weiteren Perl-Funktionen des Moduls, die von fhem.pl aus aufgerufen werden, bekannt gemacht. Dazu wird für jedes Modul ein eigener Hash (genauer "Modul-Hash") mit entsprechenden Werten gefüllt, der in fhem.pl für jedes Modul entsprechend abgelegt wird. Dadurch weiß FHEM wie dieses Modul anzusprechen ist.<br />
<br />
== Grundlegender Aufbau eines Moduls ==<br />
<br />
=== Dateiname ===<br />
<br />
Ein FHEM-Modul wird als Perl-Modul mit der Dateiendung *.pm abgespeichert. Der Dateiname folgt dabei folgendem Schema:<br />
<br />
:<code>''['''Schlüsselnummer''']''<font color="grey">_</font>''['''Modulname''']''<font color="grey">.pm</font></code><br />
<br />
* '''Schlüsselnummer''' - Eine zweistellige Zahl zwischen 00 - 99. Die Schlüsselnummer hat aktuell keine technische Relevanz mehr. In früheren FHEM-Versionen ist sie relevant für [[#Zweistufiges_Modell_f.C3.BCr_Module|zweistufige Module]] (Reihenfolge für [[DevelopmentModuleAPI#Dispatch|Dispatch()]] um logische Module zu prüfen). Die allgemeine Empfehlung ist hierbei eine Schlüsselnummer eines Moduls zu verwenden, welches eine ähnliche Funktionalität bietet. Die Schlüsselnummer 99 hat hierbei eine besondere Bedeutung, da alle Module mit dieser Schlüsselnummer beim Start von FHEM automatisch geladen werden, selbst, wenn sie in der Konfiguration nicht verwendet werden. Daher wird für myUtils 99 als Schlüsselnummer verwendet (99_myUtils.pm). Module mit der Schlüsselnummer 99 werden im SVN nicht akzeptiert (siehe [[SVN Nutzungsregeln]])<br />
* '''Modulname''' - Der Name des Moduls wie er in FHEM bei dem Anlegen einer Gerätedefinition zu verwenden ist. Der Modulname sollte nur aus den folgenden möglichen Zeichen bestehen: Groß-/Kleinbuchstaben, Zahlen sowie Unterstrich (_)<br />
<br />
=== Inhaltlicher Aufbau ===<br />
<br />
Ein Modul ist inhaltlich in folgende Abschnitte unterteilt:<br />
<br />
<syntaxhighlight lang="perl"><br />
#<br />
# 72_MYMODULE.pm <br />
#<br />
<br />
package main;<br />
<br />
# Laden evtl. abhängiger Perl- bzw. FHEM-Hilfsmodule<br />
use HttpUtils;<br />
use [...]<br />
<br />
# FHEM Modulfunktionen<br />
<br />
sub MYMODULE_Initialize() {<br />
...<br />
}<br />
<br />
sub MYMODULE_Define() {<br />
...<br />
}<br />
<br />
...<br />
<br />
# Eval-Rückgabewert für erfolgreiches<br />
# Laden des Moduls<br />
1;<br />
<br />
<br />
# Beginn der Commandref<br />
<br />
=pod<br />
=item [helper|device|command]<br />
=item summary Kurzbeschreibung in Englisch was MYMODULE steuert/unterstützt<br />
=item summary_DE Kurzbeschreibung in Deutsch was MYMODULE steuert/unterstützt<br />
<br />
=begin html<br />
Englische Commandref in HTML<br />
=end html<br />
<br />
=begin html_DE<br />
Deutsche Commandref in HTML<br />
=end html<br />
<br />
# Ende der Commandref<br />
=cut<br />
</syntaxhighlight><br />
<br />
Man kann hierbei von folgender Reihenfolge sprechen:<br />
<br />
# Perl-Code, welcher das Modul implementiert<br />
# Die Zeile <code>1;</code> nachdem der Perl-Code abgeschlossen ist. Dies dient FHEM der Erkennung, dass das Modul erfolgreich und vollständig geladen wurde. Sollte diese Zeile nicht enthalten sein, wird FHEM beim Laden des Moduls die Fehlermeldung <code>Error:Modul 72_MYMODULE deactivated</code> in das Logfile schreiben.<br />
# Commandref zur Dokumentation des Moduls. Diese Dokumentation soll dem User die möglichen Befehle/Attribute/Readings/Events vermitteln. Weitere Informationen und Hinweise findet man in den [[Guidelines zur Dokumentation]].<br />
<br />
== Der Hash einer Geräteinstanz ==<br />
Eine Besonderheit in Perl sind [http://de.wikipedia.org/wiki/Assoziatives_Array#Perl assoziative Arrays], (nicht ganz richtig als "Hash" bezeichnet) in denen die Adressierung nicht über eine Zählvariable erfolgt, sondern über einen beliebigen String. Die internen Abläufe bei der Adressierung führen dazu, dass die Speicherung in und der Abruf aus Hashes relativ langsam ist.<br />
<br />
Der zentrale Speicherort für Informationen einer Geräteinstanz bei FHEM ist ein solcher Hash, der seinerseits in fhem.pl von einem globalen Hash referenziert wird. <br />
<br />
In fhem.pl werden alle Gerätedefinitionen in dem globalen Hash <code>%defs</code> abgelegt. Der Inhalt von <code>$defs{''&lt;Name&gt;''}</code> in fhem.pl verweist dabei auf den Hash der Geräteinstanz in Form einer Hashreferenz. Diesen Verweis (also nur die Adresse) bekommen die Funktionen eines Moduls übergeben (i.d.R. als <code>$hash</code> bezeichnet), welche direkt von fhem.pl aufgerufen werden. In dem Hash stehen beispielsweise die internen Werte des Geräts, die im Frontend als "Internals" angezeigt werden, sowie die Readings des Geräts. <br />
<br />
Beispiele:<br />
*<code>$hash->{NAME}</code> enthält den Namen der Geräteinstanz, <br />
*<code>$hash->{TYPE}</code> enthält die Typbezeichnung des Geräts (Modulname)<br />
<br />
==Ausführung von Modulen==<br />
FHEM arbeitet intern nicht parallel, sondern arbeitet alle Aufgaben seriell nacheinander kontinuierlich ab. Daher wäre es ungünstig, wenn Module Daten von einem physikalischen Gerät abfragen wollen und dabei innerhalb der selben Funktion auf die Antwort des Geräts warten. In dieser Zeit, in der FHEM auf die Antwort des Gerätes warten muss, wäre der Rest von FHEM blockiert. Da immer nur eine Aufgabe zur selben Zeit bearbeitet wird, müssen alle weiteren Aufgaben solange warten. Eine Datenkommunikation innerhalb eines Moduls sollte daher immer ohne Blockierung erfolgen. Dadurch kann FHEM die Wartezeit effizient für andere Aufgaben nutzen um bspw. anstehende Daten für andere Module zu verarbeiten. Es gibt in FHEM entsprechende Mechanismen, welche eine "Non-Blocking"-Kommunikation über verschiedene Wege (z.B. seriell, HTTP, TCP, ...) ermöglichen.<br />
<br />
Dafür werden in FHEM zwei zentrale Listen gepflegt, in der die Filedeskriptoren der geöffneten Kommunikatonsverbindungen gespeichert sind. Auf Linux- bzw. Unix-basierten Plattformen wird der select-Befehl des Betriebssystems verwendet um Filedeskriptoren auf lesbare Daten zu überprüfen. In FHEM gibt es dazu eine Liste (<code>%selectlist</code>), in der die Filedeskriptoren sämtlicher Geräte (z.B. serielle Verbindung, TCP-Verbindung, etc.) gespeichert sind. <br />
<br />
In der zentralen Schleife (Main-Loop) von fhem.pl wird mit <code>select()</code> überwacht, ob über eine der geöffneten Schnittstellen Daten zum Lesen anstehen. Wenn dies der Fall ist, dann wird die Lesefunktion ([[#X_Read|X_Read]]) des zuständigen Moduls aufgerufen, damit es die Daten entgegennimmt und verarbeitet. Anschließend wird die Schleife weiter ausgeführt.<br />
<br />
Auf Windows-Systemen funktioniert dies anders. Hier können USB/Seriell-Geräte nicht per <code>select()</code> überwacht werden. In FHEM unter Windows werden daher diese Schnittstellen kontinuierlich abgefragt ob Daten bereitstehen. Dafür müssen Module zusätzlich zur Lesefunktion eine Abfragefunktion ([[#X_Ready|X_Ready]]) implementieren, welche prüft, ob Daten zum Lesen anstehen. Auch auf Linux/Unix-Plattformen hat diese Funktion eine Aufgabe. Falls nämlich eine Schnittstelle ausfällt, beziehungsweise ein CUL oder USB-zu-Seriell Adapter ausgesteckt wird, dann wird über diese Funktion regelmäßig geprüft ob die Schnittstelle wieder verfügbar wird.<br />
<br />
Innerhalb der eigentlichen Lesefunktion (X_Read) werden dann die Daten vom zugehörigen Gerät gelesen, das nötige Protokoll implementiert um die Daten zu interpretieren und Werte in Readings geschrieben.<br />
<br />
Auch wenn von einem Anwender über einen Get-Befehl Daten aktiv von einem Gerät angefordert werden, sollte nicht blockierend gewartet werden. Eine asynchrone Ausgabe, sobald das Ergebnis vorliegt, ist über [[DevelopmentModuleAPI#asyncOutput|asyncOutput()]] möglich. Siehe {{Link2Forum|Topic=43771|Message=357870|LinkText=Beschreibung}} und {{Link2Forum|Topic=43771|Message=360935|LinkText=Beispiel}}. Weitere Anwendungsbeispiele finden sich im {{Link2Forum|Topic=43052|Message=353477|LinkText=PLEX Modul}} und im überarbeiteten und nicht-blockierenden {{Link2Forum|Topic=42771|Message=348498|LinkText=SYSSTAT Modul}}.<br />
<br />
== Wichtige globale Variablen aus fhem.pl ==<br />
<br />
FHEM arbeitet mit einer Vielzahl an internen Variablen. Die nun folgenden aufgelisteten Variablen sind die wichtigsten, welche man im Rahmen der Modulprogrammierung kennen sollte:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Variable !! Beschreibung<br />
|-<br />
| <code>$init_done</code> || Dient der Erkennung für fhem.pl sowie den Modulen, ob FHEM den Initialisierungsvorgang abgeschlossen hat. Beim Starten von FHEM ist <code>$init_done</code> gleich <code>0</code>. Erst, wenn das Einlesen der Konfiguration, sowie des State-Files (Readings) abgeschlossen ist, wird <code>$init_done</code> auf <code>1</code> gesetzt.<br />
Das gleiche Verfahren wird auch bei dem Befehl <code>rereadcfg</code> angewandt. Während <code>rereadcfg</code> ausgeführt wird (Konfiguration löschen, neu einlesen), ist <code>$init_done</code> gleich <code>0</code>.<br />
<br />
Dies ist insbesondere in der [[#X_Define|Define]]-Funktion eines Moduls relevant. Durch eine Prüfung auf <code>$init_done</code> kann man erkennen, ob eine Definition von Hand (<code>$init_done</code> = 1) oder im Rahmen der Initialisierung (FHEM Start / Rereadcfg => <code>$init_done</code> = 0) erfolgte. Während der Initialisierung stehen bspw. die gesetzten Attribute der Definition noch nicht zur Verfügung und können daher nicht ausgewertet werden (siehe . <br />
|-<br />
| <code>%attr</code> || In <code>%attr</code> werden sämtliche gesetzten Attribute aller Geräte gespeichert. Diese Datenstruktur wird generell durch den <code>attr</code>-Befehl verwaltet. Hierbei wird einem Gerätenamen eine Mehrzahl an Attributnamen mit einem Wert zugeordnet. Attribut-Inhalte können über die Funktion [[DevelopmentModuleAPI#AttrVal|AttrVal()]] ausgelesen werden.<br />
|-<br />
| <code>%cmds</code> || In <code>%cmds</code> wird jedem in FHEM existierendem Befehl die entsprechende Funktion zugewiesen, welche diesen Befehl umsetzt. Module können durch das Eintragen eines Befehlsnamen samt Funktion in <code>%cmds</code> über die [[#X_Initialize|Initialize]]-Funktion eines Moduls einen (oder mehrere) eigene Befehle in FHEM registrieren.<br />
<br />
Die Struktur ist dabei wiefolgt:<br />
<br />
$cmds{''&lt;Befehlsname&gt;''} = { Fn => "''&lt;Funktionsname&gt;''",<br />
Hlp => "''&lt;Aufrufsyntax&gt;''"};<br />
<br />
|-<br />
| <code>%data</code>|| Der eigentliche Zweck von <code>%data</code> ist dem Nutzer eine Möglichkeit zum Speichern von temporären Daten im globalen Kontext zu ermöglichen. Einige Module verwenden <code>%data</code> jedoch auch um modul- & geräteübergreifend Daten auszutauschen.<br />
|-<br />
| <code>%defs</code>|| In <code>%defs</code> werden sämtliche Gerätedefinitionen, bzw. die Hash-Referenzen auf diese, gespeichert. Hier ist jedem Gerätenamen eine Hash-Referenz zugeordnet.<br />
|-<br />
| <code>%modules</code>|| In <code>%modules</code> sind alle geladenen Module gelistet mit ihren entsprechenden Initialisierungsdaten (Funktionsnamen, Attribut-Listen, spezielle Einstellungen, ...). Hier wird für jeden Modulname der Modul-Hash aus der [[#X_Initialize|Initialize]]-Funktion gespeichert. <br />
Desweiteren legen viele Module, welche nach dem [[DevelopmentModuleIntro#Zweistufiges_Modell_f.C3.BCr_Module|zweistufigen Modulkonzept]] hier eine Rückwärtszuordnung von Geräteadressen zu Geräte-Hash an.<br />
|-<br />
| <code>%readyfnlist</code>|| In <code>%readyfnlist</code> sind alle zu prüfenden Verbindungen mit ihrer entsprechendem Geräte-Hash gelistet. FHEM prüft alle hier gelisteten Geräte regelmäßig über eine Aufruf der entsprechenden [[#X_Ready|Ready]]-Funktion.<br />
<br />
Bei einer Nutzung von dem Hilfsmodul [[DevIo|DevIo.pm]] zum Aufbau einer Kommunikationsverbindung, kümmert sich DevIo selbständig um den entsprechenden Eintrag in <code>%readyfnlist</code>.<br />
|-<br />
| <code>%selectlist</code>|| In <code>%selectlist</code> sind alle geöffneten Verbindungen mit ihrer entsprechendem Geräte-Hash gelistet. FHEM prüft alle hier gelisteten Geräte, ob der geöffnete Filedeskriptor unter <code>$hash->{FD}</code> Daten zum Lesen bereitgestellt hat. Ist dass der Fall, wird die entsprechende [[#X_Read|Read]]-Funktion aufgerufen, um anstehende Daten durch das Modul zu verarbeiten.<br />
Bei einer Nutzung von dem Hilfsmodul [[DevIo|DevIo.pm]] zum Aufbau einer Kommunikationsverbindung, kümmert sich DevIo selbständig um den entsprechenden Eintrag in <code>%selectlist</code>.<br />
|}<br />
<br />
Es gibt durchaus viele weitere globale Variablen, die jedoch für sehr spezielle Anwendungsfälle und z.T. nur einzelne Module gedacht sind und daher hier nicht aufgeführt werden.<br />
<br />
== Internals ==<br />
Daten, die ein Modul im Geräte-Hash speichert nennt man Internals. Sie werden als Unterstruktur des Hashes der jeweiligen Geräteinstanz gespeichert, beispielswiese <code>$hash->{NAME}</code> für den Gerätenamen, welcher beim Define-Befehl übergeben wurde und als Internal gespeichert wird. Diese Daten spielen für FHEM eine sehr wichtige Rolle, da sämtliche gerätespezifischen Daten als Internal im Gerätehash gespeichert werden.<br />
<br />
Falls Werte wie z.B. ein Intervall nicht über den Define-Befehl gesetzt werden sollen und im Betrieb einfach änderbar sein sollten, ist eine alternative Möglichkeit die Speicherung in so genannten Attributen. Dann würde man den Define-Befehl so implementieren, dass er kein Intervall übergeben bekommt und statt dessen das Interval als Attribut über den Befehl <code>attr</code> gesetzt wird.<br />
<br />
Generell werden alle Werte, welche direkt in der ersten Ebene von <code>$hash</code> (Gerätehash) gespeichert werden auf der Detail-Seite einer Definition in der FHEMWEB Oberfläche angezeigt. Es gibt jedoch Ausnahmen:<br />
<br />
* <code>$hash->{helper}{URL}</code> - Alle Elemente, welche als Unterelement wieder einen Hash besitzen werden nicht in FHEMWEB dargestellt. Typischerweise speichern Module Daten unter <code>$hash->{helper}</code> interne Daten zwischen, die für den User nicht relevant sind, sondern nur der internen Verarbeitung dienen.<br />
* <code>$hash->{'''.'''<font color="grey">ELEMENT</font>}</code> - Alle Knoten, welche mit einem Punkt beginnen werden in der FHEMWEB Oberfläche nicht angezeigt. Man kann diese Daten jedoch beim Aufruf des [[List|list-Kommandos]] einsehen.<br />
<br />
Es gibt bereits vorbelegte Internals welche in FHEM dazu dienen definitionsbezogene Informationen wie bspw. Namen und Readings zu speichern. Dies sind im besonderen:<br />
<br />
{| class="wikitable"<br />
|-<br />
! style="min-width: 13em;" | Internal !! Beschreibung<br />
|-<br />
| <code>$hash->{NAME}</code> || Der Definitionsname, mit dem das Gerät angelegt wurde. <br />
|-<br />
| <code>$hash->{READINGS}</code> || Enthält alle aktuell vorhandenen Readings. Daten unterhalb dieses Knotens sollte man nicht direkt manipulieren. Um Readings zu Erzeugen gibt es entsprechende [[DevelopmentModuleAPI#Readings_.2F_Events|Reading-Funktionen]].<br />
|-<br />
| <code>$hash->{NR}</code> || Die Positions-Nr. der Definition innerhalb der Konfiguration. Diese dient dazu die Konfiguration in der gleichen Reihenfolge zu speichern, wie die einzelnen Geräte angelegt wurden.<br />
|-<br />
| <code>$hash->{TYPE}</code> || Der Modulname, mit welchem die Definition angelegt wurde.<br />
|-<br />
| <code>$hash->{DEF}</code> || Sämtliche Argumente, welche beim <code>define</code>-Befehl nach dem Modulnamen übergeben wurden.<br />
|-<br />
| <code>$hash->{CFGFN}</code> || Der Dateiname der Konfigurationsdatei in der diese Definition enthalten ist (sofern nicht in fhem.cfg). Dieser Wert ist nur gefüllt, wenn man mit mehreren Konfigurationsdateien arbeitet, welche dann in fhem.cfg via include-Befehl eingebunden werden.<br />
|-<br />
| <code>$hash->{NTFY_ORDER}</code> || Sofern das Modul Events via [[DevelopmentModuleIntro#X_Notify|Notify-Funktion]] verarbeitet enthält jede Definition eine Notify-Order als Zeichenkette bestehend aus dem Notify Order Prefix und dem Definitionsnamen. Details zur Funktionsweise gibt es in der Beschreibung zur [[DevelopmentModuleIntro#X_Notify|Notify-Funktion]] im Abschnitt "Reihenfolge für den Aufruf der Notify-Funktion beeinflussen".<br />
|-<br />
| <code>$hash->{NOTIFYDEV}</code> || Sofern das Modul Events via NotifyFn verarbeitet kann man damit die Definitionen, von denen man Events erhalten will begrenzen. Details zur Funktionsweise gibt es in der Beschreibung zur [[DevelopmentModuleIntro#X_Notify|Notify-Funktion]] im Abschnitt "Begrenzung der Aufrufe auf bestimmte Geräte".<br />
|-<br />
| <code>$hash->{IODev}</code> || Hier wird das zugeordnete IO-Gerät durch [[DevelopmentModuleAPI#AssignIoPort|AssignIoPort()]] gespeichert, welches für den Datentransport und -empfang dieses logischen Gerätes zuständig ist. Dieser Wert existiert nur bei Modulen die nach dem [[DevelopmentModuleIntro#Zweistufiges_Modell_f.C3.BCr_Module|zweistufigen Modulkonzept]] arbeiten. <br />
|-<br />
| <code>$hash->{CHANGED}</code> || Hier werden alle Events kurzzeitig gesammelt, welche für die Eventverarbeitung anstehen. Insbesondere die [[DevelopmentModuleAPI#Readings_.2F_Events|Reading-Funktionen]] speichern hier alle Events zwischen um sie nach Abschluss via [[DevelopmentModuleAPI#DoTrigger|DoTrigger()]] zu verarbeiten. <br />
|-<br />
| <code>$hash->{FD}</code> || Wenn die Definition eine Netzwerkverbindung oder serielle Schnittstelle geöffnet hat (z.B. via [[DevIo]]), so wird der entsprechende File-Deskriptor in diesem Internal gespeichert. Damit kann FHEM alle geöffneten Filedeskriptoren der entsprechenden Definition zuordnen um bei ankommenden Daten die Definition via [[DevelopmentModuleIntro#X_Read|Read-Funktion]] damit zu versorgen.<br />
|-<br />
| <code>$hash->{EXCEPT_FD}</code> || Ähnlich wie <code>$hash->{FD}</code>. Sofern die Definition in <code>[[#Wichtige_globale_Variablen_aus_fhem.pl|%selectlist]]</code> eingetragen ist und ein Fildeskriptor in diesem Internal gesetzt ist, wird bei einer auftretenden Exception bzw. Interrupt die [[DevelopmentModuleIntro#X_Except|Except]]-Funktion des entsprechenden Moduls aufgerufen um darauf zu reagieren.<br />
|}<br />
<br />
Generell sollte man die meisten der hier genannten systemweiten Internals nicht modifizieren, da ansonsten die korrekte Funktionsweise von FHEM nicht mehr garantiert werden kann.<br />
<br />
== Readings ==<br />
Daten, welche von einem Gerät gelesen werden und in FHEM in einer für Menschen verständlichen Form zur Verfügung gestellt werden können, werden Readings genannt. Sie geben den Status des Gerätes wieder und erzeugen Events innerhalb von FHEM auf die andere Geräte reagieren können. Sie werden als Unterstruktur des Hashes der jeweiligen Geräteinstanz gespeichert, beispielsweise <br />
*<code>$hash->{READINGS}{temperature}{VAL}</code> für die Temperatur eines Fühlers<br />
*<code>$hash->{READINGS}{temperature}{TIME}</code> für den Zeitstempel der Messung<br />
<br />
Für den lesenden Zugriff auf Readings steht die Funktion <code>[[DevelopmentModuleAPI#ReadingsVal|ReadingsVal()]]</code> zur Verfügung. Ein direkter Zugriff auf die Datenstruktur sollte nicht vorgenommen werden.<br />
<br />
Readings werden im Statefile von FHEM automatisch auf der Festplatte zwischengespeichert, damit sie nach einem Neustart sofort wieder zur Verfügung stehen. Dadurch ist der letzte Status eines Gerätes vor einem Neustart nachvollziehbar.<br />
<br />
Readings, die mit einem Punkt im Namen beginnen, haben eine funktionale Besonderheit. Sie werden im FHEMWEB nicht angezeigt und können somit als "Permanentspeicher" für kleinere Daten innerhalb des Moduls genutzt werden. Um größere Datenmengen permanent zu speichern sollte man jedoch die Funktion <code>[[DevelopmentModuleAPI#setKeyValue|setKeyValue()]]</code> verwenden.<br />
<br />
Zum Setzen von Readings sollen <br />
*bei Gruppen von Readings der Funktionsblock <code>[[DevelopmentModuleAPI#readingsBeginUpdate|readingsBeginUpdate()]]</code>, <code>[[DevelopmentModuleAPI#readingsBulkUpdate|readingsBulkUpdate()]]</code> (mehrfach wiederholt), <code>[[DevelopmentModuleAPI#readingsEndUpdate|readingsEndUpdate()]]</code><br />
*bei einzelnen Updates die Funktion <code>[[DevelopmentModuleAPI#readingsSingleUpdate|readingsSingleUpdate()]]</code> <br />
aufgerufen werden. Dabei kann man auch angeben, ob dabei ein Event ausgelöst werden soll oder nicht. Events erzeugen, je nach Hardwareperformance, spürbare Last auf dem System (siehe [[DevelopmentModuleIntro#X_Notify|NotifyFn]]), das Ändern von Readings ohne dass dabei Events erzeugt werden jedoch nicht.<br />
<br />
Eine Sequenz zum Setzen von Readings könnte folgendermaßen aussehen:<br />
<br />
<syntaxhighlight lang="perl"><br />
readingsBeginUpdate($hash);<br />
readingsBulkUpdate($hash, $readingName1, $wert1 );<br />
readingsBulkUpdate($hash, $readingName2, $wert2 );<br />
readingsEndUpdate($hash, 1);<br />
</syntaxhighlight><br />
<br />
== Events ==<br />
<br />
FHEM verfügt über einen Event-Mechanismus um Änderungen verschiedenster Art an einzelne oder alle Definitionen mitzuteilen. Jedes Modul (und damit alle Definitionen dieses Moduls) können auf Events von FHEM selber (Definition <code>global</code>) oder von anderen Definitionen reagieren und dadurch selber aktiv werden. Ein Event wird innerhalb von FHEM als Zeichenkette behandelt.<br />
<br />
Events sind grundsätzlich immer definitionsbezogen. Das bedeutet, dass ein Event immer in Verbindung mit einem Definitionsnamen erzeugt wird. Jede Definition, welche ein Event verarbeitet, erhält den Definitions-Hash (<code>$hash</code>) der auslösenden Definition.<br />
<br />
Events werden typischerweise bei der Erstellung von Readings implizit für jedes einzelne Reading erzeugt. Es gibt jedoch auch Events die nichts mit Readings zu tun haben um anderweitige Änderungen bekannt zu geben.<br />
<br />
Eigene Events können in FHEM mit der Funktion [[DevelopmentModuleAPI#DoTrigger|DoTrigger()]] erzeugt werden. Um auf Events in einem Modul reagieren zu können, muss eine [[#X_Notify|Notify]]-Funktion implementiert sein. Sobald ein oder mehrere Events für eine Definition getriggert werden, prüft FHEM, welche Definitionen über Events der auslösenden Definition informiert werden möchten. Diese werden dann nacheinander in einer bestimmten Reihenfolge durch Aufruf der [[#X_Notify|Notify]]-Funktion über anstehende Events in Kenntnis gesetzt. Es obliegt dann dem jeweiligen Modul, wie es auf die Events reagiert.<br />
<br />
=== globale Events ===<br />
<br />
Als "globale Events" werden alle Events bezeichnet, die durch die Definition <code>global</code> erzeugt werden. Es handelt sich hierbei um Events die Strukturänderungen in der Konfiguration, als auch systemweite Ereignisse zu FHEM selbst signalisieren.<br />
<br />
Hier eine kurze Zusammenfassung, welche Events durch <code>global</code> getriggert werden können:<br />
<br />
<u>Allgemeine Events:</u><br />
<br />
{| class="wikitable"<br />
|-<br />
! Event-Text !! Beschreibung.<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | '''<code>INITIALIZED</code>''' || Der Start von FHEM ist abgeschlossen. Sämtliche Definitionen und Attribute wurden aus der Konfiguration (fhem.cfg oder configDB) eingelesen, sowie sämtliche Readings sind aus dem State-File eingelesen und stehen nun voll umfänglich zur Verfügung.<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | '''<code>REREADCFG</code>''' || Die Konfiguration wurde erneut eingelesen. Dies bedeutet, es wurden alle Definitionen/Attribute/Readings aus FHEM entfernt und durch Einlesen der Konfiguration neu angelegt. (FHEM-Befehl: "rereadcfg")<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | '''<code>SAVE</code>''' || Die laufende Konfiguration soll gespeichert werden (in fhem.cfg oder configDB). Dieses Event wird '''VOR''' dem Speichern der Konfiguration getriggert. Sobald der Trigger verarbeitet wurde, beginnt das Speichern der Konfiguration. (FHEM-Befehl: "save")<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | '''<code>SHUTDOWN</code>''' || FHEM wird sich beenden. (FHEM-Befehl: "shutdown")<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | '''<code> DELAYEDSHUTDOWN </code>''' || FHEM wird sich beenden. (FHEM-Befehl: "shutdown")<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | '''<code>UPDATE</code>''' || Es wurde ein Update erfolgreich installiert. (FHEM-Befehl: "update")<br />
|}<br />
<br />
<u>Definitionsbezogene Events:</u><br />
<br />
{| class="wikitable"<br />
|-<br />
! Event-Text !! Beschreibung.<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | '''<code>DEFINED ''<Name>''</code>''' || Es wurde eine neue Definition mit Namen <code>''<Name>''</code> angelegt. (FHEM-Befehl: "define")<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | '''<code>DELETED ''<Name>''</code>''' || Die Definition mit dem Namen <code>''<Name>''</code> wurde gelöscht. (FHEM-Befehl: "delete")<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | '''<code>RENAMED ''<Alt>'' ''<Neu>''</code>''' || Die Definition mit dem Namen <code>''<Alt>''</code> wurde in den Namen <code>''<Neu>''</code> umbenannt. (FHEM-Befehl: "rename")<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | '''<code>MODIFIED ''<Name>''</code>''' || Die Definition mit dem Namen <code>''<Name>''</code> wurde modifiziert. (FHEM-Befehl: "modify")<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | '''<code>UNDEFINED ''<Name> <Modul> <Define-Parameter>''</code>''' || Es wurde eine Nachricht von einem physikalischen Modul (siehe [[#Zweistufiges Modell für Module|zweistufiges Modulkonzept]]) erhalten, für die keine passende logische Definition in FHEM existiert. Details dazu, siehe dazu Abschnitt [[#Automatisches Anlegen von logischen Gerätedefinitionen (autocreate)|Automatisches Anlegen von logischen Gerätedefinitionen (autocreate)]].<br />
|}<br />
<br />
=== Begrenzung von Events ===<br />
<br />
Ein Modul, welches Events verarbeitet, kann die Eventverarbeitung auf bestimmte Definitionen begrenzen. Dadurch werden nur Events an das Modul gemeldet (via [[#X_Notify|X_Notify()]]), welche von einer oder mehreren bestimmten Definitionen getriggert wurden. Dadurch werden unnötige Events nicht an das Modul gemeldet und schont somit Ressourcen.<br />
<br />
Standardmäßig werden sämtliche Events ohne Begrenzung an ein Modul gemeldet, welches eine [[#X_Notify|Notify]]-Funktion implementiert hat und somit Events verarbeiten kann. Details zur Begrenzung von Events findet man in der Beschreibung zur Modulfunktion [[#X_Notify|X_Notify()]].<br />
<br />
=== Reihenfolge der Eventverarbeitung ===<br />
<br />
Ein getriggertes Event wird nacheinander gegen jede Definition geprüft, deren Modul eine [[#X_Notify|Notify]]-Funktion implementiert hat. Dies bedeutet, jede Definition wird nacheinander durch Aufruf der [[#X_Notify|Notify]]-Funktion mit dem Definitionshash der auslösenden Definition aufgerufen.<br />
<br />
Unter bestimmten Umständen kann es erforderlich sein, in diese Reihenfolge einzugreifen. Beispielsweise wenn das eigene Modul und deren Definitionen das Event als letztes oder erstes verarbeiten müssen. Ein Beispiel bietet hierbei das Modul [[dewpoint]], welches Events vor allen anderen Modulen verarbeiten muss.<br />
<br />
Details, wie man die Reihenfolge der Eventverarbeitung steuern kann, findet man in der Beschreibung zur Modulfunktion [[#X_Notify|X_Notify()]].<br />
<br />
== Attribute ==<br />
Damit der Nutzer das Verhalten einer einzelnen Gerätedefinition zur Laufzeit individuell anpassen kann, gibt es in FHEM für jede Definition sogenannte Attribute, welche mit dem Befehl <code>attr</code> gesetzt werden können.<br />
Diese stehen dann dem Modul unmittelbar zur Verfügung um das Verhalten während der Ausführung zu beeinflussen. Attribute werden zusammen mit dem <code>define</code>-Befehl der jeweiligen Definition beim Speichern der aktuellen Konfiguration von FHEM in die Konfigurationsdatei geschrieben. Beim Neustart werden die entsprechenden Befehle ausgeführt um alle Definition inkl. Attribute wieder anzulegen. Zur Laufzeit werden Attribute in dem globalen Hash <code>%attr</code> mit dem Definitionsnamen als Index (<code>$attr{$name} = $value</code>) gespeichert. Ein Attribut mit dem Namen <code>header</code> würde beispielsweise mit <code>$attr{$name}{header}</code> adressiert. Generell sollte <code>%attr</code> nicht durch direkten Zugriff manipuliert/benutzt werden.<br />
<br />
Zum Auslesen von Attributen sollte die Funktion [[DevelopmentModuleAPI#AttrVal|AttrVal()]] verwendet werden.<br />
<br />
Welche Attribute ein Modul unterstützt muss in der Funktion <code>[[#X_Initialize|X_Initialize]]</code> durch Setzen von <code>$hash->{AttrList}</code> bekannt gemacht werden (siehe unten).<br />
<br />
Wenn beim Setzen von Attributen in einer Gerätedefinition entsprechende Werte geprüft werden sollen oder zusätzliche Funktionalitäten implementiert werden müssen, dann muss dies in der Funktion <code>[[#X_Attr|X_Attr]]</code> (siehe unten) implementiert werden. Hier kann man bspw. einen Syntaxcheck für Attribut-Werte implementieren um ungültige Werte zurückzuweisen.<br />
<br />
== Modulfunktionen ==<br />
<br />
Damit fhem.pl ein Modul nutzen kann, muss dieses entsprechende Funktionen mit einer vorgegebenen Aufrufsyntax implementieren. Durch die Bekanntgabe dieser modulspezifischen Funktionen können Daten zwischen fhem.pl und einem Modul entsprechend ausgetauscht werden. Es gibt verschiedene Arten von Funktionen die ein Modul anbieten muss bzw. kann, je nach Funktionsumfang.<br />
<br />
=== Die wichtigsten Funktionen in einem Modul ===<br />
<br />
Folgende Funktion muss ein Modul mit dem beispielhaften Namen "X" mindestens bereitstellen:<br />
<br />
{| class="wikitable"<br />
|-<br />
! style="text-align:left" | Funktionsname !! style="text-align:left" | Kurzbeschreibung<br />
|-<br />
| [[#X_Initialize|X_Initialize]] || Initialisiert das Modul und gibt den Namen zusätzlicher Modulfunktionen bekannt, sowie modulspezifische Einstellungen. Wird direkt nach dem erfolgreichen Laden des Moduls durch fhem.pl aufgerufen.<br />
|}<br />
<br />
Die folgenden Funktionen sind die wichtigsten Funktionen, welche je nach Anwendungsfall zu implementieren sind. Es handelt sich hierbei um die wichtigsten Vertreter, welche in den meisten Modulen Verwendung finden. Nicht alle Funktionen machen jedoch in jedem Modul Sinn. Generell sollte auch hier bei jeder Funktion der Modulname vorangestellt werden um ein einheitliches Namensschema zu gewährleisten. Hier die wichtigsten Modulfunktionen:<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! style="text-align:left" | Funktionsname !! style="text-align:left" class="unsortable"| Kurzbeschreibung<br />
|-<br />
| [[#X_Define|X_Define]] || Wird im Rahmen des <code>define</code>-Befehls aufgerufen.<br />
|-<br />
| [[#X_Undef|X_Undef]] || Wird im Rahmen des <code>delete</code>-Befehls, sowie <code>rereadcfg</code>-Befehl aufgerufen. Dient zum Abbau von offenen Verbindungen, Timern, etc.<br />
|-<br />
| [[#X_Delete|X_Delete]] || Wird im Rahmen des beim <code>delete</code>-Befehls aufgerufen wenn das Gerät endgültig gelöscht wird um weiterführende Aktionen vor dem Löschen durchzuführen.<br />
|-<br />
| [[#X_Get|X_Get]] || Wird im Rahmen des <code>get</code>-Befehls aufgerufen um Daten vom Gerät abzufragen<br />
|-<br />
| [[#X_Set|X_Set]] || Wird im Rahmen des <code>set</code>-Befehls aufgerufen um Daten an das Gerät zu senden.<br />
|-<br />
| [[#X_Attr|X_Attr]] || Wird im Rahmen des <code>attr</code>-Befehls aufgerufen um Attributwerte zu prüfen)<br />
|-<br />
| [[#X_Read|X_Read]] || Wird durch FHEM aufgerufen, wenn ein gelisteter Filedeskriptor in <code>[[#Wichtige_globale_Variablen_aus_fhem.pl|%selectlist]]</code> Daten zum Lesen bereitstellt.<br />
|-<br />
| [[#X_Ready|X_Ready]] || Wird unter Windows durch FHEM aufgerufen um zyklisch einen seriellen Filedeskriptor auf lesbare Daten zu prüfen. Unter Linux dient diese Funktion dem Wiederaufbau verlorener Verbindungen.<br />
|-<br />
| [[#X_Notify|X_Notify]] || Verarbeitet Events von anderen Geräten innerhalb von FHEM<br />
|-<br />
| [[#X_Rename|X_Rename]] || Wird aufgerufen, wenn ein Gerät umbenannt wird.<br />
|-<br />
| [[#X_Shutdown|X_Shutdown]] || Wird beim Herunterfahren von FHEM ausgeführt.<br />
|-<br />
| [[#X_DelayedShutdown | X_DelayedShutdown]] || Wird beim Herunterfahren von FHEM ausgeführt.<br />
|}<br />
<br />
Diese Funktionen werden in diesem Abschnitt genauer beschrieben.<br />
<br />
==== X_Initialize ====<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Initialize($)<br />
{<br />
my ($hash) = @_;<br />
...<br />
}<br />
</syntaxhighlight><br />
<br />
Das <code>X</code> im Namen muss dabei auf den Namen des Moduls bzw. des definierten Gerätetyps geändert werden. Im Modul mit der Datei <code>36_JeeLink.pm</code> beispielsweise ist der Name der Funktion <code>JeeLink_Initialize</code>. Die Funktion wird von fhem.pl nach dem Laden des Moduls aufgerufen und bekommt eine leere Hashreferenz für den Initialisierungsvorgang übergeben. <br />
<br />
Dieser Hash muss nun von X_Initialize mit allen modulrelevanten Funktionsnamen gefüllt werden. Anschließend wird dieser Hash durch fhem.pl im globalen Hash <code>%modules</code> gespeichert. <code>$modules{ModulName}</code> wäre dabei der Hash für das Modul mit dem Namen <code>ModulName</code>. Es handelt sich also nicht um den oben beschriebenen Hash der Geräteinstanzen sondern einen Hash, der für jedes Modul existiert und modulspezifische Daten wie bspw. die implementierten Modulfunktionen enthält. Die Initialize-Funktion setzt diese Funktionsnamen, in den Hash des Moduls wie folgt:<br />
<br />
<syntaxhighlight lang="perl"><br />
$hash->{DefFn} = "X_Define";<br />
$hash->{UndefFn} = "X_Undef";<br />
$hash->{DeleteFn} = "X_Delete";<br />
$hash->{SetFn} = "X_Set";<br />
$hash->{GetFn} = "X_Get";<br />
$hash->{AttrFn} = "X_Attr";<br />
$hash->{ReadFn} = "X_Read";<br />
$hash->{ReadyFn} = "X_Ready";<br />
$hash->{NotifyFn} = "X_Notify";<br />
$hash->{RenameFn} = "X_Rename";<br />
$hash->{ShutdownFn} = "X_Shutdown";<br />
$hash->{DelayedShutdownFn} = "X_ DelayedShutdown";<br />
</syntaxhighlight><br />
<br />
Um eine entsprechende Funktion in FHEM bekannt zu machen muss dazu der Funktionsname, wie er im Modul als <code>sub &lt;''Funktionsname''&gt;() { ... }</code> definiert ist, als Zeichenkette in <code>$hash</code> gesetzt werden. Dabei sollten die entsprechenden Funktionsnamen immer den Modulnamen (in diesem Beispiel <code>X</code>) als Präfix verwenden.<br />
Auf diese Weise können sämtliche modulspezifisch implementierten Funktionen wie <code>X_Read</code>, <code>X_Parse</code> etc. durch Zuweisung an <code>$hash->{ReadFn}</code> bzw. <code>$hash->{ParseFn}</code> usw. bekannt gemacht werden.<br />
<br />
Darüber hinaus sollten die vom Modul unterstützten Attribute definiert werden:<br />
<br />
<syntaxhighlight lang="perl"><br />
$hash->{AttrList} =<br />
"do_not_notify:1,0 " . <br />
"header " .<br />
$readingFnAttributes; <br />
</syntaxhighlight><br />
<br />
Die Auflistung aller unterstützten modulspezifischen Attribute erfolgt in Form einer durch Leerzeichen getrennten Liste in <code>$hash->{AttrList}}</code>. Es gibt in FHEM globale Attribute, die in allen Gerätedefinitionen verfügbar sind und nur modulspezifische Attribute die jedes Modul via <code>$hash->{AttrList}</code> über die eigene Initialize-Funktion setzt. In fhem.pl werden dann die entsprechenden Attributwerte beim Aufruf eines <code>attr</code>-Befehls in die globale Datenstruktur <code>$attr{$name}</code>, z.B. <code>$attr{$name}{header}</code> für das Attribut <code>header</code> gespeichert. Falls im Modul weitere Aktionen oder Prüfungen beim Setzen eines Attributs nötig sind, dann kann wie im Beispiel oben die [[#X_Attr|Attr]]-Funktion implementiert und in der Initialize-Funktion bekannt gemacht werden.<br />
<br />
Die Variable <code>$readingFnAttributes</code>, die im obigen Beispiel an die Liste der unterstützten Attribute angefügt wird, definiert Attributnamen, die dann zusätzlich gemacht werden, wenn das Modul zum Setzen von Readings die Funktionen <code>[[DevelopmentModuleAPI#readingsBeginUpdate|readingsBeginUpdate()]]</code>, <code>[[DevelopmentModuleAPI#readingsBulkUpdate|readingsBulkUpdate()]]</code>, <code>[[DevelopmentModuleAPI#readingsEndUpdate|readingsEndUpdate()]]</code> oder <code>[[DevelopmentModuleAPI#readingsSingleUpdate|readingsSingleUpdate()]]</code> verwendet. In diesen Funktionen werden Attribute wie <code>event-min-interval</code> oder auch <code>event-on-change-reading</code> ausgewertet. Für Details hierzu siehe commandref zu {{Link2CmdRef|Anker=readingFnAttributes|Label=readingFnAttributes}}.<br />
<br />
<br />
<u>Nutzung von parseParams()</u><br />
<br />
Die Funktion <code> [[DevelopmentModuleAPI#parseParams|parseParams()]]</code> unterstützt Modul-Autoren beim Parsen von Übergabeparametern, welche bei <code>define</code>, <code>get</code> und <code>set</code> Kommandos an die entsprechenden Modulfunktionen übergeben werden. Dadurch lassen sich auf einfache Weise insbesondere komplexe Parameter (wie bspw. Perl-Ausdrücke) sehr einfach parsen.<br />
<br />
Diese Zusatzfunktion kann man in der Initialize-Funktion einfach über folgenden Parameter für [[#X_Define|Define]]-, [[#X_Get|Get]]- und [[#X_Set|Set]]-Funktion modulweit aktivieren:<br />
<syntaxhighlight lang="perl">$hash->{parseParams} = 1;</syntaxhighlight><br />
Sobald es gesetzt ist wird automatisch durch fhem.pl <code>[[DevelopmentModuleAPI#parseParams|parseParams()]]</code> aufgerufen und die an die [[#X_Define|Define]]-, [[#X_Get|Get]]- und [[#X_Set|Set]]-Funktion übergebenen Parameter ändern sich wie weiter unten in den jeweiligen Funktionen beschrieben.<br />
<br />
==== X_Define ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Define($$)<br />
{<br />
my ( $hash, $def ) = @_;<br />
<br />
...<br />
<br />
return $error;<br />
}<br />
</syntaxhighlight><br />
<br />
Die Define-Funktion eines Moduls wird von FHEM aufgerufen wenn der Define-Befehl für ein Geräte ausgeführt wird und das Modul bereits geladen und mit der Initialize-Funktion initialisiert ist. Sie ist typischerweise dazu da, die übergebenen Parameter zu prüfen und an geeigneter Stelle zu speichern sowie einen Kommunikationsweg zum Gerät zu öffnen (z.B. TCP-Verbindung, USB-Schnittstelle o.ä.) oder einen [[#Pollen_von_Geräten|Status-Timer]] zu starten.<br />
Sie beginnt typischerweise mit:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Define($$)<br />
{<br />
my ( $hash, $def ) = @_;<br />
my @a = split( "[ \t][ \t]*", $def );<br />
...<br />
</syntaxhighlight><br />
<br />
Als Übergabeparameter bekommt die Define-Funktion den Hash der Geräteinstanz sowie den die im <code>define</code>-Befehl übergebenen Parameter. Welche bzw. wie viele Parameter <br />
akzeptiert werden und welcher Syntax diese entsprechen müssen ist Sache dieser Funktion. Im obigen Beispiel wird die Argumentzeile <code>$def</code> in ein Array aufgeteilt (durch Leerzeichen/Tabulator getrennt) und so können die vom Modul bzw. der Define-Funktion erwarteten Werte über das Array der Reihe nach verarbeitet werden:<br />
<br />
<syntaxhighlight lang="perl"><br />
my $name = $a[0];<br />
my $module = $a[1];<br />
my $url = $a[2];<br />
my $inter = 300;<br />
<br />
if(int(@a) == 4) { <br />
$inter = $a[3]; <br />
if ($inter < 5) {<br />
return "interval too small, please use something > 5s, default is 300 seconds";<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
Damit die übergebenen Werte auch anderen Funktionen zur Verfügung stehen und an die jeweilige Geräteinstanz gebunden sind, werden die Werte typischerweise als Internals im Hash der Geräteinstanz gespeichert:<br />
<br />
<syntaxhighlight lang="perl"><br />
$hash->{url} = $url;<br />
$hash->{Interval} = $inter;<br />
</syntaxhighlight><br />
<br />
Sobald alle Parameter korrekt verarbeitet wurden, wird in der Regel die erste Verbindung zum Gerät aufgebaut. Je nach Art des Geräts kann das eine permanente Datenverbindung sein (z.B. serielle Schnittstelle oder TCP-Verbindung) oder das Starten eines regelmäßigen Timers, der zyklisch den Status z.B. via [[HttpUtils|HTTP]] ausliest.<br />
<br />
Sollten im Rahmen der Define-Funktion Syntax-Probleme der Übergabeparameter festgestellt werden oder es kann bspw. keine Verbindung aufgebaut werden, so ist als Funktionsrückgabewert eine entsprechende Fehlermeldung zurückzugeben. Nur wenn alle Übergabeparameter akzeptiert werden, darf <code>undef</code> zurückgegeben werden. Sobald eine Define-Funktion eine Fehlermeldung zurückmeldet, wird der define-Befehl durch FHEM zurückgewiesen und der User erhält die Fehlermeldung, welche die Define-Funktion produziert hat, als Ausgabe zurück.<br />
<br />
<br />
<u>Verfügbarkeit von Attributen</u><br />
<br />
Während die Define-Funktion ausgeführt wird, sollte man nicht davon ausgehen, dass alle vom Nutzer konfigurierten Attribute via [[DevelopmentModuleAPI#AttrVal|AttrVal()]] verfügbar sind. Attribute stehen in der Define-Funktion nur dann zur Verfügung, wenn FHEM sich nicht in der Initialisierungsphase befindet (globale Variable <code>$init_done</code> ist wahr; der Nutzer hat die Gerätedefinition modifiziert). Daher sollte man weiterführende Funktion, welche auf gesetzte Attribute angewiesen sind, nur dann in der Define-Funktion starten, wenn <code>$init_done</code> zutrifft.<br />
<br />
Andernfalls sollte man den Aufruf in der Notify-Funktion durchführen sobald <code>global:INITIALIZED</code> bzw. <code>global:REREADCFG</code> getriggert wurde:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Define($$)<br />
{<br />
my ( $hash, $def ) = @_;<br />
<br />
...<br />
<br />
$hash->{NOTIFYDEV} = "global";<br />
<br />
X_FunctionWhoNeedsAttr($hash) if($init_done);<br />
}<br />
<br />
sub X_Notify($$)<br />
{<br />
my ($own_hash, $dev_hash) = @_;<br />
my $ownName = $own_hash->{NAME}; # own name / hash<br />
<br />
return "" if(IsDisabled($ownName)); # Return without any further action if the module is disabled<br />
<br />
my $devName = $dev_hash->{NAME}; # Device that created the events<br />
my $events = deviceEvents($dev_hash, 1);<br />
<br />
if($devName eq "global" && grep(m/^INITIALIZED|REREADCFG$/, @{$events}))<br />
{<br />
X_FunctionWhoNeedsAttr($hash);<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
Dadurch wird die Modulfunktion X_FunctionWhoNeedsAttr() nach dem Start erst aufgerufen, wenn alle Attribute aus der Konfiguration geladen wurden.<br />
<br />
<br />
<u>Nutzung von parseParams()</u><br />
<br />
Zum Aufteilen und Parsen von <code>$def</code> lässt sich die Funktion [[DevelopmentModuleAPI#parseParams|parseParams()]] verwenden um die einzelnen Argumente einfach zu parsen. Wenn in [[#X_Initialize|X_Initialize()]] <code>$hash->{parseParams} = 1;</code> gesetzt wurde dann wird parseParams() automatisch aufgerufen und X_Define() ändert sich wie folgt:<br />
<syntaxhighlight lang="perl"><br />
sub X_Define($$$)<br />
{<br />
my ( $hash, $a, $h ) = @_;<br />
...<br />
</syntaxhighlight><br />
<br />
Die genauen Möglichkeiten von parseParams() sind in dem entsprechenden [[DevelopmentModuleAPI#parseParams|Artikel]] dokumentiert.<br />
<br />
==== X_Undef ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Undef ($$)<br />
{<br />
my ( $hash, $name ) = @_;<br />
<br />
...<br />
<br />
return $error;<br />
}<br />
</syntaxhighlight><br />
Die Undef-Funktion wird aufgerufen wenn ein Gerät mit <code>delete</code> gelöscht wird oder bei der Abarbeitung des Befehls <code>rereadcfg</code>, der ebenfalls alle Geräte löscht und danach das Konfigurationsfile neu einliest. Entsprechend müssen in der Funktion typische Aufräumarbeiten durchgeführt werden wie das saubere Schließen von Verbindungen oder das Entfernen von internen Timern, sofern diese im Modul zum Pollen verwendet wurden (siehe Abschnitt [[#Pollen_von_Geräten|Pollen von Geräten]]). <br />
<br />
Zugewiesene Variablen im Hash der Geräteinstanz, Internals oder Readings müssen hier nicht gelöscht werden. In fhem.pl werden die entsprechenden Strukturen beim Löschen der Geräteinstanz ohnehin vollständig gelöscht.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="perl"><br />
sub X_Undef($$) <br />
{ <br />
my ( $hash, $name) = @_; <br />
DevIo_CloseDev($hash); <br />
RemoveInternalTimer($hash); <br />
return undef; <br />
}<br />
</syntaxhighlight><br />
<br />
Sollten im Rahmen der Undef-Funktion Probleme festgestellt werden, die ein Löschen nicht zulassen, so ist als Funktionsrückgabewert eine entsprechende Fehlermeldung zurückzugeben. Nur wenn die Undef-Funktion erfolgreich durchgeführt wurde, darf <code>undef</code> zurückgegeben werden. Nur dann wird eine Gerätedefinition von FHEM auch tatsächlich gelöscht bzw. neu angelegt. Sollte die Undef-Funktion jedoch eine Fehlermeldung zurückgeben, wird der entsprechende Vorgang (<code>delete</code> bzw. <code>rereadcfg</code>) für dieses Gerät abgebrochen. Es bleibt dann unverändert in FHEM bestehen.<br />
<br />
==== X_Delete ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Delete ($$)<br />
{<br />
my ( $hash, $name ) = @_;<br />
<br />
...<br />
<br />
return $error;<br />
}<br />
</syntaxhighlight><br />
<br />
Die Delete-Funktion ist das Gegenstück zur Funktion [[#X_Define|X_Define]] und wird aufgerufen wenn ein Gerät mit dem Befehl <code>delete</code> gelöscht wird. <br />
<br />
Wenn ein Gerät in FHEM gelöscht wird, wird zuerst die Funktion [[#X_Undef|X_Undef]] aufgerufen um offene Verbindungen zu schließen, anschließend wird die Funktion X_Delete aufgerufen. Diese dient eher zum Aufräumen von dauerhaften Daten, welche durch das Modul evtl. für dieses Gerät spezifisch erstellt worden sind. Es geht hier also eher darum, alle Spuren sowohl im laufenden FHEM-Prozess, als auch dauerhafte Daten bspw. im physikalischen Gerät zu löschen die mit dieser Gerätedefinition zu tun haben.<br />
<br />
Dies kann z.B. folgendes sein:<br />
<br />
* Löschen von Dateien im Dateisystem die während der Nutzung dieses Geräts angelegt worden sind.<br />
* Lösen von evtl. Pairings mit dem physikalischen Gerät <br />
<br />
Beispiel:<br />
<syntaxhighlight lang="perl"><br />
sub X_Delete($$) <br />
{ <br />
my ( $hash, $name ) = @_; <br />
<br />
# Löschen von Geräte-assoziiertem Temp-File<br />
unlink($attr{global}{modpath}."/FHEM/FhemUtils/$name.tmp";)<br />
<br />
return undef;<br />
} <br />
</syntaxhighlight><br />
<br />
Sollten im Rahmen der Delete-Funktion Probleme festgestellt werden, die ein Löschen nicht zulassen, so ist als Funktionsrückgabewert eine entsprechende Fehlermeldung zurückzugeben. Nur die Delete-Funktion erfolgreich durchgeführt wurde, darf <code>undef</code> zurückgegeben werden. Nur dann wird eine Gerätedefinition von FHEM auch tatsächlich gelöscht. Sollte die Delete-Funktion eine Fehlermeldung zurückgeben, wird der Löschvorgang abgebrochen und das Gerät bleibt weiter in FHEM bestehen.<br />
<br />
==== X_Get ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Get ($$@)<br />
{<br />
my ( $hash, $name, $opt, @args ) = @_;<br />
<br />
...<br />
<br />
return $result;<br />
}<br />
</syntaxhighlight><br />
Die Get-Funktion wird aufgerufen wenn der FHEM-Befehl <code>get</code> mit einem Gerät dieses Moduls ausgeführt wird. Mit <code>get</code> werden typischerweise Werte von einem Gerät abgefragt. In vielen Modulen wird auf diese Weise auch der Zugriff auf generierte Readings ermöglicht. Der Get-Funktion wird dabei der Geräte-Hash, der Gerätename, sowie die Aufrufparameter des get-Befehls übergeben. Als Rückgabewert wird das Ergebnis des entsprechenden Befehls in Form einer Zeichenkette zurückgegeben. Der Rückgabewert <code>undef</code> hat hierbei keine besondere Bedeutung und wird behandelt wie eine leere Zeichenkette <code>""</code>.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Get($$@)<br />
{<br />
my ( $hash, $name, $opt, @args ) = @_;<br />
<br />
return "\"get $name\" needs at least one argument" unless(defined($opt));<br />
<br />
if($opt eq "status") <br />
{<br />
...<br />
}<br />
elsif($opt eq "power")<br />
{<br />
...<br />
}<br />
...<br />
else<br />
{<br />
return "Unknown argument $opt, choose one of status power [...]";<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn eine unbekannte Option an die Get-Funktion übergeben wird, so muss als Rückgabewert der Funktion eine bestimmte Syntax einhalten um FHEM mitzuteilen, welche Optionen für einen Get-Befehl aktuell unterstützt werden. Die Rückgabe muss dabei folgender Syntax entsprechen:<br />
<br />
<code>'''unknown''' argument ''<font color="grey">[Parameter]</font>'' '''choose one of''' ''<font color="grey">[Liste möglicher Optionen]</font>''</code><br />
<br />
Hierbei sind die fett gedruckten Teile der Rückmeldung besonders wichtig. Sind diese nicht vorhanden, kann FHEM nicht die möglichen Get-Kommandos für das entsprechende Gerät ermitteln. Es muss am Anfang der Meldung das Stichwort "unknown" vorkommen gefolgt von einer frei definierbaren Fehlermeldung (i.d.R der übergebene Parameter, welcher ungültig ist). Anschließend folgt "choose one of" mit einer anschließenden Liste möglicher Optionen getrennt durch ein Leerzeichen. <br />
<br />
Beispiel:<br />
<ul><br />
<syntaxhighlight lang="perl">return "unknown argument $opt choose one of status temperature humidity";</syntaxhighlight><br />
<br />
Hier werden als mögliche Optionen für einen Get-Befehl folgende Parameter angegeben:<br />
<br />
* <code>status</code><br />
* <code>temperature</code><br />
* <code>humidity</code><br />
<br />
Dies würde in folgenden, mögliche Get-Befehle für einen User resultieren:<br />
<br />
* <code>get ''&lt;NAME&gt;'' status</code><br />
* <code>get ''&lt;NAME&gt;'' temperature</code><br />
* <code>get ''&lt;NAME&gt;'' humidity</code><br />
</ul><br />
<br />
Die Ausgabe einer solchen Meldung ist sehr wichtig, da sie im GUI-Modul verwendet wird um die möglichen <code>get</code>-Optionen zu ermitteln und als Auswahl anzubieten. Im weiteren Verlauf der Get-Funktion könnte man dann mit dem physischen Gerät kommunizieren und den gefragten Wert direkt abfragen und diesen als Return-Wert der Get-Funktion zurückgeben.<br />
<br />
<br />
<u>Nutzung von parseParams()</u><br />
<br />
Wenn in [[#X_Initialize|X_Initialize()]] <code>$hash->{parseParams} = 1;</code> gesetzt wurde dann wird [[DevelopmentModuleAPI#parseParams|parseParams()]] automatisch aufgerufen und X_Get() ändert sich wie folgt:<br />
<syntaxhighlight lang="perl"><br />
sub X_Get($$$)<br />
{<br />
my ( $hash, $a, $h ) = @_;<br />
...<br />
</syntaxhighlight><br />
<br />
Die genauen Möglichkeiten von parseParams() sind in dem entsprechenden [[DevelopmentModuleAPI#parseParams|Artikel]] dokumentiert.<br />
<br />
==== X_Set ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Set ($$@)<br />
{<br />
my ( $hash, $name, $cmd, @args ) = @_;<br />
<br />
...<br />
<br />
return $error;<br />
return ($error, $skip_trigger);<br />
}<br />
</syntaxhighlight><br />
<br />
Die Set-Funktion ist das Gegenteil zur [[#X_Get|Get]]-Funktion. Sie ist dafür gedacht, Daten zum physischen Gerät zu schicken, bzw. entsprechende Aktionen im Gerät selber auszulösen. Ein Set-Befehl dient daher der direkten Steuerung des physikalischen Gerätes in dem es bspw. Zustände verändert (wie <code>on</code>/<code>off</code>). Der Set-Funktion wird dabei der Geräte-Hash, der Gerätename, sowie die Aufrufparameter des set-Befehls übergeben. Als Rückgabewert kann eine Fehlermeldung in Form Zeichenkette zurückgegeben werden. Der Rückgabewert <code>undef</code> bedeutet hierbei, dass der Set-Befehl erfolgreich durchgeführt wurde. Eine Set-Funktion gibt daher nur im Fehlerfall eine Rückmeldung mit einer entsprechenden Fehlermeldung. Der Wert <code>undef</code> wird als "erfolgreich" interpretiert. <br />
<br />
Standardmäßig wird jeder Set-Befehl, welcher erfolgreich ausgeführt wurde (<code>$error</code> ist <code>undef</code>), als Event getriggert um dies bspw. in einem FileLog festzuhalten. Dieses Verhalten kann optional unterbunden werden indem der zweite Rückgabewert <code>$skip_trigger</code> auf <code>1</code> gesetzt wird. Damit wird das Generieren eines Events für das erfolgreich ausgeführte Set-Kommando unterbunden. Falls nicht gesetzt, wird ein Event erzeugt (<code>$cmd</code> mit sämtlichen <code>@args</code>).<br />
<br />
Rückmeldungen (Fehler) von set-Befehlen sämtlicher Module, die im Rahmen eines ausgeführten [[Notify]] auftreten werden im FHEM Logfile festgehalten.<br />
<br />
Falls nur interne Daten, die ausschließlich für das Modul relevant sind, gesetzt werden müssen, so sollte statt Set die [[#X_Attr|Attr]]-Funktion verwendet werden. Attribute werden bei Save-Config auch in der Fhem.cfg gesichert. Set-Befehle nicht, da sie nur zur Steuerungszwecken im laufenden Betrieb von FHEM dienen.<br />
<br />
Eine Set-Funktion ist ähnlich aufgebaut wie die Get-Funktion, sie bekommt jedoch in der Regel weitere zusätzliche Parameter übergeben um Zustände zu setzen. <br />
<br />
Beispiel:<br />
<syntaxhighlight lang="perl"><br />
sub X_Set($@)<br />
{<br />
my ( $hash, $name, $cmd, @args ) = @_;<br />
<br />
return "\"set $name\" needs at least one argument" unless(defined($cmd));<br />
<br />
if($cmd eq "status")<br />
{<br />
if($args[0] eq "up")<br />
{<br />
...<br />
}<br />
elsif($args[0] eq "down")<br />
{<br />
...<br />
}<br />
else<br />
{<br />
return "Unknown value $args[0] for $cmd, choose one of status power";<br />
} <br />
}<br />
elsif($cmd eq "power")<br />
{<br />
if($args[0] eq "on")<br />
{<br />
...<br />
}<br />
elsif($args[0] eq "off")<br />
{<br />
...<br />
} <br />
else<br />
{<br />
return "Unknown value $args[0] for $cmd, choose one of status power";<br />
} <br />
}<br />
...<br />
else<br />
{<br />
return "Unknown argument $cmd, choose one of status power";<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn eine unbekannte Option an die Set-Funktion übergeben wird, so muss als Rückgabewert der Funktion eine bestimmte Syntax eingehalten werden um FHEM mitzuteilen, welche Optionen für einen Set-Befehl aktuell unterstützt werden. Die Rückgabe muss dabei folgender Syntax entsprechen:<br />
<br />
<code>'''unknown''' argument ''<font color="grey">[Parameter]</font>'' '''choose one of''' ''<font color="grey">[Liste möglicher Optionen]</font>''</code><br />
<br />
Hierbei sind die fett gedruckten Teile der Rückmeldung besonders wichtig. Sind diese nicht vorhanden, kann FHEM nicht die möglichen Set-Kommandos für das entsprechende Gerät ermitteln. Es muss am Anfang der Meldung das Stichwort "unknown" vorkommen gefolgt von einer frei definierbaren Fehlermeldung (i.d.R der übergebene Parameter, welcher ungültig ist). Anschließend folgt "choose one of" mit einer anschließenden Liste möglicher Optionen getrennt durch ein Leerzeichen. <br />
<br />
Beispiel:<br />
<ul><br />
<syntaxhighlight lang="perl">return "unknown argument $cmd choose one of status power";</syntaxhighlight><br />
<br />
Hier werden als mögliche Optionen für einen Set-Befehl folgende Parameter angegeben:<br />
<br />
* <code>status</code><br />
* <code>power</code><br />
<br />
Dies würde in folgenden, mögliche Set-Befehle für einen User resultieren:<br />
<br />
* <code>set ''&lt;NAME&gt;'' status</code><br />
* <code>set ''&lt;NAME&gt;'' power</code><br />
</ul><br />
<br />
Die Ausgabe einer solchen Meldung ist sehr wichtig, da sie im Modul [[FHEMWEB]] verwendet wird um die möglichen <code>set</code>-Optionen zu ermitteln und als Auswahl anzubieten.<br />
<br />
<br />
<u>Nutzung von SetExtensions.pm</u><br />
<br />
Wenn man dem Nutzer zusätzlich zu den Set-Befehlen <code>on</code> und <code>off</code> auch weiterführende Befehle wie <code>on-for-timer</code>, <code>on-till</code>, usw. anbieten möchte, obwohl die zu steuernde Hardware solche Kommandos nicht unterstützt, kann man dies über das Hilfsmodul SetExtensions.pm realisieren.<br />
<br />
Das Hilfsmodul SetExtensions.pm bietet weiterführende Set-Kommandos basierend auf den Befehlen <code>on</code>/<code>off</code> an. Dabei werden durch interne Timer bzw. eigens angelegten [[at]]-Definitionen diese Befehle durch FHEM selber umgesetzt. Je nach ausgeführtem Befehl wird der <code>on</code>- bzw. <code>off</code>-Befehl dann durch FHEM zum richtigen Zeitpunkt ausgeführt. Vorausgesetzt das Modul unterstützt in der Set-Funktion die Befehle <code>on</code> und <code>off</code>, so werden durch den Einsatz von SetExtensions.pm folgende Befehle zusätzlich unterstützt:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Set-Kommando !! Beispiel !! Beschreibung<br />
|-<br />
| style="white-space: nowrap;" | <code>on-for-timer ''&lt;Dauer&gt;''</code> || style="white-space: nowrap;" | <code>on-for-timer 120</code> || Schaltet das Gerät sofort mit dem <code>on</code>-Befehl ein und nach der angegebenen Dauer in Sekunden via <code>off</code> wieder aus.<br />
|-<br />
| style="white-space: nowrap;" | <code>off-for-timer ''&lt;Dauer&gt;''</code> || style="white-space: nowrap;" | <code>off-for-timer 120</code> || Schaltet das Gerät sofort mit dem <code>off</code>-Befehl aus und nach der angegebenen Dauer in Sekunden via <code>on</code> wieder ein.<br />
|-<br />
| style="white-space: nowrap;" | <code>on-till ''&lt;Zeitpunkt&gt;''</code> || style="white-space: nowrap;" | <code>on-till 16:30</code> || Schaltet das Gerät sofort mit dem <code>on</code>-Befehl ein und zum angegebenen Zeitpunkt via <code>off</code> wieder aus.<br />
|-<br />
| style="white-space: nowrap;" | <code>off-till ''&lt;Zeitpunkt&gt;''</code> || style="white-space: nowrap;" | <code>off-till 16:30</code> || Schaltet das Gerät sofort mit dem <code>off</code>-Befehl aus und zum angegebenen Zeitpunkt via <code>on</code> wieder ein.<br />
|-<br />
| style="white-space: nowrap;" | <code>on-till-overnight ''&lt;Zeitpunkt&gt;''</code> || style="white-space: nowrap;" | <code>on-till-overnight 01:00</code> || Ähnlich wie <code>on-till</code>. Der übergebene Zeitpunkt wird aber nicht geprüft, ob er für den heutigen Tag bereits überschritten wurde. Dadurch kann man Abends einen Zeitpunkt setzen, der erst am nächsten Tag zutrifft.<br />
|-<br />
| style="white-space: nowrap;" | <code>off-till-overnight ''&lt;Zeitpunkt&gt;''</code> || style="white-space: nowrap;" | <code>off-till-overnight 01:00</code> || Ähnlich wie <code>off-till</code>. Der übergebene Zeitpunkt wird aber nicht geprüft, ob er für den heutigen Tag bereits überschritten wurde. Dadurch kann man Abends einen Zeitpunkt setzen, der erst am nächsten Tag zutrifft.<br />
|-<br />
| style="white-space: nowrap;" | <code>blink ''&lt;Anzahl&gt; &lt;Interval&gt;''</code> || style="white-space: nowrap;" | <code>blink 3 1</code> || Schaltet das Gerät via <code>on</code> für <code>''&lt;Interval&gt;''</code> Sekunden ein und anschließend via <code>off</code> wieder aus. Nach <code>''&lt;Interval&gt;''</code> Sekunden wird das ganze wiederholt, solange bis die angegebene Anzahl erreicht ist.<br />
|-<br />
| style="white-space: nowrap;" | <code>intervals ''&lt;Start&gt;-&lt;Ende&gt;'' ''&lt;Start&gt;-&lt;Ende&gt;'' ...</code> || style="white-space: nowrap;" | <code>intervals 07:00-08:00 16:30-18:00</code> || Schaltet das Gerät innerhalb der übergebenen Zeiträumen via <code>on</code> ein. Sobald die aktuelle Zeit ausserhalb dieser Zeiträume liegt, wird das Gerät via <code>off</code> wieder ausgeschaltet. Es können dabei beliebig viele Zeiträume angegeben werden.<br />
|-<br />
| style="white-space: nowrap;" | <code>toggle</code> || style="white-space: nowrap;" | <code>toggle</code> || Sofern der aktuelle Status <code>on</code> ist, wird das Gerät via <code>off</code> ausgeschaltet. Andernfalls wird es via <code>on</code> eingeschaltet.<br />
|}<br />
<br />
Eine kurze Beschreibung zu den möglichen Befehlen durch SetExtensions.pm gibt es auch in der commandref zum {{Link2CmdRef|Anker=set|Label=set-Befehl}}.<br />
<br />
Um SetExtensions.pm in der Set-Funktion nutzen zu können müssen folgende Aktionen durchgeführt werden:<br />
<br />
# Laden von SetExtensions.pm via <code>use SetExtensions;</code> am Anfang des Moduls<br />
# Aufruf und Rückgabe der Funktion [[DevelopmentModuleAPI#SetExtensions|SetExtensions()]] sofern die Set-Funktion mit dem übergebenen Befehl nichts anfangen kann.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="perl"><br />
use SetExtensions;<br />
<br />
...<br />
<br />
sub X_Set($@)<br />
{<br />
my ( $hash, $name, $cmd, @args ) = @_;<br />
my $cmdList = "on off";<br />
<br />
return "\"set $name\" needs at least one argument" unless(defined($cmd));<br />
<br />
if($cmd eq "on")<br />
{<br />
# Gerät einschalten...<br />
}<br />
elsif($cmd eq "off")<br />
{<br />
# Gerät ausschalten...<br />
}<br />
...<br />
else # wenn der übergebene Befehl nicht durch X_Set() verarbeitet werden kann, Weitergabe an SetExtensions()<br />
{<br />
return SetExtensions($hash, $cmdList, $name, $cmd, @args);<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
Sollte der übergebene Set-Befehl auch für SetExtensions unbekannt sein (bspw. <code>set ''&lt;Name&gt;'' ?</code>), so generiert SetExtensions() eine entsprechende Usage-Meldung, welche innerhalb der Set-Funktion an FHEM zurückgegeben werden muss.<br />
<br />
Eine ausführliche Beschreibung zu der Funktion SetExtensions() gibt es in der [[DevelopmentModuleAPI#SetExtensions|API-Referenz]].<br />
<br />
<br />
<br />
<u>Nutzung von parseParams()</u><br />
<br />
Wenn in [[#X_Initialize|X_Initialize()]] <code>$hash->{parseParams} = 1;</code> gesetzt wurde dann wird [[DevelopmentModuleAPI#parseParams|parseParams()]] automatisch aufgerufen und X_Set() ändert sich wie folgt:<br />
<syntaxhighlight lang="perl"><br />
sub X_Set($$$)<br />
{<br />
my ( $hash, $a, $h ) = @_;<br />
...<br />
</syntaxhighlight><br />
<br />
Die genauen Möglichkeiten von parseParams() sind in dem entsprechenden [[DevelopmentModuleAPI#parseParams|Artikel]] dokumentiert.<br />
<br />
<br />
<u>Nutzung von FHEMWEB-Widgets</u><br />
<br />
Das GUI-Modul [[FHEMWEB]] kann für die einzelnen Set-Optionen, die das Modul versteht, automatisch Eingabehilfen wie Drop-Down Boxen oder Slider erzeugen. In der Detailansicht der GUI kann der Anwender dann die jeweiligen Werte komfortabel auswählen. Dafür muss die Set-Funktion, wenn sie mit der Option <code>?</code> aufgerufen wird, nicht nur einen Text mit <code>"Unknown ... choose one of ..."</code> zurückgeben sondern den einzelnen Set-Optionen in diesem Rückgabetext nach einem Doppelpunkt entsprechende Zusatzinformationen anhängen.<br />
Meist prüft man in den Modulen gar nicht auf die Option <code>?</code> sondern gibt generell bei unbekannten Optionen diesen Text zurück. Das Modul FHEMWEB ermittelt die Syntax eines Gerätes jedoch immer mit dem Befehl:<br />
set ''&lt;NAME&gt;'' ?<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="perl"><br />
return "Unknown argument $cmd, choose one of status:up,down power:on,off on:noArg off:noArg";<br />
</syntaxhighlight><br />
<br />
Mit Kommata getrennte Werte ergeben eine Drop-Down Liste, mit der der User die Werte auswählen kann<br />
<pre>timer:30,120,300<br />
mode:verbose,ultra,relaxed</pre><br />
<br />
Wird kein Doppelpunkt zum Kommando angegeben, so wird eine Eingabezeile angezeigt, die die freie Eingabe eines Wertes erlaubt.<br />
<br />
Man kann jedoch die Eingabe-/Auswahlmöglichkeiten durch Widgets vereinfachen. Dazu gibt man hinter dem Doppelpunkt einen Widgetnamen und widgetspezifische Parameter an. Es existieren mehrere solcher Widgets in FHEMWEB. Die gebräuchlichsten sind:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Zusatz !! Beispiel !! Beschreibung<br />
|-<br />
| '''noArg''' || <code>reset:noArg</code>|| Es werden keine weiteren Argumente mehr benötigt. In so einem Fall wird bei der Auswahl keine Textbox oder ähnliches angezeigt, da keine weiteren Argumente für diesen Befehl notwendig sind.<br />
|-<br />
| '''slider''',<min>,<step>,<max> || <code>dim:slider,0,1,100</code>|| Es wird ein Schieberegler angezeigt um den Parameter auszuwählen. Dabei werden als Zusatzparameter Minimum, Schrittweite und Maximum angegeben.<br />
|-<br />
| '''colorpicker''' || <code>rgb:colorpicker,RGB</code>|| Es wird ein Colorpicker angezeigt, der dem Anwender die Auswahl einer Farbe ermöglicht. Die genaue Parametersyntax kann man dem Artikel zum [[Color#Colorpicker|Colorpicker]] entnehmen.<br />
|-<br />
| '''multiple''' || <code>group:multiple,Telefon,Multimedia,Licht,Heizung</code> || Es erscheint ein Auswahldialog, wo man verschiedene Werte durch klicken auswählen kann. Optional kann man in einem Freitext eigene Werte ergänzen. dieser Dialog wird bspw. bei der Raum-Auswahl (Attribut "room") oder der Gruppen-Auswahl (Attribut "group") in FHEMWEB genutzt. <br />
|-<br />
| '''sortable''' || <code>command:sortable,monday,tuesday,...</code> || Es erscheint ein Auswahldialog, wo man verschiedene Werte auswählen und sortieren kann. Man kann dabei Werte durch Klicken auswählen und durch Drag'n'Drop sortieren.<br />
|}<br />
<br />
Es gibt noch weitere solcher Widgets. Eine genaue Auflistung dazu findet sich in der {{Link2CmdRef|Anker=widgetOverride}} unter widgetOverride zu FHEMWEB.<br />
<br />
'''Hinweise'''<br />
<br />
* Damit in einer Eingabe bereits der aktuelle Wert vorbelegt bzw. in einer Auswahlliste der aktuelle Wert vorselektiert ist, muss es im Modul bzw. Gerät ein Reading mit dem gleichen Namen wie die Set-Option geben. Der Wert des gleichnamigen Readings wird dann als Vorbelegung / Vorselektion verwendet. <br />
* Der User kann sich in der Raumübersicht nach wie vor via [[WebCmd|webCmd]] eine entsprechende Steuerung anlegen.<br />
<br />
==== X_Attr ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Attr($$$$)<br />
{<br />
my ( $cmd, $name, $attrName, $attrValue ) = @_;<br />
<br />
...<br />
<br />
return $error;<br />
}<br />
</syntaxhighlight><br />
<br />
Die Attr-Funktion dient der Prüfung von Attributen, welche über den <code>attr</code>-Befehl gesetzt werden können. Sobald versucht wird, ein Attribut für ein Gerät zu setzen, wird vorher die Attr-Funktion des entsprechenden Moduls aufgerufen um zu prüfen, ob das Attribut aus Sicht des Moduls korrekt ist.<br />
Liegt ein Problem mit dem Attribut bzw. dem Wert vor, so muss die Funktion eine aussagekräftige Fehlermeldung zurückgeben, welche dem User angezeigt wird.<br />
Sofern das übergebene Attribut samt Inhalt korrekt ist, gibt die Attr-Funktion den Wert <code>undef</code> zurück. Erst dann wird das Attribut in der globalen Datenstruktur <code>%attr</code> gespeichert und ist somit erst aktiv.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Attr($$$$)<br />
{<br />
my ( $cmd, $name, $attrName, $attrValue ) = @_;<br />
<br />
# $cmd - Vorgangsart - kann die Werte "del" (löschen) oder "set" (setzen) annehmen<br />
# $name - Gerätename<br />
# $attrName/$attrValue sind Attribut-Name und Attribut-Wert<br />
<br />
if ($cmd eq "set") {<br />
if ($aName eq "Regex") {<br />
eval { qr/$aVal/ };<br />
if ($@) {<br />
Log3 $name, 3, "X ($name) - Invalid regex in attr $name $aName $aVal: $@";<br />
return "Invalid Regex $aVal: $@";<br />
}<br />
}<br />
}<br />
return undef;<br />
}<br />
</syntaxhighlight><br />
<br />
Zusätzlich ist es möglich auch übergebene Attributwerte zu verändern bzw. zu korrigieren, indem man im Parameterarray <code>@_</code> den ursprünglichen Wert anpasst. Dies erfolgt im Beispiel über die Modifikation des Wertes mit Index 3 (entspricht dem 4. Element) im Parameterarray, also <code>$_[3]</code>.<br />
<br />
Da das Attribut zum Zeitpunkt des Aufrufs der Attr-Funktion noch nicht gespeichert ist, wird der neue Wert zu diesem Zeitpunkt noch nicht via [[DevelopmentModuleAPI#AttrVal|AttrVal()]] zurückgegeben. Erst, wenn die Attr-Funktion mit <code>undef</code> beendet ist, wird der neue Wert in FHEM gespeichert und steht dann via AttrVal() zur Verfügung.<br />
<br />
Die Attr-Funktion bekommt nicht den Hash der Geräteinstanz übergeben, da sie normalerweise keine Werte dort speichern muss, sondern lediglich das Attribut auf Korrektheit prüfen muss.<br />
Im obigen Beispiel wird für ein Attribut mit Namen "Regex" geprüft ob der reguläre Ausdruck fehlerhaft ist. Sofern dieser OK ist, wird <code>undef</code> zurückgegeben und fhem.pl speichert den Wert des Attributs in <code>%attr</code>.<br />
<br />
<br />
<u>Attributnamen mit Platzhaltern</u><br />
<br />
Falls man Attribute in der [[#X_Initialize|Initialize]]-Funktion mit Platzhaltern definiert (Wildcard-Attribute) wie z.B.:<br />
<syntaxhighlight lang="perl"><br />
$hash->{AttrList} =<br />
"reading[0-9]*Name " .<br />
# usw.<br />
</syntaxhighlight><br />
dann können Anwender Attribute wie reading01Name, reading02Name etc. setzen. Leider funktioniert das bisher nicht durch Klicken in der Web-Oberfläche, da FHEMWEB nicht alle denkbaren Ausprägungen in einem Dropdown anbieten kann. Der Benutzer muss solche Attribute manuell über den <code>attr</code>-Befehl eingeben.<br />
<br />
Man kann jedoch in der Attr-Funktion neu gesetzte Ausprägungen von Wildcard-Attributen an die gerätespezifische userattr-Variable anfügen. Dann können bereits gesetzte Attribute in FHEMWEB durch Klicken ausgewählt und geändert werden.<br />
Dazu reicht ein Aufruf der Funktion [[DevelopmentModuleAPI#addToDevAttrList|addToDevAttrList()]]: <br />
<br />
<syntaxhighlight lang="perl"><br />
addToDevAttrList($name, $aName);<br />
</syntaxhighlight><br />
<br />
==== X_Read ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Read ($)<br />
{<br />
my ( $hash ) = @_;<br />
<br />
...<br />
}<br />
</syntaxhighlight><br />
Die X_Read-Funktion wird aufgerufen, wenn ein dem Gerät zugeordneter Filedeskriptor (serielle Schnittstelle, TCP-Verbindung, ...) Daten zum Lesen bereitgestellt hat. Die Daten müssen nun eingelesen und interpretiert werden.<br />
<br />
Im folgenden Beispiel wird über eine serielle Schnittstelle (beziehungsweise über einen USB-To-Serial-Konverter) von einem angeschlossenen Gerät gelesen. Dazu werden die bisher verfügbaren Daten mit der Funktion [[DevIo#DevIo_SimpleRead()|DevIo_SimpleRead()]] gelesen. Da die Übertragung möglicherweise noch nicht vollständig ist, kann es sein, dass kurz darauf die X_Read-Funktion wieder aufgerufen wird und ein weiterer Teil oder der Rest der Daten gelesen werden kann.<br />
Die Funktion muss daher prüfen ob schon alle erwarteten Daten angekommen sind und gegebenenfalls die bisher gelesenen Daten in einem eigenen Puffer (idealerweise in <code>$hash</code>) zwischenspeichern (siehe auch [[DevIo#Hinweis bei der Datenverarbeitung (Buffering)|DevIo]]). Im Beispiel ist dies <code>$hash->{helper}{BUFFER}</code> an den die aktuell gelesenen Daten angehängt werden, bis die folgende Prüfung ein für das jeweilige Protokoll vollständige Frame erkennt.<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Read($)<br />
{<br />
my ($hash) = @_;<br />
my $name = $hash->{NAME};<br />
<br />
# einlesen der bereitstehenden Daten<br />
my $buf = DevIo_SimpleRead($hash); <br />
return "" if ( !defined($buf) );<br />
Log3 $name, 5, "X ($name) - received data: ".$buf; <br />
<br />
# Daten in Hex konvertieren und an den Puffer anhängen<br />
$hash->{helper}{BUFFER} .= unpack ('H*', $buf); <br />
Log3 $name, 5, "X ($name) - current buffer content: ".$hash->{helper}{BUFFER};<br />
<br />
# prüfen, ob im Buffer ein vollständiger Frame zur Verarbeitung vorhanden ist.<br />
if ($hash->{helper}{BUFFER} =~ "ff1002(.{4})(.*)1003(.{4})ff(.*)") {<br />
...<br />
</syntaxhighlight><br />
<br />
Die zu lesenden Nutzdaten können dann je nach Protokoll des Geräts beispielsweise an einer festgelegten Stelle im Frame (dann in <code>$hash->{helper}{BUFFER}</code>) stehen oder aus dem Kontext mit einem Regex-Match extrahiert werden und via [[DevelopmentModuleAPI#Readings_.2F_Events|Reading-Funktionen]] in Readings gespeichert werden (siehe unten).<br />
<br />
Der Rückgabewert der Read-Funktion wird nicht geprüft und hat daher keinerlei Bedeutung.<br />
<br />
==== X_Ready ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Ready ($)<br />
{<br />
my ( $hash ) = @_;<br />
<br />
...<br />
<br />
return $success;<br />
}<br />
</syntaxhighlight><br />
<br />
Wird im Main-Loop aufgerufen falls das Modul in der globalen Liste <code>%readyfnlist</code> existiert. Diese Funktion hat, je nachdem auf welchem OS FHEM ausgeführt wird, unterschiedliche Aufgaben:<br />
<br />
* '''UNIX-artiges Betriebssystem:''' prüfen, ob eine Verbindung nach einem Verbindungsabbruch wieder aufgebaut werden kann. Sobald der Verbindungsaufbau erfolgreich war, muss die Funktion einen erfolgreichen Wahrheitswert zurückliefern (z.B. "1") und den eigenen Eintrag entsprechend aus <code>%readyfnlist</code> löschen.<br />
* '''Windows-Betriebssystem:''' prüfen, ob lesbare Daten für ein serielles Device (via COM1, COM2, ...) vorliegen. Sofern lesbare Daten vorliegen, muss Funktion einen erfolgreichen Wahrheitswert zurückliefern (z.B. "1"). Zusätzlich dazu muss die Funktion, wie bei UNIX-artigen Betriebssystem, ebenfalls bei einem Verbindungsabbruch einen neuen Verbindungsversuch initiieren. Der Eintrag in <code>%readyfnlist</code> bleibt solange erhalten, bis die Verbindung seitens FHEM beendet wird.<br />
<br />
Der Windows-spezifische Teil zur Datenprüfung ist dabei nur zu implementieren, wenn das Modul über eine serielle Verbindung kommuniziert.<br />
<br />
Bei der Nutzung des Moduls [[DevIo]] wird dem Modulentwickler der Umgang mit <code>%readyfnlist</code> abgenommen, da DevIo sich selbst um die entsprechenden Einträge kümmert und diese selbstständig wieder entfernt.<br />
<br />
In der Regel sieht eine Ready-Funktion immer gleich aus.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="perl"><br />
sub X_Ready($)<br />
{<br />
my ($hash) = @_;<br />
<br />
# Versuch eines Verbindungsaufbaus, sofern die Verbindung beendet ist.<br />
return DevIo_OpenDev($hash, 1, undef ) if ( $hash->{STATE} eq "disconnected" );<br />
<br />
# This is relevant for Windows/USB only<br />
if(defined($hash->{USBDev})) {<br />
my $po = $hash->{USBDev};<br />
my ( $BlockingFlags, $InBytes, $OutBytes, $ErrorFlags ) = $po->status;<br />
return ( $InBytes > 0 );<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
==== X_Notify ====<br />
<br />
Die X_Notify-Funktion wird aus der Funktion [[DevelopmentModuleAPI#DoTrigger|DoTrigger()]] in fhem.pl heraus aufgerufen sobald ein Modul Events erzeugt hat. Damit kann ein Modul auf Events anderer Module reagieren. Typische Beispiele sind dabei das [[FileLog]]-Modul oder das [[notify]]-Modul.<br />
<br />
Die Notify-Funktion bekommt dafür zwei Hash-Referenzen übergeben: den Hash des eigenen Geräts und den Hash des Geräts, das die Events erzeugt hat. <br />
Über den Hash des eigenen Geräts kann die Notify-Funktion beispielsweise auf die Internals oder Attribute des eigenen Geräts zugreifen.<br />
Über den Hash des Gerätes und der [[DevelopmentModuleAPI#deviceEvents|deviceEvents()]]-Funktion kann man auf die generierten Events zugreifen. Über den zweiten Parameter dieser Routine lässt sich bestimmen ob für das Reading <code>state</code> ein 'normales' Event (d.h. in der form <code>state: <wert></code>) erzeugen soll (Wert: 1) oder ob z.b. aus Gründen der Rückwärtskompatibilität ein Event ohne <code>state: </code> erzeugt werden soll. Falls dem Anwender die Wahl des verwendeten Formats überlassen werden soll ist hierzu das {{Link2CmdRef|Anker=addStateEvent|Lang=de|Label=addStateEvent-Attribut}} vorzusehen.<br />
<br />
Der direkte Zugriff auf <code>$hash->{CHANGED}</code> ist nicht mehr zu empfehlen.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="perl"><br />
sub X_Notify($$)<br />
{<br />
my ($own_hash, $dev_hash) = @_;<br />
my $ownName = $own_hash->{NAME}; # own name / hash<br />
<br />
return "" if(IsDisabled($ownName)); # Return without any further action if the module is disabled<br />
<br />
my $devName = $dev_hash->{NAME}; # Device that created the events<br />
<br />
my $events = deviceEvents($dev_hash,1);<br />
return if( !$events );<br />
<br />
foreach my $event (@{$events}) {<br />
$event = "" if(!defined($event));<br />
<br />
# Examples:<br />
# $event = "readingname: value" <br />
# or<br />
# $event = "INITIALIZED" (for $devName equal "global")<br />
#<br />
# processing $event with further code<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
<u>Begrenzung der Aufrufe auf bestimmte Geräte</u><br />
<br />
Da die Notify-Funktion für jedes definierte Gerät mit all seinen Events aufgerufen wird, muss sie in einer Schleife jedesmal prüfen und entscheiden, ob es mit dem jeweiligen Event etwas anfangen kann. Ein Gerät, das die Notify-Funktion implementiert, sieht dafür typischerweise einen regulären Ausdruck vor, welcher für die Filterung verwendet wird.<br />
<br />
Wenn man nur gezielt von bestimmten Definitionen Events erhalten will, kann man diese auch in Form einer {{Link2CmdRef|Lang=de|Anker=devspec|Label=devspec}} in <code>$hash->{NOTIFYDEV}</code> angeben. Bspw. kann man in der Define-Funktion diesen Wert setzen. Dadurch wird die Notify-Funktion nur aufgerufen wenn eine der Definitionen, auf welche die devspec passt, ein Event erzeugt hat. Ein typischer Fall ist die Begrenzung von Events auf "global":<br />
<br />
<syntaxhighlight lang="perl"><br />
in der Define-Funktion:<br />
<br />
$hash->{NOTIFYDEV} = "global";<br />
$hash->{NOTIFYDEV} = "global,Definition_.*";<br />
$hash->{NOTIFYDEV} = "global,Definition_A,Definition_B";<br />
$hash->{NOTIFYDEV} = "global,TYPE=CUL_HM";<br />
</syntaxhighlight><br />
<br />
Dies schont insbesondere bei grossen Installationen Ressourcen, da die Notify-Funktion nicht sämtliche Events, sondern nur noch Events der gewünschten Definitionen erhält. Dadurch erfolgen deutlich weniger Aufrufe der Notify-Funktion, was Systemressourcen schont.<br />
<br />
Sofern in der [[#X_Define|Define-Funktion]] eine Regexp als Argument übergeben wird, die ähnlich wie beim Modul [[notify]] auf Events wie <code>&lt;Definitionsname&gt;</code> bzw. <code>&lt;Definitionsname&gt;:&lt;Event&gt;</code> reagiert, so sollte man in der Define-Funktion die Funktion [[DevelopmentModuleAPI#notifyRegexpChanged|notifyRegexpChanged()]] verwenden. Diese versucht einen passenden Eintrag für <code>$hash->{NOTIFYDEV}</code> basierend auf der übergebenen Regexp zu setzen, sofern dies möglich ist.<br />
<br />
<u>Reihenfolge für den Aufruf der Notify-Funktion beeinflussen</u><br />
<br />
Sobald ein Event ausgelöst wurde, stellt sich FHEM eine Liste aller relevanten Geräte-Hashes zusammen, welche via Notify-Funktion prüfen müssen, ob das Event relevant ist. Dabei wird die Liste nach <code>$hash->{NTFY_ORDER}</code> sortiert. Diese enthält ein Order-Präfix in Form einer Ganzzahl, sowie den Namen der Definition (Bsp: <code>'''50'''-Lampe_Wohnzimmer</code>). Dadurch kann man jedoch nicht sicherstellen, dass Events von bestimmten Modulen zuerst verarbeitet werden.<br />
<br />
Wenn das eigene Modul bei der Eventverarbeitung gegenüber den anderen Modulen eine bestimmte Reihenfolge einhalten muss, kann man in der [[#X_Initialize|Initialize]]-Funktion durch Setzen von <code>$hash->{NotifyOrderPrefix}</code> diese Reihenfolge beeinflussen. Standardmäßig werden Module immer mit einem Order-Präfix von "50-" in FHEM registriert. Durch die Veränderung dieses Präfixes kann man das eigene Modul in der Reihenfolge gegenüber anderen Modulen bei der Eventverarbeitung beeinflussen. <br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Initialize($)<br />
{<br />
my ($hash) = @_;<br />
<br />
...<br />
<br />
$hash->{NotifyOrderPrefix} = "45-" # Alle Definitionen des Moduls X werden bei der Eventverarbeitung zuerst geprüft<br />
<br />
# oder...<br />
<br />
$hash->{NotifyOrderPrefix} = "55-" # Alle Definitionen des Moduls X werden bei der Eventverarbeitung als letztes geprüft<br />
<br />
</syntaxhighlight> <br />
<br />
Da dieses Präfix bei eventverarbeitenden Definitionen in <code>$hash->{NTFY_ORDER}</code> dem Definitionsnamen vorangestellt wird bewirkt es bei einer normalen aufsteigenden Sortierung nach <code>$hash->{NTFY_ORDER}</code> eine veränderte Reihenfolge. Alle Module die in der Initialize-Funktion nicht <code>$hash->{NotifyOrderPrefix}</code> explizit setzen, werden mit "50-" als Standardwert vorbelegt.<br />
<br />
==== X_Rename ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Rename($$)<br />
{<br />
my ( $new_name, $old_name) = @_;<br />
<br />
...<br />
}<br />
</syntaxhighlight><br />
<br />
Die Rename-Funktion wird ausgeführt, nachdem ein Gerät umbenannt wurde. Auf diese Weise kann ein Modul auf eine Namensänderung reagieren, wenn das Gerät <code>$old_name</code> in <code>$new_name</code> umbenannt wurde. Ein typischer Fall ist das Umsetzen der Namensänderungen bei Daten die mittels [[DevelopmentModuleAPI#setKeyValue|setKeyValue()]] gespeichert wurden. Hierbei müssen die Daten, welche unter dem alten Namen gespeichert sind, auf den neuen Namen geändert werden.<br />
<br />
Der Rename-Funktion wird lediglich der alte, sowie der neue Gerätename übergeben. Der Rückgabewert wird nicht ausgewertet.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="perl"><br />
sub X_Rename($$)<br />
{<br />
my ( $new_name, $old_name ) = @_;<br />
<br />
my $old_index = "Module_X_".$old_name."_data";<br />
my $new_index = "Module_X_".$new_name."_data";<br />
<br />
my ($err, $data) = getKeyValue($old_index);<br />
return undef unless(defined($old_pwd));<br />
<br />
setKeyValue($new_index, $data);<br />
setKeyValue($old_index, undef);<br />
}<br />
</syntaxhighlight><br />
<br />
==== X_DelayedShutdown ====<br />
<syntaxhighlight lang="perl"><br />
sub X_DelayedShutdown($)<br />
{<br />
my ( $hash ) = @_;<br />
<br />
...<br />
<br />
return $delay_needed;<br />
}<br />
</syntaxhighlight><br />
Mit der X_DelayedShutdown Funktion kann eine Definition das Stoppen von FHEM verzögern um asynchron hinter sich aufzuräumen. Dies kann z.B. der ordnungsgemäße Verbindungsabbau mit dem physikalischen Gerät sein (z.B. Session beenden, Logout, etc.), welcher mehrfache Requests/Responses benötigt. Als Übergabeparameter wird der Geräte-Hash <code>$hash</code> bereitgestellt. Je nach Rückgabewert <code>$delay_needed</code> wird der Stopp von FHEM verzögert. Ist ein verzögerter Stopp von FHEM notwendig, darf der Rückgabewert in diesem Fall nicht <code>0</code> oder <code>undef</code> sein.<br />
<br />
Im Unterschied zur [[#X_Shutdown|Shutdown]]-Funktion steht vor einem bevorstehenden Stopp von FHEM für einen User-konfigurierbaren Zeitraum (global-Attribut: <code>maxShutdownDelay</code> / Standard: 10 Sekunden) weiterhin die asynchrone FHEM Infrastruktur ([[DevIo]]/[[#X_Read|Read]]-Funktion und [[DevelopmentModuleAPI#InternalTimer|InternalTimer]]) zur Verfügung.<br />
<br />
Sobald alle nötigen Maßnahmen erledigt sind, muss der Abschluss mit [[DevelopmentModuleAPI#CancelDelayedShutdown|CancelDelayedShutdown(<code>$name</code>)]] an FHEM zurückgemeldet werden.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="perl"><br />
sub X_DelayedShutdown($)<br />
{<br />
my ($hash) = @_;<br />
<br />
# Aufräumen starten<br />
<br />
return 1;<br />
}<br />
</syntaxhighlight><br />
<br />
==== X_Shutdown ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Shutdown ($)<br />
{<br />
my ( $hash ) = @_;<br />
<br />
...<br />
}<br />
</syntaxhighlight><br />
Mit der X_Shutdown Funktion kann ein Modul Aktionen durchführen bevor FHEM gestoppt wird. Dies kann z.B. der ordnungsgemäße Verbindungsabbau mit dem physikalischen Gerät sein (z.B. Session beenden, Logout, etc.). Nach der Ausführung der Shutdown-Fuktion wird FHEM sofort beendet. Falls vor dem Herunterfahren von FHEM asynchrone Kommunikation (via [[DevIo]]/[[#X_Read|X_Read]]) notwendig ist um eine vorhandene Verbindung sauber zu beenden, sollte man [[#X_DelayedShutdownFn|X_DelayedShutdownFn]] verwenden.<br />
<br />
Als Übergabeparameter wird der Geräte-Hash bereitgestellt. Der Rückgabewert einer Shutdown-Funktion wird nicht ausgewertet und ist daher irrelevant.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="perl"><br />
sub X_Shutdown($)<br />
{<br />
my ($hash) = @_;<br />
<br />
# Verbindung schließen<br />
DevIo_CloseDev($hash);<br />
return undef;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Funktionen für zweistufiges Modulkonzept ===<br />
<br />
Für das [[#Zweistufiges_Modell_für_Module|zweistufige Modulkonzept]] gibt es weiterhin:<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! style="text-align:left" | Funktionsname !! style="text-align:left" class="unsortable" | Kurzbeschreibung<br />
|-<br />
| [[#X_Parse|X_Parse]] || Zustellen von Daten via [[DevelopmentModuleAPI#Dispatch|Dispatch()]] vom physischen Modul zum logischen Modul zwecks der Verarbeitung.<br />
|-<br />
| [[#X_Write|X_Write]]|| Zustellen von Daten via [[DevelopmentModuleAPI#Dispatch|IOWrite()]] vom logischen zum physischen Modul um diese an die Hardware weiterzureichen.<br />
|-<br />
| [[#X_Fingerprint|X_Fingerprint]] || Rückgabe eines "Fingerabdrucks" einer Nachricht. Dient der Erkennung von Duplikaten im Rahmen von [[DevelopmentModuleAPI#Dispatch|Dispatch()]]. Kann im physischen, als auch logischen Modul benutzt werden.<br />
|}<br />
<br />
Für das zweistufige Modulkonzept muss in einem logischen Modul eine [[#X_Parse|Parse]]-Funktion im Modul-Hash registriert werden. In einem physikalischen Modul muss eine [[#X_Write|Write]]-Funktion registriert sein. Diese dienen dem Datenaustausch in beide Richtungen und werden von dem jeweils anderen Modul indirekt aufgerufen.<br />
<br />
In der [[#X_Initialize|Initialize]]-Funktion werden diese wie folgt definiert:<br />
<br />
<syntaxhighlight lang="perl"><br />
$hash->{ParseFn} = "X_Parse";<br />
$hash->{WriteFn} = "X_Write";<br />
$hash->{FingerprintFn} = "X_Fingerprint";<br />
</syntaxhighlight><br />
<br />
Diese Funktionen werden in diesem Abschnitt genauer beschrieben.<br />
<br />
==== X_Parse ====<br />
{{Randnotiz|RNTyp=Info|RNText=<font color="red"><u>'''ACHTUNG''':</u></font><br />
Dieser Abschnitt geht davon aus, dass das Modul mit dem Namen "X" ein '''logisches Modul''' im Sinne des zweistufigen Modulkonzepts ist, also Daten mit einem übergeordneten, physikalischen Modul austauscht.}}<br />
<syntaxhighlight lang="perl"><br />
sub X_Parse ($$)<br />
{<br />
my ( $io_hash, $message) = @_;<br />
<br />
...<br />
<br />
return $found;<br />
}<br />
</syntaxhighlight><br />
<br />
Die Funktion X_Parse wird aufgerufen, sobald von dem IO-Gerät <code>$io_hash</code> eine Nachricht <code>$message</code> via [[DevelopmentModuleAPI#Dispatch|Dispatch()]] zur Verarbeitung angefragt wird. Die Parse-Funktion muss dann prüfen, zu welcher Gerätedefinition diese Nachricht gehört und diese entsprechend verarbeiten.<br />
<br />
Üblicherweise enthält eine Nachricht immer eine Komponente durch welche sich die Nachricht einem Gerät zuordnen lässt (z.B. Adresse, ID-Nummer, ...). Eine solche Identifikation sollte man im Rahmen der [[#X_Define|Define]]-Funktion im logischen Modul an geeigneter Stelle speichern, um in der Parse-Funktion eine einfache Zuordnung von Adresse/ID einer Nachricht zur entsprechenden Gerätedefinition zu haben. Dazu wird in der Regel im Modul-Hash im modulspezifischen Bereich eine Liste <code>defptr</code> (Definition Pointer) geführt, welche jede eindeutige Adresse/ID dem entsprechenden Geräte-Hash zuordnet:<br />
<br />
<syntaxhighlight lang="perl"><br />
<br />
sub X_Define ($$)<br />
{<br />
my ( $hash, $def) = @_;<br />
my @a = split("[ \t][ \t]*", $def);<br />
my $name = $a[0];<br />
<br />
...<br />
<br />
# erstes Argument ist die eindeutige Geräteadresse<br />
my $address = $a[1];<br />
<br />
# Adresse rückwärts dem Hash zuordnen (für ParseFn)<br />
$modules{X}{defptr}{$address} = $hash;<br />
<br />
...<br />
}<br />
</syntaxhighlight><br />
<br />
Auf Basis dieses Definition Pointers kann die Parse-Funktion nun sehr einfach prüfen, ob für die empfangene Nachricht bereits eine entsprechende Gerätedefinition existiert. Sofern diese existiert, kann die Nachricht entsprechend verarbeitet werden. Sollte jedoch keine passende Gerätedefinition zu der empfangenen Nachricht existieren, so muss die Parse-Funktion den Gerätenamen "UNDEFINED" zusammen mit den Argumenten für einen <code>define</code>-Befehl zurückgeben, welcher ein passendes Gerät in FHEM anlegen würde (durch [[autocreate]]).<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="perl"><br />
<br />
sub X_Parse ($$)<br />
{<br />
my ( $io_hash, $message) = @_;<br />
<br />
# Die Stellen 10-15 enthalten die eindeutige Identifikation des Geräts<br />
my $address = substr($message, 10, 5); <br />
<br />
# wenn bereits eine Gerätedefinition existiert (via Definition Pointer aus Define-Funktion)<br />
if(my $hash = $modules{X}{defptr}{$address}) <br />
{<br />
... # Nachricht für $hash verarbeiten<br />
<br />
# Rückgabe des Gerätenamens, für welches die Nachricht bestimmt ist.<br />
return $hash->{NAME}; <br />
}<br />
else<br />
{<br />
# Keine Gerätedefinition verfügbar<br />
# Daher Vorschlag define-Befehl: <NAME> <MODULNAME> <ADDRESSE><br />
return "UNDEFINED X_".$address." X $address";<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
==== X_Write ====<br />
{{Randnotiz|RNTyp=Info|RNText=<font color="red"><u>'''ACHTUNG''':</u></font><br />
Dieser Abschnitt geht davon aus, dass das Modul mit dem Namen "X" ein '''physisches Modul''' im Sinne des zweistufigen Modulkonzepts ist, also Daten mit untergeordneten logischen Modulen austauscht. }}<br />
<syntaxhighlight lang="perl"><br />
sub X_Write ($$)<br />
{<br />
my ( $hash, @arguments) = @_;<br />
<br />
...<br />
<br />
return $return;<br />
}<br />
</syntaxhighlight><br />
<br />
Die Write-Funktion wird durch die Funktion [[DevelopmentModuleAPI#IOWrite|IOWrite()]] aufgerufen, sobald eine logische Gerätedefinition Daten per IO-Gerät an die Hardware übertragen möchte. Dazu kümmert sich die Write-Funktion um die Übertragung der Nachricht in geeigneter Form an die verbundene Hardware. Als Argumente wird der Hash des physischen Gerätes übertragen, sowie alle weiteren Argumente, die das logische Modul beim Aufruf von IOWrite() mitgegeben hat. Im Normalfall ist das ein Skalar mit der zu sendenden Nachricht in Textform. Es kann aber auch sein, dass weitere Daten zum Versand notwendig sind (evtl. Schlüssel, Session-Key, ...). Daher ist die Parametersyntax einer zu schreibenden Nachricht via IOWrite-/Write-Funktion zwischen logischem und physikalischem Modul abzustimmen.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Write ($$)<br />
{<br />
my ( $hash, $message, $address) = @_;<br />
<br />
DevIo_SimpleWrite($hash, $address.$message, 2);<br />
<br />
return undef;<br />
}<br />
</syntaxhighlight><br />
<br />
==== X_Fingerprint ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Fingerprint($$)<br />
{<br />
my ( $io_name, $msg ) = @_;<br />
<br />
...<br />
<br />
return ( $io_name, $fingerprint );<br />
}<br />
</syntaxhighlight><br />
<br />
Die Fingerprint-Funktion dient der Erkennung von Duplikaten empfangener Nachrichten. Diese Funktion kann dabei sowohl im physischen, als auch im logischen Modul implementiert sein - je nachdem auf welcher Ebene man für eine Nachricht einen Fingerprint bilden kann. <br />
<br />
Als Parameter wird der Name des IO-Geräts <code>$io_name</code> übergeben, sowie die Nachricht <code>$msg</code>, welche empfangen wurde. Nun muss aus dieser Nachricht ein eindeutiger Fingerprint gebildet werden. Dies bedeutet, dass alle variablen Inhalte, die aufgrund des Empfangs dieser Nachricht über unterschiedliche IO-Geräte enthalten sein können, entfernt werden müssen. Dies können bspw. Empfangsadressen von IO-Geräten sein oder Session-ID's die in der Nachricht enthalten sind. Alle Fingerprints sämtlicher Nachrichten, die innerhalb der letzten 500 Millisekunden (konfigurierbar via <code>global</code> Attribut <code>dupTimeout</code>) empfangen wurden, werden gegen diesen generierten Fingerprint getestet. Sollte innerhalb dieser Zeit bereits eine Nachricht mit diesem Fingerprint verarbeitet worden sein, so wird sie als Duplikat erkannt und nicht weiter verarbeitet. In diesem Fall gibt [[DevelopmentModuleAPI#Dispatch|Dispatch()]] den Namen der Gerätedefinition zurück, welche eine Nachricht mit dem selben Fingerprint bereits verarbeitet hat. Es erfolgt dann kein Aufruf der [[#X_Parse|Parse]]-Funktion.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Fingerprint($$)<br />
{<br />
my ( $io_name, $msg ) = @_;<br />
<br />
substr( $msg, 2, 2, "--" ); # entferne Empfangsadresse<br />
substr( $msg, 4, 1, "-" ); # entferne Hop-Count<br />
<br />
return ( $io_name, $msg );<br />
}<br />
</syntaxhighlight><br />
<br />
Es wird zuerst, sofern implementiert, die Fingerprint-Funktion des physischen Moduls aufgerufen. Sollte sich hierdurch kein Duplikat erkennen lassen, wird die Fingerprint-Funktion jedes möglichen geladenen logischen Moduls aufgerufen, sofern implementiert. <br />
<br />
Sollte sowohl im physischen, als auch im logischen Modul keine Fingerprint-Funktion implementiert sein, so wird keinerlei Duplikatserkennung durchgeführt.<br />
<br />
=== FHEMWEB-spezifische Funktionen ===<br />
<br />
FHEMWEB bietet Modul-Autoren die Möglichkeit an durch spezielle Funktionsaufrufe in Modulen, eigene HTML-Inhalte zu verwenden. Dadurch können in Verbindung mit zusätzlichem JavaScript komplexe Dialoge/Inhalte/Steuermöglichkeiten dargestellt werden. <br />
<br />
Eine genaue Auflistung aller FHEMWEB-spezifischen Funktionsaufrufe gibt es in dem separaten Artikel [[DevelopmentFHEMWEB]]<br />
<br />
=== sonstige Funktionen ===<br />
<br />
In diesem Abschnitt werden weitere Funktionen behandelt die zum Teil aus FHEM, aber auch aus anderen Modulen aufgerufen werden. Sie sind dabei nur in speziellen Anwendungsfällen relevant. Hier eine Auflistung aller sonstigen Modulfunktionen:<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Funktionsname !! class="unsortable" | Kurzbeschreibung<br />
|-<br />
| [[#X_DbLog_split|X_DbLog_split]] || Wird durch das Modul 93_DbLog.pm aufgerufen. Dient dem korrekten Split eines moduleigenen Events in Name/Wert/Einheit für die Nutzung einer Datenbank.<br />
|-<br />
| [[#X_Except|X_Except]]|| Wird aufgerufen, sobald ein ein geöffneter Filedescriptor in [[#Wichtige_globale_Variablen_aus_fhem.pl|<code>%selectlist</code>]], der unter <code>$hash->{EXCEPT_FD}</code> im Geräte-Hash gesetzt ist, einen Interrupt bzw. Exception auslöst.<br />
|-<br />
| [[#X_Copy|X_Copy]]|| Wird durch das Modul 98_copy.pm aufgerufen im Rahmen des <code>copy</code>-Befehls sobald ein Gerät kopiert wurde.<br />
|-<br />
| [[#X_State|X_State]]|| Wird aufgerufen im Rahmen des <code>setstate</code>-Befehls bevor der Status einer Gerätedefinition bzw. eines zugehörigen Readings gesetzt wird.<br />
|-<br />
| [[#X_AsyncOutput|X_AsyncOutput]]|| Nur relevant für Module die via [[TcpServerUtils]] eine Client-Verbindung zu FHEM ermöglichen (z.B. FHEMWEB und telnet). Ermöglicht die asynchrone Ausgabe von Daten via [[DevelopmentModuleAPI#asyncOutput|asyncOutput()]] an einen einzelnen verbundenen Client.<br />
|-<br />
| [[#X_ActivateInform|X_ActivateInform]]|| Nur relevant für Module die via [[TcpServerUtils]] eine Client-Verbindung zu FHEM ermöglichen (z.B. FHEMWEB und telnet). Ermöglicht das Aktivieren des inform-Mechanismus zum Senden von Events für einen einzelnen verbundenen Client.<br />
|-<br />
| [[#X_Authorize|X_Authorize]]|| Wird aufgerufen im Rahmen von [[DevelopmentModuleAPI#Authorized|Authorized()]] um eine gewünschte Vorgangs-Art zu autorisieren.<br />
|-<br />
| [[#X_Authenticate|X_Authenticate]]|| Wird aufgerufen im Rahmen von [[DevelopmentModuleAPI#Authenticate|Authenticate()]] um eine Authentifizierung zu prüfen und ggf. zu genehmigen.<br />
|}<br />
<br />
In der [[#X_Initialize|Initialize]]-Funktion werden diese wie folgt definiert:<br />
<br />
<syntaxhighlight lang="perl"><br />
$hash->{DbLog_splitFn} = "X_DbLog_split";<br />
$hash->{ExceptFn} = "X_Except";<br />
$hash->{CopyFn} = "X_Copy";<br />
$hash->{AsyncOutputFn} = "X_AsyncOutput";<br />
$hash->{ActivateInformFn} = "X_ActivateInform";<br />
$hash->{StateFn} = "X_State";<br />
$hash->{AuthorizeFn} = "X_Authorize";<br />
$hash->{AuthenticateFn} = "X_Authenticate";<br />
</syntaxhighlight><br />
<br />
<br />
Diese Funktionen werden in diesem Abschnitt genauer beschrieben.<br />
==== X_DbLog_split ====<br />
<syntaxhighlight lang="perl"><br />
sub X_DbLog_split ($$)<br />
{<br />
my ( $event, $device_name ) = @_;<br />
<br />
...<br />
<br />
return ( $reading, $value, $unit );<br />
}<br />
</syntaxhighlight><br />
<br />
Die DbLog_split-Funktion wird durch das Modul [[DbLog]] aufgerufen, sofern der Nutzer DbLog benutzt. Sofern diese Funktion implementiert ist, kann der Modul-Autor das Auftrennen von Events in den Reading-Namen, -Wert und der Einheit selbst steuern. Andernfalls nimmt DbLog diese Auftrennung selber mittels Trennung durch Leerzeichen sowie vordefinierten Regeln zu verschiedenen Modulen vor. Je nachdem, welche Readings man in seinem Modul implementiert, passt diese standardmäßige Trennung jedoch nicht immer.<br />
<br />
Der Funktion werden folgende Eingangsparameter übergeben:<br />
# Das generierte Event (Bsp: <code>temperature: 20.5 °C</code>)<br />
# Der Name des Geräts, welche das Event erzeugt hat (Bsp: <code>Temperatursensor_Wohnzimmer</code>)<br />
<br />
Es ist nicht möglich in der DbLog_split-Funktion auf die verarbeitende DbLog-Definition zu referenzieren.<br />
<br />
Als Rückgabewerte muss die Funktion folgende Werte bereitstellen:<br />
# Name des Readings (Bsp: <code>temperature</code>)<br />
# Wert des Readings (Bsp: <code>20.5</code>)<br />
# Einheit des Readings (Bsp: <code>°C</code>)<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="perl"><br />
sub X_DbLog_splitFn($$)<br />
{<br />
my ($event, $device) = @_;<br />
my ($reading, $value, $unit);<br />
my $devhash = $defs{$device}<br />
<br />
if($event =~ m/temperature/) {<br />
$reading = 'temperature';<br />
$value = substr($event,12,4);<br />
$unit = '°C';<br />
} <br />
<br />
return ($reading, $value, $unit);<br />
}<br />
</syntaxhighlight><br />
<br />
==== X_Except ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Except ($)<br />
{<br />
my ( $hash ) = @_;<br />
<br />
...<br />
}<br />
</syntaxhighlight><br />
<br />
Die X_Except-Funktion wird durch fhem.pl aufgerufen, wenn die Gerätedefinition <code>$hash</code> in <code>[[#Wichtige_globale_Variablen_aus_fhem.pl|%selectlist]]</code> aufgeführt ist und der Filedeskriptor in <code>$hash->{EXCEPT_FD}</code> eine Exception bzw. Interrupt auslöst. <br />
<br />
Der Rückgabewert wird nicht ausgewertet und ist daher irrelevant.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="perl"><br />
use IO::File;<br />
<br />
...<br />
<br />
sub X_Except ($)<br />
{<br />
my ( $hash ) = @_;<br />
<br />
# Filehandle aus Filedescriptor erstellen<br />
my $filehandle = IO::File->new_from_fd($hash->{EXCEPT_FD}, 'r');<br />
seek($filehandle,0,0); <br />
<br />
# aktuellen Inhalt auslesen<br />
my $current_value = $filehandle->getline;<br />
<br />
if($current_value eq "1")<br />
{<br />
...<br />
}<br />
else<br />
{<br />
...<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
==== X_Copy ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Copy ($)<br />
{<br />
my ( $old_name, $new_name ) = @_;<br />
<br />
...<br />
}<br />
</syntaxhighlight><br />
<br />
Die X_Copy-Funktion wird durch das Modul [[copy]] aufgerufen nachdem ein Nutzer eine Gerätedefinition über den Befehl <code>copy</code> kopiert hat. Dazu werden als Funktionsparameter die Definitionsnamen der alten und neuen Gerätedefinition übergeben. Es dient dazu zusätzliche Daten aus der zu kopierenden Gerätedefinition in die neue Definition zu übernehmen. Der Befehl <code>copy</code> überträgt lediglich <code>$hash->{DEF}</code> in die neue Definition sowie sämtliche gesetzte Attribute. Weitere Daten müssen dann durch die X_Copy-Funktion übertragen werden. <br />
<br />
Die X_Copy-Funktion wird erst nach dem erfolgtem Kopiervorgang aufgerufen.<br />
<br />
Der Rückgabewert wird nicht ausgewertet und ist daher irrelevant.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="perl"><br />
<br />
sub X_Copy ($$)<br />
{<br />
my ( $old_name, $new_name ) = @_;<br />
<br />
my $old_hash = $defs{$old_name};<br />
my $new_hash = $defs{$new_name};<br />
<br />
# copy also temporary session key<br />
$new_hash->{helper}{SESSION_KEY} = $old_hash->{helper}{SESSION_KEY};<br />
}<br />
</syntaxhighlight><br />
<br />
==== X_AsyncOutput ====<br />
{{Randnotiz|RNTyp=Info|RNText='''ACHTUNG:''' Diese Funktion ist nur relevant, wenn man ein Frontend-Modul erstellt über das FHEM von einem Anwender bedient werden kann (FHEMWEB, telnet, yowsup, telegram, alexa-fhem, homebridge-fhem, tabletui, ...).}}<br />
<syntaxhighlight lang="perl"><br />
sub X_AsyncOutput ($)<br />
{<br />
my ( $client_hash, $text ) = @_;<br />
<br />
...<br />
<br />
return $error;<br />
}<br />
</syntaxhighlight><br />
<br />
Die Funktion X_AsyncOutput wird durch [[DevelopmentModuleAPI#asyncOutput|asyncOutput()]] von anderen Modulen aufgerufen. Es erlaubt diesen anderen Modulen die Ausgabe von asynchronen Befehlsergebnissen <code>$text</code> zuvor ausgeführter set-/get-Befehle an den entsprechenden Client (identifiziert durch den Client-Hash <code>$client_hash</code> der temporären Definition) zurückzugeben. <br />
<br />
Wenn ein Client einen set-/get-Befehl ausführt, wird der Client-Hash bei der Ausführung dieser Befehle an die jeweiligen Module übermittelt. Sobald ein Befehl ausgeführt wird, der seine Ausgabe asynchron ausführen möchte und die Client-Verbindung des Server-Moduls dies unterstützt (<code>$client_hash->{canAsyncOutput}</code> ist gesetzt), merkt sich das befehlsausführende Modul den Client-Hash und gibt das Ergebnis des Befehls zu späterer Zeit via [[DevelopmentModuleAPI#asyncOutput|asyncOutput()]] an den ursprünglichen Client zurück. Die Funktion X_AsyncOutput des Server-Moduls kümmert sich darum das Ergebnis dem entsprechenden Client in der notwendigen Form zuzustellen.<br />
<br />
Der Rückgabewert von X_AsyncOutput() wird als Rückgabewert für asyncOutput() verwendet. Man kann hier im Fehlerfall eine Fehlermeldung angeben und im Erfolgsfall <code>undef</code>. Der Rückgabewert wird aber aktuell nicht ausgewertet.<br />
<br />
==== X_ActivateInform====<br />
{{Randnotiz|RNTyp=Info|RNText='''ACHTUNG:''' Diese Funktion ist nur relevant, wenn man ein Frontend-Modul erstellt über das FHEM von einem Anwender bedient werden kann (FHEMWEB, telnet, yowsup, telegram, alexa-fhem, homebridge-fhem, tabletui, ...).}}<br />
<syntaxhighlight lang="perl"><br />
sub X_ActivateInform($$)<br />
{<br />
my ( $client_hash, $arg ) = @_;<br />
<br />
...<br />
}<br />
</syntaxhighlight><br />
<br />
Die Funktion X_ActivateInform wird aktuell nur durch den [[update]]-Befehl aufgerufen, sofern ein Client eines Frontend-Moduls diesen Befehl aufgerufen hat um den Inform-Mechanismus (Senden von Events) zu aktivieren. Dadurch wird im Falle von [[update]] die umgehende Anzeige der Logmeldungen für den ausführenden Client aktiviert. In [[FHEMWEB]] geschieht das über den Event-Monitor, bei telnet mit der direkten Ausgabe.<br />
<br />
Da diese Funktion aktuell nur speziell für den update-Befehl implementiert ist, kann man aktuell keine genaue Angaben zu den möglichen Werten von <code>$arg</code> geben. Dieser Parameter dient dazu genauer zu spezifizieren was exakt an Events an den entsprechenden Client <code>$client_hash</code> zu senden ist. Aktuell wird dazu die Parametersyntax des inform-Befehls verwendet (on|off|log|raw|timer|status).<br />
<br />
==== X_State ====<br />
<syntaxhighlight lang="perl"><br />
sub X_State($$$$)<br />
{<br />
my ( $hash, $time, $readingName, $value ) = @_;<br />
<br />
...<br />
<br />
return $error;<br />
}<br />
</syntaxhighlight><br />
<br />
Die X_State-Funktion wird durch fhem.pl aufgerufen, sobald über den Befehl <code>setstate</code> versucht wird ein Wert für ein Reading oder den Status (<code>$hash->{STATE}</code>) einer Gerätedefinition zu setzen. Dieser Befehl wird primär beim Starten von FHEM aufgerufen sobald das State-File eingelesen wird. Je nachdem, ob im gegebenen Fall ein Reading oder der Definitionsstatus gesetzt wird, haben die Übergabeparameter verschiedene Werte:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Funktionsparameter!! Wert beim Setzen eines Readings !! Wert beim Setzen eines Definitionsstatus<br />
|-<br />
| <code>$hash</code> || colspan=2 align=center | Die Hashreferenz der betreffenden Gerätedefinition<br />
|-<br />
| <code>$time</code>|| Der Zeitstempel auf welchen das Reading <code>$readingName</code> gesetzt werden soll. Das Ergebnis entspricht dem Rückgabewert der Funktion || Der aktuelle Zeitstempel zum jetzigen Zeitpunkt.<br />
|-<br />
| <code>$readingName</code>|| Der Name des Readings, welches auf einen neuen Wert gesetzt werden soll. || Statischer Wert "STATE" um anzuzeigen, dass es sich um den Definitionsstatus handelt, welcher gesetzt werden soll (<code>$hash->{STATE}</code>).<br />
|-<br />
| <code>$value</code> || Den Wert, welchen das Reading <code>$readingName</code> annehmen soll. || Den Wert, welchen die Gerätedefinition als Status annehmen soll.<br />
|}<br />
<br />
Wenn via <code>setstate</code> ein Reading gesetzt wird, kann die X_State-Funktion das Setzen dieses Readings durch die Rückgabe einer aussagekräftigen Fehlermeldung unterbinden. Sofern <code>undef</code> zurückgegeben wird, wird das entsprechende Reading auf den übergebenen Status gesetzt.<br />
<br />
Wenn via <code>setstate</code> der Definitionsstatus gesetzt wird, wird die X_State-Funktion erst nach dem Setzen des Status aufgerufen. Man kann dabei zwar eine Fehlermeldung zurückgeben, der Status wird aber dennoch übernommen. Die Fehlermeldung wird lediglich dem Nutzer angezeigt.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_State($$$$)<br />
{<br />
my ( $hash, $time, $readingName, $value ) = @_;<br />
<br />
return undef if($readingName "STATE" || $value ne "inactive");<br />
readingsSingleUpdate($hash, "state", "inactive", 1);<br />
return undef;<br />
}<br />
</syntaxhighlight><br />
<br />
==== X_Authorize ====<br />
<syntaxhighlight lang="perl"><br />
sub X_Authorize($$$$)<br />
{<br />
my ( $hash, $client_hash, $type, $arg ) = @_;<br />
<br />
...<br />
<br />
return $authorized;<br />
}<br />
</syntaxhighlight><br />
<br />
Die Authorize-Funktion wird von fhem.pl aufgerufen um zu erfragen, ob ein bestimmter Client <code>$client_hash</code> die Aktion <code>$type</code>/<code>$arg</code> ausführen darf. Auf diese Weise können Module Einfluss nehmen, welcher User welche Funktionen in FHEM nutzen darf. Wenn ein Client eine Aktion ausführen möchte, werden alle Module, die eine Authorize-Funktion implementiert haben, gefragt, ob diese Aktion ausgeführt werden darf. Als Rückgabewert wird das Ergebnis der Überprüfung zurückgegeben, wobei <code>0</code> (unbekannt / nicht zuständig), <code>1</code> (erlaubt) oder <code>2</code> (verboten) zurückgegeben werden können.<br />
<br />
Es gibt aktuell folgende <code>$type</code>/<code>$arg</code> Kombinationen, mit denen die Authorize-Funktion aufgerufen werden:<br />
<br />
{| class="wikitable"<br />
|-<br />
! $type !! $arg !! Überschrift<br />
|- <br />
|rowspan="3" style="white-space: nowrap;" | <code>'''$type''' = "cmd"</code><br />
<br />
<br />
''Befehlsausführung''<br />
| style="white-space: nowrap;" | <code>'''$arg''' = "set Lampe on"</code> || Jeglicher FHEM-Befehl, der ausgeführt werden soll, wird in <code>$arg</code> hinterlegt, sodass innerhalb einer Authorize-Funktion der Befehl genauer geparst werden kann um zu entscheiden, ob dieser Befehl erlaubt ist, oder nicht.<br />
|-<br />
| style="white-space: nowrap;" | <code>'''$arg''' = "perl"</code> || Ausführen von Perl-Befehlen jeglicher Art. Der genaue Befehl wird dabei nicht an die Authorize-Funktion übergeben.<br />
<br />
Bsp: <code>{ReadingsVal("Lampe", "state", "off"}</code><br />
|-<br />
| style="white-space: nowrap;" | <code>'''$arg''' = "shell"</code> || Ausführen von Shell-Befehlen jeglicher Art. Der genaue Befehl wird dabei nicht an die Authorize-Funktion übergeben.<br />
<br />
Bsp: <code>"/opt/fhem/myScript.sh"</code><br />
|-<br />
|style="white-space: nowrap;" | <code>'''$type''' = "devicename"</code><br />
<br />
<br />
''Sichtbarkeit von Geräten/Definitionen'' <br />
|style="white-space: nowrap;" | <code>'''$arg''' = "Licht_Wohnzimmer"</code> || Sichtbarkeit des jeweiligen Gerät/Definition in FHEM. Dies bedeutet konkret die Auffindbarkeit im <code>list</code>-Befehl, sowie der Suche via [[DevelopmentModuleAPI#devspec2array|devspec2array()]]. Wird eine solche Anfrage durch die Authorize-Funktion abgelehnt, ist das entsprechende Gerät bzw. Definition für den jeweiligen Client nicht sichtbar.<br />
|}<br />
<br />
==== X_Authenticate ====<br />
{{Link2Forum|Topic=72757|Message=644098}}<br />
<br />
== Bereitstellen eines eigenen Befehls (Befehlsmodul) ==<br />
<br />
Ein Modul kann primär einen neuen FHEM-Befehl bereitstellen. Man spricht in so einem Fall nicht von einem Gerätemodul, sondern einem Befehlsmodul. Ein solches Befehlsmodul stellt nur einen einzelnen Befehl bereit, der dem Modulnamen entsprechen muss. Nur, wenn der Modulname dem Befehlsname entspricht, kann FHEM das Modul beim ersten Ausführen dieses unbekannten Befehls finden und nachladen.<br />
<br />
Der entsprechende Befehl wird dazu in der [[#X_Initialize|Initialize]]-Funktion im globalen Hash <code>[[DevelopmentModuleIntro#Wichtige_globale_Variablen_aus_fhem.pl|%cmds]]</code> registriert:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Initialize($$) {<br />
<br />
$cmds{X} = { Fn => "CommandX",<br />
Hlp => "<argument1> [optional_argument2], print something very useful",<br />
<br />
# optionaler Filter für Clientmodule als regulärer Ausdruck<br />
ClientFilter => "FHEMWEB"<br />
};<br />
}<br />
</syntaxhighlight><br />
<br />
Damit wird der neue Befehl <code>X</code> in FHEM registriert. Die Funktion mit dem Namen <code>CommandX</code> setzt diesen Befehl innerhalb des Moduls um. Desweiteren wird eine kurze Aufrufsyntax mitgegeben, welche beim Aufruf des <code>help</code>-Befehls dem Nutzer angezeigt wird um als Gedankenstütze zu dienen. Optional kann man mittels <code>ClientFilter</code> (regulärer Ausdruck für Modulnamen) die Ausführbarkeit nur auf bestimmte Client-Module (wie FHEMWEB oder telnet) beschränken. <br />
<br />
Nun muss noch die Funktion <code>CommandX</code> im Rahmen des Moduls implementiert werden, welche den Befehl <code>X</code> umsetzt:<br />
<br />
<syntaxhighlight lang="Perl"><br />
sub CommandX($$)<br />
{<br />
my ($client_hash, $arguments) = @_;<br />
<br />
...<br />
<br />
return $output;<br />
}<br />
</syntaxhighlight><br />
<br />
Dabei werden der Befehlsfunktion zwei Parameter übergeben. Zuerst die Hash-Referenz des aufrufenden Clients (sofern manuell ausgeführt, ansonsten <code>undef</code>) zwecks Rechteprüfung via [[allowed|allowed-Definitionen]]. Anschließend folgen die Aufrufparameter als zusammenhängende Zeichenkette. Die Trennung der einzelnen Argumente obligt der Funktion (bspw. via [[DevelopmentModuleAPI#parseParams|parseParams()]]). Als Funktionsrückgabewert wird eine Ausgabemeldung erwartet, die dem Nutzer angezeigt werden soll.<br />
<br />
== Pollen von Geräten ==<br />
Wenn Geräte von sich aus keine Informationen senden sondern abgefragt werden müssen, kann man im Modul die Funktion [[DevelopmentModuleAPI#InternalTimer|InternalTimer()]] verwenden um einen Funktionsaufruf zu einem späteren Zeitpunkt durchführen zu können. Man übergibt dabei den Zeitpunkt für den nächsten Aufruf, den Namen der Funktion, die aufgerufen werden soll, sowie den zu übergebenden Parameter. Als zu übergebender Parameter wird üblicherweise der Hash der betroffenen Geräteinstanz verwendet. Damit hat die aufgerufene Funktion Zugriff auf alle wichtigen Daten der Geräteinstanz. Eventuell zusätzlich benötigte Werte können einfach als weitere Internals über den Hash zugänglich gemacht werden.<br />
<br />
Beispielsweise könnte man für das Abfragen eines Geräts in der [[#X_Define|Define]]-Funktion den Timer folgendermaßen setzen:<br />
<br />
<syntaxhighlight lang="perl"><br />
InternalTimer(gettimeofday()+2, "X_GetUpdate", $hash); <br />
</syntaxhighlight><br />
<br />
Alternativ kann man auch in der [[#X_Notify|Notify]]-Funktion auf das Event <code>global:INITIALIZED</code> bzw. <code>global:REREADCFG</code> reagieren und erst dort, den Timer anstoßen, sobald die Konfiguration komplett eingelesen wurde. Dies ist insbesondere notwendig, wenn man sicherstellen will, dass alle Attribute aus der Konfiguration gesetzt sind, sobald man einen Status-Update initiiert.<br />
<br />
In der Funktion <code>X_GetUpdate</code> selbst wird dann der Timer neu gesetzt, so dass nach einem Intervall die Funktion erneut aufgerufen wird:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_GetUpdate($)<br />
{<br />
my ($hash) = @_;<br />
my $name = $hash->{NAME};<br />
Log3 $name, 4, "X: GetUpdate called ...";<br />
<br />
...<br />
<br />
# neuen Timer starten in einem konfigurierten Interval.<br />
InternalTimer(gettimeofday()+$hash->{Interval}, "X_GetUpdate", $hash);<br />
}<br />
</syntaxhighlight><br />
<br />
Innerhalb der Funktion kann man nun das Gerät abfragen und die abgefragten Werte in Readings speichern. Falls das Abfragen der Werte jedoch zu einer Verzögerung und damit zu einer Blockade von FHEM führen kann, ist es möglich, in der GetUpdate-Funktion nur die Aufforderung zum Senden bestimmter Daten an das angeschlossene Gerät zu senden und dann das Lesen über die oben beschriebene [[#X_Read|Read]]-Funktion zu implementieren.<br />
<br />
Eine genaue Beschreibung der Timer-Funktion gibt es [[DevelopmentModuleAPI#Timer|hier im Wiki]]<br />
<br />
== Logging / Debugging ==<br />
Um Innerhalb eines Moduls eine Log-Meldung in die FHEM-Logdatei zu schreiben, wird die Funktion [[DevelopmentModuleAPI#Log3|Log3()]] aufgerufen.<br />
<syntaxhighlight lang="perl"><br />
Log3 $name, 3, "X ($name) - Problem erkannt ...";<br />
</syntaxhighlight><br />
Eine genaue Beschreibung zu der Funktion inkl. Aufrufparameter findet man [[DevelopmentModuleAPI#Log3|hier]]. Es ist generell ratsam in der Logmeldung sowohl den Namen des eigenen Moduls zu schreiben, sowie den Namen des Geräts, welche diese Logmeldung produziert, da die Meldung, so wie sie ist, direkt in das Logfile wandert und es für User ohne diese Informationen schwierig ist, die Meldungen korrekt zuzuordnen.<br />
<br />
Die Funktion Log3() verwendet den Namen der Geräteinstanz um das <code>verbose</code>-Attribut zu prüfen. In der Regel wird bei Modulfunktionen jedoch immer nur der Gerätehash <code>$hash</code> übergeben. Um den Namen der Definition zu ermitteln ist es daher notwendig sich diesen aus dem Hash extrahieren:<br />
<br />
<syntaxhighlight lang="perl"><br />
my $name = $hash->{NAME};<br />
</syntaxhighlight><br />
<br />
Um für eine einzelne Geräteinstanz das Verbose-Level zu erhöhen, ohne gleich für das gesamte FHEM den globalen Verbose-Level zu erhöhen und damit alle Meldungen zu erzeugen, kann man den Befehl <br />
<code>attr <NAME> verbose</code> verwenden. Beispielsweise <code>attr Lichtschalter_Wohnzimmer verbose 5</code><br />
<br />
Logmeldungen sollten je nach Art und Wichtigkeit für den Nutzer in unterschiedlichen Loglevels erzeugt werden. Es gibt insgesamt 5 Stufen in denen geloggt werden kann. Standardmäßig steht der systemweite Loglevel (<code>global</code>-Attribut <code>verbose</code>) auf der Stufe 3. Die Bedeutung der jeweiligen Stufen ist in der {{Link2CmdRef|Lang=de|Anker=verbose}} beschrieben.<br />
<br />
Während der Entwicklung eines Moduls kann man für eigene Debug-Zwecke auch die Funktion [[DevelopmentModuleAPI#Debug|Debug()]] verwenden um schnell und einfach Debug-Ausgaben in das Log zu schreiben. Diese sollten in der endgültigen Fassung jedoch nicht mehr vorhanden sein. Sie dienen ausschließlich zum Debugging während der Entwicklung.<br />
<br />
Eine genaue Beschreibung der Log-Funktion gibt es [[DevelopmentModuleAPI#Logging|hier im Wiki]].<br />
<br />
== Zweistufiges Modell für Module ==<br />
[[Datei:Zweistufiges Modulkonzept.jpg|mini|rechts|Schematische Darstellung am Beispiel CUL]]<br />
Es gibt viele Geräte, welche die Kommunikation mit weiteren Geräten mit tlw. unterschiedlichen Protokollen ermöglichen. Das typischste Beispiel bietet hier der [[CUL]], welcher via Funk mit verschiedenen Protokollen weitere Geräte ansprechen kann (z.B. Aktoren, Sensoren, ...). Hier bildet ein Gerät eine Brücke durch die weitere Geräte in FHEM zugänglich gemacht werden können. Dabei werden über einen Kommunikationsweg (z.B. serielle Schnittstelle, TCP, ...) beliebig viele Geräte gesteuert. Typische Beispiele dazu sind:<br />
<br />
* [[CUL]]: stellt Geräte mit verschiedenen Kommunikationsprotokollen via Funk bereit (u.a. [[FS20]], [[HomeMatic]], [[Funk-Heizkörperregler_Kurz-Bedienungsanleitung_FHT|FHT]], [[MAX]], ...)<br />
* [[HMLAN]]: stellt HomeMatic Geräte via Funk bereit<br />
* [[MAX#MAXLAN|MAXLAN]]: stellt [[MAX|MAX!]] Geräte via Funk bereit<br />
* [[PanStamp#panStick.2FShield|panStamp]]: stellt weitere panStamp Geräte via Funk bereit<br />
<br />
Dabei wird die Kommunikation in 2 Stufen unterteilt:<br />
* physisches Modul - z.B. 00_CUL.pm - zuständig für die physikalische Kommunikation mit der Hardware. Empfangene Daten müssen einem logischen Modul zugeordnet werden.<br />
* logische Modul(e) - z.B. 10_FS20.pm - interpretiert protokollspezifische Nachrichten. Sendet protokollspezifische Daten über das physische Modul an die Hardware.<br />
<br />
<u>physisches Modul</u><br />
<br />
Das physische Modul öffnet die Datenverbindung zum Gerät (z.B. CUL) und verarbeitet sämtliche Daten. Es kümmert sich um den Erhalt der Verbindung (bsp. durch Keep-Alives) und konfiguriert das Gerät so, dass eine Kommunikation mit allen weiteren Geräten möglich ist (bsp. Frequenz, Modulation, Kanal, etc.).<br />
<br />
Empfangene Nutzdaten werden als Zeichenkette über die Funktion [[DevelopmentModuleAPI#Dispatch|Dispatch()]] an logische Module weitergegeben.<br />
<br />
Das Modul stellt eine [[#Die_Match-Liste|Match-Liste]] bereit, anhand FHEM die Nachricht einem Modul zuordnen kann, sofern dieses noch nicht geladen sein sollte. Die Match-Liste enthält eine Liste von regulären Ausdrücken und ordnet diese einem Modul zu. Wenn eine Nachricht auf einen solchen regulären Ausdruck passt und das Modul noch nicht geladen ist, lädt FHEM dieses automatisch nach, zwecks Verarbeitung der Nachricht. <br />
<br />
Anhand einer bereitgestellten [[#Die_Client-Liste|Client-Liste]] (Auflistung von logischen Modulen) kann FHEM feststellen, welche logischen Module mit dem physischen Modul kommunizieren können. Nur die hier aufgelisteten, logischen Module werden beim Aufruf von [[DevelopmentModuleAPI#Dispatch|Dispatch()]] angesprochen.<br />
<br />
Das Modul stellt eine [[#X_Write|Write]]-Funktion zur Verfügung, über die logische Module Daten in beliebiger Form an die Hardware übertragen können. <br />
<br />
<u>logisches Modul</u><br />
<br />
Das logische Modul interpretiert die via Dispatch() übergebene Nachricht (Zeichenkette) durch eine bereitgestellte [[#X_Parse|Parse]]-Funktion und erzeugt entsprechende Readings/Events. Es stellt über <code>set</code>-/<code>get</code>-Kommandos Steuerungsmöglichkeiten dem Nutzer zur Verfügung.<br />
<br />
Es stellt FHEM einen [[#Der_Match-Ausdruck|Match-Ausdruck]] (regulärer Ausdruck) zur Verfügung anhand [[DevelopmentModuleAPI#Dispatch|Dispatch()]] ermitteln kann, ob die Nachricht durch das logische Modul verarbeitet werden kann. Nur Nachrichten, welche auf diesen Ausdruck passen, werden an das logische Modul weitergegeben (Aufruf [[#X_Parse|Parse]]-Funktion).<br />
<br />
=== Die Client-Liste ===<br />
<br />
Die Client-Liste ist eine Auflistung von Modulnamen (genauer: regulären Ausdrücken die auf Modulnamen passen) die in einem physischen Modul gesetzt ist. Damit wird definiert, mit welchen logischen Modulen das physikalische Modul kommunizieren kann. <br />
<br />
Eine Client-Liste ist eine Zeichenkette, welche aus allen logischen Modulnamen besteht. Die einzelnen Namen werden durch einen Doppelpunkt getrennt. Anstatt kompletter Modulnamen können auch reguläre Ausdrücke verwendet werden, die auf mehrere Modulnamen passen (z.B. <code>CUL_.*</code> um die logischen Module CUL_HM, CUL_MAX, etc. zu verwenden).<br />
<br />
Bsp.: Die Client-Liste von dem Modul CUL lautet daher wie folgt:<br />
<br />
FS20:FHT.*:KS300:USF1000:BS:HMS:CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN:ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY:STACKABLE_CC:CUL_RFR:CUL_TCM97001:CUL_REDIRECT<br />
<br />
Alle hier aufgelisteten Module können über das Modul CUL Daten empfangen bzw. senden.<br />
<br />
Die Client-Liste hat generell folgende Funktion:<br />
* Die Funktion [[DevelopmentModuleAPI#Dispatch|Dispatch()]] prüft nur Module, welche in der Client-Liste enthalten sind, ob diese die Nachricht verarbeiten können (Prüfung via [[#Der Match-Ausdruck|Match-Ausdruck]])<br />
* Die Funktion [[DevelopmentModuleAPI#AssignIoPort|AssignIoPort()]] prüft anhand sämtlicher Client-Listen in FHEM, welches IO-Gerät für ein logisches Gerät nutzbar ist.<br />
<br />
Üblicherweise wird die Client-Liste in der [[#X_Initialize|Initialize]]-Funktion im Modul-Hash gesetzt:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Initialize($)<br />
{<br />
my ($hash) = @_;<br />
...<br />
$hash->{Clients} = "FS20:KS300:FHT.*";<br />
}<br />
</syntaxhighlight><br />
<br />
Man kann die Client-Liste jedoch auch pro physikalisches Gerät setzen. Eine gesetzte Client-Liste in einem Gerät hat immer Vorrang vor der Liste im Modul-Hash. Eine gerätespezifische Client-Liste wird dann verwendet, wenn bspw. ein Gerät je nach Konfiguration nur bestimmte logische Module bedienen kann. Bspw. kann ein CUL je nach RF-Einstellungen FS20, uvm. oder nur HomeMatic bedienen. In einem solchen Fall wird die Client-Liste im Geräte-Hash gesetzt:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Define($$)<br />
{<br />
my ( $hash, $def ) = @_;<br />
...<br />
$hash->{Clients} = "CUL_HM";<br />
}<br />
</syntaxhighlight><br />
<br />
In vielen Modulen, welche nach dem zweistufigem Konzept arbeiten, beginnt und endet die Client-Liste mit einem Doppelpunkt. Dies ist ein historisches Überbleibsel, da der Prüfmechanismus die Client-Liste früher auf das Vorhandensein von <code>'''<u><font color="red">:</font></u>'''&lt;Modulname&gt;'''<u><font color="red">:</font></u>'''</code> prüfte. Dies ist nun nicht mehr notwendig. Die einzelnen Modulnamen müssen lediglich durch einen Doppelpunkt getrennt werden.<br />
<br />
=== Die Match-Liste ===<br />
{{Randnotiz|RNTyp=Info|RNText=<font color="red"><u>'''ACHTUNG''':</u></font><br />
Sämtliche regulären Ausdrücke in der Match-Liste werden "case insensitive" überprüft. Das bedeutet, dass Groß-/Kleinschreibung nicht berücksichtigt wird.<br />
<br />
Um dennoch in einem regulären Ausdruck auf Groß-/Kleinschreibung zu prüfen, kann man dieses mit dem Modifizierer <code>(?-i)</code> wieder aktivieren:<br />
<br />
<syntaxhighlight lang="perl"><br />
my %matchListFHEMduino = (<br />
....<br />
"5:FHEMduino_PT2262" => "^(?-i)IR.*\$",<br />
....<br />
"13:IT" => "^(?-i)i......\$",<br />
);<br />
</syntaxhighlight><br />
<br />
Siehe dazu Forumsbeitrag: {{Link2Forum|Topic=33422}}<br />
}}<br />
Die Match-Liste ordnet eine Nachrichtensyntax (regulärer Ausdruck) einem Modulnamen zu und wird in einem physikalischen Modul gesetzt. Sollte eine Nachricht vom physikalischen Gerät empfangen werden, die durch kein geladenes Modul verarbeitet werden kann ([[DevelopmentModuleAPI#Dispatch|Dispatch()]] prüft nur alle bisher geladenen Module aus der [[#Die Client-Liste|Client-Liste]]), so wird über die Match-Liste geprüft, welches Modul diese Nachricht verarbeiten kann. Dieses Modul wird anschließend geladen und die Nachricht durch dieses direkt durch Aufruf der [[#X_Parse|Parse]]-Funktion verarbeitet. In dieser Liste findet mittels regulärem Ausdruck eine Zuordnung der Nachrichtenstruktur zum verarbeitenden logischen Modul statt.<br />
<br />
Diese Liste wird ausschließlich in der [[DevelopmentModuleAPI#Dispatch|Dispatch()]]-Funktion verwendet. Sollte keine passendes Modul, welches bereits geladen ist, zur Verarbeitung einer Nachricht gefunden werden, so wird mithilfe der Match-Liste aufgrund der vorliegenden Nachricht das entsprechende Modul ermittelt. Dieses Modul wird dann direkt geladen und die Nachricht wird via [[#X_Parse|Parse]]-Funktion verarbeitet.<br />
<br />
Die Match-Liste ist eine Zuordnung von einem Sortierpräfix + Modulname zu einem regulären Ausdruck:<br />
<br />
<syntaxhighlight lang="perl"><br />
{<br />
"1:FS20" => "^81..(04|0c)..0101a001",<br />
"2:KS300" => "^810d04..4027a001",<br />
"3:FHT" => "^81..(04|09|0d)..(0909a001|83098301|c409c401).."<br />
}<br />
</syntaxhighlight><br />
<br />
Das Sortierpräfix (<code><u>1:</u><font color="grey">FS20</font></code>) dient als Sortierhilfe um so die Reihenfolge der Prüfung festzulegen. Bei der Prüfung wird die Match-Liste mittels sort() nach dem Schlüssel (Sortierpräfix + Modulname) sortiert und die regulären Ausdrücke werden dann nacheinander getestet. Daher sollten die präzisesten Ausdrücke immer zuerst getestet werden, sofern es weniger präzise Ausdrücke in der Match-Liste gibt. Dabei ist zu beachten, dass der Sortierpräfix nicht nach numerischen Regeln sortiert wird, sondern zeichenbasierend.<br />
<br />
Üblicherweise wird die Match-Liste in der [[#X_Initialize|Initialize]]-Funktion im Modul-Hash gesetzt:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Initialize($)<br />
{<br />
my ($hash) = @_;<br />
<br />
...<br />
<br />
$hash->{MatchList} = { "1:FS20" => "^81..(04|0c)..0101a001",<br />
"2:KS300" => "^810d04..4027a001",<br />
"3:FHT" => "^81..(04|09|0d)..(0909a001|83098301|c409c401).." };<br />
}<br />
</syntaxhighlight><br />
<br />
Man kann die Match-Liste, ähnlich wie bei der Client-Liste, auch pro physikalisches Gerät setzen. Dabei hat auch hier die Match-Liste eines Gerätes immer Vorrang vor der Match-Liste aus dem Modul-Hash:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Define($$)<br />
{<br />
my ($hash, $def) = @_;<br />
<br />
...<br />
<br />
$hash->{MatchList} = { "1:CUL_HM" => "^A...................." };<br />
}<br />
</syntaxhighlight><br />
<br />
=== Der Match-Ausdruck ===<br />
<br />
Ein Match-Ausdruck wird in einem logischen Modul gesetzt und dient der Prüfung, ob eine Nachricht durch das eigene Modul via [[#X_Parse|Parse]]-Funktion verarbeitet werden kann. Es handelt sich hierbei um einen einzelnen regulären Ausdruck, den FHEM innerhalb der [[DevelopmentModuleAPI#Dispatch|Dispatch()]]-Funktion prüft. Nur wenn eine Nachricht via Dispatch() auf diesen Audruck matcht, wird die Parse-Funktion des eigenen Moduls aufgerufen um die Nachricht zu verarbeiten. <br />
<br />
Der Hintergrund, warum man den Aufruf mit einem solchen Ausdruck vorher abprüft, liegt in der Möglichkeit, dass ein physikalisches Modul mehrere unterschiedliche logische Module ansprechen kann. So kann FHEM jedes geladene Modul durch diesen Match-Ausdruck prüfen, ob es diese Nachricht verarbeiten kann. Erst, wenn alle geladenen Module, aufgrund einer Prüfung des Ausdrucks, die Nachricht nicht verarbeiten können, wird via [[#Die_Match-Liste|Match-Liste]] ermittelt, welches Modul geladen werden muss um die Nachricht zu verarbeiten. <br />
<br />
Der Match-Ausdruck wird in der [[#X_Initialize|Initialize]]-Funktion zur Verfügung gestellt:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Initialize($)<br />
{<br />
my ($hash) = @_;<br />
<br />
...<br />
<br />
# Dieses Modul verarbeitet FS20 Nachrichten<br />
$hash->{Match} = "^81..(04|0c)..0101a001"; <br />
}<br />
</syntaxhighlight><br />
=== Die vollständige Implementierung ===<br />
<br />
Hier nun eine Zusammenfassung beim zweistufigen Modulkonzept in der jeweiligen Stufe implementiert werden muss, damit die Kommunikation funktioniert.<br />
<br />
==== physisches Modul ====<br />
<br />
Das physische Modul, welches als Kommunikationsbrücke zwischen der Hardware und logischen Modulen fungieren wird, sollte mindestens folgende Funktionen implementieren:<br />
<br />
* [[#X_Initialize|Initialize]]-Funktion - Zum Registrieren des Moduls in FHEM.<br />
* [[#X_Define|Define]]-Funktion - Zum öffnen der Datenverbindung zur Hardware (IP-Adresse/serielle Schnittstelle/...).<br />
* [[#X_Read|Read]]-Funktion - Zum Lesen von Daten, welche die Hardware übermittelt.<br />
* [[#X_Read|Ready]]-Funktion - Zum Wiederaufbau der Verbindung bei Verbindungsabbruch, bzw. Prüfung auf lesbare Daten bei serieller Schnittstelle unter Windows.<br />
* [[#X_Write|Write]]-Funktion - Zum Senden von Daten, welche logische Module via [[DevelopmentModuleAPI#IOWrite|IOWrite()]] an die Hardware übertragen möchten.<br />
* [[#X_Undef|Undef]]-Funktion - Schließen der Verbindung zur Hardware beim Löschen via <code>delete</code> bzw. <code>rereadcfg</code>.<br />
* [[#X_Shutdown|Shutdown]]-Funktion - Schließen der Verbindung zur Hardware beim Stopp von FHEM via <code>shutdown</code>.<br />
* [[#X_DelayedShutdown | DelayedShutdown]]-Funktion - Verzögertes beenden zum Schließen der Verbindung zur Hardware beim Stopp von FHEM via <code>shutdown</code>.<br />
<br />
<br />
Desweiteren müssen in der [[#X_Initialize|Initialize]]-Funktion folgende Daten bereitgestellt werden:<br />
<br />
* [[#Die_Client-Liste|Client-Liste]] - Auflistung aller logischen Module, die über dieses Modul kommunizieren können<br />
* [[#Die_Match-Liste|Match-Liste]] - Zuordnung von Nachrichtensyntax zu Modul zwecks Autoload-Funktionalität.<br />
<br />
==== logisches Modul ====<br />
<br />
Das logische Modul, bildet ein einzelnes Gerät ab, über das mit einem physikalisches Modul kommuniziert werden kann. Es sollte mindestens folgende Funktionen implementieren:<br />
<br />
* [[#X_Initialize|Initialize]]-Funktion - Zum Registrieren des Moduls in FHEM.<br />
* [[#X_Define|Define]]-Funktion - Speichern des Definition Pointers (siehe [[#X_Parse|Parse-Funktion]])<br />
* [[#X_Parse|Parse]]-Funktion - Zum Lesen von Daten, welche die Hardware übermittelt.<br />
* [[#X_Undef|Undef]]-Funktion - Löschen des Definition Pointers beim Löschen via <code>delete</code> bzw. <code>rereadcfg</code>.<br />
<br />
Desweiteren müssen in der [[#X_Initialize|Initialize]]-Funktion folgende Daten bereitgestellt werden:<br />
<br />
* [[#Der_Match-Ausdruck|Match-Ausdruck]] - Prüfausdruck, ob eine Nachricht durch dieses Modul verarbeitet werden kann.<br />
<br />
=== Kommunikation von der Hardware bis zu den logischen Modulen ===<br />
<br />
Die Gerätedefinition des physischen Moduls öffnet eine Verbindung zur Hardware (z.B. via [[DevIo]]). Die [[#X_Read|Read]]-Funktion wird bei anstehenden Daten aus der Hauptschleife von fhem.pl aufgerufen.<br />
<br />
Die Read-Funktion stellt dabei sicher, dass die Daten<br />
* komplett (in der Regel über einen internen Puffer in <code>$hash</code>) und<br />
* korrekt (z.B. via Prüfung mittels regulärem Ausdruck)<br />
sind und ruft die globale Funktion [[DevelopmentModuleAPI#Dispatch|Dispatch()]] mit einer kompletten Nachricht auf.<br />
<br />
Die Funktion Dispatch() prüft alle geladenen Module aus der [[#Die_Client-Liste|Client-Liste]] des physikalischen Moduls nach möglichen logischen Modulen zur Verarbeitung. Alle zum Zeitpunkt geladenen Module, die in der Client-Liste aufgeführt sind, werden über den [[#Der_Match-Ausdruck|Match-Ausdruck]] geprüft, ob sie mit der Nachricht etwas anfangen können. Sollte bei einem logischen Modul der Match-Ausdruck passen, so wird die entsprechende [[#X_Parse|Parse]]-Funktion des logischen Moduls aufgerufen. Sofern keine passendes Modul gefunden wurde, um die Nachricht zu verarbeiten, wird in der [[#Die_Match-Liste|Match-Liste]] im Geräte- bzw. Modul-Hash der physischen Gerätedefinition nach dem passenden Modul gesucht. Sollte es darin ein Modul geben, was diese Art von Nachricht verarbeiten kann, so wird versucht dieses Modul zu laden um nun die Nachricht via Parse-Funktion zu verarbeiten. Es erfolgt in diesem Fall keine Vorprüfung durch den Match-Ausdruck.<br />
<br />
Durch Dispatch() wird nun die [[#X_Parse|Parse]]-Funktion des gefundenen logischen Moduls aufgerufen. Diese<br />
* interpretiert die übergebene Nachricht,<br />
* versucht eine existierende Gerätedefinition in FHEM zu finden (z.B. mittels Definition Pointer), für welche die Nachricht addressiert ist,<br />
* setzt alle [[#Readings|Readings]] für die gefundene Gerätedefinition via [[DevelopmentModuleAPI#Readings_.2F_Events|readings*update]]()-Funktionen,<br />
* gibt den Namen der logischen Definition zurück, welche die Nachricht verarbeitet hat.<br />
<br />
Sollte keine passende Gerätedefinition für die entsprechende Nachricht existieren (Adresse/ID/Kanal/...), wird der Gerätename "UNDEFINED" inkl. einem passenden <code>define</code>-Statement zurückgegeben, um die Definition durch [[autocreate]] erzeugen zu lassen.<br />
<br />
Es findet während der Verarbeitung einer Nachricht durch Dispatch()/Parse-Funktion keine sofortige Eventverarbeitung (via [[DevelopmentModuleAPI#Dispatch|DoTrigger()]]) statt, wenn die [[DevelopmentModuleAPI#Readings_.2F_Events|readings*update]]()-Funktionen verwendet werden.<br />
(Im Gegensatz zum direkten Aufrufen der readings*update Funktionen ohne vorhergehendes Dispatch() )<br />
<br />
Die Funktion Dispatch() triggert das Event-Handling für das von der Parse-Funktion zurückgegebene logische Device selbstständig nach Abschluss der Parse-Funktion.<br />
<br />
Optional führt die Funktion Dispatch() eine Überprüfung auf Nachrichtenduplikate beim Einsatz von mehreren IO-Geräten durch. Dazu wird eine implementierte [[#X_Fingerprint|Fingerprint]]-Funktion im physischen oder logischen Modul benötigt. Sollte der Fingerprint einer Nachricht innerhalb einer bestimmten Zeit (globales Attribut <code>dupTimeout</code>, standardmäßig 500ms) bereits empfangen worden sein, so wird die Nachricht verworfen. Dies ist insbesondere bei funkbasierter Hardware notwendig, wenn mehrere Empfänger die selbe Nachricht empfangen.<br />
<br />
=== Kommunikation von den logischen Modulen bis zur Hardware ===<br />
<br />
Um von einem logischen Modul eine Nachricht an die Hardware senden zu können, muss zunächst im logischen Gerät ein passenden IO-Gerät ausgewählt sein. Dazu muss die Funktion [[DevelopmentModuleAPI#AssignIoPort|AssignIoPort()]] ein entsprechendes IO-Gerät auswählen und in <code>$hash->{IODev}</code> setzen. Dieser Aufruf wird üblicherweise in der [[#X_Define|Define]]-Funktion des logischen Moduls ausgeführt. Erst, wenn ein IO-Gerät ausgewählt wurde, können Daten über das physikalische Gerät an die Hardware übermittelt werden.<br />
<br />
Zum Senden von Daten ruft das logische Modul die Funktion [[DevelopmentModuleAPI#IOWrite|IOWrite()]] samt Daten auf. Diese ruft für das entsprechende IO-Gerät die [[#X_Write|Write]]-Funktion auf und übergibt die Daten zum Schreiben an das physikalische Modul. Die Write-Funktion kümmert sich nun um die Übertragung der Daten an die Hardware. <br />
<br />
Keine direkten Zugriffe zwischen dem logischen und dem physischen Gerät gibt (d.h. keine direkten Aufrufe von Funktionen, kein direktes Überprüfen von <code>$hash</code>-Inhalten, ...), so können die Module hintereinander geschaltet werden (z.B. für Routerfunktionen wie bei der [[RFR_CUL|RFR]]-Funktionalität) oder mittels [[FHEM2FHEM]] im RAW-Modus zwei FHEM-Installationen verbunden werden und die logischen Geräte können dennoch kommunizieren.<br />
<br />
=== Automatisches Anlegen von logischen Gerätedefinitionen (autocreate) ===<br />
<br />
Das logische Modul kann im Rahmen der [[#X_Parse|Parse]]-Funktion eine neue Gerätedefinition anlegen, sofern eine passende Definition nicht existieren sollte. Die Parse-Funktion gibt generell den Namen der logischen Gerätedefinition zurück, für welche die Nachricht verarbeitet wurde. Sollte keine passende Definition gefunden werden, so muss die Parse-Funktion folgenden Rückgabewert liefern (zusammenhängende Zeichenkette):<br />
<br />
UNDEFINED ''&lt;Namensvorschlag&gt;'' ''&lt;Modulname&gt;'' ''&lt;Define-Parameter...&gt;''<br />
<br />
Sollte also bspw. im Rahmen der Parse-Funktion zu Modul X eine Nachricht nicht einer existierenden Gerätedefinition zugeordnet werden können, so muss ein Namensvorschlag erstellt werden der eine eindeutige Komponente wie bspw. eine Adresse/ID/Kanal-Nr enthält. In der Regel wird hier immer der Modulname zusammen mit der eindeutigen Komponente, durch einen Unterstrich getrennt, verwendet (Bsp: <code>X_4834</code>). Der Modulname ist in der Regel immer der, des eigenen Moduls. In besonderen Fällen kann man hier auch einen abweichenden Modulnamen angeben. Dies wird bspw. bei den [[PanStamp#FHEM-Module.2FDevice_Definition_Files|SWAP-Modulen]] eingesetzt. Als Define-Parameter müssen alle notwendigen Parameter angegeben werden, die beim Aufruf des <code>define</code>-Befehls notwendig sind, damit eine neu angelegte Gerätedefinition Nachrichten zu dieser eindeutigen Adresse Daten verarbeitet. Dazu muss mind. die eindeutige Adresse mitgegeben werden.<br />
<br />
Beispiel für FS20:<br />
<br />
UNDEFINED FS20_0ae42f8 FS20 0ae42 f8<br />
<br />
Sobald [[DevelopmentModuleAPI#Dispatch|Dispatch()]] einen solchen Rückgabewert von einer [[#X_Parse|Parse]]-Funktion erhält, wird diese Zeichenkette so wie sie ist via [[DevelopmentModuleAPI#DoTrigger|DoTrigger()]] als Event für die Definition <code>global</code> getriggert.<br />
<br />
Sofern der Nutzer das Modul [[autocreate]] verwendet (definiert hat), kümmert sich dieses nun um das Anlegen einer entsprechenden Gerätedefinition. Es lauscht dabei auf generierte Events der Definition <code>global</code> via [[#X_Notify|Notify]]-Funktion. Der Nutzer kann dabei das Verhalten von autocreate durch entsprechende Parameter beeinflussen.<br />
<br />
Das Modul, für welches autocreate eine neue Definition anlegen möchte, kann das Verhalten durch entsprechende Parameter im Modul-Hash beeinflussen. Dabei gilt, dass gesetzte Attribute durch den Nutzer generell Vorrang haben. Die entsprechenden Parameter werden dabei im Rahmen der [[#X_Initialize|Initialize]]-Funktion im Modul-Hash gesetzt:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub X_Initialize($)<br />
{<br />
my ($hash) = @_;<br />
<br />
...<br />
<br />
$hash->{AutoCreate} = {"X_.*" => { ATTR => "event-on-change-reading:.* event-min-interval:.*:300",<br />
FILTER => "%NAME",<br />
GPLOT => "temp4hum4:Temp/Hum,",<br />
autocreateThreshold => "2:140"<br />
}<br />
};<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
Hierbei wird unterhalb von <code>$hash->{AutoCreate}</code> eine Liste angelegt, wo einem regulären Ausdruck für einen anzulegenden Definitionsnamen entsprechende Optionen zugeordnet werden. Sobald durch autocreate eine Gerätedefintion angelegt wird, auf den ein hier gelisteter Ausdruck matcht, so werden die zugeordneten Optionen berücksichtigt.<br />
<br />
Hier eine Auflistung aller möglichen Optionen und ihrer Bedeutung:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Optionsname !! Beispiel !! Bedeutung<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | <code>ATTR</code>|| style="vertical-align:top; white-space: nowrap;" | <code>"event-on-change-reading:.* event-min-interval:.*:300"</code> || Eine Auflistung von Attributen, die nach dem Anlegen einer Definition zusätzlich gesetzt werden. Es handelt sich hierbei um eine Leerzeichen-separierte Liste von Doppelpunkt-getrennten Tupels mit Attributname und -wert.<br />
<br />
Für das dargestellte Beispiel bedeutet dies, dass nach dem Anlegen der Definition folgende FHEM-Befehle zusätzlich ausgeführt werden:<br />
<br />
attr ''&lt;Name&gt;'' event-on-change-reading .*<br />
attr ''&lt;Name&gt;'' event-min-interval .*:300<br />
<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | <code>FILTER</code> || style="vertical-align:top; white-space: nowrap;" | <code>"%NAME"</code>|| Sofern in der autocreate-Definiton das Attribut <code>filelog</code> entsprechend durch den Nutzer gesetzt ist, wird eine zugehörige FileLog-Definition angelegt. Diese Option setzt den dabei benutzten Filter-Regexp, der beim Anlegen der FileLog-Definition gesetzt wird. <br />
<br />
Dabei werden folgende Platzhalter durch die entsprechenden Werte der neu angelegten Gerätedefinition ersetzt:<br />
<br />
* <code>%NAME</code> - wird ersetzt durch den Definitionsnamen<br />
* <code>%TYPE</code> - wird ersetzt durch den Modulnamen<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | <code>GPLOT</code> || style="vertical-align:top; white-space: nowrap;" | <code>"temp4hum4:Temp/Hum,"</code> || Sofern eine FileLog-Definition angelegt wurde, kann man weiterführend dazu eine passende SVG-Definition erzeugen um Daten aus dem erzeugten FileLog zu visualisieren. Ein typischer Fall sind hierbei Temperatursensoren, wo es sinnvoll sein kann, einen passenden SVG-Plot mit Temperatur/Luftfeuchtigkeit direkt anzulegen.<br />
<br />
Es handelt sich hierbei um eine kommaseparierte Auflistung von gplot-Dateinamen und optionalen Label-Texten durch einen Doppelpunkt getrennt. Im genannten Beispiel entspricht <code>temp4hum4</code> der zu verwendenden GnuPlot-Datei und <code>Temp/Hum</code> dem zu verwendenden Label ([[SVG]] Attribut <code>label</code>). Das Label wird auch durch FileLog verwendet als Link-Text zum entsprechenden SVG Plot. Alternativ kann auch nur die entsprechende GnuPlot-Datei anegeben werden ohne Label. Für jede angegebene GnuPlot-Datei wird anschließend eine entsprechende SVG-Definition erzeugt mit der vorher erzeugten FileLog-Definition als Datenquelle.<br />
<br />
Der gesamte Inhalt der <code>GPLOT</code>-Option wird beim Anlegen einer FileLog-Definition dem Attribut <code>logtype</code> als Wert plus dem Text <code>text</code> zugewiesen. Daher muss der Inhalt der Option <code>GPLOT</code> immer mit einem Komma enden. <br />
<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | <code>autocreateThreshold</code> || style="vertical-align:top; white-space: nowrap;"| <code>"2:10"</code> || Definiert, wie viele Aufrufe (im Bsp: <code>2</code>) von autocreate innerhalb welcher Zeit (im Bsp: <code>10</code> Sek.) stattfinden müssen, bevor die Gerätedefinition tatsächlich durch autocreate angelegt wird. Dadurch kann das ungewollte Anlegen von Geräten verhindert werden die tatsächlich nicht in Echt existieren. Aufgrund von Funkstörungen kann es durchaus zum ungewollten Anlegen einer Definition kommen. Diese Funktion lässt eine Definition erst zu wenn innerhalb einer vorgegeben Zeit eine Mindestzahl an Nachrichten eintrifft.<br />
<br />
Die erste Zahl stellt dabei die Mindestanzahl an Nachrichten dar. Die Zweite Zahl stellt die Zeit in Sekunden dar, in der die Mindestanzahl an Nachrichten erreicht werden muss um eine entsprechende Gerätedefinition anzulegen. <br />
<br />
Sofern diese Option nicht gesetzt ist, wird standardmäßig <code>2:60</code> verwendet.<br />
<br />
Diese Option kann durch den Anwender über das Attribut <code>autocreateThreshold</code> übersteuert werden.<br />
|-<br />
| style="vertical-align:top; white-space: nowrap;" | <code>noAutocreatedFilelog</code>|| style="vertical-align:top; white-space: nowrap;" | <code>1</code>|| Flag. Sofern gesetzt, wird keine FileLog- und ggf. SVG-Definition erzeugt. Selbst wenn der Nutzer durch entsprechende Attribute das Anlegen wünscht. Diese Option ist sinnvoll für Module bzw. Geräte die keine Readings erzeugen.<br />
|}<br />
<br />
== Ergänzende Hinweise ==<br />
Die Wahl der vorangestellten Nummer für den Dateinamen eines neuen Moduls hat keine Bedeutung mehr, es sei denn die Nummer ist 99. Module, die mit 99_ beginnen, werden von FHEM automatisch geladen. Module mit einer anderen Nummer nur wenn ein <code>define</code>-Befehl dafür sorgt, dass das Modul geladen wird.<br />
<br />
Wenn ein Modul Initialisierungsdaten benötigt, sollten diese im Modul selbst enthalten sein. Eine zusätzliche Datei oder sogar ein Unterverzeichnis mit mehreren Dateien ist bei FHEM nicht üblich und sollte bei Modulen, die mit FHEM ausgeliefert werden nur in Rücksprache mit Rudolf König angelegt werden, da sie sonst bei einem Update nicht verteilt werden.<br />
<br />
== Weitere Informationen ==<br />
Wenn man weitere Details wissen möchte, ist ein erster sinnvoller Schritt ein Blick in die Datei fhem.pl. Dort sieht man im Perl-Code wie die Module aufgerufen werden, was vorher passiert und was danach. Am Anfang der Datei (ca. ab Zeile 130) findet man beispielsweise eine Liste der globalen Variablen, die den Modulen zur Verfügung stehen sowie Details zu den wichtigen Hashes %modules und %defs. Wer mit Perl noch nicht so gut klar kommt, dem hilft eventuell ein Blick auf die Perldoc Website[http://perldoc.perl.org/] oder in das Perl-Buch seiner Wahl. Auch die FHEM {{Link2CmdRef}} sollte nicht unterschätzt werden. Es stehen oft mehr interessante Details auch für Modulentwickler darin als man zunächst vermuten könnte.<br />
<br />
<br />
== "Hello World" Beispiel ==<br />
<br />
98_Hello.pm<br />
<br />
<syntaxhighlight lang="perl"><br />
package main;<br />
use strict;<br />
use warnings;<br />
<br />
my %Hello_gets = (<br />
"whatyouwant" => "can't",<br />
"whatyouneed" => "try sometimes",<br />
"satisfaction" => "no"<br />
);<br />
<br />
sub Hello_Initialize($) {<br />
my ($hash) = @_;<br />
<br />
$hash->{DefFn} = 'Hello_Define';<br />
$hash->{UndefFn} = 'Hello_Undef';<br />
$hash->{SetFn} = 'Hello_Set';<br />
$hash->{GetFn} = 'Hello_Get';<br />
$hash->{AttrFn} = 'Hello_Attr';<br />
$hash->{ReadFn} = 'Hello_Read';<br />
<br />
$hash->{AttrList} =<br />
"formal:yes,no "<br />
. $readingFnAttributes;<br />
}<br />
<br />
sub Hello_Define($$) {<br />
my ($hash, $def) = @_;<br />
my @param = split('[ \t]+', $def);<br />
<br />
if(int(@param) < 3) {<br />
return "too few parameters: define <name> Hello <greet>";<br />
}<br />
<br />
my $hash->{name} = $param[0];<br />
my $hash->{greet} = $param[2];<br />
<br />
return undef;<br />
}<br />
<br />
sub Hello_Undef($$) {<br />
my ($hash, $arg) = @_; <br />
# nothing to do<br />
return undef;<br />
}<br />
<br />
sub Hello_Get($@) {<br />
my ($hash, @param) = @_;<br />
<br />
return '"get Hello" needs at least one argument' if (int(@param) < 2);<br />
<br />
my $name = shift @param;<br />
my $opt = shift @param;<br />
if(!$Hello_gets{$opt}) {<br />
my @cList = keys %Hello_gets;<br />
return "Unknown argument $opt, choose one of " . join(" ", @cList);<br />
}<br />
<br />
if($attr{$name}{formal} eq 'yes') {<br />
return $Hello_gets{$opt}.', sir';<br />
}<br />
return $Hello_gets{$opt};<br />
}<br />
<br />
sub Hello_Set($@) {<br />
my ($hash, @param) = @_;<br />
<br />
return '"set Hello" needs at least one argument' if (int(@param) < 2);<br />
<br />
my $name = shift @param;<br />
my $opt = shift @param;<br />
my $value = join("", @param);<br />
<br />
if(!defined($Hello_gets{$opt})) {<br />
my @cList = keys %Hello_gets;<br />
return "Unknown argument $opt, choose one of " . join(" ", @cList);<br />
}<br />
$hash->{STATE} = $Hello_gets{$opt} = $value;<br />
<br />
return "$opt set to $value. Try to get it.";<br />
}<br />
<br />
<br />
sub Hello_Attr(@) {<br />
my ($cmd,$name,$attr_name,$attr_value) = @_;<br />
if($cmd eq "set") {<br />
if($attr_name eq "formal") {<br />
if($attr_value !~ /^yes|no$/) {<br />
my $err = "Invalid argument $attr_value to $attr_name. Must be yes or no.";<br />
Log 3, "Hello: ".$err;<br />
return $err;<br />
}<br />
} else {<br />
return "Unknown attr $attr_name";<br />
}<br />
}<br />
return undef;<br />
}<br />
<br />
1;<br />
<br />
=pod<br />
=begin html<br />
<br />
<a name="Hello"></a><br />
<h3>Hello</h3><br />
<ul><br />
<i>Hello</i> implements the classical "Hello World" as a starting point for module development. <br />
You may want to copy 98_Hello.pm to start implementing a module of your very own. See <br />
<a href="http://wiki.fhem.de/wiki/DevelopmentModuleIntro">DevelopmentModuleIntro</a> for an <br />
in-depth instruction to your first module.<br />
<br><br><br />
<a name="Hellodefine"></a><br />
<b>Define</b><br />
<ul><br />
<code>define &lt;name&gt; Hello &lt;greet&gt;</code><br />
<br><br><br />
Example: <code>define HELLO Hello TurnUrRadioOn</code><br />
<br><br><br />
The "greet" parameter has no further meaning, it just demonstrates<br />
how to set a so called "Internal" value. See <a href="http://fhem.de/commandref.html#define">commandref#define</a> <br />
for more info about the define command.<br />
</ul><br />
<br><br />
<br />
<a name="Helloset"></a><br />
<b>Set</b><br><br />
<ul><br />
<code>set &lt;name&gt; &lt;option&gt; &lt;value&gt;</code><br />
<br><br><br />
You can <i>set</i> any value to any of the following options. They're just there to <br />
<i>get</i> them. See <a href="http://fhem.de/commandref.html#set">commandref#set</a> <br />
for more info about the set command.<br />
<br><br><br />
Options:<br />
<ul><br />
<li><i>satisfaction</i><br><br />
Defaults to "no"</li><br />
<li><i>whatyouwant</i><br><br />
Defaults to "can't"</li><br />
<li><i>whatyouneed</i><br><br />
Defaults to "try sometimes"</li><br />
</ul><br />
</ul><br />
<br><br />
<br />
<a name="Helloget"></a><br />
<b>Get</b><br><br />
<ul><br />
<code>get &lt;name&gt; &lt;option&gt;</code><br />
<br><br><br />
You can <i>get</i> the value of any of the options described in <br />
<a href="#Helloset">paragraph "Set" above</a>. See <br />
<a href="http://fhem.de/commandref.html#get">commandref#get</a> for more info about <br />
the get command.<br />
</ul><br />
<br><br />
<br />
<a name="Helloattr"></a><br />
<b>Attributes</b><br />
<ul><br />
<code>attr &lt;name&gt; &lt;attribute&gt; &lt;value&gt;</code><br />
<br><br><br />
See <a href="http://fhem.de/commandref.html#attr">commandref#attr</a> for more info about <br />
the attr command.<br />
<br><br><br />
Attributes:<br />
<ul><br />
<li><i>formal</i> no|yes<br><br />
When you set formal to "yes", all output of <i>get</i> will be in a<br />
more formal language. Default is "no".<br />
</li><br />
</ul><br />
</ul><br />
</ul><br />
<br />
=end html<br />
<br />
=cut<br />
</syntaxhighlight><br />
<br />
Der HTML-Code zwischen den Tags <code>=pod</code> und <code>=cut</code> dient zur Generierung der commandref.html. Der HTML-Inhalt wird automatisch beim Verteilen des Moduls im Rahmen des Update-Mechanismus aus jedem Modul extrahiert und daraus die Commandref in verschiedenen Sprachen erstellt. Eine detaillierte Beschreibung wie ein Commandref-Abschnitt in einem Modul definiert wird, siehe: [[Guidelines zur Dokumentation]]<br />
<br />
<br />
[[Kategorie:Development]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=Kommunikationsprobleme_mit_FHT&diff=29547Kommunikationsprobleme mit FHT2019-02-17T19:18:40Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>{{Randnotiz|RNTyp=y|RNText=Das FHT System ist seit 2017 abgekündigt. Vom Hersteller sind keine Neugeräte mehr erhältlich. Es ist daher zu überlegen, fehlerhafte FHTs durch andere von FHEM unterstützte Systeme zu ersetzen, z.B. MAX oder HomeMatic. Parallelbetrieb ist mit zusätzlicher Schnittstelle möglich.}}Während FHEM mit reinen Schaltaktoren in der Regel problemarm funktioniert, sind Probleme mit [[FHT80b]] Heizungssteuerungen recht häufig. Dies liegt in der deutlich anspruchsvolleren bidirektionalen Kommunikation, die zur Übermittlung der ggf. durchaus umfangreichen Daten notwendig ist.<br />
<br />
<br />
== Symptome ==<br />
Im Einsatz von FHTs kann es zu folgenden Symptomen kommen:<br />
<br />
* FHT funktioniert zunächst einwandfrei, dann plötzlich sind keine Temperaturänderungen o.ä. mehr möglich<br />
* FHTs funktionieren einwandfrei, jedoch seitdem ein weiteres dazu gekommen ist, wird die Datenübertragung langsam oder fällt ganz aus, auch zu FHTs, die vorher ohne Probleme liefen.<br />
* FHT funktioniert manchmal für Stunden gut, übermittelt aktuelle Werte und lässt sich ansprechen, dann für mehrere Stunden wieder nicht, schließlich "erholt" sich das FHT wieder (oft über Nacht)<br />
* Temperaturänderungen werden von FHT mit hoher Verzögerung (bis hin zu Stunden) ausgeführt<br />
* FHTs laufen ca. eine Woche problemfrei, dann kommen keinen Daten mehr. Nach einem neuen Pairing ist alles wieder in Ordnung, bis nach ca. einer Woche wieder keine Daten kommen.<br />
<br />
== Problemquellen ==<br />
Die FHT-Kommunikation ist recht fragil. Für eine erfolgreiche Kommunikation müssen eine Menge Funktelegramme in einem bestimmten Timing ausgetauscht werden. Selbst wenn keine Kommandos an das [[FHT80b]] übergeben werden, finden alle 15 Minuten Datenübermittlungen statt, da das FHT Temperatur und andere Daten meldet.<br />
<br />
Bereits ein fehlendes Datenpaket kann dazu führen, dass die Kommunikation erfolglos war und insgesamt alles wiederholt werden muss.<br />
<br />
Störungen des Kanals (z.B. der berühmte Funkkopfhörer aus China) führen daher so gut wie immer zu Problemen in der FHT-Kommunikation. Es reicht, wenn von den 5+n Kommandos (n=Anzahl der übermittelten Werteänderungen) die mindestens hin und her gehen müssen, eines nicht korrekt ankommt und schon muss alles wiederholt werden.<br />
<br />
Diese Wiederholung kann aber nur ca. alle 2 Minuten erfolgen. Kommandos, die noch nicht erfolgreich abgearbeitet wurden, verbleiben im FHT Befehlsbuffer des CUL/CUNO (oder sonstiger Funkschnittstellen), obwohl sie seitens FHEM als "abgesetzt" geloggt werden. Dieser FHT Buffer kann mitunter sehr viele Kommandos aufnehmen, die der Reihe nach abgearbeitet werden. Kann z.B. eine Temperaturänderung aufgrund von Funkproblemen erst nach ca. 3 Versuchen erfolgreich zugestellt werden, so dauert es in der Regel etwa 3 x 2 = 6 Minuten, bis die Änderung im FHT sichtbar ankommt. Wird z.B. aus Ungeduld eine erneute Temperaturänderung ausgelöst, so wird diese im FHT Buffer gespeichert und dann nach erfolgter Übertragung des ersten Kommandos übermittelt. Die Abarbeitungszeit der Warteschlange für dieses FHT steigt dann bereits auf ca. 12 Minuten. Es ist leicht möglich, durch Abfrage der Wochenprogramme, Änderung der Day- oder Nighttemperatur, oder Änderung von Wochenschaltpunkten Warteschlangen aufzubauen, die buchstäblich Stunden oder gar Tage zum Abarbeiten benötigen. Temperaturänderungen könnten also mitunter erst Stunden später tatsächlich ausgeführt werden. Jeder Aussendungsversuch führt außerdem zur Belastung des Sendekontos. Ist die [[1% Regel]] überschritten, wird die Warteschlange nicht mehr weiter abgearbeitet.<br />
<br />
Solche Störungen des Funkkanals sind nicht selten und können auch ohne äußere Einflüsse stattfinden.<br />
Die FHTs sind mit relativ ungenauen Sendern ausgestattet und können in Sendefrequenz und Flankensteilheit mitunter deutlich von den Sollwerten abweichen, was insbesondere beim Einsatz von CUL / CUNO (weniger beim Einsatz einer FHZ1x00PC) ein Problem sein kann, weil die CUL / CUNO eher trennscharf sind. Dies kann dazu führen, dass die Funkkommunikation oft fehlerhaft ist oder sogar ganz abbricht.<br />
<br />
Zusätzlich stellen einige FHTs das Aussenden von Temperatur und weiteren Daten nach 5-10 Tagen ein, wenn nicht zwischendurch von der Zentrale Änderungen übermittelt wurden.<br />
<br />
Alle vorstehenden Gründe kombinieren sich für gewöhnlich zu einem komplexen Versagensszenario, das sich gegenseitig selbst verstärkt:<br />
<br />
* Schlechte Funklage eines FHT80b erzeugt häufige Retrys.<br />
* Inzwischen stauen sich weitere Kommandos an das FHT auf, z.B. wegen erneuter Temperaturänderungen, automatisiert oder aus Ungeduld, sowie andere Meldungen, etwa Abfrage oder Ändern des Wochenprogramms.<br />
* Die Kommandos sammeln sich im FHT Buffer des Funkadapters an und sorgen dafür, dass die Sendezeit hoch belastet wird.<br />
* Fast Glück hat man noch, wenn der Buffer voll läuft und [[EOB]] Meldungen im Log darauf hinweisen. Es kann aber auch passieren, dass über größere Zeiträume der Buffer gerade eben nicht voll wird, insbesondere bei CUL / CUN, die im Vergleich zur FHZ1x00PC große Buffer haben, die 30 und mehr Kommandos halten können. Ist zusätzlich das Feature "Softbuffer" eingeschaltet, verschlimmert sich die Situation weiter, da die Warteschlange noch länger werden kann.<br />
* Ist die 1% Marke erreicht, das Funkkontingent also aufgebraucht, verschlimmert sich die Situation dramatisch: Nun bricht auch die Kommunikation mit anderen FHTs zusammen. Da außerdem immer Kommandos im FHT Buffer sind, wird jede freie Sendezeit durch Versuche, die Warteschlange abzuarbeiten, sofort wieder aufgebraucht. Das Timing des Gesamtsystems ist hier leider so, dass sich innerhalb des Retryintervals von ca. 2 Minuten oft gerade zu wenig freie Sendezeiteinheiten aufbauen, um den nächsten Retry komplett abwickeln zu können. D.h. jedes Retry braucht die gerade aufgebauten freien Sendeeinheiten auf, ist aber in sich erfolglos.<br />
* Spätestens ab hier ist vollständiger Stillstand erreicht. Im Log häufen sich die [[LOVF]]- Meldungen, jede Kommunikation mit allen FHTs ist zusammengebrochen. Es kommt eventuell sogar zu Beeinträchtigungen beim Schalten von FS20 Aktoren.<br />
<br />
Mit der Anzahl FHTs steigt die Wahrscheinlichkeit für das Auftreten dieser Probleme.<br />
<br />
Viele FHEM Nutzer verwenden die Kombination von FHEM und FHT so, dass die FHTs über Manipulation der im FHT gespeicherten Wochenprogramme, Schaltpunkte und Day/Nighttemp gesteuert werden. Dies erhöht die Datenmenge im Vergleich zu einer direkten Temperatursteuerung ("set desired-temp 22") und wird in kritischen Situationen die Fehlerhäufigkeit deutlich anheben. Sehr viel Datenverkehr erzeugt auch die komplette Abfrage des Wochenprogramms mittels Report1=255.<br />
<br />
== Diagnose und Lösungsansätze ==<br />
Im Folgenden einige Hinweise wie man das Auftreten von Problemen verringern bzw. diagnostizieren kann.<br />
<br />
=== Sparsam mit Funkzeit umgehen ===<br />
Da die Ausnutzung der freien Funkzeit jede Situation schnell deutlich verschlimmert, sollte man immer bemüht sein, seine Ziele mit wenig Datenverkehr zu erreichen. Dies gilt insbesondere, wenn man sich der Anzahl [[Maximal nutzbare Geräte]] nähert.<br />
<br />
* [[Heizung_mit_Bewegungsmelder_steuern#FHT80b|FHT Lazy Mode]] nutzen (Temperaturänderungen werden nur übertragen, wenn sie von der momentan eingestellten Temperatur abweichen.) Dies ist besonders hilfreich, wenn die Temperatursteuerung automatisiert durch Bewegungsmelder oder "Zuhausestatus"-Automatismen gesteuert wird, da hier in relativ kurzer Folge die selbe Temperatureinstellung übermittelt wird. Lazy Mode schützt aber nicht immer davor, dass die Warteschlange schnell anschwillt. Steht ein FHT80b z.B. auf 18 Grad, und soll auf 20 Grad angehoben werden, wenn ein Bewegungsmelder auslöst, so wird das Kommando trotz Lazy Mode immer wieder bei Bewegungsmelderauslösung in die Warteschlange eingetragen, solange das erste Kommando nicht erfolgreich abgesetzt und die neue Temperatur vom FHT rückgemeldet wurde. Das kann dazu führen, dass die FHT-Warteschlange dutzende Male das selbe "desired-temp" Kommando enthält. Wenn die Kommandos in der Warteschlange sind, gibt es keine Instanz mehr, die bemerken könnte, dass die nachfolgenden Kommandos überflüssig sind: Es wird gnadenlos versucht, alles zu senden. Lazy Mode wirkt auch bei set date oder set time (Stunde).<br />
<br />
* Temperatursteuerung der FHTs nicht durch tägliche Änderung der Wochenprogramme im FHT durchführen. Obwohl diese Methode den Vorteil hat, dass sie eine höhere Ausfallsicherheit bietet (weil die FHTs auch ohne FHEM ihr zuletzt eingegebenes Wochenprogamm weiter verwenden können), so steigt der auszutauschende Datenverkehr stark an.<br />
:Mitunter verwendete Implementationen, die Anhand von Tabellen, Kalendern oder der Auswertung von Excelsheets mehrere FHTs regelmäßig mit geänderten Wochenprogrammen und/oder Änderungen der Day/Night Temperaturen steuern, sind in schwierigen Funksituationen deutlich anfälliger.<br />
<br />
* Soweit möglich, in FHEM versuchen, Kommandos zusammenzufassen. Bis zu acht Kommandos können in einem SET Befehl abgesetzt werden, z.B.:<br />
::<code>set fl desired-temp 20.5 day-temp 19.0 night-temp 16.0</code><br />
:Diese werden schneller abgearbeitet als entsprechende Einzelkommandos.<br />
<br />
* Zeitlich unkritische Kommandos (z.B. Setzen des Datums) spät nachts durchführen, wo das Sendekontingent unbelastet ist.<br />
<br />
* Keine regelmäßigen Reports abfragen, insbesondere NICHT report1=255 (also komplettes Wochenprogramm abfragen)<br />
:Da einige FHTs nach einiger Zeit keine Temperaturdaten mehr senden, fragen viele Nutzer diese über tägliches Absetzen von report2=255 ab. Besser ist es jedoch, das FHT mit einem Watchdog zu überwachen und nur bei Bedarf zu "wecken", z.B. so:<br />
::<code>define wd_FHT_Wohnzimmer watchdog hzg_wohnzimmer:measured-temp.* 01:00 SAME set hzg_wohnzimmer time</code><br />
:Alternativ report2=255 1-2x pro Woche nachts absetzen, bei mehreren FHTs eventuell tageweise versetzt:<br />
::<code>define fht_reportZimmer1 at *03:00:00 {if ($wday == 1) { fhem("set hzg_Zimmer1 report2 255")</code><br />
<br />
=== Funklage beobachten ===<br />
* RSSI mitloggen:<br />
:<code>attr CUL addvaltrigger 1</code><br />
* RSSI der FHTs beobachten. Unter -85 (also z.B. -89) ist ungünstig. Unbedingt versuchen, ein besseres RSSI als -85 hinzubekommen, zu ALLEN FHTs.<br />
* Antennnenlage des CUL/CUN korrigieren (z.B. Antenne um 45 Grad kippen), eventuell Lage des FHTs ändern, ein halber Meter kann schon viel bringen. Dabei kommt es nicht zwingend nur auf die absolute Entfernung zum Funkadapter an, auch die Lage im Gebäude kann viel ausmachen.<br />
* Wenn CUL / CUN eingesetzt werden, gegebenenfalls die Parameter freq, bandwidth und sens ändern. Als Startpunkt z.B. bandwidth auf 464 kHz und sens auf 8 dB anstelle 4 dB ändern. Kombinationen ausprobieren, aber nicht mehrere Parameter gleichzeitig ändern. RSSI-Auswirkung jeder Änderung beobachten.<br />
<br />
Wenn das keinen Erfolg bringt, zweiten CUL / CUNO einsetzen, z.B. auch als RFR CUL. Dabei [[RFR CUL und FHT80]] Besonderheiten berücksichtigen: Nicht zu viele FHTs ans RFR CUL anbinden, nur so viele wie gerade nötig. FS20 Repeater helfen nicht.<br />
<br />
=== Einstellungen prüfen ===<br />
<br />
* Attribut fhtsoftbuffer ausschalten. Beim Einsatz von CUL/CUNO ist die Verwendung von fhtsoftbuffer sowieso überflüssig, da die eigenen FHT Buffer dieser Adapter hinreichend groß sind. Gedacht ist dieses Attribut vor allem für den Einsatz von FHEM mit FHZ1x00PC Zentralen, deren FHT Buffer klein ist und zum Teil nur 8 Befehle halten kann. Das CUL V3 kann demgegenüber 40 FHT Befehle im Buffer halten. D.h. bei einer FHZ1x00PC kann es vorkommen, dass bei 10 zu steuernden FHTs schon ein Kommando der Art "Alle FHTs auf 20 Grad" *nicht* bei allen FHTs ankommt, da nicht alle Befehle zugleich in den Buffer passen. In solchen Fällen ist der Einsatz des Softbuffers hilfreich. (in neueren FHEM Versionen hat das Attribut fhtsoftbuffer daher auf CUL und CUNOs keine Wirkung mehr)<br />
<br />
<ul>Das Attribut fhtsoftbuffer erzeugt einen "unendlich" großen Buffer, was sehr lange Warteschlangen zur Folge haben kann. Das macht die Diagnose sehr schwer und erzeugt seltsamste Effekte, wenn die Kommunikation mit den FHTs nicht einwandfrei ist. In jedem Fall aber "glaubt" FHEM sehr viel länger, dass alles in Ordnung sei, obwohl die Kommunikation gestört ist.<br />
<br />
Ganz generell: Wenn eine Installation ohne fhtsoftbuffer nicht zuverlässig läuft, sollte man der Versuchung widerstehen, das Problem durch einen größeren Buffer lösen zu wollen. Fhtsoftbuffer sollte nur eingesetzt werden, wenn eine FHZ1x00 verwendet wird, die Installation an sich gut läuft und nur gelegentlich EOB Meldungen kommen.<br />
</ul><br />
<br />
* Retrycount auf 1. Wenn fhtsoftbuffer aktiv ist, wird versucht, das Kommando Retrycount-Mal zu wiederholen, wenn es nicht innerhalb von 240 Sekunden abgesetzt werden kann. Das kann die Abarbeitungsgeschwindigkeit der Warteschlange zusätzlich senken, gleichzeitig den Funkzeitverbrauch erhöhen und dadurch Probleme eher noch verschärfen. Sinnvoll ist ein höherer Retrycount womöglich nur, wenn in kleineren Installationen ein FHT gerade am Rande des Funkbereiches liegt, ansonsten aber alles problemfrei abläuft. Ohne fhtsoftbuffer hat retrycount keine Wirkung, wenn retrycount nicht definiert wird, ist der Defaultwert 1.<br />
<br />
* Bei mehreren CUxx in der Installation (auch 1 x CUL und 1x RFR CUL) das Attribut IODev kontrollieren. Ist ein FHT mit einem CUxx gepairt, aber das IODev zeigt auf das andere, ist eine Kommunikation nicht möglich. Da aber Temperatur (und weitere Werte) trotzdem empfangen werden, fällt dies zunächst eventuell nicht sofort auf. Der FHTbuffer des "falschen" CUxx wird dann mit Befehlen an das FHT zugemüllt, die nie erfolgreich abgesetzt werden können. Ist der Buffer schließlich voll, können auch keine Kommandos an andere mit diesem CUxx gepairte FHTs mehr übermittelt werden, obwohl diese eigentlich nicht betroffen sind.<br />
* Bei mehreren CUxx UNBEDINGT sicherstellen, dass die FHT-ID unterschiedlich ist. Bei gleicher FHT-ID fühlen sich zwei "Zentralen" für die FHT Kommunikation verantwortlich, was immer im Chaos endet: beide Funkadapter antworten bei FHT Kommunikationen und stören sich so gegenseitig. Siehe auch [[Was ist der Hauscode?]].<br />
* Bei mehreren CUxx bitte auch die Erläuterungen zum [[Sendpool]] Attribut berücksichtigen, die Funktion von Sendpool wird oft missverstanden.<br />
<br />
=== Diagnosemöglichkeiten im Fehlerfall ===<br />
Eine Möglichkeit, sich dem Problem zu nähern ist, das Logfile mit verbose5 anzeigen zu lassen. Die Meldungen sind dann recht detailliert und lassen einige Rückschlüsse zu. Erfahrungsgemäß ist es jedoch besser, sich die Kommunikation mit einer Telnetsitzung anzusehen. Ein Nachteil des Logfiles liegt z.B. darin, dass eine Temperaturänderung als "ausgeführt" angezeigt wird, wenn sie erfolgreich an z.B. das CUL übermittelt wurde, auch wenn sie dort nur in einen schon übervollen Buffer geschrieben wird. In einer Telnetsitzung kann man hingegen den Zustand des Buffers prüfen und die Kommunikation mit dem FHT beobachten.<br />
<br />
Dazu:<br />
<br />
* Terminalprogramm starten<br />
* Dann mittels <code>telnet (IP des FHEM Servers) 7072 &lt;entertaste&gt;</code> eine Telnetverbindung zu FHEM starten (7072 ist FHEMs Telnetport)<br />
* erneut &lt;entertaste&gt; drücken, nun muss als Prompt "fhem&gt;" erscheinen.<br />
<br />
Jetzt können zahlreiche Kommandos zur Diagnose abgegeben werden. <br />
<br />
* info timer &lt;entertaste&gt; zeigt einem alle Events, die FHEM empfängt und sendet. Hier kann man die Kommunikation live verfolgen und so z.B. sehen, ob noch Kommunikation mit dem FHT versucht wird. Einfach eine Weile mitlaufen lassen und sich ansehen, was alles passiert.<br />
* Wenn man einen CUxx im Einsatz hat, dann kann man sich mittels "set CUL raw X61" ("CUL" durch Namen der eigenen Schnittstelle wie in fhemconfig definiert ersetzen) auch Details der Kommunikation anzeigen lassen. So kann man vergleichen, ob die Kommunikation mit dem Beispiel [[FHT80b#Log-Auszug]] übereinstimmt, also planmäßig abläuft. "set CUL raw X21" setzt das CUL wieder auf den Standard-Loglevel zurück. Achtung, Groß- und Kleinschreibung beachten: Das X61/X21 hat ein großes X. <br />
* Auch sollte man prüfen, ob der CUxx so konfiguriert ist, wie man glaubt. Mit "get CUL ccconf" kann man die wichtigsten Werte ansehen.<br />
* Ist der FHT Buffer leer oder was hat sich da ggf. aufgestaut? "'''get CUL raw T02'''" ergibt den Inhalt des Buffers. Da sollte möglichst nichts drin stehen ("CUL raw =&gt; N/A") oder nicht viel. Mit der Zeit erkennt man die Codes gleich, daraus ergibt sich, welches FHT Probleme macht (Adresse) und welche Kommandos noch auf Aussendung warten. Folgender Beispieloutput: "CUL raw =&gt; 060D:4118 060D:65FF 060D:66FF 060D:4120" ist bereits verdächtig. FHT 060D hat noch 4 Kommandos in der Warteschlange, die Abarbeitung hier dauert schon im besten Fall mindestens noch 8 Minuten. Sieht bereits nach "Rückstau" aus. (4118 = desired temp auf Wert 18, 65ff= report1=255 66ff= report2=255).<br />
* Mehrfaches Eingeben von "get CUL raw T02" im Abstand von ca. 2 Minuten (dem Intervall, in dem Kommunikation mit dem FHTs stattfinden kann) zeigt einem, ob die Schlange sich abarbeitet oder welche Kommandos klemmen.<br />
* Wenn man CUxx im Einsatz hat kann man auch die freie Sendezeit prüfen: "get CUL raw X" Der zweite Zahlenwert ist die Sendezeit in 10ms Slots. Während ein FS20 Schalter im Idealfall mit 21 Einheiten (=210 ms) erledigt werden kann, braucht schon die simpelste Übertragung nur eines Wertes an ein FHT ca. 3x mehr Zeiteinheiten. Wenn also nicht mindestens 65 Zeiteinheiten frei sind, kann keine FHT Übertragung erfolgreich sein.<br />
* CUxx Funkadapter können auch resettet werden: "set CUL raw B00" resettet das CUL, und löscht dabei alle Buffer und setzt die freie Funkzeit auf Maximum. Die Wirkung ist die selbe wie den Adapter kurz stromlos zu machen. Will man hingegen nur den FHT Buffer leeren, kann man auch "'''set CUL raw T01xxxx'''" eingeben, wobei xxxx = FHT-ID ist, die aus fhem.cfg aus der CUL-Definition gelesen werden kann. Diese muss natürlich mit der vorherigen übereinstimmen, da sonst alle FHT-Pairings ungültig sind. Nach dem Löschen des Buffers noch kurz mit "get CUL raw T02" überprüfen, dass der Buffer auch wirklich leer ist. Anschließend irgendeinen Befehl an den FHT senden, z.B. Ändern der desired-temp um 1 Grad. Erfolg beobachten. Daran denken, dass es schon im Idealfall mehr als 2 Minuten dauern kann, bis die Änderung gesendet wird.<br />
<br />
=== Repairen ===<br />
Lassen sich durch die obigen Maßnahmen keine naheliegenden Probleme entdecken, hilft gelegentlich auch ein<br />
simples neu Pairen eines nicht kommunizierenden FHTs.<br />
<br />
Wiederkehrende Actuator-Meldung "'''unknown_69'''" lassen sich z.B. meist mit einem neuen Pairing lösen.<br />
<br />
'''Wichtig: vor dem Repairen FHT Buffer des zuständigen CULs löschen, z.B. durch kurz stromlos machen oder den Befehl "set CUL raw T01 <CUL-ID>" senden.''' Damit werden ggf. für dieses FHT bereits aufgestaute Kommandos entfernt.<br />
<br />
Zum neuen Pairen wie folgt vorgehen:<br />
*FHT80b in Sonderfunktionen "cENT" auf "n/a" stellen, Sonderfunktionen am FHT80 verlassen, danach sofort in FHEM einen Befehl (egal welchen) an die FHT80b senden. <br />
*Wenn ca. zwei Minuten später Sonderfunktion cENT auf "ON" steht und/oder der Befehl ausgeführt wurde, war das Pairing erfolgreich.<br />
<br />
Machmal hilft es, das FHT zusätzlich vorher stromlos zu machen: Batterien raus, 2 Minuten warten (wichtig), Batterien wieder einsetzen.<br />
<br />
=== provisorische Linderung ===<br />
Als schnelle Notlösung kann es auch helfen, den FHT Buffer der Funkschnittstelle regelmäßig zu leeren. Beim CUL lässt sich das durch den Befehl "'''set CUL raw T01 <CUL-ID>'''" (löscht nur den FHT Buffer) oder "'''set CUL raw B00'''" (resettet das CUL komplett, auch Funkkontingent wird neu gestartet) bewerkstelligen, den man z.B. jede Nacht absetzen kann. Dies hilft nicht bei FHTs mit denen es Kommunikationsprobleme gibt, lindert aber die daraus resultierenden Probleme anderer FHTs oder gar die Kommunikation mit anderen Protokollen wie FS20, falls aufgestaute Befehlswarteschlangen das Funkkontingent verbrauchen. Grundsätzlich verdeckt diese Notlösung das Problem aber nur und kann eine echte Analyse und Lösung nicht ersetzen.<br />
<br />
== Hardware defekt? ==<br />
Es gibt auch defekte FHT80b, aber oft hilft eine geringe Aufweitung der Bandbreite (siehe oben) oder schlicht ein neuer Satz Batterien. Manchmal führt auch ein "matchen" der FHTs mit der Funklage zum Ziel: Rausfinden, welche FHTs am problemlosesten arbeiten und diese an den Stellen unterbringen, die funktechnisch die ungünstigsten sind, während weniger zuverlässige FHTs näher an der Zentrale eingesetzt werden. Aufgrund der recht primitiven Sender/Empfänger (Pendelempfänger) der FHTs sind hier durchaus deutliche Streuungen möglich.<br />
Mitunter können Probleme auch gelöst werden, indem das FHT stromlos gemacht wird: Batterien raus, 2 Minuten warten (wichtig), Batterien wieder einsetzen.<br />
<br />
== Weiterführende Artikel ==<br />
* [[Was ist der Hauscode?]]<br />
* [[1% Regel]]<br />
* [[Maximal nutzbare Geräte]]<br />
<br />
[[Kategorie:FHT Components]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=LOVF&diff=29546LOVF2019-02-17T19:12:45Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>LOVF = Limit Overflow meldet, dass die [[1% Regel]] überschritten ist.<br />
<br />
Praktisch umgesetzt ist das 1% Sendelimit z.b. im [[CUL]] so, das pro Sekunde 10ms Sendezeit "gutgeschrieben" wird. Die Anzahl der noch zur Verfügung stehenden 10ms Sendeeinheiten kann mittels "get cul raw X" abgefragt werden (zweite Zahl = Anzahl noch verfügbarer Einheiten), eine Aussendung, die wegen erreichter maximaler Frequenzbelegungsdauer nicht gesendet werden kann quittiert das CUL mit der Meldung LOVF (= limit-overflow). Eine FS20 Übertragung benötigt ca. 220ms also ca. 22 Sendeeinheiten. Ist die maximale Frequenzbelegungsdauer erreicht, dauert es also mindestens 22 Sekunden, bis erstmals wieder gesendet werden kann. <br />
<br />
Daraus ergibt sich, das maximal 163 FS20 Kommandos pro Stunde gesendet werden können. Wird dieser Wert überschritten, meldet FHEM zusätzlich zu LOVF '''CUL TRANSMIT LIMIT EXCEEDED'''. Eine weitere Schaltung von FS20 Komponenten ist dann nicht mehr möglich. Daher ist es z.B. ungünstig, blinkende Lampen oder ähnliches per Schaltbefehl zu realisieren. Eine mit 1 Hz blinkende Lampe hat das gesamte FS20 Funkkontingent einer Stunde nach weniger als 3 Minuten Blinken aufgebraucht (und dies auch nur, weil mit FS20 der "on-for-timer 1" Befehl verwendet werden kann). <br />
Gefährlich sind auch Bewegungsmelder mit kurzen Meldeintervallen aber regelmässiger Auslösung. Der [[FS20 PIRA Infrarot-Bewegungsmelder|FS20 PIRI oder PIRA]] gestattet z.b. als kürzesten Sendeabstand 8 Sekunden. Kommt es in einem Raum (in dem sich ständig Personen aufhalten und bewegen) tatsächlich zu einer Auslösung alle 8 Sekunden, ist das Sendekontingent des PIRA/PIRI nach 22 Minuten aufgebraucht und danach wird der Bewegungsmelder nicht mehr senden. Schlimmer noch: Wird in FHEM durch jede dieser Bewegungen eine Aktion ausgelöst, die FHEM dazu veranlasst, einen oder gar mehrere Sendebefehle abzusetzen, so kann die Funkschnittstelle von FHEM (z.b. eine CUL) ebenso schnell oder gar schneller ihr Sendelimit erreichen.<br />
Daher sollte bei Bewegungsmeldern immer ein möglichst langer Sendeabstand eingestellt werden.<br />
<br />
Auch [[FHT80b]]s bzw. alle im SlowRF Modus ansprechbaren Geräte belasten das Sendelimit.<br />
<br />
Insbesondere die alle 15 Minuten stattfindende bidirektionale Kommunikation mit [[FHT80b]]s sorgt dafür, dass die Anzahl [[Maximal nutzbare Geräte]] relativ eingeschränkt ist.<br />
<br />
Weiterführende Informationen über den Problembereich sind im Artikel [[Kommunikationsprobleme mit FHT]] zusammengestellt.<br />
<br />
Wegen der höheren Datenrate und der daher deutlich kürzeren Sendedauer von Befehlen kommt es bei HomeMatic seltener zu Limit Overflows.<br />
<br />
[[Kategorie:Glossary]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=1%25_Regel&diff=295451% Regel2019-02-17T19:11:44Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>= 1% Relative Frequenzbelegungsdauer =<br />
Die Bundesnetzagentur schreibt für die Nutzung verschiedener ansonsten frei nutzbarer Frequenzbereiche sogenannte maximale relative Frequenzbelegungsdauern fest. Sinn dieser Maßnahme ist es, die Nutzung der Frequenzbänder durch mehrere Nutzer auch bei Reichweitenüberlagerung zu ermöglichen. Für 868,35&#160;MHz, also der Frequenz, in dem z.B. das HM, FS20 und FHT System arbeiten, sind ≤ 1% vorgeschrieben. Dies ergibt 36 Sekunden Sendedauer je Stunde. Besonders bei der eher langsamen Datenübertragung der FHT und FS20 Protokolle kann es zu Engpässen kommen.<br />
<br />
== Details ==<br />
Um einen Kommunikationskanal durch mehrere Teilnehmer effektiv zu nutzen, bieten sich mehrere Verfahren an. Im Wesentlichen sind dies:<br />
<br />
* Token-Verfahren. Senden darf nur, wer gerade ein von Teilnehmer zu Teilnehmer herumgereichtes "Pfand" (=Token) besitzt. Tokenverfahren sind aufwändig zu implementieren und erfordern bidirektionale Kommunikation.<br />
* LBT-Verfahren. Senden darf ein Teilnehmer nur, wenn er sich vorher durch "Lauschen" vergewissert hat, dass sonst niemand sendet, der Kanal also frei ist. (LBT = Listen before talk). Es ist theoretisch jedoch denkbar, dass zwei Sender zugleich lauschen, den Kanal frei vorfinden und zugleich anfangen zu senden. LBT Verfahren sind in frei nutzbaren Kanälen mit vielen Teilnehmern schwierig zu implementieren. (Die Kommunikation zwischen [[CUL]]/CUNO und [[RFR CUL]] arbeitet aber z.B. nach diesem Verfahren.)<br />
* Zeitbeschränkung. Jeder Teilnehmer darf nur sehr kurz senden. Die Sendedauer ist so zu wählen, dass jeder Teilnehmer eine signifikante Chance hat, zufällig auf einen freien Kanal zu treffen. Dies ist beispielsweise gegeben, wenn der Kanal zu 90 oder mehr Prozent frei ist.<br />
<br />
Bei LBT und Zeitbeschränkung sind außerdem Verfahren zu implementieren, die greifen wenn der Kanal nicht frei war, die Aussendung also durch Überlagerung einer anderen Sendung gestört wurde. In der Regel wird man den erfolglosen Sendeversuch nach einer zufälligen Zeit wiederholen.<br />
<br />
Die Verfahren sind in der obigen Reihenfolge weniger aufwändig zu implementieren, d.h. Zeitbeschränkung erfordert den geringsten Aufwand.<br />
<br />
Die Bundesnetzagentur schreibt vor, dass im Frequenzbereich von 868,000 bis 868,600&#160;MHz 1% "Duty cycle" ODER die Nutzung von LBT-Verfahren implementiert sind, wobei sie definiert:<br />
<br />
<dl><dd>''Die relative Frequenzbelegungsdauer (duty cycle) in&#160;% kennzeichnet die Dauer der Aussendungen eines Senders auf einer Frequenz bezogen auf 1 Stunde. Die Gesamtsendezeit kann auf mehrere Intervalle aufgeteilt werden.''</dd></dl><br />
und<br />
<br />
<dl><dd>''LBT: Verfahren, mit dem die Kanalbelegungssituation vor Beginn und während der Aussendung geprüft wird. Aussendung erfolgt nur bei freiem Kanal.''</dd></dl><br />
Zumindest wegen des geringen Implementierungsaufwandes hat ELV als Entwickler der FS20 / FHT / HomeMatic Funkkomponenten kein LBT verwendet, sondern beachtet vielmehr die maximale Frequenzbelegungsdauer.<br />
<br />
== Bedeutung für das FS20 / FHT Funksystem ==<br />
Aus der relativen Frequenzbelegungsdauer von 1% je Stunde, also nur 36 Sekunden je Stunde, ergeben sich für das FS20 / FHT System deutliche Einschränkungen. Insbesondere ist die [[Maximal nutzbare Geräte]] stark eingeschränkt. Wegen der umfangreichen bidirektionalen Kommunikation zwischen Raumreglern und der Zentrale mit einer im Vergleich zu HomeMatic eher geringen Bandbreite lassen sich beispielsweise sinnvoll nur etwa 10-12 Räume mit FHT über Funk steuern. <br />
<br />
Problematisch kann die 1% Regel auch in Debuggingphasen sein, wenn also neue FHEM Konfigurationen mehrfach in kurzer Folge ausprobiert werden.<br />
<br />
Praktisch umgesetzt ist das 1% Sendelimit z.B. im [[LOVF]] (= Limit-overflow). Eine FS20 Übertragung benötigt mindestens ca. 220ms also ca. 22 Sendeeinheiten. Ist die maximale Frequenzbelegungsdauer erreicht, dauert es also mindestens 22 Sekunden, bis erstmals wieder gesendet werden kann. <br />
<br />
Daraus ergibt sich, dass maximal 163 FS20 Kommandos pro Stunde gesendet werden können. Wird dieser Wert überschritten, meldet FHEM '''CUL TRANSMIT LIMIT EXCEEDED'''. Eine weitere Schaltung von FS20 Komponenten ist dann nicht mehr möglich. Dies ist insbesondere auch beim Einsatz von [[FS20_PIRA_Infrarot-Bewegungsmelder|Bewegungsmeldern]] von Bedeutung, wenn deren Sendeabstand sehr kurz eingestellt ist.<br />
<br />
== Bedeutung für das HomeMatic Funksystem ==<br />
HomeMatic verwendet eine höhere Datenübertragungsrate, sodass die Kommunikation wesentlich schneller abläuft und die Grenzen wesentlich weiter sind. Dennoch kann es auch bei HomeMatic vorkommen, dass die Grenzen erreicht werden.<br />
<br />
Überschlägig kann HM etwa 1600 Nachrichten Je Stunde senden. Dazu zählen auch ACKs.<br />
Ein Burst kostet 16 Messages. Es können also nur ca. 100 Bursts je Stunde gesendet werden. <br />
Das gilt jeweils für das Aufwecken eines Device, die folgenden Messages sind "billiger".<br />
<br />
Zu beachten ist allerdings, dass z.B. der [[HMLAN Konfigurator]] Sendungen 3mal wiederholt, wenn keine Antwort kommt. Sendet man also ein Burst an ein Device, das nicht aktiv ist, ist das Sendekontingent nach nur 30 Versuchen je Stunde verbraucht.<br />
<br />
Es gibt aber noch andere Prozesse die viel Funklast erzeugen.<br />
<br />
*Insbesondere ist bei FHEM Versionen ab Oktober 2013 das Attribut ''autoReadReg'' auf "4_reqStatus" gesetzt. Damit wird für jedes HM-Device mit diesem so gesetzten Attribut beim FHEM-Start ein ''getConfig'' durchgeführt, was viel Funkverkehr erfordert.<br />
<br />
Je nach Anzahl der Geräte kann dies dazu führen, dass insgesamt zu viel Funklast erzeugt wird, im Logfile erscheint dann eine Meldung wie:<br />
<br />
2013.10.03 13:41:18 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload<br />
<br />
Ab diesem Moment werden eben auch keine anderen Befehle mehr an weitere HM-Geräte geschickt, da das Funkkontingent aufgebraucht ist. Erst nach einer Stunde kann erneut gesendet werden. <br />
<br />
''autoReadReg'' auf "4_reqStatus" kann also dazu führen, dass nach einem Neustart HM sofort sein Funkkontingent aufgebracht hat.<br />
<br />
Als '''Notbehelf''' kann die Funkschnittstelle resetted oder ([[HMLAN Konfigurator]]) kurz stromlos gemacht werden. Dann wird der Zähler wieder auf Null gesetzt.<br />
Alternativ können so viele HM-Geräte wie möglich auf ''autoReadReg 0_off'' gesetzt werden.<br />
<br />
* Ausserdem ist zu berücksichtigen, dass sich bei Einschaltung des [[AES Encryption|Signing Requests]] der Funkverkehr in etwa verdoppelt, was bei großen Installationen schon im Normalbetrieb zum Erreichen der Grenze führen könnte.<br />
<br />
== Links ==<br />
* [[Maximal nutzbare SlowRF Geräte]]<br />
<br />
* Bundesnetzagentur [http://www.bundesnetzagentur.de/cae/servlet/contentblob/134184/publicationFile/2570/FundstelleId5772pdf.pdf] Vfg. 20 / 2006<br />
[http://www.bundesnetzagentur.de/cae/servlet/contentblob/38206/publicationFile/2580/ShortRangeDevicesSRD_ID17299pdf.pdf] Vfg 30 / 2006, geändert mit Vfg. 39/2009<br />
<br />
[[Kategorie:Glossary]]<br />
[[Kategorie:FHT Components]]<br />
[[Kategorie:HomeMatic Components|2Info]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat&diff=29544HM-CC-RT-DN Funk-Heizkörperthermostat2019-02-17T19:09:56Z<p>AndreasMohr: Typos/Spelling</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HM-CC-RT-DN.jpg<br />
|Bildbeschreibung=HM-CC-RT-DN an Heizkörper montiert<br />
|HWProtocol=[[HomeMatic]]<br />
|HWType=[[HomeMatic Type Thermostat|thermostat]]<br />
|HWCategory=[[:Kategorie:Heizungsventile|Heizungsventile]]<br />
|HWComm=868 MHz<br />
|HWChannels=6<br />
|HWVoltage=3&nbsp;V<br />
|HWPowerConsumption=180&nbsp;mA<br />
|HWPoweredBy=2x LR6/Mignon/AA<br />
|HWSize=54x65x93 mm (BxHxT)<br />
|HWDeviceFHEM=[[CUL_HM]]<br />
<!-- |ModOwner= --><br />
|HWManufacturer=ELV / eQ-3<br />
}}<br />
<br />
'''HM-CC-RT-DN''' (häufig einfach '''RT''' genannt) ist ein Funk-''Heizkörperthermostate'' mit integriertem ''Stellantrieb''. Das Thermostat ist seit September&nbsp;2013 verfügbar und ist der Nachfolger des [[HM-CC-VD Funk-Stellantrieb]]s.<br />
<br />
== Vorbemerkungen ==<br />
: ''→ Einstellungen und Informationen, die alle [[HomeMatic]] Thermostate betreffen, sind unter [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]] zu finden.''<br />
<br />
Der HM-CC-RT-DN kann die Temperatur selbst messen (im Gegensatz zum [[HM-CC-VD Funk-Stellantrieb|Vorgänger]]) und verfügt über eine Fenster-Offen-Erkennung sowie eine Boost-Funktion. Der HM-CC-RT-DN ''kann'' von einem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] gesteuert werden, das ist aber ''optional''.<br />
<br />
Das Gerät wird seit Anfang Oktober 2013 von FHEM unterstützt (siehe Diskussion im {{Link2Forum|Topic=14738|LinkText=Forum}}).<br />
<br />
Der HM-CC-RT-DN scheint das erste HomeMatic-Device zu sein, bei dem ein Update der Firmware auch vom Anwender durchgeführt werden kann. Ein Firmware-Update erfordert einen [[HM-CFG-USB_USB_Konfigurations-Adapter|USB Konfigurations-Adapter]] und eine auf der eQ-3 Webseite herunterladbare Firmwareupdate-Software. Weitere Details sind unter [[#Firmware Update|Firmware Update]] beschrieben.<br />
{{Hinweis|Die Solltemperaturen eines HM-CC-RT-DN lassen sich ''nicht'' durch einen [[HM-CC-TC Funk-Wandthermostat]] ''steuern''. Dieser kann nur die Ist-Temperatur an den HM-CC-RT-DN weitergeben, damit nicht die am HM-CC-RT-DN direkt gemessene Raumtemperatur zur Regelung verwendet wird.}}<br />
Mit einem HM-CC-RT-DN können maximal (neben der Zentrale/FHEM):<br />
* 7 HomeMatic Heizkörperthermostate<br />
* 8 HomeMatic Tür-Fensterkontakte / Fenster-Drehgriffkontakte<br />
* 8 Tastenpaare von HomeMatic Fernbedienungen bzw. Display-Wandtaster<br />
* 1 HomeMatic Innen-Temperatur-Sensor<br />
[[Peering (HomeMatic)|gepeert]] werden.<br />
<br />
{{Hinweis|Wird für Wartungs-/Umbaumaßnahmen das Wasser der Heizung abgelassen bzw. diese neubefüllt, sind alle Stellantriebe manuell dauerhaft auf '''on''' zu setzen: set <HM_Stellantrieb>_Clima controlManu on. Beim Einsatz eines Wandthermostaten ist der Wandthermostat entsprechend einzustellen.}}<br />
<br />
== Technische Daten ==<br />
* Betriebsspannung: 2 Stck. 1,5V LR6/Mignon/AA<br />
* Stromaufnahme: 180 mA max.<br />
* Abmessungen (B x H x T): 54 x 65 x 93 mm<br />
* Gewicht: 180 g (ohne Batterien)<br />
* Ventilanschluss: M30 x 1,5 mm<br />
<br />
Aktuelle Firmware: 1.4 (2018)<br />
<br />
== Betrieb mit FHEM ==<br />
Der Funk-Heizkörperthermostat muss zuerst mit FHEM [[Pairing (HomeMatic)|gepairt]] werden. Stellen Sie sicher, dass FHEM aktuell ist ([[update]] durchführen)<br />
<br />
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden <br />
<br />
=== Channels (Kanäle) ===<br />
==== Channel (Kanal) 01 _Weather ====<br />
<br />
Dieser Kanal dient zur Einspeisung der (gemessenen) ''Ist-Temperatur''. Als Sensor können zum Beispiel das [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] oder ein [[HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor innen (IT)|HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor]] dienen.<br />
<br />
Ein Temperatur-Sensor ''tempSensor'' kann mit dem ''_Weather''-Kanal wie folgt [[Peering (HomeMatic)|gepeert]] werden: <br />
<br />
set <HM-TC-IT-WM-W-EU>_Weather peerChan 0 <HM-CC-RT-DN>_Weather single set<br />
<br />
Beispiel:<br />
set EG_Buero_WANDTHERMOSTAT_Weather peerChan 0 EG_Buero_THERMOSTAT_Weather single set<br />
<br />
ACHTUNG: Das Wandthermostat sowie das Thermostat Ventil (Beispiel "EG_Buero_WANDTHERMOSTAT" und EG_Buero_THERMOSTAT) werden vorher in FHEM den Status "CMDs_done" anzeigen.<br />
Beim peerChan wird dann bei beiden "CMDs_pending" stehen. Wobei das Wandthermostat sehr schnell wieder auf CMDs_done zurück springt.<br />
Allerdings ist dringend darauf zu achten, dass das Thermostat Ventil auch wieder auf "CMDs_done" wechselt, bevor man den nächsten Befehl absendet.<br />
Das Heizkörper Ventil kann unter Umständen 3 bis 5 min benötigen bis wieder "CMDs_done" steht. Evtl. kann man dies durch die BOOST Taste beschleunigen. Da das Ventil etwa alle 3 min aufwacht, prüft und Daten sendet / empfängt. Sollte man mit dem Befehlen weiter gemacht haben, so kann es zu dem Problem führen, dass einer nicht mehr mit dem Pending aufhört. In dem Fall empfiehlt es sich beide Devices von FHEM abzumelden und auf Werkseinstellung zu resetten. <br />
<br />
Zum Test haucht man das Wandthermostat an oder hält es einige Zeit in der Hand bis die Temperatur steigt, nach etwa 3 Minuten sollte man auch am Thermostat Ventil einen Temperaturanstieg sehen.<br />
<br />
==== Channel (Kanal) 02 _Climate ====<br />
Dieser Kanal erlaubt es dem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] den HM-CC-RT-DN zu steuern. Dazu müssen die beiden Geräte gepeert werden:<br />
<br />
set <HM-TC-IT-WM-W-EU>_Climate peerChan 0 <HM-CC-RT-DN>_Climate single set<br />
<br />
==== Channel (Kanal) 03 _WindowRec ====<br />
Mit diesem Kanal können Fensterkontakte ([[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] und [[HM-Sec-RHS Funk-Fenster-Drehgriffkontakt|HM-SEC-RHS]]) ihren Fensterstatus (geöffnet / gekippt) an ein oder mehrere Thermostate senden. Die Thermostate stellen anschließend die entsprechende (konfigurierbare) Temperatur ein. Der Temperaturwert kann je Fenster-Sensor unterschiedlich definiert werden. Sind mehrere Fenster gleichzeitig geöffnet, so wird der Thermostat auf die Temperatur des Sensors mit dem geringsten Temperaturwert eingestellt. <br />
Ferner wird empfohlen, bei Einsatz von externen Sensoren, die interne „Fenster auf Erkennung“ zu deaktivieren (weitere Details sind im [[HM-CC-RT-DN Funk-Heizkörperthermostat#Channel .28Kanal.29 04 _Clima|Channel (Kanal) 04 _Clima]] beschrieben).<br />
<br />
Der Befehl zum Peeren lautet, wobei <fensterSensor> die FHEM-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:<br />
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single set<br />
<br />
Zum Löschen (=unpeeren) dieser Kopplung:<br />
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single unset<br />
<br />
'''Achtung''': Der Peer-(Lösch-)Vorgang muss erst am Fensterkontakt durch Drücken der Anlerntaste ausgelöst werden, und zwar auch dann, wenn der Fensterkontakt schon vorher mit FHEM gepairt wurde. Dann kann der oben genannte Befehl in FHEM abgesetzt werden. Wichtig scheint auch, dass der Fensterkontakt geschlossen ist wenn man die Anlerntaste drückt.<br />
<br />
Der Befehl zur Temperatureinstellung des Heizkörperthermostaten für den Zustand "Fenster offen" lautet, wobei <fensterSensor> die FHEM-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates, sowie <Temp> die einzustellende Temperatur (ganzzahliger Wert):<br />
set <HM-CC-RT-DN>_WindowRec regSet winOpnTemp <Temp> <fensterSensor><br />
<br />
Weitere Hinweise im Forum, siehe [https://forum.fhem.de/index.php/topic,41541.msg348044.html#msg348044 FHEM Forum]<br />
<br />
==== Channel (Kanal) 04 _Clima ====<br />
Dieser Kanal dient zum Einstellen der Betriebsparameter, auch [[#Temperaturlisten|Temperaturlisten]] sind hierauf zu übertragen.<br />
Mit dem Modul [[Weekprofile|Wochenplan / Weekprofile]] können die Wochenpläne komfortabel in FHEM erstellt und an die Thermostate übertragen werden.<br />
<br />
{{Hinweis|In älteren Versionen von FHEM wurde dieser Kanal durch ''autocreate'' als <code>_ClimRT_tr</code> angelegt. Der Hersteller hat hier offenbar die internen Bezeichnungen geändert, denn beim Vorläufermodell HM-CC-TC mussten Temperaturlisten auf den Kanal ''Climate'' übertragen werden.}}<br />
<br />
Die maximale Öffnung des Ventils kann mittels folgendem Befehl eingestellt werden (hier auf 80 %):<br />
set <HM-CC-RT-DN>_Clima regSet valveMaxPos 80<br />
<br />
Die interne "Fenster-auf"-Erkennung kann man wie folgt abschalten:<br />
set <HM-CC-RT-DN>_Clima regSet winOpnMode off<br />
<br />
==== Channel (Kanal) 05 _ClimaTeam ====<br />
Dieser Kanal erlaubt es mehrere HM-CC-RT-DN zu einem "Team" zu gruppieren. Ein Mitglied des Teams meldet<br />
* Änderungen der Temperatur am Handrad<br />
* Einschalten des Boost-Modus am Taster<br />
an seine "Teamkollegen" weiter. Folgende Änderungen werden '''nicht''' weitergegeben:<br />
* Status der Fensterkontakte<br />
* Temperaturlisten/Wochenplan und daraus folgende Änderungen<br />
* Änderungen durch Fernbedienungen<br />
* Änderungen durch eine HomeMatic-Zentrale<br />
<br />
Befehl zum Peeren, wobei ''<HM-CC-RT-DN#1>_ClimaTeam'', ''<HM-CC-RT-DN#2>_ClimaTeam'', ..., ''<HM-CC-RT-DN#8>_ClimaTeam'' die Kanalbezeichnungen der jeweiligen ClimaTeam-Kanäle sind:<br />
set <HM-CC-RT-DN#1>_ClimaTeam peerChan 0 <HM-CC-RT-DN#2>_ClimaTeam single<br />
set <HM-CC-RT-DN#1>_ClimaTeam peerChan 0 <HM-CC-RT-DN#3>_ClimaTeam single<br />
set <HM-CC-RT-DN#2>_ClimaTeam peerChan 0 <HM-CC-RT-DN#3>_ClimaTeam single<br />
...<br />
<br />
==== Channel (Kanal) 06 _remote ====<br />
Dieser Kanal kann an eine Fernbedienung gekoppelt werden. Per Tastendruck kann man einen bestimmten Mode und/oder eine bestimmte Temperatur wählen. Dabei kann die Reaktion auf einen langen oder kurzen Tastendruck gesondert eingestellt werden.<br />
<br />
Der Befehl zum Peeren lautet, wobei <button> die Kanalbezeichnung der Fernbedienung und <rt-remote> die Kanalbezeichnung des Heizkörperthermostates ist:<br />
set <button> peerChan 0 <HM-CC-RT-DN>_remote single<br />
<br />
=== Betriebsmodus Auto, Manu, Party (Urlaub) ===<br />
<br />
Der HM-CC-RT-DN verfügt über drei Betriebsmodus: Auto, Manu (Manuell) und Party (Urlaub). <br />
<br />
==== Modus Auto ====<br />
Das Gerät arbeitet gemäß des gespeicherten Wochenprogramms. Manuelle Änderungen sind möglich, werden aber beim nächsten Schaltpunkt überschrieben.<br />
<br />
==== Modus Manu ====<br />
Die Temperatur wird manuell eingestellt, das Wochenprogramm wird nicht abgearbeitet. "Manuell Einstellen" bedeutet entweder am Handrad oder durch Übermittlung eines "set desired temp"-Befehls von FHEM (oder equivalent von einer CCU).<br />
<br />
==== Modus Party (Urlaub) ====<br />
Die eingestellte Temperatur gilt bis zu einem gegebenen Endzeitpunkt, anschließend wechselt das Thermostat in den ''Auto''-Modus. <br />
<br />
==== Welchen Modus nutzen? ====<br />
Im Umfeld von FHEM sind alle drei Modi einsetzbar. Betrieb in "Auto" hat den Vorteil, dass bei Ausfall der FHEM-Instanz der Thermostat trotzdem noch die eingespeicherten Wochenprogramme abarbeitet. Nachteilig ist aber, dass die Steuerung komplexer wird, weil sowohl die Einstellungen am Thermostat als auch Schaltbefehle von FHEM das Verhalten beeinflussen. Vielfach wird daher im Umfeld von FHEM der Modus "Manu" benutzt, hier wird die Temperatur nur per einzelnem FHEM Schaltbefehl gesteuert, ausgelöst z.b. durch "at" Kommandos, Anwesenheitserkennung oder Bewegungsmelder. Sollte FHEM (oder die Funkverbindung) ausfallen, bleibt der Thermostat allerdings auf der letzten eingestellten Temperatur stehen.<br />
<br />
Denkbar ist auch, den Modus "Auto" zu verwenden und dann die Steuerung per FHEM dadurch durchzuführen, dass durch FHEM die Wochenprogramme verändert werden. Dies verbindet zwar die Vorteil der vorgenannten Methoden, ist aber am Aufwendigsten in der Programmierung und erzeugt die höchste Funklast.<br />
<br />
Auch der Urlaubsmodus ist einsetzbar, so kann beispielsweise bei Abwesenheit ein niedrigeres Temperaturprofil eingestellt werden, ohne dass eventuell vorhandene Temperaturlisten verändert werden müssen.<br />
<br />
set <HM-CC-RT-DN>_Clima controlParty 16 06.12.13 16:30 09.12.13 05:00<br />
<br />
Dadurch wird <br />
* von 06.12.2013, 16:30 Uhr<br />
* bis 09.12.2013, 05:00 Uhr <br />
* die gewünschte Raumtemperatur auf 16 °C eingestellt.<br />
<br />
{{Hinweis|<br />
* Der Befehl muss auf dem Kanal 4 ''(_Clima)'' erfolgen.<br />
* Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30).}}<br />
<br />
Mit der folgenden Funktion <code>Urlaub()</code> kann man eine ganze Wohnung (also mehrere RTs) mit nur einem Befehl in den Party-Modus versetzen. Im Beispiel werden zwei Heizkörper ("Treppenhaus" und "Kammer") angesteuert.<br />
<br />
Zu beachten sind folgende Dinge:<br />
# Aktuelle Dateien (z.B. <code>10_CUL_HM</code>) verwenden!<br />
# Bei dem ''controlParty''-Befehl ''kein'' Komma zwischen den Parametern.<br />
# Bei der Funktion die Parameterübergabe definieren <code>($$$$$)</code><br />
<br />
'''Aufruf:'''<br />
:<code>{Urlaub ("16", "06.12.13", "16:30", "09.12.13" ,"05:00")}</code><br />
<br />
'''Funktion:'''<br />
<syntaxhighlight lang=perl><br />
my $Urlaub;<br />
sub<br />
Urlaub($$$$$)<br />
{<br />
my ($temp, $startDate, $startTime, $endDate, $endTime) = @_;<br />
<br />
# HM-CC-RT-DN akzeptiert nur Zeiten, die auf Minute 00 oder 30 enden.<br />
# Daher $startTime und $endTime abrunden<br />
$startTime =~ s/\:[0-2].$/:00/;<br />
$startTime =~ s/\:[3-5].$/:30/;<br />
$endTime =~ s/\:[0-2].$/:00/;<br />
$endTime =~ s/\:[3-5].$/:30/;<br />
<br />
# controlParty bei jedem HM-CC-RT-DN setzen.<br />
for my $rt (qw(Kammer Treppenhaus)) {<br />
fhem ("set $rt controlParty $temp $startDate $startTime $endDate $endTime");<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Tastensperre ===<br />
<br />
Um zu verhindern, dass der Modus oder die Temperatur per Tasten bzw. Drehrad am HM-CC-RT-DN verändert wird, kann eine Tastensperre gesetzt werden. Dies erfolgt mittels des Befehls:<br />
<br />
set <HM-CC-RT-DN> regSet btnLock on<br />
<br />
Rückgängig machen geht per:<br />
<br />
set <HM-CC-RT-DN> regSet btnLock off<br />
<br />
Diese Tastensperre kann man aber am HM-CC-RT-DN durch eine Tastenkombination wieder zurücksetzen. Um sie nur per FHEM rücksetzen zu können, muss<br />
<br />
set <HM-CC-RT-DN> regSet globalBtnLock on<br />
<br />
eingegeben werden. Rückgängig geht wieder per:<br />
<br />
set <HM-CC-RT-DN> regSet globalBtnLock off<br />
<br />
Es gibt auch eine Tastensperre die nur das Umschalten des Modus (Auto, Manuell, Urlaub) am Gerät verhindert. Diese wird mit<br />
<br />
set <HM-CC-RT-DN> regSet modusBtnLock on<br />
<br />
eingeschaltet. Abschalten geht mit:<br />
<br />
set <HM-CC-RT-DN> regSet modusBtnLock off<br />
<br />
=== Burst-Modus ===<br />
Das ist ein '''Übertragungs'''modus für Nachrichten zwischen HM-Geräten und der Zentrale. Der RT erwacht alle 2,5 Minuten und dann überträgt die Zentrale die Kommandos. Wenn man einen Fensterkontakt oder eine Fernsteuerung nutzt, muss der RT sofort reagieren - dann muss man den Burst ''enablen''. Der RT kann in diesem Fall sofort aufgeweckt werden und bearbeitet die Anforderung (Request). Das kann man auch von der Zentrale aus nutzen (so man möchte). Das ist der '''Vorteil''' des eingeschalteten Burst-Modus.<br />
<br />
'''Nachteil:''' Der Burst-Modus benötigt mehr Leistung, das heißt die Batterien müssen häufiger gewechselt werden: Der RT muss den Receiver ständig empfangsbereit halten. Außerdem wachen bei jedem Burst ''alle'' Burst-Empfänger auf – egal an wen die Kommunikation gerichtet war.<br />
<br />
'''Burst – wie es funktioniert'''<br />
<br />
Schickt ein Sender eine burst Sequenz, wachen alle burst-Empfänger auf und prüfen die Message. <br />
Wenn sie betroffen sind bleiben sie eine Zeit lang wach, ansonsten schlafen sie wieder ein. <br />
Man beachte also, dass Senden eines Burst Energie in ALLEN burst-Empfängern verbraucht, egal ob sie angesprochen sind.<br />
<br />
'''HMLAN und burst'''<br />
<br />
[[HMLAN]] hat ein Sendebudget das über eine Stunde berechnet wird. Burst belastet dieses Konto deutlich - so können nicht mehr als 100 bursts /h gesendet werden - dann geht HMLAN in overload. Wenn zusätzliche Nachrichten gesendet werden sind es entsprechend weniger. <br />
Es ist nicht vorteilhaft, unnötig bursts zu senden.<br />
<br />
'''Burst devices'''<br />
<br />
Es gibt Devices, die immer auf burst reagieren und solche bei denen es abgeschaltet werden kann. So reagiert ein Rauchmelder immer auf Burst damit er seine Team-Kollegen hören kann. <br />
Ein TC oder RT hingegen hat diese Funktion abschaltbar. 'Per default ist dies ausgeschaltet um Batterie zu sparen'. Wenn ein VD gesteuert wird ist der TC ja selbst wach. Wird er aber mit einem Fensterkontakt gekoppelt muss es eingeschaltet werden – sonst verpasst er die Nachricht. <br />
<br />
'''ConditionalBurst devices'''<br />
<br />
Devices mit abschaltbarem Burst wie z.B. der ''HM-CC-RT-DN'' haben ein Register, ''burstRx'', mit dem das burst-Erwachen eingestellt werden kann. <br />
Sendern, die einen burst-Aktor erwecken sollen, muss man sagen, welcher Peer Burst benötigt. Hier kann ggf. das Register ''peerNeedsBurst'' nach dem Peeren gesetzt werden. FHEM versucht dies automatisch beim Peeren zu erledigen. Siehe [[HomeMatic HMInfo|HMinfo]] Befehl ''models'' um herauszufinden, welche Devices welchen Modus unterstützen.<br />
<br />
'''Attribut burstAccess''' <br />
<br />
Devices, die abschaltbaren burst haben kann man ein attribut burstAccess 1_auto setzen. Es wird beim Abschicken eines Kommandos versucht, das Device mit burst zu wecken. Sollte es nicht funktionieren wird gewartet, bis das Device aufwacht (meist reagieren solche Devices auch auf wakeup). Das Setzen des Attributs ist angenehm – es werden aber ggf. viele bursts gesendet.<br />
<br />
'''Kommando burstXmit'''<br />
<br />
Mit diesem Kommando, das bei Devices mit conditional-Burst zu Verfügung steht, wird der burst gezielt vom User angestoßen.<br />
<br />
Der User schickt erst seine Kommandos an das device. Die Kommandos werden im Command-stack gesammelt. <br />
<br />
Dann sendet der User ein set burstXmit.<br />
<br />
Es passiert das gleiche wie bei burstAccess.<br />
<br />
FHEM versucht mittels burst zu wecken und sendet bei Erfolg die Messages aus dem Kommandostack. <br />
<br />
Im Gegensatz zu burstAccess ist burstXmit gezielt einsetzbar und kann sparsamer verwendet werden.<br />
<br />
''' FHEM und burst devices'''<br />
<br />
FHEM sendet eine burst automatisch mit Kommandos zu Devices, die nur burst unterstützen.<br />
<br />
'''So aktiviert man den burst-Betrieb am HM-CC-RT-DN'''<br />
<br />
''Burst Mode einschalten'' (der Kanal 4 des Device WZ1 heisst hier WZ1_4)<br />
:<code>set WZ1_4 regSet burstRx on </code><br />
prüfen mit:<br />
:<code>get WZ1_4 reg burstRx </code><br />
''Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)''<br />
:<code>attr WZ1 burstAccess 1_auto</code><br />
<br />
Hinweis: Das Attribut im Device und nicht im Kanal setzen, ansonsten gibt es eine Fehlermeldung.<br />
<br />
=== Temperaturlisten ===<br />
Die Temperaturlisten des HM-CC-RT-DN werden identisch mit denen anderer HomeMatic Thermostate verwaltet (siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]]). Beim HM-CC-RT-DN ist der Kanal 4 (_Clima) für die Temperaturlisten zuständig.<br />
<br />
==FHEM-Log==<br />
In den folgenden Logs heißt Kanal 4 noch "_ClimRT_tr". Inzwischen würde man dort "_Clima" sehen.<br />
<br />
=== Device-Log ===<br />
2013.10.10 20:03:24 3: CUL_HM Unknown device CUL_HM_HM_CC_RT_DN_2212BC, please define it<br />
2013.10.10 20:03:24 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC CUL_HM 2212BC A1A0184002212BC0000001000954B4551303531303031375900FFFF<br />
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time<br />
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017<br />
2013.10.10 20:03:24 3: LANCUL pairing (hmPairForSec) not enabled<br />
2013.10.10 20:03:24 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC-%Y.log CUL_HM_HM_CC_RT_DN_2212BC<br />
2013.10.10 20:03:24 3: Device Heizung_Wohnzimmer added to ActionDetector with 000:10 time<br />
2013.10.10 20:03:24 3: CUL_HM pair: Heizung_Wohnzimmer thermostat, model HM-CC-TC serialNr JEQ0044286<br />
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time<br />
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017<br />
2013.10.10 20:03:25 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Weather CUL_HM 2212BC01<br />
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather<br />
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather<br />
2013.10.10 20:03:26 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Climate CUL_HM 2212BC02<br />
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate<br />
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate<br />
2013.10.10 20:03:27 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_WindowRec CUL_HM 2212BC03<br />
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec<br />
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec<br />
2013.10.10 20:03:28 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr CUL_HM 2212BC04<br />
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr<br />
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr<br />
2013.10.10 20:03:29 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam CUL_HM 2212BC05<br />
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam<br />
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam<br />
2013.10.10 20:03:30 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_remote CUL_HM 2212BC06<br />
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote<br />
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote<br />
2013.10.10 20:03:35 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time<br />
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getSerial<br />
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getConfig<br />
2013.10.10 20:03:54 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time<br />
<br />
=== Event monitor ===<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr motorErr: ok<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr measured-temp: 18.4<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr desired-temp: 18<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr ValvePosition: 3 %<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr mode: manu<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr unknown0: 24<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr T: 18.4 desired: 18 valve: 3 %<br />
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC battery: ok<br />
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC batteryLevel: 3.1 V<br />
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC measured-temp: 18.4<br />
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC desired-temp: 18<br />
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC actuator: 3 %<br />
<br />
== Firmware Update ==<br />
Seit 24.10.2014 gibt es für den HM-CC-RT-DN die neue Firmware Version 1.4. Diese kann von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic Firmware Update]].<br />
<br />
=== HM-CC-RT-DN spezifische Update Informationen ===<br />
Durch gleichzeitiges Drücken der "Auto-/Manu"-Taste und der "Comfort-/Eco"-Taste am HM-CC-RT-DN während man die Batterien wieder einlegt wird der updatemodus gestartet. Während des Updates steht "FUP" im Display. Nach erfolgreichem Update erscheint "Ins" im Display und es muss eine erneute Adaptierfahrt durch Drücken der Boost-Taste ausgelöst werden. Anschließend sollte der HM-CC-RT-DN wieder normal funktionieren. Die eingestellten Parameter und das Pairing mit FHEM gehen beim Update nicht verloren. Sollte das Update fehlschlagen, erscheint "Err" bzw. "CrC" im Display.<br />
<br />
Normalerweise sollte dann durch erneutes Starten der Prozedur am PC und HM-CC-RT-DN das ganze erneut durchführbar sein.<br />
<br />
Es gibt einige Readings, die nicht durch ein einfaches ''getConfig'' aktualisiert werden, z.B. "battery"(nicht batteryLevel). Um diese Readings zu bekommen, ist ein <br />
:<code>set Device_Channel04 controlMode auto </code><br />
notwendig. Daraufhin werden die Readings übertragen/aktualisiert.<br />
<br />
== Simulation von Fensterkontakten und externen Temperatursensoren ==<br />
{{Randnotiz|RNTyp=r|RNText=Für jeden separat zu steuernden HM-CC-RT-DN kann nur je ein Kanal eines virtuellen Devices als Temperatur- bzw. Fensterkontakt genutzt werden. Insbesondere die virtuellen Kanäle der VCCU eignen sich nicht dazu, mehrere HM-CC-RT-DN unabhängig voneinander anzusteuern!}}<br />
grober Ablauf:<br />
* erstelle ein virtuelles Device<br />
* erstelle dazu einen virtuellen Kanal<br />
* peere den Kanal mit dem RT (als Fenster-Kontakt oder als remote, wenn du willst)<br />
* sende ein postEvent<br />
<br />
=== Fensterkontakte ===<br />
''Entnommen aus diesem {{Link2Forum|Topic=31078|Message=236245|LinkText=Forenbeitrag}}''<br />
define virSC CUL_HM 221133<br />
attr virSC autoReadReg 4_reqStatus<br />
attr virSC expert 2_full<br />
attr virSC model virtual_1<br />
attr virSC peerIDs <br />
attr virSC subType virtual<br />
attr virSC webCmd press short:press long<br />
<br />
define virtualKitchenDoor CUL_HM 22113301<br />
attr virtualKitchenDoor dummy 1<br />
attr virtualKitchenDoor expert 1<br />
attr virtualKitchenDoor group Virtual<br />
attr virtualKitchenDoor model virtual_1<br />
attr virtualKitchenDoor webCmd postEvent open:postEvent closed <br />
<br />
Anschließend peeren und Temperatur festlegen mit:<br />
set virtualKitchenDoor peerChan 0 <Thermostat_Window_Rec> single set<br />
set <Thermostat_Window_Rec> regSet winOpnTemp 5 virtualKitchenDoor<br />
<br />
Ggf noch interne "Fenster-auf" Erkennung abschalten<br />
set <HM-CC-RT-DN>_Clima regSet winOpnMode off<br />
<br />
Die virtuelle Tür wird dann entsprechend über ein Notify getriggert:<br />
define notify_virtualKitchenDoor notify (Fensterkontakt_1|Fensterkontakt_2) {if($EVENT eq "open" and Value("virtualKitchenDoor") eq "set_postEvent closed"){fhem("set virtualKitchenDoor postEvent open")} elsif (Value("Fensterkontakt") eq "closed" && Value("Fensterkontakt_2") eq "closed") {fhem("set virtualKitchenDoor postEvent closed")}}<br />
<br />
=== Temperatursensoren ===<br />
''Entnommen aus diesem {{Link2Forum|Topic=19686|Message=233788|LinkText=Forenbeitrag}}''<br />
<br />
1. Virtuelles HomeMatic Device mit _deiner_ HM Id definieren:<br />
define wz_vT CUL_HM <hmId><br />
<br />
2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen:<br />
set wz_vT virtual 1<br />
<br />
3. Es ist kein virtueller Button sondern ein virtueller Temperatursensor - darum rename:<br />
rename wz_vT_Btn1 wz_vT_Sensor1<br />
<br />
4. Virtuellen Peer Sensor mit dem Weather Channel des RT-DN peeren:<br />
set wz_vT_Sensor1 peerChan 0 <RT_DN>_Weather single<br />
<br />
5. Peering kontrollieren (Voraussetzung: Device ''hm'' vom Typ [[HomeMatic HMInfo|HMinfo]] existiert):<br />
:<code>set hm peerXref</code><br />
Beispiel-Ausgabe:<br />
peerXref done: <br />
x-ref list <br />
wz_Thermostat_Weather => wz_vT_Sensor1 <br />
wz_vT_Sensor1 => wz_Thermostat_Weather<br />
<br />
6. Gemessene Temperatur vom z.B. 1-Wire DS1820 dem virtuellen HM Sensor übergeben. Z.B. alle zwei Minuten per at:<br />
define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0));; fhem "set wz_vT_Sensor1 virtTemp $T" }<br />
<br />
Fertig.<br />
<br />
Sollte es Probleme geben, dass der RT des Öfteren wieder auf seine eigenen Messwerte wechselt, so sollte das Attr cyclicMsgOffset im Virtuellen Kanal beachtet werden. Näheres dazu ist ca. ab {{Link2Forum|Topic=45735|Message=572806|LinkText=hier}} im Forum zu finden.<br />
<br />
== Auflistung und Beschreibung der Readings ==<br />
<br />
<table cellspacing="0" border="0"><br />
<tr><br />
<td style="border-top: 2px solid #ffffff; border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#A6A6A6"><font face="Arial" size=2 color="#0D0D0D">Reading</font></td><br />
<td style="border-top: 2px solid #ffffff" align="left" valign=middle bgcolor="#A6A6A6"><font face="Arial" size=2 color="#0D0D0D">Beispielwert</font></td><br />
<td style="border-top: 2px solid #ffffff" align="left" valign=middle bgcolor="#A6A6A6"><font face="Arial" size=2 color="#0D0D0D">M&ouml;gliche Werte</font></td><br />
<td style="border-top: 2px solid #ffffff; border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#A6A6A6"><font face="Arial" size=2 color="#0D0D0D">Beschreibung</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">CommandAccepted</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">yes</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">yes; no</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Letztes Kommando akzeptiert (yes/ No)</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-boostPeriod</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">5 min</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">1 min bis x min</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Zeit wie lange das Ventil im Boost Modus sein soll.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-boostPos</font></td><br />
<td align="left" valign=middle bgcolor="#111111" sdval="0.8" sdnum="1033;0;0%"><font face="Arial" size=2 color="#CCCCCC">80%</font></td><br />
<td align="left" valign=middle bgcolor="#111111" sdnum="1033;0;0%"><font face="Arial" size=2 color="#CCCCCC">0 bis 100</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Ventilposition die im Boost Modus gesetzt wird.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-btnNoBckLight</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">off</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">on; off</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="35" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-dayTemp</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">21 C</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Siehe R-tempMin bis R-tempMax</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Solltemperatur die gesetzt werden soll, wenn das Sonnensymbol am Thermostat gedr&uuml;ckt wird. Ebenso wird bei dieser Solltemperatur das Sonnensymbol im Display angezeigt.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-daylightSaveTime</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">on</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">on; off</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-decalcTime</font></td><br />
<td align="left" valign=middle bgcolor="#111111" sdval="0.458333333333333" sdnum="1033;1033;H:MM"><font face="Arial" size=2 color="#CCCCCC">11:00</font></td><br />
<td align="left" valign=middle bgcolor="#111111" sdnum="1033;1033;H:MM"><font face="Arial" size=2 color="#CCCCCC">00:00 bis 23:59</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Uhrzeit wann die Entkalkungsfahrt durchgef&uuml;hrt werden soll. </font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-decalcWeekday</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Sat</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Mon; Tue; Wed; Thu; Fri; Sat; Sun</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Tag an dem die Entkalkungsfahrt durchgef&uuml;hrt werden soll.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-modePrioManu</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">all</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">all; ???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-modePrioParty</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">all</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">all; ???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="35" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-nightTemp</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">17 C</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Siehe R-tempMin bis R-tempMax</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Solltemperatur die gesetzt werden soll, wenn das Mondsymbol am Thermostat gedr&uuml;ckt wird. Ebenso wird bei dieser Solltemperatur das Mondsymbol im Display angezeigt.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-noMinMax4Manu</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">off</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">on; off</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-regAdaptive</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">on</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">on; off</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-reguExtI</font></td><br />
<td align="left" valign=middle bgcolor="#333333" sdval="15" sdnum="1033;"><font face="Arial" size=2 color="#CCCCCC">15</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-reguExtP</font></td><br />
<td align="left" valign=middle bgcolor="#111111" sdval="30" sdnum="1033;"><font face="Arial" size=2 color="#CCCCCC">30</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-reguExtPstart</font></td><br />
<td align="left" valign=middle bgcolor="#333333" sdval="30" sdnum="1033;"><font face="Arial" size=2 color="#CCCCCC">30</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-reguIntI</font></td><br />
<td align="left" valign=middle bgcolor="#111111" sdval="18" sdnum="1033;"><font face="Arial" size=2 color="#CCCCCC">18</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-reguIntP</font></td><br />
<td align="left" valign=middle bgcolor="#333333" sdval="33" sdnum="1033;"><font face="Arial" size=2 color="#CCCCCC">33</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-reguIntPstart</font></td><br />
<td align="left" valign=middle bgcolor="#111111" sdval="44" sdnum="1033;"><font face="Arial" size=2 color="#CCCCCC">44</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-showInfo</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">time</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">date; time</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Zeige Datum oder Uhrzeit im Display an</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-showWeekday</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">off</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">on; off</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Zeige den Wochentag im Display an</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-sign</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">off</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">on; off</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-tempMax</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">30.5 C</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Gr&ouml;&szlig;te einstellbare Temperatur</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-tempMin</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">4.5 C</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Kleinste einstellbare Temperatur</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-tempOffset</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">0.0K</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">0.0 bis ???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Temperaturabweichung gemessene Temperatur vs. realer Temperatur in Grad Kelvin. Angabe in 0.5-Schritten ohne Einheitenzeichen, z.B. 0.5 oder -1.0</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-valveErrPos</font></td><br />
<td align="left" valign=middle bgcolor="#333333" sdval="0.15" sdnum="1033;0;0%"><font face="Arial" size=2 color="#CCCCCC">15%</font></td><br />
<td align="left" valign=middle bgcolor="#333333" sdnum="1033;0;0%"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-valveMaxPos</font></td><br />
<td align="left" valign=middle bgcolor="#111111" sdval="1" sdnum="1033;0;0%"><font face="Arial" size=2 color="#CCCCCC">100%</font></td><br />
<td align="left" valign=middle bgcolor="#111111" sdnum="1033;0;0%"><font face="Arial" size=2 color="#CCCCCC">0 bis 100</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Maximale Ventilstellung die das Thermostat fahren darf.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-valveOffsetRt</font></td><br />
<td align="left" valign=middle bgcolor="#333333" sdval="0" sdnum="1033;0;0%"><font face="Arial" size=2 color="#CCCCCC">0%</font></td><br />
<td align="left" valign=middle bgcolor="#333333" sdnum="1033;0;0%"><font face="Arial" size=2 color="#CCCCCC">0 Bis 100</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="52" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-winOpnBoost</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">off</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">on; off</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Startet nach dem Fensterschlie&szlig;en die Boostfunktion um unabh&auml;ngig von der Raumtemperatur den Heizk&ouml;rper eine Zeit x aufzuheizen. (Siehe R-boostPeriod &amp; R-boostPos)</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-winOpnDetFall</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">1.4 K</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">0.5 bis 2.5</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Temperatur Sturz zwischen zwei Messungen, die als Fenster offen erkannt werden.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="35" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-winOpnMode</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">off</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">on; off</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Thermostat soll anhand eines schnellen Temperaturabfalls erkennen, dass das Fenster ge&ouml;ffnet ist.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R-winOpnPeriod</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">15 min</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">1 bis ??? Minuten</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Dauer bis das Signal Fenster offen wieder entfernt wird.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R-winOpnTemp</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">12 C</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Siehe R-tempMin bis R-tempMax</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Temperatur die eingestellt werden soll, wenn das Fenster als offen erkannt wird.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="104" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R_0_tempListSat</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">07:00 20.0 22:30 22.0 24:00 20.0</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">incomplete = Daten werden mit Thermostat abgeglichen<br><br>Zeit/Temperaturangaben siehe Beispiel</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Tages Solltemperaturen abh&auml;ngig von der Uhrzeit. <br>- Der Beginn um 00:00 ist nicht einzutragen. <br>- Es sind immer Paare einzutragen (Uhrzeit Temperatur). <br>- Der letzte Eintrag muss an jedem Tag 24:00 sein.<br>- Uhrzeiten sind auf halbe Stunden beschr&auml;nkt. Eintr&auml;ge 08:00 und 08:30 sind g&uuml;ltig. 08:20 ist ung&uuml;ltig.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R_1_tempListSun</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">07:00 20.0 22:00 22.0 24:00 20.0</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Siehe R_0_tempListSat</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Siehe R_0_tempListSat</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R_2_tempListMon</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Siehe R_0_tempListSat</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Siehe R_0_tempListSat</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R_3_tempListTue</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Siehe R_0_tempListSat</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Siehe R_0_tempListSat</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R_4_tempListWed</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Siehe R_0_tempListSat</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Siehe R_0_tempListSat</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R_5_tempListThu</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Siehe R_0_tempListSat</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Siehe R_0_tempListSat</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">R_6_tempListFri</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Siehe R_0_tempListSat</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Siehe R_0_tempListSat</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="35" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">R_tempList_State</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">verified</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">incomplete = Daten werden mit Thermostat abgeglichen<br>verified = Daten sind mit Thermostat abgeglichen</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Aktualisierungsstatus der Wochen Temperatur Einstellungen</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">ValvePosition</font></td><br />
<td align="left" valign=middle bgcolor="#333333" sdval="36" sdnum="1033;"><font face="Arial" size=2 color="#CCCCCC">36</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">0 bis 100</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">aktuelle Ventilstellung</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="35" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">boostTime</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">-</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">-<br>1 min bis n min</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Zeit wie lange der Boostmodus noch aktiv ist.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="121" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">controlMode</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">auto</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">auto = Thermostat wird nach der TempListe gesteuert<br>manual = Die eingestellte Temperatur am Thermostat wird nicht ver&auml;ndert, au&szlig;er bei Verwendung von WinOpn; <br>boost = Thermostat wird in den Boost Modus gesetzt. Siehe R-boostPeriod/Pos<br>day = Thermostat wird auf die eingestellte Tag Temperatur gesetzt (R-dayTemp).<br>night = Thermostat wird auf die eingestellte Nacht Temperatur gesetzt (R-nightTemp).</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Setzt das Thermostat in einen bestimmten Modus</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">desired-temp</font></td><br />
<td align="left" valign=middle bgcolor="#111111" sdval="22" sdnum="1033;"><font face="Arial" size=2 color="#CCCCCC">22</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">N/A</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Solltemperatur</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">measured-temp</font></td><br />
<td align="left" valign=middle bgcolor="#333333" sdval="23.2" sdnum="1033;"><font face="Arial" size=2 color="#CCCCCC">23.2</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">N/A</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Isttemperatur</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">partyEnd</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">-</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Ende Datum/Zeit in dem die Party Temperatur (partyTemp) gesetzt sein soll.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">partyStart</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">-</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">Start Datum/Zeit in dem die Party Temperatur (partyTemp) gesetzt sein soll.</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">partyTemp</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">-</font></td><br />
<td align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">-; 20.0</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Party Temperatur</font></td><br />
</tr><br />
<tr><br />
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">recentStateType</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">ack</font></td><br />
<td align="left" valign=middle bgcolor="#333333"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
<td style="border-right: 2px solid #ffffff" align="left" valign=middle bgcolor="#333333" sdnum="1033;1033;M/D/YYYY H:MM"><font face="Arial" size=2 color="#CCCCCC">???</font></td><br />
</tr><br />
<tr><br />
<td style="border-bottom: 2px solid #ffffff; border-left: 2px solid #ffffff" height="23" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">state</font></td><br />
<td style="border-bottom: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">T: 23.2 desired: 22.0 valve: 36</font></td><br />
<td style="border-bottom: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC"><br></font></td><br />
<td style="border-bottom: 2px solid #ffffff" align="left" valign=middle bgcolor="#111111"><font face="Arial" size=2 color="#CCCCCC">Aktuelle Statusinformation</font></td><br />
</tr><br />
</table><br />
<br />
== Bekannte Probleme ==<br />
=== TempList: Bad format ... ===<br />
Wenn Sie beim Setzen einer Temperaturliste nach dem o.a. Schema ("SetTempList...") die Meldung<br />
<br />
Bad format, use HH:MM TEMP ......<br />
<br />
erhalten, sollten Sie zunächst ein [[update]] von FHEM durchführen.<br />
<br />
=== Der Thermostat heizt über die Solltemperatur hinaus ===<br />
In der Regel ist das ein ganz normales Verhalten, wenn der Thermostat nicht mit einem externen Temperaturfühler oder einem Wandthermostat gepeert ist. In dem Fall muss sich der Thermostat auf den eingebauten Temperatursensor verlassen, der sehr nahe an der Heizung selbst sitzt. Dadurch ist die gemessene Temperatur höher, als sie z.B. in der Raummitte wäre. Der Hersteller hat hier einen mehr oder weniger intelligenten Algorithmus eingebaut, um diesen Effekt zu kompensieren. Das sieht dann so aus, als ob der Thermostat nicht richtig regelt.<br />
Dieses Verhalten kann man im Prinzip nur verhindern, indem man einen externen Temperatursensor oder einen Wandthermostat peert. Wie das geht ist hier beschrieben: [[#Channel (Kanal) 01 _Weather]]. Normalerweise regelt der Thermostat dann genau auf die Solltemperatur. <br />
Ansonsten sollte man sich auch fragen, ob das gezeigte Verhalten vielleicht doch gut genug ist. Dazu platziert man irgendein Thermometer möglichst in der Mitte des Raums und beobachtet den Temperaturverlauf eine Weile. Wenn man dann noch eine Abweichung feststellt, kann es sinnvoll sein, diese mittels des Registers R-tempOffset zu beheben.<br />
<br />
== Links ==<br />
* [http://www.eq-3.de/produkt-detail-aktoren/items/homematic-funk-heizkoerperthermostat.html Produktinfo]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-CC-RT-DN_UM_GE_eQ-3_web.pdf Bedienungsanleitung (PDF)]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/pdb/Funk-Heizkoerperthermostat_105155_Produktdatenblatt_V2.3.pdf Datenblatt (PDF)]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads/Ventilkompatibilitaeten.pdf Ventil-Kompatibilitätsliste (zur Zeit nicht verfügbar)]<br />
* {{Link2Forum|Topic=14738|LinkText=Forenthema zum Thermostat}}<br />
* {{Link2Forum|Topic=64446|LinkText=Reparatur einer durch mechanischen Stoß von außen abgerissenen Lichtschranke}}<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Heizungsventile]]<br />
[[Kategorie:868MHz]]</div>AndreasMohrhttp://wiki.fhem.de/w/index.php?title=HM-CFG-LAN_LAN_Konfigurations-Adapter&diff=29280HM-CFG-LAN LAN Konfigurations-Adapter2019-01-27T20:38:23Z<p>AndreasMohr: Kleine Verdeutlichungen/Hinweise</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HM-CFG-LAN.jpg<br />
|Bildbeschreibung=HM-CFG-LAN, Draufsicht und Seitenansicht<br />
|HWProtocol=HomeMatic<br />
|HWType=[[Interface]]<br />
|HWCategory=<br />
|HWComm=868,3&nbsp;MHz<br />
|HWChannels=n/a<br />
|HWVoltage=7,5&nbsp;VDC<br />
|HWPowerConsumption=ca.&nbsp;100&nbsp;mA<br />
|HWPoweredBy=Steckernetzteil<br />
|HWSize=100x30mm (ø&nbsp;x&nbsp;H)<br />
|HWDeviceFHEM= {{Link2CmdRef|Anker=HMLAN|Label= 00_HMLAN.pm}}<br />
|ModOwner={{Link2FU|251|Martin / martinp876}}<br />
|HWManufacturer=ELV / eQ-3<br />
}}<br />
<br />
Der [[HM-CFG-LAN LAN Konfigurations-Adapter]] ([http://www.eq-3.de/produkt-detail-zentralen-und-gateways/items/hm-cfg-lan.html HM-CFG-LAN]), kurz HMLAN Konfigurator, ist ein [[Interface|Schnittstellengerät]] (IO) ohne wesentliche Intelligenz. Die Aufgabe ist, ein Interface von der Zentrale zu den Geräten bereitzustellen. Ein HMLAN Konfigurator selbst steuert keine Geräte, er überträgt nur Nachrichten in beide Richtungen.<br />
<br />
== Alternativen ==<br />
Alternativen zu einem HMLAN Konfigurator sind [[HM-CFG-USB USB Konfigurations-Adapter]], [[CUN]], [[CUNO]] und [[CUL]].<br />
<br />
;HMUSB<br />
:Ein HMUSB hat nahezu identische Eigenschaften wie ein HMLAN Konfigurator. Der wesentliche Unterschied ist die Anbindung über USB anstatt Ethernet. Es hat sich erwiesen, dass USB eine bessere Latenz hat als LAN - also eine kürzere Verzögerung. Damit hat ein HMUSB leichte Vorteile zu HMLAN Konfigurator, was aber in den bei Weitem meisten Fällen durch die interne Timing Kalkulation abgefangen wird. Zudem können über den HMUSB (ab Version 2) auch Firmware-Updates OTA (over-the-air, also per Funkverbindung) auf entsprechende HM-Geräte (z.B. den HM-CC-RT-DN) durchgeführt werden.<br />
:Dafür bietet der HMLAN Konfigurator mit seinem Netzwerkanschluss Vorteile bei der Platzierung und bei der Ansteuerung (teilweise Timing-Probleme beim Anschluss von USB-Geräten an langsamere Raspberrys und beim Durchschleifen von USB an FHEM in einer virtuellen Maschine).<br />
<br />
; CUL/CUN(O)<br />
* Die Devices liefern keine eigenen Zeitstempel, wodurch eine Timingkorrektur durch FHEM nicht möglich ist. Je nach Systemgeschwindigkeit kann dies zu Problemen, Nachrichtenwiederholung und ggf. auch Nachrichtenverlust führen<br />
* Da USB kurze Reaktionszeiten und geringe Timingschwankungen hat, ist der Einsatz von [[CUL]] und [[CUNO]] mit HM möglich. <br>Die Timingschwankungen der Ethernet-Schnittstelle hingegen können in FHEM nicht ausgeglichen werden. Daher kann der Einsatz der [[CUNO]] über Ethernet '''nicht empfohlen''' werden.<br />
* Der Übertragungsmodus ''lazyConfig'' wird nicht unterstützt<br />
<br />
== Funktionen ==<br />
=== AES ===<br />
siehe [[AES Encryption]].<br />
<br />
=== Übertragungsmodus ===<br />
Es werden alle HM-Modi unterstützt. Diese sind Always, Burst, Wakeup und Config. Weiter gibt es lazyConfig und conditionalBurst. Siehe [[HomeMatic]] für Details.<br />
<br />
=== KeepAlive ===<br />
Der HMLAN Konfigurator baut eine Verbindung zur Zentrale über das LAN Interface auf. Der HMLAN Konfigurator erwartet alle 30 Sekunden eine keep-alive Nachricht von der Zentrale. Sollte diese ausbleiben, baut der HMLAN Konfigurator die LAN-Verbindung ab. Das führt zu einem Disconnect, der in State gemeldet wird. Die Verbindung wird automatisch wieder aufgebaut. <br />
FHEM sendet den keep-alive alle 25 Sekunden, was einen 5 Sekunden Puffer einräumt. In Internals '''msgKeepAlive''' kann man sehen, wie hoch die maximale Verzögerung der Zentrale beim Senden war und wie viel Puffer (in Sekunden) noch verfügbar war. <br />
Die Wiederholrate von 25 Sekunden des keep-alive kann mit dem Attribut '''wdTimer''' reduziert werden, was den Puffer erhöht. Es wird jedoch dringend geraten, im Problemfall die Ursache der Verzögerung zu suchen und zu eliminieren.<br />
<br />
=== Nachrichtenübertragung - Performance ===<br />
* Mit Internal ''msgParseDly'' kann man ablesen, welche Verzögerung eine Nachricht vom Empfang im HMLAN Konfigurator bis zur Verarbeitung in der Zentrale hat.<br />
* Der HMLAN Konfigurator hält sich an den Funkstandard, der einem Sender maximal 36 Sekunden Sendezeit je Stunde erlaubt ([[1%25_Regel]]). Wird dieser Wert überschritten, stellt der HMLAN Konfigurator das Senden ein. Empfangen wird weiter. Ist eine Nutzung des Zeitslots zu 90% erreicht, wird im Reading ''cond'' ''Warning-HighLoad'' gemeldet. Bei cond ''ERROR-Overload'' wird das Senden eingestellt.<br />
<br />
=== Loggen/Mitschneiden ===<br />
Es stehen die üblichen Funktionen des Attribute [[verbose]] zu Verfügung. Darüber hinaus gibt es die Attribute ''hmProtocolEvents'' und ''logIDs''. Siehe auch [[Homematic Nachrichten sniffen]].<br />
<br />
== Vorbereitung ==<br />
{{Randnotiz|RNText='''"Usersoftware"/Firmware'''<br />
* V1.512 / 19.12.2013 / [http://files.elv.de/Assets/Produkte/8/851/85128/Downloads/hm_cfg_lan_software_v1_512.zip Download]<br />
* V1.515 / 12.08.2014 / [http://files.elv.de/Assets/Produkte/8/851/85128/Downloads/hm_cfg_lan_software_v1_515.zip Download]<br />
* V1.520 / 10.12.2015 / [http://www.eq-3.de/Downloads/Software/Konfigurationsadapter/Konfigurationsadapter_LAN/HM-CFG-LAN_Usersoftware_V1_520_eQ-3_151207.zip Download]<br />
'''Firmware Update Tool / Firmware / Datum'''<br />
* V1.2 / 0.965 / 11.02.2016 / [http://www.eq-3.de/Downloads/Software/Firmware%20Update%20Tool/HM-Firmware-Update-Tool_V1_2_eQ-3_160211.zip Download]<br />
<br />
}}<br />
[[Datei:HMLAN_CONFIG_IP_AES.png|300px|thumb|right|HomeMatic Lan-Interface Configurator]][[Datei:HMLAN_CONFIG_AES.png|300px|thumb|right|HomeMatic Konfigurator]]<br />
Bevor man den HMLAN mit FHEM nutzen kann, müssen noch Einstellungen vorgenommen werden. Dazu braucht man die Konfigurationsadapter-LAN-Usersoftware, die bei [http://www.eq-3.de/service/downloads.html HomeMatic] herunter zu laden ist und nach der Installation mit der Verknüpfung "HomeMatic-Lan-Interface konfigurieren" oder "HomeMatic-Komponenten konfigurieren" gestartet wird und unter Windows läuft. Für andere Betriebssysteme (siehe Anhang im Beitrag {{Link2Forum|Topic=11506|Message=67417|LinkText=Anleitung für OS X}}) braucht man eine Windows-Emulation. Dem HMLAN liegen zwei Konfigurationsprogramme bei, bitte darauf achten, das richtige zu verwenden. Wenn das Konfigurationsprogramm den HMLAN-Konfigurator nicht findet, sollten alle nicht benutzten Netzwerkinterfaces vorübergehend deaktiviert werden, siehe {{Link2Forum|Topic=10933|Message=62960|LinkText=Beitrag im FHEM Forum}} und [[HM-CFG-LAN_LAN_Konfigurations-Adapter#Bekannte_Probleme|bekannte Probleme]].<br />
<br />
=== Firmware ===<br />
Die aktuelle Firmware Version des HMLAN Konfigurators ist 0.965 (Stand Februar 2016). Ein Update ist mit dem ''"Firmware Update Tool"'' möglich, die Firmware ist Bestandteil des Tools.<br />
<br />
Um einen mit FHEM benutzten HM-LAN zu aktualisieren, reicht es,<br />
# im HMLAN-Device mit <code>attr <myHMLAN> dummy 1</code> den Adapter vorübergehend zu deaktivieren,<br />
# mit dem (Windows) Firmware Update Tool die Firmware auf den HM-LAN aufzuspielen<br />
# nach dem Stoppen des Update Tools mit <code>deleteattr <myHMLAN> dummy</code> das Device in FHEM wieder zu aktivieren.<br />
<br />
Version 1.2 des Firmware Update Tools läuft auch unter Windows 10. <br />
<br />
Allerdings kann es unter Umständen passieren, dass sich das Programm mit folgender Fehlermeldung nicht starten lässt:<br />
"Die Anwendung konnte nicht gestartet werden, da die Side-by-Side Konfiguration ungültig ist."<br />
<br />
Dann fehlt die Microsoft Visual C++ 2008 SP1 Redistributable Package (x86). Diese kann dann unter dieser Adresse heruntergeladen und anschließend installiert werden: https://download.microsoft.com/download/d/d/9/dd9a82d0-52ef-40db-8dab-795376989c03/vcredist_x86.exe<br />
<br />
=== IP Adresse ===<br />
Der HMLAN Konfigurator ist ähnlich wie der CUN(O) ein Netzwerkgerät. Er beherrscht DHCP und bezieht bei einem im Netzwerk erreichbaren DHCP Server von diesem eine IP-Adresse. Da FHEM zwecks Kommunikation die IP-Adresse wissen muss, ist es sinnvoll, dem HMLAN Konfigurator eine statische (feste) Adresse zuzuweisen. <br />
* mit der auf der CD mitgelieferten ''"HomeMatic Lan-Interface Configurator"'' Software unter ''"Change IP Settings"'' oder<br />
* im DHCP-Server (sofern dies vom gegebenen DHCP Server als Konfigurationsoption unterstützt wird).<br />
<br />
=== AES Encrypted LAN Communication ===<br />
Wichtig ist, dass vor Verwendung die "AES Encrypted LAN Communication" abgeschaltet wird, da diese von FHEM nicht unterstützt wird. Dies ist unter ''"Change IP Settings"'' der ''"HomeMatic Lan-Interface Configurator"'' Software möglich. AES auf dem LAN ist zu unterscheiden von HMLAN auf der Funkschnittstelle. siehe [[AES Encryption]].<br />
<br />
== Einbindung in FHEM ==<br />
Der HMLAN-Konfigurator muss in FHEM [[Konfiguration|konfiguriert]] werden. Das erfolgt mit diesen Befehlen:<br />
:<code>define HMLAN1 HMLAN <IP Adresse>:1000</code><br />
Der Name (im obigen Beispiel ''HMLAN1'') kann frei vergeben werden. Standard IP-Port des HMLAN-Konfigurators ist 1000.<br />
<br />
HMLAN kennt mehrere Attribute ({{Link2CmdRef|Anker=HMLAN}}). <br />
Äußerst wichtig ('''''Sicherheit!!''''') ist es außerdem, die '''hmId''' zu vergeben, siehe [[HomeMatic_Devices_pairen#hmId]]. <br />
<br />
Ein '''gleichzeitiger''' Zugriff von FHEM und der HomeMatic-Software auf den HMLAN-Konfigurator ist nicht möglich, da letzterer nur eine einzige Verbindung zulässt. Wollen Sie temporär z.B. mit der Windows-Software von HomeMatic zugreifen, ist FHEM zu deaktivieren.<br />
Sinnvoll ist es, die hmId mit der hmId der PC-Software gleichzusetzen. Dann kann man von beiden Zentralen alternativ zugreifen ohne pairen zu müssen.<br />
<br />
=== Nutzung mehrere IOs ===<br />
==== Empfangen ====<br />
Man kann an einem FHEM mehrere IOs (HMLAN/USB, CUL/CUNO) betreiben. Generell empfangen alle IOs von allen Geräten in ihrem Empfangsbereich - unabhängig von der hmId. <br />
<br />
==== Senden ====<br />
An ein Gerät wird nur über das IO gesendet, das in Internals->IODev angezeigt wird. Nutzt man mehrere IOs sollte man im HM Device das Attribut IODev auf das gewünschte IO setzen. Ansonsten sucht FHEM zufällig ein IO aus.<br />
<br />
==== hmId bei mehreren IOs ====<br />
Man kann allen IOs die gleiche hmId setzen. Das erlaubt die wahlfreie Umschaltung des Sende-IOs für das Device. Sollte man unterschiedliche hmIds wählen, simuliert dies mehrere Zentralen. Das Device, an das man sendet, muss über ein IO angesprochen werden, mit einer hmId, auf die das Device gepairt ist. <br />
<br />
<br />
=== Virtueller Controller VCCU ===<br />
Speziell wenn mehrere IOs verwendet werden sollen, empfiehlt sich die Verwendung einer [[Virtueller Controller VCCU|VCCU]], da eine redundante Nutzung mehrerer Schnittstellen dann wesentlich einfacher einzurichten ist. Das Einrichten einer VCCU lohnt sich aber schon bei der Benutzung nur eines HomeMatic I/O, also wenn man z.B. nur einen HMLAN Konfigurator einsetzen will. Zum Einen ist es wesentlich einfacher ggf. später weitere Schnittstellen dazu zu konfigurieren, zum Anderen adressiert die VCCU die auch bereits bei einer Schnittstelle auftauchenden Probleme wie die "<code>Unknown code</code>" Meldungen im Log.<br />
<br />
Die Einrichtung einer VCCU ist nicht sehr aufwändig und wird dringend empfohlen.<br />
<br />
=== Attribute ===<br />
* '''hmId''': Adresse, die das IO auf der Funkstrecke nutzt. Siehe [[HomeMatic_Devices_pairen#hmId]].<br />
* '''hmKey, hmKey2..3''': bis zu 3 AES keys, die auf der Funkstrecke genutzt werden. Siehe [[AES Encryption]]<br />
* '''hmLanQlen''' legt fest, wie viele Nachrichten parallel gesendet werden dürfen, also auf wie viele Antworten die Zentrale parallel warten darf. Ein Wert von 1 ist max defensiv, erzeugt aber eine höhere Verzögerung. Wählt man einen höheren Wert kann es zu Nachrichten-Wiederholungen kommen. <br />
* '''hmProtocolEvents''': alle Nachrichten werden dekodiert ausgegeben. Diese Einstellung benötigt einige Performance insbesondere bei höherem Level. Man sollte es vorsichtig nutzen. <br />
* '''logIDs''': zeichnet Rohmessages auf und bietet die genaueste Methode bei der Fehlersuche. Da Nachrichten undekodiert ausgegeben werden, ist es im Wesentlichen für Spezialisten von Bedeutung. Man gibt eine Komma-getrennte Liste von IDs an, die geloggt werden sollen. Mit '''all''' werden alle IDs aufgezeichnet. '''sys''' zeichnet zusätzlich Systemmessages auf. '''sys,all''' somit alles.<br />
* '''respTime''': Antwortzeit des HMLAN auf ein keep-alive kann hier eingestellt werden. Normalerweise sollte das HMLAN innerhalb einer Sekunde der Zentrale antworten. Sollte dies nicht passieren, wird die Message wiederholt. Der Wert sollte nur in Ausnahmefällen verändert werden.<br />
<br />
=== Readings ===<br />
* '''Xmit-Events''': Anzahl der Ereignisse <br />
* '''cond''': aktueller Zustand des IO. <br />
** ok<br />
** Warning-HighLoad: 90% der 1h Sendekapazität sind erreicht<br />
** ERROR-Overload: 100% der Sendekapazität sind erreicht, '''das IO sendet nicht mehr'''<br />
** timeout<br />
** disconnected: die Verbindung FHEM / IO ist unterbrochen<br />
** Overload-released: das IO ist aus ERROR-Overload zurück im Sendebetrieb<br />
** init: Das IO wurde neu initialisiert. <br />
* '''prot_ERROR-Overload''': Anzahl des Events, Zeitstempel des letzten Auftretens<br />
* '''prot_Warning-HighLoad''': Anzahl des Events, Zeitstempel des letzten Auftretens<br />
* '''prot_disconnected''': Anzahl des Events, Zeitstempel des letzten Auftretens<br />
* '''prot_init''': Anzahl des Events, Zeitstempel des letzten Auftretens<br />
* '''prot_ok''': Anzahl des Events, Zeitstempel des letzten Auftretens<br />
* '''prot_timeout''': Anzahl des Events, Zeitstempel des letzten Auftretens<br />
<br />
=== Internals ===<br />
* '''XmitOpen''': 1 = HMLAN ist sendebereit<br />
* '''assignedIDs''': hmIds der HM Devices, die über dieses IO bedient werden<br />
* '''assignedIDsCnt''': Anzahl der zugewiesenen hmIds von FHEM<br />
* '''assignedIDsReport''': Anzahl der hmIds, die das HMLAN angibt zu bedienen. Die Zahl sollte identisch sein mit assignedIDsCnt<br />
* '''msgKeepAlive''': dlyMax: maximale Verzögerung, die ein keep-alive hatte. bufferMin: der minimale Zeitpuffer, der übrig blieb, bis das keep-alive zu spät gekommen wäre. Der Puffer sollte 2 oder größer sein, sonst könnte man gelegentlich disconnects bekommen. <br />
* '''msgLoadEst''': Funkbelastung des HMLAN. Der Wert wird über 1 Stunde akkumuliert. Sollten 100% erreicht sein, wird das HMLAN den Sendebetrieb einstellen. Der Wert ist eine Hochrechnung in FHEM. Es ist möglich, dass das HMLAN mehr belastet ist. Die 10 min Werte zeigen die Belastung in den letzten 10min Perioden an.<br />
* '''msgParseDly''': Verzögerung der Message Verarbeitung vom Empfang im IO bis zur Verarbeitung in FHEM, gemessen in Millisekunden. Eine Verzögerung kann durch Prozesse an LAN, durch FHEM Prozesse oder sonstige Prozesse/Applikationen der CPU hervorgerufen werden.<br />
<br />
== Pairen von Geräten ==<br />
Jedes HM Gerät muss vor Verwendung mit der HM-Zentrale [[Pairing (HomeMatic)|gepairt]] werden. Hierfür ist Wahl einer hmId nötig (alle Details siehe [[HomeMatic_Devices_pairen#hmId]]).<br />
Alle Geräte haben eine eigene Seriennummer, die nicht änderbar ist. Details zum Pairen auf der Seite [[HomeMatic Devices pairen]].<br />
<br />
== Bekannte Probleme ==<br />
=== Verbindung wird abgelehnt ===<br />
Selten lehnt der HMLAN-Adapter ohne erkennbaren Grund nach monatelangem störungsfreiem Betrieb die Verbindung ab:<br />
<pre style="width:400px;"><br />
Opening HMLAN1 device 192.168.168.60:1000<br />
192.168.168.60:1000 connection refused<br />
</pre><br />
Der HMLAN-Adapter kann aber über die mitgelieferte Konfigurationssoftware problemlos erreicht werden. Der Zustand lässt sich auch durch einen Reboot des HMLAN-Adapters (oder FHEM) nicht beheben, wohl aber durch eine Aktualisierung der Firmware des HMLAN-Adapters, '''selbst wenn die installierte Version aktuell ist'''.<br />
<br />
=== Homematic-Geräte-Konfigurationsprogramm verbindet sich nicht mit LAN-Adapter ===<br />
Damit das Konfigurationsprogramm auf den LAN-Adapter zugreifen kann, muss das FHEM-Modul deaktiviert werden. (Attribute dummy=1 oder FHEM herunterfahren) Hat das Konfigurationsprogramm trotzdem Probleme, den LAN-Adapter zu finden, sollten vorübergehend alle bis auf das aktuell genutze Netzwerkinterfaces deaktiviert werden. Unter Windows 7 reicht es eventuell nicht, die Netzwerkverbindungen im "Netzwerk- und Freigabecenter" zu deaktivieren, sondern die Netzwerkadapter müssen auch im Gerätemanager deaktiviert werden.<br />
<br />
Unter Windows 10 scheint das Programm nicht mehr zu funktionieren. Der Konfigurationsadapter wird nicht gefunden. Auch nicht bei deaktivierten Netzwerkverbindungen.<br />
<br />
=== Häufiger automatischer Neustart ("Reboot") ===<br />
Der HMLAN Adapter startet ohne erkennbaren äußeren Anlass häufig neu. Das Problem ist auch im Forum unter der Überschrift {{Link2Forum|Topic=20776|LinkText=HMLAN Adapter wechselt permanent zwischen disconnected / connected}} beschrieben. Im FHEM Log erscheinen in diesem Fall folgende Meldungen:<br />
<pre style="width:600px;"><br />
... HMLAN_Parse: myHMLAN new condition timeout (je nach Timing, manchmal)<br />
... HMLanHostname:1000 disconnected, waiting to reappear (myHMLAN)<br />
... HMLAN_Parse: myHMLAN new condition disconnected<br />
... HMLanHostname:1000 reappeared (myHMLAN)<br />
... HMLAN_Parse: myHMLAN new condition init<br />
... HMLAN_Parse: myHMLAN new condition ok<br />
</pre><br />
Dieses Problem ist bei ELV [http://www.elv.de/topic/hm-lan-reboots.html bekannt] und soll mit der [http://www.eq-3.de/Downloads/Software/Konfigurationsadapter/Konfigurationsadapter_LAN/HM-CFG-LAN_Usersoftware_V1_520_eQ-3_151207.zip Konfigurationsadapter LAN Usersoftware V1.520 (10.12.2015)], bzw. der darin enthaltenen Firmware Version, behoben sein. Stand 05.08.2016 12:32 Auch mit der aktuellen Firmware (v0.965 - Link siehe oben) und der aktuellen Version von HMLAN (Rev 11645 vom 2016-06-11) tritt der Fehler noch auf.<br />
<br />
=== Kompletter und/oder sporadischer Totalausfall ===<br />
Sollten die oben genannten softwareseitigen Problemlösungen zu keinem erwünschten Ergebnis führen, kann gegebenenfalls ein Austausch der verbauten Elektrolytkondensatoren (Elkos) Abhilfe schaffen.<BR><br />
Zumindest ist dies eine Alternative zur Verschrottung. <BR><br />
Siehe Forumsbeitrag https://forum.fhem.de/index.php/topic,62442.msg538982.html#msg538982<BR><br />
<br />
== Verbesserung der Antennenleistung ==<br />
Die Sende- und Empfangsleistung kann man verbessern. <br />
<br />
Ein relativ einfache Methode ist, die Antenne aus dem Gehäuse herauszuführen. Dies bringt in der Regel bereits einen spürbar verbesserten RSSI und eine verminderte Einstrahlung der Elektronik in die Antenne. Als Kosten fallen der Kaufpreis des 5er TORX an, der üblicherweise nicht vorhanden ist und ca. 6 € kostet (es ist u.U. empfehlenswert, gleich ein ganzes Kombi-Set für Handy-Reparatur etc. zu kaufen).<br />
<br />
* HM-CFG-LAN aufschrauben. Innen sieht er so aus:<br />
<br />
[[Datei:HM-CFG-LAN Innen.jpeg]]<br />
<br />
Der schwarze Draht im oberen Bereich unter den Lichtleitern ist die Antenne.<br />
<br />
* Lichtleiter entfernen (Bleibt machmal auch im Deckel hängen)<br />
<br />
[[Datei:HMLAN Antenne.JPG]]<br />
<br />
Rechts ist das Funkmodull zu erkennen, der schwarze Draht ist die Antenne. Es ist gut zu sehen, dass die Antenne sehr nahe an der Elektronik ist, die HF-Signale in die Antenne einstrahlt und die Empfangsleistung dadurch vermindert.<br />
<br />
* Das Gehäuse an passender Stelle mit einer kleinen Feile oder einem Drehmel oder ähnlich einkerben.<br />
<br />
[[Datei:HMLAN schlitz.JPG]]<br />
<br />
<br />
<br />
* Die Antenne einfach nach aussen biegen. Der Winkel ist egal, und kann später durch die Positionierung des HM-CFG-LAN optimal eingestellt werden. Der Draht sollte aber gerade sein, also keinen Knick oder keine Krümmung haben.<br />
<br />
[[Datei:Antenne nach aussen.JPG]]<br />
<br />
Man kann die Antenne auch verlängern, sinnvoll ist aber nur eine Verdopplung (von L/4 auf L/2). Geringere Verlängerungen verschlechtern die Leistung.<br />
<br />
<br />
* Gehäuse wieder zusammenbauen und zuschrauben, fertig.<br />
<br />
[[Datei:HMLANAntenneextern.JPG]]<br />
<br />
<br />
Dieser Umbau (ohne Antennenverlängerung) bringt in der Regel einen um 4-5 Zähler verbesserten RSSI und verringert die Einstrahlung der Elektronik. Dies ist nur der einfachste Schritt eines Antennenumbaus. Mit nur wenig mehr Aufwand lassen sich wesentlich bessere Ergebnisse erzielen.<br />
<br />
Links zu weitergehenden Maßnahmen [[Trick_der_Woche#HM_LAN_Konfig-Adapter_Antenne_verbessern|hier]].<br />
<br />
== Wechsel von CUL zu HMLAN ==<br />
{{Randnotiz|RNTyp=y|RNText=Der hier beschriebene Wechsel sollte mittlerweile einfacher über die [[Virtueller Controller VCCU|VCCU]] realisierbar sein, indem erst ein weiteres IO-Device hinzugefügt und anschließend das zu ersetzende entfernt wird.}}<br />
Sollten ein [[CUL]] als IO für HomeMatic-Geräte dienen und ein Wechsel auf den HMLAN Konfigurator geplant sein, kann die folgende Vorgehensweise gewählt werden:<br />
<br />
* deaktivieren Sie das CUL in der ''fhem.cfg''.<br />
* konfigurieren Sie den HMLAN Konfigurator '''von Hand''' <br />
* Ändern Sie das Attribut IODev aller HM-Devices vom Namen der CUL auf den Namen des HMLAN<br />
* sollten Sie das Attribut IODev nicht nutzen (nicht empfohlen), achten Sie darauf, dass im fhem.cfg das IO vor allen HM-devices definiert wird. Eine automatischen Zuweisung des IO zu den Devices ist sonst nicht möglich. <br />
** der HMLAN '''muss''' die gleiche ''hmId'' wie das bisherige CUL erhalten. Ansonsten müssen alle Geräte neu gepairt / angelernt werden.<br />
** AES muss im HMLAN abgeschaltet werden.<br />
* verbinden Sie den HMLAN Konfigurator mit ihrem Netzwerk und ziehen das CUL aus der USB-Buchse.<br />
* geben Sie in der FHEM-Befehlszeile ''shutdown restart'' gefolgt von &lt;Enter&gt; (nicht "save") ein (evtl. reicht auch ein ''rereadcfg'').<br />
* kontrollieren Sie im Event-Monitor und in den HM-Device-Logs von FHEM die Kommunikation.<br />
<br />
Bitte beachten: Falls dem CUL keine explizite hmId per Attribut zugewiesen wurde, wird diese ID aus "F1&lt;FHT-ID&gt;" zusammengebaut. Die hmId muss auf dem HMLAN explizit gesetzt werden.<br />
<br />
== Links ==<br />
<!-- Produkt derzeit nicht im Sortiment - * [http://www.elv.de/homematic-lan-konfigurations-adapter.html Produktseite] bei ELV --><br />
* [http://www.eq-3.de/service/downloads.html Software] für den Konfigurationsadapter von der eQ-3 Site<br />
* [https://download.microsoft.com/download/d/d/9/dd9a82d0-52ef-40db-8dab-795376989c03/vcredist_x86.exe Download] für das Microsoft Visual C++ 2008 SP1 Redistributable Package (x86)<br />
* [[Trick_der_Woche#HM_LAN_Konfig-Adapter_Antenne_verbessern|HM LAN Konfig-Adapter Antenne verbessern]]<br />
<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:868MHz]]</div>AndreasMohr