Noch ein Grund mehr deine X86 Patches direkt als RaspberryMatic-x86 Paket herauszubringen
CCU-Repository
Moderator: Co-Administratoren
- jmaus
- Beiträge: 9902
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 466 Mal
- Danksagung erhalten: 1892 Mal
- Kontaktdaten:
Re: CCU-Repository
RaspberryMatic 3.75.7.20240420 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- jmaus
- Beiträge: 9902
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 466 Mal
- Danksagung erhalten: 1892 Mal
- Kontaktdaten:
Re: CCU-Repository
Tut mir leid, gerade keine Zeit dafür. Glaub dir das allerdings und werde es mir heute abend mal anschauen. Kannst du rausfinden bei welcjen Gerätetypen das auch noch auftritt?
Tut mir leid, das wird/muss erst einmal ins RaspberryMatic GitHub als ordentlicher WebUI patch damit das eQ3 geordnet und abgetrennt vom Rest vorgelegt werden kann denn du suchen sich hier nichts aus irgendwelchen GitHub Repositories selbst zusammen und akzeptieren auch keine PullRequests gegen ihr OCCU. Ich werde es aber bei der nächsten Telefonkonferenz ansprechen oder eine direkte Email an das Entwicklungsteam schreiben wenn ich den Fix fertig habe.Ps, das sollte ins occu-git
RaspberryMatic 3.75.7.20240420 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
-
- Beiträge: 518
- Registriert: 20.01.2011, 14:39
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 4 Mal
Re: CCU-Repository
Alles klar hier schließt sich auch der Kreis. Genau darum sollte wir ein aktuelles (mir egal welches) z.b. dein occu Repo auf den aktuellen Stand heben.
Nichts gegen das EQ3 Repo, aber es ist doch an mehreren Stellen bewiesen, dass das nicht ordentlich gepflegt wird.
Ist halt auch schwer fuer mich (oder allgemein fuer andere Hobby-Entwickler), wenn man kein echtes Repo hat, von dem man sauber wegentwickeln kann.
Soll auch kein Vorwurf sein! Nur ich hoffe die Situation verbessert sich.
Ps:
Ich hab jetzt dein occu geforkt und werde in Zukunft das nehmen. Ich werde versuchen aktuell zu sein und zu bleiben und auch das alte ganze Geruempel rauszuschmiessen. Ausserdem werde ich versuchen die Ordnerstruktur im git neu (imho korrekt) aufzubauen.
Mal schauen ob das klappt.
Nichts gegen das EQ3 Repo, aber es ist doch an mehreren Stellen bewiesen, dass das nicht ordentlich gepflegt wird.
Ist halt auch schwer fuer mich (oder allgemein fuer andere Hobby-Entwickler), wenn man kein echtes Repo hat, von dem man sauber wegentwickeln kann.
Soll auch kein Vorwurf sein! Nur ich hoffe die Situation verbessert sich.
Ps:
Ich hab jetzt dein occu geforkt und werde in Zukunft das nehmen. Ich werde versuchen aktuell zu sein und zu bleiben und auch das alte ganze Geruempel rauszuschmiessen. Ausserdem werde ich versuchen die Ordnerstruktur im git neu (imho korrekt) aufzubauen.
Mal schauen ob das klappt.
- jmaus
- Beiträge: 9902
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 466 Mal
- Danksagung erhalten: 1892 Mal
- Kontaktdaten:
Re: CCU-Repository
Also ich hab mir deine Hinweise bzgl. $(DOCUMENT_ROOT) einmal angeschaut und ich denke das dies nicht generell ein Problem darstellt. Das an den Stellend die du benannt wirst das $(DOCUMENT_ROOT) ohne ein Slash mit dem restlichen Pfad verbunden wird ist nur ein problem wenn DOCUMENT_ROOT nicht immer selbst einen Slash (/) am Ende hat. Und das ist eben abhängig von den document root Pfad Einstellungen des Webserver. Im Falle von RaspberryMatic und der CCU2/3 ist das jeweils in der lighttpd.conf der folgende Pfad:
Wie man hier sieht ist dort server_root mit /www/ definiert, d.h. am Ende ist ein Slash und somit sollten die von dir aufgezeigten Pfade korrekt zusammengesetzt werden. Unschön sind diese stellen allemal, aber bist du dir sicher das das in RaspberryMatic auch zu Problemen führt? Ich denke momentan nämlich nicht.
Code: Alles auswählen
var.server_root = "/www/"
Klappen kann das schon, aber das wird dazu führen das du auf kurz oder lang komplett inkompatibel zu zukünftigen Anpassungen von eQ3 und mir sein wirst und dann sicher hier/da auch mit einigen merge Konflikten zu kämpfen haben wirst. Ob das sinnvoll ist oder managebar musst du selber wissen. Ich hätte es an deiner stelle anders gemacht. Und zwar einfach mein OCCU repo als Basis und dann entsprechend erweitert um (ausgewählte) RaspberryMatic Patches aus dem RaspberryMatic repository. Und ich kann nur noch einmal betonen: Wichtiger erscheint mir momentan das du für deine x86 Anpassungen mal ein GitHub repository machst, das wäre IMHO viel hilfreicher.quickmic hat geschrieben: ↑15.12.2018, 20:22Ich hab jetzt dein occu geforkt und werde in Zukunft das nehmen. Ich werde versuchen aktuell zu sein und zu bleiben und auch das alte ganze Geruempel rauszuschmiessen. Ausserdem werde ich versuchen die Ordnerstruktur im git neu (imho korrekt) aufzubauen.
Mal schauen ob das klappt.
RaspberryMatic 3.75.7.20240420 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
-
- Beiträge: 518
- Registriert: 20.01.2011, 14:39
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 4 Mal
Re: CCU-Repository
Code: Alles auswählen
var.server_root = "/www/"
https://github.com/eq-3/occu/blob/maste ... httpd.conf
Zweitens ist es an dann an anderen Stellen wieder falsch:
z.b. hier: catch {source $env(DOCUMENT_ROOT)/config/easymodes/$file}
Vermutlich hat es aber durch pures Glueck keine Auswirkungen.
Ich bleibe dabei das war und ist ein Fehler oder zumindest wieder nicht konsequent durchgezogen.
Ps:
Und ich glaube auch, dass die ccu3 server_root anders definiert hat. Werde ich mir anschaunen. Das waere dann schon wieder ein Beleg, dass eq3 das Repo vernachlässigt.
- jmaus
- Beiträge: 9902
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 466 Mal
- Danksagung erhalten: 1892 Mal
- Kontaktdaten:
Re: CCU-Repository
Das ist aber nicht das server_root wie es auf der CCU/RaspberryMatic verwendet wird. Dort ist es /www/ ubd zwar mit absicht mit einem Slash am Ende.quickmic hat geschrieben: ↑16.12.2018, 07:50Das ist vermutlich richtig, aber Erstens ist das so nicht definiert hier:Code: Alles auswählen
var.server_root = "/www/"
https://github.com/eq-3/occu/blob/maste ... httpd.conf
Es gibt nämlich auch andere Stellen in der WebUI wo es sondefiniert ist und zwar z.B:
https://github.com/eq-3/occu/blob/maste ... ic.cgi#L28
Wie du hier sehen kannst muss es in dieser Datei explizit /www/ sein sonst wird das system nicht als CCU Zentrale gesetzt. D.h. In deinen X86 anpassen wirst du das auch angepasst haben, vmtl eben auf /opt/hm, du solltest hier aber das am besten auf /opt/hm/ ändern.
Das hat eigentlich nichts mit Glück zu tun, denn wie du weisst ist unter unix es egal ob man /www/file oder /www//file schreibt. Beides referenziert die gleiche Datei.Zweitens ist es an dann an anderen Stellen wieder falsch:
z.b. hier: catch {source $env(DOCUMENT_ROOT)/config/easymodes/$file}
Vermutlich hat es aber durch pures Glueck keine Auswirkungen.
Es ist unschön, ja. Und man könnte/sollte das anpassen lassen - eben durch eine meldung an eq3, ja (werde eine entsprechende email in die richtung schicken). Was aber wichtiger ist, ist das dies momentan anscheinend auf einer realen RaspberryMatic oder CCU3 oder CCU2 zu keinem negativem Effekt führt und wohl nur in deiner x86 Version zu Effekten kommt weil du dein server root nicht mit einen zusätzlichen slash am ende definierst. Oder sehe ich das falsch und du konntest das problem auf einer CCu/RaspberryMatic reproduzieren?Ich bleibe dabei das war und ist ein Fehler oder zumindest wieder nicht konsequent durchgezogen.
Nun kann man das natürlich in seinem eigenen OCCU fork anpassen, allerdings wird das eben zu besagten merge konflikten führen wenn eq3 dieses in zukunft anfasst. Meine herangehensweise ist eben genau deshalv diese direkte Änderungen im OCCU zu vermeiden wo es geht und besser auf für eQ3 leichter erkennbare Patchfiles zu setzen die diese einfach und schnell einsehen können um ggf dinge zu übernehmen/reparieren. Deshalb sollte man IMHO nicht größere Umstrukturierungen im OCCU repository vermeiden - ausser einen interessiert nicht was eq3 da tut...
Das ist leider ein Missverständnis dem ich selbst am Anfang auf den leim gegangen bin indem ich nömlich selvst auch gedacht hatte das doch das OCCU repository 1:1 mit einer CCU übereinstimmen muss. Nach Klärung von eQ3 ist das aber so nicht und das teils mit Absicht. Das OCCU repository ist z.b. Auch nicht das working directory von eQ3 selbst sondern stellt lediglich eine Sammlung der notwendigen Dinge dar um damit dann eine eigene CCU Zentrale aufbauen zu können (wie ich/du das ja machen). Das das OCCU Repo so aufgebaut ist wie es momentan ist, hat wohl mit kommerziellen Partnern zu tun die das auch für ihre eigenen Projekte nutzen und wenn es da Handlungsbedarf geben würde würden sie auch was ändern. OCCU wird eben wohl für mehr verwendet als nur für eine CCU3 oder RaspberryMatic.Und ich glaube auch, dass die ccu3 server_root anders definiert hat. Werde ich mir anschaunen. Das waere dann schon wieder ein Beleg, dass eq3 das Repo vernachlässigt.
RaspberryMatic 3.75.7.20240420 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
-
- Beiträge: 518
- Registriert: 20.01.2011, 14:39
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 4 Mal
Re: CCU-Repository
Ist richtig und ist mir auch aufgefallen.jmaus hat geschrieben: ↑16.12.2018, 08:30Es gibt nämlich auch andere Stellen in der WebUI wo es sondefiniert ist und zwar z.B:
https://github.com/eq-3/occu/blob/maste ... ic.cgi#L28
Ich vermute jedoch das der "join" command den Pfad intelligent zusammenbaut und somit keine Fehler entstehen. Egal ob mit oder ohne /.
Ansonsten wurde alles im A... sein, denn dass ist auch bei vielen easymodes drin https://github.com/eq-3/occu/blob/maste ... master.tcl
Aber muesste ich testen, ist bisher nur eine Annahme.
Koennte auch irgendwo der Slash vor den calls angeflanscht werden.
Wird aber (voellig sinnlos) in der naechsten Zeile wieder wegeschmissen.Es gibt nämlich auch andere Stellen in der WebUI wo es sondefiniert ist und zwar z.B:
https://github.com/eq-3/occu/blob/maste ... ic.cgi#L28
Dann kann man das gleich weglassen.
Ja weiss ich, aber wenn man sowas mit Absicht programmiert...Zweitens ist es an dann an anderen Stellen wieder falsch:
z.b. hier: catch {source $env(DOCUMENT_ROOT)/config/easymodes/$file}
Vermutlich hat es aber durch pures Glueck keine Auswirkungen.
Das hat eigentlich nichts mit Glück zu tun, denn wie du weisst ist unter unix es egal ob man /www/file oder /www//file schreibt. Beides referenziert die gleiche Datei.
Abschließend... Es geht mir nicht darum irgendwas schlecht zu machen! Das soll einfach sauber gefixt werden und ein Bug nicht als Feature verkauft werden.
Der Fix dauert 30 Sekunden und eigentlich muss der Code einfach nur mal sauber durchgeschaut werden.
Aber ich kenne die Programmierer Mentalität auch. Never change a running code aber je umfangreicher die Codebasis, desto mehr Tretminen faengt man sich ein wenn man nicht konsequent eine Linie durchzieht.
Ich hab auch bei meinen eigenen Programmen schon Stunden/Tage/Wochen nur mit Codebereinigungen und Performanceoptimierungen verbracht.
Da bin ich sehr skeptisch. Ich glaube das es einfach ein gewachsenes System ist und Altlasten nicht beseitigt wurden.Das ist leider ein Missverständnis dem ich selbst am Anfang auf den leim gegangen bin indem ich nömlich selvst auch gedacht hatte das doch das OCCU repository 1:1 mit einer CCU übereinstimmen muss. Nach Klärung von eQ3 ist das aber so nicht und das teils mit Absicht. Das OCCU repository ist z.b. Auch nicht das working directory von eQ3 selbst sondern stellt lediglich eine Sammlung der notwendigen Dinge dar um damit dann eine eigene CCU Zentrale aufbauen zu können (wie ich/du das ja machen). Das das OCCU Repo so aufgebaut ist wie es momentan ist, hat wohl mit kommerziellen Partnern zu tun die das auch für ihre eigenen Projekte nutzen und wenn es da Handlungsbedarf geben würde würden sie auch was ändern. OCCU wird eben wohl für mehr verwendet als nur für eine CCU3 oder RaspberryMatic.
Doppelte config files in verschiedenen Folder die unterschiedlich gepatcht wurden...
Wie auch immer, damit kann ich leben. Ich hab das bei meinem Fork von dir auch mittlerweile rausgeschmissen soweit ich die bemerkt habe.
- jmaus
- Beiträge: 9902
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 466 Mal
- Danksagung erhalten: 1892 Mal
- Kontaktdaten:
Re: CCU-Repository
Und genauso wird das in RaspberryMatic in einem WebUI patch gemacht der ja nun in meinem OCCU fork einzugehalten hat (siehe https://github.com/jens-maus/occu/blob/ ... gi#L27-L30) und so übrigens auch in der CCU3 Buildumgebung umgepatcht wird.quickmic hat geschrieben: ↑16.12.2018, 18:46Wird aber (voellig sinnlos) in der naechsten Zeile wieder wegeschmissen.Es gibt nämlich auch andere Stellen in der WebUI wo es sondefiniert ist und zwar z.B:
https://github.com/eq-3/occu/blob/maste ... ic.cgi#L28
Dann kann man das gleich weglassen.
Welche doppelten Config files meinst du bitte?Da bin ich sehr skeptisch. Ich glaube das es einfach ein gewachsenes System ist und Altlasten nicht beseitigt wurden.
Doppelte config files in verschiedenen Folder die unterschiedlich gepatcht wurden...
Wie auch immer, damit kann ich leben. Ich hab das bei meinem Fork von dir auch mittlerweile rausgeschmissen soweit ich die bemerkt habe.
RaspberryMatic 3.75.7.20240420 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
-
- Beiträge: 518
- Registriert: 20.01.2011, 14:39
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 4 Mal
Re: CCU-Repository
Code: Alles auswählen
rfd.conf Update to 2.17.15 Version 3 years ago
https://github.com/eq-3/occu/tree/master/X86_32_Debian_Wheezy/packages-eQ-3/RFD/etc/config
rfd.conf Update to 2.21.10 version 2 years ago
https://github.com/eq-3/occu/tree/master/X86_32_Debian_Wheezy/packages-eQ-3/RFD/etc/config_templates
legacy-parameter-definition.config update to 3.41.7 (3.41.x Release Candidate 7) 2 months ag
https://github.com/eq-3/occu/tree/master/X86_32_Debian_Wheezy/packages-eQ-3/RFD/opt/HmIP
legacy-parameter-definition.config add missing HmIP legacy api parameter definition file 2 years ago
https://github.com/eq-3/occu/tree/master/HMserver/opt/HmIP
mehrere hier:
https://github.com/eq-3/occu/tree/master/X86_32_Debian_Wheezy/packages/lighttpd/etc/lighttpd
https://github.com/eq-3/occu/tree/master/X86_32_Debian_Wheezy/packages-eQ-3/WebUI/etc/lighttpd