Es gibt seit ein paar Wochen einen neuen Lichtsensor für Homematic:
http://www.elv.de/homematic-funk-lichtsensor-fuer-aussenbetrieb-komplettbausatz.html
Aus der Beschreibung liest es sich so also ob man ihn als Sonnensensor verwenden kann um zu erkennen ob die Sonne scheint oder nicht.
Die Auflösung scheint recht groß zu sein: 0,1 lx bis 100 klx
Hat diesen schon jemand im Einsatz und schon Erfahrungen damit sammeln können? Wäre eine tolle Ergänzung für meine Rolladensteuerung ;D, arbeite hier derzeit mit einem Homematic Differenz-Temperatur-Sensor.
Den Clou habe ich jetzt nicht erkannt. Warum nutz man nicht einen Bewegungsmelder? Die senden Helligkeitswert in der identischen Geschwindigkeit.
Nachdem der Sensor nicht mit Aktoren gepeert werden kann kann er offensichtlich auch keine rollos steuern. Das kann die zentrale klar. Koennte ein mdir auch leisten.
Vielleicht ist die Auflösung besser?
ich könnte wetten das ich irgendwo einen vergleich der kennlinken aller hm geräte mit helligkeitssenior gesehen habe bei dem der HM-Sen-LI-O auch dabei war. ich finde es aber nicht mehr. nur noch die ältere variante hier: http://www.elv.de/topic/kennlinie-des-helligkeitssensors-beim-hm-sec-mdir-2.html (http://www.elv.de/topic/kennlinie-des-helligkeitssensors-beim-hm-sec-mdir-2.html).
ich meine kennlinie und wertebereich ziemlich ähnlich zum MDIR-O und MDIR-WM55.
dort stand auch etwas davon das der wertebereich zwischen 0 und 255 liegt wie bei den anderen. d.h. die auflösung scheint auch nicht besser zu sein.
leider finde ich den beitrag nicht mehr...
gruss
andre
doch noch was gefunden:
ZitatParameter LUX
Typ: float Zugriffsart: lesend, über Ereignisse
Minimaler Wert: 0.00
Maximaler Wert: 100000.00 Einheit: Lux
die auflösung scheint also doch besser zu sein.
die daten stehen hier drin:http://www.eq-3.de/Downloads/Software/HM-CCU2-Firmware_Updates/Tutorials/hm_devices_Endkunden.pdf (http://www.eq-3.de/Downloads/Software/HM-CCU2-Firmware_Updates/Tutorials/hm_devices_Endkunden.pdf)
lustigerweise ist meiner heute gekommen :)
anbei die messages beim pairen und von mindestens einem getconfig:2016.05.12 20:07:02.392 0: HMLAN_Parse: hmlan R:E4960C5 stat:0000 t:10A24ED8 d:FF r:FFA4 m:1C 8400 4960C5 000000 1100FD4E45513033323331353560030101
2016.05.12 20:07:40.346 0: HMLAN_Parse: hmlan R:E4960C5 stat:0000 t:10A2E2A2 d:FF r:FFA0 m:07 8653 4960C5 000000 00C100000359
2016.05.12 20:07:40.349 0: HMLAN_Parse: hmlan R:EF10000 stat:0000 t:10A2E325 d:FF r:FFC2 m:1D A112 F10000 4960C5
2016.05.12 20:07:40.557 0: HMLAN_Parse: hmlan R:E4960C5 stat:0000 t:10A2E3A2 d:FF r:FFA4 m:1D 8002 4960C5 F10000 00
2016.05.12 20:07:40.594 0: HMLAN_Parse: hmlan R:EF10000 stat:0000 t:10A2E42A d:FF r:FFC1 m:1E A001 F10000 4960C5 00040000000000
2016.05.12 20:07:40.839 0: HMLAN_Parse: hmlan R:E4960C5 stat:0000 t:10A2E4AE d:FF r:FFA4 m:1E A010 4960C5 F10000 0202010AF10B000C001100140618000000
2016.05.12 20:07:40.850 0: HMLAN_Parse: hmlan R:EF10000 stat:0000 t:10A2E536 d:FF r:FFC1 m:1E 8002 F10000 4960C5 00
2016.05.12 20:07:40.881 0: HMLAN_Parse: hmlan R:EF10000 stat:0000 t:10A2E555 d:FF r:FFC1 m:1F A001 F10000 4960C5 01040000000001
2016.05.12 20:07:40.947 0: HMLAN_Parse: hmlan R:E4960C5 stat:0000 t:10A2E585 d:FF r:FFA3 m:1E 8002 4960C5 F10000 80
2016.05.12 20:08:18.604 0: HMLAN_Parse: hmlan R:E4960C5 stat:0000 t:10A37825 d:FF r:FFA1 m:1F 8400 4960C5 000000 1100FD4E45513033323331353560030101
2016.05.12 20:08:18.607 0: HMLAN_Parse: hmlan R:EF10000 stat:0000 t:10A378AE d:FF r:FFC1 m:20 A001 F10000 4960C5 00050000000000
2016.05.12 20:08:18.827 0: HMLAN_Parse: hmlan R:E4960C5 stat:0000 t:10A37925 d:FF r:FF9F m:20 8002 4960C5 F10000 00
2016.05.12 20:08:18.855 0: HMLAN_Parse: hmlan R:EF10000 stat:0000 t:10A379AF d:FF r:FFC1 m:21 A001 F10000 4960C5 000802010AF10B000C00
2016.05.12 20:08:19.084 0: HMLAN_Parse: hmlan R:E4960C5 stat:0000 t:10A37A24 d:FF r:FF97 m:21 8002 4960C5 F10000 00
2016.05.12 20:08:19.104 0: HMLAN_Parse: hmlan R:EF10000 stat:0000 t:10A37AA9 d:FF r:FFC1 m:22 A001 F10000 4960C5 0006
2016.05.12 20:08:19.248 0: HMLAN_Parse: hmlan R:E4960C5 stat:0000 t:10A37B39 d:FF r:FF9F m:22 8002 4960C5 F10000 00
2016.05.12 20:08:37.021 0: HMLAN_Parse: hmlan R:E4960C5 stat:0000 t:10A3C005 d:FF r:FFA1 m:23 8400 4960C5 000000 1100FD4E45513033323331353560030101
2016.05.12 20:08:37.024 0: HMLAN_Parse: hmlan R:EF10000 stat:0000 t:10A3C08F d:FF r:FFC0 m:24 A001 F10000 4960C5 00040000000000
2016.05.12 20:08:37.151 0: HMLAN_Parse: hmlan R:E4960C5 stat:0000 t:10A3C113 d:FF r:FFA5 m:24 A010 4960C5 F10000 0202010AF10B000C001100140618000000
2016.05.12 20:08:37.580 0: HMLAN_Parse: hmlan R:EF10000 stat:0000 t:10A3C19A d:FF r:FFC1 m:24 8002 F10000 4960C5 00
2016.05.12 20:08:37.583 0: HMLAN_Parse: hmlan R:EF10000 stat:0000 t:10A3C1B9 d:FF r:FFC1 m:25 A001 F10000 4960C5 01040000000001
2016.05.12 20:08:37.586 0: HMLAN_Parse: hmlan R:E4960C5 statt:0000 t:10A3C1EA d:FF r:FFA2 m:24 8002 4960C5 F10000 80und ein list aufs device:list HM_4960C5
Internals:
CFGFN
DEF 4960C5
IODev cul2
LASTInputDev hmlan
MSGCNT 134
NAME HM_4960C5
NR 80255
STATE Nack
TYPE CUL_HM
cul2_MSGCNT 68
cul2_RAWMSG A0F0A86534960C500000000C1001433C5::-71.5:cul2
cul2_RSSI -71.5
cul2_TIME 2016-05-12 20:15:01
hmlan_MSGCNT 66
hmlan_RAWMSG E4960C5,0000,10A99D98,FF,FFA2,0A86534960C500000000C1001433C5
hmlan_RSSI -94
hmlan_TIME 2016-05-12 20:15:01
lastMsg No:0A - t:53 s:4960C5 d:000000 00C1001433C5
protCmdDel 11
protLastRcv 2016-05-12 20:15:01
protNack 11 last_at:2016-05-12 20:12:01
protResnd 2 last_at:2016-05-12 19:52:56
protSnd 49 last_at:2016-05-12 20:12:01
protState CMDs_done_Errors:1
rssi_at_cul2 avg:-77.33 max:-64.5 cnt:68 min:-94.5 lst:-71.5
rssi_at_hmlan min:-105 cnt:66 lst:-94 max:-81 avg:-91.46
Readings:
2016-05-12 20:12:01 Activity alive
2016-05-12 20:15:01 Chan_01 brigth: 132397300.0
2016-05-12 20:12:01 CommandAccepted no
2016-05-12 20:12:01 D-firmware 1.1
2016-05-12 20:12:01 D-serialNr NEQ0323155
2016-05-12 20:12:01 PairedTo 0xF10000
2016-05-12 20:10:16 R-cyclicInfoMsgDis 1
2016-05-12 20:08:37 R-pairCentral 0xF10000
2016-05-12 20:12:01 RegL_00. 02:01 0A:F1 0B:00 0C:00 11:01 14:06 18:00 00:00
2016-05-12 20:13:18 RegL_01.
2016-05-12 20:15:01 battery ok
2016-05-12 19:50:38 powerOn 2016-05-12 19:50:38
2016-05-12 19:50:38 recentStateType info
2016-05-12 20:12:01 state Nack
Helper:
HM_CMDNR 10
PONtest 1
cSnd 01F100004960C500040000000000,01F100004960C501040000000001
getCfgListNo
mId 00FD
rxType 12
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +4960C5,00,00,00
nextSend 1463076901.29912
prefIO
rxt 2
vccu
p:
4960C5
00
00
00
Mrssi:
mNo 0A
Io:
cul2 -69.5
hmlan -94
Prt:
bErr 0
sProc 0
try 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_cul2:
avg -77.3308823529412
cnt 68
lst -71.5
max -64.5
min -94.5
At_hmlan:
avg -91.4696969696969
cnt 66
lst -94
max -81
min -105
Shadowreg:
Tmpl:
Attributes:
IODev cul2
IOgrp ccu:cul2
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.1
model HM-Sen-LI-O
room CUL_HM
serialNr NEQ0323155
subType senBright
die helligkeit landet noch nicht in einem eigenen reading sondern in Chan_01. das device für den channel 1 wird auch noch nicht automatisch angelegt und state steht auf Nack. (ich habe auch NACK vorbei rauschen sehen)
gruss
andre
Das device hat doch nur einen Kanal. Fhem legt dann keinen automatisch an. Hat mich einiges über die Zeit gekostet es aufrecht zu halten.
Du kannst manuell die beiden separieren. Sehe ich als Feature.
Das mit dem reading werde ich kontrollieren
Kann es sein, dass der gelieferte Messwert noch durch 10.000 zu teilen ist, um ungefähr auf Lux zu kommen?
Dann passt er jedenfalls hinreichend genau zum Output meines Luxmeters.
(Das wiederum "kalibriert" is an anderen Luxmetern in der Taschenlampenszene,
und wir sind da ziemlich pingelig, was Luxe und Lumen angeht... :-)
Möglich. Ist es gesichert?
Meinerseits nur mit Indizien belegt:
Der Messbereich ist mit 0 bis 100000 Lux angegeben.
Im Beispiel von justme1968 erscheint "Chan_01 brigth: 132397300.0" .
(Zahlen in der gleichen Größenordnung meldet mein eigener Sensor auch)
Dieser Wert wäre so *weit* ausserhalb des Messbereichs.
Durch 10000 geteilt, hat mein Sensor heute um 14:09 einen Maximalwert von 105947
bei stahlendem Sonnenschein geliefert - laut "Beleuchtungsstärke"-Eintrag bei Wikipedia
sollten es um die 90000 Lux sein - für die Abschätzung der Größenordnung passts gut genug.
PS: wer kümmert sich gelegentlich mal um das "brigth"?
wenn man meine werte von gestern durch 10000 teilt wären es tagsüber im Zimmer zwischen 500 und 1400. das würde glaube ich zu einem mehr oder weniger hellen zimmer passen.
Habe über einen Tag einen nach Süden ausgerichteten Sensor ausgelesen. Hier kamen um den Faktor 10 höhere Messwerte.
2016-05-14_13:28:12 Lichtsensor Chan_01: brigth: 1072980100.0
2016-05-14_13:31:14 Lichtsensor Chan_01: brigth: 1058769000.0
2016-05-14_13:34:01 Lichtsensor Chan_01: brigth: 1072585400.0
Wenn man ein DOIF für das Schalten der Rollladen benutzt, stört das bright nicht.
@Klaus1956
Konntest du testen ob die Auflösung des Sensors ausreicht um den Unterscheid zu messen zwischen:
- es ist hell und die Sonne scheint aber es ist zb. leicht bewölkt/diesig
- direkte Sonneneinstrahlung (keine Wolke am Himmel...)
Hallo Martin,
in 10_CUL_HM.pm sollte diese Variante (ab Zeile 2134) sinnvolle Werte in lux liefern, denke ich, da der Sensor laut Bauanleitung bis 0.01lux messen können soll:
elsif($mh{st} eq "senBright") { #############################################
if ($mh{mTp} =~ m/5[34]/){
#Channel is fixed 1
my ($chn,$unkn,$dat) = unpack 'A2A2A8',$mh{p};
# push @evtEt,[$mh{devH},1,"battery:".(hex($chn)&0x80?"low":"ok")];
# $dat = sprintf("%0.1f",hex($dat)*100);
$dat = sprintf("%0.2f",hex($dat))/100; #down to 0.01lux as the sensor supports
# my $chnHash = $modules{CUL_HM}{defptr}{$mh{src}."01"};#fixed channel
# if ($chnHash){
# push @evtEt,[$chnHash,1,"state:bright: $dat"];
# push @evtEt,[$chnHash,1,"bright:$dat"];
# }
# else{
# push @evtEt,[$mh{devH},1,"Chan_01:brigth: $dat"];
# }
push @evtEt,[$mh{shash},1,"brightness:".$dat];
push @evtEt,[$mh{shash},1,"unknown: 0x".$unkn]; # I read 0xC1 here, but what is it?
push @evtEt,[$mh{devH},1,"battery:".(hex($chn)&0x80?"low":"ok")];
if ($modules{CUL_HM}{defptr}{$mh{src}."01"}){ #fixed channel 1
my $ch = $modules{CUL_HM}{defptr}{$mh{src}."01"};
push @evtEt,[$ch,1,"state:B: $dat"];
push @evtEt,[$ch,1,"brightness:$dat"];
}
push @evtEt,[$mh{shash},1,"state:B: $dat"];
}
}
Und angelehnt an den THSensor code kommen die Readings so in device statt in ein channel device. Ich denke, das ist so gedacht.
Gruß,
Ansgar.
bis auf die push @evtEt,[$mh{shash},1,"unknown: 0x".$unkn]; # I read 0xC1 here, but what is it?
zeile schaut es bei mir damit gut aus.
$unkn gibt es bei mir nicht.
gruss
andre
mir ist gerade noch etwas aufgefallen: es gibt ein R-cyclicInfoMsgDis reading. bis her kenne ich nur R-cyclicInfoMsg.
weiss jemand wozu R-cyclicInfoMsgDis sein könnte? das ding sendet doch sowieso immer alle 4 oder 5 minuten.
@savage7
Hallo savage7,
eine Range von 1000000000 Stellen reicht allemal aus. Es kommt auf das Setzen der richtigen Triggerwerte an, das ist Finetuning und auch bei jeder Himmelsrichtung, Uhrzeit und Neigung des Sensors anders. hier ein paar Messwerte aus der Log.
Sonnenaufgang
2016-05-15_04:47:58 Lichtsensor Chan_01: brigth: 0.0
2016-05-15_04:50:38 Lichtsensor Chan_01: brigth: 200.0
2016-05-15_04:53:03 Lichtsensor Chan_01: brigth: 500.0
stark bewölkt
2016-05-15_13:00:55 Lichtsensor Chan_01: brigth: 41760100.0
direkte Sonneneinstrahlung
2016-05-15_13:33:31 Lichtsensor Chan_01: brigth: 1110657000.0
bewölkt
2016-05-15_14:57:01 Lichtsensor Chan_01: brigth: 116573300.0
Hallo Andre,
Du hast
my ($chn,$unkn,$dat) = unpack 'A2A2A8',$mh{p};
in meiner Änderung übersehen. Da steckt $unkn drin.
Gruß, Ansgar.
Hallo justme1968,
zu Deiner Anfrage
mir ist gerade noch etwas aufgefallen: es gibt ein R-cyclicInfoMsgDis reading. bis her kenne ich nur R-cyclicInfoMsg.
weiss jemand wozu R-cyclicInfoMsgDis sein könnte? das ding sendet doch sowieso immer alle 4 oder 5 minuten.
Dieses Register habe ich auch bei einem Füllstandsmesser (HM-Sen-Wa-Od). Er gibt an: Anzahl der auszulassenden Meldungen. Dort steht er bei 6 und es kommen nur ~ alle 20 Minuten Meldungen.
das passt es. sehr gut.
und das register auch.
danke
andre
Hallo zusammen,
wenn man die beiden Nachkommastellen haben will,
$dat = sprintf("%0.2f",hex($dat))/100; #down to 0.01lux as the sensor supports
statt
$dat = sprintf("%0.1f",hex($dat))/100; #down to 0.01lux as the sensor supports
natürlich.
Gruß,
Ansgar
Hallo Ansgar,
Werde ich fast so uebernehme. Allerdings ist die aufteilung chn dev nicht korrekt.
Typisch hat man den chan nicht definiert. Dann kommt alles ins device. Sollte jemand den chn definieren kommen die kanalreadings in den kanal. Brightness kommt dann nicht mehr ins device.
Der state des device beinhaltet dann protokollzustaende. Also cmddone,....
Batterie ist immer device, logisch.
Sollte ein user readings anders anzeigen wollen kann er userreadings nutzen
Hallo Martin,
danke!
Das mit der Channelaufteilung habe ich noch nicht wirklich verstanden, aber vielleicht liegt das auch nur an meinen TH Sensoren, die sich immer so verhalten und ich mich daher an $mh{mTp} eq "70" im Code orientiert habe. Ich bin gespannt auf Deinen Code.
Wenn $chn aus den Sensordaten beim Helligkeitssensor die Channelnummer angeben soll, dann noch als Info, da kommt immer 00 bei meinem Sensor.
EDIT: 80 bei schwacher Batterie natürlich...
Hast Du eine Erklärung, was das C1 nach der 00 sagen will? Das C1 kommt immer.
NACK und Nack habe ich nach dem Anlernen (mit uralter 10_CUL_HM.pm) auch gesehen.
Hängt das eventuell mit der Abfrage der AES Verschlüsselung zusammen?
Hier das Statuslog zu diesem Anlernvorgang.
2016-05-14_12:15:27 Helligkeit_HM Activity: unknown
2016-05-14_13:43:16 Helligkeit_HM R-pairCentral: 0x......
2016-05-14_13:43:16 Helligkeit_HM R-transmDevTryMax: 6
2016-05-14_13:43:16 Helligkeit_HM R-localResDis: off
2016-05-14_13:43:26 Helligkeit_HM aesKeyNbr: 00
2016-05-14_13:45:19 Helligkeit_HM Nack
2016-05-14_13:45:19 Helligkeit_HM NACK
Gruß,
Ansgar.
Mal sehen, dass ich heute Abend zum Einbau komme.
Bei dieser message kommt kein chn mit, eq3 beschreibt dass es fix auf 1 zu setzen ist, was Sinn macht.
Grundsätzlich sind alle Funktionen in Kanälen. Das device macht immer das Protokoll.
1-kanal Sensoren werden in fhem per Default in einer entity verwaltet. Rein technisch unschön aber fuer den User komfortabler. Will man es sauber haben kann man den Kanal definieren, dann werden die readings der entsprechenden entity zugewiesen. Macht wohl kaum einer. State koennte man besser verwalten insbesondere die Protokol Ereignisse.
ist drin.
kurz zur info: ich habe hier: https://forum.fhem.de/index.php/topic,53487.0.html (https://forum.fhem.de/index.php/topic,53487.0.html) einen patch vorgeschlagen um in svg plots die y-achse logaritmisch zu skalieren.
ohne eine solche änderung ist es nicht möglich die werte des sensors sinnvoll zu plotten.
gruss
andre
Hallo Martin,
nach einem update bekomme ich jezt ein unknown 0XC1 im Reading,
2016-05-17_17:39:26 Lichtsensor battery: ok
2016-05-17_17:39:26 Lichtsensor brightness: 13097.33
2016-05-17_17:39:26 Lichtsensor B: 13097.33
2016-05-17_17:39:26 Lichtsensor unknown: 0xC1
Gruß
Klaus
War die Idee von Ansgar. Werde ich ggf. Wieder löschen. Es ist ein Wert in der message den wir nicht deuten koennen. Kein Fehler.
Hallo Martin,
oder so:
push @evtEt,[$cHash,1,"unidentified:0x".$unkn] if ($unkn ne "C1"); # read 0xC1 here, but what is it?
Dann bekommen wir mit, wenn mal was anderes kommt, um es vielleicht doch noch zu deuten.
Gruß, Ansgar.
Unknown ist etwas für die Entwicklung. Auch wenn viele hier entwickeln sollten unknown nicht kommen wenn es nicht ein Problem darstellen.
Ich hatte so etwas auch schon einmal drin.... wieder entfernt.
Wahrscheinlich ist es so etwas wie eine Adresse - haben wir auch in anderen msgs so drin.
Es gibt weitere Bytes oder bits die wir nicht kennen oder die ungenutzt sind. Wenn wir alle ausgeben wollten kennt sich keiner mehr aus.
Immer unschoen wenn man das Gefühl hat, da koennte noch etwas sein, klar
Moin
Gibt es schon eine Lösung für Dummies?
Ich versuche mich seit ein paar Wochen an Haussteuerung mit FHEM und bin zur Zeit noch voll ausgelastet, wenn ich versuche diverse Hinweise und Tipps umzusetzen, davon selber einmal hier Input zu liefern bin ich leider noch weit entfernt. Aber: learning by doing!
Ich habe mit den Lichtsensor zugelegt, habe auch alles mit Löten etc. hinbekommen und ihn sogar an meinen CUL anlernen können. So, jetzt sitze ich da in weiß nichts mit anzufangen. Kann mir jemand er klären, wie ich an die readings sprich die LUXwerte komme und damit eine notify Sequenz auslöse, z.B. Um die Rollos hoch bzw. runter zu fahren?
Am Liebsten wäre es mir, wenn ich es in der FHEM Oberfläche einfliegen kann. Finde ich noch einfacher nachvollziehbar als Programmzeilen im Terminal einzupflegen.
Derzeit kann ich aber in FHEM bei State nur ein ? Sehen und readings sehe ich gar nicht.
Wäre echt toll, wenn mir hier jemand eine Dummie-Lösung geben kann.
Beste Grüße
K-H
Hallo zusammen
Hat jemand diesen Lichtsensor in den letzten Wochen bei elv.de bestellt?
Auf der Homepage steht Lieferfrist 8 Wochen?
Hats bei Euch so lange gedauert???
Ehomeportal würde den Sensor auch noch anbieten. Aber die haben bis Mitte September Ferien...
Hallo,
meine Erfahrung ist, dass die Angaben (leider) meistens stimmen. Ab und zu hatte ich aber auch schon Glück und die Bestellung kam etwas früher.
Gruß
glaube es waren 13Wochen Lieferzeit, als ich ihn mir auf meine Wunschliste packte...
So wie es aussieht, wird es wohl doch noch so lange dauern.
Hilft nur auf die Email warten, daß er verfügbar ist.....
Als ich ihn bestellt habe, stand dort 1 Woche Lieferzeit. Das war am 5.6...dann wurde ich ständig vertröstet, dass es noch eine weitere Woche dauern würde (insgesamt 3 mal) und dann waren es auch irgendwann 13 Wochen.
Hallo zusammen ich habe den Sensor schon Mai funktioniert eigentlich nicht schlecht.
Hab mal 2 Diagramme hochgeladen
TSL2561
BH1705
Homematic
Eigentlich sollten alle genau die gleiche Lichtstärke(lux) messen, liegen alle direkt nebeneinander.....
ELV hat die Lieferzeit korrigiert... nach oben :(
War die letzten Tage bei 3 Wochen, nun 8 Wochen >:(
Das wird dieses Jahr nichts mehr :(
Lieferzeit von 3 auf 11 Wochen hochgeschnipst
Moin!
Ich hatte meinen im Juli bestellt, ist dann gestern endlich bei mir angekommen. Habe ihn heute zusammengebaut, funktioniert soweit... ;D
Gruß,
Thomas
Hatte meine jetzt ein paar Wochen, jetzt hat er den Geist aufgegeben. Im Sensor ist schwitzwasser zu erkennen, keine Ahnung ob es daran liegt.
Jedenfalls habe ich ihn eingeschickt, elv will ihn prüfen. Mal sehen wann welche Reaktion kommt und wann ein neuer kommt.
na das trübt ja die Vorfreude ein wenig...
wann der neue kommt, kann ich die schon sagen.. nicht vor 8 Wochen :D
drück dir die daumen...
Zitat von: Garbsen am 02 November 2016, 20:58:49
Hatte meine jetzt ein paar Wochen, jetzt hat er den Geist aufgegeben. Im Sensor ist schwitzwasser zu erkennen, keine Ahnung ob es daran liegt.
Jedenfalls habe ich ihn eingeschickt, elv will ihn prüfen. Mal sehen wann welche Reaktion kommt und wann ein neuer kommt.
Beim Zusammenbau die Dichtung nicht richtig eingesetzt?
Zitat von: zap am 03 November 2016, 07:18:37
Beim Zusammenbau die Dichtung nicht richtig eingesetzt?
Der Sensor selber kam in meiner Erinnerung als ein fertiges Tail, dass dann ins Gehäuse eingefügt wurde.
Da war m.E. Nach nichts zusammenzubauen und entsprechend keine Dichtung.
Wer einen braucht... gestern noch 3Wochen Wartezeit, seit heute wieder lieferbar ;)
Hab ihn gestern (14.12.2016), nach 12 Wochen Lieferzeit, von ELV bekommen.
Zusammenbau easy, aber MIT Dichtung zwischen Sensor und Gehäuse.
Achtung, die Dichtung hat 2 verschiedene Konturen, ist auch in der Anleitung zu sehen.
Hat eine große Auflösung, viel besser als mein FAH60. Der, so meine Vermutung, kriegt wegen der geringen Helligkeit nicht genug Strom über seine Solarzellen.
Bis jetzt sehr zufriedenstellend.
Schauen wir mal
Gr. Rob
Hallo zusammen,
erst lief dass Teil einwandfrei, jetzt brauche ich alle 14 Tage neue Batterien, gibt es da schon Neuigkeiten ?
bis dann
Klaus
Habe mal gemessen, 5mA ist wohl definitiv zuviel.
Habe den Sensor mal zerlegt, eindringendes Schwitzwasser konnte ich nicht erkennen ..
Evtl. in der Blackbox, doch diese kann ich nicht öffnen.
Hallo Zusammen,
kann mir jemand kürz sagen, was der Sensor genau ausgibt?
Sind das direkt Lux werte?
Gruß Robert
Liefert Dir den Batteriestatus und die Helligkeit in Lux zurück.
Her mal meine aktuellen Reading:
battery ok 2019-05-05 23:19:58
brightness 0.02 2019-05-05 23:19:58
state B: 0.02 2019-05-05 23:19:58
Ziemlich dunkel draußen, deshalb 0.02 lux
Hier von der ELV-Seite der Messbreich:
Lichtsensor für einen weiten Lichtstärkebereich von 0,1 lx bis 100 klx
Zitat von: kumue am 05 Mai 2019, 23:28:48
Liefert Dir den Batteriestatus und die Helligkeit in Lux zurück.
Her mal meine aktuellen Reading:
battery ok 2019-05-05 23:19:58
brightness 0.02 2019-05-05 23:19:58
state B: 0.02 2019-05-05 23:19:58
Ziemlich dunkel draußen, deshalb 0.02 lux
Hier von der ELV-Seite der Messbreich:
Lichtsensor für einen weiten Lichtstärkebereich von 0,1 lx bis 100 klx
Danke