Hallo!
Sorry, ich stehe hier gerade total auf dem Schlauch. Ich habe einen I2C-Temperaturesensor, der alle 5 Minuten abgefragt wird. Funktioniert seit Jahren stabil:
define Arbz_hdc1080 I2C_HDC1008 0x40
attr Arbz_hdc1080 IODev rpii2c
attr Arbz_hdc1080 interval 5
attr Arbz_hdc1080 room Arbeitszimmer
attr Arbz_hdc1080 stateFormat T: temperature H: humidity D: dewpoint
define hdc1080D dewpoint dewpoint .*_hdc1080
Jetzt dachte ich gestern Abend, ich reduziere mal die Log- und Event-Last:
attr Arbz_hdc1080 event-min-interval dewpoint:1800,humidity:1800,temperature:1800
attr Arbz_hdc1080 event-on-change-reading dewpoint:0.1,humidity:0.5,temperature:0.2
Seit dem kommen wie gewünscht die "humidity" und "dewpoint"-Werte, aber keine "temperature" mehr.
Ich habe alles mögliche versucht, für "humidity" und "dewpoint" funktioniert alles genau wie erwartet, aber so bald ich für "temperature" ein "event-min-interval" von auch nur 10 Sekunden setze, ist's vorbei, es kommen überhaupt keine Temperatur-Events mehr (im Event-Monitor überprüft). Das Verhalten habe ich auf zwei getrennten FHEM-Instanzen.
Gibt es irgendeine Sonderbehandlung von "temperature"; die mich hier erwischt haben könnte - oder ist das ein Problem von I2C_HDC1008? Auf Anhieb sehe ich keinen Bug im Quellcode...
Danke!!
bei mir (LaCrosse) ohne Probleme :
attr 2_FT_Esszimmer event-min-interval temperature:300
attr 2_FT_Esszimmer event-on-change-reading .*
allerdings ohne wie dir :0.2
Hallo Wzut!
Zitat von: Wzut am 01 August 2020, 08:52:56
bei mir (LaCrosse) ohne Probleme :
attr 2_FT_Esszimmer event-min-interval temperature:300
attr 2_FT_Esszimmer event-on-change-reading .*
allerdings ohne wie dir :0.2
Vielen Dank für die schnelle Antwort, das hat mich dann doch motiviert, weiter zu graben. Mit einem SD_WS kann ich es auch nicht reproduzieren. Wohl tatsächlich ein Problem von I2C_HDC1008 - dummerweise inzwischen mein Modul. ;) Jetzt muss ich wohl die etwas eigenwillige Receive-Funktion dort doch verstehen... :-(
Zitat von: yoda_gh am 01 August 2020, 20:00:41
Wohl tatsächlich ein Problem von I2C_HDC1008 - dummerweise inzwischen mein Modul. ;) Jetzt muss ich wohl die etwas eigenwillige Receive-Funktion dort doch verstehen... :-(
Ok, hab's wohl gefunden. Mir war schon immer unklar warum, aber im Modul steht erst ein
readingsSingleUpdate mit
$dotrigger auf 0 für "temperature" und dann ein
readingsBulkUpdate für "temperature"
und "humidity" mit
$dotrigger auf 1: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/52_I2C_HDC1008.pm#L188
Schmeisse ich das
readingsSingleUpdate raus, verhält sich alles wie ich es erwarte.
Moin,
(schon zu spät...), aber bei der Gelegenheit: Es gab vor einiger Zeit ein paar Kandidaten für "eigenwillige" Doku: https://forum.fhem.de/index.php/topic,101114.msg945754.html#msg945754 (https://forum.fhem.de/index.php/topic,101114.msg945754.html#msg945754). Weiß nicht, ob das inzwischen irgendwer gefixt hat, vermute aber, da ist noch mehr in die Richtung zu tun.
Zitat von: Beta-User am 01 August 2020, 20:23:44
Moin,
(schon zu spät...), aber bei der Gelegenheit: Es gab vor einiger Zeit ein paar Kandidaten für "eigenwillige" Doku: https://forum.fhem.de/index.php/topic,101114.msg945754.html#msg945754 (https://forum.fhem.de/index.php/topic,101114.msg945754.html#msg945754). Weiß nicht, ob das inzwischen irgendwer gefixt hat, vermute aber, da ist noch mehr in die Richtung zu tun.
Ja, da ist Rudolf schon eingesprungen: https://svn.fhem.de/trac/log/trunk/fhem/FHEM/52_I2C_HDC1008.pm?rev=22514.
Eigentlich bräuchten die Module mal eine größere "Überholung" aber dazu fehlen mir Zeit und Perl-Praxis. :-( Ich habe I2C_HDC1008.pm (wie auch 19_Revolt.pm) letzlich auch nur übernommen, weil die Original-Autoren nicht mehr greifbar waren bzw. nicht mehr aktiv...
OK, trotzdem wäre es nicht schlecht, wenn du nochmal einen Blick auf die Doku werfen würdest, vermutlich war das nur "die Spitze des Eisbergs"...
Was die Überarbeitung angeht: Kannst das gerne Step für Step in der Perl-Ecke einkippen, das haben Wzut und ich mit manchen Modulen auch gemacht (oder das mal ansehen, was wir da veranstaltet haben mit perlcritic und so).
(Ich hatte auch das "Vergnügen", praktisch ohne Perl-Grundlagen ein paar Module übernommen zu haben, deren Vor-Maintainer zwar noch aktiv sind, aber auch keine Zeit oder (weitere) Motivation hatten, sich zu kümmern.)
Zitat von: Beta-User am 01 August 2020, 20:41:17
OK, trotzdem wäre es nicht schlecht, wenn du nochmal einen Blick auf die Doku werfen würdest, vermutlich war das nur "die Spitze des Eisbergs"...
Auf den ersten Blick sieht's für mich eigentlich gut aus, die "summary" etc. habe ich seinerzeit angepasst und für
commandref_join.pl und mein Auge schaut die Struktur in beiden Modulen ok aus. Gibt's spezielle Punkte, die ich prüfen soll? (Gerne auch Verweis auf einen Post, etc.)
Zitat von: Beta-User am 01 August 2020, 20:41:17
Was die Überarbeitung angeht: Kannst das gerne Step für Step in der Perl-Ecke einkippen, das haben Wzut und ich mit manchen Modulen auch gemacht (oder das mal ansehen, was wir da veranstaltet haben mit perlcritic und so).
Auch wenn meine Perl-Kenntnisse erbärmlich sind, ist das Hauptproblem wirklich die Zeit, mich aktiv damit auseinanderzusetzen. Jedesmal, wenn ich den Quellcode sehe, springen mich diverse Stellen an, die man verbessern sollte (auch in Bezug auf I2C-Kommunikation, von der ich mal etwas Ahnung hatte), aber mehr als die Module am Funktionieren zu halten und wirkliche Fehler zu beheben, ist leider nicht drin... :-(
Über die commandref schaue ich ggf. bei Gelegenheit mal drüber, mir war nur das Modul noch aus der damaligen, bereits verlinkten Diskussion im Ohr.
Ansonsten ist das mit der Perl-Ecke nur eine Anregung, in der Regel ist es ja schon super, wenn ein Modul einfach fehlerfrei läuft.
Speziell zu I2C vielleicht noch eine Anregung (auch wenn ich generell die Nutzung von Pi-GPIO nicht gut/empfehlenswert für Anfänger finde): Es würde ggf. Sinn machen, die generische I2C Kommunikation (@arduino: wire.h?) und die "spezielle lib" für einzelne Chipsets zu trennen und das ganze als eine Art "plugin"-System (ähnlich Weather/Darksky+...) auszugestalten. Dann müßte man Code-Verbesserungen, die den I2C-Teil betreffen nicht in alle Module übertragen (das sind ja schon eine ganze Menge), sondern könnte das zentral erledigen. Dann bräuchte man innerhalb des "Rahmenmoduls" nur noch den Chipset auswählen ("model"), was ggf. auch in der commandref übersichtlicher wäre.
Erweiterungen/neue Chipsets könnten auch durch Perl-Einsteiger einfacher bereitgestellt werden. Da geht es ja in der Regel nur um Adressen, Timing, Umrechnung und Reading-Benennung..., oder?
Zitat von: Beta-User am 02 August 2020, 07:49:51
Über die commandref schaue ich ggf. bei Gelegenheit mal drüber, mir war nur das Modul noch aus der damaligen, bereits verlinkten Diskussion im Ohr.
Wenn Du Probleme findest, gerne Bescheid sagen, danke!!
Zitat von: Beta-User am 02 August 2020, 07:49:51
Speziell zu I2C vielleicht noch eine Anregung (auch wenn ich generell die Nutzung von Pi-GPIO nicht gut/empfehlenswert für Anfänger finde): Es würde ggf. Sinn machen, die generische I2C Kommunikation (@arduino: wire.h?) und die "spezielle lib" für einzelne Chipsets zu trennen und das ganze als eine Art "plugin"-System (ähnlich Weather/Darksky+...) auszugestalten. Dann müßte man Code-Verbesserungen, die den I2C-Teil betreffen nicht in alle Module übertragen (das sind ja schon eine ganze Menge), sondern könnte das zentral erledigen. Dann bräuchte man innerhalb des "Rahmenmoduls" nur noch den Chipset auswählen ("model"), was ggf. auch in der commandref übersichtlicher wäre.
Wer sagt, dass FHEM und speziell I2C nur von Anfängern genutzt wird? ;) Ich würde das auch nicht jedem als FHEM/RPI-Einstieg empfehlen, aber für Hardware-Bastler ist es schon von Vorteil, wenn man die I2C-Sensoren direkt anbinden kann und nicht noch einen eigenen Arduino spendieren muss, finde ich.
Bzgl. der Trennung kann ich Dir nicht ganz folgen: genau das macht doch https://fhem.de/commandref_DE.html#RPII2C. Und ich bin auch nicht der ideale Kontakt, um die I2C-Architektur zu diskutieren, gibt ja noch einen Haufen andere I2C-Maintainer, allen voran klausw.
Zitat von: Beta-User am 02 August 2020, 07:49:51
Erweiterungen/neue Chipsets könnten auch durch Perl-Einsteiger einfacher bereitgestellt werden. Da geht es ja in der Regel nur um Adressen, Timing, Umrechnung und Reading-Benennung..., oder?
Genau, so wie der Anbindung von jeder externen Hardware. ;-)
Zitat von: yoda_gh am 02 August 2020, 20:35:17
Bzgl. der Trennung kann ich Dir nicht ganz folgen: genau das macht doch https://fhem.de/commandref_DE.html#RPII2C (https://fhem.de/commandref_DE.html#RPII2C). Und ich bin auch nicht der ideale Kontakt, um die I2C-Architektur zu diskutieren, gibt ja noch einen Haufen andere I2C-Maintainer, allen voran klausw.
Genau, so wie der Anbindung von jeder externen Hardware. ;-)
RPII2C scheint zwar ein generisches Modul zu sein, aber die Idee war eine andere: Man nehme was ähnliches als IO-Modul, um einen bestimmten Bus einzubinden, und klemme dahinter ein generisches Client-Modul, das dann über Attribute/XML/Plugins universell für jeden (im Prinzip beliebigen) Chipset genutzt werden kann. CUL_HM oder ZWave kennen ja auch nicht CUL_HM_Lichtsensor_xyz, sondern ermitteln, welche konkrete Hardware es ist (ggf. von User-Seite über modelForce vorgegeben) und setzen den Rest der Parameter entsprechend...
Aber wir brauchen das nicht zu vertiefen.
Zitat von: Beta-User am 03 August 2020, 10:37:22
RPII2C scheint zwar ein generisches Modul zu sein, aber die Idee war eine andere: Man nehme was ähnliches als IO-Modul, um einen bestimmten Bus einzubinden, und klemme dahinter ein generisches Client-Modul, das dann über Attribute/XML/Plugins universell für jeden (im Prinzip beliebigen) Chipset genutzt werden kann. CUL_HM oder ZWave kennen ja auch nicht CUL_HM_Lichtsensor_xyz, sondern ermitteln, welche konkrete Hardware es ist (ggf. von User-Seite über modelForce vorgegeben) und setzen den Rest der Parameter entsprechend...
Aber wir brauchen das nicht zu vertiefen.
Ah, jetzt verstehe ich, was Du meinst - so eine Art Template, in das man nur noch die Chip-Adressen und Register einträgt. Nein, ich denke, so einfach ist es nicht. Je nach Chip musst Du ein bestimmtes Protokoll einhalten und verarbeiten (z.B. zum Setup eine Nachricht schicken, dann x ms warten, dann bekommst Du Antwort X, dann schickst Du wieder was, wartest y ms und bekommst dann zwei Antworten, die Du zusammensetzen musst, daraus interessieren Dich dann nur bestimmte Bits etc.). Ich denke, da braucht man eine Programmiersprache, ein allgemeines Template dürfte mühsam sein.
Zitat von: yoda_gh am 04 August 2020, 09:17:29
Ah, jetzt verstehe ich, was Du meinst - so eine Art [...]
Dass das nur via attrTemplate (z.B.) nicht ginge, war mir eigentlich relativ klar, deswegen hatte ich auch auf eine etwas andere Implementierung verwiesen:
Zitat von: Beta-User am 02 August 2020, 07:49:51
das ganze als eine Art "plugin"-System (ähnlich Weather/Darksky+...) auszugestalten.
In https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/DarkSkyAPI.pm gibt es z.B. keine commandref, die ist auch nicht notwendig...
Diese Art Plugin-System hätte vermutlich auch den Vorteil, dass man z.B. "Mainboard"-(PI-)GPIO und FRM-Module nicht getrennt halten müßte, sondern evtl. einfach (?) das IO-Modul wechseln könnte?
Btw: Du hast mich erst auf den Gedanken gebracht mit dem Hinweis, dass ggf. die I2C-Ansteuerung in deinem Modul nicht optimal ist; da stellt sich direkt die Frage, warum denn jedes Modul da seine eigene Implementierung braucht und man nicht einfach gemeinsam optimierte Standardroutinen nutzt...?