Mein FHEM
  1. Meine FHEM Konfiguration – notify mal anders
  2. Meine FHEM Konfiguration – Geräte an- und ausschalten für Fortgeschrittene
  3. Meine FHEM Konfiguration – dkUtils DAS Helferlein
  4. Meine FHEM Konfiguration – Fritzbox
  5. Meine FHEM Konfiguration – Schritt für Schritt

Um die Anzahl an Notify-Definitionen in FHEM zu reduzieren habe ich etwas experimentiert, so dass die Logik nicht mehr direkt über eine Notify erfolgt, sondern direkt in der Programmierung in Perl. Für meine Anwendungsfälle ist dies vollkommen ausreichend.

Hier ein Beispiel aus meiner 31_actions.cfg:


#########################################################################
## Notify für alle Actions
#########################################################################

define Action_notify notify (Action_.*) { dkRouteActions($NAME, $EVENT) }
attr Action_notify group Notifiers
attr Action_notify room System

Dieser Notify sorgt dafür, dann alle Events an die Funktion dkRouteActions geleitet werden.

Die korrespondierende PERL-Datei lautet 99_dkHandleActions.pm
Hier prüft die Funktion dkRouteActions zunächst, ob die Funktion dkAct_AKTIONSNAME vorhanden ist.

Beispiel: heißt das Gerät „Action_Panic“, so muss analog eine Funktion namens „dkAct_Action_Panic“ definiert sein.



#######################################
##
##
## ROUTES
##
##
#######################################

sub dkRouteActions($$) {
	my ($device, $event) = @_;
	my $action = "dkAct_" . $device;
	my $coderef=__PACKAGE__->can($action);
	if ($coderef) {
		$coderef->($event);
	}
}

Aus diese Weise könnt ihr nicht nur die Notify-Definitionen reduzieren, sondern auch die Logik komplett in PERL ausgliedern. Darüber hinaus müsst ihr nicht für jedes neue Gerät einen Notify anlegen, sondern könnt gleich in PERL die Funktion implementieren.

Lasst mich wissen, wie Ihr eure Programmierung optimiert und Overhead reduziert.