Hat hier keine eine Idee zu?MrPetz hat geschrieben: ↑03.05.2024, 22:00Hallo zusammen,
ich weiß nicht ob dies das richtige Forum für meine Frage ist, aber ich versuche es mal.
Ich habe hier eine recht umfangreiche Installation gesteuert über Raspberrymatic 3.75.7.20240420.
Nun habe ich einen neuen HMIP-RGBW Controller eingebunden.
Diesen kann ich über die Oberfläche Steuern und alles ist gut.
Wenn ich diesen aber aus einem Programm ansteuern will habe ich nur „Kanalaktion“ und eine Zahl von 1000 – 10200 K zur Auswahl.
Ich habe den Aktor schon gelöscht und wieder hinzugefügt, alles ohne Erfolg.
Ich müsste diesem doch Dimm-Zeiten, Helligkeitswerte usw. mitteilen können?
Hat jemand eine Idee wo hier der Fehler liegen könnte?
Danke schon mal für eure Hilfe!
...
Kleines Update:
Wenn ich den Controller neu anlerne und direkt ein Programm schreibe, ist der Kanal konfigurierbar.
Auffällig ist, nach „Kanalaktion“ kommt ein langes Feld auf das ich klicken kann um Einstellungen vorzunehmen.
Ab dem 2. Kanal kommt nach dem „Kanalaktion“ ein kusives „auf“ und das Wertefeld ist klein mit einer 1 die ich dann nur in 1000 – 10200 K ändern kann.
Ab dann keine Chance mehr etwas einzustellen bis zum nächsten Reset und neu anlernen des Controllers.
Das kann doch nur ein Bug sein?
RaspberryMatic 3.75.7.20240420 – Neue Version
Moderatoren: jmaus, Co-Administratoren
Re: RaspberryMatic 3.75.7.20240420 – Neue Version
Rasberrymatic auf Pi3+ mit 654 Kanäle in 139 Geräten.
ioBroker als Midware auf Proxmox.
ioBroker als Midware auf Proxmox.
-
- Beiträge: 12440
- Registriert: 19.03.2014, 00:37
- System: in Planung
- Hat sich bedankt: 105 Mal
- Danksagung erhalten: 380 Mal
Re: RaspberryMatic 3.75.7.20240420 – Neue Version
Da auch diese Version auf Odroid-C4 nicht startet, habe ich einen Bug-Report auf Github erstellt -> keine Umschaltung auf die Startseite.
https://github.com/jens-maus/RaspberryMatic/issues/2740
Im Gegensatz zur 3.75.6.20240316 startet Odroid N2 problemlos.
Danke
Gruß
Bruno
EDIT: Ist schon erledigt und im Nigthly verfügbar, alternativ neue Version abwarten ... danke Jens.
C4 läuft wieder.
https://github.com/jens-maus/RaspberryMatic/issues/2740
Im Gegensatz zur 3.75.6.20240316 startet Odroid N2 problemlos.
Danke
Gruß
Bruno
EDIT: Ist schon erledigt und im Nigthly verfügbar, alternativ neue Version abwarten ... danke Jens.
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
C4 läuft wieder.
-
- Beiträge: 5
- Registriert: 30.11.2020, 16:58
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 1 Mal
Re: RaspberryMatic 3.75.7.20240420 – Neue Version
Ich nutzte seit vielen Jahren RaspberryMatic auf einem Tinkerboard S. Ich würde mein System als "eingeschwungenes System" bezeichnen, an dem sich (von meiner Seite) nicht mehr viel ändert. Zur groben Orientierung: Ich habe 45 "alte" Homematic-Geräte, 33 virt. CUX-Geräte und (nur) 7 HMIP-Geräte in Betrieb. Zudem nutze ich ioBroker für Visualisierung und (herstellerübergreifender) Steuerung. Die Steuerung innerhalb CCU habe ich wenn möglich als Direktverknüpfungen ausgelegt und wenn (zumindest mir) nicht möglich, für "kritische" Komponenten als CCU-Programme implementiert. (etwas OT: ich komme nicht sooo gut mit HM-Script klar; JavaScript im ioBroker fällt mir irgendwie leichter. Allerdings habe ich nicht jedes Programm migriert, wenn eine (größere) Änderung ansteht, portiere ich das aber von HM-Scrip auf ioBroker - mit den genannten Ausnahmen)
Da ich das System eher produktiv nutze, warte ich gerne etwas ab, bevor ich auf die jeweils neue Version gehe. Weil es hier etwas widersprüchliche Rückmeldungen gab, hatte ich zunächst gewartet. Nach Jens' Bitte habe ich aber gestern den Sprung "gewagt", da ich mit den vorherigen Versionen auch keine Probleme hatte. Nach einem halben Tag und grobem Durchtesten (sicher nicht aller Funktionen) kann ich sagen, dass mein System bislang gewohnt stabil läuft. Der DC liegt i.d.R bei 3% für die CCU und ca. 1% bei meinem LGW (als solches konfigurierte alte CCU2).
Einzige Situation, bei der der DC reproduzierbar ansteigt (vollkommen nachvollziehbar und unabhängig von der RM-Version), ist wenn meine Waschmaschine läuft. Hier nutze ich einen HMIP-PSM mit einer Direktverknüpfung zu einem HmIP-SCI, mit dem ich die manuelle Betätigung des Rückschlagventils kontrolliere (die WaMa steht knapp unterhalb der Kanalebene und hat keine eigene Hebepumpe, sondern pumpt eigenständig in den Kanal - mit zwischengeschaltetem Rückschlagventil, das auch manuell betätigt werden kann; das machen wir bei längerer Abwesenheit, dann soll aber die WaMa gar nicht starten, weil sie dann nicht abpumpen kann - natürlich wurde das nach dem Urlaub schon vergessen...)
Außerdem steuere ich damit auch die "fertig"-Meldung der WaMa.
Die Konfiguration des PSM hat einiges an try&error benötigt. Stellt man die Parameter zu großzugig ein, schießt der DC nach oben. Ist man zu konservativ, ist die Steuerung (des Fortschritts) zu instabil. Das nur als Hinweis für DC-Geplagte...
Ich persönlich bin nicht so ein großer Freund von HM-IP. Einerseits durch meine eigenen Erfahrungen mit den 7 Komponenten, andererseits durch das, was man hier so liest (z.B. Rollladen-Steuerung).
Wenn ich mir dann noch den Trend anschaue, den eq-3 einschlägt, frage ich mich schon, wie die Zukunft der CCU-(Derivate) aussieht. Denn mein System läuft stabil und ich wüsste auch nicht ad hoc, auf was ich das alles migrieren sollte - von den Kosten mal ganz abgesehen. Und darum bin ich der Community hier und ganz besonders Jens Maus extrem dankbar, dass es dieses Projekt gibt. Sorry für das lange OT, aber das wollte ich auch mal loswerden (verbunden mit einer kleinen Spende an Jens).
Nochmal vielen Dank für die ganze in der Freizeit geleistete Arbeit!
Jens (nicht Maus)
![Smile :)](./images/smilies/icon_smile.gif)
- mototeacher
- Beiträge: 352
- Registriert: 28.11.2013, 22:41
- Wohnort: Idstein
- Hat sich bedankt: 27 Mal
- Danksagung erhalten: 24 Mal
Re: RaspberryMatic 3.75.7.20240420 – Neue Version
Hallo Jens,
nur weil ich hier zufällig vorbei schneie..
Ja, ich bin ziemlich Linux unerfahren
Ja, ich beobachte einen ziemlich hohen DC nach einem Neustart, habe mir aber bis jetzt nicht die Mühe gemacht, zu testen, wie lange das anhält.
Ich beobachte seit einiger Zeit, dass beim ersten Aufruf die GUI im Browser das Fenster etliche Sekunden (5) leer bleibt, bis die Startseite auftaucht. Ein zweiter, paralleler Aufruf hängt dann oft mit kreisender "Eieruhr" bis zum manuellen Refresch.
Nein, früher - was auch immer das bedeutet - ist mir das in der Form nie so krass aufgefallen, hatte aber schon vor "längerer Zeit" einen Teil der DC-Last auf ein CCU2 LAN GW verlagert.
Letzter Neustart am 26.04.
Aktueller DC auf dem LGW 1% und auf der CCU 5% - aktuell schläft aber auch die ganze Heizungssteuerung
Ein Großteil meiner BidCos Komponenten liegt auf dem LGW.
Ich richte mir gerade ein Testsystem auf einem weiteren Tinker S ein, werde berichten, wenn mir was auffällt.
Gruß Uli
nur weil ich hier zufällig vorbei schneie..
Ja, ich bin ziemlich Linux unerfahren
Ja, ich beobachte einen ziemlich hohen DC nach einem Neustart, habe mir aber bis jetzt nicht die Mühe gemacht, zu testen, wie lange das anhält.
Ich beobachte seit einiger Zeit, dass beim ersten Aufruf die GUI im Browser das Fenster etliche Sekunden (5) leer bleibt, bis die Startseite auftaucht. Ein zweiter, paralleler Aufruf hängt dann oft mit kreisender "Eieruhr" bis zum manuellen Refresch.
Nein, früher - was auch immer das bedeutet - ist mir das in der Form nie so krass aufgefallen, hatte aber schon vor "längerer Zeit" einen Teil der DC-Last auf ein CCU2 LAN GW verlagert.
Letzter Neustart am 26.04.
Aktueller DC auf dem LGW 1% und auf der CCU 5% - aktuell schläft aber auch die ganze Heizungssteuerung
Ein Großteil meiner BidCos Komponenten liegt auf dem LGW.
Ich richte mir gerade ein Testsystem auf einem weiteren Tinker S ein, werde berichten, wenn mir was auffällt.
Gruß Uli
>500 Kanäle in ca. 100 Geräten / CCU2 als LAN GW / Tinker S mit 3.75.7.20240420 produktiv.
Weiterhin über Cat5 abgesetztes HM-MOD-RPI-PCB Modul zum optimalen Antennenstandort -
3 HmIP AP Systeme mit > 30 + 40 + 15 Komponenten aufgebaut und fortlaufender Support.
1 HmIP AP mit knapp 40 Komponenten (Klimaregelung in einem Appartmenthaus/FB Heizung)
Wärmebedarfssteuerung mehrerer Buderus Systeme über HM und HmIP
Administrator der neuen User Map v.2 https://t1p.de/HMmap
Weiterhin über Cat5 abgesetztes HM-MOD-RPI-PCB Modul zum optimalen Antennenstandort -
3 HmIP AP Systeme mit > 30 + 40 + 15 Komponenten aufgebaut und fortlaufender Support.
1 HmIP AP mit knapp 40 Komponenten (Klimaregelung in einem Appartmenthaus/FB Heizung)
Wärmebedarfssteuerung mehrerer Buderus Systeme über HM und HmIP
Administrator der neuen User Map v.2 https://t1p.de/HMmap
- Baxxy
- Beiträge: 11478
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 671 Mal
- Danksagung erhalten: 2433 Mal
Re: RaspberryMatic 3.75.7.20240420 – Neue Version
Hier auch noch mal der Hinweis das das Tinker-S mit aktuellem Nightly-Snapshot wieder "rund" laufen sollte.
Wäre natürlich super wenn der Ein oder Andere das mal testen könnte.
Siehe auch viewtopic.php?f=65&t=82395&start=30#p804755
Wäre natürlich super wenn der Ein oder Andere das mal testen könnte.
![Wink :wink:](./images/smilies/icon_wink.gif)
Siehe auch viewtopic.php?f=65&t=82395&start=30#p804755
Grüße... Baxxy
- Raspberry Pi 4 als Homematic-Zentrale - Tipps und Informationen
- Analysescript für genutzte Funk-Adressen, Funkmodul-Hardware und Zentralen Hardware
- NANO CUL 868MHz - Stick zum AskSin Analyzer XS umflashen (Anleitung für ArduinoIDE unter Windows)
- Firmware Updates für IP-Aktoren / Sensoren... Info's, Tipps und Sonstiges
- CCU funkt nicht - CarrierSense (CS) Probleme erkennen und lösen
-
- Beiträge: 74
- Registriert: 30.09.2014, 23:02
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 10 Mal
Re: RaspberryMatic 3.75.7.20240420 – Neue Version
Hallo zusammen.
Ich melde mich etwas spät, denn leider hat es meine Zeit bisher nicht erlaubt. Auch ich habe den hier schon ausgiebig besprochenen Effekt der schlechten Performance beim Tinkerboard S, und kann mir jetzt die Zeit nehmen, ein wenig zu berichten. Eins vorweg: Nachdem ich heute morgen diesen Thread hier "gefunden" habe, habe ich gleich das aktuelle Nightly eingespielt (3.75.7.20240522), und kann sagen, dass das Verhalten damit deutlich verbessert ist, evtl. auch ganz beseitigt - aber dazu habe ich noch nicht ausreichend getestet.
Nun zu meinem Setup und einigen Überprüfungen, die ich vorgenommen habe.
Meine Installation besteht aus 51 Geräten, überwiegend BidCos und ca. 10 Stk. HmIP. Dazu noch diverse Addons wie E-Mail, CUXD, CCU-Historian, Sonos Player, XML-API, Hue-Kopplung zu Philips Hue mit 10 Lampen, Alexa.sh, und auch die Remote-Kopplung via HConnect zu Alexa. Ich arbeite auch viel mit Programmen und Scripten darin, die auch externe Webseiten aufrufen (z.B. Wetterdaten, Thema Ampersand natürlich berücksichtigt) und diverse Werte in Systemvariablen schreiben (temporäre Logging-Funktion).
Nun zum Effekt:
Auch bei mir ist der Aufruf der GUI in der Performance grottig. Der Effekt ist, dass nach Aufruf der Klickibunti die Anzeige im Browser irgendwie blockiert/hängt, und die GUI nicht mehr weiter geladen und zur Anzeige gebracht wird. Manchmal hängt es direkt beim weißen oder auch beim blauen (ansonsten leeren) Bildschirm. Dann tut es ein F5-Browser-Refresh oder auch ein neuer Aufruf in einem neuen Browser-Tab (den alten geschlossen, Cache gelöscht). Das Blockieren dreht sich so um die Zeitdauer von 1-3 Minuten, bis man dann in der GUI ist. Hat man das hinter sich, ist die Bedienung ansonsten soweit ok, aber auch dann kommt es gelegentlich zu einem solchen "Hänger" der GUI (z.B. beim Editieren einer beliebigen Funktion in beliebigen Untermenüs - egal ob Geräte, Programme oder Favoriten). Interessant evtl. noch die Beobachtung, dass meist ein "Abmelden" über den Button rechts oben noch funktioniert, aber auch nicht immer.
Wobei das Hängenbleiben der GUI in dieser Form bei mir nicht unbedingt erst seit dem letzten Update ist. Ich kämpfe durchaus schon seit einigen Monaten mit dem Problem, aber seit der jüngsten Version Ende April 2024 ist der Effekt doch deutlich verstärkt.
Die CCU-Load ist in der Regel bei ~3%, geht manchmal auch leicht über 10% vermutlich wenn die Programme zum Parsen der Webaufrufe alle 10-15 Minunten mit Versatz laufen. Der DutyCyclce ist ebenfalls bei ruhigen 2-5%, bei Bedienung z.B. mehrerer Rolladen natürlich dann auch mal an die 20%. Der Carrier-Sense liegt bei 0-5%, springt ca. alle 10 Minuten kurzzeitig auf 10%, aber das führt nicht zu Verbindungsproblemen (den Störer dazu konnte ich leider noch nicht identifizieren). Die CCU-Kerntemperatur bewegt sich um die 55°, aber das Tinkerboard ist auch in einem geschlossenen Kunststoffgehäuse ohne Belüftung. Ich würde mal sagen, alle diese Betriebsparameter sind für die Größenordnung der Konfiguration normal.
Da ich hier im Forum schon genügend Hinweise zur Fehlersuche gefunden habe, habe ich natürlich auch zunächst in meiner Konfiguration gesucht:
- ALLE Programme deaktiviert
- ALLE "verdächtigen" Addons entfernt bzw. gestoppt (Historian)
Leider alles ohne Erfolg. GUI hängt immer noch sehr häufig beim ersten Aufruf, und geht nicht weiter als bis zum (leeren) weißen oder (leeren) blauen Bildschirm.
Der nächste Schritt war dann die Einrichtung des Monit-Tools (monit.cfg und Aufruf Port 2812).
- KEINER der laufenden Prozesse war auffällig in der CCU-Last. Auch mit häufigem Refresh bewegt sich alles deutlich unter 3-5%, ggfls. sporadisch mal kurz an die 10%.
Vielleicht noch anzumerken, dass sich das Performance-Thema ausschließlich auf das beschriebene Verhalten der GUI im Browser beschränkt. Die Automation meiner Scripte und Programme (nach Reaktivierung) und Addons ebenso wie die Remote-Bedienung via Alexa und HConnect (hatte ich natürlich auch im Auge) laufen durchaus flüssig und ohne merkliche Verzögerung. Interessant auch, dass z.B. die Monit-Anzeige nicht ähnlich blockiert im Browser (was aber auch am Anzeigemechanismus des Monit-Tools für den Browser liegen kann).
Die o.a. Nightly habe ich dann heute morgen eingespielt, und die GUI-Hänger waren damit im Nu beseitigt!!
Auch ist das Laden der GUI und auch Aufruf von Untermenüs gefühlt ca. 2 bis 3 mal so schnell, sofern man das überhaupt messen kann.
Meine Vermutung ist daher, dass die Blockade evtl. in dem Teil des Webservers für die GUI-Anzeige bzw. in der Generierung der Webseiten der GUI selbst liegt, der die Browseranfragen an die GUI bedient. Das alles aber nur Vermutung, denn Jens ist hat ja schon ein paar Modifikationen in der Nigthly untergebracht.
Vielleicht helfen meine doch etwas langatmigen Ausführungen hier, dem Problem auf die Spur zu kommen (sofern nicht schon erledigt).
Das Verhalten mit der Nightly werde ich jetzt noch weiter beobachten und untersuchen.
Und gerne teste ich auch noch ein paar Nightlys und auf Wunsch spiele ich entsprechende Testszenarien mit entsprechender Anweisung/Anleitung durch.
Ansonsten auch von mir hier ein Dankeschön an Jens für die unermüdliche Arbeit am ganzen Projekt.
Das erinnert mich auch wieder an einen Lizenz-Obulus.
MFG
schneider.obw
Ich melde mich etwas spät, denn leider hat es meine Zeit bisher nicht erlaubt. Auch ich habe den hier schon ausgiebig besprochenen Effekt der schlechten Performance beim Tinkerboard S, und kann mir jetzt die Zeit nehmen, ein wenig zu berichten. Eins vorweg: Nachdem ich heute morgen diesen Thread hier "gefunden" habe, habe ich gleich das aktuelle Nightly eingespielt (3.75.7.20240522), und kann sagen, dass das Verhalten damit deutlich verbessert ist, evtl. auch ganz beseitigt - aber dazu habe ich noch nicht ausreichend getestet.
Nun zu meinem Setup und einigen Überprüfungen, die ich vorgenommen habe.
Meine Installation besteht aus 51 Geräten, überwiegend BidCos und ca. 10 Stk. HmIP. Dazu noch diverse Addons wie E-Mail, CUXD, CCU-Historian, Sonos Player, XML-API, Hue-Kopplung zu Philips Hue mit 10 Lampen, Alexa.sh, und auch die Remote-Kopplung via HConnect zu Alexa. Ich arbeite auch viel mit Programmen und Scripten darin, die auch externe Webseiten aufrufen (z.B. Wetterdaten, Thema Ampersand natürlich berücksichtigt) und diverse Werte in Systemvariablen schreiben (temporäre Logging-Funktion).
Nun zum Effekt:
Auch bei mir ist der Aufruf der GUI in der Performance grottig. Der Effekt ist, dass nach Aufruf der Klickibunti die Anzeige im Browser irgendwie blockiert/hängt, und die GUI nicht mehr weiter geladen und zur Anzeige gebracht wird. Manchmal hängt es direkt beim weißen oder auch beim blauen (ansonsten leeren) Bildschirm. Dann tut es ein F5-Browser-Refresh oder auch ein neuer Aufruf in einem neuen Browser-Tab (den alten geschlossen, Cache gelöscht). Das Blockieren dreht sich so um die Zeitdauer von 1-3 Minuten, bis man dann in der GUI ist. Hat man das hinter sich, ist die Bedienung ansonsten soweit ok, aber auch dann kommt es gelegentlich zu einem solchen "Hänger" der GUI (z.B. beim Editieren einer beliebigen Funktion in beliebigen Untermenüs - egal ob Geräte, Programme oder Favoriten). Interessant evtl. noch die Beobachtung, dass meist ein "Abmelden" über den Button rechts oben noch funktioniert, aber auch nicht immer.
Wobei das Hängenbleiben der GUI in dieser Form bei mir nicht unbedingt erst seit dem letzten Update ist. Ich kämpfe durchaus schon seit einigen Monaten mit dem Problem, aber seit der jüngsten Version Ende April 2024 ist der Effekt doch deutlich verstärkt.
Die CCU-Load ist in der Regel bei ~3%, geht manchmal auch leicht über 10% vermutlich wenn die Programme zum Parsen der Webaufrufe alle 10-15 Minunten mit Versatz laufen. Der DutyCyclce ist ebenfalls bei ruhigen 2-5%, bei Bedienung z.B. mehrerer Rolladen natürlich dann auch mal an die 20%. Der Carrier-Sense liegt bei 0-5%, springt ca. alle 10 Minuten kurzzeitig auf 10%, aber das führt nicht zu Verbindungsproblemen (den Störer dazu konnte ich leider noch nicht identifizieren). Die CCU-Kerntemperatur bewegt sich um die 55°, aber das Tinkerboard ist auch in einem geschlossenen Kunststoffgehäuse ohne Belüftung. Ich würde mal sagen, alle diese Betriebsparameter sind für die Größenordnung der Konfiguration normal.
Da ich hier im Forum schon genügend Hinweise zur Fehlersuche gefunden habe, habe ich natürlich auch zunächst in meiner Konfiguration gesucht:
- ALLE Programme deaktiviert
- ALLE "verdächtigen" Addons entfernt bzw. gestoppt (Historian)
Leider alles ohne Erfolg. GUI hängt immer noch sehr häufig beim ersten Aufruf, und geht nicht weiter als bis zum (leeren) weißen oder (leeren) blauen Bildschirm.
Der nächste Schritt war dann die Einrichtung des Monit-Tools (monit.cfg und Aufruf Port 2812).
- KEINER der laufenden Prozesse war auffällig in der CCU-Last. Auch mit häufigem Refresh bewegt sich alles deutlich unter 3-5%, ggfls. sporadisch mal kurz an die 10%.
Vielleicht noch anzumerken, dass sich das Performance-Thema ausschließlich auf das beschriebene Verhalten der GUI im Browser beschränkt. Die Automation meiner Scripte und Programme (nach Reaktivierung) und Addons ebenso wie die Remote-Bedienung via Alexa und HConnect (hatte ich natürlich auch im Auge) laufen durchaus flüssig und ohne merkliche Verzögerung. Interessant auch, dass z.B. die Monit-Anzeige nicht ähnlich blockiert im Browser (was aber auch am Anzeigemechanismus des Monit-Tools für den Browser liegen kann).
Die o.a. Nightly habe ich dann heute morgen eingespielt, und die GUI-Hänger waren damit im Nu beseitigt!!
Auch ist das Laden der GUI und auch Aufruf von Untermenüs gefühlt ca. 2 bis 3 mal so schnell, sofern man das überhaupt messen kann.
Meine Vermutung ist daher, dass die Blockade evtl. in dem Teil des Webservers für die GUI-Anzeige bzw. in der Generierung der Webseiten der GUI selbst liegt, der die Browseranfragen an die GUI bedient. Das alles aber nur Vermutung, denn Jens ist hat ja schon ein paar Modifikationen in der Nigthly untergebracht.
Vielleicht helfen meine doch etwas langatmigen Ausführungen hier, dem Problem auf die Spur zu kommen (sofern nicht schon erledigt).
Das Verhalten mit der Nightly werde ich jetzt noch weiter beobachten und untersuchen.
Und gerne teste ich auch noch ein paar Nightlys und auf Wunsch spiele ich entsprechende Testszenarien mit entsprechender Anweisung/Anleitung durch.
Ansonsten auch von mir hier ein Dankeschön an Jens für die unermüdliche Arbeit am ganzen Projekt.
Das erinnert mich auch wieder an einen Lizenz-Obulus.
MFG
schneider.obw
- jmaus
- Beiträge: 9975
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 472 Mal
- Danksagung erhalten: 1952 Mal
- Kontaktdaten:
Re: RaspberryMatic 3.75.7.20240420 – Neue Version
Danke für deine Rückmeldungen. In der Tat sollten die Probleme nicht nur beseitigt sondern auch verstanden sein. Es liegt/lag an der Konfiguration des Linux kernel selbst dem eine config option gefehlt hat damit auch bei Geräten der Hardware ein Frequency Scaling passieren kann/konnte und das hat eben dazu geführt das an verschiedenen Stellen sich das Tinkerboard nicht so verhalten hat wie das sein sollte. Nun mit der zusätzlichen Konfigurationsoption sind die Probleme wieder weg und Tinkerboard-Nutzer sollten ab der nächsten version bzw. mit den nightly snapshots dann wieder die volle Geschwindigkeit des Tinkerboards haben.schneider.obw hat geschrieben: ↑22.05.2024, 10:22Meine Vermutung ist daher, dass die Blockade evtl. in dem Teil des Webservers für die GUI-Anzeige bzw. in der Generierung der Webseiten der GUI selbst liegt, der die Browseranfragen an die GUI bedient. Das alles aber nur Vermutung, denn Jens ist hat ja schon ein paar Modifikationen in der Nigthly untergebracht.
Vielleicht helfen meine doch etwas langatmigen Ausführungen hier, dem Problem auf die Spur zu kommen (sofern nicht schon erledigt).
RaspberryMatic 3.77.6.20240720 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ![☕️](//cdn.jsdelivr.net/emojione/assets/3.1/png/64/2615.png)
![☕️](http://cdn.jsdelivr.net/emojione/assets/3.1/png/64/2615.png)
- onkeltommy
- Beiträge: 1416
- Registriert: 07.05.2016, 08:03
- Wohnort: Wien
- Hat sich bedankt: 29 Mal
- Danksagung erhalten: 29 Mal
Re: RaspberryMatic 3.75.7.20240420 – Neue Version
Hi
wow, danke für den unermüdlichen Einsatz
eine Frage, habt ihr da auch bemerkt, dass da (wenn die Gui so runterbricht) die Rega abschmiert bzw die CPU auf Anschlag geht ? So ist es bei mir mit den letzten Versionen. Ich bin leider noch nicht dazu gekommen die neue Nightly zu testen, ist das Hochlaufen den Last damit vl auch schon im Griff durch Jens´ Maßnahmen ?
wow, danke für den unermüdlichen Einsatz
eine Frage, habt ihr da auch bemerkt, dass da (wenn die Gui so runterbricht) die Rega abschmiert bzw die CPU auf Anschlag geht ? So ist es bei mir mit den letzten Versionen. Ich bin leider noch nicht dazu gekommen die neue Nightly zu testen, ist das Hochlaufen den Last damit vl auch schon im Griff durch Jens´ Maßnahmen ?
lG
Thomas
--------------------------
RaspberryMatic 3.75.7.20240601 @ TinkerS (Produktivsystem) & Historian @ SynologyVM & 2x RB3+ @ Nachwuchs
Thomas
--------------------------
RaspberryMatic 3.75.7.20240601 @ TinkerS (Produktivsystem) & Historian @ SynologyVM & 2x RB3+ @ Nachwuchs
-
- Beiträge: 74
- Registriert: 30.09.2014, 23:02
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 10 Mal
Re: RaspberryMatic 3.75.7.20240420 – Neue Version
Hi zurück.
Wie ich beschrieben habe, sind bei mir keinerlei Funktionen des Systems im Hintergrund zusammengebrochen.
Das konnte ich m.E. auch durch die Überprüfung im MONIT bestätigen.
Meine Performance-Einbußen waren sichtbar/spürbar nur das Hängenbleiben beim Laden der Klickibunti.
Eine ReGa oder andere Module sind dabei auch niemals abgeschmiert; das hätte sich ja irgendwie bemerkbar gemacht.
Inwiefern das jetzt mit der Darstellung von Jens zur Fehlerursache zu tun hat, und diesen Effekt in der GUI hervorruft, hab ich bei den Ausführungen von Jens leider nicht verstanden. Aber ich muss auch nicht alles verstehen, sofern die Profis das in den Griff bekommen haben.
Danke dafür.
Und ich werde bei ggfls. weiteren Problemen gerne berichten.
Sieht aber mit den ersten Eindrücken gut aus.
Themen wie DutyCylce und CarrierSense waren bei mir in diesem Zusammenhang übrigens auch niemals Thema.
Da muss man als Laie ggfls. aufpassen, dass man nicht alles einfach unbedacht bzw. unstrukturiert in den gleichen Sack reinsteckt.
Danke nochmal an Jens.
Einfach Super Arbeit!
VG
schneider.obw
Wie ich beschrieben habe, sind bei mir keinerlei Funktionen des Systems im Hintergrund zusammengebrochen.
Das konnte ich m.E. auch durch die Überprüfung im MONIT bestätigen.
Meine Performance-Einbußen waren sichtbar/spürbar nur das Hängenbleiben beim Laden der Klickibunti.
Eine ReGa oder andere Module sind dabei auch niemals abgeschmiert; das hätte sich ja irgendwie bemerkbar gemacht.
Inwiefern das jetzt mit der Darstellung von Jens zur Fehlerursache zu tun hat, und diesen Effekt in der GUI hervorruft, hab ich bei den Ausführungen von Jens leider nicht verstanden. Aber ich muss auch nicht alles verstehen, sofern die Profis das in den Griff bekommen haben.
Danke dafür.
Und ich werde bei ggfls. weiteren Problemen gerne berichten.
Sieht aber mit den ersten Eindrücken gut aus.
Themen wie DutyCylce und CarrierSense waren bei mir in diesem Zusammenhang übrigens auch niemals Thema.
Da muss man als Laie ggfls. aufpassen, dass man nicht alles einfach unbedacht bzw. unstrukturiert in den gleichen Sack reinsteckt.
Danke nochmal an Jens.
Einfach Super Arbeit!
VG
schneider.obw
- jmaus
- Beiträge: 9975
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 472 Mal
- Danksagung erhalten: 1952 Mal
- Kontaktdaten:
Re: RaspberryMatic 3.75.7.20240420 – Neue Version
All das hängt meines Erachtens zusammen mit den generellen Performanceproblemen die es gegeben hat im bezug auf das Tinkerboard und die die Änderung im Linux kernel die angewendet habe behebt. Die aktuellen nightly snapshots sollten diese Probleme also nicht mehr haben. Da heisst es einfach "Probieren geht über Studieren...".onkeltommy hat geschrieben: ↑22.05.2024, 10:44eine Frage, habt ihr da auch bemerkt, dass da (wenn die Gui so runterbricht) die Rega abschmiert bzw die CPU auf Anschlag geht ? So ist es bei mir mit den letzten Versionen. Ich bin leider noch nicht dazu gekommen die neue Nightly zu testen, ist das Hochlaufen den Last damit vl auch schon im Griff durch Jens´ Maßnahmen ?
Das einzige was davon unbetroffen sein sollte ist natürlich die DC/CS "Problematik" die oft hier+da mit berichtet wurde. Das werden nur subjektive bzw. auf das jeweilige System bezogene Problematiken sein (meinst suboptimale Programmierung/WebUI Programme) wie man sie auch für die anderen Platformen oft hier vorgebracht sieht. Leider tendieren viele alles mögliche in den gleichen Topf zu werden. Man muss hier aber sehr vorsichtig alle probleme voneinander trennen bzw. auseinander dividieren um nicht gefahr zu laufen dieser herangehensweise auf dem Leim zu gehen... Wir wissen ja nicht erst seit dem Tinkerboard Performanceproblemen in den letzten Versionen das DC/CS Probleme eine Klasse für sich sind und zu 99% mit suboptimalen Programmierungen/Direktverknüpfungen/Geräteeinstellungen zusammenhängt und zu lediglich 1% mit irgendeinem Update von RaspberryMatic zusammenhängt...
RaspberryMatic 3.77.6.20240720 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ![☕️](//cdn.jsdelivr.net/emojione/assets/3.1/png/64/2615.png)
![☕️](http://cdn.jsdelivr.net/emojione/assets/3.1/png/64/2615.png)