RaspberryMatic 3.55.5.20201226 – Neue Version

[AndiN]

Hallo,

dann mal wieder zurück zum Thema

Also ich habe vor 24 Stunden das Weihnachtsgeschenk noch ausgepackt...ähm eingespielt.

Läuft unauffällig... Keine Bugs entdeckt....

Und ich gebe stan23 Vorschlag 5 Punkte.... Fände ich auch besser. Wenn man die Entwicklung hier die letzen 5 Jahre verfolgt hat, dann wäre ohne RM und der Entwicklung das System nicht so genial geworden. Früher waren Updates wie russiches Roulette und viele sinnvolle Funktionen waren nicht vorhanden und Wünsche wurden nicht entgegen genommen.

Daher nochmal Danke an Alle die das System zu dem gemacht haben was es jetzt ist.

Andi

[jmaus]

Ich kann es jetzt auch im Testsystem reproduzieren.
[...]
Hier zum Angucken mit dem HB-RC-4-Dis-TH:
http://g.recordit.co/N30RKZ0Uy4.gif

Die Änderung wirkt sofort.

Da könnte in der Tat die Ursache sein, ja. Aber was mich stutzig macht ist,

1. das es ja anscheinend nicht immer auftritt sondern hier/da random ist wann genau es auftritt.
2. diese Änderung sicher nicht unbewusst passiert sein mag. Wird denn diese functions datei noch an anderer Stelle inkludiert und folglich wäre an der stelle eigentlich "device" statt "oDev" wiederum richtig?

[MichaelN]

Warum lässt die strikte QM den Hausmeister an der Firmware rumändern... sind so Fragen, die einem spontan durch den Kopf gehen.

Tut mir leid, aber diese Fragen haben inzwischen einen viel zu langen Bart und am schluss hilft es nicht dauernd und immer wiederholend daraufhin zu weisen das es da offensichtlich Probleme gibt. Die Zeit und Energie ist wirklich besser in Weiterentwicklung investiert IMHO.

Als gelernter QSler kann ich dir versichern, dass dein Ansatz der falsche ist. Es gibt hier ein massives Problem im change Management und bei der QS. Und solange das niemand bei Eq-3 anpackt, wird es eher schlimmer als besser. Von selbst wird es sich definitiv nicht ändern. Da wirst du noch viel Arbeit haben, wenn du dir nicht die Mühe machst mal ein ernstes Wort mit Verantwortlichen bei Eq-3 zu reden. Und wer außer dir könnte das tun? Die zahlende Kundschaft wird ja nicht gehört.

[jp112sdl]

1. das es ja anscheinend nicht immer auftritt sondern hier/da random ist wann genau es auftritt.

Ich vermute mal, ausschlaggebend ist das Vorhandensein eines bestimmten Gerätetyps in der Liste.

2. diese Änderung sicher nicht unbewusst passiert sein mag. Wird denn diese functions datei noch an anderer Stelle inkludiert und folglich wäre an der stelle eigentlich "device" statt "oDev" wiederum richtig?

Benutzt wird die neue function.fn in

Code: Alles auswählen

/www/rega/pages/tabs/control/hfuncchannels.htm
/www/rega/pages/tabs/control/hdevichannels.htm
/www/rega/pages/tabs/control/hroomchannels.htm

device kommt dabei nur in /www/rega/pages/tabs/control/hdevichannels.htm vor
oDev in /www/rega/pages/tabs/control/hroomchannels.htm und /www/rega/pages/tabs/control/hfuncchannels.htm - also da, wo es zu der Fehldarstellung kommt.

Du könntest also alle Vorkommen von "oDev" in "device" in den letzten beiden genannten Dateien ändern, dann passt alles zur function.fn

[Black]

Tut mir leid, aber diese Fragen haben inzwischen einen viel zu langen Bart und am schluss hilft es nicht dauernd und immer wiederholend daraufhin zu weisen das es da offensichtlich Probleme gibt. Die Zeit und Energie ist wirklich besser in Weiterentwicklung investiert IMHO.

Mag sein, aber solange derartige Qualität rausgehauen wird, darf man bei denen auch ruhig mal die Finger in die Wunde legen und bisschen Salz nachstreuen. Sonst glaubt nachher dort noch jemand, der ausgelieferte Qualitätsstandart wäre voll in Ordnung. Den Running-Gag mit der Strikten QM hat sich nämlich EQ3 selbst zuschreiben. Die dortigen Mitarbeiter werden dafür bezahlt, tests zu machen und fehler zu beheben, NICHT die Community, die bezahlt nämlich für die Produkte .

just my 2 cent, Black

[jp112sdl]

So, dann wäre ja ggü. der original 3.55.5
- das ProofAndSetValue gefixt
- die Darstellung von Gewerke und Räume auch demnächst,
...bleibt noch die kaputte Sortierung der Kanäle bei der Geräteauswahl in Programmen? Das ist mir aber wirklich egal

[jmaus]

Tut mir leid, aber diese Fragen haben inzwischen einen viel zu langen Bart und am schluss hilft es nicht dauernd und immer wiederholend daraufhin zu weisen das es da offensichtlich Probleme gibt. Die Zeit und Energie ist wirklich besser in Weiterentwicklung investiert IMHO.

Als gelernter QSler kann ich dir versichern, dass dein Ansatz der falsche ist. Es gibt hier ein massives Problem im change Management und bei der QS. Und solange das niemand bei Eq-3 anpackt, wird es eher schlimmer als besser. Von selbst wird es sich definitiv nicht ändern. Da wirst du noch viel Arbeit haben, wenn du dir nicht die Mühe machst mal ein ernstes Wort mit Verantwortlichen bei Eq-3 zu reden. Und wer außer dir könnte das tun? Die zahlende Kundschaft wird ja nicht gehört.

Du kannst mir glauben, das mache ich schon hier/da natürlich. Allerdings sind da meine Mittel auch mehr als begrenzt, denn ich bin kein eQ3 Mitarbeiter und erst recht kein Funktionsträger dort. Und so bleibt mir nur die Dinge in routinierter Art&Weise und mit der notwendigen Diplomatie vorzutragen und zu hoffen das es hier zu einer Veränderung kommt. Alleine an dem WebUI Patch Stau (wir sind inzwischen bei >100 Patches die RaspberryMatic gegenüber der CCU3 nutzt), kann man glaube ich gut erkennen das die Entwicklungsabteilung dort (aus welchen Gründen auch immer) mit der Entwicklungsgeschwindigkeit von RaspberryMatic bzw. der Community nicht mithalten kann. Ihr könnt euch aber sicher sein das ich weiterhin (auch kritische) Dinge gegenüber eQ3 vorbringen werde. Aber ob ich damit auf offene Ohren treffe oder aber hier eine andere Agenda verfolgt wird liegt nicht in meiner Hand und ich denke auch weiterhin das es sinnvoller wäre wenn wir uns hier auf die sukzessive Weiterentwicklung konzentrieren sollten solange das möglich ist. Das erscheint mir der effektivste Weg zu sein etwas zu bewegen, denn wenn man die Nutzerzahlen so anschauen bzw. weiss dann ist das "CCU Geschäft" immer noch ein Nieschengeschäft für eQ3 und die internen Stimmen die gerne auf Cloud-Only setzen würden werden definitiv nicht leiser, soviel kann ich verraten...

[Black]

So, dann wäre ja ggü. der original 3.55.5
- das ProofAndSetValue gefixt
- die Darstellung von Gewerke und Räume auch demnächst,
...bleibt noch die kaputte Sortierung der Kanäle bei der Geräteauswahl in Programmen? Das ist mir aber wirklich egal

Ich hätte da noch ein projekt in der Pipeline... Dazu bräuchte ich aber wieder deine geschicken fingerchen für die WebUi.
Und zwar gehts um Kommentarmöglichkeit von Bedingungen in der WebUI. Den technischen Background habe ich soweit zusammen, ich bins immo für mein system am programmieren (FPC). Wenn man da frühzeitig zusammen die Spezifikationen festlegt, wäre das auch nicht unbedingt zu verachten

Black

[jmaus]

Mag sein, aber solange derartige Qualität rausgehauen wird, darf man bei denen auch ruhig mal die Finger in die Wunde legen und bisschen Salz nachstreuen. Sonst glaubt nachher dort noch jemand, der ausgelieferte Qualitätsstandart wäre voll in Ordnung. Den Running-Gag mit der Strikten QM hat sich nämlich EQ3 selbst zuschreiben. Die dortigen Mitarbeiter werden dafür bezahlt, tests zu machen und fehler zu beheben, NICHT die Community, die bezahlt nämlich für die Produkte .

Natürlich darf und soll man Kritik äußern! Aber die Vergangenheit müsste doch gezeigt haben, dass diese Kritik hier nur wirklich sehr begingt (wenn überhaupt) gehört wird bzw. bei eQ3 durchdringt, denn offiziell ist hier kein eQ3 Mitarbeiter aktiv. Das hier ist einfach das falsche Forum dafür. Sowas sollte man besser z.B. an vielleicht wieder stattfindenden Usertreffen gegenüber eQ3 Verantwortlichen äußern oder aber via entsprechender Supportrequests oder Schreiben an eQ3 selbst. Denn der gemeine Entwickler bei eQ3 macht meiner Meinung nach bereits das Möglichste aus der ihm zugeteilten CCU-Projektzeit...

[jmaus]

1. das es ja anscheinend nicht immer auftritt sondern hier/da random ist wann genau es auftritt.

Ich vermute mal, ausschlaggebend ist das Vorhandensein eines bestimmten Gerätetyps in der Liste.

Das kann gut sein. Ich vermute sogar ein Zusammenspiel aus der Reihenfolge der Aufrufe sodass mitunter device dann doch bereits irgendwie als variable existiert (oder eben nicht).

2. diese Änderung sicher nicht unbewusst passiert sein mag. Wird denn diese functions datei noch an anderer Stelle inkludiert und folglich wäre an der stelle eigentlich "device" statt "oDev" wiederum richtig?

Benutzt wird die neue function.fn in

Code: Alles auswählen

/www/rega/pages/tabs/control/hfuncchannels.htm
/www/rega/pages/tabs/control/hdevichannels.htm
/www/rega/pages/tabs/control/hroomchannels.htm

device kommt dabei nur in /www/rega/pages/tabs/control/hdevichannels.htm vor
oDev in /www/rega/pages/tabs/control/hroomchannels.htm und /www/rega/pages/tabs/control/hfuncchannels.htm - also da, wo es zu der Fehldarstellung kommt.

Du könntest also alle Vorkommen von "oDev" in "device" in den letzten beiden genannten Dateien ändern, dann passt alles zur function.fn

Ich würde sagen wir machen das doch so wie von dir vorgeschlagen und du schickst einen WebUI Patch PR ein der in der function.fn das "device" gegen "oDev" tauscht. Nachdem ich mir die besagten Code-Passagen angeschaut habe erscheint mir das in der Tat doch ein Fehler dort zu sein, denn oDev gibt es in all diesen drei fällen und device eben nur 1x. Da hat der Entwickler wohl mit der Auslagerung in die function.fn wirklich einen Fehler begangen in dem er gedacht hat "device" wäre immer deklariert, was aber nicht der Fall ist. Danke dir auf jeden Fall schon für den PR. Komisch das mir das nicht auch aufgefallen ist, denn ich hatte da drüber auch schon geschaut und auch bemerkt das hier eine Auslagerung passiert ist. Das "device" vs. "oDev" hab ich dann aber selbst auch übersehen. Also Hut ab dafür!