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

Begonnen von manne44, 11 November 2016, 13:26:10

Vorheriges Thema - Nächstes Thema

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:
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:
ZitatDieses 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:
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
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:
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.
RPI4-Buster mit SSD, RPI-Zero mit Bookworm

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?
RPI4-Buster mit SSD, RPI-Zero mit Bookworm

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:
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
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

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
    ZitatDie 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
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
cnt0.*|cnt1.*
wirklich als regular expression genommen wird und bedeutet "nehme cnt0.* ODER cnt1.*", was ja gewollt ist. Stimmt das?
RPI4-Buster mit SSD, RPI-Zero mit Bookworm

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

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.
RPI4-Buster mit SSD, RPI-Zero mit Bookworm

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
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.
RPI4-Buster mit SSD, RPI-Zero mit Bookworm

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.
RPI4-Buster mit SSD, RPI-Zero mit Bookworm