Hallo liebe fhem Gemeinde
Seit fast 5 Jahren habe ich einen raspberry mit fhem-Installation als Smart Home Zentrale. Als IODev benutze ich den HMLAN-Adapter von Homematic. Alle Geräte (Heizkörperthermostate, Wandthermostate, Fensterkontakte, Bewegungsmelder sowie diverse andere Sensoren und Aktoren) sind von Homematic. Zusätzlich befindet sich ein Jeelink USB-Stick für einige Technoline Thermometer, eine 1-wire Platine für Temperaturen am Heizkessel, sowie ein USB-Stick für die Speicherung der Log-Files und regelmäßigen fhem-Backups am raspberry.
Mein Dank an alle die mir damals im Forum mit Geduld und Ratschlägen geholfen haben.
Als neueste Errungenschaft habe ich eine Markise zur Beschattung der Terrasse. Auf fertige Fernsteuerungen oder Sensoren (wie somfy oder dgl.) habe ich bewusst verzichtet, da ich lieber Herr im eigenen Haus bin, statt über irgendeine Cloud eines Herstellers die Markise zu bedienen. Als Aktor benutze ich den Aufputz Homematic HM-LC-BL1-SM Rollladenaktor mit der Homematic Fernbedienung HM-RC-12. Alles war leicht über fhem einzurichten und funktioniert soweit tadellos.
Für den Fall einer Abwesenheit der Hausbewohner möchte ich aber noch zusätzliche Sicherheiten einbauen falls vergessen wurde die Markise einzufahren. Die An-/Abwesenheit wird schon über das structure Modul gesteuert.
Von den etablierten Herstellern gibt eine Menge zusätzlicher Sensoren wie Windsensor, Regensensor, Virbrationssensor, Sonnensensor u.s.w. die aber aus genannten Gründen nicht in Frage kommen. Als alternative habe ich die sehr preiswerten Aqara-Sensoren mit Zigbee-Protokoll in fhem integriert. Dazu brauchte ich ein entsprechendes IO-Device. Meine Wahl fiel auf den ConBeeII-Stick von Dresden Elektronik. Um mit dem Experiment nicht meinen System-raspberry zu belasten und möglicherweise zu zerschiessen, habe ich einen anderen raspberry mit einem Kartenimage von Dresden Elektronik versehen, den Stick eingesteckt und in Betrieb genommen. Alles klappte reibungslos.
Als Sensoren habe ich auf gut Glück den Xiaomi/Aqara Schock-/Vibrationsensor DJT11LM und den Aqara WaterLeakSensor SJCGQ11LM beschafft. Beide wurden vom ConBeeII-Stick auf Anhieb erkannt. Dann noch den ConBeeII-raspberry am System-raspberry als deConz angemeldet, die Device-ID der Sensoren ausgelesen und alles war gut.
Der WaterLeakSensor kennt nur das Reading water=0 oder water=1. Der Vibrationsensor hat verschiedene Readings. Ich brauche aber nur das Reading vibration. vibration=0 oder vibration=1.
Durch notify's werden die Sensoren der Markise gesteuert.
define Markise_Regenalarm notify RegenSensor:water:.1 set Markisenschalter pct 0
define Markise_Windalarm notify VibrationsSensor:vibration:.1 set Markisenschalter pct 0
Der Regensensor ist extrem empfindlich. Schon bei geringer Benetzung der Kontakte spricht er schon an. Das gleiche für den Vibrationssensor. Die sensitivity des Vibrationssensors soll sich noch anpassen lassen.
Bei starker Sonneneinstrahlung wird die Markise durch ein doif mit einem Thermometer, dass sich auf auf der Terrasse befindet, zur Beschattung ausgefahren.
define Markise_Temperaturalarm doif ([LaCrosse_2A:temperature] >30) (set Markisenschalter pct 100)
Alles funktioniert soweit und so gut. Das die Markise bei Regen komplett einfährt und das sie bei Hitze ausfährt ist ja ok.
Allerdings möchte ich die Markise, wenn sie auf größer als pct 90 ausgefahren ist, mit dem VibrationsSensor erst einmal auf pct 60 schliessen. Wenn dann der VibrationsSensor durch Windboen immer noch anspricht, zu pct 30 schliessen u.s.w.
Das kann man sicherlich mit entsprechenden notify's/doif's mit if/elsif/and/or Regeln machen. Soweit bin ich aber leider noch nicht. Seit 3 Wochen scheitere ich bei allen Bemühungen eine funktionierende Syntax für den VibrationsSensor für meine Zwecke zu schreiben. Mittlerweile habe ich alle FHEM-WIKI Seiten zu doif und notify durch. Ich komme einfach nicht auf eine Lösung. Deshalb wende ich mich jetzt an das Forum um Hilfe und einen Lösungsansatz zu bekommen. Ich erwarte keine fertige Lösung, nur jemand müsste mich in die richtige Richtung schubsen.
Vielen Dank fürs Lesen und Anteilnahme
Hier noch die Internals, Readings und Attributes
Xiaomi/Aqara Schock-/Vibrationsensor DJT11LM:
------------------------------------------------
Internals
----------------------------------------------
CFGFN
DEF sensor 6 IODev=deCONZ
FUUID 5ec04640-f33f-6cfc-12e4-aebb2d9e6f645768
FVERSION 31_HUEDevice.pm:0.218370/2020-05-02
ID S6
INTERVAL
IODev deCONZ
NAME VibrationsSensor
NR 675
STATEInitialized
TYPE HUEDevice
lastupdated 2020-05-17 08:26:41
lastupdated_local 2020-05-17 10:26:41
manufacturername LUMI
modelid lumi.vibration.aq1
name VibrationsSensor
on 1
reachable 1
sensitivity 11
sensitivitymax 21
swversion 20180130
type ZHAVibration
uniqueid 00:15:8d:00:04:83:5e:90-01-0101
--------------------------------------------
Readings
--------------------------------------------
battery 100
2020-05-17 10:57:44 batteryPercent 100
2020-05-17 10:57:44 orientation 0,-1,89
2020-05-17 10:47:30 reachable 1
2020-05-17 10:57:44 temperature 28
2020-05-17 10:57:44 tiltangle 177
2020-05-17 10:47:30 vibration 0
2020-05-17 10:47:30 vibrationstrength 38
-------------------------------------------
Attributes
-------------------------------------------
IODev deCONZ
event-on-change-reading vibration
genericDeviceType security
icon hue2019_devicesMotionSensor
model lumi.vibration.aq1
room Markise
stateFormat vibration
-------------------------------------------
Hi,
ich habe nicht verstanden wo Dein Problem liegt und Du Hilfe brauchst.
Nur das fällt mir auf:
notify VibrationsSensor
name Vibrationssensor
Gruß Otto
Moin Otto,
der Name aus den Internals (Vibrationsensor) ist jetzt korrekterweise VibrationsSensor. Hatte ihn gestern geändert, aber die Internals vorher schon mit dem falschen Namen herauskopiert. >:(
Mein Problem ist einfach das ich keinen Ansatz finde durch ein doif oder notify die Markise in Schritten einfahren kann. Der VibrationsSensor befindet sich am Ende der Markise im Gehäuse und ist etwa 3,5x3,5 cm groß. Bei 4m Ausfall schüttelt es die Markise bei entsprechendem Wind schon heftig.
Beispiel: Die Markise ist auf pct 100 ausgefahren d.h. langer Hebelarm. Jetzt kommt Wind auf und rüttelt an der Markise und bringt sie ins Schwingen. Dann löst der VibrationsSensor aus und fährt sie auf pct 60. Wenn das reicht, ist alles ok. Sollte es nicht reichen und der Wind immer noch an der Markise rüttelt, löst der VibrationsSensor wieder aus und schliesst die Markise auf pct 30 oder was immer man möchte. Das Reading vibration wechselt in ca. 60 sek. nach Auslösung von 1 auf 0
Mit meinem notify:
define Markise_Windalarm notify VibrationsSensor:vibration:.1 set Markisenschalter pct 0
klappt das ja auch schon. Nur fährt sie dann auf pct 0 ein. Das möchte ich nicht, da die Markise ja zur Beschattung der Terrasse / Wohnzimmer bei hohen Temperaturen dienen soll. Das Ganze ist ja auch nur gedacht für den Fall das niemand Zuhause ist.
Gruß, Ludwig
Hallo Ludwig,
Und jedesmal einfach relativ fahren, also set Markisenschalter down 30
Gruß Otto
Hallöchen,
ich weiss nicht inwiefern Du Dich mit Perl auseinander gesetzt hast, aber sollte hier die Erfahrung bei null liegen, kannst Du nur mehrere DOIFs anlegen, die dann auf die verschiedenen Umstände (Vibration in Abhängigkeit von pct ). Da ich aber mich selbst so gut wie gar nicht mit DOIFs auskenne, wäre ich da eher Verwirrung als Hilfe.
Wo ich Dir helfen kann ist ein Gedankenganz, den Du für Deine Umstände anpassen musst....
Ich würde es mit einem Faktor (reading) lösen, das Du einmalig setzt und es entsprechend in die Berechnung mit eingeht. Angenommen Deine Markise muss bei einem Wer von 1 einfahren das wären dann 100 % Vibrationsstärke die zum Einfahren nötig sind also:
Faktor * 1.1 * (pct) 100 = Vibrationswert der zum Einfahren in die nächste Stufe nötig ist
(Faktor * 1.6) * (pct) 70 = Vibrationswert der zum Einfahren in die nächste Stufe nötig ist
(Faktor * 3.7) * (pct) 30 = Vibrationswert der zum Einfahren in die nächste Stufe nötig ist
Als Beispiel wäre das dann ein Faktor 3:
3 * 1.1 * 100 = 330
3 *1.6 * 70 = 336
3 *3,7* 30 = 333
Nun müsstest Du Faktor und Anpassung so einsetzen, dass am Ende immer ein eindeutiger Wert herausommt (z.B. > 330 ) Dann kannst Du anhand diesem dann weiter vorgehen:
Prüfe auf Wert > 330 => tritt dieser ein => bestimme die Position (100 oder <100 und >70 oder <70 und >30 ) => Bestimmte anhand der aktuellen Position die nächst niedrigere => Die von Otto vorgeschlagene relativ Fahrt ist noch besser an der Stelle
Wenn Du nun feststellst, dass das viel zu früh ist wie die Markise rein fährt, nimmst Du als Faktor 4 oder streckst die Bestimmungszahlen (1,1 1,6 und 3,7) für die prozentuellen Anteile ein wenig.... oder oder ....
Zur Umsetzung da bewusst mal nichts vor, weil ich es direkt per if / elsif / ellse Abfragen in Perl lösen würde (Einfach so Laienhanft ::) weil ich DOIF einfach nicht kapiere und bisher ohne auskomme )
Aber vielleicht hilft der Gedankengang ja schonmal weiter :)
Viele Grüße
Andreas
Mal so als Gedankenanregung ohne vorheriges Testen (ich habe etwas Ähnliches zur Lautstärkesteuerung)...
Eine Funktion in der 99_myUtils anlegen:
sub
Windschutz()
{
# aktuellen %-Wert der Markise ermitteln
my $pct_old = ReadingsVal("Markisenschalter","pct","");
# mit Hilfe der Schrittweite neuen Wert ermitteln
my $pct_new = $pct_old - 30;
# kleiner 0 heisst ganz einfahren
if ($pct_new < 0) { $pct_new = 0 };
# Markise mit neuem Wert setzen
fhem ("set Markisenschalter pct $pct_new");
}
Dein Notify würde dann nicht mehr direkt den Wert setzen, sondern die Funktion aufrufen:
define Markise_Windalarm notify VibrationsSensor:vibration:.1 {Windschutz}
@Otto,
@Andreas,
@Hollo,
Danke, dass ihr euch des Themas angenommen habt. Der Hinweis von Otto hat nicht funktioniert.
Und jedesmal einfach relativ fahren, also set Markisenschalter down 30 Was mit 'relativ' gemeint ist konnte ich nicht umsetzen.
Die Hinweise von Andreas habe ich nicht wirklich nachvollziehen können. Ich bin mittlerweile ziemlich unbedarft in diesen Dingen. Als ich vor ca. 5 Jahren mit allem anfing, habe ich mich sehr in das Thema fhem eingearbeitet. Seitdem habe ich nicht mehr viel gemacht und man verlernt so einiges.
Die Gedankenanregung von Hollo traf genau ins Schwarze. Es ist genau das was ich wollte. Es funktioniert perfekt. Den Wert von 30 habe ich in 25 geändert um die Markise in 25er Schritten einzufahren. Was ich jetzt noch machen muß ist die Einbindung des Anwesenheits Status. Die drei Sensoren sollen ja nur bei Abwesenheit der Hausbewohner die Kontrolle übernehmen. Wo kann/sollte ich den ZuHause Staus einbauen, in die sub in der 99_myUtils oder im Aufruf des notifys?
Vielen Dank an alle,
Gruß, Ludwig
Hallo Ludwig,
perfekt das Du ein Lösung hast.
Noch zur Erklärung "relativ":
set Markisenschalter down 30
Im Gegensatz zu pct 30 wird mit down 30 nicht auf den Level 30% gefahren, sondern vom existierenden Punkt um 30% gefahren.
Also steht der Rollladen auf 100 -> down 30 -> steht er jetzt auf 70 -> dann wieder down 30 -> jetzt steht er auf 40 usw.
Gruß Otto
Hallo Otto,
Habe alle Varianten von
define Markise_Windalarm notify VibrationsSensor:vibration:.1 set Markisenschalter down 30
ausprobiert. So wie es oben steht. Danach mit Klammern in allen Variationen. Es geht leider nicht. Die Version von Hollo ist die Einzige die funktioniert.
Wenn Du jetzt noch eine Idee hast, wie ich das notify
define Markise_Regenalarm notify RegenSensor:water:.1 set Markisenschalter pct 0
dahingehend ändern kann, dass das notify nur anspricht wenn niemand Zuhause ist. Das structure Modul ZuHause gibt den state "present oder "absent". Ich möchte, dass die Markise nur einfährt wenn niemand Zuhause ist. Habe schon alles mit notify laut FHEM-WIKI ausprobiert. Komme leider nicht klar.
Danke nochmal, Ludwig
Ich will nicht auf meiner Idee rumreiten, weil die andere sicher viel besser ist. Aber funktioniert denn
set Markisenschalter down 30 in der FHEM Kommandozeile wie beschrieben? Oder gibt es Fehler.
Oder andersrum, funktioniert die andere Richtung?
set Markisenschalter up 30
Dein anders notify musst Du mit einer Bedingung im Ausführungsteil ausstatten, entweder FHEM IF oder Perl if:
Ungetestet!
IF ([ZuHause:state] eq "absent") (set Markisenschalter pct 0)
{if (ReadingsVal('ZuHause','state',error) eq "absent") {fhem('set Markisenschalter pct 0')}}
Gruß Otto
Moin Otto,
Die Eingabe in der FHEM-Kommandozeile set Markisenschalter up 30
erzeugt die Fehlermeldung off requires no parameters
Umgekehrt mit down ebenfalls.
Das notify für die Abfrage "absent" / "present" funktioniert einwandfrei. Ich hatte einen Denkfehler in der Syntax mit >Suchmuster< und >Ausführungsteil<. Jetzt klappt auch das. :) Dank Dir und Hollo bin ich jetzt zufrieden. Als letztes versuch ich nur noch eine Meldung mit dem Modul sendemail zu generieren, die mir meldet wann die Markise bei Abwesenheit ein-/ausfährt. Bei z.B. Fensterstatus bei Abwesenheit klappt das wunderbar Das ist aber eine andere Geschichte. Der WAF ist im Moment nicht mehr so groß ;)
Gruß, Ludwig
Hallo Ludwig,
damit ich das verstehe, kannst Du mal bitte die Ausgabe posten
list Markisenschalter
Gruß Otto
Hallo Otto,
aber gerne,
Internals:
DEF 67E4F3
FUUID 5ea2d1df-f33f-6cfc-3efc-8e83fde0d9f461f3
HMLAN1_MSGCNT 54
HMLAN1_RAWMSG E67E4F3,0000,2E6A8438,FF,FFBF,5DA41067E4F332241A06010000
HMLAN1_RSSI -65
HMLAN1_TIME 2020-05-25 11:09:38
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 54
NAME Markisenschalter
NOTIFYDEV global
NR 400
NTFY_ORDER 50-Markisenschalter
STATE up
TYPE CUL_HM
chanNo 01
lastMsg No:5D - t:10 s:67E4F3 d:32241A 06010000
protLastRcv 2020-05-25 11:09:38
protRcv 53 last_at:2020-05-25 11:09:38
protResnd 1 last_at:2020-05-25 00:54:56
protSnd 54 last_at:2020-05-25 11:09:38
protState CMDs_done
rssi_HMLAN1 cnt:27 min:-83 max:-67 avg:-72.51 lst:-69
rssi_at_HMLAN1 cnt:54 min:-85 max:-58 avg:-68.77 lst:-65
READINGS:
2020-05-25 11:09:33 CommandAccepted yes
2020-04-29 17:18:47 D-firmware 2.11
2020-04-29 17:18:47 D-serialNr OEQ2478938
2020-04-29 13:52:23 PairedTo 0x32241A
2020-04-27 23:43:11 R-driveDown 28 s
2020-04-28 20:17:30 R-driveTurn 1 s
2020-04-27 23:43:11 R-driveUp 28 s
2020-04-27 23:43:10 R-pairCentral 0x32241A
2020-04-28 11:06:11 R-self01-lgActionType jmpToTarget
2020-04-28 11:06:11 R-self01-lgOnLevel 100 %
2020-04-28 11:06:11 R-self01-shActionType jmpToTarget
2020-04-28 11:06:11 R-self01-shOnLevel 100 %
2020-04-28 11:06:15 R-self02-lgActionType jmpToTarget
2020-04-28 11:06:15 R-self02-lgOnLevel 100 %
2020-04-28 11:06:15 R-self02-shActionType jmpToTarget
2020-04-28 11:06:15 R-self02-shOnLevel 100 %
2020-04-27 23:43:11 R-sign off
2020-04-29 13:52:23 RegL_00. 00:00 02:01 0A:32 0B:24 0C:1A 15:FF 18:00
2020-04-29 13:52:24 RegL_01. 00:00 08:00 09:00 0A:00 0B:01 0C:18 0D:01 0E:18 0F:0A 10:00 30:06 56:00 57:24
2020-05-25 11:09:38 commState CMDs_done
2020-05-25 11:09:38 deviceMsg off (to HMLAN1)
2020-05-25 11:09:38 level 0
2020-05-25 11:09:38 motor stop:off
2020-05-25 11:09:38 pct 0
2020-05-25 11:09:38 recentStateType info
2020-05-25 11:09:38 state off
2020-05-25 11:09:38 timedOn off
helper:
HM_CMDNR 93
cSnd 1132241A67E4F3020100,1132241A67E4F3020100
dlvlCmd ++A01132241A67E4F3020100
mId 0005
peerFriend peerSens,peerVirt
peerOpt 3:blindActuator
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
cmds:
TmplKey :no
cmdKey :1:1:0::0005:01
TmplCmds:
cmdList:
assignHmKey:
clear:[readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
deviceRename:newName
down:[-changeValue-] [-ontime-] [-ramptime-] ...
eventL:-peer- -cond-
eventS:-peer- -cond-
fwUpdate:-filename- -bootTime- ...
getConfig:
getDevInfo:
getRegRaw:[List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
getSerial:
getVersion:
inhibit:[on|off]
off:
on:
pair:
pct:[-value-] ... [-ontime-]
peerBulk:-peer1,peer2,...- [set|unset]
peerIODev:[IO] -btn- [set|unset]... not for future use
press:[long|short] -peer- [-repCount(long only)-] [-repDelay-] ...
raw:data ...
regBulk:-list-.-peer- -addr1:data1- -addr2:data2- ...
regSet:[prep|exec] -regName- -value- ... [-peerChannel-]
reset:
sign:[on|off]
statusRequest:
stop:
toggle:
toggleDir:
tplDel:tmplt
unpair:
up:[-changeValue-] [-ontime-] [-ramptime-] ...
dir:
cur stop
rct down
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +67E4F3,00,00,00
nextSend 1590397778.30425
prefIO
rxt 0
vccu
p:
67E4F3
00
00
00
mRssi:
mNo 5D
io:
HMLAN1:
-61
-61
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rpt:
IO HMLAN1
flg A
ts 1590397778.21767
ack:
HASH(0x34c5fc0)
5D800232241A67E4F300
rssi:
HMLAN1:
avg -72.5185185185185
cnt 27
lst -69
max -67
min -83
at_HMLAN1:
avg -68.7777777777778
cnt 54
lst -65
max -58
min -85
tmpl:
Attributes:
IODev HMLAN1
alexaName Markise
autoReadReg 4_reqStatus
devStateIcon up:fts_sunblind_0@green 2\d.*:fts_sunblind_20@red 1\d.*:fts_sunblind_10@red 3\d.*:fts_sunblind_30@red 4\d.*:fts_sunblind_40@red 5\d.*:fts_sunblind_50@red 6\d.*:fts_sunblind_60@red 7\d.*:fts_sunblind_70@red 8\d.*:fts_sunblind_80@red 9\d.*:fts_sunblind_90@red down:fts_sunblind_100@red
eventMap on:down off:up
expert 2_defReg+raw
firmware 2.11
genericDeviceType blind
group MarkiseSensoren
icon fts_sunblind@yellow
model HM-LC-BL1-SM
peerIDs 00000000,
room 9_Markise
serialNr OEQ2478938
subType blindActuator
webCmd pct:toggleDir:on:off:up:down:stop
Du Schlingel :)
eventMap on:down off:up
Dachte ich mir so etwas.
Damit hast Du Dir genau diese Möglichkeit der relativen Steuerung selbst genommen.
Und auch noch damit die Logik gedreht!
on bedeutet "Licht an" - also beim Rolladen hoch (bei Dir runter)
off bedeutet "Licht aus" - also beim Rolladen runter (bei Dir hoch)
Ohne weitere Angabe mach up/down übrigens 10 % - also kleine Schritte.
Zitat von: Otto123 am 25 Mai 2020, 12:47:28
...
on bedeutet "Licht an" - also beim Rolladen hoch (bei Dir runter)
off bedeutet "Licht aus" - also beim Rolladen runter (bei Dir hoch)
...
Sehr schöne Eselsbrücke ;D
@Terra
Freut mich, dass wir helfen konnten und Du nun eine funktionierende Lösung hast.
Evtl. kannst Du den entsprechenden Code am Ende nochmal zusammenfassen und dann vor den Thread-Titel noch ein [gelöst] setzen.
@Otto
Du hast ja so recht!! :D Bei der Installation des Markisenschalters, (offiziell Homematic Rollladenaktor HM-LC-BL1-SM) https://wiki.fhem.de/wiki/HM-LC-Bl1-SM_Funk-Jalousieaktor (https://wiki.fhem.de/wiki/HM-LC-Bl1-SM_Funk-Jalousieaktor), habe ich mich nach einigem studieren der Readings / Attributes für die Variante der Steuerung mit pct (percent) entschlossen. Die anderen Readings / Attributes wie on, off, up, down, stop habe ich außer Acht gelassen. Ich möchte nicht ausschliessen, dass ich ein wenig mit den Attributes "gespielt" habe, um deren Funktion zu testen. Dabei habe ich bestimmt das Attribut eventMap geändert und es hat dann nicht so wie von Dir vorgeschlagen funktioniert. Nach der Änderung hat es funktioniert. Die Bezeichnung on and off sind nicht für jeden intuitiv. Für den einen ist on = hoch und off = runter. Für den anderen ist es genau umgekehrt. Aber trotzdem bleibe ich bei der Variante mit dem "set pct..." Der Vorschlag von Hollo funktioniert so wie von mir gewünscht.
@Hollo
Die Steuerung der Markise funktioniert eigentlich perfekt, mit kleinen Einschränkungen. Im Moment arbeite ich noch an einer Verbesserung der Temperaturregelung. Ich werde diesen Thread-Titel als gelöst markieren. Danke nochmal.
Nachdem ich fast alle Threads im Forum zu Thema Markisensteuerung gelesen habe, stelle ich fest das diese schon ziemlich alt und für mich nicht sehr befriedigend sind. Insbesondere Helligkeits-Beschattungsregelung über Sensoren die nicht die tatsächliche Sonneneinstrahlung (Hitzeeintrag) sondern nur die Helligkeitswerte über Bewegungsmelder oder dgl. liefern. Das teste ich grade mit einer Differenzmessung zwischen einem Thermometer in der Sonne und einem im Schatten. Wenn beide annähernd gleiche Temperaturen haben, brauche ich keine Beschattung; es ist nämlich bewölkt. ;) Oder Windgeschwindigkeitsmesser die die Geschwindigkeit in m/sek ermitteln. Mich interessiert nur ob es an der Markise rüttelt. Das soll ja der Vibrationsensor melden.
Alles das werde ich in den nächsten Wochen im Feldversuch testen und dann darüber ausführlich berichten. Vieleicht im Forum unter Verschiedenes > Projekte.
Ideen und Kommentare sind erwünscht.
Gruß, Ludwig