HmIP-SAM: Bei Eventverzögerung keine Motion Events mehr

[krobipd]

Describe the issue you are experiencing

Wenn ich die Eventverzögerung beim HmIP-SAM einschalte kommt kein Signal mehr an der CCU an.

Describe the behavior you expected

Das Gerät scheint wohl, anhand des grünen aufblinken, zu reagieren aber in der CCU wird keine Erschütterung registriert.
Stelle ich die Eventverzögerung auf "nicht aktiv" funktioniert alles wieder.

auch custom timings funktionieren gar nicht, wenn ich zB 5 Minuten einstelle und nach dem speichern die Einstellungen erneut aufrufe steht dort 500ms und nicht die 5 Minuten.

Steps to reproduce the issue

Eventverzögerung einschalten zB auf 3 Sekunden. - CCU registriert kein Event.
Eventverzögerung auf "nicht aktiv" stellen - CCU registriert wieder Events.

What is the version this bug report is based on?

3.61.7.20211218

Which base platform are you running?

rpi3 (RaspberryPi3)

Which HomeMatic/homematicIP radio module are you using?

RPI-RF-MOD

Anything in the logs that might be useful for us?

-

Additional information

No response

[jens-maus]

Tut mir leid, aber all dies betrifft die Firmware des jeweiligen HomeMatic Gerätes selbst. Diese Firmware ist selbst nicht open source und darauf hat RaspberryMatic als OSS Projekt auch kein Einfluss. Bitte bei etwaigen Probleme die in der Gerätefirmware liegt direkt an den Hersteller (eQ3) wenden.

[Baxxy13]

Das Problem tauchte ja schon im letzten Sommer im Homematic-Forum auf: EventDelay bei HmIP-SAM ?
Ich hatte dazu dann noch bei CCUx Usern um Hilfe gebeten:
Kurze Mithilfe von CCUx 3.57.5 (sowie Derivate) Nutzer mit HmIP-SAM gesucht

Die Beteiligung war eher mau und das Resultat... naja nicht eindeutig.

Somit lässt sich ein Fehler in der Gerätefirmware also erstmal nicht komplett ausschließen.
Aber auch ein Fehler in RaspberryMatic bzw. OCCU kann m.E. nicht ausgeschlossen werden (ProofAndSetValue ?) .

@jens-maus : wenn du den HmIP-SAM noch in Benutzung hast kannst du das doch mal testen.

[jens-maus]

@jens-maus : wenn du den HmIP-SAM noch in Benutzung hast kannst du das doch mal testen.

Das war natürlich ein guter Hinweis. :) Hab es nun mal mit meinem eigenen HmIP-SAM versucht zu reproduzieren und in der Tat kann ich das. Siehe hier mal ein Screenshot des Protokolles:

Bis 12:00:28 Uhr sieht man da die Versuche dem SAM ein Bewegungsevent zu entlocken mit aktivierter Eventverzögerung (hier 500ms). Was man wahrnimmt ist, das im Protokoll Events für jede Bewegung/Erschütterung ankommen. Allerdings wird da immer dann "keine Bewegung/waagerecht" in meinem Fall geloggt. D.h. der SAM liefert immer (vmtl. durch die Eventverzögerung) einen falschen Status aus.

Um 12:00:29 habe ich dann die Konfig wieder ohne Eventverzögerung aktiviert und siehe da, darauffolgend sieht man wieder für die gleiche Art der Bewegungen/Erschütterungen, das der SAM hier wieder ein Event ausliefert wo auch der Status entsprechend geändert ist (d.h. nicht nur "keine Bewegung/waagerecht").

Für mich sieht es aktuell in der Tat nach einem Gerätefirmware-Problem aus das nur eQ3 beheben kann. Hier scheint in Kombination mit einer aktivierten Eventverzögerung die Firmware in der Auslieferung der Stati durcheinander zu kommen und folglich bekommt die CCU immer nur den gleichen Status zurückgeliefert. Aber ein Event kommt definitiv vom SAM and die CCU an, was aus aus dem Protokoll ersichtlich wird.

Im ioBroker kann ich im übrigen das selbe Verhalten feststellen. Sobald die Eventverzögerung aktiviert ist (egal welcher Wert) kommen zwar für jede Bewegung aktualsierte Maintenance :0 Daten ab, aber "Motion" Datenpunkt bleibt immer auf false.

Brauchen wir hier also langsam mal eine DeviceFirmware Kategorie um dieses upstream-Issue entsprechend zuzuordnen.

[Baxxy13]

Interessant.
Hast du mal an der WebUI vorbei (getParamset) geprüft ob die Parameter für das Delay korrekt im Sensor landen?
Sollte ja für die 500ms...

EVENT_DELAY_UNIT = 0 (100ms)
EVENT_DELAY_VALUE = 5

Nicht das wir hier 2 Probleme haben.

langsam mal eine DeviceFirmware Kategorie

Oh je, da fallen mir gleich mehrere IP-Geräte ein die mehr oder weniger relevante Bugs haben.

[jens-maus]

Interessant. Hast du mal an der WebUI vorbei (getParamset) geprüft ob die Parameter für das Delay korrekt im Sensor landen? Sollte ja für die 500ms...

EVENT_DELAY_UNIT = 0 (100ms)
EVENT_DELAY_VALUE = 5

Nein. Wenn du mir ein kurzes ReGa-Skript dafür basteln würdest könnte ich das nochmal kurz testen in der Tat. Hab sowas hier gerade nicht parat (leider).

Nicht das wir hier 2 Probleme haben.

Das kann natürlich gut sein, ja. Aber das es das Problem hier dann auslöst glaube ich immer noch nicht.

langsam mal eine DeviceFirmware Kategorie

Oh je, da fallen mir gleich mehrere IP-Geräte ein die mehr oder weniger relevante Bugs haben.

Dann kannst du die alle hier gerne reinballern und wir flaggen die entsprechend damit eQ3 da auch geordnet drüberschauen kann oder so.

[Baxxy13]

object if = dom.GetObject("HmIP-RF");
var v = xmlrpc.GetParamset(if,"000F18A98Cxxxx:1","MASTER");
WriteLine(v);

Sollte die gespeicherten Werte ausgeben.

[krobipd]

Tut mir leid, aber all dies betrifft die Firmware des jeweiligen HomeMatic Gerätes selbst. Diese Firmware ist selbst nicht open source und darauf hat RaspberryMatic als OSS Projekt auch kein Einfluss. Bitte bei etwaigen Probleme die in der Gerätefirmware liegt direkt an den Hersteller (eQ3) wenden.

zuerst mal tausend dank für deine Arbeit und Bemühungen. aber ich denke derwegen das es besser ist wenn du oder ähnliche sowas an eQ-3 leiten den als normaler Benutzer bekommt man nur diese Antwort.

Einen Support für die Verhaltensweise von Geräten an Communitylösungen, wie z.B. Raspberrymatic, DebMatic o.ä., bieten wir im Rahmen unseres Kundenservice nicht an. Daher können wir Ihnen zu Ihrer Anfrage keine Unterstützung anbieten.

[jens-maus]

@Baxxy13

Sollte die gespeicherten Werte ausgeben.

Danke. Das hat geholfen. Hier scheint es also in der Tat ein Problem bzgl. des Setzen der Werte der Eventverzögerung beim HmIP-SAM via WebUI zu geben. Folgende Ausgaben bekomme ich nämlich für die verschiedenen Units:

500ms:
<member><name>EVENT_DELAY_UNIT</name><value><i4>0</i4></value></member><member><name>EVENT_DELAY_VALUE</name><value><i4>5</i4></value></member>

30s:
<member><name>EVENT_DELAY_UNIT</name><value><i4>0</i4></value></member><member><name>EVENT_DELAY_VALUE</name><value><i4>30</i4></value></member>

15min:
<member><name>EVENT_DELAY_UNIT</name><value><i4>0</i4></value></member><member><name>EVENT_DELAY_VALUE</name><value><i4>15</i4></value></member>

1h:
<member><name>EVENT_DELAY_UNIT</name><value><i4>0</i4></value></member><member><name>EVENT_DELAY_VALUE</name><value><i4>1</i4></value></member>

Wie man unschwer sehen kann wird EVENT_DELAY_UNIT wohl gar nicht gesetzt bzw. nicht an das Gerät übertragen. Die Frage wäre also ist das generell bei allen Geräten so die EVENT_DELAY_UNIT usw. haben oder nur beim HmIP-SAM in der WebUI? Welche anderen Gerätetypen unterstützen auch noch dieses EventDelay damit man das mal mit den anderen auch noch testen kann?

[jens-maus]

Welche anderen Gerätetypen unterstützen auch noch dieses EventDelay damit man das mal mit den anderen auch noch testen kann?

Hab das gerade mal mit einem HmIP-PSM getestet und dort geht das einstellen der Eventverzögerung problemlos und die WebUI zeigt danach auch den richtigen wert an. Wäre also die Frage inwieweit das nur ein Problem im HmIP-SAM ist. Hab nun einmal "hart" das MASTER Paramset mit folgendem Skript umgesetzt:

object if = dom.GetObject("HmIP-RF");
xmlrpc.PutParamset(if, "000XXXXXXXXF4:1", "MASTER", "EVENT_DELAY_UNIT", "1"); ! Sekunden
xmlrpc.PutParamset(if, "000XXXXXXXXF4:1", "MASTER", "EVENT_DELAY_VALUE", "3"); ! Wert
WriteLine(xmlrpc.GetParamset(if, "000XXXXXXXXF4:1", "MASTER"));

Und siehe da, nun zeigt die WebUI zumindest das Richtige an. Allerdings wird trotz nun richtiger gesetzter Eventverzögerung immer noch nicht korrekt das Event an die CCU gesendet und es wird immer keinerlei Bewegung mitgeteilt sondern immer nur "keine Bewegung". Die Vermutung von @Baxxy13 scheint also richtig zu sein, das dies zwei getrennte Probleme sind:

1. Bei aktivierter Eventverzögerung wird immer nur "keine Bewegung" als Event mitgeteilt
2. über die WebUI lässt sich für den HmIP-SAM die Eventverzögerung nicht richtig setzen, das geht momentan nur via Skripting.

Problem 2 können wir sicherlich über einen WebUI Patch innerhalb von RaspberryMatic reparieren. Das Problem 1 (Einstellen der Eventverzögerung geht Bewegungs/Erschütterungsmeldung lahm) muss definitiv ein Ticket/Issue eQ3 gemeldet werden. Dazu würde ich jedoch jemanden mit einer CCU3 Firmware bitten das entsprechend eQ3 zu melden nachdem man es damit versucht hat zu reproduzieren.

@krobipd Ich sehe uns hier aus diesem Projekt nicht direkt das an eQ3 zu melden und können bzgl. dieser Gerätefirmwareprobleme nicht direkt auf eQ3 stellvertretend zugehen. Das muss schon ein Endnutzer machen und eben nachdem er das mit einer reinen CCU3+CCU3 Firmware nachgespielt hat.

[jp112sdl]

Hab das gerade mal mit einem HmIP-PSM getestet und dort geht das einstellen der Eventverzögerung problemlos

Der PSM verwendet für EVENT_DELAY_UNIT nicht den parameter subtype cts.

PSM:
<parameter>EVENT_DELAY_UNIT</parameter>

SAM:
<parameter subtype="cts">EVENT_DELAY_UNIT</parameter>

Daher wäre die Gegenprobe sinnvoll mit Geräten, die auch den Subtyp cts verwenden.
Funktioniert das Setzen von EVENT_DELAY_UNIT beim HmIP-SWDO / SWDI / SWDM?
Funktioniert das Setzen beim HmIP-STV (der wäre auch vom Kanaltyp ACCELERATION_TRANSCEIVER) ?

[Baxxy13]

Den SWDM habe ich gerade beim Wickel, der nimmt die Parameter ohne Probleme.

[jp112sdl]

Okay, dann ist schon mal nicht die gesamte Parameter-Gruppe innerhalb des HMIPServer "defekt".

STV wäre wirklich noch interessant. Für den SAM gibt es in der WebUI noch an 2 Stellen eine Sonderbehandlung (zwar unabhängig vom EVENT_DELAY_UNIT aber man weiß ja nie)

[Baxxy13]

Habe mal den Hilfegesuch aufgefrischt und den HmIP-STV mit aufgenommen.
Mal schauen.

[jens-maus]

So, das Problem in der WebUI das man für den HmIP-SAM die Eventverzögerung nicht richtig setzen konnte bzw. da immer nur sekunden-basierte Werte gesetzt wurden (weil eben EVENT_DELAY_UNIT nicht gesetzt wurde) habe ich nun beseitigt wie man in c126205 unschwer sehen kann. Das war in der Tat ein Bug in der WebUI. Es hat aber wie gesagt nichts mit diesem Problem hier (das bei gesetztem EVENT_DELAY_VALUE keine Motion events mehr ankommen) zu tun. Denn hier ist immer noch meine Vermutung das das ein Firmware-Bug des HmIP-SAM ist.

[Baxxy13]

habe ich nun beseitigt

Super, 50% des Problems abgehakt.
Für den Rest müssen wir erstmal auf Feedback von CCU Usern warten.

[jp112sdl]

Ich hab schon wieder zu komplex gedacht. 🤯
Dass eQ-3 einfach nur vergessen hat, den Paramcounter zu erhöhen, damit habe ich nicht gerechnet eigentlich rechnen müssen.

[stale]

Thanks for your contribution!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of RaspberryMatic and tell us. Also check that all relevant details,

---

Vielen Dank für die Unterstützung!
Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüfen Sie, ob das Problem auch in der aktuellsten Version von RaspberryMatic noch relevant ist, und teilen Sie uns dies mit. Überprüfen Sie auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind oder aktualisiert werden müssen.

[stale]

This issue has been automatically closed because of inactivity. Please open a new issue if still relevant and make sure to include all relevant details, logs and reproduction steps.

---

Dieses Problem wurde aufgrund von Inaktivität automatisch geschlossen. Bitte öffnen Sie ein neues Issue, falls dies noch relevant ist und stellen Sie sicher das alle relevanten Details, Logs und Reproduktionsschritte enthalten sind.