Ich habe in meinem Regensensor eine eventMap definiert, die mir die Werte "rain" in 25 und "dry" in 0 umsetzt.
Internals:
DEF 20EC0401
NAME out_Regen_Sensor
NR 338
STATE 0
TYPE CUL_HM
chanNo 01
device out_Regen
peerList self02,
Readings:
2013-08-08 13:53:38 R-eventFilterTime dry.5
2013-08-08 13:53:39 R-self02-expectAES off
2013-08-08 13:53:39 R-self02-peerNeedsBurst off
2013-08-08 13:53:38 R-transmitTryMax 6
2013-08-08 13:53:38 RegL_01: 08:00 22:64 23:05 30:06 00:00
2013-08-08 13:53:39 RegL_04:self02 01:00 00:00
2013-08-25 22:21:20 lastRain 2013-08-rain
2013-08-26 21:58:07 peerList self02,
2013-08-25 22:21:20 state dry
2013-08-25 22:21:20 timedOn off
2013-08-25 22:21:12 trigger 181:dry (to out_Regen)
Helper:
Role:
chn 1
Attributes:
eventMap rain:25 dry:0
expert 2_full
group Balkon Wetter
model HM-Sen-RD-O
peerIDs 00000000,20EC0402,
room 20_Wetter,17_Balkon
Das völlig unselektive Arbeiten der eventMap führt nun dazu, dass Readings verstümmelt werden:
(http://forum.fhem.de/index.php?t=getfile&id=5319&private=0)
Eigentlich sollte da ein vollständiger TimeStamp 2013-08-25... stehen. Die eventMap verstümmelt mir im gleichen Sensor auch noch andere Readings (bei R-eventFilterTime sollte eigentlich 0.5 stehen, nicht dry.5), indem Zahlen durch Text ersetzt werden.
1. Eine Umsetzung des Zahlenwertes 25 in einen Text war bei meiner Definition der eventMap in keinster Weise angedacht und ist auch nicht erwünscht.
2. Die Wirkungsweise der eventMap auf alle Readings und immer in beide Richtungen halte ich in vielen Fällen nicht für zielführend.
> 2. Die Wirkungsweise der eventMap auf alle Readings und immer in beide Richtungen halte ich in vielen Fällen nicht für zielführend.
Kurz:
Kann ich nachvollziehen, habe aber (noch) keine befriedigende Loesung dafuer.
Lang:
Eigentlich benoetigt man zwei Attribute fuers mappen: eins hin, eins zurueck, und jeweils mit optionalen spezifikation des readings, welches modifiziert werden soll. Zwei sind notwendig, damit man beim von-Wert ein regexp angeben kann, was natuerlich als Ziel nicht tragbar ist. Selbst dabei muesste man ueber den Syntax nachdenken, damit ein Anfaenger das kapieren kann.
eventMap hat den Vorteil, dass es eine Konvertierung in beide Richtungen anbietet, d.h. der Benutzer muss wenig spezifizieren, und meist funktioniert es. Leider ist es viel zu ungenau, und fuehrt an diversen Stellen (nicht nur hier) zu Problemen.
Vmtl. muss man parallel zu eventMap einen anderen Mechanismus einfuehren, und eventMap dann irgendwannmal abschalten. Da eventMap an ueberraschend vielen Stellen verwendet wird, und ich keine griffige Alternative habe, habe ich mich noch nicht an einem Umbau gewagt.
Zitat von: rudolfkoenig schrieb am Mi, 28 August 2013 11:11Eigentlich benoetigt man zwei Attribute fuers mappen: eins hin, eins zurueck,
Nein. Es würde schon sehr viel bringen, wenn eventMap einfach das Mapping nur in der "Richtung" machen würde, wie ich das vorgebe. Wenn ich also "dry:0 rain:25" angebe, dann will ich das auch nur so gemappt haben und nicht auch umgekehrt. Für beide Richtungen müsste man dann eben das hier schreiben: "dry:0 rain:25 0:dry 25:rain"
Das löst zwar noch nicht das Problem mit dem unselektiven Arbeiten auf alle Readings, aber meistens will man ja nur einen Wert mappen, der ohnehin nur in einem einzigen Reading vorkommt.
Das sollte wirklich nicht sein: ich schau mir das mal an, kann abr etwas dauern.
Zitat von: rudolfkoenig schrieb am Do, 29 August 2013 09:09Das sollte wirklich nicht sein: ich schau mir das mal an
ich auch :)
Zitat von: betateilchen schrieb am Do, 29 August 2013 01:09Wenn ich also "dry:0 rain:25" angebe, dann will ich das auch nur so gemappt haben
Temporär habe ich das eventMap jetzt als "dry:000 rain:025" definiert. Das beseitigt momentan die negativen Auswirkungen in der Darstellung, ohne andere Funktionen zu beeinträchtigen, wegen derer ich das Mapping überhaupt brauche.
Ich kriege das Problem nicht reproduziert. Da ich HM nicht so recht offline testen kann/will, habe ich es mit einem S300TH probiert:
fhem> define s300th_2 CUL_WS 2 -1.0 -10.1
fhem> attr s300th_2 eventMap dry:20
fhem> inform timer
fhem> { Dispatch($defs{CUL}, "K1115426516", undef) }
2013-08-31 16:45:50.869 CUL_WS s300th_2 T: 20.5 H: 55.3
2013-08-31 16:45:50.869 CUL_WS s300th_2 temperature: 20.5
2013-08-31 16:45:50.869 CUL_WS s300th_2 humidity: 55.3
2013-08-31 16:45:50.869 CUL_WS s300th_2 dewpoint: 11.2
ARRAY(0x7fc2c9e46cd0)
fhem>
Wenn Du irgendetwas in dieser Art zeigen kannst, was das Problem demonstriert, dann suche ich weiter.
Hallo Rudi,
das ist cool... Martin schiebt es auf eventMap und Du vermutest HM als Ursache *lach*
Schau mal bitte hier: Link (http://forum.fhem.de/index.php?topic=13997.msg91817#msg91817) ab diesem Beitrag hatte ich bereits mit Martin über das Problem diskutiert, bevor ich mein Problem auf Deiner Seite vermutet habe.
Wenn ich irgendwas spezielles reproduzieren soll, lass es mich bitte wissen. Bei mir ist das "Fehlverhalten" Standard, ich muss dazu nix besonderes machen.
Viele Grüße
Udo
> das ist cool... Martin schiebt es auf eventMap und Du vermutest HM als Ursache *lach*
Das ist nicht wahr, obwohl ich HM kurz wirklich in Verdacht hatte, da Martin im CUL_HM eventMap ausliest.
Ich sagte nur, dass ich es mit HM nicht testen kann/will, weil mir HM zu kompliziert ist um es offline zu testen. D.h. ich will ein Beispiel was ich ohne Hardware nachstellen kann, z.Bsp. mit einem dummy, mit einem S300TH (wie oben geschrieben), etc.
dann muss wohl Martin ran, so ein Beispiel zu konstruieren...
Hi Rudi,
Ich habe jetzt kein Beispiel zum Testen ohne HW.
probiert habe ich folgendes
attr <name> eventMap 100:testme
dann habe ich alle Readings gelöscht, geht bei HM mit
set <name> clear readings
und dann neue Readings erzeugt. Bei HM einfach, getConfig leist so einiges.
2013-08-31 20:10:27 PairedTo 0x1743BF
2013-08-31 20:10:28 R-driveDown 50 s
2013-08-31 20:10:28 R-driveTurn 1.2 s
2013-08-31 20:10:28 R-driveUp 50 s
2013-08-31 20:10:27 R-pairCentral 0x1743BF
2013-08-31 20:10:36 R-self01-lgActionType jmpToTarget
2013-08-31 20:10:36 R-self01-lgOnLevel 100 %
2013-08-31 20:10:36 R-self01-shActionType jmpToTarget
2013-08-31 20:10:36 R-self01-shOnLevel 100 %
2013-08-31 20:10:38 R-self02-lgActionType jmpToTarget
2013-08-31 20:10:38 R-self02-lgOnLevel 100 %
2013-08-31 20:10:38 R-self02-shActionType jmpToTarget
2013-08-31 20:10:38 R-self02-shOnLevel 100 %
2013-08-31 20:10:28 R-sign off
2013-08-31 20:11:35 deviceMsg on (to LANIf1)
2013-08-31 20:11:35 level 100 %
2013-08-31 20:11:35 motor stop:on
2013-08-31 20:11:35 state on
danach kommen folgende trigger
2013-08-31 20:10:27.759 CUL_HM RolloW R-pairCentral: 0x1743BF
2013-08-31 20:10:28.531 CUL_HM RolloW R-sign: off
2013-08-31 20:10:28.531 CUL_HM RolloW R-driveTurn: 1.2 s
2013-08-31 20:10:28.531 CUL_HM RolloW R-driveUp: 50 s
2013-08-31 20:10:28.531 CUL_HM RolloW R-driveDown: 50 s
2013-08-31 20:10:36.952 CUL_HM RolloW R-self01-lgOnLevel: test %
2013-08-31 20:10:36.952 CUL_HM RolloW R-self01-shActionType: jmpToTarget
2013-08-31 20:10:36.952 CUL_HM RolloW R-self01-lgActionType: jmpToTarget
2013-08-31 20:10:36.952 CUL_HM RolloW R-self01-shOnLevel: test %
2013-08-31 20:10:38.457 CUL_HM RolloW R-self02-lgOnLevel: test %
2013-08-31 20:10:38.457 CUL_HM RolloW R-self02-shActionType: jmpToTarget
2013-08-31 20:10:38.457 CUL_HM RolloW R-self02-lgActionType: jmpToTarget
2013-08-31 20:10:38.457 CUL_HM RolloW R-self02-shOnLevel: test %
Die Readings sind aber immer noch
2013-08-31 20:30:08 PairedTo 0x1743BF
2013-08-31 20:30:08 R-driveDown 50 s
2013-08-31 20:30:08 R-driveTurn 1.2 s
2013-08-31 20:30:08 R-driveUp 50 s
2013-08-31 20:30:08 R-pairCentral 0x1743BF
2013-08-31 20:30:17 R-self01-lgActionType jmpToTarget
2013-08-31 20:30:17 R-self01-lgOnLevel 100 %
2013-08-31 20:30:17 R-self01-shActionType jmpToTarget
2013-08-31 20:30:17 R-self01-shOnLevel 100 %
2013-08-31 20:30:18 R-self02-lgActionType jmpToTarget
2013-08-31 20:30:18 R-self02-lgOnLevel 100 %
2013-08-31 20:30:18 R-self02-shActionType jmpToTarget
2013-08-31 20:30:18 R-self02-shOnLevel 100 %
Genügt diese Info oder brauchst du mehr?
Gruss Martin
> dann muss wohl Martin ran, so ein Beispiel zu konstruieren...
Meiner Ansicht nach nicht, ich glaube ja nicht an einem HM Problem.
Aber wenn Martin eher ein Beispiel bauen kann, dann gerne.
> Ich habe jetzt kein Beispiel zum Testen ohne HW.
Schade, macht meine Arbeit schwieriger. Ich habe kaum HM Komponenten, und die will ich auch nicht unbedingt zum testen verwenden. Wenn es nicht anders geht, dann bitte mit eine Zwischensteckdose und einem CUL.
> attr <name> eventMap 100:testme
Das ist falschrum. Laut diese Definition soll eventMap den String 100 in testme umbauen. betateilchen hatte ein Problem damit, dass die Definition dry:0 aus 0 irrtuemlicherweise dry gemacht hat.
> 2013-08-31 20:10:36 R-self01-lgOnLevel 100 %
...
> 2013-08-31 20:10:36.952 CUL_HM RolloW R-self01-lgOnLevel: test %
Was nun: testme oder test ??? Wenn es oben mit testme ein Vertipper war (wovon ich ausgehe), dann ist das ein Beweis dass eventMap tut.
> Genügt diese Info oder brauchst du mehr?
Dies war ein Beispiel, das zeigt das eventmap funktioniert. Ich haette gerne etwas, was das Problem von betateilchen so demonstriert, dass ich es nachstellen kann.
wenn ich es mir recht überlege: Ich habe dieses Problem an mehreren Stellen meiner fhem-Installation. Allen gemeinsam ist die Tatsache, dass es Homematic Komponenten sind. Bei anderen Typen ist mir das noch nie begegnet.
Konnte mit einem HM-LC-SW1-PL nach Anweisungen von Martin auch nichts reproduzieren.
Allerdings kriege ich auch deutlich weniger Daten per getConfig.
einmal kurzer Abriss, damit ich verstehe wo das Problem liegt:
nach meinen tests
- eventMap ersetzt alle strings in state (if match...)
- eventMap ersetzt alle strings in Trigger events (if match...)
- eventMap ersetzt KEINE strings in Readings
HM nutzt eventMap nicht intern und nutzt die angebotenen Funktionen zum Setzen der Readings/trigger
Was ist das Problem, wie soll es sein/wie nicht?
Gruss Martin
Bei "eventMap dry:0" soll bei keinem Event das 0 in dry konvertiert werden.
Ist bei mir zwar acuh nicht der Fall, aber bei betateilchen findet irgendwann/irgendwo eine "rueckkonvertierung" statt (ReplaceEventMap(*,*,0)), den wir finden sollten (meint betateilchen :)
nun, die Stelle ist einfach:
fhem.pl, line~2500
if(!$noreplace) { # Backward compatibility for code without readingsUpdate
if($attr{$dev}{eventMap}) {
my $c = $hash->{CHANGED};
for(my $i = 0; $i < @{$c}; $i++) {
$c->[$i] = ReplaceEventMap($dev, $c->[$i], 1);
}
$hash->{STATE} = ReplaceEventMap($dev, $hash->{STATE}, 1);
}
}
es werden alle "changes" konvertiert, die Readings nicht.
=> wenn man den trigger weiter verarbeitet könnte es zu diesem Verhalten kommen.
mehr habe ich jetzt nicht
> nun, die Stelle ist einfach:
Das ist nur eine Behauptung ohne Beweise. Wie man es an dem Kommentar sieht, wird es in bestimmten Faellen verwendet. Und ich kann es nicht reparieren, wenn ich nicht weiss, warum bzw. wie HM (oder wer auch immer) sich anders verhaelt, als der Normalfall.
Hallo Rudi,
ZitatDas ist nur eine Behauptung ohne Beweise
????
hast du nicht meinen Beweis vorneweg gesehen? Was willst du noch?
ZitatUnd ich kann es nicht reparieren, wenn ich nicht weiss, warum bzw. wie HM (oder wer auch immer) sich anders verhaelt, als der Normalfall.
kann ich auch nicht sagen
a) was der "Normalfall" ist
b) wie sich HM von einem Normalfall unterschiedet (da ich den Normalfall nicht kenne)
c) mir nicht klar ist, ob ein ersetzen hier stattfinden soll oder nicht.
d) ich erst einmal kein Problem damit habe.
e) HM in diesem Fall die "normalen" reading-update funktionen aufruft
Der Kommentar mutet etwas seltsam
Zitat# Backward compatibility for code without readingsUpdate
zumal in ~3364 der Reading-update funktion
Zitatif($dotrigger && $init_done) {
DoTrigger($name, undef, 0) if(!$readingsUpdateDelayTrigger);
} else {
genau der Code genutzt wird.
Nach dem Code muss es also zu einen replace kommen wenn man readingsUpdate mit option "doTrigger" ruft (ohne trigger auch kein replace im trigger...)
Also noch einmal die Frage: wie ist die "spec" von eventMap? Sollen alle Events nach der Map resetzt werden? Dann ist es doch ok.
Evtl. habe ich das Problem noch nicht erfasst, das ihr zu lösen versucht
Gruss Martin
> d) ich erst einmal kein Problem damit habe.
Ich doch auch nicht. Nur betateilchen behauptet, er haette ein Problem :) :)
Und wir sind nett, und wollen ihm helfen. Bzw. wir wollen keine Bugs in FHEM haben.
> Evtl. habe ich das Problem noch nicht erfasst, das ihr zu lösen versucht
attr device eventMap alt1:neu1 alt2:neu2 ...
-> d.h. in Events von device soll alt1 nach neu1 konvertiert werden. Beim betateilchen wurde aber im Event neu1 nach alt1 konvertiert, also falschrum. Sein eventmap ist dry:0, weil er aus dry ein Zero machen will. Aber keineswegs will er alle Nullen zu dry konvertieren.
Das was du gefunden hast kann sehr wohl die Ursache sein, aber ich brauche diesen Code fuer die Module, die noch kein readingsUpdate verwenden. Ich muesste also ein Problemfall zum nachstellen haben, damit ich eine Loesung fuer alle Seiten finden kann. Es kann aber auch sein, dass diese Stelle gar nicht die Ursache ist.
Zitat von: rudolfkoenig schrieb am Fr, 06 September 2013 14:03Beim betateilchen wurde aber im Event neu1 nach alt1 konvertiert, also falschrum.
Da fehlt eigentlich ein "auch":
Zitatwurde aber im Event auch neu1 nach alt1 konvertiert
Es wird immer und alles in beide Richtungen konvertiert. Und dieses Verhalten ist mir bisher immer nur bei Homematic-Komponenten begegnet, obwohl ich mit eventMap auch bei anderen Komponenten arbeite.
Zitat von: rudolfkoenig schrieb am Fr, 06 September 2013 14:03Sein eventmap ist dry:0, weil er aus dry ein Zero machen will. Aber keineswegs will er alle Nullen zu dry konvertieren.
genau. Endlich versteht mal jemand das Problem :)
nun, das kann ich eben nicht nachstellen.
Habe es mit meinem Rollo probiert
attr RolloW eventMap off:100
set RolloW clear readings
set RolloW getConfig
=> die Readings werden nicht ersetzt
=> die events werden ersetzt, alls off (die Register) nach "100". Geht auch umgekehrt. Aber die Readings bleiben stabil.
Kommt der Fehler bei dich auch in dem Scenario wie oben oder nur bei bestimmten Readings?
Gruss Martin
Du kannst doch schon in meinem eingangs aufgeführten "list" sehen, dass der Fehler dort schon bei zwei Readings auftaucht.
2013-08-08 13:53:38 R-eventFilterTime dry.5
2013-08-25 22:21:20 lastRain 2013-08-rain
Die erste Zeile sollte 0.5 heißen, die Null wurde durch "dry" ersetzt.
In der zweiten Zeile fehlt der korrekte Timestamp weil der Tag "25" durch "rain" ersetzt wurde.
ja,aber es passiert bei mir eben nicht.
Ich habe ein lastRain "dummy" event erzeugt und deine eventMap eingestellt - es kommt trotzdem immer der korrekte Wert.
Wie sieht das Gesamptbild aus?
werden ALLE "0" durch dry ersetzt, wenn die also "single-word" erkannt werden?
werden alle "25" durch rain ersetzt?
wie gesagt, wenn es ein einzel-wort ist, also entsprechend begrenzt mit .,- oder so.
du kannst ja ein paar versuche machen und zeigen, was ersetzt wird, was nicht und wann es ersetzt wird.
Wir gesagt, ich kann in der eventMap einstellen was ich will, bei einem getConfig - auch mit vorherigen clear Readings - wird bislang nie etwas ersetzt. wäre cool, wenn du einen entsprechenden Testfall beschreiben könntest.
Gruss Martin
Zitat von: martinp876 schrieb am Sa, 07 September 2013 08:26wäre cool, wenn du einen entsprechenden Testfall beschreiben könntest.
Ich habe doch den "Testfall" nun wirklich schon x-Mal hier beschrieben. Der "Testfall" ist kein Testfall, sondern ein tatsächlich existierendes Fehlverhalten im Produktivsystem. Was soll ich noch mehr beschreiben? Ich tue NICHTS um das Fehlverhalten herbeizuführen - es ist einfach da.
> Was soll ich noch mehr beschreiben?
Nichts, wir brauchen nur eine Beschreibung, was wir nachstellen koennen, damit wir auch ein Problem haben :) Evtl. kriegst Du eine hin, indem Du deine Produktivkonfiguration nach-und nach abspeckst.
Zitat von: rudolfkoenig schrieb am So, 08 September 2013 08:35indem Du deine Produktivkonfiguration nach-und nach abspeckst.
das ist mir zu unspezifisch...
Zitat von: rudolfkoenig schrieb am So, 08 September 2013 08:35wir brauchen nur eine Beschreibung, was wir nachstellen koennen, damit wir auch ein Problem haben
1. Nimm den genannten Regensensor und binde ihn als HM-Device in fhem ein
2. Definiere die genannte eventMap für den Regensensor und warte
3. Bewundere das Problem
Genau diese drei Schritte sind notwendig. Nicht mehr und nicht weniger.
gut - aber ich habe keinen regensensor - das ist nun einmal mein Problem. Ich versuche support für alle zu leisten, so gut ich kann - aber deshalb werde ich mir nicht alle Devices kaufen, die jemand hat.
Du hast das Problem auch mit anderen Aktoren? - mit welchen? Wo kannst du es noch nachstellen? Wenn ich ein solches Device habe versuche ich es.
Wie (auch schon mehrfach) erwähnt habe ich es mit meinen Devices bisher nicht geschafft, es nachzustellen. Versucht habe ich es schon, erfolglos.
Gruss Martin