Zeitdelay Trigger BWM Multisensor 6 und Start LUA Script

Hallo Zusammen
bin Leihe und hab Probleme mit HC2&Multisensor 6.

Geräte: HC2 neuste Firmware, Fibaro Switch im Lichtschalter, Aeontec MultiSensor 6 am USB. Am HC sind ca 60 Geräte gepaird (15 Switches, MS6 und RollerShutter, Rest Hue-Lampen). CPU-Load vom HC2 kaum je über 10%.

Problem: Wenn man das Bad betritt detektiert der MS6 nach ca 1-3 Sec die Bewegung (Grünes Licht am MS6). Danach dauert es teilweise bis mind 5s, teilweise bis zu 20 Sekunden, bis das Script ausgeführt wird, was natürlich unbrauchbar ist.

Das LUA Scipt ist eine Abwandlung des „LichtEinSolangeBewegung“ aus dem Forum.

Wenn ich dies via Magic Szene mache, geht es gefühlt einiges schneller (aber immer noch zu langsam), aber dort kann ich (mit meinem Wissen) nicht so viel machen, da im Script noch Hue’s geschaltet und je nach Tageszeit gedimmt werden.

Ist dies normal? Oder gib es hier einen guten Trick? (Hab mir schon überlegt einen Türkontakt an die Badtüre zu machen, aber wenn es dort zwischen Trigger und LUA Ausführung auch so lange geht, bringt das ja auch nichts).

Danke und Grüsse
H.

Hallo @hb-iwc,

die Frage ist eigentlich was passiert wirklich, ist die Ausführung des Scripts bei Bewegungserkennung verzögert, was ich persönlich für unwahrscheinlich halte, oder tritt die Verzögerung beim Schalten des Aktors auf? Letzteres ist sicher deutlich wahrscheinlicher und lässt Probleme im z-wave Netzwerk vermuten, diese wiederum können sehr vielschichtig sein und reichen von schlichten Empfangsproblemen bis hin zu Geräten, die evtl. das z-wave Netzwerk mit „Informationen“ fluten/überlasten.
Solchen Problemen ist leider schwer auf die Spur zu kommen, als erstes würde ich versuchen, den Schaltaktor für das Licht und den BWM neu abzufragen, evtl. sind hier mal Informationen über das z-wave Mesh „durcheinander gekommen“. Auch eine komplette Mesh-Reorganisation könnte hier helfen, evtl. sind im Laufe der Zeit Geräte abgeschafft oder umpositioniert worden?!? Diese Prozedur dauert aber und kann zu zeitweisem „Ausfall“ von Geräten führen, da auch die Reorganisation viel Netzwerktraffic verursacht. Auch der Einsatz anderer 868MHz-Antennen kann helfen, das kostet nicht die Welt. Bei Empfangsproblemem kann auch ein zusätzliches, günstig positioniertes z-wave Gerät, das permanent mit Strom versorgt wird und somit als Repeater fungiert, Abhilfe schaffen.

Wenn Du nicht über einen z-wave Sniffer verfügst, kann man nur mittels Trail&Error, sprich nacheinander Geräte deaktivieren, Geräte finden, die evtl. das Netzwerk fluten. Ggf. sind sog. FLIRS-Geräte (Heizungsthermostate) im Einsatz, die sowas IMMER machen, weswegen man diese „sparsam“ einsetzten sollte…
Wenn Dein Netzwerk geflutet wird, kann Dir aber auch der Support bei der Suche helfen.

Sollte aber wirklich, wie Du schreibst, die Verzögerung wirklich zwischen BWM und Script-Start entstehen, wäre zu prüfen, wann kommt denn die Bewegungsmeldung im HC2 an. Dass wirklich eine Verzögerung zwischen Eingang der Bewegungsmeldung und Script-Start entsteht, ist wirklich sehr unwahrscheinlich. Ich würde vermuten, in dem Fall gibt es eine Verzögrung zwischen Erkennung und Meldung, womit wir wieder beim Thema z-wave Netzwerk von oben wären…

Möglicherweise sieht das tatsächliche Verhalten ja so in der Art aus:

Bewegungserkennung -> delay -> Eingang Bewegungsmeldung am HC2 -> Scriptstart -> Schaltbefehl HC2 an Aktor -> delay -> Schaltaktion Aktor

Du siehst, es ist ein weites Feld, leider.
Viel Erfolg, Heiko.

Hmm :thinking: … ich wurde mit den Motion Sensoren - egal welche Marke, egal welches Skript - nie glücklich. Haben immer nur Probleme verursacht. Ausgelöst, nicht ausgelöst, Geister Auslösungen, Netzwerk geflutet, usw.
Seitdem ich normale Bewegungsmelder verwende ist der Spuk vorbei.

@mib Im Außenbereich nehme ich auch normale BWM (15.-) mit Fibaro-Switch (lag noch rum) und kann das auch nur empfehlen, im Innenbereich hat mach sicher aber eben meist nicht an der richtrigen Stelle Strom anliegen, wie hast Du das gelöst?

Grüße Heiko…

Hallo Zusammen,

danke für die Tipps. Ich habe eine Mesh-Rekonfiguration und die Funktion „Alle Geräte neue konfigurieren“ durchgeführt. Damit sind dann alle Modul-Daten, Namen, Setups verloren gegangen und ich musste das ganze Haus neu konfigurieren, was mich 2 Tage gekostet hat :disappointed_relieved:

Bei dieser Gelegenheit habe ich auch einen Fibaro-Tür-Sensor installiert und in das Bad-Licht-Script eingebaut, sowie bei jedem MS6 die Standard-Reportingzeiten hoch geschraubt umden Zwave-Traffic zu verringen.

Resultat ist, dass es nun viel besser und schneller funktioniert. Am Besten geht es, wenn der Trigger durch öffnen der Türe kommt, dann geht es jetzt ca 1-2 Sekunden, bis der Fibaro Dimmer-Switch geschaltet wird. Wenn der Trigger vom Aeontec Multisensor 6 geht es ca 3-5 Sekunden (im Gegensatz zu 5-20 Sekunden von vorher).

Also der recht grosse Aufwand hat sich gelohnt. Es funktioniert nun sehr viel besser und ist sogar brauchbar. Ich denke das Mesh-Netzwerk hatte wirklich ein Problem und der Tür-Switch hat dann die Schaltverzögerung nochmals entscheidend verbessert :call_me_hand:

Danke und beste Grüsse, hb-iwc

Guten Morgen

Das hatte ich in den letzten Tagen auch, mein Mesh hatte sich völlig aufgehängt.
Hat sehr lange gedauert bis ich das gefunden hatte.
Lag an einem Heizkörperthermostat der hatte nur noch 30% Batterie (eigentlich kein Problem) aber der hat das komplette Netz aus 124 Teilnehmern so durcheinander gebracht das Lampen schalteten, Klingeln klingelten und Sirenen losgingen hier wahr was los kann ich dir sagen.
Ich habe das hier mit wieder hingebogen nach dem ich den Störenfried gefunden hatte :crazy_face:

Das habe ich im Fibaro Forum dazu gefunden von einem User Namens „robmac“ aus England.
[ Hinzugefügt*: 2014-06-03, 14:19* ]
Von dem, was ich verstehen kann, gibt es drei Versionen des Anrufs, aber da es keine Dokumentation gibt…
a) fibaro:call(1,‚requestNodeNeighborUpdate‘,1) --updates alle Knoten im Netzwerk
b) fibaro:call(1,‚requestNodeNeighborUpdate‘,anode) --updates anode im netzwerk
c) fibaro:call(anode,‚requestNodeNeighborUpdate‘) --updates anode im Netzwerk
wobei Anode die ID eines beliebigen Knotens ist.
Ich neige dazu, a) selten und b) zu verwenden, wenn ein Knoten nicht funktioniert. Wenn das nicht behoben wird, gehe ich zurück zu a).
so einfach ausgedrückt

Ich benutze:
a) wenn ich einen Knoten verschoben habe und weiß, dass er alle Knoten wiederentdecken muss, um ihn zu finden
b) wenn sich ein Knoten nicht verhält, sondern a) verwendet, wenn dies nicht
aber ich dachte, c) würde auch funktionieren, aber möglicherweise nicht?
Es wird in Aktionen gegen Knoten aus der API aufgeführt, aber richtige Dokumente würden helfen.
(Übersetzt aus dem Englischen mit Google).
Beim HC3 habe ich das so aufgerufen (Neuer Syntax)
fibaro.call(1,„requestNodeNeighborUpdate“,319)

Hat wunderbar funktioniert nach ca. 15 Minuten wahr das Thema durch und alle Teilnehmer wahren von Rot und Gelb wieder auf grün ohne meinen direkten Eingriff.

Grüße aus dem Sauerland
Frank

@hb-iwc

Das tut mir wirklich unendlich leid, aber Du hast dann offenbar die erste Option gewählt „Alle Modul erneut konfigurieren:“
Das hier wäre das Angesprochene:


Am Ende kann man ja aber, zum Glück sagen, kein Schaden ohne Nutzen.
Offensichtlich, hat der Neuaufbau deines Meshs ja Abhilfe geschaffen, auch wenn Du leider den harten Weg gewählt hast.

@Berges01
gibt’s die Reconfig-Option (s.o.) in der GUI des HC3 nicht mehr?

Grüße Heiko…

@heikoh

Eigentlich schon aber ist bei mir ausgegraut.
Hatte schon Fibaro-Support dran die haben das nicht hinbekommen.
Da ich da hoffentlich nicht so oft benötige ist mir das auch Egal, so lange der LUA funktioniert ist alles in Butter.
Ob das beides das Gleiche ist weis ich aber nicht, der LUA funktioniert und das ist ausreichend.
Im Forum bei Fibaro schrieben die das der HC3 das turnusmäßig anwirft was ich aber so nicht bestätigen kann.
Ich habe das mal über mehrere Tage beobachtet bei einem Sensor der schlecht angebunden wahr und der hatte sich erst nach dem ich den LUA abgesetzt habe richtig einsortiert.
Das spricht gegen einen Turnusmäßigen anwurf.
Wie dem auch seih alles wieder in Butter und läuft, wahr aber sehr schlechte Erfahrungen.
Hatte schon drüber nachgedacht auf openHAB, IO-Broker oder Home-Assist umzusteigen wegen so einiger Ungereimtheiten mit dem HC3.
Habe openHAB und Home-Assist mal Installiert und etwas rumgespielt. (Pro System ca. 3 Tage investiert) Beide auch nicht Schlecht aber da hätte ich alles Neu machen und mich von LUA auf Java umstellen müssen dazu hatte ich dann wirklich keine Lust.
Aber was nicht Ist kann ja noch werden wenn mich der HC3 weiter ärgert stelle ich um, vom homee auf HC3 hat ja auch funktioniert.

Gruss Frank

Hallo Heiko,

danke für die Antwort. Immerhin läuft jetzt alles besser als vorher :slight_smile:

Sollte man die Mesh-Reconfig beim HC2 periodisch machen, oder ist das -wenn man nichts ändert- nicht nötig?

@Berges01
Danke für den Tip. Führst Du das Lua-Script
a) fibaro:call(1,‚requestNodeNeighborUpdate‘,1) --updates alle Knoten im Netzwerk
oft aus? Ist das das gleiche wie die Funktion „Mesh-Netzwerk Reconfig“?

Wo sieht man den Zustand des Mesh-Netzwerks mit Rot/Gelb/Grün?

Danke und viele Grüsse
hb-iwc

Hallo @hb-iwc

Ich führe das nur aus, bzw. Starte die Szene nur wenn ich Probleme habe.
Never change a running system
If ain’t broke, don’t fix it
Never change a winning team
usw.
Kann ich dazu nur sagen.

Rot,Grün,Gelb ist das kleine Symbol bei den Geräten.


Hier ist alles mit einem Grünen Häkchen also alles OK.

Schau mal hier auch das kann ein Grund sein das abzurufen. (prevention ist hier das Thema)
Mesh Konfiguration auslesen HC3 - Fibaro Forum / Fibaro (HC3) LUA Scripts - siio – Community

Gruss Frank

Danke Frank,

gehe ich richtig in der Annahme, dass das mit dem Rot/Gelb/Grün bei ‚Devices‘ beim HC3 ist? Beim meinem HC2 sieht das anders aus. Sieht man dies beim HC2 auch irgendwo?

Grüsse hb-iwc

Hallo @hb-iwc

Ja ich habe den HC3 und das ist ein Bild vom HC3 Geräteansicht (Nur ein Auszug).
Ob das beim HC2 auch so ist kann ich dir leider nicht sagen, da ich den nicht kenne.

Gruss Frank