RaspberryMatic Fehlerbehebung/Verbesserungen

[Henke]

Mir stellt sich aktuell die Frage in welcher Größenordnung Änderungen an der Webui vorgenommen werden können, die auch eingepflegt werden.

Dazu ein Beispiel:

Ist:

Code: Alles auswählen

DEV_LIST = new Array();
DEV_DESCRIPTION = new Array();
DEV_PATHS = new Array();
DEV_HIGHLIGHT = new Array();
DEV_LIST.push('HM-RC-Sec4-3');
DEV_DESCRIPTION["HM-RC-Sec4-3"] = "HM-RC-4";
DEV_PATHS["HM-RC-Sec4-3"] = new Object();
DEV_PATHS["HM-RC-Sec4-3"]["50"] = "/config/img/devices/50/84_hm-rc-4-x_thumb.png";
DEV_PATHS["HM-RC-Sec4-3"]["250"] = "/config/img/devices/250/85_hm-rc-sec4-3.png";
DEV_HIGHLIGHT["HM-RC-Sec4-3"] = new Object();
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["arrow_part1"] = [6, 0.312, 0.288, 0.416, 0.288, 0.012];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["arrow_part2"] = [6, 0.312, 0.288, 0.352, 0.248, 0.012];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["arrow_part3"] = [6, 0.312, 0.288, 0.352, 0.328, 0.012];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["Arrow"] = [5, 'arrow_part1', 'arrow_part2', 'arrow_part3'];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["1_Arrow"] = [7, 'Arrow', 0.25, 0.0];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["2_Arrow"] = [7, 'Arrow', 0.238, 0.156];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["3_Arrow"] = [7, 'Arrow', 0.228, 0.312];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["4_Arrow"] = [7, 'Arrow', 0.212, 0.468];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["1"] = [5, '2_Arrow'];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["2"] = [5, '1_Arrow'];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["3"] = [5, '4_Arrow'];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["4"] = [5, '3_Arrow'];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["1+2"] = [5, '1_Arrow', '2_Arrow'];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["3+4"] = [5, '3_Arrow', '4_Arrow'];

Dabei ist DEV_DESCRIPTION ,DEV_PATHS und DEV_HIGHLIGHT ein Object und kein Array. Unter den Browsern läuft es, unter NodeRed als JavaScript Interpreter nicht. Richtig wäre "new Object()" oder kürzer "{}".

Die erste Stufe wäre die Fehlerbehebung mit einem minimalen diff der Zeilen 2,3,4.

Code: Alles auswählen

DEV_LIST = new Array();
DEV_DESCRIPTION = new Object();
DEV_PATHS = new Object();
DEV_HIGHLIGHT = new Object();
DEV_LIST.push('HM-RC-Sec4-3');
DEV_DESCRIPTION["HM-RC-Sec4-3"] = "HM-RC-4";
DEV_PATHS["HM-RC-Sec4-3"] = new Object();
DEV_PATHS["HM-RC-Sec4-3"]["50"] = "/config/img/devices/50/84_hm-rc-4-x_thumb.png";
DEV_PATHS["HM-RC-Sec4-3"]["250"] = "/config/img/devices/250/85_hm-rc-sec4-3.png";
DEV_HIGHLIGHT["HM-RC-Sec4-3"] = new Object();
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["arrow_part1"] = [6, 0.312, 0.288, 0.416, 0.288, 0.012];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["arrow_part2"] = [6, 0.312, 0.288, 0.352, 0.248, 0.012];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["arrow_part3"] = [6, 0.312, 0.288, 0.352, 0.328, 0.012];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["Arrow"] = [5, 'arrow_part1', 'arrow_part2', 'arrow_part3'];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["1_Arrow"] = [7, 'Arrow', 0.25, 0.0];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["2_Arrow"] = [7, 'Arrow', 0.238, 0.156];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["3_Arrow"] = [7, 'Arrow', 0.228, 0.312];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["4_Arrow"] = [7, 'Arrow', 0.212, 0.468];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["1"] = [5, '2_Arrow'];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["2"] = [5, '1_Arrow'];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["3"] = [5, '4_Arrow'];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["4"] = [5, '3_Arrow'];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["1+2"] = [5, '1_Arrow', '2_Arrow'];
DEV_HIGHLIGHT["HM-RC-Sec4-3"]["3+4"] = [5, '3_Arrow', '4_Arrow'];

Wenn man jedoch schon an dieser Stelle ist, könnte die Definition geändert werden, so das sie übersichtlicher, in manchen Editoren einklappbar wird und die Suche nach Schlüsselwörten vereinfacht.

Stufe 2 mit größerem diff:

Code: Alles auswählen

var DEV_LIST = new Array();
var DEV_DESCRIPTION = new Object();
var DEV_PATHS = new Object();
var DEV_HIGHLIGHT = new Object();
DEV_LIST.push('HM-RC-Sec4-3');
DEV_DESCRIPTION["HM-RC-Sec4-3"] = "HM-RC-4";
DEV_PATHS["HM-RC-Sec4-3"] = {
    50: "/config/img/devices/50/84_hm-rc-4-x_thumb.png",
    250: "/config/img/devices/250/85_hm-rc-sec4-3.png"
};
DEV_HIGHLIGHT["HM-RC-Sec4-3"] = {
    "arrow_part1": [6, 0.312, 0.288, 0.416, 0.288, 0.012],
    "arrow_part2": [6, 0.312, 0.288, 0.352, 0.248, 0.012],
    "arrow_part3": [6, 0.312, 0.288, 0.352, 0.328, 0.012],
    "Arrow": [5, 'arrow_part1', 'arrow_part2', 'arrow_part3'],
    "1_Arrow": [7, 'Arrow', 0.25, 0.0],
    "2_Arrow": [7, 'Arrow', 0.238, 0.156],
    "3_Arrow": [7, 'Arrow', 0.228, 0.312],
    "4_Arrow": [7, 'Arrow', 0.212, 0.468],
    "1": [5, '2_Arrow'],
    "2": [5, '1_Arrow'],
    "3": [5, '4_Arrow'],
    "4": [5, '3_Arrow'],
    "1+2": [5, '1_Arrow', '2_Arrow'],
    "3+4": [5, '3_Arrow', '4_Arrow']
};

Da die DEV_LIST Information auch in DEV_DESCRIPTION enthalten ist, ist diese überflüssig. Jedes mal den gleichen Pfad anzugeben macht auch keinen SInn und kann in der abfragenden Funktion implementiert werden. Letztendlich wäre ein Umbau der Struktur sinnvoll und durch minimale Änderungen bei den Funktionen zu realisieren.

Stufe 3:

Code: Alles auswählen

let DEV2_LIST = {
"HM-RC-Sec4-3": {
        "Desc": "HM-RC-4",
        "Hl": {
            "1": [GD_TYPE_FORMSET, "2_Arrow"],
            "2": [GD_TYPE_FORMSET, "1_Arrow"],
            "3": [GD_TYPE_FORMSET, "4_Arrow"],
            "4": [GD_TYPE_FORMSET, "3_Arrow"],
            "arrow_part1": [GD_TYPE_LINE, 0.312, 0.288, 0.416, 0.288, 0.012],
            "arrow_part2": [GD_TYPE_LINE, 0.312, 0.288, 0.352, 0.248, 0.012],
            "arrow_part3": [GD_TYPE_LINE, 0.312, 0.288, 0.352, 0.328, 0.012],
            "Arrow": [GD_TYPE_FORMSET, "arrow_part1", "arrow_part2", "arrow_part3"],
            "1_Arrow": [GD_TYPE_OFFSET, "Arrow", 0.25, 0],
            "2_Arrow": [GD_TYPE_OFFSET, "Arrow", 0.238, 0.156],
            "3_Arrow": [GD_TYPE_OFFSET, "Arrow", 0.228, 0.312],
            "4_Arrow": [GD_TYPE_OFFSET, "Arrow", 0.212, 0.468],
            "1+2": [GD_TYPE_FORMSET, "1_Arrow", "2_Arrow"],
            "3+4": [GD_TYPE_FORMSET, "3_Arrow", "4_Arrow"]
        },
        "Path": {
            50: "84_hm-rc-4-x_thumb",
            250: "85_hm-rc-sec4-3"
        }
    }

Stufe 4 würde dann die Struktur und die Funktionen, die sie nutzen in eine eigene Datei auslagern um eine doppelte Implementierung, wie z.B. in den "/tools" zu vermeiden.

Daher die Frage, bis zu welcher Stufe werden Änderungen eingepflegt?

[jmaus]

Ich sehe hier ehrlich gesagt nur eine reelle Chance die Änderung der Stufe1 umzusetzen. Alles andere würde zuviele Änderungen mit sich bringen die zu dauerhaften Konflikten gegenüber neuen OCCU Versionen von eQ3 führen würde.

Auch muss man bedenken, das diese Listen von eQ3 mittels automatisierten Tools erzeugt werden. Ich bin zwar dran eQ3 zu überzeugen diese Tools samt Rohdaten die diese Listen zugrundeliegen mit ins OCCU zu legen in Zukunft, aber da sist leider noch nicht soweit, denn dann gäbe es vllt eine Chance das umzusetzen in dem man diese Tools entsprechend umpatcht. Müssen wir abwarten… abee für Stufe1 müsste das bereits jetzt umsetzbar sein… müsste man aber auch beachten welche eventl. Dinge neben der normalen Browsernutzung dann vielleicht nicht mehr gehen würden…

[Henke]

… müsste man aber auch beachten welche eventl. Dinge neben der normalen Browsernutzung dann vielleicht nicht mehr gehen würden…

Da wird es nichts geben, da es einfach ein Fehler ist. Ob DEV_DESCRIPTION.length bei einer Array Deklaration die als Object genutzt wird nun immer "0" ist oder bei einem Object "undefined" sorgt garantiert nicht dafür das etwas schlechter läuft.

Zum Testen:

Code: Alles auswählen

DEV_DESCRIPTION = [];
DEV_DESCRIPTION['HM-RC-Sec4-3'] = 'HM-RC-4';
DEV_DESCRIPTION['bb'] = 'HM-RC-4 aaa';

console.log(DEV_DESCRIPTION);
console.log(DEV_DESCRIPTION.constructor.name);
console.log(DEV_DESCRIPTION.length);

DEV_DESCRIPTION = {};
DEV_DESCRIPTION['HM-RC-Sec4-3'] = 'HM-RC-4';
DEV_DESCRIPTION['bb'] = 'HM-RC-4 aaa';

console.log(DEV_DESCRIPTION);
console.log(DEV_DESCRIPTION.constructor.name);
console.log(DEV_DESCRIPTION.length);
console.log(Object.keys(DEV_DESCRIPTION).length);

Unter: https://developer.mozilla.org/en-US/doc ... ects/Array
Findet man auch ganz klar die Definition eines JS Arrays:

JavaScript arrays are not associative arrays and so, array elements cannot be accessed using arbitrary strings as indexes, but must be accessed using nonnegative integers (or their respective string form) as indexes.

Ich sehe hier ehrlich gesagt nur eine reelle Chance die Änderung der Stufe1 umzusetzen.

Das ist sehr schade und reduziert die Möglichkeiten Verbesserungen einzubringen ganz erheblich.

[jmaus]

Ich sehe hier ehrlich gesagt nur eine reelle Chance die Änderung der Stufe1 umzusetzen.

Das ist sehr schade und reduziert die Möglichkeiten Verbesserungen einzubringen ganz erheblich.

So ist das eben wenn die Lösung die man entwickelt im Grunde ein Fork ist und upstream immer noch neue Versionen rausbringt die man gerne unproblematisch einpflegen können möchte. Da muss man dann eben Kompromisse machen oder upstream davon überzeugen die vermeintliche Verbesserung zu übernehmen damit man selbst einen Schritt weiterkommt.

Wie ich aber schon geschrieben hatte. Für deine Stufe1 Verbesserung kannst du aber gerne ein PullRequest samt WebUI Patch einreichen im GitHub, das sollte kein Problem sein nachdem was ich verstanden habe.

Was die anderen Dinge angeht, so sehe ich da nach weiterem Nachdenken folgende Möglichkeiten diese Anpassungen vielleicht doch integriert zu bekommen:

1. Entweder ich bekomme eQ3 dazu die Quelldateien samt tools ins OCCU eibzupflegen die diese webui.js samt DEVDB automatisiert erzeugt. Dann könnte man diese Tools für uns anpassen und verbessern damit diese eben z.b. statt Array dann Object nimmt und die webui.js und DEVDB dann eben damit erzeugt wird.

2. Du schreibst selbst ein Tool (in Python, shell, etc.) das im Grunde das jetzt automatisiert was du hier vorschlägst. D.h. Es nimmt die webui.js und die Datei mit der DEVDB und baut die entsprechend dann um. Und wenn eQ3 dann eine neue Version bzw Änderungen rausbringt kann man dieses Tool dann eben einfach über die neuere webui.js/DEVDB laufen lassen und es baut die statements entsprechend um ohne das man irgendwie manuell eingreifen muss. Dieses Tool könnte man dann in die Build-Umgebung von RaspberryMatic integrieren das das immer aufgerufen wird bei jedem Build.

Bevor man eins der beiden dann aber umsetzt wäre es aber trotzdem interessant zu erfahren was du dir genau von diesen Umstellungen technisch herhoffst. Ausser das formal man das auch alles anders machen kann ist mir noch nicht so klar was man konkret davon hätte? Gibt es da Performancevorteile die ich jetzt nicht erkenne oder was würden diese Umstellungen konkret dem Endnutzer bringen? Auch wenn ich das mit Array vs Object verstehe, so funktioniert das ja trotzdem auch wenn es formal nicht ganz optimal ist. Und so auch mit den anderen Umstellungen. Und was für konkrete externe Applikationen könnten davon dann profitieren?

Auch müsste man dann mal mit Jerome (@jp112sdl) sprechen inwieweit seine homebrew Anpassungen via seines HB addons damit dann ggf ein Problem hätten bzw wie man diese dann ggf umstellen müsste.

[jp112sdl]

Auch müsste man dann mal mit Jerome (@jp112sdl) sprechen inwieweit seine homebrew Anpassungen via seines HB addons damit dann ggf ein Problem hätten bzw wie man diese dann ggf umstellen müsste.

In Anbetracht der Tatsache, dass sich am status quo meines Addons und meiner Projekte über kurz oder lang nichts ändern wird, könnte man überlegen, das Addon direkt in RM zu integrieren. So wären dann zumindest automatisierte Transformationen meiner zu patchenden Sektionen aus der alten webui.js-Struktur in die neue möglich.

[jmaus]

Das wäre in der Tat auch möglich, klar. Vllt schafft man es ja auch irgendwie das so anzupassen das andere addons oder externe apps sich da irgendwie andocken könnten ohne die dateien zu patchen? Das wäre dann ggf der "richtigere" Weg. Quasi irgendeine Schnittstelle nach aussen wo apps/addons neuw geräte der devdb via API unterjubeln können…