Re: CCU-Repository
Verfasst: 15.12.2018, 19:58
Noch ein Grund mehr deine X86 Patches direkt als RaspberryMatic-x86 Paket herauszubringen
Heimautomation mit ELV HomeMatic und FHZ Funk-Hauszentralen
https://homematic-forum.de/forum/
Noch ein Grund mehr deine X86 Patches direkt als RaspberryMatic-x86 Paket herauszubringen
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
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.
Code: Alles auswählen
var.server_root = "/www/"
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
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.
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.
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
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
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.
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.
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.
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