Neue Release-Candidate/Test Version (3.47.10.20190712) verfügbar

[jp112sdl]

Allerdings würde ich das gerne via auslesen der Systemvariablen sehen und nicht so wie es eQ3 selbst angefangen hat zu implementieren, nämlich über separates auslesen via listBidCosInterface aufruf.

Was ist an der eQ-3 Variante nachteilig?
Es wird 1x listBidCosInterface angefragt und es werden alle Interfaces als Array zurückgeliefert.

[MathiasZ]

Mein Duty Cycle ist auf 51 Prozent angestiegen...........
das Log sagt nichts auffälliges.

So schaut er jetzt ca 30 Minuten später aus:

[darkbrain85]

Meine Installation hat sich jetzt mit der alten Version wieder beruhigt. Warum nur zwei Aktoren betroffen waren, kann ich mir nicht erklären. Der Zusammenhang mit dem Update ist aber nicht von der Hand zu weisen. Ein Dutycycle Problem kann ich allerdings genauso ausschließen. Die Zentrale lag im einstelligen Bereich, der Dimmer war beim Update seit vielen Stunden aus und hat direkt beim ersten Versuch die Lampe hoch zu dimmen eine Meldung gebracht...

Ich werde gleich mal so mutig sein, eine separate SD-Karte mit der neuen Version und dem Backup von gestern auszustatten. Mal sehen ob es diesmal wieder Probleme gibt...

[jmaus]

Allerdings würde ich das gerne via auslesen der Systemvariablen sehen und nicht so wie es eQ3 selbst angefangen hat zu implementieren, nämlich über separates auslesen via listBidCosInterface aufruf.

Was ist an der eQ-3 Variante nachteilig?
Es wird 1x listBidCosInterface angefragt und es werden alle Interfaces als Array zurückgeliefert.

Da gibt es meines Erachtens mehrere Nachteile:

• Löst der "listBidCosInterface" Aufruf eine Bearbeitung des Schnittstellenprozesses aus, ergo potentiell mehr Lastaufkommen
• Findet die listBidCosInterface Abfrage komplett im Browserkontext statt, d.h. hat man z.B. mehrere Browser/Tabs offen wird für jeden separat immer 1x pro minute eine Anfrage an den Schnittstellenprozess ausgelöst -> wieder erhöhtes Lastaufkommen.
• Gibt es die Information bei RaspberryMatic bereits in den jeweiligen "DutyCycle*" Systemvariablen und wird dort zyklisch über ein resourcenschonenderen cronjob 1x pro Minute abgefragt.
• Kann es dadurch zu Abweichungen zwischen den dargestellten Werten in der ProgressBar bzw. DutyCycle Systemvariablen kommen weil der Browser die Abfrage antizyklisch zu dem Abfrageinterval des cronjobs erledigt. Auch passiert das z.B. bei zwei unterschiedlichen Browserfenstern/Tabs. Auch dort können in beiden unterschiedliche Werte dargestellt werden je nachdem wann das Browserfenster/Tab geöffnet wurde.

Meines Erachtens ist es daher wesentlich sinnvoller (weil man die Information ohnehin bereits in den Systemvariablen hat) die Darstellung der DutyCycle ProgressBar an den Inhalt der Systemvariablen zu binden statt das Rad erneut erfinden zu wollen und eine zyklische ListBidCosInterface Abfrage durch den Webbrowser auslösen zu lassen. Und in der Tat habe ich das für die einzelne DutyCycle Anzeige des Funkmodulen so für RaspberryMatic auch bereits umgesetzt. Siehe hier:

https://github.com/jens-maus/RaspberryM ... play.patch

Wenn man das jetzt noch anhand deiner Anpassungen so erweitert das nicht nur der DutyCycle des Funkmoduls sondern auch der LAN Gateways dargestellt wird, wäre das IMHO perfekt.

[jp112sdl]

Ich hab das jetzt auf einer CCU2 implementiert. Daher kann ich dort nicht mit den Variablen arbeiten.
Der Vorteil ist hier für mich, dass man mit .each über alle Interfaces interieren kann...

Code: Alles auswählen

    homematic("Interface.listBidcosInterfaces", {"interface": ifaceBidCosRF}, function (interfaceStatus) {
      jQuery.each(interfaceStatus, function(index, iFace) {
      ...
  

Vielleicht geht das ja mit einer Art "startsWith("DutyCycle")" hier auch?

Code: Alles auswählen

homematic("SysVar.getValueByName", {"name": "DutyCycle"}, function(dcVal) {

Kenne mich in der JS-Welt programmiertechnisch nur ganz rudimentär aus.

Ich habe mal die Modifikationen in die OCCU-Files eingearbeitet und hier angehängt.

[jmaus]

Basierend auf den neuesten Erkenntnissen bzgl. WebUI Patch für das Energiezählerproblem in der WebUI der 3.47.10 firmware habe ich soeben eine neue Release-Candidate/Testversion (3.47.10.20190709) hochgeladen und würde bitten jeden interessierten Tester diese Version von dem kommenden finalen Release auch entsprechend durchzutesten. Der Link im ersten Beitrag dieses Threads ist immer noch gültig und von dort kann momentan eine aktualisierte rpi3 und Tinkerboard heruntergeladen werden.

Über entsprechendes Feedback würde ich mich wie immer freuen.

[sauss]

Basierend auf den neuesten Erkenntnissen bzgl. WebUI Patch für das Energiezählerproblem in der WebUI der 3.47.10 firmware habe ich soeben eine neue Release-Candidate/Testversion (3.47.10.20190709) hochgeladen und würde bitten jeden interessierten Tester diese Version von dem kommenden finalen Release auch entsprechend durchzutesten. Der Link im ersten Beitrag dieses Threads ist immer noch gültig und von dort kann momentan eine aktualisierte rpi3 und Tinkerboard heruntergeladen werden.

Über entsprechendes Feedback würde ich mich wie immer freuen.

Hab diese Version getestet und für gut empfunden! Zumindest gab es bis jetzt ... keine Auffälligkeiten... Somit großes Lob an alle die wieder viele graue Haare bekommen haben.

[LibertyX]

Gerade geflasht und restore durchgeführt, bis jetzt keine Auffälligkeiten.

[RO-Smart]

Basierend auf den neuesten Erkenntnissen bzgl. WebUI Patch für das Energiezählerproblem in der WebUI der 3.47.10 firmware habe ich soeben eine neue Release-Candidate/Testversion (3.47.10.20190709) hochgeladen und würde bitten jeden interessierten Tester diese Version von dem kommenden finalen Release auch entsprechend durchzutesten. Der Link im ersten Beitrag dieses Threads ist immer noch gültig und von dort kann momentan eine aktualisierte rpi3 und Tinkerboard heruntergeladen werden.

Über entsprechendes Feedback würde ich mich wie immer freuen.

Alles total problemlos. Habe jetzt auch nicht mehr die endlosen Hänger (nach Studium der Logdatei habe ich aber OpenHab auf NAS im Rahmen dieses Tests gestoppt, weil das evtl. die Ursache war). Einzige Besonderheit: DRAP ist aktiv aber ohne Anzeige der IP und der aktuellen Firmware-Versionen. Kommando zurück: Nach Stromlos setzen alles, wirklich alles in Ordnung.

[MathiasZ]

Update ohne nennenswerte Störungen durchgeführt.
Das Update ging schneller als das letzte zum 3.47.10.20190708
Gruß,
Mathias