Hoher Duty Cycle während der Bearbeitung der Flows

[taucher4000]

Hallo,

ich habe in den letzten Tagen sehr viele Änderungen und Anpassungen an meinen Flows gemacht, da ich vor kurzen erst auf RedMatic umgestiegen bin. Nun ist mir aufgefallen, dass ich mit jedem Deployment meinen Duty Cylce in die höhe treibe. Bis auf 100% und dann geht natürlich gar nichts mehr.

Ist das ein Bekanntes Problem? Gibt es dazu eine Lösung oder mache ich etwas falsch?

Für mich sieht es so aus, als ob RedMatic bei jedem Deployment alle Geräte "anfunkt".

Gruß

[Hypnos3]

Du kannst einstellen wie deployed werden soll:

Ein komplettes deploy sollte nur selten nötig sein.

Ein kompletter Deploy wirkt wie ein Neustart, da geben die Value Nodes den letzten Status aus, wenn es eingestellt ist. Das kann dazu führen dass alle Flows anspringen und das wiederrum das viel gefunkt wird (ist genauso wie bei den ReGa Programmen).

Ich habe mir eine Neustart Strategie überlegt. Mit einem Inject Node lässt sich ein Flow auch nur einmalig zu einem neustart triggern. Hier setze ich eine globale context "variable", und diese nach einiger Zeit zurück. Wenn die Variable gesetzt ist verzögere ich Aktionen oder unterbinde diese ganz (je nachdem). Damit kann ich zwar den aktuellen Status "abgreifen" verhindere aber das wie wild herumgefunkt wird.

[hobbyquaker]

RedMatic "sollte" den DutyCycle beim Deployment nicht hochtreiben, hab vor einer Weile schon mal an dem Thema gehangen und dachte ich hätte das aus der Welt geschafft, aber offensichtlich ist da noch was im Argen. Werde es mir asap noch mal genau anschauen.

[hobbyquaker]

@taucher4000 könntest Du Deine Flows mal exportieren und zeigen? Ich bekomm das Problem mit dem DutyCycle beim Deployment nicht reproduziert und würde gern schauen ob dass vielleicht mit Deinen Flows an sich zusammenhängt. Wenn man z.B. Werte setzt in einem Flow der an einem Node hängt der "Beim Start bekannte Werte ausgeben" aktiviert hat könnte das eine Ursache sein.

[taucher4000]

@hobbyquaker Ich habe dir meine Flows per mail geschickt, da ich diese hier nur ungern komplett veröffentlichen will.

[Hypnos3]

@hobbyquaker, genau das war meine Vermutung.

[taucher4000]

Die Option "Beim Start letzten bekannten Wert ausgeben" habe ich bei allen Homematic Komponenten aktiviert. Ich habe diese Option aber so verstanden, dass der letzte bekannte Wert aus der CCU ausgegeben wird und nicht das Geräte beim start aktiv abgefragt wird. Die Bezeichnung dieser Option wäre somit irreführend, oder?

[hobbyquaker]

Nein, das wird auch nicht aktiv abgefragt. Das bezieht die Werte die die "Rega" im Cache hält. Allerdings erzeugt es halt beim Start je nach Konfiguration sehr viele Messages - und wenn die wiederrum mit Nodes verbunden sind die Werte auf Homematic setzen könnte das eine Ursache für hohen DutyCycle beim Deploy sein.

[hobbyquaker]

Auf den ersten Blick nichts auffälliges in Deinen Flows. Wichtig ist wenn Du eine Schleife mit Dashboard UI Nodes machst dass der Haken "If msg arrives on input, pass through to output:" nicht gesetzt ist, aber bei ein paar Stichproben scheinst Du das überall beachtet zu haben. Was ich gesehen habe ist dass Du einige Flows hast wo die Nachrichten in "OpenHAB Out" Nodes fließen, da wäre die Frage ob da vielleicht OpenHAB einen Befehl an Homematic Aktoren sendet, dann könnte das eine Erklärung sein.

[taucher4000]

Openhab nutze ich hier eigentlich nur als dashboard da ich HABPanel und Basic UI (mit mobiler Android App) 1000x besser finde als Dashboard UI. Leider habe ich da auch noch keine gute Alternative für node red gefunden (Etwas Off-Topic: für einen Tipp bezüglich alternative zu Dashboard UI wäre is dankbar. Muss aber neben Homematic auch andere Systeme unterstützen, daher aktuell Openhab).

Die Items im Openhab sind also nur Dummies und haben keine direkte Homematic-Verbindung.

Ich habe das Deployment jetzt mal auf "Modified Nodes" umgestellt und werde beobachten, wie sich der Duty Cycle verhält.

[hobbyquaker]

Habe mal angefangen ein UI zu basteln, das unterstützt aber stand heute nur Homematic Geräte, plane aber in Zukunft da auch Widgets für beliebige Geräte anzubieten: https://github.com/hobbyquaker/RedMatic/wiki/Webapp Bis jetzt nur als WebUI, aber in Zukunft möcht ich es auch mit Cordova als iOS/Android App verpacken.

[Sineos]

Habe mal angefangen ein UI zu basteln, das unterstützt aber stand heute nur Homematic Geräte, plane aber in Zukunft da auch Widgets für beliebige Geräte anzubieten

Zu diesem Thema: https://github.com/GermanBluefox/node-red-vis bluefox von ioBroker hatte mal angefangen eine geniale UI für NR zu bauen. Leider nicht mehr aktiv entwickelt wegen dem Fokus auf ioBroker.

[taucher4000]

@Sineos das sieht eigentlich sehr vielversprechend aus. Leider mit Redmatic nicht kompatibel wegen den URL-Pfaden :-(

Echt schade, dass es zu Node Red meiner Meinung nach keine "ordentliche" Visualisierungsmöglichkeit gibt.

[Sineos]

Ja, so genial ich NR finde, die UI ist gruselig. Langsam, die Graphen haben ein schreckliches Mem-Leak im Browser, keine freie Positionierung usw.

Die vis von ioBroker ist echt schick und flexibel, nur der NR Abkömmling ist schrecklich veraltet und buggy. Nutze ioBroker eh schon, also werde ich wohl die gesamte UI mal dorthin umziehen. Wobei mir alles unter einem Dach wirklich besser gefallen würde.

[hobbyquaker]

Ein UI mit freier Positionierung a la DashUI/ioBroker.vis werde ich eher nicht bzw. nicht in absehbarer Zukunft angehen, das wäre ein riesen Projekt und ich selbst habe da eher keine Verwendung für. Ich selbst nutze als UI und Android App eine individuelle und statische (nicht mit einem Editor erzeugte sondern einfach in HTML/CSS zusammengebastelte) Cordova App die auf Polymer und diesem Element fußt dass Attribute und Events der Elemente direkt auf MQTT Topics linkt: https://www.webcomponents.org/element/hobbyquaker/mqtt-wrapper/elements/mqtt-wrapper Sieht beispielsweise so aus:

Ich bin einfach schneller am Ziel wenn ich das statisch bau als wenn ich jetzt nochmal ein neues DashUI/vis beginnen würde und mit Web Components und Custom Elements performed das imho auch wesentlich besser als mit dem mittlerweile recht angestaubten Can.js auf dem DashUI/vis basiert.

Ihr könnt mir allerdings gern Wünsche mitteilen für RedMatic-WebApp - https://github.com/hobbyquaker/RedMatic-WebApp/issues

Wenn euch das Konzept der WebApp zu starr ist: Ich denke ioBroker.vis lässt sich recht komfortabel an RedMatic anbinden wenn man MQTT zum Nachrichtenaustausch nutzt, hab auch den Mosquitto Broker als CCU-Addon paketiert: https://github.com/hobbyquaker/ccu-addon-mosquitto

[hobbyquaker]

Und um nochmal vom Off-Topic wegzukommen: @taucher4000 besteht das Problem mit dem DutyCycle beim Deployment noch? Sollen wir das weiter untersuchen? Der nächste Schritt wäre mal RedMatic auf Debug Level loggen zu lassen und sich anzuschauen was da so an die Homematic Schnittstellenprozesse gesendet wird wenn Du Deine Flows Deployst.

[taucher4000]

Ich habe soeben testweise 6x hintereinander (mit ein paar Minuten Abstand) ein Full-Deployment durchgeführt. Dabei ist der Duty-Cycle auf 97% gestiegen. Irgend etwas scheint bei mir also grundlegend schief zu laufen. Evtl. doch meine Flows?

Anbei die Debug-Log während eines Depoloyments

messages.log

[hobbyquaker]

Kam leider noch nicht dazu Deine Logs anzuschauen. Aber such einfach mal ob da beim Deployment eine Häufung von ccu-connection ... setValue Einträgen auftaucht. Wenn ja müsstest mal versuchen rauszufinden durch welche Flows/Nodes die ausgelöst werden.

[taucher4000]

In Verbindung mit dem ObenHab node bekomme ich immer ein "setValue" in der Log, egal ob der Trigger von Openhab kommt oder direkt von der CCU via z.B. eines Schalters. Das macht für mich aktuell keinen Sinn und könnte ein Grund dafür sein, dass der Duty Cycle nach oben schießt.

Ich habe überall die Option "Emit changed values only" in den CCU Items aktiviert. Wenn also ein CCU Item bereits den STATE == true hat und ich dann den status boolean/true erneut injecte, dann sollte in der Log doch eigentlich kein "setValue" auftauchen, oder? Genau das passiert aber. Kann das den Duty Cycle nach oben treiben?

[hobbyquaker]

Jap, die setValue gehen auf den DutyCycle. Wenn "Beim Start letzten bekannten Wert ausgeben" aktiviert ist erzeugen die RPC Event und RPC Value Nodes bei jedem Deploy eine Nachricht. Sind die vielleicht ursächlich für die setValue?

[hobbyquaker]

@taucher4000 hast Du das mit dem Duty Cycle in den Griff bekommen?

[taucher4000]

@hobbyquaker Ich bin aktuell dabei alles auf MQTT umzustellen. Damit läuft es deutlich besser. Der hohe Duty Cayle scheint also tatsächlich durch das OpenHab Node und der Integration ins Openhab zu Stande bekommen zu sein. Da ich jetzt eine gute MQTT Alternative zu den Openhab Visualisierungen gefunden habe, sollte sich das Problem für mich gelöst haben.

[hobbyquaker]

Top, dann schließ ich den Issue hier.

[ptweety]

@taucher4000 was ist denn die von dir nun eingesetzte Alternative?

[taucher4000]

@ptweety Ich bin jetzt komplett auf Home Remote umgestiegen. Eine Android/IOS app, welche neben MQTT noch viele andere Protokolle unterstützt und komplett selber gestaltbar ist.

http://thehomeremote.com/

Für mich die beste Alternative aktuell.

Anbei mal zwei Screenshots von meiner Umsetzung. Das Design ist dabei via Windows-Anwendung (Designer) komplett selber gestaltbar.