Hallo,
ich bin bei meinem aktuellen Projekt an einer Stelle angekommen, an der ich gerade einfach nicht weiterkomme. Vielleicht hat ja ein Experte einen Tipp für mich:
Ich habe einen Signalgeber am Gaszähler montiert, der über S0 am GPIO von einem FHEM-Raspberry Pi hängt. Mit jeder Umdrehung des Zählers wird bei "9" geschlossen und bei "0" wieder geöffnet. Ich habe mit einem Kondensator entprellt und zudem debounce_in_ms auf 250ms gesetzt.
Via Interrupt auf der fallenden Flanke zählt der Counter im Logfile offensichtlich fehlerfrei:
2014-11-21_10:19:06 GPIO3 Counter: 3760
2014-11-21_10:19:36 GPIO3 Toggle: off
2014-11-21_10:19:36 GPIO3 Counter: 3761
2014-11-21_10:20:07 GPIO3 Toggle: on
2014-11-21_10:20:07 GPIO3 Counter: 3762
2014-11-21_10:20:37 GPIO3 Toggle: off
Jetzt habe ich mit kW differential { ReadingsVal("GPIO3","Counter",0)*0.01*3600*0.9384*10.056} ein Userreading erstellt, welches mir den Momentanverbrauch in kW errechnet. Das funktionier soweit auch, allerdings bekomme ich keine vernünftige grafischen Auswertung hin. Das Problem liegt in der Berechnung des Userreadings:
2014-11-21_09:31:27 GPIO3 Counter: 3660
2014-11-21_09:31:27 GPIO3 kW: 12.0170219164229
2014-11-21_09:31:31 GPIO3 kW: 0 <----------- Woher kommt diese Eintrag?
2014-11-21_09:31:55 GPIO3 Counter: 3661
2014-11-21_09:31:55 GPIO3 kW: 13.8390445073263
Ich kann mir nicht erklären, warum 4 Sekunden nach Ereignis nochmals kW berechnet wird, allerdings ist klar, dass der Wert 0 ist, da sich der Counter ja nicht verändert hat. Wer verursacht diesen einzelnen Eintrag?
Ich habe versuchsweise event-min-interval auf 5 gesetzt, um diese erneute Berechnung zu verhindern. Allerdings habe ich noch ein weiteres Problem im Userreading:
2014-11-21_10:14:32 GPIO3 Counter: 3750
2014-11-21_10:14:32 GPIO3 kW: 11.1653127290338
2014-11-21_10:15:02 GPIO3 Toggle: off
2014-11-21_10:15:02 GPIO3 Counter: 3751
2014-11-21_10:15:02 GPIO3 kW: 11.1568769601285
2014-11-21_10:15:05 GPIO3 Toggle: on
2014-11-21_10:15:05 GPIO3 Counter: 3752
2014-11-21_10:15:05 GPIO3 kW: 104.932400438307 <----------- Plötzlich extrem hoher Wert?
2014-11-21_10:15:32 GPIO3 Toggle: off
2014-11-21_10:15:32 GPIO3 Counter: 3753
2014-11-21_10:15:32 GPIO3 kW: 12.4980773082179
2014-11-21_10:16:03 GPIO3 Toggle: on
2014-11-21_10:16:03 GPIO3 Counter: 3754
2014-11-21_10:16:03 GPIO3 kW: 11.1507232659794
Es gibt immer wieder unregelmäßig Peaks, die ich mir nicht erklären kann. Ich kann mir nur vorstellen, dass diese beiden Fehler irgendwie zusammenhängen, allerdings habe ich gerade keine Idee mehr, wo ich suchen soll.
Ich würde das Projekt auch gerne wieder ins Forum zurückspielen, allerdings möchte ich keine unfertigen Projekte abgeben :)
Liebe Grüße
DerJens
userreadings wird bei jeder änderung irgendeines readings im device getriggert. wenn du das vermeiden willst musst du hinter dem namen mit : getrennt das reading angeben bei dem getriggert werden soll.
gruß
andre
Vielen Dank für die Rückmeldung, ich hoffe, ich darf noch einmal bezüglich der Userreadings nachfragen:
Ich habe einen Dummy
Zentralheizung, dessen Reading
state aus einem
at alle 5 Minuten aktualisiert wird:
+*00:05:00 {my $b = ReadingsVal("GPIO3", "Counter", ""); fhem("set Zentralheizung $b"); }Jetzt möchte ich, ausgehend von
state, dem Dummy weitere Readings hinzufügen und dachte, ein eleganter Weg wäre, dies über Userreadings zu machen und füge zunächst ein Userreading
Verbrauch hinzu:
Verbrauch difference { ReadingsVal("Zentralheizung","state",0)*0.01*0.9384*10.056; }Das funktioniert und alle 5 Minuten bekomme ich wie erwartet einen neuen Wert.
Was allerddings nicht funktioniert ist der trigger:
Verbrauch:state difference { ReadingsVal("Zentralheizung","state",0)*0.01*0.9384*10.056; } --> Verbrauch wird nicht mehr aktualisiert.Mein Plan war weiterhin, aus dem Verbrauch einen weiteren Wert in einem Userreading zu errechnen:
Tagesverbrauch { ReadingsVal("Zentralheizung", "Tagesverbrauch", 0) + ReadingsVal("Zentralheizung", "Verbrauch", 0); }Das funktioniert soweit, allerdings wenn ich (nachts)
setreading Zentralheizung Tagesverbrauch 0 ausführe um den Tagesverlauf zu löschen, wird auch der
Verbrauch aktualisiert und auch wieder der
Tagesverbrauch. Das, dachte ich, könnte ich mit einem trigger verhindern:
Tagesverbrauch:Verbrauch { ReadingsVal("Zentralheizung", "Tagesverbrauch", 0) + ReadingsVal("Zentralheizung", "Verbrauch", 0); } --> Tagesverbrauch aktualisiert gar nicht mehr Was stimmt denn mit meinem trigger nicht?
Da mir mehr damit geholfen ist, wenn ich das Konzept der Userreadings verstehe, hab ich mich auf die Suche gemacht und diesen Beitrag gefunden: http://forum.fhem.de/index.php/topic,19619.msg132720.html#msg132720 (http://forum.fhem.de/index.php/topic,19619.msg132720.html#msg132720) Wenn ein Userreading "nur" eine Anzeige ist, warum schlägt dann eine Änderung wieder auf andere Userreadings durch? Weiterhin stelle ich mir folgende Fragen:
- Spielt die Reihenfolge der angegebenen Userreadings eine Rolle?
- Userreadings könne sich auch aus anderen Userreadings berechnen. Was passiert, wenn eine Kreuzbeziehung vorhanden ist?
Es wäre super, wenn einer das Konzept der Userreadings kurz erklären könnte.
Herzlichsten Dank
DerJens
Ich würde gerne etwas ganz ähnliches machen (meine Stellantrieb-Öffnungen aufsummieren für eine Übersicht welcher Raum wie viel im Vergleich verbraucht. Bisher habe ich es so versucht (direkt im PID-Device)
timediff {time_str2num(ReadingsTimestamp("stellantrieb.badezimmer","valve",""))-ReadingsVal("stellantrieb.badezimmer","lastreadingtime","")}, valvesecs {(ReadingsVal("stellantrieb.badezimmer","timediff","")*ReadingsVal("stellantrieb.badezimmer","lastreading",""))/3600}, lastreading:valvesecs {ReadingsVal("stellantrieb.badezimmer","valve","")}; lastreadingtime:valvesecs {time_str2num(ReadingsTimestamp("stellantrieb.badezimmer","valve",""))}
Es scheint als ob Userreadings-Berechungen nicht von anderen Userreading-Berechungen getriggert werden und ich bin noch nicht hinter die Reihenfolge der Berechnung gekommen.
timediff aus lastreading und dem aktuellen wert alleine berechnen funktioniert wenn ich lastreading erst nach timediff setze, aber valvesecs wird nicht berechnet sonder immer mit aktuellen Werten statt mit lastreading und timediff. (das war alles noch vor der dem ":valvesecs" filter"
mit :valvesecs werden lastreading und lastreadingtime sowieso nicht mehr gesetzt.
Ich habe dann noch versucht mit voranstellen von 10_, 20_ etc. zu schauen ob ich auf die richtige Auswertungsreihenfolge komme, aber auch da hat es nicht gestimmt.