EMail-AddOn Umlaute falsch dargestellt

[jp112sdl]

Bei RM habe ich permanent das Gefühl, dass sein Fortbestehen von exakt einer Person abhängt - und zwar völlig unabhängig davon wieviele Leute gerade noch zuliefern (und auch das sind ja nur sehr wenige).

Schau dir LXCCU an, schau dir YAHM an, schau dir RedMatic, pivCCU, debmatic an. Und es gibt noch eine Vielzahl anderer Beispiele.
Alles hängt oder hing an einem einzigen Maintainer. Wenn der keine Lust mehr hat, stirbt das Projekt.

Einer muss den Hut bei solchen Projekten auf haben und sagen, "genau so" oder "so nicht".
Wird mal abgestimmt, fallen solche Umfragen selten, gemessen an den RM-Download-/Forennutzerzuahlen, repräsentativ aus.
Selbst Testversionen mit angekündigten Bitten um (konkrete) Tests werden, wenn überhaupt, nur von einer Hand voll ausprobiert und bewertet.

Die Beteiligung ist wirklich sehr sehr gering.

Und für das Erlernen und Einarbeiten fehlt mir die Zeit. Also kann ich leider aktiv nichts beitrage

Das ist ja genau das Argument, das halt (ich pauschalisiere mal) alle vorbringen.
So ist es halt. Mir fehlt jetzt auch die Zeit, um mich weiter an RM-Verschlimmbesserungen zu beteiligen.

[jmaus]

Einer muss den Hut bei solchen Projekten auf haben und sagen, "genau so" oder "so nicht".
Wird mal abgestimmt, fallen solche Umfragen selten, gemessen an den RM-Download-/Forennutzerzuahlen, repräsentativ aus.

Das was du da beschreibst ist ja das "Friendly Dictator"-Prinzip das im OpenSource Bereich sehr gängig ist. OpenSource Entwicklung hat eben (auch wenn das viele gefühlt gerne anders hätten) nichts mit Demokratie zu tun. Dort entscheiden die "Maintainer" und wenn das eben wie bei RaspberryMatic nur ein paar "Hanseln" sind, dann entscheiden die eben wohin die Reise geht. Und ich hab ja schon sehr oft betont, das ich sehr sehr gerne mehr Kontrolle über RaspberryMatic abgeben würde. Das würde es aber notwendig machen, das mehr Entwickler (und nicht nur Nutzer) sich rund um RaspberryMatic tummeln und aktiv via PullRequests, etc. daran mitarbeiten. Mit dir (@jp112sdl) und ein paar anderen (@Baxxy, usw.) hat das in der Vergangenheit ja bereits recht erfolgreich geklappt und es sind IMHO ein paar beachtliche Änderungen/Bugfixes dabei herausgekommen. Alleine die Möglichkeit RaspberryMatic virtuell als Docker oder HomeAssistant Addon zu betreiben geht ja ursprünglich auf einen PullRequest eines anderen Entwicklers zurück! Das sollte man nicht vergessen. Und natürlich hoffe ich, dass es in ähnlichem Maße in Zukunft weiter geht und ich zumindest hin und wieder Änderungsvorschläge im RaspberryMatic Projekt bei GitHub von anderen eingereicht sehe und nicht nur ich hier alleine auf weiter Flur daran arbeite. Das vielleicht niemand ähnlich viel Zeit investieren kann oder will wie ich, ist ja prinzipiell ok. Und bis zu einem gewissen Grad ist das ja auch vielleicht Ausdruck dessen das die Entscheidungen die ich als Hauptmaintainer treffe im Gesamten eigentlich ganz ok sind und deshalb der Eine oder Andere sich vielleicht deshalb nicht noch mehr einbringt - weil es eben prinzipiell in die richtige Richtung geht.

So ist es halt. Mir fehlt jetzt auch die Zeit, um mich weiter an RM-Verschlimmbesserungen zu beteiligen.

Da hab ich natürlich weiterhin die Hoffnung das sich bei dir vielleicht wieder in naher Zukunft ein gewisses Zeitkontingent auftut und du wieder hier+da gewisse Anpassungen an der WebUI für die Integration vorschlagen kannst. Denn in der Tat bin ich (und die Community sicherlich auch) für deine bisherige Mitarbeit an RaspberryMatic sehr dankbar. Und es steht ja immer noch eine gewisse größere Anpassung/Modifikation der WebUI hin zur Nutzung von Bootstrap als Javascript-Grundlage an die ich in diesem Jahr gerne voll integriert sehen würde, damit dann darauffolgend noch weitere - aus stilistische Verbesserungen in die WebUI einfließen können. Und wer weiss, vielleicht kann ich dich damit ja ködern wieder etwas mehr Zeit für RaspberryMatic Verbesserungen einzuplanen

[MichaelN]

Mich erinnert die Diskussion an manche Mitarbeiter in der Firma. Die erzählen auch den lieben langen Tag was alles schlecht läuft. Und wenn ich dann sage, lass uns die Dinge ändern, mach mal Vorschläge, verschwinden die ganz schnell wieder in ihren Höhlen...

[zautrix]

So, jetzt muss ich doch auch mal meinen Senf hier dazu geben.
Wie heißt es doch so schön bei einer Immobilie? Das wichtigste sind
1. Die Lage
2. Die Lage
und dann auch noch 3.Die Lage.

Abgewandelt auf mich und die CCU Firmware gilt für mich persönlich:
Das wichtigste für mich sind
1. Ein stabiles und fehlerfreies System
2. Ein stabiles und fehlerfreies System
3. Ein stabiles und fehlerfreies System

und dann sind 4. natürlich auch Usability Features nicht unwichtig.

Bei Punkt 4. hat Raspberrymatic natürlich gegenüber der CCU3 Original-Firmware gaaaaanz weit die Nase vorne. Danke dafür an alle Beteiligten.

Bei Punkt 1.-3. hat im allgemeinen Raspberrymatic auch gegenüber der CCU3 Original-Firmware die Nase vorne. Wenn mal etwas "hakt" in Raspberrymatic ( was nicht auf occu von eQ3 beruht ) wird es von Jens zeitnah gefixt. So weit super.

Und ich bitte alle, die schon länger Raspimatic und CCU3 verfolgen kurz innezuhalten und zu überlegen, wo wir in Sachen CCU Firmware ohne Jens wären ...
Es würde wahrscheinlich das "200 Sysvar max" Problem noch immer in der CCU3 Original-Firmware geben.

Also, was Jens macht ist ein absoluter Glücksfall für die CCU Community. So etwas ist nicht selbstverständlich. Das bitte ich stets zu bedenken.

Und wenn Jens die ganze Hauptarbeit macht ist es auch selbstverständlich, dass er entscheidet was, wann, wie gemacht wird.

Wer nicht selbst beim Testen von Entwicklungsversionen mitmacht sollte also besser "stille sein" und nicht meckern wenn es bei Releases zu unerwünschten Fehlern kommt.

So weit, so gut.

Nun aber mein ganz persönliches ABER

Ich finde das Release Management von Raspberrymatic "etwas merkwürdig". Es gibt ein Release. Da sind Fehler drin. Diese Fehler werden zeitnah gefixt. Verfügber in nightly builds. Danach werden Änderungen gemacht. Und wieder neue Fehler eingebaut. Die wegen mangelnder Anzahl von Leuten, die das testen, in der nächsten Release drinne sind. ... und wieder gehts von vorne los ...

Meine Vorstellung von Release Management ist das nicht. Wenn in einem Release Fehler erkannt und gemeldet werden, denke ich, sollten diese zeitnah behoben werden und dann ein neues Release mit nur den erfolgten Bugfixes erfolgen. Danach kann dann wieder an dem "Einbauen von neuen Fehlern" gebastelt werden.

Wie ich ich schon oben sagte: Jens macht das so, wie er das meint. Ist total ok für mich.

Da aber diese Vorgehensweise nicht mit meinen Prio 1.-3. ( Ein stabiles und fehlerfreies System ) in Einklang zu bringen ist, meckere ich nicht rum sondern baue ich mir schon seit einiger Zeit mein eigenes Raspberrymatic.

Das Ziel dieser Version ist nicht etwa irgendwelche tollen Features zu entwickeln und diese der Community vorzuenthalten, sondern nicht mehr jedes neue Feature der Raspimatic übernehmen zu müssen.
Einfach um ein stabiles System zu erhalten.

Des weiteren hat meine Version ein rw 3 GB root file system.
Und außerdem empfinde ich buildroot zum Bauen der CCU Firmware mittlerweile als "rechten Scheißdreck".
Buildroot ist für kleine, limitierte embedded Systeme das Richtige. Aber einen Raspi 4 kann man schon als Desktop rechner nutzen. Bei einer CCU2 war das nicht möglich.
Aber um buildroot kommt man leider nicht herum ohne das Rad komplett neu zu erfinden. Ich bin gerade dabei auszuprobieren, wie man das alles ( gebaut via buildroot und danach gepatcht) für meine Zwecke "aufmotzen" kann.
Denn mein Ziel ist ja eine native Zentrale mit originaler ( aber ggf. älterer ) , nur leicht gepatchter, Raspimatic, neuestem occu von eQ3, und einem ioBroker darauf nativ zu laufen zu haben. Wo bei diesem iobroker auch das Installieren von dem zigbee Adapter funzen muss, also sich eine c++ Compile Toolchain auf der Raspimatic befinden muss ( was mit buildroot gar nicht möglich ist ).
Ich bin schon ziemlich weit, aber noch immer dabei Ideen für Vereinfachungen zu haben und diese zu testen.

Zur Info: Meine "broker-matic" wird es auschliesslich für Pi 4 / Pi 400 geben und wenn ich etwas Vorzeigbares habe, würde ich mich natürlich über Tester freuen. Das kann aber noch Monate dauern ... es sind noch gewaltige Probleme zu klären um die entsprechenden OS Lizenzen einzuhalten. Das ist nicht trivial. Es ist ein gewaltiger Unterschied, ob ich etwas für mich "bastele" oder dieses an andere Leute weitergeben kann/will. Und ich halte strikt sämtliche OS Lizenzen ein, da führt kein Weg dran vorbei!


Also, lange Rede kurzer Sinn:
Wenn einem etwas im Open Source Umfeld nicht passt: Nicht meckern. Selber machen.
Oder mit dem leben, was andere so machen.

Und natürlich gilt auch für mein Projekt:
Wieder so ein "für viele User nutzloses Projekt". Das mit mit seinem Programmierer "eingeht".
Doch halt! ( Noch habe ich nichts im github hinterlegt, siehe oben ). Wenn ein OSS Projekt nicht mehr weiterentwickelt wird steht es jedem frei ( und natürlich auch schon, wenn es noch aktiv entwickelt wird ) dieses Projekt ( zu forken und ) weiter zu führen.
Aber mein Projekt stirbt nicht "wenn ich keine Lust mehr habe", sondern erst, wenn ich das Gras von unten wachsen sehe.

[MichaelN]

Wenn in einem Release Fehler erkannt und gemeldet werden, denke ich, sollten diese zeitnah behoben werden und dann ein neues Release mit nur den erfolgten Bugfixes erfolgen. Danach kann dann wieder an dem "Einbauen von neuen Fehlern" gebastelt werden.

Das halte ich für einen sinnvollen Vorschlag. Ich lasse derzeit auch immer einige RM Versionen auf dem Produktivsystem aus, weil zwar jede neue Version was interessantes mitbringt, aber auch oft einen Haken, den man schlucken muss.

Daher @Jens: kannst Du mal drüber nachdenken, ob man eine "Stable" Release nur mit Bugfixes und ein "enhanced" Release mit Erweiterungen im Wechsel veröffentlichen könnte?

[jmaus]

Ich finde das Release Management von Raspberrymatic "etwas merkwürdig". Es gibt ein Release. Da sind Fehler drin. Diese Fehler werden zeitnah gefixt. Verfügber in nightly builds. Danach werden Änderungen gemacht. Und wieder neue Fehler eingebaut. Die wegen mangelnder Anzahl von Leuten, die das testen, in der nächsten Release drinne sind. ... und wieder gehts von vorne los ...

Meine Vorstellung von Release Management ist das nicht. Wenn in einem Release Fehler erkannt und gemeldet werden, denke ich, sollten diese zeitnah behoben werden und dann ein neues Release mit nur den erfolgten Bugfixes erfolgen. Danach kann dann wieder an dem "Einbauen von neuen Fehlern" gebastelt werden.

Nur kurz dazu meine Meinung: Es gibt schon länger in meinem Kopf die Idee neben den normalen RaspberryMatic Versionen noch so etwas wie eine "LTS" Version anzubieten die nur ein paar mal im Jahr Updates erhält (eben hauptsächlich Bugfixes), darüberhinaus aber keine größeren Neuerungen. Auch würde ich natürlich gerne die Art&Weise der Entwicklung in GitHub ändern und z.B. alles über PullRequests machen um so z.B. keine direkten Checkins mehr in den master branch zu wollen. Das würde dann erlauben gewisse neue Features und Fixes besser zu separieren und somit auch besser zu stabilisieren. Allerdings steht und fallen diese Ideen der potentiellen Verbesserung der Entwicklungsarbeit rund um RaspberryMatic mit dem Aufwand der damit einhergeht. Denn es ist nicht ohne all das umzusetzen und parallel mehr oder weniger zwei Versionen in Zukunft zu pflegen. Daher sind diese Ideen dem potentiellen Aufwand bisher zum Opfer gefallen. Wenn es allerdings genug regelmäßige Entwickler geben würde die sich aktiv an RaspberryMatic beteiligen, dann könnte man darüber in der Tat nachdenken.

Zusätzlich muss man aber auch sehen, das ich ja seit vielen Jahren auf ein "Rapid Release Modell" setze und quasi fast auf den Tag genau 1x im Monat einen neuen Release rausbringe. Das alleine sollte IMHO doch schon die ganze Problematik wesentlich entspannen weil dann max. nach einem Monat man ja dann ein neues Release mit den entsprechenden Bugfixes (und ja, ggf. natürlich wieder mit ein paar anderen Bugs die wiederum dann einen Monat später beseitigt werden sollten) erhalten sollte. Man kann also locker (bei einem neuen Bug) erst einmal bei seiner alten Version bleiben um dann eben auf die neu zu erscheinende Version zu wechseln. Und ich denke die bisherige Statistik bzgl. neuer Bugs in neuen Versionen sollte diesem Vorgehen doch eigentlich recht geben.

Da aber diese Vorgehensweise nicht mit meinen Prio 1.-3. ( Ein stabiles und fehlerfreies System ) in Einklang zu bringen ist, meckere ich nicht rum sondern baue ich mir schon seit einiger Zeit mein eigenes Raspberrymatic.

Das Ziel dieser Version ist nicht etwa irgendwelche tollen Features zu entwickeln und diese der Community vorzuenthalten, sondern nicht mehr jedes neue Feature der Raspimatic übernehmen zu müssen.
Einfach um ein stabiles System zu erhalten.

Des weiteren hat meine Version ein rw 3 GB root file system.
Und außerdem empfinde ich buildroot zum Bauen der CCU Firmware mittlerweile als "rechten Scheißdreck".

Tut mir leid, aber wie du dir denken kannst bin ich nicht nur bzgl. "buildroot == Scheißdreck" absolut nicht deiner Meinung, denn ich denke dir fehlt vmtl. hier nur einfach der tiefere Einblick bzw. die langjärhige Erfahrung und teils das KnowHow um zu durchschauen das Buildroot genau das richtige Linux Betriebssystem für den Unterbau eines solchen Projektes ist. Auch dein Ansinnen hier ein aufgeblähtes RaspberryMatic zu machen nur um dein Problem zu lösen für das ioBroker Addon auch platformabhängige Adapter/Pakete anbieten zu können halte ich für kritisch. Als ich dir damals die Quellen des ioBroker Addon übereingnet hatte, hatte ich ja die Hoffnung du arbeitest dich entsprechend ein und baust die CI Umgebung des GitHub Projektes so um das ähnlich wie bei RedMatic am Schluss auch direkt vorkompilierte Binärdateien im Addon tar.gz mit ausgeliefert werden können. Dazu kam es aber leider nicht und ich halte es auch wirklich nicht für sinnvoll und zeitgemäß eine gesamte Build-Umgebung innerhalb des RaspberryMatic Betriebssystemes mit auszuliefern nur um ein einfaches "npm install XXX" ausführen lassen zu können. Sowas sollte man IMHO anders lösen.
Aber wie du schon sagtest, es obliegt jedem Entwickler selbst nach gut dünken vorzugehen und wenn du meinst das es nicht ohne eigenes OS Image geht, dann ist das so. Die Zeit wird dann zeigen ob nicht jemand anders dann eben ein eigenes ioBroker Addon irgendwann herausbringt das alles notwendige (inkl. platformabhängige Binaries) schon mit sich bringt genauso wie das bei RedMatic z.B. ja auch der Fall ist.

[MichaelN]

Denn es ist nicht ohne all das umzusetzen und parallel mehr oder weniger zwei Versionen in Zukunft zu pflegen

Ich weiß auch nciht ob es soviel SInn macht eine Stabile, aber Feature reduzierte Version zu pflegen. Das haben wir ja schon mit der OCCU.
Als Kompromiss zu "2 Versionen pflegen" denk doch mal drüber nach ob es Sinn machen kann, sagen wir mal in den geraden Monaten kommt nur ein Release mit Bugfixes aus der Vorversion, Und in den ungeraden Monaten kommt eine Version mit neuen Features bzw. Ziefergehenden Updates.
Ich denke das wäre ein guter Kompromiss.

[Black]

Wenn ich in einer SDV Version einen Bug drinhatte, den jemand gefunden hatte und den wir dann auch manchmal gemeinsam nachvollzogen und den ich dann gefixt hatte, dann kam bei mir halt auch mal eine HF1 oder auch HF2 Version, die diesen Bug abstellte.

Black

[Baxxy]

Back to Topic...

Mit dem heutigen Nightly Snapshot (RaspberryMatic-3.63.8.20220405-d2a744) ist wieder alles "beim Alten".
Also Umlaute im Betreff funktionieren wieder und für SysVars die Umlaute im Text haben nimmt man wieder...

Code: Alles auswählen

encoding convertfrom utf-8

Grüße, Baxxy

[zautrix]

Man kann also locker (bei einem neuen Bug) erst einmal bei seiner alten Version bleiben um dann eben auf die neu zu erscheinende Version zu wechseln.

Das Problem ist ja, dass in dieser alten Version auch wieder Bugs drin sind, mit denen man leben muss und man eigentlich genau auf die neue Version wartet, wo diese Bugs behoben sind.
Eine Abhilfe wäre nur, wenn man die nightly builds von ein paar Tagen später installiert. Doch halt! Sind dort jetzt die Bugs wirklich gefixt? Sind da vielleicht mittlerweile neue Umbauten begonnen worden und neue Bugs drin?
Wenn ich das alles erst einmal haarklein anhand der checkins nachprüfen muss, ist das ein ziemlicher Aufwand. Da erscheint es für mich sinnvoller mein System selbst zu pflegen nd zu kompilieren.

Tut mir leid, aber wie du dir denken kannst bin ich nicht nur bzgl. "buildroot == Scheißdreck" absolut nicht deiner Meinung, denn ich denke dir fehlt vmtl. hier nur einfach der tiefere Einblick bzw. die langjärhige Erfahrung und teils das KnowHow um zu durchschauen das Buildroot genau das richtige Linux Betriebssystem für den Unterbau eines solchen Projektes ist.

Ich denke es mir und es muss dir nicht leid tun.
Meine Erfahrung mit den embedded build systemen OpenEmbedded, Yocto und buildroot ist ... öhm ... ääh ... so ca. 21 Jahre, also tatsächlich sehr begrenzt.

Auch dein Ansinnen hier ein aufgeblähtes RaspberryMatic zu machen nur um dein Problem zu lösen für das ioBroker Addon auch platformabhängige Adapter/Pakete anbieten zu können halte ich für kritisch.

Für wen denn kritisch? Für mich nicht.

Als ich dir damals die Quellen des ioBroker Addon übereingnet hatte, hatte ich ja die Hoffnung du arbeitest dich entsprechend ein und baust die CI Umgebung des GitHub Projektes so um das ähnlich wie bei RedMatic am Schluss auch direkt vorkompilierte Binärdateien im Addon tar.gz mit ausgeliefert werden können. Dazu kam es aber leider nicht und ich halte es auch wirklich nicht für sinnvoll und zeitgemäß eine gesamte Build-Umgebung innerhalb des RaspberryMatic Betriebssystemes mit auszuliefern nur um ein einfaches "npm install XXX" ausführen lassen zu können.

Meine Maxime ist nicht nur "ein fehlerfreies System" sondern auch "so viel Ergebnis ( für mich selbst ) wie nötig mit so wenig Aufwand wie möglich".

Aber wie du schon sagtest, es obliegt jedem Entwickler selbst nach gut dünken vorzugehen und wenn du meinst das es nicht ohne eigenes OS Image geht, dann ist das so. Die Zeit wird dann zeigen ob nicht jemand anders dann eben ein eigenes ioBroker Addon irgendwann herausbringt das alles notwendige (inkl. platformabhängige Binaries) schon mit sich bringt genauso wie das bei RedMatic z.B. ja auch der Fall ist.

Genau so sieht's aus! Jeder macht, was er für richtig hält. Und ich mache genau das, was ich für mich brauche. Wenn es sich ergibt, dass ein Tag Arbeitsaufwand etwas entstehen lassen kann, was auch für andere sinnvoll ist, bin ich gerne bereit diesen Aufwand auf mich zu nehmen.

ioBroker als addon auf Raspimatic hat viel zu viele Einschränkungen ( "Stichwort buildroot" ) und benötigt viel zu viel Wartung, um das auf die Allgemeinheit loszulassen. Und das "tolle Redmatic" hat sich ja gerade auch "schlafen gelegt" in der Entwicklung.

Ich habe aber einige Ideen wie man den Wartungsaufwand von iobroker auf raspimatic ( d.h. broker-matic ) optimieren könnte.

Also: Schaun mer mal ... wie es so weitergeht ...