Modul 98_monitoring zur Überwachung von Geräten

Begonnen von igami, 09 März 2017, 22:12:42

Vorheriges Thema - Nächstes Thema

igami

Das ganze ist nun ofiziell in FHEM eingecheckt.
Die git repository kann mit
update delete https://raw.githubusercontent.com/Igami/monitoring-fhem/master/controls_monitoring.txt
wieder entfernt werden.

Einleitung:
Zitat
Jedes monitoring verfügt über eine warning- und eine error-Liste, welche als Readings gespeichert werden.
Beim auftreden eines definierten add-events wird das Gerät nach einer vorgegeben Zeit erst auf die warning-Liste gesetzt.
Nach einer weiteren vorgegeben Zeit wird das Gerät von der warning-Liste gelöscht und auf die error-Liste gesetzt.
Beim auftreten eines definierten remove-events wird das Gerät von beiden Listen gelöscht und noch laufende Timer abgebrochen.
Hiermit lassen sich auf einfache Weise Sammelmeldungen erstellen und durch zwei Attribute formatiert ausgeben.

Folgende Anwendungen sind möglich und werden unten beschrieben:

    geöffnete Fenster
    Batterie Warnungen
    Activity Monitor
    regelmäßige Wartungsarbeiten (z.B. Tischwasserfilter wechseln)
    Betriebsstunden abhängige Wartungsarbeiten (z.B. Beamer Filter reinigen oder Räume putzen)


Das monitor sendet selbst keine Benachrichtung, hierfür ist ein notify oder DOIF notwendig, welches auf das Event "<monitoring-name> error add: <name>" reagiert und dann den Rückgabewert von "get <monitoring-name> default" versendet.

Die folgenden beispiel Codes können per "Raw defnition" importiert werden.

Globale, flexible Fenster-/Tür-Offen-Meldungen (ähnlich wie im Forum beschrieben)

defmod Fenster_monitoring monitoring .*:(open|tilted) .*:closed
attr Fenster_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Fenster \"$errors[0]\" ist schon länger geöffnet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Fenster sind schon länger geöffnet:", @errors))\
}
attr Fenster_monitoring errorWait {AttrVal($name, "winOpenTimer", 60*10)}
attr Fenster_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Fenster \"$warnings[0]\" ist seit kurzem geöffnet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Fenster sind seit kurzem geöffnet:", @warnings))\
}

Sobald ein Gerät ein "open" oder "tilded" Event auslöst wird das Gerät auf die warning-Liste gesetzt und es wird ein Timer gestartet nach dessen Ablauf das Gerät von der warning- auf die error-Liste verschoben wird. Die Wartezeit kann für jedes Gerät per userattr "winOpenTimer" festgelegt werden. Der Vorgabewert sind 10 Minuten.
Sobald ein Gerät ein "closed" Event auslöst wird das Gerät von beiden Listen gelöscht und noch laufende Timer werden gestoppt.

Batterieüberwachung

defmod Batterie_monitoring monitoring .*:battery:.low .*:battery:.ok
attr Batterie_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Bei dem Gerät \"$errors[0]\" muss die Batterie gewechselt werden.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten muss die Batterie gewechselt werden:", @errors))\
}
attr Batterie_monitoring errorWait 60*60*24*14
attr Batterie_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Bei dem Gerät \"$warnings[0]\" muss die Batterie demnächst gewechselt werden.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräten muss die Batterie demnächst gewechselt werden:", @warnings))\
}

Sobald ein Gerät ein "battery: low" Event auslöst wird das Gerät auf die warning-Liste gesetzt und es wird ein Timer gestartet nach dessen Ablauf das Gerät von der warning- auf die error-Liste verschoben wird. Die Wartezeit ist auf 14 Tage eingestellt.
Sobald ein Gerät ein "battery: ok" Event auslöst wird das Gerät von beiden Listen gelöscht und noch laufende Timer werden gestoppt.

Activity Monitor

defmod Activity_monitoring monitoring .*:.*
attr Activity_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))\
}
attr Activity_monitoring errorWait 60*60*24
attr Activity_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräten haben sich seit mehr als 12 Stunden nicht mehr gemeldet", @warnings))\
}
attr Activity_monitoring warningWait 60*60*12

Geräte werden erst überwacht, wenn sie mindestens ein Event ausgelöst haben. Sollte das Gerät in 12 Stunden kein weiterer Event auslösen, wird es auf die warning-Liste gesetzt. Sollte das Gerät in 24 Stunden kein weiteres Event auslösen, wird es von der warning- auf die error-Liste verschoben.

regelmäßige Wartungsarbeiten (z.B. Tischwasserfilter wechseln)

defmod Wasserfilter_monitoring monitoring Wasserfilter_DashButton:.*:.short
attr Wasserfilter_monitoring errorReturn {return unless(@errors);;\
return "Der Wasserfilter muss gewechselt werden.";;\
}
attr Wasserfilter_monitoring errorWait 60*60*24*30
attr Wasserfilter_monitoring warningReturn {return unless(@warnings);;\
return "Der Wasserfilter muss demnächst gewechselt werden.";;\
}
attr Wasserfilter_monitoring warningWait 60*60*24*25

Hierbei wird ein DashButton genutzt um FHEM mitzuteilen, dass der Wasserfilter gewechselt wurde. Nach 30 Tagen wird der DashButton auf die error-Liste gesetzt.

regelmäßige Wartungsarbeiten (z.B. Räume putzen)

defmod putzen_DashButton dash_dhcp
attr putzen_DashButton allowed AC:63:BE:2E:19:AF,AC:63:BE:49:23:48,AC:63:BE:49:5E:FD,50:F5:DA:93:2B:EE,AC:63:BE:B2:07:78
attr putzen_DashButton devAlias ac-63-be-2e-19-af:Badezimmer\
ac-63-be-49-23-48:Küche\
ac-63-be-49-5e-fd:Schlafzimmer\
50-f5-da-93-2b-ee:Arbeitszimmer\
ac-63-be-b2-07-78:Wohnzimmer
attr putzen_DashButton event-min-interval .*:5
attr putzen_DashButton port 6767
attr putzen_DashButton userReadings state {return (split(":", @{$hash->{CHANGED}}[0]))[0];;}
attr putzen_DashButton widgetOverride allowed:textField-long devAlias:textField-long

defmod putzen_monitoring monitoring putzen_DashButton:.*:.short
attr putzen_monitoring errorFuncAdd {$event =~ m/^(.+):/;;\
$name = $1;;\
return 1;;\
}
attr putzen_monitoring errorReturn {return unless(@errors);;\
return("Der Raum \"$errors[0]\" muss wieder geputzt werden.") if(int(@errors) == 1);;\
return(join("\n - ", "Die folgenden Räume müssen wieder geputzt werden:", @errors))\
}
attr putzen_monitoring errorWait 60*60*24*7

Hierbei werden mehrere DashButton genutzt um FHEM mitzuteilen, dass die Räume geputzt wurden.
Nach 7 Tagen wird der Raum auf die error-Liste gesetzt.
Der Raum Name ist hierbei jedoch nicht der Geräte-Name, sondern der Readings-Name und wird in dem errorFuncAdd-Attribut geändert.

Betriebsstunden abhängige Wartungsarbeiten (z.B. Beamer Filter reinigen)

defmod BeamerFilter_monitoring monitoring Beamer_HourCounter:pulseTimeOverall BeamerFilter_DashButton:.*:.short
attr BeamerFilter_monitoring userattr errorInterval
attr BeamerFilter_monitoring errorFuncAdd {return 1\
   if(ReadingsVal($name, "pulseTimeOverall", 0) >= \
        ReadingsVal($name, "pulseTimeService", 0)\
      + (AttrVal($SELF, "errorInterval", 0))\
      && $addMatch\
   );;\
return;;\
}
attr BeamerFilter_monitoring errorFuncRemove {return unless($removeMatch);;\
fhem(\
    "setreading $name pulseTimeService "\
   .ReadingsVal($name, "pulseTimeOverall", 0)\
);;\
return 1;;\
}
attr BeamerFilter_monitoring errorInterval 60*60*200
attr BeamerFilter_monitoring errorReturn {return unless(@errors);;\
return "Der Filter vom Beamer muss gereinigt werden.";;\
}
attr BeamerFilter_monitoring warningFuncAdd {return}
attr BeamerFilter_monitoring warningFuncRemove {return}

Hierbei wird ein HourCounter genutzt um die Betriebsstunden eine Beamer zu erfassen und ein DashButton um FHEM mitzuteilen, dass der Filter gereinigt wurde.
Wurde der Filter länger als 200 Betriebsstunden nicht gereinigt wird das Gerät auf die error-Liste gesetzt. Wurde die Reinigung mit dem DashButton quittiert wird das Gerät von der error-Liste entfernt und der aktuelle Betriebsstunden-Stand in dem HourCounter Gerät gespeichert.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

igami

Schon 11 Mal runtergeladen und noch kein Feedback? ;)
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

mahowi

12mal...   ;)

Ich muß aber zugeben, ich habe es erstmal runtergeladen, um die commandref zu lesen und zu sehen, was das Modul überhaupt macht. Vielleicht solltest Du mal ein Anwendungsbeispiel hier posten.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

igami

Zitat von: mahowi am 10 März 2017, 20:48:24
Ich muß aber zugeben, ich habe es erstmal runtergeladen, um die commandref zu lesen und zu sehen, was das Modul überhaupt macht. Vielleicht solltest Du mal ein Anwendungsbeispiel hier posten.
Habe die Anwendugsbeispiele aus der commandref in den ersten Beitrag gepackt.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

ThomasMagnum

Hallo igami,

auch ich habe mir das gestern mal geladen und heute Morgen mal eingebaut.
Als erstes Beispiel habe ich direkt die Fensterüberwachung genommen, das hat schon mal einwandfrei geklappt und läuft ohne Fehler.

Wenn ich am Wochenende die Zeit finde, werde ich mal schauen wie ich das verwenden kann und in meine Umgebung einbauen kann. Mir fällt da spontan die Benachrichtigungen per Jabber ein, sobald verschiedene Bedingungen (Anwesenheit, Temperatur,...) gegeben sind. Dazu muss ich mir das aber mal genauer ansehen.

Gruß, Thomas

igami

Zitat von: ThomasMagnum am 11 März 2017, 07:45:10
Mir fällt da spontan die Benachrichtigungen per Jabber ein, sobald verschiedene Bedingungen (Anwesenheit, Temperatur,...) gegeben sind. Dazu muss ich mir das aber mal genauer ansehen.
Ich habe ein DOIF das inetwa so aussieht:

defmod ServiceNotifications_DI DOIF ([16:30-21:00|8]\
&& (   [":^error add:"]\
     || [$SELF:cmd_nr] == 2\
)\
)(\
  set TelegramBot message {(fhem("get TYPE=monitoring default"))}\
)\
DOELSEIF\
([":^error add:"])

attr ServiceNotifications_DI cmdState send notifications|notifications pending
attr ServiceNotifications_DI cmdpause 60*15
attr ServiceNotifications_DI do always
attr ServiceNotifications_DI icon time_automatic
attr ServiceNotifications_DI wait 60*15

Trifft ein "error add:" event ein wird 15 Minuten gewartet, dann bekomme ich eine Nachricht mit allen Sammelmeldungen. Passiert das außerhalb des Zeitraums wird es in die Warteschlange gepackt.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

igami

Neue Version im ersten Beitrag:
# changelog ###################################################################
# 170311:
#  - Fehler in der commandref behoben
#  - Versionsnummer eingebaut
#  - Logging erweitert
#  - Verhalten für Definitionen ohne remove-event mit non-preset Funktionen
#    verbessert
#  - monitoring_Get verbessert
# 170312: im Forum veroeffentlicht

Es ist auch ein neues Beispiel dazugekommen wie man Readings-Namen anstelle von Geräte-Namen auf die Liste setzen kann. Ich selbst nutze das im zusmamenhang mit dash_dhcp und Unifi da dort ein define mehrere Geräte als Readings beinhaltet.

Gibt es mittlerweile FeedBack? ;D
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

ThomasMagnum

Hallo igami,

ich hatte ja geschrieben das ich mich nochmal mit einem kleinen Feedback zum Modul melde, das möchte ich hiermit gerne tun.

Wie geschrieben, habe ich das Modul mal testweise in mein FHEM eingebaut und "spiele" mal mit der Fensterbenachrichtigung rum. Über ein kleines DOIF lass ich mir, sobald ein Gerät in den "error" Status gelangt, eine kurze Nachricht per Jabber zusenden. Das klappt bei einem meiner Fenstersensoren (HM) auch, andere hingegen werden zwar in den Status "warning" gesetzt, nicht aber in den Status "error". Selbst wenn ich Verbose auf 5 setze steht zur entsprechenden Zeit nichts im Eventlog.

Da ich allerdings einen "." im Namen habe und hier schon mehrfach gelesen habe das es damit immer wieder mal Probleme gibt vermute ich den Sensor als Ursache. Komisch ist nur, dass der funktinierende Sensor ebenfalls einen "." im Namen hat.

Bei Gelegenheit werde ich die Namensgebung deshalb mal überdenken und ändern.

Ansonsten vielen Dank für das Modul, da steckt in meinen Augen jede Menge an Potential drin.

Gruß, Thomas

dieter56

Hallo igami,

ich habe es mal ausprobiert und ich muss sagen, dass ich von dem Potenzial was drin steckt begeistert bin.

Ich habe schon Pläne, was ich damit machen werde.

Eine Anregung hätte ich schon: Schön wäre es, wenn der Übergang vom Warning- zum Error-Status (errorWait, warningWait) nicht nur eine Zeitangabe sondern auch EVENT-gesteuert möglich wäre. Z.B. Fenster-auf wird ERROR wenn die Temperatur im Raum unter einen bestimmten Wert fällt. Ideal wäre es, wenn man eine Bedingung wie in DOIF angeben könnte.

Etwa so: attr Fenster_monitoring errorWait ($DEVICE:measured_temp < 16)

Gruß
Dieter
Wilhelm II (deutscher Kaiser): "Ich glaube an das Pferd. Das Automobil ist eine vorübergehende Erscheinung." Gottlieb Daimler (Autoerfinder): "Die weltweite Nachfrage nach Kraftfahrzeugen wird eine Million nicht überschreiten – allein schon aus Mangel an verfügbaren Chauffeuren."

igami

#9
Habe das ganze nun mal auf Github gestellt.
Repository hinzufügen:

update add https://raw.githubusercontent.com/Igami/monitoring-fhem/master/controls_monitoring.txt

danach sollte das Modul per "update" aktualisiert werden.

CHANGED:
- bugfix:  98_monitoring.pm: monitoring_Set, monitoring_modify

Zitat von: ThomasMagnum am 15 März 2017, 09:25:23
Wie geschrieben, habe ich das Modul mal testweise in mein FHEM eingebaut und "spiele" mal mit der Fensterbenachrichtigung rum. Über ein kleines DOIF lass ich mir, sobald ein Gerät in den "error" Status gelangt, eine kurze Nachricht per Jabber zusenden. Das klappt bei einem meiner Fenstersensoren (HM) auch, andere hingegen werden zwar in den Status "warning" gesetzt, nicht aber in den Status "error". Selbst wenn ich Verbose auf 5 setze steht zur entsprechenden Zeit nichts im Eventlog.

Da ich allerdings einen "." im Namen habe und hier schon mehrfach gelesen habe das es damit immer wieder mal Probleme gibt vermute ich den Sensor als Ursache. Komisch ist nur, dass der funktinierende Sensor ebenfalls einen "." im Namen hat.
Es kann sein, dass es mit dem update von heute schon funktioniert. Da war noch ein Fehler drin.

Zitat von: dieter56 am 15 März 2017, 12:29:50
Ich habe schon Pläne, was ich damit machen werde.
An was denkst du denn so?

Zitat von: dieter56 am 15 März 2017, 12:29:50
Eine Anregung hätte ich schon: Schön wäre es, wenn der Übergang vom Warning- zum Error-Status (errorWait, warningWait) nicht nur eine Zeitangabe sondern auch EVENT-gesteuert möglich wäre. Z.B. Fenster-auf wird ERROR wenn die Temperatur im Raum unter einen bestimmten Wert fällt. Ideal wäre es, wenn man eine Bedingung wie in DOIF angeben könnte.
Wie würdest du denn die Zuordnung Fenster/Temperatursensor lösen?

Man könnte es andersrum lösen, man macht ein Monitoring für Temperatursensoren und in der errorFuncAdd prüft man ob im Raum ein Fenster geöffnet ist

defmod temperature_monitoring monitoring .+:temperature:.+
attr temperature_monitoring errorFuncAdd {my $room = AttrVal($name, "room", "Unsorted");;\
$room =~ s/ /./g;;\
$room =~ s/,/|/g;;\
\
return unless(\
      ReadingsVal($name, "temperature", 0) <= 16 \
   && devspec2array("room=.*".$room.".*:FILTER=state=(open|tilted)")\
);;\
return 1;;\
}
attr temperature_monitoring errorFuncRemove {my $room = AttrVal($name, "room", "Unsorted");;\
$room =~ s/ /./g;;\
$room =~ s/,/|/g;;\
\
return unless(\
      ReadingsVal($name, "temperature", 0) <= 16 \
   || devspec2array("room=.*".$room.".*:FILTER=state=(open|tilted)")\
);;\
return 1;;\
}
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

ThomasMagnum

Guten Morgen igami,

hab dein Update erst gesehen nachdem ich gestern Abend meine Namen geändert habe, macht aber nichts, da ich das eh bereinigen wollte.
Auf alle Fälle hat nach der Änderung und dem Update auf die neue Version alles so funktioniert wie erwartet - Vielen Dank!

Jetzt schau ich mal was damit alles umgesetzt werden kann. Das erste wird eine Batterieüberwachung sein, dann kommen Wartungsarbeiten rund ums Haus dran. Dank deiner Beispiele ist die dahinter stehende Logik ja sehr gut dokumentiert bzw. nachzuvollziehen.

Gruß, Thomas

igami

Zitat von: ThomasMagnum am 16 März 2017, 08:18:14
hab dein Update erst gesehen nachdem ich gestern Abend meine Namen geändert habe, macht aber nichts, da ich das eh bereinigen wollte.
Auf alle Fälle hat nach der Änderung und dem Update auf die neue Version alles so funktioniert wie erwartet - Vielen Dank!
Also klappt das mit dem update so ja schonmal, da bin ich beruhigt :)

Zitat von: ThomasMagnum am 16 März 2017, 08:18:14
Jetzt schau ich mal was damit alles umgesetzt werden kann. Das erste wird eine Batterieüberwachung sein, dann kommen Wartungsarbeiten rund ums Haus dran. Dank deiner Beispiele ist die dahinter stehende Logik ja sehr gut dokumentiert bzw. nachzuvollziehen.
Ich hoffe ja, dass ich das so universell gehalten habe, dass sich alles damit abdecken lässt. So viele verschiedene Arten gibt es meiner Meinung nach gar nicht.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

igami

Eine englische Commandref habe ich nun auch hinzugefügt und die deutsche ist nun auch als deutsche commandref vorhanden.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

igami

Gibt es noch weiteres Feedback zum Modul? Besonders interessiert mich ob irgendetwas nicht funktioniert. Ich würde das dann gerne in FHEM einchecken.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

igami

Bitte das git repository aus den update Quellen entfernen, das Modul ist nun ofiziell in FHEM eingecheckt.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED