RaspberryMatic 2.27.7.20170316 DutyCycle erhöht nach Update

[jmaus]

Es mag sein, dass der Dutycycle vorher zu tief war aber jetzt ist er unter RaspberryMatic eindeutig zu hoch (oder dann unter der CCU2 zu niedrig).
Denn ich habe inzwischen meine CCU2 wieder in Betrieb genommen um einen Vergleich zu haben und das Resultat ist eigentlich klar:
[...]

Nun, es ist schon einmal ein guter Ansatz die DC werte der exakt gleichen Installation unter einer CCU2 mit dem von RaspberryMatic zu vergleichen, das sollten viel mehr Leute machen! Aber selbst unter einer CCU2 erscheint mir ein DC von großteils < 1-2% vom Bauch her ziemlich unrealistisch zu sein, muss ich sagen. Das würde ja bedeuten das gerade mal 1%-2% von 36 Sekunden (d.h. 0.36 bis 0.72 Sekunden) innerhalb einer Stunde etwas gesendet wird. Insofern würde ich mal behaupten das der DC unter einer CCU2 ggf. immer noch nicht ganz korrekt berechnet bzw. ausgegeben wird. Denn solch niedrige Werte erhalte ich lediglich mit einer frischen RaspberryMatic mit nur wenigen angelernten Geräten. Sobald man mehr und mehr Geräte dazu nimmt steigt der DC natürlich sukzessive an.

Die praktisch relevante Frage die sich dabei jedoch stellt ist, ob solch erhöhte DC werte in der Praxis wirklich zu Problemen führt. Bei mir geht der DC lediglich nach einem Neustart für ca. 1 Std auf rund 90-99% und das vmtl. auch nur weil ich einige Programme in der WebUI noch habe die bei einem Neustart überdurchschnittlich viele Komponenten anfunkt - dann pendelt er sich aber so bei 20 bis max 60% ein und ich habe eigentlich auch nicht wirklich mehr Kommunikationsstörungen (auf längere zeit gesehen).

Wenn ihr aber definitiv untermauern könnt, dass mit der exakt gleichen Anzahl an Geräten und Programmen, etc. der DC in RaspberryMatic bzw. mit dem Funkmodul substantiell größer ist als mit einer CCU2 der gleichen Konfiguration dann würde ich mal bitten das wir hierzu mehr debug Informationen (grafische/zeitliche verläufe des DC) sammeln sollten. Sinnvoll wäre hierbei in der Tat eine zusätzliche Sammlung von rfd logs wo auch die jeweilige Funkinformation drinsteht damit man das Funkaufkommen zwischen dem CCU2 Test und dem RaspberryMatic Test vergleichen und in relation setzen kann. Wenn wir hierzu dann genug Informationen sammeln könnte ich damit erneut auf eQ3 zugehen und probieren das diese sich das ganze nochmal detaillierter anschauen um ggf. irgendwelche Probleme bei der Berechnung des DC zu korrigieren.

[danberg]

Hallo,

Da muss ich wohl noch etwas klarstellen. Werte von 1-2% hatte ich mit der CCU2 nicht, die lagen schon immer bei 5-8% (im 'Ruhezustand'). Die 1-2%-Werte auf meinem Bild betreffend CCU2 stammen noch von der RaspberryMatic da ich ja ein Backup zurückgespielt hatte.

Ich hatte auch gehofft, dass sich das mit dem nächsten Update wieder legt, bis ich die Antwort von eq3 gelesen habe.

Was ich mir auch nicht erklären kann wieso der DC eine halbe Stunde lang nach Reboot noch steigt, eigentlich müsste er nach dem 'Reboot-Feuer', ich sage jetzt einmal nach 5Min., wieder beginnen zu sinken (auf der CCU2 steigt er zwar nicht, sinkt aber eine halbe Stunde auch nicht).

Desweiteren kann ich bezüglich Funkmodul zu meiner Situation nur sagen, dass ich überrascht war wie gut das funktioniert (nach den 'negativen' Berichten hier). Rechnete schon damit, dass ich eine der besseren Antennen basteln muss. War aber nicht nötig, denn die RSSI-Werte liegen weiterhin alle im 'grünen Bereich' (habe bis auf zwei mit -85dbm und -86dbm alle besser als -80dbm) und auch die Servicemeldungen haben nicht zugenommen (ich weiss, sind alles 'nicht belastbare Aussagen' aber Fakten die ich als User nun einmal feststelle).

[Pietro]

Hi,

bin gestern von der 2.25.15 auf die 2.27.8er umgestiegen.
Auch wenn Jens nicht daran glaubt, für mich sehen nun die duty-cycles der CCU wieder deutlich realistischer (höher) aus, als mit der 2.27.2er.

Hier meine Duty-Cycles mit der original CCU2 vom Februar:

Hier der Vergleich zwischen Raspberrymatic 2.25.15 und 2.27.8 (der Peak ist die Einschwingphase nach dem ersten Reboot mit der 2.27.8er):

Sprich, der CCU-Duty-Cycle liegt nun wieder in etwa wieder auf dem selben Niveau wie bei der CCU2.

lg Pietro

[jmaus]

bin gestern von der 2.27.2 auf die 2.27.8er umgestiegen.
Auch wenn Jens nicht daran glaubt, für mich sehen nun die duty-cycles der CCU wieder deutlich realistischer (höher) aus, als mit der 2.27.2er.

Ich schätze mal du meinst die 2.27.7 und nicht die 2.27.2, oder? Und warum sollte ich das nicht glauben?

Hier meine Duty-Cycles mit der original CCU2 vom Februar:
[...]

Hier der Vergleich zwischen Raspberrymatic 2.27.2 und 2.27.8 (der Peak ist die Einschwingphase nach dem ersten Reboot mit der 2.27.8er):
[...]
Sprich, der CCU-Duty-Cycle liegt nun wieder in etwa wieder auf dem selben Niveau wie bei der CCU2.

Danke für diesen sehr guten Vergleich. Das zeigt also das der DutyCycle in RaspberryMatic in etwa so groß ist wie bei einer CCU2 mit der gleichen Konfiguration. D.h. das der DutyCycle in vorherigen RaspberryMatic Versionen immer < 5% war und fast nie über die 20-30% hinausgegangen ist zeigt das das wohl ein Bug war der nun beseitigt ist. Dann gibt es nun also wie es aussieht kein wirkliches Problem, oder?

[nicolas-eric]

Falls es hilft.
Bei mir ist der DC zwischen RaspiMatic 2.27.7 und 2.27.8 gleich geblieben.

[jmaus]

Falls es hilft.
Bei mir ist der DC zwischen RaspiMatic 2.27.7 und 2.27.8 gleich geblieben.

Das hatte ich nicht anders erwartet denn die Funkmodul-Firmware hat sich hier nicht geändert. Wichtig ist nur ob sie im Verhältnis zu einer CCU2 mit gleichem CCU-Firmwareversionsstand wesentlich höher/niedriger ist.

[nicolas-eric]

Aaaah ok, da hab ich nicht drauf geachtet, die CCU ist nun mittlerweile auch schon verkauft.

[Pietro]

bin gestern von der 2.27.2 auf die 2.27.8er umgestiegen.
Auch wenn Jens nicht daran glaubt, für mich sehen nun die duty-cycles der CCU wieder deutlich realistischer (höher) aus, als mit der 2.27.2er.

Ich schätze mal du meinst die 2.27.7 und nicht die 2.27.2, oder? Und warum sollte ich das nicht glauben?

Sorry, meinte die 2.25.15 - hab es im ursprünglichen Beitrag nun korrigiert.
Und hier hattest Du bei der 2.27.7er gemeint, dass der erhöhte CCU-Dutycycle womöglich auf einen Bug (zu hoch berechnet) zurückzuführen ist.
viewtopic.php?f=65&t=34497&p=351320&hil ... le#p351320

Danke für diesen sehr guten Vergleich. Das zeigt also das der DutyCycle in RaspberryMatic in etwa so groß ist wie bei einer CCU2 mit der gleichen Konfiguration. D.h. das der DutyCycle in vorherigen RaspberryMatic Versionen immer < 5% war und fast nie über die 20-30% hinausgegangen ist zeigt das das wohl ein Bug war der nun beseitigt ist. Dann gibt es nun also wie es aussieht kein wirkliches Problem, oder?

Gern - bin ich jedenfalls happy und aus meiner Sicht passt alles !

[schneidy76]

Und ich bin zu blöd mir den als Sysvar anzeigen zu lassen. Ich krieg es nicht hin...

[nicolas-eric]

Systemvariable Typ Zahl 1-100
Nehmen wir an, die heisst DUTYCYCLESV.

Dann ein Programm, das alle paar Minuten startet und das dann dieses Script ausführt:

Code: Alles auswählen

! DutyCycle CCU mit HM Script und CUxD.exec (c) by Alchy v 0.1
dom.GetObject("CUxD.CUX2801001:1.CMD_SETS").State("echo 'load tclrpc.so; puts [xmlrpc http://127.0.0.1:2001/ listBidcosInterfaces ]'|tclsh |grep -o 'DUTY_CYCLE.[0-9]*.'");
dom.GetObject("CUxD.CUX2801001:1.CMD_QUERY_RET").State(1);
if (dom.GetObject(ID_SYSTEM_VARIABLES).Get("DUTYCYCLESV")){dom.GetObject(ID_SYSTEM_VARIABLES).Get("DUTYCYCLESV").State((dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State().StrValueByIndex(" ",1)).ToFloat());} 
!WriteLine((dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State().StrValueByIndex(" ",1)).ToFloat());