Hallo,
ich habe vor, auf ein clonedummy eines RemotePi device ein DOIF aufzusetzen. Leider scheint dieses auf Veränderungen des clonedummy überhaupt nicht zu reagieren.
Wenn ich stattdessen im gleichen DOIF ein lokales device verwende, klappt alles wie geplant.
Kann jemand einen Tipp geben? Erzeugt ein clonedummy kein $EVENT?
Grüße, Tom S
Warum schaust Du nicht einfach in den Eventmonitor und beantwortest die Frage nach dem clonedummy Event Dir damit selber. Du kannst im Übrigen auch auf den original Event von der Remoteinstanz triggern.
Warum schaust Du nicht selbst im Event monitor?
Edit:
Leon war schneller :)
Gruß Otto
Hallo.
habe selbiges Problem, aber anderwertig. habe einige cloneDummys die sauber laufen, von 2. fhem2 1. fhme. heute habe ich div. dummys auf 2. fhem angelegt, die ich weiterhin in 1. fhem sehen will. der eventmonitor auf 1. fhem sieht die dummys, aber der state wird nicht aktualisiert. nur active.
wieters zeigt mir einer dieser dummys nur 3 stellen statt 4 stellen des originaldummys an, und das reading wird aufgefüllt mit jedem neuen eintrag.
ich sehe mich nicht mehr raus.
hat wer tips?
thx
Zitat von: satprofi am 17 August 2017, 17:55:26
Hallo.
habe selbiges Problem, aber anderwertig. habe einige cloneDummys die sauber laufen, von 2. fhem2 1. fhme. heute habe ich div. dummys auf 2. fhem angelegt, die ich weiterhin in 1. fhem sehen will. der eventmonitor auf 1. fhem sieht die dummys, aber der state wird nicht aktualisiert. nur active.
wieters zeigt mir einer dieser dummys nur 3 stellen statt 4 stellen des originaldummys an, und das reading wird aufgefüllt mit jedem neuen eintrag.
ich sehe mich nicht mehr raus.
hat wer tips?
thx
Sorry ich hab's versucht. Aber ich kann beim besten Willen nicht Dein Problem interpretieren.
Grüße
sorry.
nochmals: habe 2 raspi mit fhem am laufen. am 2. raspi habe ich dummys die am 1. raspi geclont werden, also gespiegelt.
heute wollte ich weitere dummys clonen/spiegeln, aber die werte kommen nich am 1. raspi an. nur active, und ein dummy empfängt die werte in den readings, allerdings wird eine readingsliste angelegt, habe schon ~30 werte die minütlich mehr werden. nur im state steht immer noch active.
der eventmonitor schreibt aber die werte.
wieters werden statt 4 stellen der zahl nur 3 stellen empfangen
@staprofi:
Beim besten Willen sehr schwer zu verstehen von was du redest. Ich rate mal:
Reading state wird nicht übertragen, alle anderen Readings schon. Irgendein Reading wird abgeschnitten.
Posten doch einfach mal ein List der beiden Device, wie es im Thread: https://forum.fhem.de/index.php/topic,71806.0.html steht. Sonst kann man dir nur SEHR SCHWER helfen.
kann man denn nicht die cloneDummys auf dem 2.Pi durch "normale" dummys ersetzen, welche den gleichen Namen haben wie das Device auf dem 1.Pi und gut iss... ?
Das geht sogar sehr gut
Zitat von: Amenophis86 am 18 August 2017, 02:07:26
@staprofi:
Beim besten Willen sehr schwer zu verstehen von was du redest. Ich rate mal:
Reading state wird nicht übertragen, alle anderen Readings schon. Irgendein Reading wird abgeschnitten.
Posten doch einfach mal ein List der beiden Device, wie es im Thread: https://forum.fhem.de/index.php/topic,71806.0.html steht. Sonst kann man dir nur SEHR SCHWER helfen.
OK, aber Problem gelöst.
Ein state von einem Dummy kann man nicht clonen, ich habe ein weiteres dummy definiert, das mit einem setreading gefüllt wird. jetzt wird auch dieser neue dummy übertragen. stateformat ist der wert aus setrading.
wieder was dazugelernt, weil die funktionierenden clonedummys werden von python mit setreading gefüllt und weitergespiegelt nach 2. fhem.
lg
Sorry, nochmal zurück zum Anfang des threads. Der besagte Clonedummy taucht im Eventmonitor wie erwartet auf. Trotzdem reagiert das DOIF nicht wie es soll. Hier mal ein paar Details; es geht um den Status einer Solarpumpe am RemotePi, die ca. 30 bis 40 mal pro Tag anläuft:
define Pumpe cloneDummy Solarpumpe
attr Pumpe alias Solarpumpe
attr Pumpe devStateIcon on:sani_pump@red off:sani_pump@grey
attr Pumpe event-on-change-reading 1
attr Pumpe group Solarthermie
define DO_Start_Mess DOIF ([Pumpe:"on"]) ({ my $tv = ReadingsVal("Vorlauf","temperature","") ;; fhem "set T_Vorlauf1 $tv" ;; my $tr = ReadingsVal("Ruecklauf","temperature","") ;; fhem "set T_Ruecklauf1 $tr" })
attr DO_Start_Mess group to_be_tested
define DO_End_Mess DOIF ([Pumpe:"off"]) (hier steht der auszuführende Code bei abschaltender Pumpe, der auch mit "trigger Pumpe off" ausgeführt wird; ist recht lang, daher hier kein listing )
attr DO_End_Mess group to_be_tested
Was könnte man noch prüfen. Wie gesagt: die beiden DOIF's reagieren nicht automatisch sondern nur per "trigger"
Also wenn Dein original Device nicht auch zufällig Pumpe heißt dann wird das auch nichts. Nimm mal das event-on-change-reading 1 raus und nach zu mindest fest ein .* daraus. Besser aber erstmal ohne event-on-update-reading
Ich bezweifel das Events von cloneDummy auftauchen.
Hallo,
fehlt da nicht ein DOELSE oder do allways? Oder braucht man das nicht? Das doif würde doch sonst nur ein einziges mal ausführen oder liege ich da fasch?
Gruß Rolf
Hi,
set magic (https://fhem.de/commandref_DE.html#set)geht vor allem auch in DOIF, da muss man nicht soviel schreiben:
(set T_Vorlauf1 [Vorlauf:temperature])
Ersetz dies hier {my $tv = ReadingsVal("Vorlauf","temperature","") ;; fhem "set T_Vorlauf1 $tv" ;;}
Was ich nicht verstehe, was ist Dein Problem? Dein DOIF schaltet nicht? Wie triggerst Du es denn?
Was hat das mit dem clonedummy zu tun?
Gruß Otto
Zitatfehlt da nicht ein DOELSE oder do allways? Oder braucht man das nicht? Das doif würde doch sonst nur ein einziges mal ausführen oder liege ich da fasch?
Braucht man nicht. Wenn Pumpe irgendwelches anderes Event generiert, wird das DOIF auf cmd_2 schalten, und wird wieder bereit für ein erneutes "on".
Es fehlt aber einfach... Events. Mit event-on-change-reading 1 wird gar kein Event generiert. Deswegen wird das DOIF nie getriggert.
Hallo Otto123,
ich bin ein Stück weiter: das DOIF wird getriggert, führt aber offenbar nicht alle Kommandos aus, da kein Ergebnis erscheint. Es werden eine Menge Readings gelesen und dann einiges berechnet. Der komplette Code (der evtl. auch eleganter prorammiert werden kann) lautet :
([Solarpumpe:"off"]) ({ my $tv1 = ReadingsVal("T_Vorlauf1","state","") ; my $tv2 = ReadingsVal("Vorlauf","temperature","") ; fhem "set T_Vorlauf2 $tv2" ; my $tv = ($tv1+$tv2)/2 ; fhem "set T_Vorlauf $tv" ; my $tr1 = ReadingsVal("T_Ruecklauf1","state","") ; my $tr2 = ReadingsVal("Ruecklauf","temperature","") ; fhem "set T_Ruecklauf2 $tr2" ; my $tr = ($tr1+$tr2)/2 ; fhem "set T_Ruecklauf $tr" ; my $C11 = AttrVal("Konstante_ST2","C11",0) ; my $C21 = AttrVal("Konstante_ST2","C21",0) ; my $C22 = AttrVal("Konstante_ST2","C22",0) ; my $C23 = AttrVal("Konstante_ST2","C23",0) ; my $C31 = AttrVal("Konstante_ST2","C31",0) ; my $tr_tv = ($tv-$tr) ; my $tr_tv_Quadrat = ($tr_tv * $tr_tv) ; my $Fm = AttrVal("Konstante_ST","Foerdermenge_h",0) ; my $dt = ReadingsVal("Solarpumpe_Count","pulseTimeIncrement",0) ; fhem "set Delta_t_tmp $dt" ; my $delta_E = ($C11 + (($C21 + ($C22 * ($tr-20)) + ($C23 * ($tr-20) * ($tr-20))) * $tr_tv) + ($C31 * $tr_tv_Quadrat)) ; fhem "set Delta_E_tmp $delta_E" ; fhem "set FM_tmp $Fm" ; my $E = ((($delta_E * $Fm) / 3600) * $dt) ; fhem "set Delta_E $E" } )
Seltsamerweise ist die ReadingsVal("Solarpumpe_Count","pulseTimeIncrement",0) immer gleich 0, so dass das Ergebnis Delta_E auch 0 ist. Solarpumpe_Count ist ein Hour_Counter.
Definitiv steht in dem Reading etwas drin, z.B. ein Wert 75 und wenn ich diesen mit einem eigenen, separaten DOIF auslese, bekomme ich auch den Inhalt auch als Delta_t_tmp ausgegeben, nur nicht nicht in dem angegebenen DOIF. Kann es sein, dass die Anzahl der Kommandos oder die Länge des Kommandostrings beim DOIF begrenzt ist?
Ich bin etwas ratlos! Eine Idee?
Zitatdass die Anzahl der Kommandos oder die Länge des Kommandostrings beim DOIF begrenzt ist?
Nicht dass ich wüsste. Du kannst selbst die timestamps auf Solarpumpe_Count kontrollieren, um zu sehen, ob es aktualisiert worden ist oder nicht.
Zeig mal ein "list Solarpumpe_Count"?
Hier das Listing des HourCounters:
Internals:
CHANGED
DEF Solarpumpe:on Solarpumpe:off
NAME Solarpumpe_Count
NR 103
NTFY_ORDER 50-Solarpumpe_Count
STATE 2 Starts, 3.0 Minuten, 0.01kWh, 102sek
TYPE HourCounter
VERSION 1.0.1.2 - 24.12.2014
READINGS:
2017-05-17 13:05:01 clearDate 2017-05-17 13:05:01
2017-08-26 10:31:31 countsOverall 3507
2017-08-26 10:31:31 countsPerDay 2
2017-08-26 10:31:31 pauseTimeEdge 1188
2017-08-26 10:31:31 pauseTimeIncrement 0
2017-08-26 10:31:31 pauseTimeOverall 8177011
2017-08-26 10:31:31 pauseTimePerDay 37709
2017-08-26 10:31:31 pulseTimeEdge 102
2017-08-26 10:31:31 pulseTimeIncrement 102
2017-08-26 10:31:31 pulseTimeOverall 423359
2017-08-26 10:31:31 pulseTimePerDay 182
2017-08-26 10:31:31 state 2
2017-08-26 10:31:31 tickChanged 87
2017-08-26 00:00:00 tickDay 1
2017-08-26 10:00:00 tickHour 20
2017-08-25 14:03:07 tickMonth 0
2017-08-26 10:31:31 tickUpdated 676
2017-08-25 14:03:07 tickWeek 0
2017-08-25 14:03:07 tickYear 0
2017-08-26 10:31:31 value 0
helper:
OFF_Regexp Solarpumpe:off
ON_Regexp Solarpumpe:on
calledByEvent
changedTimestamp 2017-08-26 10:31:31
forceClear
forceDayChange
forceHourChange
forceMonthChange
forceWeekChange
forceYearChange
isFirstRun
sdRoundHourLast 1503734400
value 0
cmdQueue:
Attributes:
alias Laufzeit, Energieverbrauch Solarpumpe
event-on-change-reading pulseTimePerDay pulseTimeIncrement
group Solarthermie
icon general_an_fuer_zeit
room Solarthermie
sortby 3
stateFormat {sprintf("%.0f Starts",ReadingsVal("Solarpumpe_Count","countsPerDay",0)).sprintf(", %.1f Minuten",ReadingsVal("Solarpumpe_Count","pulseTimePerDay",0)/60).sprintf(", %.2fkWh",ReadingsVal("Solarpumpe_Count","pulseTimePerDay",0)*0.150/3600).sprintf(", %.0fsek",ReadingsVal("Solarpumpe_Count","pulseTimeIncrement",0))}
Grüße
Tom
Hallo Tom,
25 Einzelbefehle -> ich würde als erstes den Code in eine Sub in 99_myUtils auslagern. Diese kannst Du unabhängig vom DOIF einfach mal aufrufen und überprüfen.
Gruß Otto
Und wenn Du folgendes machst, aktualisieren sich die Sachen auch nur teilweise?
set <doifname> cmd_1
Hallo und vielen Dank für die vielen hilfreichen Tipps. Sie haben mich soweit gebracht, dass ich nun eindeutig sagen kann dass von den 25 Befehlen des DOIF genau einer nicht funktioniert und das Ergebnis zu Null macht:
my $dt = ReadingsVal("Solarpumpe_Count","pulseTimeIncrement",0)
Und dies, obwohl zu dem Zeitpunkt, in dem das Event "true" ist dort definitiv ein Wert , z.B. 91 (die Laufzeit des aktuellen Einschaltintervalls) drin steht.
Alle anderen Befehle werden ausgeführt und auch dass Triggerevent passt.
Ich bin jetzt seit Tagen an dieser Hürde und komme nicht drüber!
Freue mich über jeden Hinweis, der zum Ziel führt.
ZitatUnd dies, obwohl zu dem Zeitpunkt, in dem das Event "true" ist dort definitiv ein Wert , z.B. 91 (die Laufzeit des aktuellen Einschaltintervalls) drin steht.
Genau das bezweifle ich.
Falls nicht vorhanden, definiere mal eine FileLog auf Solarpumpe:pulseIncrement und dem Event:
define testLog FileLog ./log/solarpulse-%Y-%U.log Solarpumpe:pulseIncrement.*|Solarpumpe.*(on|off).*, prüfe, dass du kein event-on-change-reading oder event-on-update-reading hast, das die Events ausfiltern könnte, und beobachte genau nur diese Werte im Laufe der Zeit.
{ ReadingsVal("Solarpumpe_Count","pulseTimeIncrement",'haste mist jebaut') }
Das mal bitte die Eingabezeile von FHEMWEB eingeben. Wenn du Mist erhälst stimmt was mit dem Devicenamen oder dem Reading nicht.
@CoolTux: ich glaube aber eher, dass das Problem an die Reihenfolge von Events liegt. Da hatte er schon zu Solarpumpe das "list" geliefert, und dort war doch ein Wert zu sehen:
Zitat von: Tom S am 26 August 2017, 10:47:51
Hier das Listing des HourCounters:
Internals:
CHANGED
DEF Solarpumpe:on Solarpumpe:off
NAME Solarpumpe_Count
NR 103
NTFY_ORDER 50-Solarpumpe_Count
STATE 2 Starts, 3.0 Minuten, 0.01kWh, 102sek
TYPE HourCounter
VERSION 1.0.1.2 - 24.12.2014
READINGS:
...
2017-08-26 10:31:31 pulseTimeEdge 102
2017-08-26 10:31:31 pulseTimeIncrement 102
2017-08-26 10:31:31 pulseTimeOverall 423359
Aber OK, das Test tut nicht weh ;)
Oder hast du eine andere Quelle im Verdacht?
Noch nicht. Mich hatte die Aussage mit dem Ergebnis zu null macht etwas irritiert. Deswegen wollte ich mal schauen ob da wirklich was passiert.
Hallo CoolTux,
ich habe mal das Filelog wie von dir beschrieben erstellt. Hier mal ein aktuelles LOG von heute:
2017-08-28_19:26:54 Solarpumpe on
2017-08-28_19:26:56 Solarpumpe Longpress: on
2017-08-28_19:27:35 Solarpumpe off
2017-08-28_19:27:35 Solarpumpe Longpress: off
Im der fhem.log steht für die gleiche Zeit:
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=countsPerDay: 47
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=countsOverall: 3630
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=pulseTimeIncrement: 0
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=pulseTimeEdge: 41
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=pulseTimePerDay: 4935
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=pulseTimeOverall: 437445
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=pauseTimeIncrement: 1344
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=pauseTimeEdge: 1344
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=pauseTimePerDay: 65079
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=pauseTimeOverall: 8367789
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=value: 1
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=47
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=tickUpdated: 979
2017.08.28 19:26:54 1: NAME=Solarpumpe_Count EVENT=tickChanged: 332
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=countsPerDay: 47
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=countsOverall: 3630
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=pulseTimeIncrement: 41
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=pulseTimeEdge: 41
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=pulseTimePerDay: 4976
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=pulseTimeOverall: 437486
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=pauseTimeIncrement: 0
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=pauseTimeEdge: 1344
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=pauseTimePerDay: 65079
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=pauseTimeOverall: 8367789
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=value: 0
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=47
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=tickUpdated: 980
2017.08.28 19:27:35 1: NAME=Solarpumpe_Count EVENT=tickChanged: 333
Ich lese daraus, dass mit dem Event Pumpe on pulseTimeIncrement auf Null gesetzt wird und anfängt zu zählen. Mit Pumpe off zeigt pulseTimeIncrement den Wert in Sekunden, den ich benötige für meine Berechnung.
Trotzdem klappt halt das Auslesen des ReadingsVal nicht.
Grüße
Tom S
Ah sorry, mein Schuld. Es fehlt etwas in der FileLog Definition:
define testLog FileLog ./log/solarpulse-%Y-%U.log Solarpumpe_Count:pulseTimeIncrement.*|Solarpumpe.*(on|off).*
Aber ich glaube, es ist doch, was ich meinte. Fakt ist, dass der pulseTimeIncrement machmal gleich 0 ist. Jetzt müssen wir die Reihenfolge von den Events genauer beobachten. Aber ich vermute, es ist noch nicht aktualisiert (dann noch = 0) wenn das Event "off" kommt. Weil dieses "off" das auslösende Event für die Kalkulation von den anderen Readings ist. Das lässt sich dann vielleicht mit einem einfachen "attr <doifname> wait 1" lösen. Alternativ, das DOIF auf pulseTimeIncrement triggern
Ich habe die Idee mit dem attr <...> wait 1 ausprobiert, ebenso das DOIF auf den HourCounter direkt zu triggern. Beides bringt leider keine Verbesserung: es lässt sich kein ReadingsVal des HourCounter per DOIF auslesen. Auch ein einfaches set <XY> [HourCounter:Reading] auf Kommandoebene bringt als Ergebnis stets 0.
Mache ich da noch einen Denkfehler?
Kann man die Log mit allen Events sehen?
Das Logfile sieht wie folgt aus:
2017.08.30 09:13:18 3: get I2C_Device read 48 40 4 : received : 140 135 255 94 | transmission: Ok
2017.08.30 09:13:19 3: GenShellSwitch command result: sending code[16762193]
2017.08.30 09:13:19 2: GenShellSwitch set Aussenbeleuchtung off
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=countsPerDay: 1
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=countsOverall: 3684
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=pulseTimeIncrement: 0
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=pulseTimeEdge: 55
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=pulseTimePerDay: 0
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=pulseTimeOverall: 443394
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=pauseTimeIncrement: 51463
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=pauseTimeEdge: 51463
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=pauseTimePerDay: 33214
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=pauseTimeOverall: 8497327
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=value: 1
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=1
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=tickUpdated: 127
2017.08.30 09:13:34 1: NAME=Solarpumpe_Count EVENT=tickChanged: 440
2017.08.30 09:14:58 1: NAME=Solarpumpe_Count EVENT=countsPerDay: 1
2017.08.30 09:14:58 1: NAME=Solarpumpe_Count EVENT=countsOverall: 3684
2017.08.30 09:14:58 1: NAME=Solarpumpe_Count EVENT=pulseTimeIncrement: 84
2017.08.30 09:14:58 1: NAME=Solarpumpe_Count EVENT=pulseTimeEdge: 84
2017.08.30 09:14:58 1: NAME=Solarpumpe_Count EVENT=pulseTimePerDay: 84
2017.08.30 09:14:58 1: NAME=Solarpumpe_Count EVENT=pulseTimeOverall: 443478
2017.08.30 09:14:58 1: NAME=Solarpumpe_Count EVENT=pauseTimeIncrement: 0
2017.08.30 09:14:58 1: NAME=Solarpumpe_Count EVENT=pauseTimeEdge: 51463
2017.08.30 09:14:58 1: NAME=Solarpumpe_Count EVENT=pauseTimePerDay: 33214
2017.08.30 09:14:58 1: NAME=Solarpumpe_Count EVENT=pauseTimeOverall: 8497327
2017.08.30 09:14:58 1: NAME=Solarpumpe_Count EVENT=value: 0
2017.08.30 09:14:58 1: NAME=Solarpumpe_Count EVENT=1
2017.08.30 09:14:58 1: NAME=Solarpumpe_Count EVENT=tickUpdated: 128
2017.08.30 09:14:59 1: NAME=Solarpumpe_Count EVENT=tickChanged: 441
2017.08.30 09:18:18 3: get I2C_Device read 48 40 4 : received : 140 152 255 96 | transmission: Ok
2017.08.30 09:18:19 3: GenShellSwitch command result: sending code[16762193]
Interessanterweise liefert das stateFormat des devices
stateFormat {sprintf("%.0f Starts",ReadingsVal("Solarpumpe_Count","countsPerDay",0)).sprintf(", %.1f Minuten",ReadingsVal("Solarpumpe_Count","pulseTimePerDay",0)/60).sprintf(", %.2f kWh",ReadingsVal("Solarpumpe_Count","pulseTimePerDay",0)*0.150/3600).sprintf(", %.0f sek",ReadingsVal("Solarpumpe_Count","pulseTimeIncrement",0))}
korrekte Werte für die Readings des HourCounter, z.B.:
Laufzeit, Energieverbrauch Solarpumpe: 1 Starts, 1.4 Minuten, 0.00 kWh, 84 sek
Warum also nicht das ReadingsVal im DOIF?
Ich sehe aber das Event Solarpumpe on/off nicht
Ich meinte "meine" Log wie oben definiert.
ZitatWarum also nicht das ReadingsVal im DOIF?
Das ist m.A. eine Frage von Zeitpunkt der jeweiligen Events
... du meinst das Logfile solarpulse...
Hier ist es:
2017-08-30_16:29:19 Solarpumpe Longpress: on
2017-08-30_16:31:30 Solarpumpe off
2017-08-30_16:31:30 Solarpumpe Longpress: off
2017-08-30_16:41:52 Solarpumpe on
2017-08-30_16:41:53 Solarpumpe Longpress: on
2017-08-30_16:44:06 Solarpumpe off
2017-08-30_16:44:06 Solarpumpe Longpress: off
2017-08-30_17:16:15 Solarpumpe on
2017-08-30_17:16:16 Solarpumpe Longpress: on
2017-08-30_17:17:42 Solarpumpe off
2017-08-30_17:17:42 Solarpumpe Longpress: off
Die Triggerung des DOIF erfolgt somit korrekt und regelmäßig (wenn die Sonne scheint).
Das DOIF führt ja auch alles korrekt aus. Ich vermute inzwischen, dass bei dem HourCounter etwas nicht stimmt. Den HourCounter hatte ich ja bereits weiter oben gelistet. Ich habe mal andere Readings ausprobiert und außer im stateFormat des HourCounter-devices selbst bekommt man nichts davon heraus, weder auf Kommandoebene noch per at oder DOIF.
Sollte das so sein? Sind die HourCounter Readings generell nicht auslesbar oder sehe ich nur den Wald vor Bäumen nicht? Ich brauche unbedingt die jeweilige Laufzeit der Solarpumpe für die jeweilige Einschaltperiode, um die Energiemenge berechnen zu können.
Vielleicht gibt es ja einen anderen Weg als per HourCounter?
Hast Du die Definition der Log angepasst?
define testLog FileLog ./log/solarpulse-%Y-%U.log Solarpumpe_Count:pulseTimeIncrement.*|Solarpumpe.*(on|off).*
Sorry fürs Kapern, aber:
Zitat von: amenomade am 29 August 2017, 01:27:39
define testLog FileLog ./log/solarpulse-%Y-%U.log Solarpumpe_Count:pulseTimeIncrement.*|Solarpumpe.*(on|off).*
kann mir Mal jemand bitte den Regex dieser Definition aufdröseln?
Alle Events des Readings pulseTimeIncrement des Devices Solarpumpe_Count + on/off Events des Devices Solarpumpe
Hallo amenomade,
hier der Inhalt der Log-Datei:
2017-09-02_17:33:06 Solarpumpe_Count pulseTimeIncrement: 0
2017-09-02_17:33:06 Solarpumpe on
2017-09-02_17:33:07 Solarpumpe Longpress: on
2017-09-02_17:35:31 Solarpumpe_Count pulseTimeIncrement: 145
2017-09-02_17:35:31 Solarpumpe off
2017-09-02_17:35:31 Solarpumpe Longpress: off
2017-09-02_17:42:44 Solarpumpe_Count pulseTimeIncrement: 0
2017-09-02_17:42:44 Solarpumpe on
2017-09-02_17:42:47 Solarpumpe Longpress: on
2017-09-02_17:45:01 Solarpumpe_Count pulseTimeIncrement: 137
2017-09-02_17:45:01 Solarpumpe off
2017-09-02_17:45:01 Solarpumpe Longpress: off
2017-09-02_17:53:39 Solarpumpe_Count pulseTimeIncrement: 0
2017-09-02_17:53:39 Solarpumpe on
2017-09-02_17:53:39 Solarpumpe Longpress: on
2017-09-02_17:55:56 Solarpumpe_Count pulseTimeIncrement: 137
2017-09-02_17:55:56 Solarpumpe off
2017-09-02_17:55:56 Solarpumpe Longpress: off
Die Events des HourCounter kommen also korrekt und stehen offenbar auch zeitgleich (zumindest auf die Sekunde) mit der Solarpumpe zur Verfügung.
Na ja, wie dem auch sei: ich hab's aufgegeben und berechne mir die Laufzeit der Pumpe nun selbst durch Abspeichern der Systemzeit bei Solarpumpe "on" und Differenzbildung mit der aktuellen Zeit bei "off". Funktioniert tadellos und ergibt die gleichen Werte wie pulseTimeIncrement.
Warum aber das Reading pulseTimeIncrement des HourCounter nicht auslesbar ist erschließt sich mir nach wie vor nicht und hat mich eine gute Woche Bastlei gekostet.
ZitatDie Events des HourCounter kommen also korrekt und stehen offenbar auch zeitgleich (zumindest auf die Sekunde) mit der Solarpumpe zur Verfügung.
Stimmt nicht ganz. Bei der Zeit wo Solarpumpe auf "on" geht, ist pulseTimeIncrement gleich 0. Erst nach 2.5 Minuten kommt ein neuer Wert 145
2017-09-02_17:33:06 Solarpumpe_Count pulseTimeIncrement: 0
2017-09-02_17:33:06 Solarpumpe on
2017-09-02_17:33:07 Solarpumpe Longpress: on
2017-09-02_17:35:31 Solarpumpe_Count pulseTimeIncrement: 145Jetzt die Frage: wäre das Triggern vom DOIF auf pulseTimeIncrement statt "on" nicht eine Lösung?
Zitat
Stimmt nicht ganz. Bei der Zeit wo Solarpumpe auf "on" geht, ist pulseTimeIncrement gleich 0. Erst nach 2.5 Minuten kommt ein neuer Wert 145
Das ist schon korrekt. Mich interessiert ja auch nur der Wert bei Solarpumpe "off", um zu wissen, wie lange die Pumpe gelaufen hat.
Stimmt, sorry. Und die Events sind anscheinend in der richtige Reihenfolge... na ja, ich weiss auch nicht, was passiert. Man könnte noch die Logs mit millisekunden bestücken, damit man genau sieht, aber ich glaube, das wird nichts bringen. Wenn Du eine andere Lösung gefunden hast, um so besser.