2017-04-01T18:35:03Z

Rince: Kategorie Glossary zugeordnet

= MQTT Teil 2 =
Konzepte und best practices

== Vorwort ==
Wer den Teil 1 noch nicht gelesen hat, ist herzlich eingeladen das vorher noch schnell zu machen :)

[https://wiki.fhem.de/wiki/MQTT_Einf%C3%BChrung Hier ist Teil 1]

Dieser Artikel beschreibt, etwas trocken, weiterführend Konzepte und Denkweisen des Übertragungsprotokolls MQTT. Es wird etwas technischer als die Einführung und der ein oder andere Vergleich zu anderen Protokollen wird auch gezogen. Vieles davon kann man auch so nachlesen, wenngleich nicht immer auf deutsch. Ich gehe davon aus, dass der Leser MQTT vornehmlich mit FHEM einsetzen will.

Ein Beispielkurs ist in Planung. Dort werden wir die Konzepte praktisch kennen lernen.

== Retained Messages ==
=== Szenario ===
Stellen wir uns vor, wir starten FHEM neu. Wer Homematic Devices kennt weiß, spätestens nach einem Blick ins Logfile, dass nun zunächst ein Statusrequest aller Geräte erfolgt. Schließlich konnte sich zwischen Beenden und Neustart von FHEM etwas geändert haben.
* Homematic
* Es wird jedes Gerät angesprochen und abgefragt:
* "Lieber Lichtschalter, was tust du grade?"
* "Ich lasse das Licht über dir leuchten mein User."
MQTT hat hier ein anderes Konzept. Wenn in ein Topic gepostet wird, kann ein "retained Flag" gesetzt werden.

=== Das bedeutet ===
Die zuletzt gepostete Nachricht wird vom Broker nicht gelöscht. Publishen wir also den Status unseres Lichts:
* zuHause/1OG/Kueche/Licht/state "on" oder "off" + retained flag
Sobald wir dieses Topic auf einem Gerät subscriben, bekommen wir den Status angezeigt. Ein neu startendes FHEM ist so ein Fall.

Was bei Homematic erst über einen (zugegeben automatisierten Request) abläuft, kann MQTT mit den retained Messages auch so.

Trifft am Broker eine neue retained Message ein, so wird die alte Nachricht gelöscht. Zum absichtlichen Löschen einer retained Message, etwa weil man weiß, dass dieses Topic zukünftig nicht mehr benötigt wird, kann man eine leere Message posten.

=== Fazit ===
Retained Messages sind gut, um jeweils die letzte aktuelle Statusmeldung zu erhalten. Was damit nicht geht, ist z.B. die letzten 30 Messungen eines Temperatursensors zu speichern und auszuliefern! Sobald eine retained Message überschrieben wird, ist der alte Wert futsch.

== Last Will and Testament (LWT) ==
=== Szenario ===
Letzter Wille und Testament. <hr>
Unser batteriebetriebener Sensor hat keinen Strom mehr, das billige 5V Netzteil stellt seinen Dienst ein, ein netter Nachbar eröffnet ein neues WLAN Netz welches unser Bestehendes gnadenlos stört, unsere süßen kleinen Miezekatzen finden Patchkabel so spannend, dass sie es für erfolgreiche Beißübungen verwenden…
Gründe für einen Sensorausfall gibt es durchaus.
Was passiert in FHEM?
Der letzte Sensorwert bleibt im Reading stehen. Blöd wenn man erst abends feststellt, dass der Kühlschrank offen stand oder der Schaltbefehl zum Heizung einschalten nicht angekommen ist. Ersteres sorgt für aufgetautes Essen, letzteres für kalte Füße.
Wie fängt man das ab?
FHEM-seitig könnte man einen Watchdog oder ein DOIF einrichten. Es muss geprüft werden, ob sich das entsprechende Reading in einer bestimmten Zeit verändert hat. <hr>
Möglich.

=== MQTT Lösung ===
Der Letzte Wille, das Testament (LWT)

Beim Anmelden an einen Broker kann ein Last Will - Topic angegeben werden. Ebenso eine Payload. Wenn das Gerät verschwindet ohne sich sauber abgemeldet zu haben, wird der Broker die gewünschte Nachricht auf dem hinterlegten Topic publishen. Das retained Flag kann auch gesetzt werden.
Was bedeutet das für uns?

Zusätzlich zu:
*zuHause/1_OG/Kueche/Licht/state
*zuHause/1_OG/Kueche/Licht/set

könnten wir zusätzlich
* zuHause/1_OG/Kueche/Licht/status
definieren.

Beim Anmelden an den Broker schicken wir (mit retained flag) ein "online"
Als LWT geben wir das gleiche Topic an, aber mit "offline" und retained flag. Meldet sich unser Device sauber ab (disconnect), wird das LWT nicht verwendet. Es dient nur dazu, einen Fehler deutlich zu machen.

==== Vorsicht ====
LWT bezieht sich auf die Client ID. Was das schon wieder?
Jedes angemeldete Gerät hat eine einzige Client ID, unabhängig davon wie viele Topics es published und subscribed hat.
LWT auf ein Topic zu beziehen macht wenig Sinn, wenn es mehrere Topics auf dem Gerät gibt. Obiges Beispiel ist also gut, wenn an dem MC genau dieses eine Licht hängt!
* zuHause/1OG/Arduino_1
Ist der bessere Weg! Jetzt können wir in FHEM auf online / offline reagieren und den davon abhängigen Geräten eine Fehlerbehandlung spendieren. Da ist unser DOIF wieder :)

==== Noch eine Falle ====
Wer denkt, er wirft alle Geräte in ein einziges retained last will Topic, sieht immer nur die letzte Meldung!

Böse:

zuHause/MQTT/Status (<= nicht nachmachen)

=== Fazit ===
MQTT kann einen eleganten Weg bieten, über das Ende eines Gerätes zu informieren. Genau wie bei Homematic aber auch, muss man diese Meldungen auswerten um was sinnvolles damit anzufangen!
Im Fall eines einfachen Sensors ist es recht easy, bei einem Arduino Mega mit 30 Sensoren wird es dann aufwendig (außer man liest weiter bei den Filtern)

== Organisation der Topics ==
=== Basics, erlaubte Zeichen ===
MQTT erlaubt prinzipiell den kompletten UTF8 Zeichensatz.

Außer:
* U+0001..U+001F control characters
* U+007F..U+009F control characters

Theoretisch gehen also Umlaute, Leerzeichen etc. Praktisch kann es passieren, dass ein Endgerät mit Umlauten einfach nix anfangen kann. Leerzeichen sind auch ein Problem, weil UTF 8 davon doch recht viele Möglichkeiten bietet. Ich würde daher empfehlen, Topicbezeichnungen eher wie Gerätenamen in FHEM zu betrachten: Unterstriche statt Leerzeichen, Umlaute ausschreiben (=> ü => ue...)

Groß- und Kleinschreibung muss beachtet werden. Ein Topic muss mindestens ein Zeichen haben, um gültig zu sein. Oh, und $ gehen auch gar nicht. Die verwendet der Broker nämlich für Interna...

Schlechtes Beispiel:
* /zuHause/
* nicht ganz falsch, aber der / am Anfang ist nur zusätzlicher Overhead, daher weglassen

Wirklich falsch:
* zuHause//1_OG
* Hier wird ein leeres Topic definiert. Das ist ungültig.

=== Basics, Strukturierung ===
MQTT kennt publishen und subscriben.

FHEM kennt für jedes Gerät einen "state" und ein "set" Kommando. Das ist bei MQTT nicht nötig, aber durchaus sehr sinnvoll.

Nehmen wir wieder unseren Lichtschalter: Ein Taster an einem Arduino mit einem Relais nebst Lampe daran.

Unglücklich:
* zuHause/1_OG/Kueche/Lichtschalter
Wenn da ein "on" steht, woher will man wissen ob es sich um einen Befehl oder um eine Statusmeldung handelt? Daher bauen wir die FHEM übliche Logik einfach nach:

Etwas glücklicher (kann man machen, man kann es aber schwer filtern)
* zuHause/1_OG/Kueche/Lichtschalter/set
* zuHause/1_OG/Kueche/Lichtschalter/state

Richtig schlau (warum, kommt bei den Filtern)
* set/zuHause/1_OG/Kueche/Lichtschalter
* state/zuHause/1_OG/Kueche/Lichtschalter/state

Jetzt wird es einfach:

auf dem set-Topic publishen wir immer Schaltbefehle. Mit oder ohne retained flag, darüber kann man streiten. Unser Arduino muss also dieses Topic abhören und auswerten.

Das state-Topic nehmen wir um darauf zu publishen (hier ist retained einfeutig praktisch), wie der Zustand unserer Lampe gerade ist. Unser Arduino muss dieses Topic nur schreiben, niemals selber lesen.

Damit haben wir eine saubere Trennung von Befehl und Status erreicht.

=== Aufbau eines Topics ===
Wie bereits geschrieben, kann man die Topics recht frei einfach selbst erfinden. Sinnvoll ist es jedoch, jedem gewünschten Wert ein eigenes Topic zu spendieren.

Ungünstig:
* zuHause/state/1_OG/Kueche
* => In diesem Topic Licht, Temperatur, Luftfeuchte, Bewegungsmelder etc zu publishen ist eine nicht schlaue Idee; das Problem beginnt damit, dass man erst mal selber rausfinden muss, welchen Wert man gerade hat. Viel Programmcode für quasi umsonst; "on 20.3 66 motion" ist nun nicht wirklich toll.

Besser:
* zuHause/state/1_OG/Kueche/Licht
* zuHause/state/1_OG/Kueche/Raumtemperatur
* zuHause/state/1_OG/Kueche/Luftfeuchte
* zuHause/state/1_OG/Kueche/Bewegungsmelder
=> Auf diese Weise weiß man vorher, welche (Zahlen)werte in einem Topic stehen und was sie bedeuten. Das hat man automatisch durch die geschickte Topic Wahl festgelegt.

=== Filter ===
Eine witzige Sache von MQTT sind Filter. Das ist in etwa wie in FHEM eine readingsGroup für Arme. Wir möchten schnell einen Überblick haben, welchen Status bestimmte Devices haben.

Es gibt zwei Arten von Filtern:
* Single Level Filter: +
* Multi Level Filter: #

Beispiele:
* zuHause/state/1_OG/Kueche/Temperatur
* zuHause/state/1_OG/Kueche/Kuehlschrank/Temperatur
* zuHause/state/1_OG/Kueche/Licht
* zuHause/state/1_OG/Wohnzimmer/Licht
* zuHause/state/1_OG/Schlafzimmer/Licht

Jetzt filtern wir:

"#" => muss immer der letzte Filter sein (es gibt Broker, die die # auch als Platzhalter innerhalb eines Topics erlauben, aber Standard ist das nicht)

* zuHause/state/# => gibt uns alle oben genannten Beispiel-Topics zurück
* zuHause/state/1_OG/+/Licht => gibt uns das Licht der Küche, des Wohn- und des Schlafzimmers
* zuHause/state/1_OG/+/Temperatur => gibt nur die Küchentemperatur (+ steht für genau 1 Topic, der Kühlschrank fällt also nicht in das Muster)

=== Diskussionspunkt, Devicenamen ===
Manchmal liest man auch den Tip, eine eindeutige Gerätebezeichnung in das Topic mit aufzunehmen.
* Arduino_1/state/Zimmer_1/Licht
* Arduino_1/state/Zimmer_1/Temperatur
* Arduino_1/state/Zimmer_2/Licht
* Arduino_2/state/Zimmer_3/Licht

Hat im wesentlichen folgenden Vorteil:

Wenn ich mir nur ansehen will, was ein bestimmter Mikrocontroller published, kann ich ihn sehr einfach filtern.
* Arduino_1/# => perfekt um alle Werte des Arduino_1 zu lesen und sonst nichts

Nachteilig:

Tauscht man später den Controller aus, muss man ihn wieder so nennen. Fasst man später Arduino_1 und Arduino_2 auf einem Arduino Mega zusammen, stimmen die Topics schlicht nicht mehr und man muss seine ganzen Devicenamen anpassen.

== Der Artikel hast "Best Practices" versprochen - wo sind sie? ==
Schwierig. Was die Benennung der Topics betrifft, so vom Zeichensatz her, gibt es Regeln und best practices, die stehen oben.

Ob man jetzt eindeutige Gerätenamen vorne weg schreibt, oder ob man state und set weiter vorne im Topic Tree unterbringt oder hinten, ich fürchte da gibt es keine allgemein gültigen Regeln. MQTT lässt einem hier alle Freiheiten.

Das eine sieht eher nach FHEM aus (set und state am Ende), das andere lässt sich besser filtern.
Hardcoreuser könnten auch auf die Idee kommen, einfach beide Varianten gleichzeitig zu nutzen. Für FHEM alleine ist das sicherlich nicht hilfreich (aber auch nicht störend).

== Schlusswort ==
Hier endet vorübergehend unser kleiner Exkurs zu MQTT.

Wer Fragen der Anregungen hat, bitte im [https://forum.fhem.de/index.php/topic,69701.0.html Diskussionsthread dieses Artikels] stellen.

Weiterhin haben wir ganz neu [https://forum.fhem.de/index.php/board,94.0.html einen eigenen Forumsbereich für MQTT].

Je nachdem wie gut die Artikelserie ankommt, werde ich einen Teil 3 auflegen. Dieser ist dann zum "get your hands dirty", zum Hände dreckig machen. Darin könnte ein kleiner Programmierkurs in der Arduino IDE kommen. Mir schwebt vor, einen kleinen Sketch zu nehmen, diesen mit MQTT auszurüsten und nach und nach die Dinge wie LWT, retained messages etc. einzubauen. Das ist im wesentlichen mit wenigen Änderungen möglich. Also durchaus anfängertauglich.

Ich werde einen Arduino Uno oder Mega nehmen, sowie ein Ethernetshield mit W5100 Chip benutzen. Die Dinger kosten keine 6 € auf eBay. Die ENC28J60 (oder ähnliche) Chips werden explizit NICHT unterstützt werden! Wer lieber einen ESP8266 nimmt, der sei an dieser Stelle auf das Template von Pf@nne verwiesen [https://forum.fhem.de/index.php/topic,50238.0.html hier zu finden].

[[Kategorie:Glossary]]

2017-03-27T08:39:26Z

Rince:

== Kategorisierung Artikel ==
In welche Kategorie gehört das? Kann es bitte wer in passende Kategorien einsortieren? [[Benutzer:Rince|Rince]] ([[Benutzer Diskussion:Rince|Diskussion]]) 10:19, 22. Mär. 2017 (CET)
<hr>
:Bist Du denn mit dem Artikel fertig oder wird der noch fortgesetzt? Bisher würde ich den Artikel in Glossary einordnen, da allgemeine Begriffserklärung und keine direkten Angaben zu MQTT in FHEM. Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 13:41, 24. Mär. 2017 (CET)
<hr>
:Dieser ist denke ich soweit fertig, außer es finden sich Fehler darin, oder es beschließt jemand ihn völlig anders zu schreiben. Glossary gefällt mir denke ich gut. Es folgt noch ein weiterer Artikel, der sich etwas genauer mit MQTT Dingen beschäftigt. Diese werden nach und nach mehr Bezug zu FHEM bekommen. [[Benutzer:Rince|Rince]] ([[Benutzer Diskussion:Rince|Diskussion]]) 10:39, 27. Mär. 2017 (CEST)

2015-08-04T10:43:33Z

Rince: /* Benötigte Frameworks */

{{Todo|Das wird die Doku für den optischen Sensor. Der Programmcode ist ziemlich weit gediehen. Ich dachte mir, die Doku mal zum Start eines Projekts fertig zu haben, ist auch nicht schlecht}}


==Was ich noch nicht weiß==
* soll das Programm regelmäßig per Cron ausgeführt werden, oder ist es schlauer einen WebSocket zu öffnen, so dass fhem dem Programm sagen kann, wenn es ein Bild bearbeiten soll
* <s>Treshold für Farben im Programm anwenden,</s> oder nackten Zähler direkt an fhem senden
** besser, eine Weiterverarbeitung der Werte in fhem
** fhem ist diesbezüglich viel mächtiger

==Übersicht==
Das kleine Programm liest ein Farbbild ein. Anschließend werden (in definierbaren Bereichen) Farbwerte ermittelt. Das Resultat wird dann an fhem gesendet.

Wozu ist das gut?

Mein Anwendungsfall:

Eine USB Kamera am Raspberry macht regelmäßig Bilder meiner Küche. Darin sind insbesondere die Geschirrspülmaschine und der Herd zu sehen. Wenn meine Geschirrspülmaschine Dinge wie Salz oder Klarspüler benötigt, leuchtet eine entsprechende LED rot auf. Das kann das Programm erkennen und fhem mitteilen.
Ähnlich beim Herd: ist der an, leuchtet es gelb. Beim Verlassen des Hauses kann mir fhem sagen, dass der Herd noch an ist...

Wichtig:
Die Kamera darf nicht bewegt werden, sonst funktionieren die Masken nicht mehr! Also z.B. festschrauben...

Anderer Anwendungsfall:

Ein Bild (z.B. Bodenfeuchte) vom DWD runterladen (das müsst ihr selbst!), dann analysieren lassen, welche Bodenfeuchte bei euch ist. Selbiges wird an fhem gesendet.

Einfach für jede mögliche Farbe eine eigene Maske erstellen (die ist natürlich identisch), in die conf die Farbwerte und die setreadings schreiben, fertig...

{{Link2Forum|Topic=39678|LinkText=Forumsthread}}

==Beschreibung==
Ein bisschen mehr ins Detail gehend:

Das Programm erwartet ein farbiges Bitmap Bild. Anschließend werden Masken über das Bild gelegt. Was übrig bleibt (idealerweise also der Bildausschnitt wo die entsprechende LED zu sehen ist) wird in den HSV Farbraum konvertiert. Eine Beschreibung warum und wie er funktioniert, folgt noch. Dann werden Die gewünschten Farben gefiltert. Intern übrig bleiben dann einige weiße Pixel auf schwarzem Grund. Die werden schlicht gezählt. Der Wert wird an fhem gesendet.

===Konfiguration der Software===
Das Programm an sich benötigt eine Config-Datei.
<pre>
{
"fhem_host_port": "http://192.168.5.31:8083",
"fhem_request": "/fhem?cmd=",
"different_ROI": "5",
"path_to_picture": "./Picture",
"picture": "picture_kitchen",
"type": "jpg",
"mask": "dishwasher",
...

</pre>

Was ist hier einzustellen?
* "fhem_host_port": Adresse des fhem Servers, ebenso wie der Port. (Muss man also anpassen)
* "fhem_request": (weiß nicht, wie es heißt), sollte aber so passen
* "different_ROI": ist spannend: hier sagt man, wie viele LEDs (ROI = region of interesst) man überwachen will. (für jede ROI muss genau 1 Maske existieren)
* "path_to_picture": logisch, wo liegt das Bild? In diesem Fall in einem Unterordner Namens Picture
* "picture": der Name des Bildes (aufgemerkt: das Programm geht also immer vom gleichen Dateinamen aus!) (Quellbild)
* "type": bitte mit angeben; jpg, png...
* "mask": der erste Teil des Maskennamens
** die Dateiendung nicht angeben, bitte die gleiche wie beim Quellbild verwenden
** so kann man bei einem Quellbild verschiedene Masken angeben (in verschiedenen Config Dateien)
** bei Karten vom DWD z.B. kann man so aus einem Quellbild Werte für verschiedene Regionen ermitteln
** munic.conf, berlin.conf
** bei mehr Küchengeräten z.B. dishwasher.conf und waterboiler.conf

===Was sind diese Masken?===
Die sind cool. Einfache schwarz/weiß Bilder.

Zum erstellen:
Ein Musterbild von der Kamera besorgen. In Gimp öffnen, den Bereich um eine der gewünschten LEDs ein Viereck oder ein Kreis, ist egal) markieren. Löschen, Füllfarbe weiß. Markierung umdrehen, löschen, Füllfarbe schwarz. Fertig.

Stellt euch vor, die Maske wäre aus Tonpapier. Da wo weiß ist, ist ein Loch drin. Die Maske wird über das Bild gelegt. Nun seht ihr nur noch die gewünschte LED...

Wichtig:

Die Maske braucht nun einen festen Dateinamen, damit sie gefunden werden kann! Hängt an den in der Config angegebenen Dateinamen ein _mask_1 an, für eure erste Maske. Hättet ihr ROI = 1, ist das alles. Bei ROI = 2 wollen wir 2 Masken abarbeiten.

Also, bei ROI = 3
* quellbild.jpg (das, was eure Kamera immer generiert, oder euch der DWD zur Verfügung stellt)
* <AngegebenerName>_mask_1.jpg (die Dateiendung bitte wie beim Quellbild)
* <AngegebenerName>_mask_2.jpg
* <AngegebenerName>_mask_3.jpg

===Benötigte Frameworks===
folgt noch

*Linux
*[http://www.pyimagesearch.com/2015/02/23/install-opencv-and-python-on-your-raspberry-pi-2-and-b/ Diese] Anleitung ist wirklich gut. Habe es auf meinem RasPi auch so gemacht.

*Windows
*bei Bedarf gerne

===Kalibrierung des Sensors===

==Programmcode==
Der Programmcode ist im ersten Forumsthread mit einigen Beispielen zum Download.
[http://forum.fhem.de/index.php/topic,39678.msg318865.html#msg318865 Download]

===Sensor===
Anmerkung:

Ich bin kein Programmierer. Wenn das jemand durchliest der Ahnung hat, sich totlacht => ich übernehme keine Verantwortung
<pre>
#!/usr/bin/env python
# Optical Sensor
# using Python 2.7 and OpenCV 2.4.11
# do not use german umlauts, not even in description
# ver 0.2 first public release
import cv2
import argparse
import json
import urllib
import numpy as np

#cv2 importiert OpenCV
#argparse wird benoetigt fuer die Parameteruebergabe
#json zum lesen des Config-Files
#urllib um uns mit fhem zu unterhalten

# construct the argument parse and parse the arguments
ap = argparse.ArgumentParser()
ap.add_argument("-c", "--conf", required=True,
help="path to the JSON configuration file; eg try: >sensor.py --conf dishwasher.json")
args = vars(ap.parse_args())

#ConfigFile laden
conf = json.load(open(args["conf"]))
client = None

#Gespeichertes Bild mit Pfad in Variable
path = (conf["path_to_picture"])
picture = (conf["picture"])
type = (conf["type"])
first_picture = path + "/" + picture + "." + type

#Namen der Maske auslesen
first_mask = (conf["mask"])

#Laden des Bildes
image = cv2.imread(first_picture)

# Bild anzeigen
#cv2.imshow("Originalbild", image)

# Schleife erzeugen
ROI = int(conf["different_ROI"])

print "Soll-Durchlaeufe " + str(ROI)

i = 0
while i < ROI:
i = i + 1

# Maskenpfad und Dateinamen generieren
mask = path + "/" + first_mask + "_mask_" + str(i) + "." + type

# Maske laden
mask = cv2.imread(mask,0)

# Maske anwenden
masked = cv2.bitwise_and(image, image, mask = mask)
#cv2.imshow("Maske", masked)

# BGR in HSV konvertieren wenn gewollt
if conf["hsv"]:
masked = cv2.cvtColor(masked, cv2.COLOR_BGR2HSV)
#cv2.imshow("HSV", masked)

# Grenzwerte aus Config auslesen
lower_col_value = tuple(conf["lower_col" + "_" + str(i)])
upper_col_value = tuple(conf["upper_col" + "_" + str(i)])
#print lower_col
#print upper_col

# Range definieren
lower_col = np.array([(lower_col_value)], dtype=np.uint8)
upper_col = np.array([(upper_col_value)], dtype=np.uint8)

# Threshold the image to get only selected colors
mask = cv2.inRange(masked, lower_col, upper_col)
#cv2.imshow("Maske", mask)

# Pixel zaehlen
white = cv2.countNonZero(mask)
print('The number of positive pixels is: ' + str(white))

# Pixelanzahl an fhem senden
# fhem Kommando erzeugen
url = (conf["fhem_host_port"])
request = (conf["fhem_request"])
command = (conf["fhem_command" + "_" + str(i)])
value = "%20" + str(white)
fhem = url + request + command + value
#print fhem
urllib.urlopen(fhem)

#cv2.waitKey(0)

print "Fertig"
#cv2.waitKey(0)
cv2.destroyAllWindows()
</pre>

===Config-File===
So kann ein Config File aussehen

5seenland.json (könnte ein guter Dateinname sein...)
<pre>
{
"config_version": "0.2",
"fhem_host_port": "http://192.168.5.31:8083",
"fhem_request": "/fhem?cmd=",
"different_ROI": "8",
"path_to_picture": "./Picture",
"picture": "bodenfeuchte",
"type": "png",
"mask": "5seenland",
"hsv": false,
"lower_col_1": [45,100,200],
"upper_col_1": [45,100,200],
"lower_col_2": [60,200,250],
"upper_col_2": [60,200,250],
"lower_col_3": [75,250,250],
"upper_col_3": [75,250,250],
"lower_col_4": [75,250,200],
"upper_col_4": [75,250,200],
"lower_col_5": [75,220,150],
"upper_col_5": [75,220,150],
"lower_col_6": [75,150,75],
"upper_col_6": [75,150,75],
"lower_col_7": [250,200,50],
"upper_col_7": [250,200,50],
"lower_col_8": [250,0,0],
"upper_col_8": [250,0,0],
"fhem_command_1": "setreading%20Bodenfeuchte%200-10",
"fhem_command_2": "setreading%20Bodenfeuchte%2010-30",
"fhem_command_3": "setreading%20Bodenfeuchte%2030-50",
"fhem_command_4": "setreading%20Bodenfeuchte%2050-80",
"fhem_command_5": "setreading%20Bodenfeuchte%2080-95",
"fhem_command_6": "setreading%20Bodenfeuchte%2095-100",
"fhem_command_7": "setreading%20Bodenfeuchte%20100-105",
"fhem_command_8": "setreading%20Bodenfeuchte%20105-"
}
</pre>

Eigentlich ganz einfach. Für jede ROI benötigt man lower_col_?, upper_col_? und fhem_command_?

Die lower/upper cols definieren für jede ROI den zu suchenden Farbbereich... das Ergebnis wird dann an den fhem_command_? angehängt.

Hat man nur 2 ROI, kann man die Werte 4-8 natürlich rauswerfen; andernfalls werden sie schlicht ignoriert, tun also auch nicht weh. Sind nur eben sinnbefreit.

===Beispiel mit Bildern===
Ist denke ich im Forumsthread schon ganz schön beschrieben.

Wer eigene Beispiele hat, immer her damit :)

Optischer Sensor, Software

2015-08-04T10:33:30Z

Rince: /* Config-File */

{{Todo|Das wird die Doku für den optischen Sensor. Der Programmcode ist ziemlich weit gediehen. Ich dachte mir, die Doku mal zum Start eines Projekts fertig zu haben, ist auch nicht schlecht}}


==Was ich noch nicht weiß==
* soll das Programm regelmäßig per Cron ausgeführt werden, oder ist es schlauer einen WebSocket zu öffnen, so dass fhem dem Programm sagen kann, wenn es ein Bild bearbeiten soll
* <s>Treshold für Farben im Programm anwenden,</s> oder nackten Zähler direkt an fhem senden
** besser, eine Weiterverarbeitung der Werte in fhem
** fhem ist diesbezüglich viel mächtiger

==Übersicht==
Das kleine Programm liest ein Farbbild ein. Anschließend werden (in definierbaren Bereichen) Farbwerte ermittelt. Das Resultat wird dann an fhem gesendet.

Wozu ist das gut?

Mein Anwendungsfall:

Eine USB Kamera am Raspberry macht regelmäßig Bilder meiner Küche. Darin sind insbesondere die Geschirrspülmaschine und der Herd zu sehen. Wenn meine Geschirrspülmaschine Dinge wie Salz oder Klarspüler benötigt, leuchtet eine entsprechende LED rot auf. Das kann das Programm erkennen und fhem mitteilen.
Ähnlich beim Herd: ist der an, leuchtet es gelb. Beim Verlassen des Hauses kann mir fhem sagen, dass der Herd noch an ist...

Wichtig:
Die Kamera darf nicht bewegt werden, sonst funktionieren die Masken nicht mehr! Also z.B. festschrauben...

Anderer Anwendungsfall:

Ein Bild (z.B. Bodenfeuchte) vom DWD runterladen (das müsst ihr selbst!), dann analysieren lassen, welche Bodenfeuchte bei euch ist. Selbiges wird an fhem gesendet.

Einfach für jede mögliche Farbe eine eigene Maske erstellen (die ist natürlich identisch), in die conf die Farbwerte und die setreadings schreiben, fertig...

{{Link2Forum|Topic=39678|LinkText=Forumsthread}}

==Beschreibung==
Ein bisschen mehr ins Detail gehend:

Das Programm erwartet ein farbiges Bitmap Bild. Anschließend werden Masken über das Bild gelegt. Was übrig bleibt (idealerweise also der Bildausschnitt wo die entsprechende LED zu sehen ist) wird in den HSV Farbraum konvertiert. Eine Beschreibung warum und wie er funktioniert, folgt noch. Dann werden Die gewünschten Farben gefiltert. Intern übrig bleiben dann einige weiße Pixel auf schwarzem Grund. Die werden schlicht gezählt. Der Wert wird an fhem gesendet.

===Konfiguration der Software===
Das Programm an sich benötigt eine Config-Datei.
<pre>
{
"fhem_host_port": "http://192.168.5.31:8083",
"fhem_request": "/fhem?cmd=",
"different_ROI": "5",
"path_to_picture": "./Picture",
"picture": "picture_kitchen",
"type": "jpg",
"mask": "dishwasher",
...

</pre>

Was ist hier einzustellen?
* "fhem_host_port": Adresse des fhem Servers, ebenso wie der Port. (Muss man also anpassen)
* "fhem_request": (weiß nicht, wie es heißt), sollte aber so passen
* "different_ROI": ist spannend: hier sagt man, wie viele LEDs (ROI = region of interesst) man überwachen will. (für jede ROI muss genau 1 Maske existieren)
* "path_to_picture": logisch, wo liegt das Bild? In diesem Fall in einem Unterordner Namens Picture
* "picture": der Name des Bildes (aufgemerkt: das Programm geht also immer vom gleichen Dateinamen aus!) (Quellbild)
* "type": bitte mit angeben; jpg, png...
* "mask": der erste Teil des Maskennamens
** die Dateiendung nicht angeben, bitte die gleiche wie beim Quellbild verwenden
** so kann man bei einem Quellbild verschiedene Masken angeben (in verschiedenen Config Dateien)
** bei Karten vom DWD z.B. kann man so aus einem Quellbild Werte für verschiedene Regionen ermitteln
** munic.conf, berlin.conf
** bei mehr Küchengeräten z.B. dishwasher.conf und waterboiler.conf

===Was sind diese Masken?===
Die sind cool. Einfache schwarz/weiß Bilder.

Zum erstellen:
Ein Musterbild von der Kamera besorgen. In Gimp öffnen, den Bereich um eine der gewünschten LEDs ein Viereck oder ein Kreis, ist egal) markieren. Löschen, Füllfarbe weiß. Markierung umdrehen, löschen, Füllfarbe schwarz. Fertig.

Stellt euch vor, die Maske wäre aus Tonpapier. Da wo weiß ist, ist ein Loch drin. Die Maske wird über das Bild gelegt. Nun seht ihr nur noch die gewünschte LED...

Wichtig:

Die Maske braucht nun einen festen Dateinamen, damit sie gefunden werden kann! Hängt an den in der Config angegebenen Dateinamen ein _mask_1 an, für eure erste Maske. Hättet ihr ROI = 1, ist das alles. Bei ROI = 2 wollen wir 2 Masken abarbeiten.

Also, bei ROI = 3
* quellbild.jpg (das, was eure Kamera immer generiert, oder euch der DWD zur Verfügung stellt)
* <AngegebenerName>_mask_1.jpg (die Dateiendung bitte wie beim Quellbild)
* <AngegebenerName>_mask_2.jpg
* <AngegebenerName>_mask_3.jpg

===Benötigte Frameworks===
folgt noch

===Kalibrierung des Sensors===

==Programmcode==
Der Programmcode ist im ersten Forumsthread mit einigen Beispielen zum Download.
[http://forum.fhem.de/index.php/topic,39678.msg318865.html#msg318865 Download]

===Sensor===
Anmerkung:

Ich bin kein Programmierer. Wenn das jemand durchliest der Ahnung hat, sich totlacht => ich übernehme keine Verantwortung
<pre>
#!/usr/bin/env python
# Optical Sensor
# using Python 2.7 and OpenCV 2.4.11
# do not use german umlauts, not even in description
# ver 0.2 first public release
import cv2
import argparse
import json
import urllib
import numpy as np

#cv2 importiert OpenCV
#argparse wird benoetigt fuer die Parameteruebergabe
#json zum lesen des Config-Files
#urllib um uns mit fhem zu unterhalten

# construct the argument parse and parse the arguments
ap = argparse.ArgumentParser()
ap.add_argument("-c", "--conf", required=True,
help="path to the JSON configuration file; eg try: >sensor.py --conf dishwasher.json")
args = vars(ap.parse_args())

#ConfigFile laden
conf = json.load(open(args["conf"]))
client = None

#Gespeichertes Bild mit Pfad in Variable
path = (conf["path_to_picture"])
picture = (conf["picture"])
type = (conf["type"])
first_picture = path + "/" + picture + "." + type

#Namen der Maske auslesen
first_mask = (conf["mask"])

#Laden des Bildes
image = cv2.imread(first_picture)

# Bild anzeigen
#cv2.imshow("Originalbild", image)

# Schleife erzeugen
ROI = int(conf["different_ROI"])

print "Soll-Durchlaeufe " + str(ROI)

i = 0
while i < ROI:
i = i + 1

# Maskenpfad und Dateinamen generieren
mask = path + "/" + first_mask + "_mask_" + str(i) + "." + type

# Maske laden
mask = cv2.imread(mask,0)

# Maske anwenden
masked = cv2.bitwise_and(image, image, mask = mask)
#cv2.imshow("Maske", masked)

# BGR in HSV konvertieren wenn gewollt
if conf["hsv"]:
masked = cv2.cvtColor(masked, cv2.COLOR_BGR2HSV)
#cv2.imshow("HSV", masked)

# Grenzwerte aus Config auslesen
lower_col_value = tuple(conf["lower_col" + "_" + str(i)])
upper_col_value = tuple(conf["upper_col" + "_" + str(i)])
#print lower_col
#print upper_col

# Range definieren
lower_col = np.array([(lower_col_value)], dtype=np.uint8)
upper_col = np.array([(upper_col_value)], dtype=np.uint8)

# Threshold the image to get only selected colors
mask = cv2.inRange(masked, lower_col, upper_col)
#cv2.imshow("Maske", mask)

# Pixel zaehlen
white = cv2.countNonZero(mask)
print('The number of positive pixels is: ' + str(white))

# Pixelanzahl an fhem senden
# fhem Kommando erzeugen
url = (conf["fhem_host_port"])
request = (conf["fhem_request"])
command = (conf["fhem_command" + "_" + str(i)])
value = "%20" + str(white)
fhem = url + request + command + value
#print fhem
urllib.urlopen(fhem)

#cv2.waitKey(0)

print "Fertig"
#cv2.waitKey(0)
cv2.destroyAllWindows()
</pre>

===Config-File===
So kann ein Config File aussehen

5seenland.json (könnte ein guter Dateinname sein...)
<pre>
{
"config_version": "0.2",
"fhem_host_port": "http://192.168.5.31:8083",
"fhem_request": "/fhem?cmd=",
"different_ROI": "8",
"path_to_picture": "./Picture",
"picture": "bodenfeuchte",
"type": "png",
"mask": "5seenland",
"hsv": false,
"lower_col_1": [45,100,200],
"upper_col_1": [45,100,200],
"lower_col_2": [60,200,250],
"upper_col_2": [60,200,250],
"lower_col_3": [75,250,250],
"upper_col_3": [75,250,250],
"lower_col_4": [75,250,200],
"upper_col_4": [75,250,200],
"lower_col_5": [75,220,150],
"upper_col_5": [75,220,150],
"lower_col_6": [75,150,75],
"upper_col_6": [75,150,75],
"lower_col_7": [250,200,50],
"upper_col_7": [250,200,50],
"lower_col_8": [250,0,0],
"upper_col_8": [250,0,0],
"fhem_command_1": "setreading%20Bodenfeuchte%200-10",
"fhem_command_2": "setreading%20Bodenfeuchte%2010-30",
"fhem_command_3": "setreading%20Bodenfeuchte%2030-50",
"fhem_command_4": "setreading%20Bodenfeuchte%2050-80",
"fhem_command_5": "setreading%20Bodenfeuchte%2080-95",
"fhem_command_6": "setreading%20Bodenfeuchte%2095-100",
"fhem_command_7": "setreading%20Bodenfeuchte%20100-105",
"fhem_command_8": "setreading%20Bodenfeuchte%20105-"
}
</pre>

Eigentlich ganz einfach. Für jede ROI benötigt man lower_col_?, upper_col_? und fhem_command_?

Die lower/upper cols definieren für jede ROI den zu suchenden Farbbereich... das Ergebnis wird dann an den fhem_command_? angehängt.

Hat man nur 2 ROI, kann man die Werte 4-8 natürlich rauswerfen; andernfalls werden sie schlicht ignoriert, tun also auch nicht weh. Sind nur eben sinnbefreit.

===Beispiel mit Bildern===
Ist denke ich im Forumsthread schon ganz schön beschrieben.

Wer eigene Beispiele hat, immer her damit :)