http://wiki.fhem.de/w/api.php?action=feedcontributions&user=Neubert&feedformat=atomFHEMWiki - Benutzerbeiträge [de]2024-03-29T07:41:05ZBenutzerbeiträgeMediaWiki 1.39.3http://wiki.fhem.de/w/index.php?title=SiSi&diff=28512SiSi2018-11-24T21:26:11Z<p>Neubert: </p>
<hr />
<div>Diese Seite beschreibt, wie man das Signal Messenger Command Line Interface (CLI) unter Raspbian installiert und mit FHEM benutzt.<br />
<br />
Wir lassen '''signal-cli''' unter dem Benutzer '''fhem''' laufen, abweichend von der Dokumentation auf GitHub. Das Home-Verzeichnis dieses Users ist bei mir '''/opt/fhem/home'''. Dies muss im Folgenden angepasst werden, wenn Du ein anderes Home-Verzeichnis für den Benutzer '''fhem''' hast.<br />
<br />
Was man alles mit dem Signal Messenger CLI machen kann, ist auf der o.g. Github-Seite beschrieben. <br />
<br />
== Installation von signal-cli ==<br />
<br />
Es werden die Pakete '''haveged''' und '''openjdk-9-jre-headless''' benötigt.<br />
<br />
haveged dient dazu, genügend Entropie für den Zufallszahlengenerator zu erzeugen. Das Java-9-Runtime-Environment bringt schon die unbeschränkten kryptographischen Funktionen vorkonfiguriert mit, die in älteren Version mühsam nachinstalliert werden müssten. Ältere Java-Versionen müssen zuvor deinstalliert werden.<br />
<br />
Als nächstes lädt man '''signal-cli-0.6.0.tar.gz''' von https://github.com/AsamK/signal-cli herunter. Im Abschnitt Installation der Beschreibung findet man einen Link zu den Binaries. Zum Zeitpunkt, an dem dieser Text verfasst wurde (12.11.2018) ist die aktuelle Version 0.6.0. Das Archiv wird ins Home-Verzeichnis von FHEM entpackt.<br />
<br />
Das folgende wird als Benutzer '''fhem''' ausgeführt, damit die Konfiguration im Home-Verzeichnis von '''fhem''' landet, und zwar in '''/opt/fhem/home/.config/signal'''.<br />
<br />
Man registriert man seine Festnetznummer (im Beispiel: +49xxxxxxxxxx) mittels '''signal-cli''' in einer Shell, um davon Signal-Nachrichten zu versenden:<br />
<br />
<source lang="bash">signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx register --voice</source><br />
<br />
Wenn alles in Ordnung ist, erhält man keine Rückmeldung. Wenn es lange dauert, hat man nicht genug Entropie. <br />
Kurz darauf erhält man einen Sprachanruf auf Englisch, mit dem einem der sechsstellige Registrierungscode yyyyyy mitgeteilt wird. Um die Registrierung abzuschließen, führt man<br />
<br />
<source lang="bash">signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx verify yyyyyy</source><br />
<br />
in der Shell aus. Wenn alles in Ordnung ist, erhält man keine Rückmeldung.<br />
<br />
Dann kann man Nachrichten an einen Signal Messenger auf dem Mobiltelefon mit der Nummer 49170zzzzzzzz mittels<br />
<br />
<source lang="bash">signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx send -m "Greetings from FHEM!" +49170zzzzzzzz</source><br />
<br />
senden. Wenn die Schlüssellänge bemängelt wird, hat man nicht die Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files installiert oder konfiguriert. Das sollte bei Java 9 aber nicht vorkommen.<br />
<br />
Ich hatte das Problem, dass die Sprachanrufe erst mit Stunden oder Tagen Verzögerung kamen (siehe [https://community.signalusers.org/t/call-verification-takes-forever/4479/11 Thread im Signal-Forum]). Dabei handelte es sich um einen vorübergehenden serverseitigen Fehler, der einige Tage bestand.<br />
<br />
Um bei Updates von '''signal-cli''' nicht die Pfade anpassen zu müssen, kann man noch im Home-Verzeichnis von '''fhem''' einen symbolischen Link anlegen:<br />
<br />
<source lang="bash">ln -s signal-cli-0.6.0 signal-cli</source><br />
<br />
== Einrichten der Kommunikation über DBus ==<br />
<br />
Es werden die Pakete '''libunixsocket-java''', '''dbus''' und '''dbus-x11''' benötigt.<br />
<br />
Es müssen als Benutzer '''root''' die folgenden Dateien angelegt werden:<br />
<br />
'''/etc/dbus-1/system.d/org.asamk.Signal.conf'''<br />
<br />
<pre><br />
<?xml version="1.0"?> <!--*-nxml-*--><br />
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"><br />
<br />
<busconfig><br />
<policy user="fhem"><br />
<allow own="org.asamk.Signal"/><br />
<allow send_destination="org.asamk.Signal"/><br />
<allow receive_sender="org.asamk.Signal"/><br />
</policy><br />
<br />
<policy context="default"><br />
<allow send_destination="org.asamk.Signal"/><br />
<allow receive_sender="org.asamk.Signal"/><br />
</policy><br />
</busconfig><br />
</pre><br />
<br />
'''/usr/share/dbus-1/system-services/org.asamk.Signal.service'''<br />
<br />
<pre><br />
[D-BUS Service]<br />
Name=org.asamk.Signal<br />
Exec=/bin/false<br />
SystemdService=dbus-org.asamk.Signal.service<br />
</pre><br />
<br />
'''/etc/systemd/system/signal.service'''<br />
<br />
<pre><br />
[Unit]<br />
Description=Send secure messages to Signal clients<br />
Requires=dbus.socket<br />
After=dbus.socket<br />
Wants=network-online.target<br />
After=network-online.target<br />
<br />
[Service]<br />
Type=dbus<br />
Environment="SIGNAL_CLI_OPTS=-Xms2m"<br />
ExecStart=/opt/fhem/signal-cli/bin/signal-cli -u +49xxxxxxxxxx --config /opt/fhem/home/.config/signal daemon --system<br />
User=fhem<br />
BusName=org.asamk.Signal<br />
<br />
[Install]<br />
Alias=dbus-org.asamk.Signal.service<br />
</pre><br />
<br />
Aktiviert wird das alles mit<br />
<br />
<source lang="bash"><br />
systemctl daemon-reload<br />
systemctl enable signal.service<br />
systemctl reload dbus.service<br />
</source><br />
<br />
Ob es funktioniert, kann man mit<br />
<source lang="bash">signal-cli/bin/signal-cli --dbus-system send -m "dbus working" +49170zzzzzzzz</source><br />
austesten.<br />
<br />
== Verwendung mit FHEM ==<br />
<br />
Es wird das Paket '''libnet-dbus-perl''' benötigt.<br />
<br />
Es wird das Modul '''32_SiSi.pm''' von [https://github.com/Quantum1337/32_SiSi.pm Quantum1337] verwendet. Am einfachsten wechselt man als Benutzer '''fhem''' ins Verzeichnis '''FHEM''' mit den Modulen und führt<br />
<br />
<source lang="bash">wget https://raw.githubusercontent.com/Quantum1337/32_SiSi.pm/master/FHEM/32_SiSi.pm</source><br />
<br />
aus. Die Datei sollte den richtigen Eigentümer haben. Bei mir sieht das so aus:<br />
<br />
<source>-rw-r--r-- 1 fhem dialout 29375 Nov 24 22:09 FHEM/32_SiSi.pm</source><br />
<br />
Idealerweise führt man jetzt noch <source lang="bash">/opt/fhem/contrib/commandref_join.pl</source> aus, um die Commandref zu regenerieren.<br />
<br />
Eine simple Definition in FHEM sieht so aus:<br />
<br />
<source><br />
define sisi SiSi<br />
attr sisi enable yes<br />
attr sisi defaultPeer +49170zzzzzzzz<br />
</source><br />
<br />
Du schickst eine Nachricht aus FHEM mit<br />
<br />
<source>set sisi msg Hurra, es funktioniert!</source><br />
<br />
<br />
<br />
<br />
[[Kategorie:Signal]]</div>Neuberthttp://wiki.fhem.de/w/index.php?title=SiSi&diff=28511SiSi2018-11-24T21:24:49Z<p>Neubert: </p>
<hr />
<div>Diese Seite beschreibt, wie man das Signal Messenger Command Line Interface (CLI) unter Raspbian installiert und mit FHEM benutzt.<br />
<br />
Wir lassen '''signal-cli''' unter dem Benutzer '''fhem''' laufen, abweichend von der Dokumentation auf GitHub. Das Home-Verzeichnis dieses Users ist bei mir '''/opt/fhem/home'''. Dies muss im Folgenden angepasst werden, wenn Du ein anderes Home-Verzeichnis für den Benutzer '''fhem''' hast.<br />
<br />
Was man alles mit dem Signal Messenger CLI machen kann, ist auf der o.g. Github-Seite beschrieben. <br />
<br />
== Installation von signal-cli ==<br />
<br />
Es werden die Pakete '''haveged''' und '''openjdk-9-jre-headless''' benötigt.<br />
<br />
haveged dient dazu, genügend Entropie für den Zufallszahlengenerator zu erzeugen. Das Java-9-Runtime-Environment bringt schon die unbeschränkten kryptographischen Funktionen vorkonfiguriert mit, die in älteren Version mühsam nachinstalliert werden müssten. Ältere Java-Versionen müssen zuvor deinstalliert werden.<br />
<br />
Als nächstes lädt man '''signal-cli-0.6.0.tar.gz''' von https://github.com/AsamK/signal-cli herunter. Im Abschnitt Installation der Beschreibung findet man einen Link zu den Binaries. Zum Zeitpunkt, an dem dieser Text verfasst wurde (12.11.2018) ist die aktuelle Version 0.6.0. Das Archiv wird ins Home-Verzeichnis von FHEM entpackt.<br />
<br />
Das folgende wird als Benutzer '''fhem''' ausgeführt, damit die Konfiguration im Home-Verzeichnis von '''fhem''' landet, und zwar in '''/opt/fhem/home/.config/signal'''.<br />
<br />
Man registriert man seine Festnetznummer (im Beispiel: +49xxxxxxxxxx) mittels '''signal-cli''' in einer Shell, um davon Signal-Nachrichten zu versenden:<br />
<br />
<source lang="bash">signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx register --voice</source><br />
<br />
Wenn alles in Ordnung ist, erhält man keine Rückmeldung. Wenn es lange dauert, hat man nicht genug Entropie. <br />
Kurz darauf erhält man einen Sprachanruf auf Englisch, mit dem einem der sechsstellige Registrierungscode yyyyyy mitgeteilt wird. Um die Registrierung abzuschließen, führt man<br />
<br />
<source lang="bash">signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx verify yyyyyy</source><br />
<br />
in der Shell aus. Wenn alles in Ordnung ist, erhält man keine Rückmeldung.<br />
<br />
Dann kann man Nachrichten an einen Signal Messenger auf dem Mobiltelefon mit der Nummer 49170zzzzzzzz mittels<br />
<br />
<source lang="bash">signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx send -m "Greetings from FHEM!" +49170zzzzzzzz</source><br />
<br />
senden. Wenn die Schlüssellänge bemängelt wird, hat man nicht die Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files installiert oder konfiguriert. Das sollte bei Java 9 aber nicht vorkommen.<br />
<br />
Ich hatte das Problem, dass die Sprachanrufe erst mit Stunden oder Tagen Verzögerung kamen (siehe [https://community.signalusers.org/t/call-verification-takes-forever/4479/11 Thread im Signal-Forum]). Dabei handelte es sich um einen vorübergehenden serverseitigen Fehler, der einige Tage bestand.<br />
<br />
Um bei Updates von '''signal-cli''' nicht die Pfade anpassen zu müssen, kann man noch im Home-Verzeichnis von '''fhem''' einen symbolischen Link anlegen:<br />
<br />
<source lang="bash">ln -s signal-cli-0.6.0 signal-cli</source><br />
<br />
== Einrichten der Kommunikation über DBus ==<br />
<br />
Es werden die Pakete '''libunixsocket-java''', '''dbus''' und '''dbus-x11''' benötigt.<br />
<br />
Es müssen als Benutzer '''root''' die folgenden Dateien angelegt werden:<br />
<br />
'''/etc/dbus-1/system.d/org.asamk.Signal.conf'''<br />
<br />
<pre><br />
<?xml version="1.0"?> <!--*-nxml-*--><br />
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"><br />
<br />
<busconfig><br />
<policy user="fhem"><br />
<allow own="org.asamk.Signal"/><br />
<allow send_destination="org.asamk.Signal"/><br />
<allow receive_sender="org.asamk.Signal"/><br />
</policy><br />
<br />
<policy context="default"><br />
<allow send_destination="org.asamk.Signal"/><br />
<allow receive_sender="org.asamk.Signal"/><br />
</policy><br />
</busconfig><br />
</pre><br />
<br />
'''/usr/share/dbus-1/system-services/org.asamk.Signal.service'''<br />
<br />
<pre><br />
[D-BUS Service]<br />
Name=org.asamk.Signal<br />
Exec=/bin/false<br />
SystemdService=dbus-org.asamk.Signal.service<br />
</pre><br />
<br />
'''/etc/systemd/system/signal.service'''<br />
<br />
<pre><br />
[Unit]<br />
Description=Send secure messages to Signal clients<br />
Requires=dbus.socket<br />
After=dbus.socket<br />
Wants=network-online.target<br />
After=network-online.target<br />
<br />
[Service]<br />
Type=dbus<br />
Environment="SIGNAL_CLI_OPTS=-Xms2m"<br />
ExecStart=/opt/fhem/signal-cli/bin/signal-cli -u +49xxxxxxxxxx --config /opt/fhem/home/.config/signal daemon --system<br />
User=fhem<br />
BusName=org.asamk.Signal<br />
<br />
[Install]<br />
Alias=dbus-org.asamk.Signal.service<br />
</pre><br />
<br />
Aktiviert wird das alles mit<br />
<br />
<source lang="bash"><br />
systemctl daemon-reload<br />
systemctl enable signal.service<br />
systemctl reload dbus.service<br />
</source><br />
<br />
Ob es funktioniert, kann man mit<br />
<source lang="bash">signal-cli/bin/signal-cli --dbus-system send -m "dbus working" +49170zzzzzzzz</source><br />
austesten.<br />
<br />
== Verwendung mit FHEM ==<br />
<br />
Es wird das Paket '''libnet-dbus-perl''' benötigt.<br />
<br />
Es wird das Modul '''32_SiSi.pm'' von https://github.com/Quantum1337/32_SiSi.pm verwendet. Am einfachsten wechselt man als Benutzer '''fhem''' ins Verzeichnis '''FHEM''' mit den Modulen und führt<br />
<br />
<source lang="bash">wget https://raw.githubusercontent.com/Quantum1337/32_SiSi.pm/master/FHEM/32_SiSi.pm</source><br />
<br />
aus. Die Datei sollte den richtigen Eigentümer haben. Bei mir sieht das so aus:<br />
<br />
<source>-rw-r--r-- 1 fhem dialout 29375 Nov 24 22:09 FHEM/32_SiSi.pm</source><br />
<br />
Idealerweise führt man jetzt noch <source lang="bash">/opt/fhem/contrib/commandref_join.pl</source> aus, um die Commandref zu regenerieren.<br />
<br />
Eine simple Definition in FHEM sieht so aus:<br />
<br />
<source><br />
define sisi SiSi<br />
attr sisi enable yes<br />
attr sisi defaultPeer +49170zzzzzzzz<br />
</source><br />
<br />
Du schickst eine Nachricht aus FHEM mit<br />
<br />
<source>set sisi msg Hurra, es funktioniert!</source><br />
<br />
<br />
<br />
<br />
[[Kategorie:Signal]]</div>Neuberthttp://wiki.fhem.de/w/index.php?title=SiSi&diff=28510SiSi2018-11-24T21:05:59Z<p>Neubert: </p>
<hr />
<div>Diese Seite beschreibt, wie man das Signal Messenger Command Line Interface (CLI) unter Raspbian installiert.<br />
<br />
Wir lassen '''signal-cli''' unter dem Benutzer '''fhem''' laufen, abweichend von der Dokumentation auf GitHub. Das Home-Verzeichnis dieses Users ist bei mir '''/opt/fhem/home'''. Dies muss im Folgenden angepasst werden, wenn Du ein anderes Home-Verzeichnis für den Benutzer '''fhem''' hast.<br />
<br />
Was man alles mit dem Signal Messenger CLI machen kann, ist auf der o.g. Github-Seite beschrieben. Sobald ich Signal in FHEM eingebunden habe, wird diese Anleitung erweitert.<br />
<br />
== Installation von signal-cli ==<br />
<br />
Es werden die Pakete '''haveged''' und '''openjdk-9-jre-headless''' benötigt.<br />
<br />
haveged dient dazu, genügend Entropie für den Zufallszahlengenerator zu erzeugen. Das Java-9-Runtime-Environment bringt schon die unbeschränkten kryptographischen Funktionen vorkonfiguriert mit, die in älteren Version mühsam nachinstalliert werden müssten. Ältere Java-Versionen müssen zuvor deinstalliert werden.<br />
<br />
Als nächstes lädt man '''signal-cli-0.6.0.tar.gz''' von https://github.com/AsamK/signal-cli herunter. Im Abschnitt Installation der Beschreibung findet man einen Link zu den Binaries. Zum Zeitpunkt, an dem dieser Text verfasst wurde (12.11.2018) ist die aktuelle Version 0.6.0. Das Archiv wird ins Home-Verzeichnis von FHEM entpackt.<br />
<br />
Das folgende wird als Benutzer '''fhem''' ausgeführt, damit die Konfiguration im Home-Verzeichnis von '''fhem''' landet, und zwar in '''/opt/fhem/home/.config/signal'''.<br />
<br />
Man registriert man seine Festnetznummer (im Beispiel: +49xxxxxxxxxx) mittels '''signal-cli''' in einer Shell, um davon Signal-Nachrichten zu versenden:<br />
<br />
<source lang="bash">signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx register --voice</source><br />
<br />
Wenn alles in Ordnung ist, erhält man keine Rückmeldung. Wenn es lange dauert, hat man nicht genug Entropie. <br />
Kurz darauf erhält man einen Sprachanruf auf Englisch, mit dem einem der sechsstellige Registrierungscode yyyyyy mitgeteilt wird. Um die Registrierung abzuschließen, führt man<br />
<br />
<source lang="bash">signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx verify yyyyyy</source><br />
<br />
in der Shell aus. Wenn alles in Ordnung ist, erhält man keine Rückmeldung.<br />
<br />
Dann kann man Nachrichten an einen Signal Messenger auf dem Mobiltelefon mit der Nummer 49170zzzzzzzz mittels<br />
<br />
<source lang="bash">signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx send -m "Greetings from FHEM!" +49170zzzzzzzz</source><br />
<br />
senden. Wenn die Schlüssellänge bemängelt wird, hat man nicht die Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files installiert oder konfiguriert. Das sollte bei Java 9 aber nicht vorkommen.<br />
<br />
Ich hatte das Problem, dass die Sprachanrufe erst mit Stunden oder Tagen Verzögerung kamen (siehe [https://community.signalusers.org/t/call-verification-takes-forever/4479/11 Thread im Signal-Forum]). Dabei handelte es sich um einen vorübergehenden serverseitigen Fehler, der einige Tage bestand.<br />
<br />
Um bei Updates von '''signal-cli''' nicht die Pfade anpassen zu müssen, kann man noch im Home-Verzeichnis von '''fhem''' einen symbolischen Link anlegen:<br />
<br />
<source lang="bash">ln -s signal-cli-0.6.0 signal-cli</source><br />
<br />
<br />
== Einrichten der Kommunikation über DBus ==<br />
<br />
Es werden die Pakete '''libunixsocket-java''', '''dbus''' und '''dbus-x11''' benötigt.<br />
<br />
Es müssen als Benutzer '''root''' die folgenden Dateien angelegt werden:<br />
<br />
'''/etc/dbus-1/system.d/org.asamk.Signal.conf'''<br />
<br />
<pre><br />
<?xml version="1.0"?> <!--*-nxml-*--><br />
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"><br />
<br />
<busconfig><br />
<policy user="fhem"><br />
<allow own="org.asamk.Signal"/><br />
<allow send_destination="org.asamk.Signal"/><br />
<allow receive_sender="org.asamk.Signal"/><br />
</policy><br />
<br />
<policy context="default"><br />
<allow send_destination="org.asamk.Signal"/><br />
<allow receive_sender="org.asamk.Signal"/><br />
</policy><br />
</busconfig><br />
</pre><br />
<br />
'''/usr/share/dbus-1/system-services/org.asamk.Signal.service'''<br />
<br />
<pre><br />
[D-BUS Service]<br />
Name=org.asamk.Signal<br />
Exec=/bin/false<br />
SystemdService=dbus-org.asamk.Signal.service<br />
</pre><br />
<br />
'''/etc/systemd/system/signal.service'''<br />
<br />
<pre><br />
[Unit]<br />
Description=Send secure messages to Signal clients<br />
Requires=dbus.socket<br />
After=dbus.socket<br />
Wants=network-online.target<br />
After=network-online.target<br />
<br />
[Service]<br />
Type=dbus<br />
Environment="SIGNAL_CLI_OPTS=-Xms2m"<br />
ExecStart=/opt/fhem/signal-cli/bin/signal-cli -u +49xxxxxxxxxx --config /opt/fhem/home/.config/signal daemon --system<br />
User=fhem<br />
BusName=org.asamk.Signal<br />
<br />
[Install]<br />
Alias=dbus-org.asamk.Signal.service<br />
</pre><br />
<br />
Aktiviert wird das alles mit<br />
<br />
<source lang="bash"><br />
systemctl daemon-reload<br />
systemctl enable signal.service<br />
systemctl reload dbus.service<br />
</source><br />
<br />
Ob es funktioniert, kann man mit<br />
<source lang="bash">signal-cli/bin/signal-cli --dbus-system send -m "dbus working" +49170zzzzzzzz</source><br />
austesten.<br />
<br />
<br />
<br />
[[Kategorie:Signal]]</div>Neuberthttp://wiki.fhem.de/w/index.php?title=SiSi&diff=28301SiSi2018-11-12T20:17:48Z<p>Neubert: </p>
<hr />
<div>Diese Seite beschreibt, wie man das Signal Messenger Command Line Interface (CLI) unter Raspbian installiert.<br />
<br />
Es werden die Pakete '''haveged''' und '''openjdk-9-jre-headless''' benötigt.<br />
<br />
haveged dient dazu, genügend Entropie für den Zufallszahlengenerator zu erzeugen. Das Java-9-Runtime-Environment bringt schon die unbeschränkten kryptographischen Funktionen vorkonfiguriert mit, die in älteren Version mühsam nachinstalliert werden müssten. Ältere Java-Versionen müssen zuvor deinstalliert werden.<br />
<br />
Als nächstes lädt man '''signal-cli-0.6.0.tar.gz''' von https://github.com/AsamK/signal-cli herunter. Im Abschnitt Installation der Beschreibung findet man einen Link zu den Binaries. Zum Zeitpunkt, an dem dieser Text verfasst wurde (12.11.2018) ist die aktuelle Version 0.6.0. Das Archiv wird ins Home-Verzeichnis von FHEM entpackt.<br />
<br />
Nun registriert man seine Festnetznummer (im Beispiel: +49xxxxxxxxxx) mittels '''signal-cli''' in einer Shell, um davon Signal-Nachrichten zu versenden:<br />
<br />
<source lang="bash">signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx register --voice</source><br />
<br />
Wenn alles in Ordnung ist, erhält man keine Rückmeldung. Wenn es lange dauert, hat man nicht genug Entropie. <br />
Kurz darauf erhält man einen Sprachanruf auf Englisch, mit dem einem der sechsstellige Registrierungscode yyyyyy mitgeteilt wird. Um die Registrierung abzuschließen, führt man<br />
<br />
<source lang="bash">signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx verify yyyyyy</source><br />
<br />
in der Shell aus. Wenn alles in Ordnung ist, erhält man keine Rückmeldung.<br />
<br />
Dann kann man Nachrichten an einen Signal Messenger auf dem Mobiltelefon mit der Nummer 49170zzzzzzzz mittels<br />
<br />
<source lang="bash">signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx send -m "Greetings from FHEM!" +49170zzzzzzzz</source><br />
<br />
senden. Wenn die Schlüssellänge bemängelt wird, hat man nicht die Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files installiert oder konfiguriert. Das sollte bei Java 9 aber nicht vorkommen.<br />
<br />
Ich hatte das Problem, dass die Sprachanrufe erst mit Stunden oder Tagen Verzögerung kamen (siehe [https://community.signalusers.org/t/call-verification-takes-forever/4479/11 Thread im Signal-Forum]). Dabei handelte es sich um einen vorübergehenden serverseitigen Fehler, der einige Tage bestand.<br />
<br />
Was man alles mit dem Signal Messenger CLI machen kann, ist auf der o.g. Github-Seite beschrieben. Sobald ich Signal in FHEM eingebunden habe, wird diese Anleitung erweitert.</div>Neuberthttp://wiki.fhem.de/w/index.php?title=SiSi&diff=28300SiSi2018-11-12T18:41:34Z<p>Neubert: Die Seite wurde neu angelegt: „Diese Seite beschreibt, wie man das Signal Messenger Command Line Interface (CLI) unter Raspbian installiert. Es werden die Pakete haveged und openjdk-9-jre-h…“</p>
<hr />
<div>Diese Seite beschreibt, wie man das Signal Messenger Command Line Interface (CLI) unter Raspbian installiert.<br />
<br />
Es werden die Pakete haveged und openjdk-9-jre-headless benötigt.<br />
<br />
haveged dient dazu, genügend Entropie für den Zufallszahlengenerator zu erzeugen. Das Java-9-Runtime-Environment bringt schon die unbeschränkten kryptographischen Funktionen vorkonfiguriert mit, die in älteren Version mühsam nachinstalliert werden müssten. Ältere Java-Versionen müssen zuvor deinstalliert werden.<br />
<br />
Als nächstes lädt man signal-cli-0.6.0.tar.gz von https://github.com/AsamK/signal-cli herunter. Im Abschnitt Installation der Beschreibung findet man einen Link zu den Binaries. Zum Zeitpunkt, an dem dieser Text verfasst wurde (12.11.2018) ist die aktuelle Version 0.6.0. Das Archiv wird ins Home-Verzeichnis von FHEM entpackt.<br />
<br />
Nun registriert man seine Festnetznummer (im Beispiel: +49xxxxxxxxxx) mittels signal-cli in einer Shell, um davon Signal-Nachrichten zu versenden:<br />
<br />
signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx register --voice<br />
<br />
Wenn alles in Ordnung ist, erhält man keine Rückmeldung. Wenn es lange dauert, hat man nicht genug Entropie. <br />
Kurz darauf erhält man einen Sprachanruf auf Englisch, mit dem einem der sechsstellige Registrierungscode yyyyyy mitgeteilt wird. Um die Registrierung abzuschließen, führt man<br />
<br />
signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx verify yyyyyy<br />
<br />
in der Shell aus. Wenn alles in Ordnung ist, erhält man keine Rückmeldung.<br />
<br />
Dann kann man Nachrichten an einen Signal Messenger auf dem Mobiltelefon mit der Nummer 49170zzzzzzzz mittels<br />
<br />
signal-cli-0.6.0/bin/signal-cli -u +49xxxxxxxxxx send -m "Greetings from FHEM!" +49170zzzzzzzz<br />
<br />
senden. Wenn die Schlüssellänge bemängelt wird, hat man nicht die Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files installiert oder konfiguriert. Das sollte bei Java 9 aber nicht vorkommen.<br />
<br />
Ich hatte das Problem, dass die Sprachanrufe erst mit Stunden oder Tagen Verzögerung kamen (siehe [https://community.signalusers.org/t/call-verification-takes-forever/4479/11 Thread im Signal-Forum]). Dabei handelte es sich um einen vorübergehenden serverseitigen Fehler, der einige Tage bestand.<br />
<br />
Was man alles mit dem Signal Messenger CLI machen kann, ist auf der o.g. Github-Seite beschrieben. Sobald ich Signal in FHEM eingebunden habe, wird diese Anleitung erweitert.</div>Neuberthttp://wiki.fhem.de/w/index.php?title=DevelopmentUpdate&diff=26193DevelopmentUpdate2018-03-22T17:19:34Z<p>Neubert: </p>
<hr />
<div>== Updatemechanismus ==<br />
<br />
'''Diese Seite ist frisch dem Ei entschlüpft und noch nicht qualitätsgesichert.'''<br />
<br />
Wenn der Benutzer den FHEM-Befehl update in seiner FHEM-Installation aufruft, werden aus allen Repositories, die er für Updates registriert hat, aktualisierte Dateien heruntergeladen. Dieser Artikel beschreibt den Mechanismus hinter der Bereitstellung des Updates aus dem zentralen FHEM-Repository.<br />
<br />
Jeden Tag um X:00 Uhr wird auf dem FHEM-Updateserver fhemupdate.pl (siehe contrib) ausgeführt. Ab diesem Zeitpunkt kann ein Benutzer von FHEM die zu diesem Zeitpunkt neuesten Dateien per update-Befehl beziehen. Abends in SVN-Repository eingecheckte Dateien stehen damit am nächsten Morgen per Update zur Verfügung.<br />
<br />
fhemupdate.pl stellt im SVN-Repository neue und geänderte Dateien aus FHEM, FHEM/lib sowie einige weitere Dateien von FHEM sowie CUL-Firmware für das Update bereit. Die Liste der Dateien steht am Anfang von contrib/fhemupdate.pl. Insbesondere werden außer den Dateien zur Erzeugung der commandref keine Dateien aus contrib über update verteilt.<br />
<br />
Ohne weiteres Zutun löscht das Update keine Dateien in der Installation des Users, wenn diese im SVN-Repository fehlen, und liefert auch keine neuen Verzeichnisse und darin enthaltene Dateien aus.<br />
<br />
fhemupdate.pl wird von Rudolf König gepflegt. Ein Entwickler, der neue Verzeichnisse und deren Inhalte über Update verteilen möchte oder Dateien in den Benutzerinstallationen per Update löschen lassen möchte, stellt diesen Wunsch zunächst im [https://forum.fhem.de/index.php/board,48.0.html Forum im Board FHEM Development] zur Diskussion. Hintergrund ist es, die Entwicklung in geordnete Bahnen zu lenken. Da es in der Natur von FHEM liegt, mit unterschiedlichen Systemen zu kommunizieren, wird es nur natürlich sein, dass immer mehr Fremdpakete in FHEM abgelegt werden sollen.<br />
Es soll einerseits den Anwendern das Leben leicht gemacht werden, andererseits soll aber FHEM weder den Paketmanager des Systems ersetzen noch als Repository für Fremdsoftware dienen.<br />
<br />
<br />
[[Kategorie:Development]]</div>Neuberthttp://wiki.fhem.de/w/index.php?title=DevelopmentUpdate&diff=26192DevelopmentUpdate2018-03-22T17:18:45Z<p>Neubert: Die Seite wurde neu angelegt: „== Updatemechanismus == '''Diese Seite ist frisch dem Ei entschlüpft und noch nicht qualitätsgesichert.''' Wenn der Benutzer den FHEM-Befehl update in sein…“</p>
<hr />
<div>== Updatemechanismus ==<br />
<br />
'''Diese Seite ist frisch dem Ei entschlüpft und noch nicht qualitätsgesichert.'''<br />
<br />
Wenn der Benutzer den FHEM-Befehl update in seiner FHEM-Installation aufruft, werden aus allen Repositories, die er für Updates registriert hat, aktualisierte Dateien heruntergeladen. Dieser Artikel beschreibt den Mechanismus hinter der Bereitstellung des Updates aus dem zentralen FHEM-Repository.<br />
<br />
Jeden Tag um X:00 Uhr wird auf dem FHEM-Updateserver fhemupdate.pl (siehe contrib) ausgeführt. Ab diesem Zeitpunkt kann ein Benutzer von FHEM die zu diesem Zeitpunkt neuesten Dateien per update-Befehl beziehen. Abends in SVN-Repository eingecheckte Dateien stehen damit am nächsten Morgen per Update zur Verfügung.<br />
<br />
fhemupdate.pl stellt im SVN-Repository neue und geänderte Dateien aus FHEM, FHEM/lib sowie einige weitere Dateien von FHEM sowie CUL-Firmware für das Update bereit. Die Liste der Dateien steht am Anfang von contrib/fhemupdate.pl. Insbesondere werden außer den Dateien zur Erzeugung der commandref keine Dateien aus contrib über update verteilt.<br />
<br />
Ohne weiteres Zutun löscht das Update keine Dateien in der Installation des Users, wenn diese im SVN-Repository fehlen, und liefert auch keine neuen Verzeichnisse und darin enthaltene Dateien aus.<br />
<br />
fhemupdate.pl wird von Rudolf König gepflegt. Ein Entwickler, der neue Verzeichnisse und deren Inhalte über Update verteilen möchte oder Dateien in den Benutzerinstallationen per Update löschen lassen möchte, stellt diesen Wunsch zunächst im [https://forum.fhem.de/index.php/board,48.0.html Forum im Board FHEM Development] zur Diskussion. Hintergrund ist es, die Entwicklung in geordnete Bahnen zu lenken. Da es in der Natur von FHEM liegt, mit unterschiedlichen Systemen zu kommunizieren, wird es nur natürlich sein, dass immer mehr Fremdpakete in FHEM abgelegt werden sollen.<br />
Es soll einerseits den Anwendern das Leben leicht gemacht werden, andererseits soll aber FHEM weder den Paketmanager des Systems ersetzen noch als Repository für Fremdsoftware dienen.</div>Neuberthttp://wiki.fhem.de/w/index.php?title=OWServer_%26_OWDevice&diff=11261OWServer & OWDevice2015-05-14T12:03:15Z<p>Neubert: </p>
<hr />
<div><br />
<br />
==Einleitung==<br />
<br />
Bei OWServer handelt es sich um eine 1-Wire Server Komponente und bei OWDevice um eine Geräte-Komponente, die die angeschlossenen Module definiert-<br />
Die Module benötigen die Serverkomponente von [http://www.owfs.org OWFS].<br />
<br />
<br />
'''Wichtig:'''<br />
<br />
Die Module sind eine eigenständige Möglichkeit, den 1-Wire Bus anzusteuern und kommen ohne die Module aus, deren Namen aus Großbuchstaben bestehen (wie OWX, OWSWITCH, OWTHERM, etc.). <br />
Umgekehrt können die Module OWSWITCH, OWTHERM, etc. auch mit dem Backendmodul OWServer zusammenarbeiten, siehe dazu die commandref der betreffenden Module.<br />
<br />
<br />
<br />
==Vorbereitung==<br />
<br />
Wie oben erwähnt, setzt OWServer/OWDevice auf OWFS auf. Dazu ist eine funktionierende OWFS Installation notwendig. Die Installation ist auf der selben Plattform (Debian-based) möglich oder auch Remote (zBsp Dockstar oder RPi). Eine gute [http://owfs.org/index.php?page=standard-devices Liste der Standard Devices]auf der Homepage von OWFS einzusehen. Nicht alle Standard Devices sind in OWDevice verfügbar (siehe unten).Wenn OWFS funktioniert kann's weiter gehen...<br />
<br />
<br />
===owfs Pakete installieren===<br />
<br />
1) entweder sind die Pakete bereits vorpaketiert und man muss nur das [http://owfs.davromaniak.eu/ Repository] noch in /etc/apt/sources.list eintragen<br />
<br />
2) oder man muss selber kompilieren ([http://www.navitron.org.uk/forum/index.php?topic=12604.msg151750#msg151750 Quelle]). <br />
Für den RaspberryPi wurde dies schon durchgeführt: [http://forum.fhem.de/index.php?action=dlattach;topic=12219.0;attach=2463 owfs_2.8p17-1_all.zip]<br />
<br />
<nowiki>sudo apt-get install automake autoconf autotools-dev gcc g++ libtool libusb-dev fuse-utils libfuse-dev swig python-dev tcl-dev php5-dev<br />
sudo apt-get install git git-buildpackage dh-make quilt php5-cli<br />
git clone [git://git.debian.org/collab-maint/owfs.git git://git.debian.org/collab-maint/owfs.git] git<br />
git-buildpackage -uc -us<br />
cd ..<br />
sudo dpkg -i ./owserver_2.8p7+cvs20110310-1_i386.deb ./libow-2.8-7_2.8p7+cvs20110310-1_i386.deb ./owfs-common_2.8p7+cvs20110310-1_all.deb<br />
sudo dpkg -i ./owhttpd_2.8p7+cvs20110310-1_i386.deb</nowiki><br />
diese Pakete werden alle gebaut:<br />
<br />
<nowiki>libow-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-common_2.8p7+cvs20110310-1_all.deb<br />
libowcapi-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-dbg_2.8p7+cvs20110310-1_i386.deb<br />
libow-dev_2.8p7+cvs20110310-1_i386.deb owfs-doc_2.8p7+cvs20110310-1_all.deb<br />
libownet-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-fuse_2.8p7+cvs20110310-1_i386.deb<br />
libownet-dev_2.8p7+cvs20110310-1_i386.deb owftpd_2.8p7+cvs20110310-1_i386.deb<br />
libownet-perl_2.8p7+cvs20110310-1_all.deb owhttpd_2.8p7+cvs20110310-1_i386.deb<br />
libownet-php_2.8p7+cvs20110310-1_all.deb owserver_2.8p7+cvs20110310-1_i386.deb<br />
libow-perl_2.8p7+cvs20110310-1_i386.deb ow-shell_2.8p7+cvs20110310-1_i386.deb<br />
libow-php5_2.8p7+cvs20110310-1_i386.deb python-ow_2.8p7+cvs20110310-1_i386.deb<br />
libow-tcl_2.8p7+cvs20110310-1_i386.deb python-ownet_2.8p7+cvs20110310-1_all.deb<br />
owfs_2.8p7+cvs20110310-1_all.deb</nowiki><br />
<br />
3) In aktuellen Versionen von Raspbian sind die notwendigen Pakete schon in den konfigurierten Quellen vorhanden. Es reicht ein<br />
<br />
<pre>sudo apt-get install owserver ow-shell owhttpd owftpd</pre><br />
<br />
===Unterstütze Geräte===<br />
Eine aktuelle Liste der von OWDevice unterstützen Geräte findet man im [http://fhem.de/commandref.html#OWDevice FHEM-Commandref].<br />
<br />
<br />
==Konfiguration von owserver==<br />
<br />
Folgendes ist eine beispielhafte Konfiguration für OWFS mit einem am USB-Port angeschlossenen [http://denkovi.com/usb-to-one-wire-interface-adaptor-converter-thermometer Denkovi-Adapter] (Klon von DS9097U).<br />
<br />
Es ist praktisch, dem Adapter ein festes Device zuzuordnen. Dazu legt man in /etc/udev/rules.d/ eine Datei 11-onewire.rules mit folgendem Inhalt an:<br />
<br />
<nowiki>ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="DAE001nq", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", SYMLINK+="onewire"<br />
</nowiki><br />
<br />
Nach dem Einstöpseln des USB-Kabels vom Adapter wird über die Seriennummer DAE001nq des USB-Wandlers auf dem Adapter das Gerät erkannt und der Symlink /dev/onewire auf das eigentliche USB-Gerät (z.B. /dev/ttyUSB1) erstellt.<br />
<br />
Eine Minimalkonfiguration für /etc/owfs.conf ist<br />
<br />
<pre>server: device = /dev/onewire<br />
http: port = 2121<br />
ftp: port = 2120<br />
server: port = 4304<br />
</pre><br />
<br />
Es ist sinnvoll, owhttpd installiert und laufen zu haben, um über die URL http://deinRaspberryPi:2121 zu sehen, dass owserver läuft und die Geräte am 1-wire-Bus erkennt.<br />
<br />
==Konfiguration in FHEM==<br />
Als erstes definiert man OWServer. Hiermit wird ein logischer OWServer definiert, auf welchem OWFS installiert ist<br />
<br />
<nowiki>define &lt;name&gt; OWServer &lt;protocol&gt;</nowiki><br />
&lt;protocol&gt; hat das Format &lt;hostname&gt;:&lt;port&gt;.<br />
<br />
zBsp:<br />
<br />
<nowiki>define myOWServer OWServer 192.168.14.100:4304</nowiki><br />
oder wenn sich OWFS auf dem gleichen Server befindet wie FHEM:<br />
<br />
<nowiki>define myOWServer OWServer localhost:4304</nowiki><br />
Nach erfolgreichem "define" ist ein Klick auf den "Save" Button notwenig. Wenn nun der Status von myOWServer auf "Initialized" steht, ist der Server verbunden. Um sicher zu sein, dass der OWServer funktioniert, kann eine manuelle Abfrage der Device durchgeführt werden mit:<br />
<br />
<nowiki>get myOWServer devices</nowiki><br />
Danach werden sämtliche angeschlossene Geräte angezeigt, inkl. Busmaster<br />
<br />
===OWServer Set Befehle===<br />
<nowiki>set &lt;name&gt; &lt;value&gt;<br />
value:<br />
timeout/directory<br />
timeout/ftp<br />
timeout/ha7<br />
timeout/network<br />
timeout/presence<br />
timeout/serial<br />
timeout/server<br />
timeout/stable<br />
timeout/uncached<br />
timeout/usb<br />
timeout/volatile<br />
timeout/w1<br />
units/pressure_scale<br />
units/temperature_scale</nowiki><br />
Weitere Informationen zu den Set Befehlen sind im [http://owfs.org/uploads/owserver.1.html#sect41 OWServer Manual] zu entnehmen.<br />
<br />
===OWServer Get Befehle===<br />
<nowiki>get &lt;name&gt; &lt;value&gt;<br />
value:<br />
/settings/timeout/directory<br />
/settings/timeout/ftp<br />
/settings/timeout/ha7<br />
/settings/timeout/network<br />
/settings/timeout/presence<br />
/settings/timeout/serial<br />
/settings/timeout/server<br />
/settings/timeout/stable<br />
/settings/timeout/uncached<br />
/settings/timeout/usb<br />
/settings/timeout/volatile<br />
/settings/timeout/w1<br />
/settings/units/pressure_scale<br />
/settings/units/temperature_scale</nowiki><br />
Zusätzlich stehen die FHEM-internen Befehle "errors" und "devices" zur Verfügung.<br />
zBsp:<br />
<br />
<nowiki>get &lt;Devicename&gt; errors #listet die Fehler des Device auf<br />
get &lt;Devicename&gt; devices #scan den Server nach Device</nowiki><br />
<br />
===Angeschlossene Geräte auslesen===<br />
Grundsätzlich werden die am Busmaster von OWFS angeschlossenen 1-Wire Geräte durch aktives autocreate nach einem Neustart (erfordert shutdown restart) selber in FHEM definiert.<br />
Der Busmaster (zBsp ein DS9490r) selbst wird ebenfalls eingelesen und angezeigt.<br />
<br />
===Definition von Geräten===<br />
Es ist auch möglich, Geräte manuell anzulegen. Dies erfolgt in folgendem Format:<br />
<br />
<nowiki>define &lt;name&gt; OWDevice &lt;address&gt; [&lt;interval&gt;]</nowiki><br />
zBsp:<br />
<br />
<nowiki>define Vorlauftemp OWDevice 28.334F2B040000 60</nowiki><br />
Wobei der Wert 60 als Abfrageintervall in Sekunden zu verstehen ist.<br />
<br />
<br />
===OWDevice State===<br />
Bei Temperaturfühler wie DS18S20 wird das Reading "state" wie folgt ausgegeben:<br />
<br />
<nowiki>temperature: 56.1875 alarm: 1</nowiki><br />
Um die Temperatur wie bei anderen Temperatur-Sensoren (zBsp. CUL_WS) anzuzeigen, hilft das Attribut "stateFormat". Dies kann wie folgt definiert werden:<br />
<br />
<nowiki>attr &lt;Devicename&gt; stateFormat T: &lt;wert&gt;</nowiki><br />
zBsp:<br />
<br />
<nowiki>attr Boiler stateFormat T: temperature</nowiki><br />
alternativ<br />
<br />
<nowiki>attr &lt;Devicename&gt; stateFormat {sprintf("%.1f",ReadingsVal("&lt;Devicename&gt;","temperature",0))."°C"}</nowiki><br />
Zusätzlich rundet das obenstehende Attribut mit "%.1f" die Temperatur auf eine Kommastelle.<br />
<br />
==Tipps und Tricks==<br />
1-wire-Geräte sind häufig generische Geräte, wie Zähler und Spannungsmesser (A/D-Wandler), an denen Sensorik hängt. Die rohen Werte vom 1-wire-Gerät (Zählimpulse, Spannungen) sind dann noch in menschenlesbare Werte zu verwandeln. Hier helfen userReadings, z.B.<br />
<br />
<nowiki>attr myEnergyMeter userReadings energy { (ReadingsVal("myEnergyMeter","count.A",0)+AttrVal("myEnergyMeter","myBasis",0))/1250.0;; }</nowiki><br />
<br />
==Anwendungsbeispiele==<br />
[[Stromzähler_und_1-Wire,_OWServer,_OWDevice|Hier]] findet man ein Beispiel einer Anbindung zweier Leistungsmesser (aka Stromzähler) mit S0 Ausgang über einen 1-wire-S0-Zähler an FHEM. <br />
<br />
== Bekannte Probleme ==<br />
=== Fhem hängt, wenn OWServer nicht erreichbar ist ===<br />
Am Anfang gab es mit OWServer das Problem, dass Fhem immer komplett hing, wenn OWServer nicht erreichbar war (siehe z.&nbsp;B. [http://www.fischer-net.de/hausautomation/haustechnik/1-wire/60-1-wire-integration-in-fhem.html hier am Ende]). Das Problem wurde inzwischen dankenswerterweise für den laufenden Betrieb {{Link2Forum|Topic=16945|LinkText=behoben}} - <code>attr myOWServer nonblocking 1</code> muss dazu gesetzt werden -, aber zumindest beim Start hängt Fhem nach wie vor, wenn OWServer nicht erreichbar ist.<br />
<br />
[[Kategorie:1-Wire]]</div>Neuberthttp://wiki.fhem.de/w/index.php?title=DevelopmentReadingsAPI&diff=8557DevelopmentReadingsAPI2014-11-22T08:18:40Z<p>Neubert: </p>
<hr />
<div>[[Kategorie:Development]]<br />
<br />
== Abstract ==<br />
<br />
Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand der Diskussion. <br />
<br />
Ausgangspunkt ist [http://forum.fhem.de/index.php/topic,21247.0.html dieser Thread].<br />
<br />
== Ausgangssituation ==<br />
<br />
In FHEM besitzen Geräte sogenannte Readings (Anzeigewerte). Diese bestehen aus einem Zeitstempel und einem Wert. Die Änderung eines Readings wird in der Regel durch einen Event daran interessierten Geräten über die NotifyFn mitgeteilt. Die Werte von Readings sind Zeichenketten. Sie können beim Herunterfahren in einer eigenen Datei (fhem.save) gesichert und beim Neustarten von FHEM wiederhergestellt werden. Readings sind von der Natur her schnellveränderlich.<br />
<br />
Geräte können Attribute besitzen. Attribute besitzen nur einen Werte ohne Zeitstempel. Sie sind in der Regel un- bzw. langsamveränderlich und dienen typischerweise zur Konfiguration. Attribute werden persistent in der Konfiguration abgelegt. Änderungen an Attributen werden auch analog zu Reading-änderungen durch Events distributiert. Auch Attribute sind Zeichenketten.<br />
<br />
Geräte besitzen interne Werte (sog. Internals). Auch diese besitzen nur einen Werte ohne Zeitstempel. Internals können perl-skalare oder Referenztypen (z.B. hashes oder Arrays) sein. Änderungen an Internals werden nicht per Event weitergegeben, die Werte werden nicht persistiert.<br />
<br />
Readings, Attribute und Internals genügen keiner festgelegten Syntax: es gibt bezüglich der Werte keine Vorgaben zur Standardisierung. Diese können z. B. Zahlenwerte, Kombinationen aus Zahlen und physikalischen Einheiten oder Texte enthalten. Beispielsweise können Readings, die Temperaturen darstellen, die Temperatur in Celsius-Graden oder Kelvin-Graden mit oder ohne Einheitensymbol enthalten. Das erschwert die Weiterverarbeitung. Soll beispielsweise eine Temperatur in einer graphischen Benutzeroberfläche mit einem Thermometer-Widget dargestellt werden, müssen für jede Geräteklasse individuelle Transformationsregeln von der Darstellung im Reading auf den Eingangsparameter im Widget transformiert werden.<br />
<br />
Keine Semantik: Es gibt kein API, anhand dessen eine Funktion erkennen kann, was das Reading inhaltlich darstellt. Eine graphische Benutzeroberfläche kann beispielsweise nicht ermitteln, ob für ein bestimmtes Reading ein Thermometer-Widget oder eine Lampe dargestellt werden soll.<br />
<br />
== Zielsetzung ==<br />
<br />
Es soll ein API eingeführt werden, das einen bzgl. Syntax und Semantik standardisierten Zugriff auf Readings, Attribute und Internals erlaubt.<br />
<br />
Gehören Attribute und Internals wirklich hierher?<br />
* Internals sind device-intern und normalerweise nicht für Dritte gedacht. Wenn etwas 'öffentlich' und auswertebar sein soll gehört es womöglich in ein Reading oder Attribut.<br />
* manche Devices legen aus der Definition abgeleitete Werte in Internals ab. Auch diese sollten externen Schnittstellen einheitlich zugänglich gemacht werden können.<br />
* Attribute sind für den Endanwender gedacht. Was gibt es hier zu Standardisieren ausser den möglichen Werten?<br />
* Eine externe Schnittstelle kennt die FHEM-interne Struktur nicht, soll aber ggf. trotzdem vereinheitlichen Zugriff auf die Konfiguration (= die Attribute) bekommen können.<br />
<br />
Frühere Ansätze sind [[DevelopmentInterfaces|Interfaces]] und [[DevelopmentGuidelines|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].<br />
<br />
== Anforderungen an das API ==<br />
<br />
# Funktionale Anforderungen<br />
#* Es soll möglich sein einen aus den Werten von Readings, Attributen und Internals abgeleiteten Wert abzufragen<br />
#* die Zugrunde liegenden Werte (Readings, Attribute und Internals) sollen beliebigen Devices zuordenbar sein. Es soll z.B. ermöglicht werden mehrere getrennte Analoge Ausgabedevices zu einem einzigen RGB-Wert zu aggregieren.<br />
#* Sofern die Abbildevorschrift bijektiv ist, soll es möglich sein durch Setzen des abgeleiteten Wertes die zugrunde liegenden Größen zu verändern. Readings sind per definitionem nur aus dem Gerät selbst heraus und nicht in das Gerät hinein veränderbar. Oder wollen wir zulassen, dass Readings manipuliert werden können? Welchen Anwendungsfall gibt es dafür?<br />
#* Es soll möglich sein eine Benachrichtigung zu erhalten, wenn sich dieser abgeleitete Wert ändert (ggf. mit Verzicht auf Änderungen von Internals die ja keine Events auslösen).<br />
#* Es soll sich die Bedeutung eines abgeleiteten Wertes ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).<br />
#* Es sollen sich bei physikalischen Größen Wert und Einheit ermitteln lassen.<br />
#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).<br />
#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.<br />
#* Es soll sich der Wertebereich ermitteln lassen. Ein Wertebereich könnte zur sinnvollen Skalierung analoger Werte (z.B. Slider) benutzt werden.<br />
#* Es soll möglich sein mehrere Sets von Abildungsvorschriften konfigurativ hinterlegen zu können. Damit können unterschiedliche Schnittstellen oder Frontends parallel nutzbar gemacht werden. Unterschiedliche Frontends benötigen z.B. RGB-Werte in unterschiedlichen Formaten auf ggf. auf einen oder mehrere Kanäle abgebildet. -> Widerspricht das nicht dem Standardgedanken? Sollte es nicht eine Weise geben, wie RGB-Werte bereit gestellt werden, und der Kunde sollte diese dann in das eigene Format bringen?<br />
# Nichtfunktionale Anforderungen<br />
#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.<br />
#* das API soll abwärtskompatibel sein und einen (bidirektionalen) Zugriff auf bestehende Module ermöglichen.<br />
#* Das API soll nur unwesentlichen Overhead bzgl. Speicherverbrauch und Verarbeitungszeiten erzeugen.<br />
#* Es soll keine Vereinheitlichung von Readings-Namen erfolgen (temp, temperature) (das war früher einmal eine Forderung).<br />
<br />
== Erste Überlegungen ==<br />
<br />
* Einheiten alleine genügen nicht, es sollte die physikalische Größe bekannt sein, die von dem Reading repräsentiert wird (Temperatur, Druck, ...).<br />
* Dazu eine Regel, in welcher Einheit diese physikalische Größe vorliegt.<br />
* Es bringt keinen Zusatznutzen, die physikalische Größe am Reading verfügbar zu haben.<br />
* Stattdessen meldet das Device, dass es einem Standard gehorcht (ein Interface implementiert, z.B "temperature").<br />
* Ein GUI weiß dadurch, was es anzuzeigen hat. <br />
* KEINE Einheiten im {readings}{VAL}. Das muß bei wirklich jeder anderen Verwendung außer "Anzeige für Mensch mit selben Locale wie Entwickler." gestrippt werden.<br />
* An jedes Reading werden Metainformationen geklebt. Welche?<br />
* Die Metainformationen könnten Zeiger in eine hierarchische Liste standardisierter Beschreibungen sein. Sind die [[DevelopmentInterfaces|Interfaces]] modellhaft?<br />
* Es ist klar, dass die Bedeutung eine Vereinbarung darstellt, die außerhalb des Systems liegt. GGf. kann man die Implementierung aber ihre eigene Dokumentation enthalten lassen.<br />
* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.<br />
* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").<br />
* Wie wäre es, erst die Zugriffsmethoden zu definieren? Z.B. RUnit, RValue, RValue(..., $unit), RType, ...? Das macht es griffig. Ich meine damit, dass die Kunden sagen, was sie brauchen, und wir daraus das API definieren.<br />
* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB, DBLog, MQTT, smartVisu, mobile Clients sind Kunden.<br />
* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.<br />
* Think big, start small: vermutlich bringen wir nur etwas zu Wege, wenn wir nicht gleich den großen Wurf anstreben, sondern mit einem Aspekt beginnen (de facto Readings) und dabei stets das gesamte Zielbild im Auge halten.</div>Neuberthttp://wiki.fhem.de/w/index.php?title=DevelopmentReadingsAPI&diff=8547DevelopmentReadingsAPI2014-11-21T20:36:44Z<p>Neubert: Die Seite wurde neu angelegt: „Kategorie:Development == Abstract == Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand …“</p>
<hr />
<div>[[Kategorie:Development]]<br />
<br />
== Abstract ==<br />
<br />
Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand der Diskussion. <br />
<br />
Ausgangspunkt ist [http://forum.fhem.de/index.php/topic,21247.0.html dieser Thread].<br />
<br />
== Ausgangssituation ==<br />
<br />
In FHEM besitzen Geräte sogenannte Readings (Anzeigewerte). Diese bestehen aus einem Zeitstempel und einem Wert. <br />
<br />
Keine Syntax: es gibt bezüglich der Werte keine Vorgaben zur Standardisierung. Diese können z. B. Zahlenwerte, Kombinationen aus Zahlen und physikalischen Einheiten oder Texte enthalten. Beispielsweise können Readings, die Temperaturen darstellen, die Temperatur in Celsius-Graden oder Kelvin-Graden mit oder ohne Einheitensymbol enthalten. Das erschwert die Weiterverarbeitung. Soll beispielsweise eine Temperatur in einer graphischen Benutzeroberfläche mit einem Thermometer-Widget dargestellt werden, müssen für jede Geräteklasse individuelle Transformationsregeln von der Darstellung im Reading auf den Eingangsparameter im Widget transformiert werden.<br />
<br />
Keine Semantik: Es gibt kein API, anhand dessen eine Funktion erkennen kann, was das Reading inhaltlich darstellt. Eine graphische Benutzeroberfläche kann beispielsweise nicht ermitteln, ob für ein bestimmtes Reading ein Thermometer-Widget oder eine Lampe dargestellt werden soll.<br />
<br />
== Zielsetzung ==<br />
<br />
Es soll ein API eingeführt werden, das einen bzgl. Syntax und Semantik standardisierten Zugriff auf Readings erlaubt.<br />
<br />
Frühere Ansätze sind [[DevelopmentInterfaces|Interfaces]] und [[DevelopmentGuidelines|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].<br />
<br />
== Anforderungen an das API ==<br />
<br />
# Funktionale Anforderungen<br />
#* Es soll sich die Bedeutung eines Readings ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).<br />
#* Es sollen sich bei physikalischen Größen Wert und Einheit ermitteln lassen.<br />
#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).<br />
#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.<br />
#* Es wurde die Anforderung genannt, dass sich der Wertebereich ermitteln lassen sollte. Mir ist nicht klar, ob dies für Readings erforderlich ist (es wäre für Settings erforderlich).<br />
# Nichtfunktionale Anforderungen<br />
#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.<br />
#* Das API soll nur unwesentlichen Overhead bzgl. Speicherverbrauch und Verarbeitungszeiten erzeugen.<br />
#* Es soll keine Vereinheitlichung von Readings-Namen erfolgen (temp, temperature) (das war früher einmal eine Forderung).<br />
<br />
== Erste Überlegungen ==<br />
<br />
* Einheiten alleine genügen nicht, es sollte die physikalische Größe bekannt sein, die von dem Reading repräsentiert wird (Temperatur, Druck, ...).<br />
* Dazu eine Regel, in welcher Einheit diese physikalische Größe vorliegt.<br />
* Es bringt keinen Zusatznutzen, die physikalische Größe am Reading verfügbar zu haben.<br />
* Stattdessen meldet das Device, dass es einem Standard gehorcht (ein Interface implementiert, z.B "temperature").<br />
* Ein GUI weiß dadurch, was es anzuzeigen hat. <br />
* KEINE Einheiten im {readings}{VAL}. Das muß bei wirklich jeder anderen Verwendung außer "Anzeige für Mensch mit selben Locale wie Entwickler." gestrippt werden.<br />
* An jedes Reading werden Metainformationen geklebt. Welche?<br />
* Die Metainformationen könnten Zeiger in eine hierarchische Liste standardisierter Beschreibungen sein. Sind die [[DevelopmentInterfaces|Interfaces]] modellhaft?<br />
* Es ist klar, dass die Bedeutung eine Vereinbarung darstellt, die außerhalb des Systems liegt. GGf. kann man die Implementierung aber ihre eigene Dokumentation enthalten lassen.<br />
* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.<br />
* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").<br />
* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB und DBLog sind Kunden.<br />
* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.</div>Neuberthttp://wiki.fhem.de/w/index.php?title=Strace_verwenden&diff=6985Strace verwenden2014-07-23T07:07:53Z<p>Neubert: </p>
<hr />
<div><br />
Auf Linux-Maschinen können mit dem Befehl<br />
<pre><br />
strace -p PIDvonFHEM -ttT -o strace.log<br />
</pre><br />
sämtliche Systemaufrufe von FHEM in eine Datei protokolliert werden. Dabei wird jeder Zeile ein Zeitstempel (aktuelle Uhrzeit) vorangestellt und die Dauer des Systemaufrufs in Sekunden in spitzen Klammern hintenangestellt.<br />
<br />
Um nur Aufrufe von select und write zu sehen, kann man mit der Option<br />
<pre><br />
-e trace=select,write<br />
</pre><br />
vorfiltern. Näheres ist der Manpage von strace zu entnehmen.<br />
<br />
Lang laufende Operationen (eine Sekunde oder länger) werden dann parallel dazu in einem anderen Terminal mit<br />
<pre><br />
tail -f strace.log | grep -v '<0.' <br />
</pre><br />
herausgefiltert.<br />
<br />
Um herauszufinden, was die Filedeskriptoren bedeuten, wird der Befehl<br />
<pre><br />
list .* FD<br />
</pre><br />
auf der FHEM-Kommandozeile aufgerufen. Ist der Filedeskriptor nicht dabei, wird man im Verzeichnis<br />
<pre><br />
/proc/PIDvonFHEM/fd<br />
</pre><br />
fündig.<br />
<br />
Um sich alle offenen Files, Sockets und Pipes anzusehen, dient der Befehl:<br />
<pre><br />
lsof -p PIDvonFHEM<br />
</pre><br />
<br />
[[Kategorie:HOWTOS]]</div>Neuberthttp://wiki.fhem.de/w/index.php?title=Strace_verwenden&diff=6967Strace verwenden2014-07-21T14:31:13Z<p>Neubert: Die Seite wurde neu angelegt: „ Auf Linux-Maschinen können mit dem Befehl <pre> strace -p PIDvonFHEM -ttT -o strace.log </pre> sämtliche Systemaufrufe von FHEM in eine Datei protokolliert …“</p>
<hr />
<div><br />
Auf Linux-Maschinen können mit dem Befehl<br />
<pre><br />
strace -p PIDvonFHEM -ttT -o strace.log<br />
</pre><br />
sämtliche Systemaufrufe von FHEM in eine Datei protokolliert werden. Dabei wird jeder Zeile ein Zeitstempel (aktuelle Uhrzeit) vorangestellt und die Dauer des Systemaufrufs in Sekunden in spitzen Klammern hintenangestellt.<br />
<br />
Um nur Aufrufe von select und write zu sehen, kann man mit der Option<br />
<pre><br />
-e trace=select,write<br />
</pre><br />
vorfiltern. Näheres ist der Manpage von strace zu entnehmen.<br />
<br />
Lang laufende Operationen (eine Sekunde oder länger) werden dann parallel dazu in einem anderen Terminal mit<br />
<pre><br />
tail -f strace.log | grep -v '<0.' <br />
</pre><br />
herausgefiltert.<br />
<br />
Um herauszufinden, was die Filedeskriptoren bedeuten, wird der Befehl<br />
<pre><br />
list .* FD<br />
</pre><br />
auf der FHEM-Kommandozeile aufgerufen. Ist der Filedeskriptor nicht dabei, wird man im Verzeichnis<br />
<pre><br />
/proc/PIDvonFHEM/fd<br />
</pre><br />
fündig.<br />
<br />
[[Kategorie:HOWTOS]]</div>Neubert