[Gelöst] userReading und event-on-change-reading

[manne44]

Hallo,
ich habe mal eine grundsätzliche Frage, die ich mir nicht beantworten kann:
Es geht um Log-Einträge in die Datenbank. Zu Test habe ich mal folgendes gemacht:

Code Auswählen Erweitern

define TestCnt dummy
attr TestCnt userReadings cnt1 {ReadingsVal("TestCnt","cnt0","0")+1}, cnt2 {ReadingsVal("TestCnt","cnt1","0")+2}
attr TestCnt room Test
attr TestCnt event-on-change-reading cnt0.*, cnt1.*

define TestCntInc at +*00:00:10 { my $x = ReadingsVal("TestCnt","cnt0","0")+1;; fhem('setreading TestCnt cnt0 '.$x);; }


define FileLog_TestCnt FileLog ./log/testCnt.log TestCnt


Wie man sieht, habe ich 2xuserReading und ein "event-on-change-reading"-Attribut das in der FHEM Referenz wie folgt beschrieben wird:

Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings".

Im Logfile wird dann aber nur der Wert für cnt0 eingetragen, obwohl das Reading cnt1 sich auch ändert:

Code Auswählen Erweitern

2016-11-11_12:49:40 TestCnt cnt0: 62
2016-11-11_12:49:50 TestCnt cnt0: 63
2016-11-11_12:50:00 TestCnt cnt0: 64
2016-11-11_12:50:10 TestCnt cnt0: 65
2016-11-11_12:50:20 TestCnt cnt0: 66
2016-11-11_12:50:30 TestCnt cnt0: 67
2016-11-11_12:50:40 TestCnt cnt0: 68
2016-11-11_12:50:50 TestCnt cnt0: 69


Wenn ich jedoch

Code Auswählen Erweitern

attr TestCnt event-on-change-reading cnt0.*|cnt1.*
schreibe, also die beiden Readings "verodere", dann kommt auch der Wert für cnt1 in das Logfile:

Code Auswählen Erweitern

016-11-11_12:46:19 TestCnt cnt0: 44
2016-11-11_12:46:19 TestCnt cnt1: 45
2016-11-11_12:46:29 TestCnt cnt0: 45
2016-11-11_12:46:29 TestCnt cnt1: 46
2016-11-11_12:46:39 TestCnt cnt0: 46
2016-11-11_12:46:39 TestCnt cnt1: 47
2016-11-11_12:46:49 TestCnt cnt0: 47
2016-11-11_12:46:49 TestCnt cnt1: 48
2016-11-11_12:46:59 TestCnt cnt0: 48
2016-11-11_12:46:59 TestCnt cnt1: 49
2016-11-11_12:47:09 TestCnt cnt0: 49
2016-11-11_12:47:09 TestCnt cnt1: 50


Das hat auch einen für mich wichtigen Hintergrund, weil an bestimmter Stelle nichts geloggt wurde, obwohl ich dort die offenbar die richtige Schreibweise verwendet hatte. Wer kann mir denn mal sagen was und warum die offenbar richtige Schreibweise <Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings"> nicht zum gewünschten Ergebnis führt und was die "Veroderung" hier anders macht.
Vielen Dank schon mal.

[marvin78]

Dort steht "durch Komma getrennt" und nicht "durch Komma und Leerzeichen getrennt"

[manne44]

Vielen Dank für die Antwort, aber das erklärt noch nicht den Unterschied zum Oder. Normalerweise werden in Sprachen wie C usw Leerzeichen überlesen. Warum ist das hier nicht so?

[marvin78]

Weil das Komma das Trennzeichen ist und nicht KommaBLANK. Mehr ist dazu nicht zu sagen. Es ist klar dokumentiert. Die Frage lautet, warum du es auf Teufel komm raus anders haben möchtest?

Und "C usw". überlesen pauschal auch keine Leerzeichen. Das ist schlicht falsch.

Und doch, es erklärt auch den Unterschied.

[DeeSPe]

Und da eigentlich auch überall RegEx zugegen ist, wäre:

Code Auswählen Erweitern

attr TestCnt event-on-change-reading cnt0.*|cnt1.*
nicht ver-oder-t sondern ver-und-tet. Ein normales oder (im if) wäre ja ||.

Gruß
Dan

[manne44]

Hallo, vielen Dank für die Antworten, aber obwohl ich niemanden zu nahe treten will, habe ich doch noch einige Anmerkungen:

• Ich bin kein Experte für "regular expressions", aber das "|" ist doch eher als "ODER" zu verstehen. Auch in Perl wie in C ist das "|" ein bitweises ODER.
• In der Sprache C werden "Whitespaces" sofern sie sich nicht in Literale befinden vom Präprozessor entfernt. So ist es bedeutungslos ob sprintf(txt, "%d. %s\n", nr, text) oder sprintf(txt, "%d. %s\n",    nr,     text) geschrieben wird, also die Anzahl der Leerzeichen ist egal. Auch hier wird für die Variablen eine durch Kommata getrennte Liste angegeben, aber Whitespaces sind egal. In Perl scheint die Anzahll von Leerzeichen in dieser durch Kommata getrennten Liste in sprintf(..) auch egal zu sein, ist ja auch ein Mix aus C und anderen Sprachen.
• Auf die Frage
  

  Die Frage lautet, warum du es auf Teufel komm raus anders haben möchtest?

  antworte ich, daß ich das überhaupt nicht anders haben will, ich es nur nicht gewußt habe, und es mir etwas ungewöhnlich vorkommt.
  Ich bin froh und glücklich FHEM benutzen zu können, habe aber ab und zu auch Verständnisprobleme, wie hier z.B. Aber nun weiß ich es und gut ist.
  

Auch meine Frage, wie es zu verstehen ist, daß auch

Code Auswählen Erweitern

attr TestCnt event-on-change-reading cnt0.*|cnt1.*
funktioniert, obwohl hier eine "durch Kommata getrennte Liste" (ohne Leerzeichen) verwendet werden soll, kann ich mir nur damit erklären, daß das

Code Auswählen Erweitern

cnt0.*|cnt1.*
wirklich als regular expression genommen wird und bedeutet "nehme cnt0.* ODER cnt1.*", was ja gewollt ist. Stimmt das?

[justme1968]

1. das | ist ein oder. aber kein bitweises sondern es wird damit eine alternative in der regex gezeigt. der unterschied ist wichtig weil es bei falscher klammerung nicht intuitive dinge tut.  und man könnte es auch auf andere arten schreiben. z.b. cnt(0|1).*

2. der attribut wert wird. ich durch den parser einer sprache ausgewertet sondern durch fhem und hier wird das leerzeichen nicht als unwichtig angesehen. unter anderem weil an ander stelle tatsächlich leerzeichen in den werten erlaubt sind. wie in der komma getrennten raum liste.

3. ja. es ist eine durch komma getrennte regex liste. müsste auch so in der commandref stehen. und so geschrieben ist es eine liste aus einer einzigen regex.

gruss
  andre

[marvin78]

Dass alles dokumentiert ist, habe ich ja oben geschrieben. Das beantwortet eigentlich auch alle Fragen.

Und es bleibt dabei: Programmiersprachen wie C "überlesen" nicht pauschal alle Leerzeichen. Es kommt IMMER auf den Kontext an. Hier ist der Kontext, dass es ein FHEM-Parser ist, wie justme1968 schon schrieb, der seine eigenen klaren Regeln hat und die Gründe dafür, dass Leerzeichen nicht ignoriert, liefert sowohl die Doku, als auch justme1968 übersetzt über mir und auch der gesunde Menschenverstand. Solche Dinge gibt es auch in C Programmen. Dann muss man sich an die dokumentierte Syntax halten. Lesen und Mitdenken ist immer erlaubt.

[manne44]

Herzlichen Dank für die fundierten Erläuterungen von justme1968, die mich in dieser Sache wirklich "erleuchtet" haben. Ich habe jetzt den Erkenntnisgewinn, den ich mit meiner Frage auch erhofft hatte. Dadurch wird es mir in Zukunft auch leichter sein etwaige ähnliche Ungereimtheiten zu erkennen und selbst zu lösen.
Zu C will ich nun nichts mehr sagen, aber das kann ich nun wirklich.
Vielen Dank an alle.

[manne44]

Ich habe mal noch mal alles durchsucht und habe tatsächlich alle "event-on-change-reading"-Listen  immer als ein Regex geschrieben. Der Grund war der, daß ich zur besseren Lesbarkeit immer gern überall ein zusätzliches Leerzeichen einfüge, was hier aber falsch ist. Und weil die falsche Leerzeichen-Notation einfach nie funktionieren wollte, hatte ich dann mehr als 50x diese Schreibweise verwendet, die auch immer zuverlässig funktioniert hat wie beispielsweise

Code Auswählen Erweitern

attr Hzg.Bad event-on-change-reading (batteryLevel|desired-temp|measured-temp|actuator)

Ob das aber laufzeitmäßig ungünstiger ist als die mit Kommata getrennte Liste, das ist mir unklar.

[marvin78]

Ich denke nicht, dass du einen Unterschied feststellen kannst.  Aber wenn ich mir unsicher bin, probiere ich solche Dinge einfach aus.

[manne44]

Wenn ich wüßte wie ich das messen könnte, dann würde ich das sicher machen, aber ich weiß das nicht.