HMIP-SMI - Fehlermeldungen im Protokoll ... ?

[Xel66]

is also bestimmt noch "Verbesserungspotential" drin, oder ?

Massiv. Ein Grundpegel des Duty Cycle von über 20, wenn wirklich nichts los sein sollte, ist in meinen Augen in ungünstiger Programmierung begründet. Das kann auch nicht mit zyklischen Statusmeldungen erklärt werden (maximal nur durch Programmläufe, die durch Statusübermittlungen "bei Aktualisierung" getriggert werden), denn diese gehen häufig als nicht quittierpflichtige Broadcasts raus. Um Problemen mit unbeabsichtigt getriggerten Programmen auf die Schliche zu kommen, sind die Zeitstempel in der WebUI unter "Status und Bedienung/Programme" ein erster Anlaufpunkt, um häufig getriggerte Programme zu identifizieren. Hat man welche identifiziert, muss man die Programmierung analysieren und ggf. optimieren. In bestimmten Konstellationen verhalten sich vermeintlich auf "bei Änderung" getriggerte Programme wie "bei Aktualisierung". Besonders Programme mit mehreren SONST WENN oder welche, die Trigger in beide Richtungen (über /unter definiertem Grenzwert oder WAHR/FALSCH-Prüfungen) auswerten.

Gruß Xel66

[g55]

jep, mag schon sein, dass meine Programme nicht ganz optimal sein könnten ... andere Baustelle ...
Die "Grundlast" ist bestimmt zum Teil durch die Menge der IP-Geräte verursacht. Hier sind u.a. Temperatur- + Sonnensensor + Wetterstation verbaut, die funken eben alle 2-6 Minuten. Viele andere Geräte haben zykl. Meldungen aktiv mit 1/20, manche funken da auch mehrmals pro Stunde + bei irgendwelchen Wertänderungen.

Probleme sehe ich jedoch eher bei den Peaks morgens und abends, die neben der Rollo-Steuerung durch die SMIs nach meinen bisherigen Erkenntnissen um bis zu 20% in die Höhe getrieben werden, und das auch bei deaktivierten Programmen.
Auch wenn ich die SMIs tagsüber aktiv lasse, quasseln diese natürlich bei jeder Bewegung, bedeutet auch ca 5-10% mehr DC bei meinen 7-10 SMIs, obwohl ich diese Bewegungsmeldungen tags bei Anwesenheit überhaupt nicht brauche

So richtig verstehen kann ich die SMIs wohl noch nicht ...

[nimmnenkeks]

jep, mag schon sein, dass meine Programme nicht ganz optimal sein könnten ... andere Baustelle ...
...
... Rollo-Steuerung durch die SMIs nach meinen bisherigen Erkenntnissen um bis zu 20% in die Höhe getrieben werden, und das auch bei deaktivierten Programmen.
..obwohl ich diese Bewegungsmeldungen tags bei Anwesenheit überhaupt nicht brauche...

Sofern Du DV'S für die Rollladensteuerung nutzt, wird das vermutlich so bleiben.
Abhilfen schaffen dazu z.B. Rollladen-Programme, die NUR die zu nutzenden Rollladenposition verwenden (ohne DV's SMI-> Rollladenaktor).

Wenn Du die SMI's wirklich "tagüber" und "bei Anwesenheit" nicht brauchst, aktiviere/deaktiviere die Dinger (ggf. einzelne) doch bevor Du ggf. eine SysVar Tag/Nacht und/oder Anwesenheit/nicht Anwesend um ein paar Sekunden verzögert setzt.
So bleibt deren DC unten.
Habe eben noch einmal ins Protokoll geschaut und keine Fahler bzgl. SMI's gefunden, obwohl Tag/Nachtkonfiguration einiges bei den Dingern gänzlich umfrickelt.
Über den SDV kannst Du ja dann auch die Auslöseskripte einbauen und kontrollieren, ob es wie umgesetzt funktioniert.

.Keks

[Xel66]

Hier sind u.a. Temperatur- + Sonnensensor + Wetterstation verbaut, die funken eben alle 2-6 Minuten.

Genau diese senden aber ihre Werte als Broadcasts. Somit sind diese Statusinfos nicht quittierpflichtig und wirken sich nicht auf den Duty Cycle aus. Etwas anders sind ggf. Programme, die genau auf diese Werte triggern und ggf. im gleichen Takt irgendwelche Aktoren ansteuern (deren Ansteuerung und Rückmeldung aber dann quittierpflichtig sind). Die Programme könnte man dahingehend optimieren, dass der Status des anzusteuernden Aktors vorher geprüft wird, und eine Ansteuerung nur bei Abweichung vom Sollzustand erfolgt.

Gruß Xel66

[g55]

danke :

Sofern Du DV'S für die Rollladensteuerung nutzt, wird das vermutlich so bleiben.
Abhilfen schaffen dazu z.B. Rollladen-Programme ...

meine Rollosteuerung läuft nur über Variablen, Programme, Scripts. SMIs sind da nicht enthalten. Sorry, vielleicht unglücklich formuliert. Die SMIs werden i.d.R. verzögert eingeschaltet durch SV "Rollo aktuell xxx < 20" UND SV "Nacht=true", letzterer nur prüfen.

Wenn Du die SMI's wirklich "tagüber" und "bei Anwesenheit" nicht brauchst, aktiviere/deaktiviere die Dinger (ggf. einzelne) doch bevor Du ggf. eine SysVar Tag/Nacht und/oder Anwesenheit/nicht Anwesend um ein paar Sekunden verzögert setzt.

Mache ich ja bereits. Für jeden SMI gibt es ein Programm, welches den durch SVs aktiviert / deaktiviert. Ansonsten habe die SMIs DVs zu den zu schaltenden IP-Aktoren (BSM, BDT, PS)

Habe eben noch einmal ins Protokoll geschaut und keine Fahler bzgl. SMI's gefunden,

bei jedem deaktivieren / aktivieren taucht bei mir der Fehler im Protokoll auf, z.B.:

Code: Alles auswählen

Sep  4 06:49:07 HomeBox21 local0.err ReGaHss: ERROR: rpc.CallSetValue failed; address = 00091BE998F084:1 [WriteValue():iseDOMdpHSS.cpp:76]
Sep  4 06:49:07 HomeBox21 local0.err ReGaHss: ERROR: XMLRPC 'setValue' call failed (interface: 1011, params: {"00091BE998F084:1","MOTION_DETECTION_ACTIVE",true}) [CallSetValue():iseXmlRpc.cpp:1505]
Sep  4 06:49:07 HomeBox21 local0.warn ReGaHss: WARNING: XMLRPC 'setValue': rpcClient.isFault() failed (url: xmlrpc://127.0.0.1:32010, params: {"00091BE998F084:1","MOTION_DETECTION_ACTIVE",true}, result: [faultCode:-1,faultString:"Generic error"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]
Sep  3 23:48:29 HomeBox21 local0.err ReGaHss: ERROR: rpc.CallSetValue failed; address = 00091BE998F0D6:1 [WriteValue():iseDOMdpHSS.cpp:76]
Sep  3 23:48:29 HomeBox21 local0.err ReGaHss: ERROR: XMLRPC 'setValue' call failed (interface: 1011, params: {"00091BE998F0D6:1","MOTION_DETECTION_ACTIVE",false}) [CallSetValue():iseXmlRpc.cpp:1505]
Sep  3 23:48:29 HomeBox21 local0.warn ReGaHss: WARNING: XMLRPC 'setValue': rpcClient.isFault() failed (url: xmlrpc://127.0.0.1:32010, params: {"00091BE998F0D6:1","MOTION_DETECTION_ACTIVE",false}, result: [faultCode:-1,faultString:"Generic error"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]

anscheinend auch nur, wenn das SMI schon länger ein/aus war ... hab da noch kein eindeutiges Muster erkennen können.

Über den SDV kannst Du ja dann auch die Auslöseskripte einbauen und kontrollieren, ob es wie umgesetzt funktioniert.

jep, is ja bereits eingebaut, sowohl eigene Debugs (mache in schon länger per SV ) wie auch die SDV-Skripte ...die SMI-Programme funktionieren eigentlich, wie sie sollten ... jedenfalls ist mir noch nix aufgefallen ...

Die Programme könnte man dahingehend optimieren, dass der Status des anzusteuernden Aktors vorher geprüft wird, und eine Ansteuerung nur bei Abweichung vom Sollzustand erfolgt.

klar, meine Programme prüfen den Status, da wird mWn. nicht ohne Prüfung gefunkt. Zudem baue ich in der Regel eine Verzögerung ein.

Ich sehe schon bez. meiner Programme, ich werde dem allgemeinen Tipp mal folgen und die einfach mal ggf. blockweise deaktivieren. Ist wohl der einfachste Weg um eben rauszufinden, ob / welchen Einfluss Programme auf den DC und SMIs haben

[nimmnenkeks]

hmmm,
Störer scheiden eigentlich aus, da ja bei jedem SMI.

Wo Du schreibst, dass Du die Probleme bei längerer Aktivierung hast, fällt mir ein, dass die Dinger seit Anbeginn einen Bug hatten (immer noch???)...
sie pennen ein.
Daher setze ich die Dinger einfach in der Nacht per noch einmal auf "aktiv" (einfaches Zeitprogramm auf alle SMI's).
Hatte ich verdrängt und das Programm ebenfalls, sorry.

OT
Programmoptimierung für Rollladenaktoren mache ich so, dass SysVarwerte erst geprüft werden und NUR bei Abweichung vom neuen Positionswert ein Funkbefehl raus geht.
Nachdem die Rolladen gefahren sind, werden die aktuellen Werte ja geschrieben und es braucht nie etwas abgefragt zu weden.
Rollladenprogramme kann man (Zitat Black: "in epischer Tiefe umsetzen!"), eben jeder wie er mag

BTT
Mach Doch mal ein "Komplett-Backup" von einem SMI per SDV.

Dann Schritt 1:
Am SMI Werksreset durchführen, anschließend ein enig warten.
Danach sollten "eigentlich" die Parameter von CCU/Raspel wieder komplett übertragen werden.
Protokoll prüfen.

Immer noch nicht besser, dann Schritt 2:
Da SDV Backup von Device vorhanden, ein Ding in UI Löschen und wieder anlernen.
Mit SDV dann das Device wieder herstellen.
Da Komplett-Bakup von Device vorhanden, weden auch alle DV's wieder hergestellt


Gute Gelingen

.Keks

[g55]

Wo Du schreibst, dass Du die Probleme bei längerer Aktivierung hast, fällt mir ein, dass die Dinger seit Anbeginn einen Bug hatten (immer noch???)...
sie pennen ein.
Daher setze ich die Dinger einfach in der Nacht per noch einmal auf "aktiv" (einfaches Zeitprogramm auf alle SMI's).
Hatte ich verdrängt und das Programm ebenfalls, sorry.

jep, hat @Xel66 weiter vorne auch schon bestätigt, dass die SMIs einpennen ... "Bug or Feature" ?
Zeitprogramm hatte ich schon aktiv für jeden einzelnen SMI, da die zu unterschiedlichen Zeiten aktiv/deaktiv sind ... mit Nebeneffekt des Licht einschaltes beim Aktivieren. Ok, das bekomme ich auch noch weg per virtuellem Kanal...

Rolladensteuerung : meine ist auch nicht gerade DC-freundlich funktioniert mMn. fast perfekt, is jedoch relativ komplex, berücksichtigt u.a. Sonnenstand, Helligkeit, akt Temperatur innen und außen, Temp-Diff außen, Tageszeit und natürlich mit Check soll-aktuell um unnötiges zu vermeiden.
Trotzden sehe ich auch in älteren Diagrammen, dass da morgens / abends und bei Beschattung intensiv gefunkt wird.

btw, der Fehler im Protokoll tauch wohl erst auf, wenn der SMI bereits längere Zeit (bei mir > 20-30 min) in einem Zustand war. Bei früherem (de-)Aktiviren komt keine Meldung im Protokoll.
Danke, den SMI-Test mit Ablernen / Anlernen / SDV-backup mach ich nachher ...

[g55]

Ein Grundpegel des Duty Cycle von über 20, wenn wirklich nichts los sein sollte

Mal nur so nebenbei ... meine SMIs sind alle gerade deaktiviert. F..k for Servicemeldungen.
Ändert leider wenig am "Grundpegel"
hab inzwischen herausgefunden, dass des wohl normal ist bei meinen HMIP-Geräten :

• kritisch sind meine Rollos = BROLL, die senden zyklisch per Standard, aber bei jedem Fahren mindestens 3+ Ihre Werte, egal ob getriggert per Schater, Programm oder Wochenprogramm des Gerätes. Wenn ich also 5 von 8 Rollos innerhalb von 20 min. hoch oder runter fahre, ist der DC eben ca 10 % höher.
• ebenso kritisch sehe ich meine Thermostate/Gruppen aus eTRV/WTH/SWDO. Gerade morgens springt ebem Heizung an... eTRVs melden sich öfter auch wegen Temperatur/Ventil... dann machst du natürlich Fenster auf zum Lüften ... eTRVs werden informiert, und Fenster wohl auch wieder zu ... wieder mit Meldung an eTRV ...da kommt schon einiges zusammen.
• meine Programme analysiere ich gerade ... noch nix wesentliches gefunden bez. DC da bleibt ich jedoch dran ... die meisten Programme checken Werte von Geräten und speichern die in SVs. Ist das jetzt "Schädlich fürn DC" ? ich denke, eher nicht, oder ?

Ich denke eher, dass mein Konzept, die SMIs ein-/auszuschalten, wenn das Rollo unten/oben ist, so nicht funktioniert ... wenn ich 5 SMIs so einschalte, steigt der DC um 10 % ... ich hab aber evt. 10 SMIs
da muss ich wohl mir was anderes ausdenken oder mit den Verzögerungen versuchen, zu "optimieren" ... 2Btested.

btw... @Keks : die Fehlermeldungen sind auch bei neu angelerntem SMI vorhanden ... nach ca. 20-30 min.
vG

[g55]

nur mal so als Update :

• ich hab jetzt 11*HMIP-SMI instaliiert für meine automatiche Lichtsteuerung
• für jeden SMI gibt es 2-4 Programme ... je nach Anwesenheit, Nachtruhe, Licht (hab noch HM-Aktoren...)
• und natürlich DVs zu HMIP-Aktoren ... BSM, BDT, PS ...
• ich schalte die SMI aus/ein je nach Rollo-aktuell (SV) oder Helligkeit per script+SV (wo eben kein Rollo ist)
• hab auch meine Programme / scripts angepasst, dass eben einiges nicht gleichzeitig erfolgt. Rollos eben eins nach dem anderen ... verzögert
• die Servicemeldungen der SMIs im ausgeschalteten Zustand interessieren mich nicht mehr ... werden ignoriert.
• ich schalte (fast) alle bei "Abwesenheit" auf aus... Verzögerung +10 sec ...
• und ggf. bei Anwesenheit wieder ein ... je nach Dunkelheit, Nachtruhe, Helligkeit/Rollostand ...
• und der DC liegt immer noch unter 30% ... ok DC ist wohl auch eine Philosophie-Frage ... für mich ist jetz bei meiner Installation alles unter 50% = "normal"

so, des funktioniert soweit, mal sehen, ob ich (+Frau ) die nächsten Tage noch was finde(n)
vG