Helligkeitssensor - Empfehlung?

Begonnen von Pi_01, 30 Juli 2020, 09:17:13

Vorheriges Thema - Nächstes Thema

Pi_01

Ich möchte bestimmte Teile meiner FHEM-Automatisierung von einem Helligkeitssensor abhängig machen.

Welche Variante ist die eleganteste?

Wenn ich beispielsweise einen ganz normalen Fotowiderstand über ein MCP3008-Modul an meinem Raspberry anschließe, kann ich dann trotzdem mittels FHEM die Werte abfragen?

Oder müsste ich dann über eine Zwischenlösung (z.B. Datenbankeintrag) gehen?

dora71

Hallo,

ich benutze zur Zeit ein "Duo", bestehend aus einem LDR (Fotowiderstand) und dem Luxmeter BH1750.

Der LDR geht auf den Analog-Eingang, das Luxmeter benutzt den I2C-Bus eines Wemos D1 Mini.
Der sendet dann in regelmäßigen Abständen (z. Zt. alle 10 min.) seine Werte via WLAN über MQTT. Dazwischen schicke ich ihn in den DeepSleep Modus, da das Teil akkubetrieben läuft.
Der Sketch ist teilweise selbst geschrieben, teilweise aus dem Internet zusammengesucht. In nächster Zeit will ich den Sketch noch so erweitern, dass ich in der Dämmerungsphase mehr Werte bekomme, dafür tagsüber und nachts weniger Werte (Akkulaufzeit verlängern). Dafür muss ich das Teil aber noch weiter bei unterschiedlichem Wetter beobachten.

Meine Erfahrung: Gerade bei der Dämmerung ist der LDR empfindlicher (und meistens will man den Teil ja auswerten), dafür hat das Luxmeter einen größeren Wertebereich (besser um z. B. eine Beschattungs-Steuerung aufzubauen).

Das MCP3008-Modul kenne ich nicht.

Vorteil dieser Lösung: Du kannst den Sensor hinhängen, wo Du willst (innerhalb der WLAN Reichweite). Ansonsten bist Du ja auf gewisse Grenzen festgelegt, wo Dein Pi steht.

Gruß Rainer

Beta-User

...gibt sicher viele Möglichkeiten, hier noch 1,5 weitere:
https://www.mysensors.org/build/light-lm393https://www.mysensors.org/build/light-bh1750

Der BH1750 ist afaik aber dahingehend beschränkt, dass er "oben raus" schlecht auflöst (Stichwort Sättigung).

Grundsätzlich würde ich davon abraten, Pi-GPIO zu nutzen, man nutzt besser einen Microcontroller für sowas. Ein Arduino könnte die Werte übrigens auch über das keyValue-Protokoll via USB an FHEM übergeben.

Und eine Datenbanklösung würde ich auf dem Pi direkt auch nicht realisieren (die braucht man auch nicht, um Werte in FHEM zu bekommen). Grade als Anfänger sind FileLog-Aufzeichnungen zu empfehlen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Pi_01

Zitat von: Beta-User am 30 Juli 2020, 10:56:21
Grundsätzlich würde ich davon abraten, Pi-GPIO zu nutzen, man nutzt besser einen Microcontroller für sowas.
Kannst du etwas weiter ausholen? Warum sind die Pi-GPIO eher ungeeignet?

Beta-User

Mein grundsätzliches Problem: Mit sowas vermengt man Steuerung (=fhem) mit der Hardware (=Pi).

Damit es funktioniert, muß man im Fehlerfall beides wiederherstellen, was zu ungeahnten Schwierigkeiten führen kann, siehe z.B. https://forum.fhem.de/index.php/topic,113176.0.html (es gibt viele solcher Threads...).

In der Vergangenheit haben sich auch diverse schlaue Leute mit Pi-GPIO auseinandergesetzt, und dabei z.B. auch (hin und wieder) Latenzen im Stunden-Bereich (!) feststellen können (ggf. blockiert FHEM in der Zeit dann und du sitzt im besten Fall solange im Dunkeln, im schlechtesten deine Familie in der Kälte...).

Pi-GPIO sind (elektrisch) sehr prozessornah (ich habe mal einen Pi mit meinen ersten Versuchen "zerschossen"; bin damit nicht ganz allein, es gibt noch mehr mit zwei linken Händen; einen Arduino-Clon werfe ich dann halt weniger ärgerlich weg, aber die sind auch nicht so empfindlich...).

Außerdem bindest du dich damit an den Pi, und der ist m.E. nur eine Notlösung, schon alleine wegen der SD-Karte (ja, ich weiß, zwischenzeitlich kann man auch USB und es gibt aus USB-SSD's, die wear-leveling können... Nur nutzt sowas kaum einer, und wenn, riskiert er, dass der Pi an USB zu wenig Strom liefert, ...)

Kurz: Ein Pi ist ein lauer Kompromis, und man sollte jederzeit bereit sein, ihn durch - was auch immer - zu ersetzen; im einfachsten Fall durch das Nachfolgemodell, im Regelfall durch irgendeinen x86-basierten Server, der irgendwo (ggf. virtualisiert) läuft...

(Das war jetzt ausnahmsweise - aus gegebenem Anlaß, s.o. - mal wieder die Langfassung, ich hoffe, nichts wesentliches vergessen zu haben).

Kurz: Wenn man GPIO braucht, nimmt man eine MCU und programmiert die entsprechend, Punkt. (Solche Aussagen habe ich vor 6 Jahren auch noch als völlig abwegig empfunden...! Man gewöhnt sich dran ;) .)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

pwlr

Moin,

falls Du Aktoren aus der HM-Serie schalten willst, wäre der Bewegungsmelder HM-Sen-MDIR-O eine Alternative. Der sendet dimensionslose Helligkeitswerte zwischen 0 und 250. Nachteil: der Helligkeitssensor kann nur als Bewegungssensor direkt mit Aktoren gepeert werden, die Abfrage der Helligkeit geht "nur" über Reading im FHEM

Dann gibt es noch den HM-Sen-Li-O, der wohl direktes Peering kann. Ich habe aber keine Erfahrung, da ich so ein Teil nicht besitze. Ist in einer Installaton mit HM-Geräten vermutlich die beste Alternative, da ein Stand-Alone-System möglich ist.

Zitatich benutze zur Zeit ein "Duo", bestehend aus einem LDR (Fotowiderstand) und dem Luxmeter BH1750.

Ich auch. Die Programmierung ist nicht ganz unproblematisch bei komplexen WLAN, aber sonst ok. Nach meiner Erfahrung reicht die Genauigkeit beider Lösungen dicke für die Hausautomation - für Messanwendungen sicher nicht. Die Lösung ist deutlich kostengünstiger als die HM-Sensoren. Nachteil: WLAN, MQTT und FHEM müssen laufen.
Moin
Bernd

jhohmann

Falls EnOcean in Frage kommen würde, ich nutze den Eltako FAH60 Funksensor Außen-Helligkeits-Dämmerungs-Sensor.
Der hat ein Solar-Modul und wenn der halbwegs im Licht steht, braucht man sich um die Batterie nicht mehr kümmern.
Die Positionierung muss man auch wegen der Empfangsstärke im Auge behalten.
Ich hatte ihn zuerst unterhalb des Balkons, da kam es zu Unterbrechungen. Nun hängt er weiter oben am Balkon über unserem und da ist alles schick.
Nur im Winter kann es sein, dass ihm abends die Puste ausgeht. Unterhalb von 300 lumen(?) kommen dann keine weiteren neuen Daten.
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Pi_01

Ich bin jetzt der Empfehlung von Beta-User nachgegangen und habe einen Lichtsensor an einem Arduino angeschlossen, und der Microcontroller hängt wiederum an den USB-Port des Pi.

Danach folgte ich dem Tutorial https://tutorials-raspberrypi.de/arduino-raspberry-pi-miteinander-kommunizieren-lassen/
Der nachfolgende Python-Code funktioniert auch:

import serial
import time

s = serial.Serial('/dev/ttyAMA0', 9600) # Namen ggf. anpassen
s.open()
time.sleep(5) # der Arduino resettet nach einer Seriellen Verbindung, daher muss kurz gewartet werden

s.write("test")
try:
    while True:
        response = s.readline()
        print(response)
except KeyboardInterrupt:
    s.close()


Wenn ich das Python-Script aufrufe, wird nach einer Wartezeit von 5 Sekunden der "Lichtwert" ausgegeben (und zwar jede Sekunde ein neuer Wert - der "Takt" wurde im Script des Arduino festgelegt)

Nun stellt sich mir die Frage, wie ich die Werte mittels FHEM auslesen kann.

Auch hier habe ich ein schönes Tutorial gefunden: https://www.computerhilfen.de/info/fhem-php-python-oder-sh-skript-ausfuehren-und-rueckgabe-wert-speichern.html

Der Code

define testdummy dummy
attr testdummy webCmd on:off

define testdummywert dummy

define act_on_testdummy notify testdummy {\
my $rueckgabe = "php /home/pi/testdummy.php &";;\
fhem("set testdummywert $rueckgabe;;");;\
}


funktioniert leider nicht. Soll heißen: wenn ich den Schalter auf "on" stelle, kriege ich keinen Rückgabewert.
Als Reading steht da nur "state     python /home/licht/lichtsensor.py &"

Woran liegts?

Die Codezeile

my $rueckgabe = "php /home/pi/testdummy.php &";;\

wurde geändert in

my $rueckgabe = "python /home/licht/lichtsensor.py &";;\

und das Verzeichnis und die Datei lichtsensor.py bekamen die Rechte 777.

Ich vermute das Problem liegt in der Datei lichtsensor.py, denn dort wird der "Lichtwert" nicht sofort ausgeben, sondern erst nach einer Wartezeit von 5 Sekunden. Außerdem wird beim Aufruf von lichtsensor.py eine Schleife durchlaufen, d.h. jede Sekunde wird ein neuer "Lichtwert" gemeldet.

Wie müsste ich mein Projekt umbauen, so dass FHEM die wiederkehrenden Schleifenwerte verarbeiten kann?

Beta-User

Mit python-Code kenne ich mich nicht so aus und würde das auf ganz anders lösen, nämlich den Arduino die "Schleife" selber machen lassen, und z.B. jede Minute zwischendurch (signifikant) geänderte Werte und alle 5 Minuten den aktuellen Wert senden lassen, und zwar in einem Format, das FHEM schon kennt.

Vermutlich die einfachste Variante sollte "keyValueProtocol" sein, hier hatte ich dazu mal ausgiebiger geholfen und auch andere Varianten mit besprochen: https://forum.fhem.de/index.php/topic,76291.0.html.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors