Bug Bewegungsmelder BidCosRF vs bewegungsmelder HM-IP

[Black]

Hi Jens, wie per PN schon besprochen:

Typen Bewegungsmelder aussen
1: Sen-MDIR-O-2 (BidCos-RF)
2: HmIP-SMO-A (HM-IP)

beides: bewegunsmelder aussen:

Typ1 verhält sich TimeStamp, LastValue und LastTimeStamp so wie erwartet.
bei einer Änderung von Value wird TimeStamp bzw LastTimeStamp und lastValue entsprechend angepasst. aus den Zeitstempeln lässt sich entnehmen, wann die Änderungen eingetrten sind

TestCode

Code: Alles auswählen

object oID=datapoints.Get ("BidCos-RF.LEQxxxxxx:1.MOTION");  !- Seriennummer da eintragen des BW
WriteLine ("Value:\t" # oID.Value () );
WriteLine ("TimeStamp:\t" # oID.Timestamp () );
WriteLine ("LastValue:\t" # oID.LastValue () );
WriteLine ("LastTimeStamp:\t" # oID.LastTimestamp () );   (

Bei dem IP Bewegungsmelder sieht man, das der Timestamp und lastvalue bei jedem Empfang (anscheinend net auf Änderung sondern auf Aktualisierung) geändert wird.

Sollte ja nicht sein. testcode wäre der gleiche.. einfach nur beobachten und ab und zu programm ausführen

Black

[jmaus]

Danke!

Können das andere hier bereits nachvollziehen? Und bitte mal einen Screenshot eines WebUI Programmes liefern das ich/andere hier in Testumgebungen nutzen können um dem Problem auf dich Schliche zu kommen.

[Black]

ursprungsthreat war dieser

viewtopic.php?f=26&t=11496

ich habe dieses beschriebene verhalten an meinen BMW überprüft und konnte es verifizieren.

drum die Meldung, Black

[Black]

so, Noch ein paar weitere Arten von bewegungsmeldern:

HMIP-SMI

DP Motion

DP ILLUMINATION

Die Sendestempel der Helligkeitsübertragung scheinen hier auch für die Bewegungserkennung benutzt worden sein. Meiner meinung nach ein Fehler

IOBroker, welcher wie die rega auch am RPC hängt, generiert aus den Daten richtige zeitstempel:

Hier ist letzte Änderung 9:08, was ja richtig wäre

------------------

[Black]

bei einem Weiteren BidCos Sender, dem HM-Sen-MDIR-WM55 ist es wiederrum richtig:

Beide Screenschoot binnen einer Minute gemacht. Das schaut für mich so aus, als würden da bei HMIP die zeitstempel nicht korrekt gebildet. und zwar nicht nur über ein gerät

Black

Langsam geht mir nun die Bwegungsmelder gerätevielfalt aus...

[jmaus]

Beide Screenschoot binnen einer Minute gemacht. Das schaut für mich so aus, als würden da bei HMIP die zeitstempel nicht korrekt gebildet. und zwar nicht nur über ein gerät

Also ich durchschaue das noch nicht so ganz. Aber kann es nicht einfach sein das für die Statusänderung der HmIP Geräte eben einfach jedesmal der Status+Timestamp gesetzt wird egal ob der bereits exakt so war? D.h. in den BidCos-RF Geräten sieht man ja das da Value und LastValue immer anders sind und bei den HmIP Geräten die du gezeigt hast sind die immer gleich. Mal angenommen bei HmIP setzt/aktualisiert er eben auch einfach wenn erneut der gleiche Wert kommt. Dann wäre das jetzige Verhalten doch prinzipiell richtig, oder? Weil wer sagt denn das LastValue und Value immer unterschiedlich sein müssen? Das würde bedeuten das eben z.B. das vorletzte "false" des Bewegungsmelders in LastValue() wäre mit entsprechendem LastTimeStamp() und das letzte event das ReGa erhalten hat war eben auch ein false in Value() mit entsprechender TimeStamp(). Oder bringe ich hier etwas durcheinander?!?

EDIT:
Z.B. sieht man das hier sehr gut:

Code: Alles auswählen

WriteLine("HmIP:");
object oID=dom.GetObject(ID_DATAPOINTS).Get("HmIP-RF.XXXXXXXXX:1.MOTION");  !- Seriennummer da eintragen des BW
WriteLine ("Value:\t\t\t" # oID.Value () );
WriteLine ("TimeStamp:\t\t" # oID.Timestamp () );
WriteLine ("LastValue:\t\t" # oID.LastValue () );
WriteLine ("LastTimeStamp:\t" # oID.LastTimestamp () );
WriteLine("BidCos-RF:");
object oID=dom.GetObject(ID_DATAPOINTS).Get("BidCos-RF.XXXXXXXXX:1.MOTION");  !- Seriennummer da eintragen des BW
WriteLine ("Value:\t\t\t" # oID.Value () );
WriteLine ("TimeStamp:\t\t" # oID.Timestamp () );
WriteLine ("LastValue:\t\t" # oID.LastValue () );
WriteLine ("LastTimeStamp:\t" # oID.LastTimestamp () );

Ergebnis:

Code: Alles auswählen

HmIP:
Value:			false
TimeStamp:		2018-12-18 14:40:28
LastValue:		false
LastTimeStamp:	2018-12-18 13:51:36
BidCos-RF:
Value:			false
TimeStamp:		2018-12-18 14:21:30
LastValue:		true
LastTimeStamp:	2018-12-18 14:21:13

D.h. man sieht das hier der BidCos-RF Bewegungsmelder wohl immer Value != LastValue hat, das HmIP Gerät allerdings wohl nicht immer, denn dort ist Value == LastValue, aber mit einer anderen Uhrzeit. Ob das nun per se ein falsches Verhalten ist, hmmmm. Wo steht geschrieben das Value und LastValue immer unterschiedlich sein müssen?

[Black]

hi jens, ich seh das aus meiner erfahrung nicht so...

ansonsten könnte man sich ja den aufwand um lasttimestamp und lastvalue auch sparen. der sollte schon aussagen, wann da eine änderung stattfand. zumal das über die geräteserien ja dann inkonsistent ist. die andere machts so, die andere macht es so.

iobroker generiert auch den richtigen zeitstempel bei IPgeräten. siehe screenshot.

[jmaus]

hi jens, ich seh das aus meiner erfahrung nicht so...

Nun, es geht aber darum ob das ggf. aber beabsichtigt ist. Das kann ich aus der aktuellen Datenlage wenig bis gar nicht einschätzen.

ansonsten könnte man sich ja den aufwand um lasttimestamp und lastvalue auch sparen. der sollte schon aussagen, wann da eine änderung stattfand. zumal das über die geräteserien ja dann inkonsistent ist. die andere machts so, die andere macht es so.

Man könnte auch anders argumentieren: Dadurch das er bei HmIP Geräten wohl immer jedes einkommende Event (egal ob der aktor/sensor bereits diesen wert hat) vermerkt und den vorherigen in LastValue setzt kann man sehe in welchen Sendeabständen der Aktor/Sensor überhaupt eine Aktualisierung schickt. Schaue mal hier und vergleiche die Werte mit meinen vorher geposteten:

Code: Alles auswählen

HmIP:
Value:			false
TimeStamp:		2018-12-18 15:42:53
LastValue:		false
LastTimeStamp:	2018-12-18 14:40:28
BidCos-RF:
Value:			false
TimeStamp:		2018-12-18 15:28:08
LastValue:		true
LastTimeStamp:	2018-12-18 15:27:51

Wie du sieht ist der Zeitpunkt 14:40:28 der vorher auf Value() gesessen hat nun zu LastValue() geworden. D.h. man kann hier sehr schön erkennen das er wohl so 1x in der Std eine Aktualisierung schickt. Und wenn LastValue doch immer nur auf einem Wert sitzen würde der != von Value sein muss, dann müsste der Eintrag doch eigentlich "LastChangedValue" oder so heissen, denn die Bezeichnung "LastValue" stimmt ja eigentlich mit dem überein was er bei HmIP Geräten momentan tut.

Und alleine mit dieser Datenlage tue ich mich wirklich schwer zu bewerten ob es sich hier definitiv um einen Bug handelt. Es sieht zwar wie eine Inkonsistent zwischen BidCos-RF und HmIP Geräten aus, aber wie genau soll man bitte bewerten welche der beiden Methoden nun falsch/richtig ist?!?

iobroker generiert auch den richtigen zeitstempel bei IPgeräten. siehe screenshot.

Wenn ich mich recht erinnere vermerkt hier ioBroker ja die "letzte Änderung" und nicht den "letzten bzw. vorletzten Wert". Schau dir noch einmal dein ioBroker Screenshot an, da steht ja auch "Letzte Änderung" und nicht "Letzter Wert". Kann man zwar so oder so sehen, aber wie gesagt tue ich mich gerade schwer damit zu bewerten welches von beiden nun "richtiger" ist. Man könnte ja auch argumentieren das hier die BidCos-RF Geräte die zwischenzeitlich ankommenden gleichen Werte einfach ignoriert (oder aber vielleicht kommen für die ja zwischendrin gar keine gleichen werte an?).

[Black]

das wollte ich ja damit sagen, dass iobroker die letzte änderung vermerkt... aber genauso machen es ja auch die classic aktoren.

[jmaus]

das wollte ich ja damit sagen, dass iobroker die letzte änderung vermerkt... aber genauso machen es ja auch die classic aktoren.

Das ist mir klar, allerdings ist die Frage ob das die ReGa auch so machen muss/sollte. ioBroker scheint ja explizit nach einer Änderung zu schauen und benennt das ja auch explizit "Änderung". In der ReGa ist das aber anders, da heisst das "LastValue" und die LastValue kann eben (und ich hab noch nicht gesehen das es irgendwo anders definiert ist) gleich der aktuellen Value() sein. Warum auch nicht?