HM Bewegungsmelder bleibt fälschlich auf Motion

Hallo,

nun hat es einen zweiten Bewegungsmelder erwischt, der solange auf Motion hängen bleibt, bis er erneut ausgelöst wird. Diesmal handelt es sich allerdings um einen fertig gekauften Innenmelder (HM-Sec-MDIR), sodass meine Lötkünste als Ursache ausscheiden. :wink:

Weshalb könnten mehrere HM-Bewegungsmelder gelegentlich diese Hänger zeigen? Sie bleiben auch über Stunden mit dem ursprünglichen Zeitstempel auf Motion. Eine erneute Bewegung aktualisiert den Zeitstempel nicht, gibt den BM aber (nach weiteren 240 Sekunden) wieder frei.

Könnte das Problem durch Signalverluste verursacht werden? Ich kann es bislang nicht absichtlich reproduzieren. Batterie-Warnung liegt von keinem Gerät vor. (Ach ja: Der Thread trifft das Problem nicht.)

Grüße
galleto

Das deutet eigentlich darauf hin, dass der BM auf klassische „Wahl des Sendeabstandes“ eingestellt ist.
Wenn du für jede Bewegung die zwischen den 4 Minuten liegen soll eine Aktualisierung willst, dann musst du das über die CCU resp. BidCos-Software (LAN-Adapter) auf dynamisch umstellen (für direkte Verknüpfungen)… Mindestsendeabstand von 15s bis 120s wählbar oder eventuell die Option „Innerhalb des Sendeabstandes erkannte Bewegung senden“ auswählen.

Hilfetext der CCU sagt:

Wahl des Sendeabstandes

Wenn beim Anlegen direkter Verknüpfungen die „Art der Verweildauer“ auf „minimal“ gestellt ist (Standardverhalten), dann wirkt sich die Wahl des Sendeabstandes direkt auf die Mindestverweildauer des Verbrauchers (Aktors) aus.

Es gilt dann folgende Beziehung:

Einstellung klassisch:
Diese Einstellung gibt die Funktion eines klassischen Bewegungsmelders wieder. Der Sendeabstand ist fest auf 240 Sekunden (+ 10% Toleranz) vorgegeben. Dies bedeutet: Der Bewegungsmelder meldet die erste erkannte Bewegung sofort, weitere Bewegungen dann erneut wieder nach einer Zeit von ca. 240 Sekunden. Bei direkten Verknüpfungen z. B. mit einem Funk-Schalter (zum Einschalten der Beleuchtung) hat die Beleuchtung damit automatisch eine Einschaltzeit von min. 5 Minuten. D. h., die Beleuchtung schaltet sich frühestens 5 Minuten nach der erkannten Bewegung wieder aus. Bei ständiger Bewegung wird die Einschaltdauer automatisch immer um 5 Minuten verlängert.

Vorteil: Fest vorbestimmte Einschaltdauer des Verbrauchers und batterieschonender Betrieb des Bewegungsmelders.

Nachteil: Keine kürzeren Einschaltzeiten als 5 Minuten möglich.

Einstellung dynamisch:
Der Sendeabstand passt sich automatisch der im Raum vorhandenen Bewegung an. Der Minimalwert kann vorgegeben werden, wobei kleine Werte zu Lasten der Batterielebensdauer gehen. Der Bewegungsmelder meldet die erste erkannte Bewegung sofort, weitere Bewegungen dann zunächst nach der eingegebenen Minimalzeit (z. B. 30 Sekunden). Bei direkten Verknüpfungen z. B. mit einem Funk-Schalter (zum Einschalten einer Beleuchtung) hat die Beleuchtung damit auch eine Mindesteinschaltzeit von 30 Sekunden. Die Beleuchtung schaltet sich nach 30 Sekunden ab. Bei ständiger Bewegung verlängert der Bewegungsmelder selbstständig schrittweise (dynamisch) seinen Sendeabstand und damit auch gleichzeitig die Einschaltdauer eines direkt veknüpften Verbrauchers auf bis zu 10 Minuten.

Vorteil: Bei Umgebungen mit wenig Bewegung kann die Einschaltdauer direkt verknüpfter Verbraucher klein gehalten werden (energiesparend).

Nachteil: Die Einschaltdauer ist nicht vorhersehbar und kann u. U. bis zu 10 Minuten betragen. Verkürzte Batterielebensdauer des Bewegungsmelder.

Nein, nein, das ist nicht das Problem. Dass er nach dem Auslösen für 240 Sekunden sperrt, ist bei „klassisch“ tatsächlich völlig korrekt. Aber:

Die BM fallen nicht zurück auf „untätig“! Das macht mir Kopfzerbrechen.

Jetzt ist schon Nr. 3 betroffen. Ich tippe stark auf Signalverlust. Wäre das HM-technisch logisch?

Grüße
galleto

… hast du auch schon probiert?
Abwarten bis die geänderte Config an den BM übertragen wurde!

Ähm, ne - inwiefern könnte das im Hinblick auf das Problem hilfreich sein? Ich mag ja eigentlich bei „klassisch“ bleiben. :confused:

Wer ist denn für die Variablen-Umschaltung von „Motion“ zurück auf „untätig“ zuständig? Sendet der BM das „untätig“? Folgender Ablauf wäre dann - rein logisch, nicht unbedingt technisch - eine Erklärung für das Fehlerbild:

  1. BM sendet Motion mit Zeitstempel A (kommt an)
  2. BM sendet „untätig“ mit Zeitstempel B (kommt nicht an)
    #PAUSE#
  3. BM sendet Motion mit Zeitstempel X (kommt nicht an)
  4. BM sendet „untätig“ mit Zeitstempel Y (kommt an)

Merkwürdigerweise gibt es aber keinerlei HM-Fehlermeldungen wie „vorübergehend nicht erreichbar“ o.ä.

Grüße
galleto

Genau das sollte dich stutzig machen.

Einfach mal in eine andere Richtung denken, oder Empfehlungen durch probieren.

Ja!

Brain on! Sonst drehst du dich im Kreis … http://www.ip-symcon.de/forum/threads/19166-Außenbewegungsmelder-viele-nächtliche-Fehlalarme?p=172442#post172442

Och nö, ich mag heute keine Kommunikations-Rätsel mehr lösen. :confused:

Hat es schon, bringt mich aber nicht weiter. Falls Du mir damit etwas spezielles sagen wolltest - ist nicht angekommen.

Okay, ich teste das. Vielleicht kommt etwas hilfreiches dabei raus, auch wenn ich es aktuell nicht verstehe.

Was immer das bedeuten soll. Ich habe das Problem jetzt (auch) bei zwei Innen-Sensoren, die keine Bausätze sind. Warum sollte ich mich hierbei im Kreis drehen? Falls andere Infos fehlen, dann sag das doch einfach.

Bin heute nicht mehr in der Stimmung für sowas…

Grüße
galleto

Kannst du mal einen Screenshot von den Einstellungen eines der BM hier posten?

Bin gerade erst rein, hier die Einstellungen:

Sobald die Kinder im Bett sind, wollte ich mal schauen, ob ich eine Art Logfile für die Zeitstempel konstruieren kann, und dann auch Deinen Vorschlag ausprobieren. Allerdings ist mir seit gestern Abend kein Hänger mehr aufgefallen.

Was mir noch einfällt: Das WLAN hat gestern auch arg gelahmt, sollte aber selbst keinen Einfluss haben. Vielleicht hat etwas insgesamt gestört? Zwei Häuser weiter hat einer den Garten voll mit riesigen Funkantennen. War aber bislang kein Problem. Ach ja - nix CCU, hab nen LAN-Adapter.

Danke für Deine Hilfe! Ich hatte gestern echt einen miserablen Tag… :wink:

Grüße
galleto

EDIT: Hier nun das Skript.

<?

IPSUtils_Include ("IPSLogger.inc.php", "IPSLibrary::app::core::IPSLogger");
define ("c_LogId", "BMtest");
$sender = "BMtest";

$Motion = GetValue(10623  /*[HomeMatic Socket\Bewegungsmelder\IPS\MOTION]*/);
$info = IPS_GetVariable(10623);
$time = ($info['VariableUpdated']);
$zeit = date("H:i:s",$time);

if ($Motion) $ausgabe = "Bewegung ".$zeit;
else $ausgabe = "untätig ".$zeit;
//print_r ($ausgabe);

IPS_LogMessage ($sender, $ausgabe);
IPSLogger_Dbg(c_LogId, "$ausgabe");

?>

Achso… ein Script ist auch noch im Spiel! … hatte ich „irgendwie“ überlesen :rolleyes:
Was macht den einfach nur die Motion-Variable (10623 ?) deiner BM-Instanz ohne Script nach max. 5 Minuten?

Die Einstellungen sind soweit unbedenklich.

Ja, hast Du wohl:

Das Skript existiert erst eine Stunde und logt jetzt lediglich die Variablenänderungen, was man auch hätte erkennen können…

Wollen wir den „zickigen“ Tonfall jetzt bitte lassen? Ich steh da nicht so drauf.

Wenn es gut läuft (wie heute tagsüber/abends), dann macht die Variable was sie soll: sie schaltet bei Bewegung auf „Bewegung“ und nach ca. 4 Minuten zurück auf „untätig“.
Wenn es schlecht läuft (so wie gestern*), dann bleibt sie dauerhaft (auch über Stunden) auf „Bewegung“. Erst bei einer erneuten Bewegung wird dieser Hänger aufgehoben und sie fällt ca. 4 Minuten später wieder auf „untätig“. Bei meinen Tests gestern wurde manchmal diese neue Bewegung gemeldet (= Variable bleibt auf „Bewegung“, der Zeitstempel wird aktualisiert), manchmal wird auch erst das folgende „untätig“ gemeldet. - Das betraf gestern nachmittags und abends drei BM, zwei davon Innen-Melder.

*Während ich hier tippe, hing genau die Varaible 10623 wieder und fiel ca. 20 Minuten lang nicht auf „untätig“ zurück. Erneute Bewegung wurde jetzt aber sofort gemeldet (= Zeitstempel aktualisiert). EDIT: Nach ca. 4 Minuten ist sie nun auch korrekt auf „untätig“ gewechselt.

Meine derzeitige Diagnose: Signalverlust.
Ursache unbekannt.

Grüße
galleto

Das Skript hat auch mit dem eigentlichen Problem nix zu tun :rolleyes:

Hast Du die Teile mal zurückgesetzt und neu angelernt ?

Gruß
Bruno

Soeben versucht. Außerdem hab ich vorher die Einstellung testweise auf „dynamisch“ umstellen wollen. Es zeigt sich immer dasselbe Fehlerbild: Der Ablern-Befehl und auch die neuen Einstellungen können erst übertragen werden, wenn ich den Bidcos-Dienst neu gestartet habe. Dort scheint die Ursache zu liegen!

Wenn ich bei den Bewegungsmeldern manuell den Sabotage-Kontakt drücke/loslasse, dann reagiert zwar der LAN-Adapter (rote LED). Aber in der HM-Konfigurationssoftware wird (manchmal) keine Sabotage-Meldung ausgegeben (müsste aber laut Einstellung). Auch hier: Erst, wenn ich den Bidcos neu gestartet habe, dann funktioniert es korrekt.

Also schmiert der Bidcos aus irgend einem Grund ab, hab ihn mal neu installiert. Einen BM, der besonders „widerporstig“ war, hab ich stromlos gemacht, ebenso den Bausatz. Jetzt schaun wir mal.

Grüße
galleto

Ich glaub, jetzt hat er´s… :smiley:

Die Probleme mit den BM hörten nicht auf. Die vermutete Ursache Bidcos-Service bestätigte sich immer mehr: Anlernen, Ablernen, Konfigurationsänderungen, Sabotagemeldungen - alles funktionierte absolut unzuverlässig, oft gar nicht, manchmal aber schon. Gerade bei den Sabotagemeldungen konnte man schön sehen, dass der LAN-Adapter sie erhält (rote LED), aber im HM-Konfigurator tauchten sie fast nie auf. Auch andere Statusmeldungen waren gar nicht oder falsch vorhanden. Das entsprechende IPS-Skript meldete dagegen alles korrekt. Merkwürdigerweise funktionierten außer den Bewegungsmeldern praktisch alle anderen HM-Komponenten problemlos. :confused:

Na ja, die Suchbegriffe „Bidcos Problem“ führten dazu:

Eins, zwei, Klick - nun stimmen die Statusmeldungen alle wieder und der HM-Konfigurator verhält sich auch sonst normal.

Hintergrund:
Ich hatte das System neu aufgesetzt und nach der Installation von Bidcos und HM-Konfigurator die Einstellungen nur per Kopie übernommen:

Ich hoffe, der Spuk hat jetzt ein Ende. Danke an alle!

Grüße
galleto

Somit hat sich diese Aussage mehr als bestätigt :wink: :smiley:

Gruß
Bruno

Kurze Zwischenmeldung: Leider ist das Grundproblem noch da. Einige „untätig“-Meldungen der Bewegungsmelder kommen nach wie vor nicht an, sodass die BM dann dauerhaft auf „Bewegung“ bleiben, bis sie erneut ausgelöst werden.

Merkwürdig ist, dass

  1. es keine Service-Meldungen hagelt („Kommunikation ist/war gestört“).
  2. die Meldung „Bewegung“ offenbar alle ankommen. *
  3. alle anderen HM-Komponenten zuverlässig funktionieren.

Nr. 1 spricht dafür, dass die BM ihre Bestätigung für jede Meldung bekommen. Sonst kann ich mir keinen Reim darauf machen. Ich suche die Ursache weiter beim Bidcos-Dienst und teste mal Einiges durch…

*Edit: Die Tests zeigen, dass das ein Irrtum war - man kann das Ausbleiben nur etwas schwerer feststellen.

Schon klar, wer den Schaden hat, spottet jeder Beschreibung. :slight_smile:

Grüße
galleto

Hab das heute mal probiert. Soweit ich das beobachten konnte, kommen zuverlässig aller 15 Sekunden neue Zeitstempel an. Manchmal erkennt mich der BM nicht sofort und braucht zwei, drei Sekunden. Aber das ist ja normal. Wenn ich direkt vor ihm winke, dann klappt es sehr pünktlich. (Meine Frau ist gerade kopfschüttelnd vorbei gelaufen… :wink: )

Generell war heute ein besser Tag - jedenfalls bis zu meinen Tests. Es gab davor einen einzigen Aussetzer und das auch erst ca. 19:30 Uhr. Mit genau dem BM hab ich dann angefangen zu testen. Wie gesagt: er sendete dabei zuverlässig. Nach der Rückstellung auf „klassisch“ hat er aber etwas später einmal „Bewegung“ nicht gesendet (war einfach nur für knapp 5 Minuten gesperrt).

Ein anderer BM hing nach den Tests ca. 20 Minuten lang. Er sendete keine „untätig“ mehr, blieb also fälschlich auf „Bewegung“. Eine neue „Bewegung“ nach je 5 Minuten hat er aber immer gesendet.

Die letzten 45 Minuten hab ich den Test-BM wieder auf „dynamisch“ umgestellt und kann keinen einzigen Hänger feststellen, aller 15 Sekunden kommt ein Zeitstempel. Alle anderen BM funktionieren derweil auch.

Gestern betraf der Signalverlust alle drei BM. Gefühlt 50% aller Signale ging verloren. Dabei gab es nicht eine Service-Meldung. Zwei Keymatics, zwei Drehgriffsensoren, zwei Schließerkontakt-Interfaces und drei Tür-Fenster-Kontakte funktionieren problemlos.

Ich bin ziemlich ratlos. Was kann das sein? Wo/wie kann ich noch suchen? :confused:

Grüße
galleto

Langsam kommt Bewegung in die Sache. Zum einen fingen die BM-Hänger heute schon früh an, zum anderen hat nun auch eine Keymatic mehrfach einen Statuswechsel nicht übertragen. Nach wie vor keinerlei Servicemeldung.

Da es sich offenbar verschlimmert, tippe ich auf eine schwächer werdende Batterie als Ursache. Hatte gelesen, dass dadurch Störungen ausgelöst werden können. Ein langsames Sterben des LAN-Adapters oder einer Software-Komponente ist ja eher unwahrscheinlich. Werde heute abend alles bis auf die BM und die Keymatics stromlos machen. Und hoffen!

Falls noch jemand einen anderen Einfall hat - nur her damit!

Grüße
galleto

Ursache im Bidcos-Log gefunden:

23.10.2012 17:05:33 <Debug> Event: IEQ0403xxx:1.MOTION=false
23.10.2012 17:05:33 <Debug> HSSXmlRpcEventDispatcher::Handle send 1 events
23.10.2012 17:05:33 <Error> XmlRpcClient error calling event({[methodName:"event",params:{"IPS","IEQ0403xxx:1","MOTION",false}]}) on http://192.168.178.yy:5544/RPC2:
23.10.2012 17:05:33 <Error> XmlRpc transport error

Das Problem „transport error“ ist im Forum ja schon bekannt, aber offenbar noch keine Lösung.

Wie oben schon geschrieben, hatte ich das System neu aufgesetzt und BidCos V1.506 aus dem Netz direkt installiert. Merkwürdig ist, dass es auf dem alten System monatelang funktionierte. Dort hatte ich vor geraumer Zeit ein Update auf eben diese Version gemacht.

Ich werde jetzt mal die CD rauskramen und die Vorversion installieren. Falls ich hier nicht nochmal etwas schreibe, dann ist das Problem damit gelöst. Hoffentlich!!! :rolleyes:

Grüße
galleto