Seit Fhem-Update kein richtiger Wert mehr in SQL-Datenbank via eventMap....

[Sven]

Hallo miteinander...,

ich hänge irgendwie auf der Stelle. Ich habe einige Bewegungsmelder FS20pira im Einsatz, die schön mit den Befehlen "on-old-for-timer 120" (und 240) und "off" an fhem senden. Mit nem EventMap habe ich mir diese Werte umgebogen auf 0 und 1. Befehl lautet..

Code Auswählen Erweitern

attr BM_Meldername eventMap /on-old-for-timer 120:1/off:0/

Die Werte landen entsprechend in eine SQL-Datenbank. Mit diesen Werte führe ich dann Aktionen aus, wie z.B. Kamerabild abrufen bei Bewegung und Bewegungserkennung per SVG-Plot darstellen. Alles klappte prima...

Seit ich am 30.07. nen Update in Fhem durchgeführt habe, werden die Werte in FHEM zwar noch richtig gesetzt, d.h. STATE wird auf 0 und 1 gesetzt, aber in der SQL-DB werden sie nicht geschrieben. Hier landen nun die ursprünglichen Werte, also "on-old-for-timer 120" und "off". Meine Alarmierung dass nen Kamera-Bild abgerufen und per Telegram verschickt wird, klappt daher immer noch. Nur mein Plot kann natürlich aufgrund der fehlenden VALUES 0 und 1 in der DB nicht dargestellt werden.

Hat jemand vielleicht ne Idee was geändert wurde? Ich kann nix finden, und Änderungen an meinem EventMap bringen auch nix. Diese Änderungen sind zwar im Device-STATE dann richtig drin, landen aber nicht richtig in der DB. Hier sind wieder die anderen drin.

Es werden also die "umgemappten" Events/Values der Melder zwar richtig in FHEM gesetzt, aber nicht mehr richtig in der SQL-Datenbank geschrieben. Ist das ggf. ein neuer Bug?

Falls ihr zur weiteren Diagnose noch was braucht, dass sagt bitte Bescheid....

In Bild ist nen Auszug der SQL zu sehen....

Liebe Grüße
Sven

[DS_Starter]

Hallo Sven,

möglicherweise hängt es damit zusammen, dass dblog beim Reading "state" seit der V2.20.0 auch das Reading an sich, also "state", intern abruft.
Du kannst dir das Attribut "addStateEvent=0" in deinem DbLog-Device setzen um auf die alte Verfahrensweise (ohne state im Event) zurück zu schalten.
Vielleicht hilft dies an dieser Stelle.

VG

[Sven]

Hallo DS_Starter,

das scheint es tatsächlich zu sein. 
Nachdem ich das Attribut gesetzt habe, werden nun wieder die "richtigen" Werte in die SQL geschrieben!

Ein MEGA-DANKESCHÖN!

Ich verstehe im Moment nur nicht ganz den Hintergrund dieser Umstellung... Hat das Vorteile, die für mich nicht ersichtlich sind?

Lieben Gruß
Sven

[DS_Starter]

Ich verstehe im Moment nur nicht ganz den Hintergrund dieser Umstellung... Hat das Vorteile, die für mich nicht ersichtlich sind?

Ja, das state-Reading erzeugt historisch ein Event ohne das "state". Es verhält sich also anders als "normale" Readings. Das führt unter Umständen bei Usern, die das state-Reading loggen möchten und aufgrund des Inhaltes eine unbefriedigende "Erkennung" stattfindet dazu, dass das Logging-Ergebnis unbrauchbar ist.
Die Mehrheit der User wird es begrüßen dass "state" auch so erkannt wird. Aber in manchen Fällen, so wie hier, kann das Gegenteil der Fall sein.
Mit dem Attribut kann man das entsprechend anpassen. Möglicherweise hast du eine andere Anwendung, für die eine genau gegenteilige Einstellung günstig wäre. Dann wird es schwierig 

Stöbere mal hier : https://forum.fhem.de/index.php/topic,74234.msg659354.html#msg659354

Grüße,
Heiko

[Sven]

Hallo Heiko,

ufff.... gerade mal alles durchgelesen. Klingt ja, dass ich in Dir genau den RICHTIGEN gefunden habe! Geht recht tief in die Materie, in der ich als Nicht-Programmierer nicht so tief drin bin. Verständlich ist es für mich daher zumindest halbwegs.

Dass die Funktion addStateEvent=0 wieder den "für-mich-Normalzustand" herstellt ist perfekt. Ich habe mir da wohl wirklich eine Anwendung gebastelt, die mit dem neuen Attribut addStateEvent=1 nicht optimal arbeitet.

Wie gesagt, die BM-Melder haben intern alles richtig gemacht:
Auslösung des Melders, Readings des Melders zur besseren Verarbeitung umgemappt, dann mit DOIF in Abhängigkeit von DUMMY-Schalter (Alarmierung an oder aus) von meiner IPCam nen getImage gemacht, Foto auf Raspi als Snapshot abgelegt und dann diese Fotos per Telegram aufs Handy geschickt. Das hat immer alles perfekt geklappt. Somit ist mir die Umstellung nicht aufgefallen.

Erst heute, als ich mal den Graphen checken wollte... Leider nur eine Linie die trotz Auslösung immer auf 0 hing. Konnte ich nicht nachvollziehen. Parallel zur Alarmierung habe ich diesen Graphen, der mir ähnlich wie bei der Temperatur die Auslösungen zeigt. Da habe ich dann die Werte 0 und 1 für die Achse abgerufen. Hier mal der Code des Plots:

Code Auswählen Erweitern

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics ("Aus" 0, "An" 1)
set y2tics ("Aus" 0, "An" 1)
set grid ytics
set ylabel ""
set y2label ""
set yrange [-0.1:1.3]
set y2range [-0.1:1.3]

#DBLogging <SPEC1>:state

plot "<IN>" using 1:2 axes x1y1 title 'Bewegung Terrasse' ls l0fill lw 1 with steps

Der Graph sieht dann so wie im Bild aus! Hier klappte er noch. Aber ab heute habe ich auch wieder Werte.... 

Danke nochmal für die Klasse Hilfe!

LG
Sven