HMIP-SMI - Fehlermeldungen im Protokoll ... ?

[g55]

Hallo Leute,
Ich bräuchte mal Euer Feedback zu meinen Problem(chen) mit dem Bewegungsmelder.
Mein Scenario:

• hab so 6 Stück installiert
• die schalten per DV das Licht (Treppenhaus) für eine bestimmte Zeit
• jetzt will ich für Nachtruhe einige auschalten ... geht per Programm ... "Bewegungsmelder nicht aktiv"
• wenn die Dinger jedoch ausgeschaltet sind = Bewegungserkennung aus, senden die wohl gar nix mehr nach (weis nich) Minuten ...
• nach gefühlten 1-4 Stunden kommt dann die Servicemeldung "Kommunikation gestört" ...
• wenn ich die SMI dann per Programm wieder einschalte = "Bewegungsmelder aktiv", geht auch das Licht per DV an ... obwohl keine Bewegung ???
• wenn ich den Test-SMI mal eben ein-ausschalte, geht das per DV verbundene Licht NICHT an ... wohl ne Frage der Zeit ...

und dann noch die Zeitverzögerung, wenn ich per WebUI die Erkennung ein-/ausschalten will ... das dauert ...
btw, im Protokoll hab ich ich meist folgende Meldungen :

Code: Alles auswählen

Aug 27 20:08:33 HomeBox21 local0.err ReGaHss: ERROR: ScriptRuntimeError: integer devId = 7355;string action= 'setVisible';integer iVis = 1; [ExecError():iseESPexec.cpp:12798]
Aug 27 20:08:33 HomeBox21 local0.err ReGaHss: ERROR: foreach(): invalid expression used [ExecForEach():iseESPexec.cpp:515]
Aug 27 20:05:49 HomeBox21 user.debug hm_deldev: event fired (delete 00091BE99D55DF)
Aug 27 20:01:47 HomeBox21 local0.err ReGaHss: ERROR: rpc.CallSetValue failed; address = 00091BE99D55DF:1 [WriteValue():iseDOMdpHSS.cpp:76]
Aug 27 20:01:47 HomeBox21 local0.err ReGaHss: ERROR: XMLRPC 'setValue' call failed (interface: 1011, params: {"00091BE99D55DF:1","RESET_MOTION",true}) [CallSetValue():iseXmlRpc.cpp:1505]
Aug 27 20:01:47 HomeBox21 local0.warn ReGaHss: WARNING: XMLRPC 'setValue': rpcClient.isFault() failed (url: xmlrpc://127.0.0.1:32010, params: {"00091BE99D55DF:1","RESET_MOTION",true}, result: [faultCode:-1,faultString:"Generic error (TIMEOUT)"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]
Aug 27 19:59:34 HomeBox21 local0.err ReGaHss: ERROR: rpc.CallSetValue failed; address = 00091BE998F0D6:1 [WriteValue():iseDOMdpHSS.cpp:76]
Aug 27 19:59:34 HomeBox21 local0.err ReGaHss: ERROR: XMLRPC 'setValue' call failed (interface: 1011, params: {"00091BE998F0D6:1","MOTION_DETECTION_ACTIVE",true}) [CallSetValue():iseXmlRpc.cpp:1505]
Aug 27 19:59:34 HomeBox21 local0.warn ReGaHss: WARNING: XMLRPC 'setValue': rpcClient.isFault() failed (url: xmlrpc://127.0.0.1:32010, params: {"00091BE998F0D6:1","MOTION_DETECTION_ACTIVE",true}, result: [faultCode:-1,faultString:"Generic error"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]]

hmm, irgendwie hab ich den Eindruck, hier is was faul ... either in Firmware ... or in CCU-SW/WebUI.

kann jemand das evtl. nachvollziehen, bestätigen oder so, bzw. hat jemand noch ein paar Tipps für mich bez. SMI-Einstellungen/Programme?
die Forensuche die letzten 30 min. hat mich da auch nich weitergebracht, oder hab ich was übersehen ?

vielen Dank.

[Xel66]

• wenn die Dinger jedoch ausgeschaltet sind = Bewegungserkennung aus, senden die wohl gar nix mehr nach (weis nich) Minuten ...
• nach gefühlten 1-4 Stunden kommt dann die Servicemeldung "Kommunikation gestört" ...

Ja, das Verhalten ist bekannt, wurde schon öfter diskutiert und könnte als Bug gewertet werden. Diesen Fehler kann aber nur der Hersteller beheben. Daher wäre eine Fehlermeldung an diesen zielführend.

und dann noch die Zeitverzögerung, wenn ich per WebUI die Erkennung ein-/ausschalten will ... das dauert ...

Ja, es dauert. Einen Meldezyklus des BWM. Als Batteriesensor ist er aus Batteriespargründen nicht ständig auf Empfang, sondern lauscht nur kurz nach seiner zyklischen Statusmeldung, ob die CCU ihm etwas mitteilen möchte und legt sich dann wieder schlafen. Auch an diesem Verhalten kann man ohne Nebenwirkungen (erhöhter Batteriebedarf) nicht viel ändern.

Ich würde über einen weiteren UND-verknüpften virtuellen Kanal die Aktoren ausschalten, die nachts nicht einschalten sollen. Somit könnte der BWM in Betrieb bleiben und Du wärst frei von diesbezüglichen Nebenwirkungen. Damit man dann noch manuell am Lichttaster bei Bedarf das Licht einschalten kann, musst Du noch DVs für diesen Kanal zu den Gerätetastern ergänzen.

Gruß Xel66

[g55]

vielen Dank für Deine Rückmeldung

• ja, das Verhalten ist mir im Prinzip auch bekannt, k.A., was sich eq-3 dabei gedacht hat, erschließt sich mir irgendwie nicht
  aber ok, is halt so.
  btw. hat schon jemand eine Supportanfrage bei eq-3 diesbezüglich gestellt ? ... hab hier per Forumssuche noch nix gefunden ...
• Zeitverzögerung : klar, ist Batterie = meist "Wake-on_burst" = muss durch mehrere Funksignale aufgeweckt werden
  Andere Batterie-Sensoren reagieren jedoch bei mir deutlich schneller ... eTRV, WTH, B(W)RCx...
• Virtueller Kanal : danke für den Tipp bin ich jetzt noch nicht selbst drauf gekommen ... 2Btested ... evtl morgen, wenn es regnet
• apropos SMI in Betrieb lassen : Hatte ich mit den ersten 4 SMIs anfangs so eingerichtet ...bei DVs die Helligkeit eingestellt, ab der der Aktor geschaltet werden sollte... funktioniert nachts und auch tagsüber, Licht wird eben nicht eingeschaltet ... jedoch erhöhte es den DC bei Anwesenheit = Bewegung um ca 10-20%. Daher will ich unbedingt die Erkennung der SMIs ausschalten, wenn ich die Erkennung nicht eben brauche, z.B. bei Nachtruhe.

noch kein Feedback sehe ich hier zu meinen Fragen bez.:

• SMI-Erkennung einschalten nach längerer Zeit aus = Licht an bei aktiver DV ? ... wer kann das nachvollziehen ?
• Fehlermeldungen im Protokoll : wer kann das nachvollziehen / hat die auch beim ein-ausschalten der Erkennung per WebUI oder script ?

wie gesagt, ich würde mich über jeden Tipp freuen. Wenn noch Infos nötig sind, liefere ich diese gerne.
VG

[Xel66]

... k.A., was sich eq-3 dabei gedacht hat, erschließt sich mir irgendwie nicht

Ich vermute mal, die haben sich gar nichts dabei gedacht, sondern es ist einfach ein Programmierfehler, der nicht erkannt wurde, weil nicht ausgiebig genug getestet. Ich wüsste nicht, dass jemand aus dem Forum diesen Bug gemeldet hat.

Andere Batterie-Sensoren reagieren jedoch bei mir deutlich schneller ... eTRV, WTH, B(W)RCx...

Bei diesen kann wake on radio aktiviert werden, was auch zielführend und notwendig für eine schnelle Reaktion auf Sollwertänderungen oder Fensteröffnungen ist. BWMs müssen aber im Normalfall auf keinerlei externe Geräte reagieren, weil sie eben im Normalfall Sensoren sind und selbst nur erkannte Bewegung etc. an verknüpfte Geräte oder CCU senden.

Daher will ich unbedingt die Erkennung der SMIs ausschalten, wenn ich die Erkennung nicht eben brauche, z.B. bei Nachtruhe.

Bei Nachtruhe läuft auch niemand durch die Gegend und könnte so durch kurze Erkennungsintervalle den DC hochtreiben. Bleiben nur die zyklischen Meldungen. Du versucht m.E. das Pferd von hinten aufzuräumen. Das Abschalten der Bewegungserkennung ist mit zu vielen Nachteilen verbunden und deshalb nicht zielführend.

...einschalten nach längerer Zeit aus = Licht an bei aktiver DV ? ... wer kann das nachvollziehen ?

Ich habe es nicht nachvollzogen, weil ich keine Verknüpfungspartener habe. Allerdings kann ich mir durchaus vorstellen, dass die Ursache ebenfalls in der Firmware zu suchen ist und eben ein "Bewegung erkannt" gesendet wird.

wie gesagt, ich würde mich über jeden Tipp freuen.

Du kannst das bekannte Verhalten nicht ändern, insofern wird es wenig wirklich hilfreiche Tipps (außer alternative Lösungsansätze) geben.

Gruß Xel66

[nimmnenkeks]

naja, klingt wie immer:
Leere in Leer....

Die ganzen von g55 angesprochenen Verhltensweisen der Dinger sind Leer schon über 12 Monde bekannt und es passier wie immer... NIX

Egal, man musssich derweil "wie immer" selbst helfen da die Gurkentruppe es eh nicht ändert.
Bin daher dabei die SMI'sdurch SMI55 mit Netzteilen zuersetzen, da diese im Netzbetrieb oft ihre Stati übermitteln können, wie es in entsprechenden Szenarien benögt wird.
Dann kommen die SMI's ggf. nur noch für Nachtlichtszenarien/Nachtauslösungen zum Einsatz (tagsüber, oder Überrangsteuerung auf AUS/deaktiviert).

Abhilfe bei Auslösung der SMI's bringt eine SysVar die über ein Programm (nicht verknüft) den Status beinhaltet.
Gaaaanz wichtig, vor der Deaktivierung der Bewegungserkennung im Programm verzögert (2-3sec) ein Resetbefehl mit durchführen.
Dann:
Gerät: BWM -> Reset (verzögert um 3sec)
Gerät: BWM -> Bewegungserkennung deaktiviert (sofort)
Dann ist die Sysvar "BEWEGUNG" auch auf "Bewegungserkennung deaktiviert), welche in den Programmen von mir weiter genutzt wird.
Da ich auch eine SysVar für die Helligkeit der Dinger nutze (alles über ein Programm mit Skript) wird diese dann auch noch aktualisiert.
Hat sich so eingebürgert, da es "früher" keinen SDV gab, der vernüpfte SysVars reparieren konnte und das Arbeiten mit den Dingern nur über Patch/Raspel möglich war.
So kann man in ui auchmitechten und nicht auf-/abgerundeten Helligkeitswerten arbeiten.

Die Fehlermeldungen kann das Leer uch nicht abschalten....nicht das es dort nicht bekannt wäre.
Damit muss man bei den SMI's leider leben.


Die SMI55 können bei entsprechenden Settings in Geräteeigenschaften auch in den zyklischen Statiübermittlungen dazu gebracht werden, annähernd die richtige Helligkeit zu übermitteln (s.o. nur im Netzbetrieb)

BG .Keks

[g55]

Hallo @nimmnenkeks,
besten Dank .
na ja, es wundert mich jetzt nicht, dass sich beim SMI nix ändert ... die firmware ist "stoneOld" : Version 1.4.8 - 20180219 ... und nachwievor "aktuell"
Ich bin es ja gewohnt, mir selbst zu helfen ... der SDV hilft mir da auch sehr ... mal hier noch OT ein kurzes, intensives DANKE an @Black.

Ich verstehe Dich jedoch nicht so ganz :

• wozu der RESET ? was bewirkt der eigentlich und dann noch NACH der Deaktivierung ?
  ich weis inzwischen, dass der SMI nach deaktivierung noch eine gewisse Zeit reagiert, bevor der sich schlafen legt, ich denke so 5-20 min, evtl abhängig von den cyclic Einstellungen Oder ist das evtl. nur ein "Sicherheitsfaktor", damit der SMI "sauber schlafen geht" ?
• apropos Helligkeit ... es gibt beim SMI 2 DPs, ILLUMINATION und CURRENT_ILLUMINATION... wenn ich mir im SDV den Timestamp ansehe, sind diese DPs wohl vertauscht. Sehe ich auch in Programmen bei "wenn" bez. "Helligkeit" und "Ungefilterte...Helligkeit". auch im CCU-Historian werd ich nicht schlau aus den Werten ...
• mal ne Frage : wie hast du die zyklischen Statusmeldungen beim SMI eingestellt ? Default ist ja wohl "ein/1/20" ... ich hab schon experimentiert mit z.B. aus, "ein/20/0" oder "ein/2/12", des bringt alles nix in Bezug auf DC und/oder Aktualisierung der Helligkeit.

BTW: im SDV mit entprechenden ParamSets/LinkSets rumgespielt ...

• die in der DV eingestellte Helligkeitsgrenze is in den Expertenparametern unter SHORT_COND_VALUE_LO gespeichert ... könnte man auch per script auf 0 setzen, dann ist die Bewegungserkennung auch wohl deaktiviert für diese DV, d.h. Licht geht nicht mehr an ... hab mir überlegt, das nach dem Deaktivieren der Erkennung einzubauen mit Speichern des Wertes in SV und bein Aktivieren der Erkennung wieder zurückzusetzen ... nee, was nen Aufwand
• es gibt im Paramset des SMI Kanal 1 noch nen "PIR_OPERATION_MODE" ... der hat 0:normal, 1:eco, 2:off ... im WebUI wird die "2" gar nicht angeboten ... kurz getestet, setzen auf 2 ... ja, ist das gleiche wie "Erkennung aus" im WebUI ode DP "MOTION_DETECTION_ACTIVE" auf "false". --> Bringt mMn.auch nix.

Ich denke, ich werde auch mal ne Supportanfrage an ELV/eq-3 stellen ...verstehen / nachvollziehen kann ich das Verhalten des SMI nicht, zumal der Aufbau sehr ähnlich den Sonnen-/Temperatur-Sensor ist (SLO/STHO). Gleiches Gehäuse, gleiche CPU, nur andere Sensoren ... ok Bewegungsmelder ist evtl. etwas anderes ... wo liegt der Unterschied ?
Ich kann mir durchaus vorstellen, dass ein SMI auch bei deaktiviertem Bewegungsmelder munter per cyclic messages seine Status wie ILLUMINATION funken könnte ...

aber ok... LEER ... die haben sich wohl irgendwas dabei gedacht, was sich mir so nicht so ganz erschließt ... und ich bekomme die Dinger aber trotzdem zum Laufen nach meinen Kriterien
VG

[nimmnenkeks]

Servus,
und nur gaaanz kurz... Teigvorbereitungen Brot(e), Brötchen mit unterschiedlichen Teigführungen, Pizzen (Dehnen ,Falten......) damit man für die Woche durch ist

Den Reset mache ich, da ich mit SysVars arbeite und Diese dann auch durch BWM auf "keine Bewegung" stehen!
Da die Dinger ja zyklische Statusmeldungen versenden und damit auch die Helligkeit übertragen wird, ist das fast immer der falsche Wert.
Denn die SMI's senden in nicht (oder per Expertenparameter einstellbar, jedoch wegen Batteriehaltbarkeit nicht nutzbar, die Helligkeit bei den zyklischen Statusübermittlungen mit. Da das Luder aber einen nicht abstellbaren Messwertintervall hat (min 6 Minuten) kommt da nur Müll raus.
Die Antwort aus der Leere "dafür ist das Gerät nicht gedacht, nehmen Sie einen SLO.... janeee, is klar (man pflastert sich zusätzlich noch jeweils nen SLO in die Räume.....). Klar, die wollen Harware verdengeln
Daher stelle ich ja auch auf SMI55 mit Netzteil um, nen paar HAP's dabei und die können ruhig jede Minute ihre Werte übertragen.

Das lässt sich prima mit Blacks SDV nachvollziehen.

Leider ist Sammy ja seit geraumer Zeit inaktiv um mal Licht in die Dinger zu bringen.
Es gibt einen älteren Fred 2017/2018 bzgl. SMI und Expertenparmeter, damit die Auflösung entsprechen fixer ist (jedoch hielt damit eine neuer Batt.-Satz ca. nen Monat, oder so.

SMI55 stehen bei mir auf
Anzahl der auszulassenden Statusmeldungen: 0
Anzahl der auszulassenden, unveränderten Statusmeldungen: 1

SMI sind auf Standard 1/20 bis sie raus fliegen, oder andere Verwendung bekommen.
Praktisch sind sie ja, um z.B. die Platzierung für die weiteren SMI55 zu finden (man will ja wissen, welche Richtung eingeschlagen worden ist, bzw. in welche Richtung man sich bewegt)

CURRENT_ILLUMINATION ist für mich auch nix nutzbares (genauso wie ungefilterte Helligkeit), womit man tatsächlich bzgl. der Helligkeit arbeiten kann.
Man benötigt ja bei der "Auflösung der Dinger im unteren, bis mittleren Bereich ja zwingend die Nachkommastellen, damit bei der Beleuchtung was brauchbares zu machen ist.
DP MOTION_DETECTION_ACTIVE ist Aktivierung/Deaktivierung der Bewegungserkennung
DP PIR_OPERATION_MODE ist nur für Normal/ECO Modus.
Was sich das Leer bei dem Lastenheft für die Firmware gedacht hat.... man wird es nie erfahren.

BG .Keks

[g55]

Hallo Ihr Lieben,
danke für die Rückmeldungen, ich hab die SMI-"Luder" noch weiter getestet ... man, man, man, was für'n Krampf:

1. SMI aktiv gelassen ...
   • ok, dann senden die munter ihre Bewegungsmeldungen tagsüber (btw. wir sind ein 2-Personen-Haushalt ), auch wenn durch die DVs per Helligkeit kein Licht geschaltet wird
   • Fürs Licht soweit ok...
   • Ergebnis ist jedoch ein DC im Bereich 40-50%
   • also für mich eigentlich unbrauchbar
2. Virtuelle Kanäle
   • danke an @Xel66 für den Tipp
   • ich hab mal beim BSL/BSM Kanal 4 für den SMI reserviert, da geht die DV drauf, Dann Kanal 5 per AND verknüpft (der ist für SMI aktiv=100 / inaktiv=0) , Kanal 6 wieder per OR, und die Tasten des Schalters per DV zusätzlich auf Kanal 6 gelegt (Kanal 4 is eh schon drin)
   • somit kann ich per Kanal 5 den SMI quasi (de-)aktivieren, jedoch per Taste am Schalter (oder Programm/DV) das ganze per Kanal 6/4 übersteuern
   • also schon mal nen Erfolg
3. RESET ...
   • Besten Dank @ Keks ... erschließt sich mir noch nicht ganz, da ich nicht mit SVs für Erkennung / Helligkeit der SMIs arbeite
   • ich überlege grad, ob ich in nicht evtl. den SMI ausschalte, wenn grad Erkennung aktiv ist ... kann theoretisch ja passieren ...2Btested
   • ich behalte es mal im Hinterkopf ... vielleicht brauch ich es ja doch irgendwann
4. HMIP-SMI55 ... keine Alternative für mich
   • den SMi 55 hatte ich schon getestet und wieder zurück geschickt
   • der passt nicht zu meinem Schalterprogramm
   • und ist mir zu globig= unförmig = WAF = 0, ... Tasten brauch ich da nicht ... Einbausituationn auch ungeeignet
5. PIR_OPERATION_MODE ist nur für Normal/ECO Modus.
   • eben nicht, damit kannst du auch die Bewegungserkennung auschalten (=2), was im WebUI so nicht angeboten wird... wie gesagt, bring aber nix, der Effekt nach meinen Test ist der gleiche, wenn du die Bewegungserkenung ausschaltestest per WebUI oder auch oder DP "MOTION_DETECTION_ACTIVE"

Noch ein paar Kommentare:

Daher will ich unbedingt die Erkennung der SMIs ausschalten, wenn ich die Erkennung nicht eben brauche, z.B. bei Nachtruhe.

Bei Nachtruhe läuft auch niemand durch die Gegend und könnte so durch kurze Erkennungsintervalle den DC hochtreiben. Bleiben nur die zyklischen Meldungen. Du versucht m.E. das Pferd von hinten aufzuräumen. Das Abschalten der Bewegungserkennung ist mit zu vielen Nachteilen verbunden und deshalb nicht zielführend.

ja ... nee, ich versuche nur meine Scenarien abzubilden ... nach meinen Tests kann ich die SMIs nicht aktiv lassen wegen DC. Es geht nicht nur um Nachtruhe ... meine Erkennungsintervalle sind 4 min, und das ist tagsüber eben zu viel wegen DC.

Leider ist Sammy ja seit geraumer Zeit inaktiv um mal Licht in die Dinger zu bringen.
Es gibt einen älteren Fred 2017/2018 bzgl. SMI und Expertenparmeter, damit die Auflösung entsprechen fixer ist (jedoch hielt damit eine neuer Batt.-Satz ca. nen Monat, oder so.

ja, danke. Hab ich auch gefunden ... Du hast ja damals schon etliche Analysen zum SMI durchgeführt
ok, is mir jetzt zu kompliziert, suspekt ... verstehe ich nicht ganz ... will ich auch irgendwie nicht.
nee, das will ich eigentlich gar nicht ...

Summa summarum : ich will eigentlich nur, dass die "Luder" HMIP-SMI bei mir funktionieren nach meinen Scenarien, die da wären:

• mach ma automatisch Licht an,wenn ich mich im Bereich befinde
• und das auch nur, wenn ich das will ...
• und dann noch Alarm bei abwesend + Bewegung...

Somit wären wir bei meinen Kriterien / Bedingungen:

• Bewegungserkennung eben nicht bei Nachtruhe
• tagsüber brauch ich des auch net.
• die Alarmanlage überlege dazu ich mir noch ... hab schon Templates, kein großes Ding
• im Arbeitszimmer/Homeoffice funxt des auch net wirklich abends ... igendwann geht das Licht aus, weil evtl. die 6 min * 8 erschöpft sind.

Na ja, kenn ich ja bei HMIP ... ich versuche halt immer, meine Scenarien zu realisieren nach dem Schema:

• per Direktverknüpfung
• ok. is limitiert ... wenn weitere Kriterien auftreten, dann per CCU-Programm
• und wenn das auch nicht geht, dann eben per Script ... SDV sei Dank

Ich denke grad, es wird auf folgendes raus gehen :

• SMIs cyclic messages auf das Minimum beschränken oder ganz ausschalten ... ich brauch von denen keine Werte außer Bewegung erkannt oder nicht.
• DVs löschen und eben per CCU-Programm das Licht schalten... mach ich ja für meine verbliebenen HM-Schalter eh schon und ich kann da noch weitere Kriterien einfügen. ... ok, läuft dann nicht mehr ohne die zentrale CCU ... mir grad egal.

VG und vielen Dank für evtl. Rückmeldungen

[Xel66]

ja ... nee, ich versuche nur meine Scenarien abzubilden ... nach meinen Tests kann ich die SMIs nicht aktiv lassen wegen DC.

Ich weiß nicht, was Du für Tests machst oder ob Du ständig durch die Wohnung tanzt. Ich habe zwei SMI bei mir im System, aber mangels IP-Partner für DVs laufen deren Funktionen ausschließlich über die CCU. Mein Duty Cycle ist meist einstellig mit wenigen Ausreißern auf etwas über 20% durch meine spezielle Art, die Keymatic beim Verlassen des Hauses anzusteuern. Allerdings bin ich in meiner DHH ein Einpersonenhaushalt, sitze aber nicht den ganzen Tag auf dem Sofa rum. Einer meiner SMI ist im Arbeitszimmer und da ich mich teilweise da häufig aufhalte, hat er auch oft was zu erkennen (und er erkennt auch normale Bewegungen am Schreibtisch). Eine negative Auswirkung auf den DC konnte ich noch nicht erkennen. Auch wenn früher Besuch im Hause war (teilweise mit zwei Kindern), war zwar der DC zweistellig, aber weit von Deinen Werten entfernt. Allerdings gab es da die SMI noch nicht. Die habe ich erst später nachgerüstet, weil ich sie für meine automatische Lichtsteuerung benötigte.

Meine SMI stehen auf:

• Zyklische Statusmeldung: [X]
• Anzahl der auszulassenden Statusmeldungen 1
• Anzahl der auszulassenden, unveränderten Statusmeldungen 20
• Low-Bat.-Schwelle 2.2V
• Reset per Gerätetaste sperren [ ]
• Routing aktiv [X]
• Empfindlichkeit Auslösen bei [jedem] Sensor-Impuls
• Mindestsendeabstand 4min
• Innerhalb des Sendeabstandes erkannte Bewegung senden [X]
• Zeit, nach der erkannte Bewegung zurückgesetzt wird 4min
• Helligkeitsfilter 8
• Normal / Eco Modus normal
• Blockierzeitraum 3sec

Diese Einstellungen sollten den Auslieferungsstand darstellen, da ich nichts m.W. geändert habe. Aber wie beschrieben, die SMI haben keine Verknüpfungspartner außer der CCU (einer steuert Hue-Strahler und einer einen HM-Aktor über Programme). Ich betreibe eigentlich alle meine BWM in den Einstellungen des Auslieferungszustandes (außer dass die Helligkeitsschwellen an die örtlichen Bedingungen angepasst sind). Das heißt auch, dass eben alle automatisch eingeschalteten Lichter mindestens 4 Minuten leuchten. Da ich inzwischen auch fast überall LED-Leuchtmittel und -Lampen verbaut habe, ist das auch kein wirkliches Problem.

Gruß Xel66

[g55]

Danke @Xel66,
leider ist meine umfangreiche Rückmeldung gestern abend irgendwie "verschütt" gegangen evtl. falscher Kopf im Browser gedrückt ? egal, das Problem sitzt wohl wie üblich so ca. 60 cm vorm Bildschirm

nur mal kurz zusammengefasst :

• tja, meine Installation ist eben anders = 7xSMI, davon 6 mit DVs, 1x per Programm mit HM-Dimmer ... noch 4 SMI in Planung für Lichtsteuerung
• die SMI-Einstellungen stehen bei mir auch auf "default", so wie du es beschrieben hast.... Danke. BTW, war "default" nicht 8 min für Einschaltdauer/zurückgesetzt ? ... ich hab noch nen unangelernten SMI in der Schublade, teste ich morgen mal ...
• ich und auch meine Frau tanzen nicht viel ... aber wir sitzen auch nicht nur aufm Sofa... das Übliche Halt : Aufstehen, Frühstücken, Arbeiten ... daneben eben Kochen + Essen, Putzen, mal eben was zu Trinken holen, ok... Bad muss auch mal sein.... was man halt so in den eigenen 4 Wänden macht. Da kommt wohl so einiges im Tagesablauf zusammen
• LEDs hab ich inzwischen auch überall, es kommt mir also auf die Einschaltzeit auch weniger an ...

Hier mal zur Info mein aktueller DC pro Tag = heute = nix verändert an dem SMIs

und gestern mit ein paar Tests ...

is also bestimmt noch "Verbesserungspotential" drin, oder ?
VG + good n8

PS : die Fehlermeldungen im Protokoll lt. Post 1 bez. "RESET_MOTION" und "MOTION_DETECTION_ACTIVE" hat sonst noch jemand ?