RaspberryMatic - Verbesserungsvorschläge/Wünsche

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

MichaelN
Beiträge: 3814
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 304 Mal
Danksagung erhalten: 544 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche

Beitrag von MichaelN » 17.11.2021, 13:50

Ich denke Jens meint nicht dass die neue Oberfläche wie vorher aussehen soll, sondern eher das das grundsätzliche Layout erhalten bleibt. Ob die Spalte nun etwas breiter oder schmaler ist, egal. Hauptsache das Konzept z. b. links in der Spalte ein Gerät auswählen und rechts werden die Details angezeigt bleibt erhalten.
So würde ich das interpretieren.
Also das Bedienkonzept bleibt gleich nur mit modernen Look.
Oder gibt es Dinge die du komplett anders umsetzen würdest?
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

Benutzeravatar
jmaus
Beiträge: 7884
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 269 Mal
Danksagung erhalten: 973 Mal
Kontaktdaten:

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche

Beitrag von jmaus » 17.11.2021, 14:12

ptweety hat geschrieben:
17.11.2021, 13:37
jmaus hat geschrieben:
17.11.2021, 11:17
Worauf wir uns aber noch einigen müssten wäre, welches stilistische Ziel wir bei dem Redesign ansetzen sollten/wollen? Dein Prototyp gefällt mir bereits sehr gut und ich finde es super wenn wir uns am Layout der bestehenden WebUI weiterhin orientieren könnten genau wie das auch in deinem Prototypen zu sehen ist. D.h. jetzt nicht komplett das gesamte Layout-Konzept auf den Kopf zu stellen und gar was komplett neues zu schaffen. Die Bereicheinteilung, das Layout und die Grundfunktionalität sollten IMHO weiterhin so bestehen bleiben und im Grunde "nur" eben Bootstrap für die CSS repräsentation eingesetzt werden um damit ein moderneren Look&Feel abzuliefern. Wenn wir uns darauf einigen könnten wäre das super.
Da bin ich bei dir. Ein Einwurf wäre mir aber auch wichtig: ein Framework wie Bootstrap verwendet man ja wegen der bereitgestellten Komponenten (um sich die Arbeit des Selbermachen zu sparen) und Utilities. Im Zweifel würde ich also immer auf diese Komponenten und vorgesehenAnpassungen im Rahmen des Frameworks setzen, anstatt was eigenes zu stricken, nur damit es genau so wie die WebUI aussieht
Da hast du mich in der Tat etwas missverstanden. Natürlich sollten/müssen wir alle möglichen GUI Elemente (wie z.B. bereits mit den progressbars geschehen) gegen Bootstrap varianten ersetzen. Nur das Bedienkonzept (Hauptmenüleiste oben, Status und Bedienung links, Einstellunge rechts, Nutzung von modalen Popups, usw.) sollte sich an der Struktur und Bedienkonzept der alten WebUI anlehnen. So meinte ich das.
ptweety hat geschrieben:
17.11.2021, 13:37
jmaus hat geschrieben:
17.11.2021, 11:17
Die Frage wäre aber weiterhin, was machen wir mit deinem PR? In der jetzigen Form wäre dieser ja nicht in die existierende WebUI integrierbar, weil damit IMHO zuviele Styleänderungen einhergehen die das prinzipielle Aussehen der WebUI verändert. Meines Erachtens sollten wir vielleicht in einem separaten Branch im RaspberryMatic Repository arbeiten und dort die WebUI Anpassungen bzgl. Bootstrap und deinen Styleänderungen integrieren und dort auch weiter gemeinsam dran arbeiten. Für diesen Branch könnte ich dann gerne auch separate nightly snapshots bereitstellen damit wir - aber auch interessierte Dritte - da Feedback geben könnten und vielleicht sich so auch der Kreis der interessierten Mitentwickler an diesem WebUI Redesign potentiell steigt.
Das wäre sicher ein guter Weg. Insbesondere da es auch einer Menge Tests bedarf.
Ok, wie wäre dann das nächste vorgehen deiner Meinung? Ich kann den entsprechden WebUIv2 branch anlegen und dann schickst du in zukunft einfach PullRequests darauf basierend ein und arbeitest in deinem Fork auch darin die Anpassungen ein, dann kann ich darauf folgenden dann die nightly builds generieren lassen, usw.
ptweety hat geschrieben:
17.11.2021, 13:37
Apropos Test: ich bräuchte eine vernünftige Test-Umgebung mit einer Menge an Test-Fällen. Heißt: ein Backup mit möglichst vielen unterschiedlichen Geräten, Programmen und ..., welches ich (und evtl. jeder Andere auch) zum testen und entwickeln nutzen könnte. Haben wir sowas schon irgendwo mal diskutiert und geteilt?
Solch eine Testumgebung mit umfangreichen Geräten (aus der BidCos, HmIP, HmIP-Wired, CUxD Welt) + Programmen, usw. wäre in der Tat sehr hilfreich. Vielleicht könnte sich jemand drittes ja einmal daran machen solch eine Testkonfiguration (mit Hilfe von "implantierten" Geräten" fertig zu machen)? Oder jemand schafft es doch einmal eine Art WebUI/CCU Simulation zu basteln. hobbyquaker hat diesbzgl. bereits einmal nodejs sachen gebaut um Interfaces zu simulieren usw. Aber das wäre jetzt vmtl. etwas zuviel des guten bzw. zuviel vorarbeit. Vllt. reicht es auch wenn jemand seine umfangreiche Grundkonfiguration einfach exportieren und dann nochmal datenschutzbereinigt und erweitert durch Testprogramme usw. allen bzw. im GitHub zur Verfügung stellen könnte. Freiwillige?
RaspberryMatic 3.61.5.20211113 @ ESXi – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

Benutzeravatar
Baxxy
Beiträge: 4679
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 314 Mal
Danksagung erhalten: 857 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche

Beitrag von Baxxy » 17.11.2021, 16:38

Bezüglich Testumgebung:
Für erste Tests würden wohl die CUxD-Geräte gut funktionieren.
Oder auch eine HM-Heizgruppe die sich auch ohne Funkmodul anlegen lässt.

Echte Geräte, egal ob HM oder IP bringen nicht viel wenn sie nicht auch tatsächlich vorhanden sind.

Grüße, Baxxy

Benutzeravatar
jmaus
Beiträge: 7884
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 269 Mal
Danksagung erhalten: 973 Mal
Kontaktdaten:

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche

Beitrag von jmaus » 17.11.2021, 17:03

Baxxy hat geschrieben:
17.11.2021, 16:38
Bezüglich Testumgebung:
Für erste Tests würden wohl die CUxD-Geräte gut funktionieren.
Oder auch eine HM-Heizgruppe die sich auch ohne Funkmodul anlegen lässt.

Echte Geräte, egal ob HM oder IP bringen nicht viel wenn sie nicht auch tatsächlich vorhanden sind.
Deshalb sagte ich ja, es wäre sicherlich von vorteil wenn es irgendeine möglichkeit geben würde
  1. Jede beliebige Geräteart/typ virtuell in der WebUI anlegen zu können
  2. ggf. einen fake-rfd bzw. fake-hmipserver zu haben der die existenz dieses Gerätes irgendwie vorgaukelt.
Punkt 1 wäre sicherlich irgendwie möglich (CUxD macht das ja auch irgendwie), aber Punkt 2 würde eben dauern bzw. wäre zu kompliziert für den Moment.
RaspberryMatic 3.61.5.20211113 @ ESXi – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

ptweety
Beiträge: 368
Registriert: 07.01.2017, 16:48
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 17 Mal
Danksagung erhalten: 23 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche

Beitrag von ptweety » 17.11.2021, 18:00

Ich hätte fast sowas wie den Dummy Beacon von Jérôme in Software erhofft ;)

ptweety
Beiträge: 368
Registriert: 07.01.2017, 16:48
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 17 Mal
Danksagung erhalten: 23 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche

Beitrag von ptweety » 17.11.2021, 18:26

jmaus hat geschrieben:
17.11.2021, 14:12
Ok, wie wäre dann das nächste vorgehen deiner Meinung? Ich kann den entsprechden WebUIv2 branch anlegen und dann schickst du in zukunft einfach PullRequests darauf basierend ein und arbeitest in deinem Fork auch darin die Anpassungen ein, dann kann ich darauf folgenden dann die nightly builds generieren lassen, usw.
Ja, wäre gut, wenn du schonmal die Infrastruktur anlegen kannst:
  • Branch anlegen
  • Build Toolchain dafür aufbauen
Was mir noch ein wenig Kopfzerbrechen bereitet, sind diese Punkte:
  • Die bestehenden WebUI-Patches sind ja so aufgebaut, das EQ3 per Cherry-Picking beliebige Teile in die Original Firmware einbauen kann. Wenn ein solcher Patch für eine neue WebUI angepasst werden muss (ein Patch des Patches) ... wie soll das strukturiert werden?
  • Die bestehenden Addons verlassen sich auch auf eine gewisse Struktur (und sind meist mit RM und original-FW) kompatibel. Wie gehen wir mit breaking changes für diese Addons um? Ist hier Rückwärts-Kompatibilität oberstes Ziel? Und welche Addons müsste sich mal besonders anschauen? Da fällt mir spontan natürlich wieder die Arbeit von Jérôme ein und damit das ganze HB-Ökosystem ... oder ProgrammeDrucken oder ...
  • Wie wird der Branch einigermaßen in Synch mit dem Main-Branch gehalten?

Benutzeravatar
Frosch63
Beiträge: 73
Registriert: 25.05.2020, 15:36
System: Alternative CCU (auf Basis OCCU)
Wohnort: Sektor 001
Hat sich bedankt: 5 Mal
Danksagung erhalten: 8 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche

Beitrag von Frosch63 » 18.11.2021, 18:33

Hallo,

ich hätte gern die Möglichkeit z.B. in "Startseite > Einstellungen > Geräte" den Tabellenkopf inkl. Filter
fixieren zu können.

Grüße vom Frosch
RaspberryMatic auf Raspberry Pi 3B mit RPI-RF-MOD
549 Kanäle in 77 Geräten und 96 CUxD-Kanäle in 6 CUxD-Geräten

ptweety
Beiträge: 368
Registriert: 07.01.2017, 16:48
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 17 Mal
Danksagung erhalten: 23 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche

Beitrag von ptweety » 19.11.2021, 08:09

Die WebUI berechnet sich die Höhe und Breite einzelner Bereiche ja beim Start und jeder Änderung an der Fenstergröße selber neu. Dazu werden onResize und weitere resize() Methoden aufgerufen.

Gibt es dafür (insbesondere in modernen Browsern) noch einen guten Grund es so zu tun?

Ich fände es gut, wenn dies auf die Nutzung einfacher CSS-Regeln umgestellt wird.

Ref:

Code: Alles auswählen

  onResize: function()
  {
    var height       = WebUI.getHeight();
    var width        = WebUI.getWidth();
    var bodyOverflow = "hidden";

    if (width  < this.MIN_WIDTH)  { width  = this.MIN_WIDTH;  bodyOverflow = "auto"; }
    if (height < this.MIN_HEIGHT) { height = this.MIN_HEIGHT; bodyOverflow = "auto"; }
    var contentHeight = height - this.STATIC_HEIGHT;

    if ($("body"))    { Element.setStyle("body", {"overflow": bodyOverflow, "width": width  + "px", "height": height + "px"}); }
    if ($("header"))  { Element.setStyle("header" , {"height": this.HEADER_HEIGHT  + "px", "width": width + "px"}); }
    if ($("menubar")) { Element.setStyle("menubar", {"height": this.MENUBAR_HEIGHT + "px", "width": width + "px"}); }
    if ($("content")) { Element.setStyle("content", {"height": contentHeight       + "px", "width": width + "px"}); }
    if ($("footer"))  { Element.setStyle("footer" , {"height": this.FOOTER_HEIGHT  + "px", "width": width + "px"}); }

    if (this.currentPage) { this.currentPage.resize(); }

    if(typeof dcTimeout == "undefined") {
      dcTimeout = window.setTimeout(function () {
        showDutyCycle();
        delete dcTimeout;
      }, 10);
    }
  },

Benutzeravatar
jmaus
Beiträge: 7884
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 269 Mal
Danksagung erhalten: 973 Mal
Kontaktdaten:

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche

Beitrag von jmaus » 19.11.2021, 09:12

ptweety hat geschrieben:
19.11.2021, 08:09
Die WebUI berechnet sich die Höhe und Breite einzelner Bereiche ja beim Start und jeder Änderung an der Fenstergröße selber neu. Dazu werden onResize und weitere resize() Methoden aufgerufen.

Gibt es dafür (insbesondere in modernen Browsern) noch einen guten Grund es so zu tun?

Ich fände es gut, wenn dies auf die Nutzung einfacher CSS-Regeln umgestellt wird.
Witzig. Da fällt mir gleich der Spruch "Zwei Dumme, Ein Gedanke" ein :D Denn ich hatte vor kurzem als ich an der WebUI hier+da gebastelt hatte und auch diese onResize() usw. Funktion anpassen musste die gleichen "Warum zur XXXX wird das so gemacht?" Gedanken. Aber dann habe ich es wieder besseren Wissens einfach so belassen. Angefasst hatte ich die weil das Resize bei "Status und Bedienung -> Geräte/Gewerke/Räume" nicht in dem gesplitteten bereich (Links die Liste, rechts die Details) korrekt funktioniert hatte bzw. gar nicht. Da wurde bisher (und wird noch in der originalen CCU3 Firmware) einfach nicht der Bereich vergrößert und man musste immer ein reload machen. Und da hatte ich mich eben schon gefragt warum das überhaupt so aufwenig via JS gemacht wird statt dem Browser bzw. CSS sowas komplett zu überlassen?!?

Deshalb sage ich da vollmundig, das du das gerne abändern kannst und wenn es möglich ist dieses ganze onResize vollumfänglich wegrationalisieren kannst wenn du einen Weg findest wie. Würde mich nicht wundern wenn dadurch die WebUI auch merklich schneller wird beim resizen, eben weil dieser ganze Eventhandler dann nicht unnötig belastet wird und er dynamisch dann <div> elemente vergrößert usw.

Also ja, bitte dieses ganze dynamische resizing eliminieren, wenn du weisst wie :mrgreen:
RaspberryMatic 3.61.5.20211113 @ ESXi – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

schweiger2
Beiträge: 66
Registriert: 14.03.2018, 08:48
Danksagung erhalten: 1 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche

Beitrag von schweiger2 » 19.11.2021, 11:37

Hallo zusammen,

nach dem heutigen Homematic-Update (Raspberrymatic 3.61.5.2021-11-19) als Proxmox-VM zeigt das ioBroker-Log folgende Fehlermeldungen. Die Steuerung der Homematic-Komponenten über ioBroker funktioniert dann auch nicht.

Code: Alles auswählen

2021-11-19 09:18:26.502 - info: host.iobroker Restart adapter system.adapter.hm-rpc.1 because enabled
2021-11-19 09:18:56.529 - info: host.iobroker instance system.adapter.hm-rpc.1 started with pid 5172
2021-11-19 09:18:57.695 - info: hm-rpc.1 (5172) starting. Version 1.14.50 in /opt/iobroker/node_modules/iobroker.hm-rpc, node: v14.18.1, js-controller: 3.3.19
2021-11-19 09:18:57.915 - info: hm-rpc.1 (5172) xmlrpc server is trying to listen on 192.168.178.40:2010
2021-11-19 09:18:57.916 - info: hm-rpc.1 (5172) xmlrpc client is trying to connect to 192.168.178.20:2010/ with ["http://192.168.178.40:2010","iobroker:hm-rpc.1"]
2021-11-19 09:18:57.942 - error: hm-rpc.1 (5172) Init not possible, going to stop: Unknown XML-RPC tag 'TITLE'
2021-11-19 09:19:27.934 - error: hm-rpc.1 (5172) Init not possible, going to stop: Unknown XML-RPC tag 'TITLE'
2021-11-19 09:19:27.943 - info: hm-rpc.1 (5172) xmlrpc -> 192.168.178.20:2010/ init ["http://192.168.178.40:2010",""]
2021-11-19 09:19:27.954 - error: hm-rpc.1 (5172) Cannot call init: [http://192.168.178.40:2010, ""] Unknown XML-RPC tag 'TITLE'
2021-11-19 09:19:27.961 - info: hm-rpc.1 (5172) terminating
2021-11-19 09:19:27.962 - info: hm-rpc.1 (5172) Terminated (NO_ERROR): Without reason
Nach Rücksprung auf die vorherige Version ist wieder alles i.O.
Worauf ist dieser Fehler zurückzuführen ? Bin ich der einzige Betroffene ?
Ich habe das auch im ioBroker-Forum als Frage eingestellt - ich weiß nicht, wohin diese Frage genau gehört.

Beste Grüße

Antworten

Zurück zu „RaspberryMatic“