Bug Bewegungsmelder BidCosRF vs bewegungsmelder HM-IP

[Familienvater]

Moin,

kann es daran liegen, das rfd-Events per BINRPC kommen, und evtl. in anderen Event-Handlern abgefrühstückt werden, als HmIP-Events, die per (nachträglich angedocktem?) XMLRPC kommen?

Oder liegt es am "Versuch" seitens EQ3, Fehler in der Firmware der HmIP-SMO--Bewegungsmelder (die bei entsprechender Konfiguration MOTION nicht auf false zurückstellen), das irgendwie in der Rega geradezuziehen?

Der Familienvater

[jmaus]

kann es daran liegen, das rfd-Events per BINRPC kommen, und evtl. in anderen Event-Handlern abgefrühstückt werden, als HmIP-Events, die per (nachträglich angedocktem?) XMLRPC kommen?

Wie genau meinst du das? Das verstehe ich nicht genau.

Oder liegt es am "Versuch" seitens EQ3, Fehler in der Firmware der HmIP-SMO--Bewegungsmelder (die bei entsprechender Konfiguration MOTION nicht auf false zurückstellen), das irgendwie in der Rega geradezuziehen?

Davon weiss ich persönlich nichts.

[alchy]

Ach da werden >> Erinnerungen << wach.
Ich werf dann auch noch .LastDPActionTime() ins Rennen.

Alchy

[Black]

si, dann kommen wir zu den Channels udn den LastDPAktionTime...

Wie von den vorposten schon beschrieben, verhalten sich diese bei RF und IP konsistent, also gleich, ein verabeitetes Funkpaket findet da berücksichtigung in dem Stempel.
jetzt übertragen die Geräte ja keine einzelnen Punkte sondern glaub ich channels in einem Rutsch. sonst wäre die Einordnung in Kanäle ja auch sinnfrei,

Aus dem grunde müsste dann aber wenn schon die Kanäle in ihrem Last DP Actiontime den zeitpunkt des Funkpaketes beschreiben, dann sollten die Datenpunkte aber den Zeitpunkt der Änderungen beschreiben. das wäre logisch in meinen Augen. Also so wie es RF tut. das Verhalten von IP ist da inkostistent in meinen Augen.

Black

[Familienvater]

Hi,

kann es daran liegen, das rfd-Events per BINRPC kommen, und evtl. in anderen Event-Handlern abgefrühstückt werden, als HmIP-Events, die per (nachträglich angedocktem?) XMLRPC kommen?

Wie genau meinst du das? Das verstehe ich nicht genau.

Naja, die Rega konnte ursprünglich zu CCU1-Zeiten wahrscheinlich nur BINRPC um mit dem rfd und dem hs485d sprechen zu können, nur die Schnittstellen-Prozesse selber sind "bilingual" und können sowohl BINRPC als auch XMLRPC.

Da auf der CCU2 wahrscheinlich zuerst für die Heizgruppen und auch für die Diagramme dann der Hm-Server in Java dazukam, und da weiß ich es gar nicht genau, ob der per BINRPC oder per XMLRPC an die ReGa andockt, auf jeden Fall spricht der "nur" XMLRPC mit dem rfd, muss spätestens dann für die HmIP-Unterstützung XMLRPC Einzug in der Rega gehalten haben, weil die HmIP-Schnittstelle kein BINRPC kann. Deshalb "nachträglich angedockt", und wie das halt mit Erweiterungen nach längerer Zeit und evtl. auch durch andere Programmierer so ist, merkt man das auch als "Nutzer", das eine später dazugekommene Funktionalität sich ein bisschen "anders" verhält, als der ursprüngliche Rest der Software.

Der Familienvater