Lichtsensor HM-Sen-LI-O

Begonnen von savage7, 11 Mai 2016, 16:30:56

Vorheriges Thema - Nächstes Thema

Klaus1956

@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
1xFb7390(84.06.23), 1xRaspberry B mit CUL868,1xEM,3xFHTTK, 6xFS20, 9xFHT80, 1xKS300, 6xRM100-2, FritzBox, FHEM2FHEM, Pushover, Mail, Callmanager,
1xRaspberry B+ mit HM, 6xHM-SEC-SC, 2xHM-ES-PMSw1-Pl, 2xHM_WDS30_OT2, 3xHM-LC-Bl1PBU-FM, PRESENCE, HM-LC-SW1-PL2, 3xHM-CC-RT-DN, Withings, WetterOnline,

noansi

Hallo Andre,

Du hast

      my ($chn,$unkn,$dat) = unpack 'A2A2A8',$mh{p};

in meiner Änderung übersehen. Da steckt $unkn drin.

Gruß, Ansgar.

Klaus1956

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.
1xFb7390(84.06.23), 1xRaspberry B mit CUL868,1xEM,3xFHTTK, 6xFS20, 9xFHT80, 1xKS300, 6xRM100-2, FritzBox, FHEM2FHEM, Pushover, Mail, Callmanager,
1xRaspberry B+ mit HM, 6xHM-SEC-SC, 2xHM-ES-PMSw1-Pl, 2xHM_WDS30_OT2, 3xHM-LC-Bl1PBU-FM, PRESENCE, HM-LC-SW1-PL2, 3xHM-CC-RT-DN, Withings, WetterOnline,

justme1968

#18
das passt es. sehr gut.

und das register auch.

danke
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

noansi

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

martinp876

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

noansi

#21
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.

martinp876

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.

martinp876


justme1968

kurz zur info: ich habe hier: 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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Klaus1956

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
1xFb7390(84.06.23), 1xRaspberry B mit CUL868,1xEM,3xFHTTK, 6xFS20, 9xFHT80, 1xKS300, 6xRM100-2, FritzBox, FHEM2FHEM, Pushover, Mail, Callmanager,
1xRaspberry B+ mit HM, 6xHM-SEC-SC, 2xHM-ES-PMSw1-Pl, 2xHM_WDS30_OT2, 3xHM-LC-Bl1PBU-FM, PRESENCE, HM-LC-SW1-PL2, 3xHM-CC-RT-DN, Withings, WetterOnline,

martinp876

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.

noansi

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.

martinp876

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

Garbsen

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
FHEM und Homebridge auf Intel NUC, CUL 868 v 1.66, CUL466 V 1.66, SOMFY RTS Rolläden, HM-LC-Bl1PBU-FM, HM-LC-BL1-FM, HM-SEC-SC-2, HM-SEC-RHS, HM-WDS10-TH-O, HM-SEC-WDS-2, HM-Sen-LI-O, HM-CC-RT-DN, HM-LC-Sw1-Pl-DN-R1, HM-SCI-3-FM, HM-Sec-Sir-WM, HM-PB-2-WM55-2, HM-RC-8, HM-LC-SW1-PL2, Alpha2