== Sinn und Zweck ==
[[Datei:Sensorfeed2.jpg|mini|links]]Aus Fernost gab es gerade sehr billig ein Gadget in Form eines Mini-Fernsehers, der im wesentlichen aus einem ESP32 mit einem 240x240 Pixel großen Farb-LCD besteht: das GIFTV von GeekMagic. Ich habe mir damit ein Mini-Dashboard für meine Photovoltaik-Anlage gebaut.

== Komponenten ==

=== Übersicht ===
Das Dashboard wird als JPG-Bild mit dem Modul RSS on-the-fly erstellt. Ein at-Kommando ruft jede Minute ein Bild vom Modul ab und schiebt es über eine Perl-Funktion auf das GIFTV. Das GIFTV arbeitet dabei mit seiner Standard-Firmware im Bilderalbum-Modus.

Die Werte für das Dashboard stammen aus einem readingsProxy (neue Version ab April 2026), der die angezeigten Werte aus mehreren Geräten (SMA Energy Meter, SMA Inverter, Electricity Calculator) zusammenführt. Die Anzeige im Dashboard bedient sich der Widgets von DOIF (siehe [[DOIF/uiTable Schnelleinstieg]]).

=== readingsProxy ===

==== Einleitung ====
Der readingsProxy wird benötigt, um aus verschiedenen Geräten Werte zusammenzuziehen, diese verständlich zu benennen, und weitere Werte mit userReadings zu berechnen.

Ich möchte im Mini-Dashboard gerne folgende Werte sehen:
* Momentane Leistung der PV-Anlage in Watt: PVPowerSourceW
* Tageserzeugung Solarstrom in kWh: PVEnergySourcekWh
* Momentaner Stromverbrauch des Hauses in Watt: HousePowerSinkW
* Tagesverbrauch des Hauses in kWh: HouseEnergySinkkWh
* Momentane Netzeinspeisung oder Netzbezug in W: GridPowerW = GridPowerSourceW + GridPowerSinkW
* Netzbezug des Tages in kWh: GridEnergySourcekWh
* Momentane Batterieladung oder -entladung in W: BatteryPowerW = BatteryPowerSourceW + BatteryPowerSinkW
* Ladezustand der Batterie in %: BatteryPercent
Die Benennung der Werte und deren Vorzeichen folgen einer Logik:

* Es gibt Quellen (Source) und Senken (Sink) von Strom.
* Leistung mit positivem Vorzeichen wird einer Komponente entnommen (Quellen: PV-Anlage, Netzbezug, Batterieentladung).
* Leistung mit negativem Vorzeichen wird einer Komponente hinzugefügt (Senken: Netzeinspeisung, Hausstromverbrauch, Batterieladung).
* Die Energiemengen (PV-Anlage, Netzbezug, Netzeinspeisung, Batterieladung, Batterieentladung, Hausstromverbrauch) sind immer positiv.

==== Definition ====

Inspiration fand ich auf der Webseite [https://www.juergenstechnikwelt.de/photovoltaik/pv-anlage-in-fhem-die-datenbasis-fuer-das-dashboard/ Jürgens Technikwelt].

<code><nowiki>define aggr.PV readingsProxy \
smainverter:SPOT_PDC_SUM:PVPowerSourceW \
smainverter:SPOT_EPVTODAY:PVEnergySourceWh \
smaem:SMAEM1234567890_Bezug_Wirkleistung:GridPowerSourceW \
smaem:SMAEM1234567890_Einspeisung_Wirkleistung:GridPowerSinkW \
calc.Netzbezug:smaem_SMAEM1234567890_Bezug_Wirkleistung_Zaehler_EnergyDay:GridEnergySourcekWh \
calc.Netzeinspeisung:smaem_SMAEM1234567890_Einspeisung_Wirkleistung_Zaehler_EnergyDay:GridEnergySinkkWh \
smainverter:BAT_P_CHARGE:BatteryPowerSinkW \
smainverter:BAT_P_DISCHARGE:BatteryPowerSourceW \
smainverter:ChargeStatus:BatteryPercent \
smainverter:BAT_LOADTODAY:BatteryEnergySinkWh \
smainverter:BAT_UNLOADTODAY:BatteryEnergySourceWh \
smaem:SMAEM1234567890_GridFreq:GridFrequencyHz
attr aggr.PV stateFormat PV: PVPowerSourceW W < PVEnergySourcekWh kWh | Haus: HousePowerSinkW W > HouseEnergySinkkWh kWh | Netz: GridPowerW W < GridEnergySourcekWh kWh > GridEnergySinkkWh kWh | Batterie: BatteryPowerW W BatteryPercent % < BatteryEnergySourcekWh kWh > BatteryEnergySinkkWh kWh
attr aggr.PV userReadings \
GridPowerW { ReadingsNum("aggr.PV", "GridPowerSourceW", 0) - ReadingsNum("aggr.PV", "GridPowerSinkW", 0) }, \
BatteryPowerW { ReadingsNum("aggr.PV", "BatteryPowerSourceW", 0) - ReadingsNum("aggr.PV", "BatteryPowerSinkW", 0) }, \
PVEnergySourcekWh { ReadingsNum("aggr.PV", "PVEnergySourceWh", 0)/1000.0 }, \
BatteryEnergySourcekWh { ReadingsNum("aggr.PV", "BatteryEnergySourceWh", 0)/1000.0 }, \
BatteryEnergySinkkWh { ReadingsNum("aggr.PV", "BatteryEnergySinkWh", 0)/1000.0 }, \
HousePowerSinkW { -( ReadingsNum("aggr.PV", "PVPowerSourceW", 0)+ReadingsNum("aggr.PV", "GridPowerW", 0)+ReadingsNum("aggr.PV", "BatteryPowerW", 0) ) }, \
HouseEnergySinkkWh { ReadingsNum("aggr.PV", "PVEnergySourcekWh", 0)-ReadingsNum("aggr.PV","GridEnergySinkkWh", 0)+ReadingsNum("aggr.PV", "GridEnergySourcekWh", 0)-ReadingsNum("aggr.PV", "BatteryEnergySinkkWh",0)+ReadingsNum("aggr.PV", "BatteryEnergySourcekWh", 0) \
}</nowiki></code>

=== RSS ===

==== Definition ====

<code>define sensorfeed2 RSS jpg has-1.example.com /opt/fhem/conf/sensorfeed2.layout
attr sensorfeed2 bg /opt/fhem/PictureFrame/sensorfeed2
attr sensorfeed2 size 240x240</code>

Das KI-generierte Hintergrundbild /opt/fhem/PictureFrame/sensorfeed2 dient als Symbolbild.

==== Layout ====

Das Modul 98_DOIF.pm wird benötigt, damit RSS die darin enthaltenen Widgets verwenden kann. Wenn man kein DOIF benutzt, muss man das Modul mit <code>require 98_DOIF.pm</code> im Perl-Kode laden - das erfolgt unprätentiös in dem automatisch geladenen 99_GIFTV.pm.

Datei: <code>/opt/fhem/conf/sensorfeed2.layout</code>

<code><nowiki># ------------------
# font
# ------------------
font /opt/fhem/conf/DroidSans.ttf
# ------------------
# bottom left corner
# ------------------
#
# date/time
#
rgb "c0c0c0"
pt 10
date 10 230
time 100 230
#
# links oben: Erzeugung
#
img 10 10 100w svg data { ui_Table::ring2( \
main::ReadingsVal('aggr.PV','PVPowerSourceW',0.0), 0.0, 4.0, 0, 240, "PV", 100, undef, "0,,,W", \
main::ReadingsVal('aggr.PV','PVEnergySourcekWh',0.0), 0, 50, 0, 120, undef, undef, "0,,,kWh") \
}
#
# rechts oben: Verbrauch
#
img 130 10 100w svg data { ui_Table::ring2( \
main::ReadingsVal('aggr.PV','HousePowerSinkW',0.0), 0.0, 4.0, 0, 240, "Haus", 100, undef, "0,,,W", \
main::ReadingsVal('aggr.PV','HouseEnergySinkkWh',0.0), 0, 50, 0, 120, undef, undef, "0,,,kWh") \
}
#
# links unten: Netzbezug (+)/Netzeinspeisung (-)
#
img 10 130 100w svg data { ui_Table::ring2( \
main::ReadingsVal('aggr.PV','GridPowerW',0.0), -4.0, 4.0, 0, 240, "Netz", 100, undef, "0,,,W", \
main::ReadingsVal('aggr.PV','GridEnergySourcekWh',0.0), 0, 100, 0, 120, undef, undef, "0,,,kWh") \
}
#
# rechts unten: Batterie
#
img 130 130 100w svg data { ui_Table::ring2( \
main::ReadingsVal('aggr.PV','BatteryPowerW',0.0), -4.0, 4.0, 0, 240, "Batt", 100, undef, "0,,,W", \
main::ReadingsVal('aggr.PV','BatteryPercent',0.0), 0, 100, 0, 120, undef, undef, "0,,,%") \
}</nowiki></code>

=== Bespielung des GIFTV ===

==== at ====

Der at-Befehl schiebt durch Aufruf von push2giftv() in Sekunde 1 jeder Minute das Bild vom RSS-Gerät sensorfeed2 auf zwei im Haus verteilte GIFTVs.

<code>define at.sensorfeed at +*00:01:00 { push2giftv( { "sensorfeed2" => ["giftv-1.example.com","giftv-3.example.com"] } ) }
attr at.sensorfeed alignTime 01:01:01</code>

==== push2giftv() ====

Es wird ein automatisch von FHEM geladenes Modul 99_GIFTV.pm mit folgendem Inhalt im Ordner FHEM (unter Linux üblicherweise <code>/opt/fhem/FHEM/99_GIFTV.pm</code>) bei den anderen Modulen angelegt:

<code><nowiki>require '98_DOIF.pm';
sub push2giftv {
my $uploadsref = shift;
# wrap code in eval to avoid lethal errors crashing FHEM
eval {
my $type = "jpg";
while( my ($rssname, $hostnamesref) = each(%$uploadsref) ) {
# make RSS generate the image
my ($mimetype, $image) = RSS_returnIMG($rssname, $type);
my $targetfilename = "$rssname.$type";
foreach my $hostname (@$hostnamesref) {
# parameters for GIFTV
my $url = "http://$hostname/doUpload?dir=%2Fimage%2F";
my $param = {
loglevel => 4,
url => $url,
method => "POST",
hideurl => 0,
noshutdown => 0,
callback => sub($$$) { Log3 $name, 1,"ERR:$_[1] DATA:".length($_[2]) },
};
# add image as multipart form data
HttpUtils_AddMultipartData($param, $image,
{"Content-Disposition" => "form-data; name=\"file\"; filename=\"$targetfilename\"", "Content-Type" => $mimetype }
);
# upload to GIFTV $hostname
HttpUtils_NonblockingGet($param);
}
}
};
if ($@) {
my $msg = $@;
chomp $msg;
Log3 $name, 2, $msg;
}
}</nowiki></code>

Das Modul 98_DOIF.pm wird benötigt, damit RSS die darin enthaltenen Widgets verwenden kann.

push2giftv() nimmt als Argument ein Hash, das jedem RSS-Gerät (hier sensorfeed2) ein Array mit den Hostnamen oder IP-Adressen der GIFTVs zuordnet, auf die das Bild vom RSS-Gerät geschoben wird.

Beispielaufruf, um mehrere Dashboards (sensorfeed1 und sensorfeed2) auf zwei GIFTVs zu schieben:

<code>push2giftv( { "sensorfeed1" => ["giftv-1.example.com","giftv-3.example.com"], "sensorfeed2" => ["giftv-1.example.com","giftv-3.example.com"] } ) }</code>

Das GIFTV zeigt dann die beiden Dashboards im Wechsel an.

Mini-Dashboard für PV-Anlage

2026-03-29T16:27:11Z

Datei:Sensorfeed2.jpg

2026-03-29T14:44:46Z

Neubert:

240x240 Pixel großes JPG-Bild der Anzeige im Mini-Dashboard

Anwendungsszenarien

2026-03-29T14:38:18Z

Neubert: Fallstudien verlinkt

Diese Seite stellt eine "redaktionell bearbeitete" Liste von Anwendungsszenarien dar. Weitere, ähnliche Aufstellungen finden sich in den Kategorielisten
* [[:Kategorie:Examples|Examples]] für komplette Beispiele
* [[:Kategorie:Code Snippets|Code Snippets]] für kleine Schnipsel mit einzelnen Befehlen und/oder Definitionen
* und auf der Seite "[[Wie kann ich...]]"

Finden sich hier Links auf Forenbeiträge oder externe Seiten, so sind diese als "gewünschte Seite" zu interpretieren.

== Szenarien ==
{| class="wikitable"
|-
| style="width:50%" |
* (Haus-)Informations- und Steuerzentrale
** [[Fallstudie: Haus automatisieren]]
** Mittels [[RSS]] generiertes Übersichtsbild (ausführlicher Workshop verfügbar)
** Digitaler Bilderrahmen mit [[Digitaler Bilderrahmen | eingeblendeten FHEM-Daten]] oder zur [[Digitaler_Bilderrahmen_mit_lcd4linux| Anzeige von FHEM-Grafiken]]
** [[Statusdisplay Fritzbox 7390]]
** [[Kindle_Display]] (FHEM Informationen als Screensaver)
** [[Mini-Dashboard für PV-Anlage]]

* Telefon
** [[Telefonat als Auslöser für Aktionen]]
** ...

* Rollladensteuerung
** [[Jalousie und Beleuchtung in mehreren Räumen]]
** [[Slider für HM-Rolladensteuerung anzeigen]]
** [[Rolladensteuerung mit FS20SM8]]
** ...

* Heizungssteuerung
** [[Grundlagen der Heizungssteuerung]]
** [[Heizungskontrolle Einfach]] (Englische Version: [[Heating Control Basic]])
** [[Junkers Therme Stetigregelung]]
** Heizungssteuerung mit [[HCS]] und/oder [[Heating Control]]
** 3/4-Wege-Mischer-Steuerung mit [[STELLMOTOR]]: [[Mischersteuerung]]
** Vorlauf-Energiebedarf mit [[VALVES]]: [[Raumbedarfsabhängige Heizungssteuerung]]
** Heizungsoptimierung (Mischer, Pumpe) [[Heizung:_Verbrauchsoptimierung,_Radiator/Fußboden-Steuerung]]
** [[Luxtronik 1 in FHEM]] einbinden
** [[Effizienter Betrieb einer Fußbodenheizung mit Luft-Wasser-Wärmepumpe (Fallbeispiel)]]

* Balkon und Garten
** [[Bewässerungssteuerung]]
** ...

* Lüftung und Klima
** [[Energiesparende Schimmelbekämpfung / Luftentfeuchtung in kritischen Räumen‎]]
** ...

* Auto, Verkehr
** [[Spritpreismonitor]] sammelt und visualisiert die Preisentwicklung an ausgewählten Tankstellen

| style="width:50%" |

* Finanzen
** [[STOCKQUOTES|Wertpapierkurse verfolgen/protokollieren]]
** ...

* Helligkeitsgeführte Steuerung
** [[Twilight Anwendungsbeispiel]]
** ...

* Terminerinnerungen, Kalenderintegration
** Erinnerung an Müllabfuhr, etc.: {{Link2Forum|Topic=26209|LinkText=Forenthema}} und ein {{Link2Forum|Topic=32382|LinkText=weiteres Forenthema}}
** ...

* Zugriff auf FHEM "von außen"
** [[FritzBox Webzugriff absichern]]
** [[FB7390 VPN-Zugang einrichten]]
** ...

* Anwesenheitssimulation / -steuerung
** [[Anwesenheitserkennung]]
** ...

* Zugangskontrolle, Fenster, Tür und Tor
** [[DoorPi_und_FHEM |Türsprechstelle mit DoorPi]]
** [[Garagentorsteuerung]]
** {{Link2Forum|Topic=11715|LinkText=Zugangskontrolle mit Keymatic, Fingerabdruck, RFID}} (Forum; sollte noch ins Wiki integriert werden)
** ...

* (Video-)Überwachung
** Einbindung von (Web-)Cam Bildern / Streams
** ...

* Energieverbrauch / -erzeugung
** [[Ertragsmessung Solarthermie]]
** [[Heizleistung und Gasverbrauch]]

* Rundfunk / Fernsehen / Multimedia
** {{Link2Forum|Topic=28123|LinkText=Aktuelles TV-Programm}} auflisten (Forenthema)
** ...

* Sonstiges
** [[Watchdog kombiniert mit Threshold|Auf ausbleibende Aktionen oder Ereignisse reagieren]]
** mit FHEM realisierte [[Zeitschaltuhr]]
** [[Temperaturfarbe | Temperatur in Farbe]]
|}

Sofern hier statt Verweisen auf andere Wiki-Seiten Forenthemen verlinkt sind, sind alle Wiki-Schreiber herzlich eingeladen, die Informationen aus dem Forum in einer (neuen) Wiki-Seite zu konsolidieren.

[[Kategorie:Examples]]

Fallstudie: Haus automatisieren

2026-03-05T18:17:17Z

Neubert: /* Leuchtmittel */

== Einleitung ==

Dieser Artikel ist eine Fallstudie zum Einsatz von FHEM für die Hausautomation mit Anwendungsfeldern von FHEM, die für die meisten Anwender üblich sind. Er soll Einsteigern in FHEM die Nutzung von FHEM erleichtern.

Ich bin ein FHEM-Nutzer der ersten Stunde und FHEM-Entwickler seit 2007. Dieser Artikel beschreibt die aufgrund von Umzügen vierte Installation von FHEM in einer von mir bewohnten Liegenschaft, nicht eingerechnet Aktualisierungen und Veränderungen an der Hausautomation aufgrund von Wechseln bei der eingesetzen Server-Hardware und -Software und den verwendeten Hausautomationssystemen.

Ich bringe in diesen Artikel meine Erfahrungen ein, was sich als nützlich und praktisch erwiesen hat, und möchte dem FHEM-Anwender helfen, die Herausforderungen beim Einsatz bei FHEM durch konkrete Beispiele anhand meiner Anwendungsfälle zu bewältigen.

== Automatisierte Liegenschaft ==

Bei der Liegenschaft handelt es sich um ein Einfamilienhaus mit vier Etagen (Keller, Erdgeschoss, Obergeschoss, Dachgeschoss), Garage und Garten.

== Hausautomationsserver ==

=== Hardware ===

==== Anforderungen ====

Die Server-Hardware sollte zum einen ausreichend Rechenleistung für den Betrieb des FHEM-Frontends FHEMWEB bereitstellen, andererseits sparsam im Stromverbrauch sein, sowie autark.

Die Autarkie spricht dafür, einen dedizierten Rechner für FHEM zum Einsatz zu bringen, denn die Hausautomation sollte durchgehend laufen, unabhängig von den anderen Spielereien im Home Lab.

==== Geräteauswahl ====

Es lag zunächst nahe, einen Raspberry Pi zum Einsatz zu bringen. Während die Modelle bis zum Raspberry Pi 3 bei der Darstellung von SVG-Plots mit längeren Zeitreihen überfordert waren, liefern die Versionen 4 und 5 mit viel RAM genügend Leistung. Allerdings sind die Flaggschiffe mittlerweile recht teuer, wenn man alle erforderlichen Komponenten (Computer, SD-Karte für Boot-Partition, SSD für Root- und Daten-Partionen, Netzteil, Gehäuse) zusammennimmt. Da ich die I/O-Ports des Raspberry Pi für Basteleien nicht benötige, habe ich mich in der Welt der Mini-PCs umgesehen.

Meine Wahl fiel auf einen [https://minisforumpc.eu/ Minisforum] UN150P. Das Gerät bietet für knapp über 200 € eine grandiose Ausstattung und Leistung ([https://www.heise.de/bestenlisten/testbericht/minisforum-un150p-im-test/jn4g3l4 Testbericht]). Im Dezember 2025 ist das Gerät nicht (mehr) verfügbar. Es gibt aber eine Reihe vergleichbar leistungsstarker Mini-PCs in dieser Preisklasse.

==== Aufstellort ====

Um mit den anzuschließenden Funk-Interfaces das Haus möglichst gut abzudecken, empfiehlt sich ein zentraler Aufstellort. Bei mir ist das unter dem Schreibtisch im Arbeitszimmer im Obergeschoss.

Eine Aufstellung im Serverschrank im Keller ist wegen der abseitigen Lage und der elektromagnetischen Abschirmung nicht sinnvoll.

==== Peripherie ====

Für die Erstinstallation habe ich Tastatur, Maus und HDMI-Monitor an den Mini-PC angeschlossen. Später läuft der Mini-PC ohne Peripherie ("Headless").

Alternativ kann man einen Remote-KVM-Adapter anschließen. Dieser überträgt die Anschlüsse inklusive Bild hardwareseitig an einen entfernten Rechner. Im Gegensatz zu Remotedesktopsoftware, die ein laufendes Betriebssystem auf dem ferngesteuerten Rechner erfordert, kann man mit dem Remote-KVM-Adapter bereits den Boot-Vorgang beobachten und Einstellungen im BIOS aus der Ferne machen.

Ich verwende dafür an einem anderen Rechner den [https://www.gl-inet.com/products/gl-rm1/ GL.iNet Comet (GL-RM1)] in der PoE-Variante. Für rund 100 € erhält man damit eine Funktionalität, für die man sonst ein sehr viel teureres Server-Mainboard benötigen würde.

=== Software ===

==== Überblick ====
Der Softwarestack auf dem Hautomationsserver besteht aus Proxmox Virtual Enviromnent und darauf ein Linux-Container mit Debian Linux 13 (Trixie) und FHEM als Hausautomationssoftware sowie Zigbee2MQTT für das Management der Zigbee-Geräte. Die Installation ist im folgenden skizziert.

==== Installation des Proxmox Virtual Environments ====

==== Installation des Linux-Containers ====
Hostname: has.example.org

==== Installation von FHEM im Linux-Container ====

== Anwendungsfelder ==

Die gängigen Anwendungsfelder sind
* Beleuchtungssteuerung
* Raumklimaüberwachung und Heizungssteuerung
* Wetteraufzeichnung

== Hausautomationssysteme ==

=== Zigbee ===

==== Hardware ====
[https://de.wikipedia.org/wiki/ZigBee Zigbee] braucht eine Zentraleinheit, die Koordinator genannt wird. Es kommt dafür ein [https://phoscon.de/de/conbee2 ConBee II von Phoscon] zum Einsatz, der direkt am USB-Port des Hausautomationsservers angeschlossen ist. Das Gerät hatte ich mir vor einigen Jahren für Testzwecke zugelegt. Heute würde ich zu einem Flagschiff-Produkt von [https://smlight.tech/ SMLIGHT] greifen, das unabhängig vom Hausautomationsserver ans LAN angeschlossen und via PoE mit Strom versorgt wird.

Der ConBee II erscheint auf dem Host (auf der Konsole mit <code>lsusb</code> anzeigen):

<code>Bus XXX Device XXX: ID 1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]</code>

Das Device dazu ist:

<code>/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DExxxxxxx-if00</code>

Unter Proxmox fügt man zum Container unter ''Resources'' mit ''Add'' ein ''Device Passtrough'' hinzu mit dem o.a. ''Device Path, UID in CT: 0, GID in CT: 20, Access Mode in CT: 0660, Read only: aus''. UID 0 ist ''root'' und GID 20 ist ''dialout''. Das Gerät erscheint dann im Container genau mit demselben Device Path und Besitzer ''root:dialout''.

==== Software ====
Für die Steuerung des Zigbee-Netzwerks kommt [https://www.zigbee2mqtt.io/ zigbee2mqtt] (kurz: z2m) zum Einsatz, was eine absolut spitzenmäßige Unterstützung für alle möglichen Fabrikate bietet. Die Software wird im Container installiert. Dazu folgt man der [https://www.zigbee2mqtt.io/guide/getting-started/ Anleitung für zigbee2mqtt]. Die Weboberfläche von zigbee2mqtt ist dann unter <code><nowiki>http://has.example.org:8080</nowiki></code> zu erreichen.

==== Zigbee-Geräte ====
Um Zigbee-Geräte mit dem Koordinator zu paaren, also sie anzulernen, aktiviert man das Anlernen in der Weboberfläche von zigbee2mqtt wie in dessen Anleitung beschrieben.

===== Leuchtmittel =====
Um Zigbee-Leuchtmittel zu paaren, hat sich eine "Paarungsstation" bewährt. Dabei handelt es sich um eine E27-Baufassung, die mit einem Schukostecker in eine schaltbare Steckdose eingesteckt wird.
[[Datei:Zigbee Paarung.jpg|mini]]
Dies ermöglicht es bequem vom Schreibtisch aus die Zigbee-Leuchtmittel mit dem Zigbee-Coordinator zu paaren.

Die bekannten Paarungssequenzen für Leuchtmittel sind:
* IKEA-Tradfri: 6 Mal im Sekundentakt aus- und anschalten
* EGLO-Z (AwoX): 30 s aus, 1 s ein, 6 s aus, 1 s ein, 6 s aus, 1 s ein, 6 s aus, 12 s ein, 6 s aus, 12 s ein, 6 s aus, einschalten (siehe [https://www.eglo.com/de/connect-z-general-q2 Wie kann ich eine Leuchte auf Werkseinstellung zurücksetzen. (RESET)])
Die Sequenz von EGLO-Z kann man am besten wie folgt realisieren: Man lässt die Lampe mindestens 30 Sekunden aus. Dann startet man die Stoppuhr vom Smartphone und legt den Schalter jeweils um, wenn die folgenden Sekunden verstrichen sind: 0 (Stoppuhr starten und anschalten) 7 8 14 15 21 33 39 51 57 (Licht ist an und Lampe paarungsbereit). Es kommt übrigens nicht darauf an, die Zeit exakt zu treffen; es funktioniert auch schon, wenn man die Sequenz zeitlich so gut abarbeitet, wie man eben kann.

== Nomenklatur ==

Fallstudie: Haus automatisieren

2026-02-28T18:41:53Z

Neubert:

Fallstudie: Haus automatisieren

2026-02-07T16:22:59Z

Neubert: /* Software */

Fallstudie: Haus automatisieren

2026-01-02T12:22:21Z

Neubert: /* Zigbee */

Fallstudie: Haus automatisieren

2026-01-02T12:21:28Z

Neubert: /* Anwendungsfelder */

Datei:Zigbee Paarung.jpg

2026-01-02T12:14:29Z

Neubert:

Gerät zur Paarung von Zigbee-Leuchtmitteln

Fallstudie: Haus automatisieren

2026-01-02T12:09:59Z

Neubert: /* Anwendungsfelder */

Fallstudie: Haus automatisieren

2025-12-07T16:10:06Z

Neubert: /* Geräteauswahl */

Fallstudie: Haus automatisieren

2025-12-07T16:09:18Z

Neubert: /* Hardware */

Fallstudie: Haus automatisieren

2025-12-07T15:50:15Z

Neubert: /* Hausautomationsserver */

2018-03-22T17:19:34Z

Neubert:

== Updatemechanismus ==

'''Diese Seite ist frisch dem Ei entschlüpft und noch nicht qualitätsgesichert.'''

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.

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.

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.

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.

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.
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.

[[Kategorie:Development]]

DevelopmentUpdate

2018-03-22T17:18:45Z

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…“

OWServer & OWDevice

2015-05-14T12:03:15Z

Neubert:

==Einleitung==

Bei OWServer handelt es sich um eine 1-Wire Server Komponente und bei OWDevice um eine Geräte-Komponente, die die angeschlossenen Module definiert-
Die Module benötigen die Serverkomponente von [http://www.owfs.org OWFS].

'''Wichtig:'''

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.).
Umgekehrt können die Module OWSWITCH, OWTHERM, etc. auch mit dem Backendmodul OWServer zusammenarbeiten, siehe dazu die commandref der betreffenden Module.

==Vorbereitung==

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...

===owfs Pakete installieren===

1) entweder sind die Pakete bereits vorpaketiert und man muss nur das [http://owfs.davromaniak.eu/ Repository] noch in /etc/apt/sources.list eintragen

2) oder man muss selber kompilieren ([http://www.navitron.org.uk/forum/index.php?topic=12604.msg151750#msg151750 Quelle]).
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]

<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
sudo apt-get install git git-buildpackage dh-make quilt php5-cli
git clone [git://git.debian.org/collab-maint/owfs.git git://git.debian.org/collab-maint/owfs.git] git
git-buildpackage -uc -us
cd ..
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
sudo dpkg -i ./owhttpd_2.8p7+cvs20110310-1_i386.deb</nowiki>
diese Pakete werden alle gebaut:

<nowiki>libow-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-common_2.8p7+cvs20110310-1_all.deb
libowcapi-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-dbg_2.8p7+cvs20110310-1_i386.deb
libow-dev_2.8p7+cvs20110310-1_i386.deb owfs-doc_2.8p7+cvs20110310-1_all.deb
libownet-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-fuse_2.8p7+cvs20110310-1_i386.deb
libownet-dev_2.8p7+cvs20110310-1_i386.deb owftpd_2.8p7+cvs20110310-1_i386.deb
libownet-perl_2.8p7+cvs20110310-1_all.deb owhttpd_2.8p7+cvs20110310-1_i386.deb
libownet-php_2.8p7+cvs20110310-1_all.deb owserver_2.8p7+cvs20110310-1_i386.deb
libow-perl_2.8p7+cvs20110310-1_i386.deb ow-shell_2.8p7+cvs20110310-1_i386.deb
libow-php5_2.8p7+cvs20110310-1_i386.deb python-ow_2.8p7+cvs20110310-1_i386.deb
libow-tcl_2.8p7+cvs20110310-1_i386.deb python-ownet_2.8p7+cvs20110310-1_all.deb
owfs_2.8p7+cvs20110310-1_all.deb</nowiki>

3) In aktuellen Versionen von Raspbian sind die notwendigen Pakete schon in den konfigurierten Quellen vorhanden. Es reicht ein

<pre>sudo apt-get install owserver ow-shell owhttpd owftpd</pre>

===Unterstütze Geräte===
Eine aktuelle Liste der von OWDevice unterstützen Geräte findet man im [http://fhem.de/commandref.html#OWDevice FHEM-Commandref].

==Konfiguration von owserver==

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).

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:

<nowiki>ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="DAE001nq", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", SYMLINK+="onewire"
</nowiki>

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.

Eine Minimalkonfiguration für /etc/owfs.conf ist

<pre>server: device = /dev/onewire
http: port = 2121
ftp: port = 2120
server: port = 4304
</pre>

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.

==Konfiguration in FHEM==
Als erstes definiert man OWServer. Hiermit wird ein logischer OWServer definiert, auf welchem OWFS installiert ist

<nowiki>define <name> OWServer <protocol></nowiki>
<protocol> hat das Format <hostname>:<port>.

zBsp:

<nowiki>define myOWServer OWServer 192.168.14.100:4304</nowiki>
oder wenn sich OWFS auf dem gleichen Server befindet wie FHEM:

<nowiki>define myOWServer OWServer localhost:4304</nowiki>
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:

<nowiki>get myOWServer devices</nowiki>
Danach werden sämtliche angeschlossene Geräte angezeigt, inkl. Busmaster

===OWServer Set Befehle===
<nowiki>set <name> <value>
value:
timeout/directory
timeout/ftp
timeout/ha7
timeout/network
timeout/presence
timeout/serial
timeout/server
timeout/stable
timeout/uncached
timeout/usb
timeout/volatile
timeout/w1
units/pressure_scale
units/temperature_scale</nowiki>
Weitere Informationen zu den Set Befehlen sind im [http://owfs.org/uploads/owserver.1.html#sect41 OWServer Manual] zu entnehmen.

===OWServer Get Befehle===
<nowiki>get <name> <value>
value:
/settings/timeout/directory
/settings/timeout/ftp
/settings/timeout/ha7
/settings/timeout/network
/settings/timeout/presence
/settings/timeout/serial
/settings/timeout/server
/settings/timeout/stable
/settings/timeout/uncached
/settings/timeout/usb
/settings/timeout/volatile
/settings/timeout/w1
/settings/units/pressure_scale
/settings/units/temperature_scale</nowiki>
Zusätzlich stehen die FHEM-internen Befehle "errors" und "devices" zur Verfügung.
zBsp:

<nowiki>get <Devicename> errors #listet die Fehler des Device auf
get <Devicename> devices #scan den Server nach Device</nowiki>

===Angeschlossene Geräte auslesen===
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.
Der Busmaster (zBsp ein DS9490r) selbst wird ebenfalls eingelesen und angezeigt.

===Definition von Geräten===
Es ist auch möglich, Geräte manuell anzulegen. Dies erfolgt in folgendem Format:

<nowiki>define <name> OWDevice <address> [<interval>]</nowiki>
zBsp:

<nowiki>define Vorlauftemp OWDevice 28.334F2B040000 60</nowiki>
Wobei der Wert 60 als Abfrageintervall in Sekunden zu verstehen ist.

===OWDevice State===
Bei Temperaturfühler wie DS18S20 wird das Reading "state" wie folgt ausgegeben:

<nowiki>temperature: 56.1875 alarm: 1</nowiki>
Um die Temperatur wie bei anderen Temperatur-Sensoren (zBsp. CUL_WS) anzuzeigen, hilft das Attribut "stateFormat". Dies kann wie folgt definiert werden:

<nowiki>attr <Devicename> stateFormat T: <wert></nowiki>
zBsp:

<nowiki>attr Boiler stateFormat T: temperature</nowiki>
alternativ

<nowiki>attr <Devicename> stateFormat {sprintf("%.1f",ReadingsVal("<Devicename>","temperature",0))."°C"}</nowiki>
Zusätzlich rundet das obenstehende Attribut mit "%.1f" die Temperatur auf eine Kommastelle.

==Tipps und Tricks==
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.

<nowiki>attr myEnergyMeter userReadings energy { (ReadingsVal("myEnergyMeter","count.A",0)+AttrVal("myEnergyMeter","myBasis",0))/1250.0;; }</nowiki>

==Anwendungsbeispiele==
[[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.

== Bekannte Probleme ==
=== Fhem hängt, wenn OWServer nicht erreichbar ist ===
Am Anfang gab es mit OWServer das Problem, dass Fhem immer komplett hing, wenn OWServer nicht erreichbar war (siehe z. 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.

[[Kategorie:1-Wire]]

DevelopmentReadingsAPI

2014-11-22T08:18:40Z

Neubert:

[[Kategorie:Development]]

== Abstract ==

Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand der Diskussion.

Ausgangspunkt ist [http://forum.fhem.de/index.php/topic,21247.0.html dieser Thread].

== Ausgangssituation ==

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.

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.

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.

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.

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.

== Zielsetzung ==

Es soll ein API eingeführt werden, das einen bzgl. Syntax und Semantik standardisierten Zugriff auf Readings, Attribute und Internals erlaubt.

Gehören Attribute und Internals wirklich hierher?
* 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.
* manche Devices legen aus der Definition abgeleitete Werte in Internals ab. Auch diese sollten externen Schnittstellen einheitlich zugänglich gemacht werden können.
* Attribute sind für den Endanwender gedacht. Was gibt es hier zu Standardisieren ausser den möglichen Werten?
* Eine externe Schnittstelle kennt die FHEM-interne Struktur nicht, soll aber ggf. trotzdem vereinheitlichen Zugriff auf die Konfiguration (= die Attribute) bekommen können.

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].

== Anforderungen an das API ==

# Funktionale Anforderungen
#* Es soll möglich sein einen aus den Werten von Readings, Attributen und Internals abgeleiteten Wert abzufragen
#* 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.
#* 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?
#* 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).
#* Es soll sich die Bedeutung eines abgeleiteten Wertes ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).
#* Es sollen sich bei physikalischen Größen Wert und Einheit ermitteln lassen.
#* 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, ...).
#* 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.
#* Es soll sich der Wertebereich ermitteln lassen. Ein Wertebereich könnte zur sinnvollen Skalierung analoger Werte (z.B. Slider) benutzt werden.
#* 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?
# Nichtfunktionale Anforderungen
#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.
#* das API soll abwärtskompatibel sein und einen (bidirektionalen) Zugriff auf bestehende Module ermöglichen.
#* Das API soll nur unwesentlichen Overhead bzgl. Speicherverbrauch und Verarbeitungszeiten erzeugen.
#* Es soll keine Vereinheitlichung von Readings-Namen erfolgen (temp, temperature) (das war früher einmal eine Forderung).

== Erste Überlegungen ==

* Einheiten alleine genügen nicht, es sollte die physikalische Größe bekannt sein, die von dem Reading repräsentiert wird (Temperatur, Druck, ...).
* Dazu eine Regel, in welcher Einheit diese physikalische Größe vorliegt.
* Es bringt keinen Zusatznutzen, die physikalische Größe am Reading verfügbar zu haben.
* Stattdessen meldet das Device, dass es einem Standard gehorcht (ein Interface implementiert, z.B "temperature").
* Ein GUI weiß dadurch, was es anzuzeigen hat.
* 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.
* An jedes Reading werden Metainformationen geklebt. Welche?
* Die Metainformationen könnten Zeiger in eine hierarchische Liste standardisierter Beschreibungen sein. Sind die [[DevelopmentInterfaces|Interfaces]] modellhaft?
* 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.
* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.
* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").
* 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.
* 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.
* 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.
* 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.

DevelopmentReadingsAPI

2014-11-21T20:36:44Z

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 …“

Strace verwenden

2014-07-23T07:07:53Z

Neubert:

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 werden. Dabei wird jeder Zeile ein Zeitstempel (aktuelle Uhrzeit) vorangestellt und die Dauer des Systemaufrufs in Sekunden in spitzen Klammern hintenangestellt.

Um nur Aufrufe von select und write zu sehen, kann man mit der Option
<pre>
-e trace=select,write
</pre>
vorfiltern. Näheres ist der Manpage von strace zu entnehmen.

Lang laufende Operationen (eine Sekunde oder länger) werden dann parallel dazu in einem anderen Terminal mit
<pre>
tail -f strace.log | grep -v '<0.'
</pre>
herausgefiltert.

Um herauszufinden, was die Filedeskriptoren bedeuten, wird der Befehl
<pre>
list .* FD
</pre>
auf der FHEM-Kommandozeile aufgerufen. Ist der Filedeskriptor nicht dabei, wird man im Verzeichnis
<pre>
/proc/PIDvonFHEM/fd
</pre>
fündig.

Um sich alle offenen Files, Sockets und Pipes anzusehen, dient der Befehl:
<pre>
lsof -p PIDvonFHEM
</pre>

[[Kategorie:HOWTOS]]

Strace verwenden

2014-07-21T14:31:13Z

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 …“