Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[oFbEQnpoLKKl6mbY5e13]

@tyantreides

Du kannst uns teilhaben lassen, wenn du den github-Link zu deinem Projekt teilst.

[Tyantreides]

@ofbeqnpolkkl6mby5e13
Das kann ich gern zu einem späteren Zeitpunkt mal machen.

Aber da wird wohl vorher noch der ein oder andere Refactor Zyklus notwendig sein.
Man will sich ja bei Github auch nicht blamieren :)

Andererseits hätte das vielleicht ohnehin nur informativen Charakter. Denn in der aktuellen Form lässt sich das Projekt nur schwer mit der Codebasis aufsetzen, da einiges auch noch mit Scriptlogik im iobroker gestrickt ist.

Aber dennoch, könnte eine Veröffentlichung vielleicht neue Impulse oder Verbesserungen bringen. Ich überlege es mir. :)

[darkiop]

Spannend was du gebaut hast!

Die ioBroker Devs haben eine Telegram Gruppe, die ist vielleicht was für dich. @apollon77 kann dir da sicherlich etwas zu sagen.

[Tyantreides]

@darkiop danke für den Tip
Habe soeben mal auf einen Threat geantwortet und @apollon77 direkt geschrieben.
Er hatte in dem Zusammenhang über die Arbeit am Alias Adapter gesprochen. Also genau die Baustelle, die mir da Kopfzerbrechen bereitet.

Vielen Dank nochmal.

[da_Woody]

@tyantreides ah, daher kommt das posting, auf das ich dir gerade geschrieben habe. :)
so wie ich dich verstehe, versuchst du was in richtung iQontrol zu basteln.

[Tyantreides]

@da_woody haha. hab Dir gerade geantwortet und auf diesen Threat verwiesen :)

iQontrol - kannte ich noch nicht. Hab kurz mal reingeschaut.

Der Nachteil als Adapterlösung ist natürlich das Korsett das Adaptertanzbereichs im iobroker.
Das sieht man auch schön an der über 13000 Zeilen langen index.js von iQontrol.

Mein Ansatz hat natürlich den Nachteil einer externen App, die ja irgendwo außerhalb des iobroker laufen muss. Aber dem Problem habe ich mit der Wahl auf "react native" zu Entwickeln bereits von Anfang an Rechnung getragen. So kann man das "Hosting" für sein Frontend quasi auf das Anzeigegerät auslagern und ist bei der Entwicklung was die Struktur der App angeht nicht so eingeschränkt.
Und da tat sich leider das Problem mit der Kommunikation zwischen iobroker und app auf :)

Aber ich glaube, diese Probleme bestehen auch für Adapterentwickler. Wenn ich mir die ellenlangen Devicemappings im iqontrol so angucke....
Oder die if, elseif else Wüsten die da drin stehen.

Allein für eine Rollenzuordnung gibt es ein switch statement mit fast 150 Zeilen.....
29 cases welche zum grossteil noch mit if elseif und else gespickt sind.....
WER wartet so etwas?

Mit Programmierung hat das für mich nichts mehr zu tun :)

[Jabba_the_Hutt]

:D
Früher war Programmieren anders ... jeweniger Codezeilen, desto besser war der Programmierer. Speicher war knapp.

React ist ein verdammt guter Ansatz ... hatte ich mir auch überlegt aber aus Zeitgründen dann nicht weiter verfolgt.

[Tyantreides]

@jabba_the_hutt said in Mein nicht VIS Ansatz:

:D
Früher war Programmieren anders ... jeweniger Codezeilen, desto besser war der Programmierer. Speicher war knapp.

React ist ein verdammt guter Ansatz ... hatte ich mir auch überlegt aber aus Zeitgründen dann nicht weiter verfolgt.

Ach so "früher" ist der Ansatz eigentlich gar nicht :)

Ich bin beileibe kein Programmierer, der auf Teufel komm raus alles in 2 oder 3 Zeilen schreibt.
Das ist heutzutage Dank nodejs ja durchaus möglich auch komplexe Logiken in Einzeiler zu verwandeln.

Ob das dann zur Wartbarkeit des Codes beiträgt bezweifele ich.

Nein guter Code ist aus meiner Sicht, wenn eine App so strukturiert ist, dass man mit wenig Zeitaufwand verstehen kann was passiert.
Nur dann kann man sinnvoll und strukturiert daran arbeiten.

Wenn es im Code notwendig wird, ein Objekt durch ein 150 Zeilen Logik Monster zu jagen um zu entscheiden was dann unter welchem Umstand passiert wenn Wert X < Wert Y ist aber nur wenn Wert Z String A entspricht, läuft doch was falsch.

Das hat aus meiner Sicht in einer abbildenden App nichts verloren. Darum ist es ja so schade, wenn die Quelle die Daten nicht einer differenzierten Anforderung entsprechend aufbereiten kann.

Na mal sehen. Vielleicht schreibe ich auch einen eigenen Adapter, der mir nur die Datenstruktur zusammenstellt. Das wäre ein Kompromiss.

Aber "Zeit" ja da sagste was. Die ist als Privatperson in Vollzeitbeschäftigung natürlich knapp.
Naja ganz ohne Druck. Sehe das für mich als Hobby und Herausforderung.
Und wenn ich dabei was für meinen Job lernen kann um so besser. Habe schon das ein oder andere React Projekt beruflich durch. Von daher einen guten Start gehabt.
React Native ist neu für mich. Hat aber erstaunlich gut funktioniert bis hier.

Ich beginne aktuell auch tatsächlich zu erkennen, wie groß der Bedarf nach einer guten Visualisierung in der Community ist. Sind wir ehrlich... VIS ist mächtig aber alles was ich damit bisher gesehen hab versprüht immer so den Charm wie die Anzeige einer Flugzeug Boardamatur oder recht statisch.

Aber vielleicht stecke ich in dem Thema einfach nicht genug drin um die Geheimtips zu kennen.

[Jabba_the_Hutt]

Ich war Programmierer bei Nixdorf ;) Damals 1989. Da war der Speicher sehr knapp und Business Basic bei Nixdorf noch modern.

Widerstrebte mir damals zwar, da ich Assembler, Cobol, Pascal auch konnte und die für mich sinnvoller als Basic waren... was solls ... das Geld hat gepasst.

React ist recht einfach zu verstehen ... alles nur übungssache ;)

VIS hat viel mit CSS und auch HTML zu tun. ich finde VIS sehr ausgereift und auch gut. Klar musst du dich mit "Webdesign" beschäftigen .... aber wenn ich ne eine für mich angepasste Anzeige haben will von ner Software ... dann habe ich zwei Möglichkeiten:

1.) Kaufen
2.) Lernen und selbst machen

[da_Woody]

@tyantreides sagte in Mein nicht VIS Ansatz:

haha. hab Dir gerade geantwortet und auf diesen Threat verwiesen

jap, das hat sich überschnitten... :D

iQontrol - kannte ich noch nicht. Hab kurz mal reingeschaut.

das dachte ich mir, deswegen hab ich dich darauf hingewiesen. wer das wartet? tja, der @s-bormann halt. ;)
iQontrol gibts ja noch nicht so lange, ist aber in kurzer zeit mächtig geworden und vieles könnte sicher schlanker sein, allerdings ist da in kurzer zeit extrem viel dazugekommen durch userwünsche wodurch sich so ein ding halt schnell aufbläht. die urversion war sicher um einiges kürzer. aber, wenn du wirklich weitermachst mit deinem projekt wirst du das sicher schnell merken, das du nicht alle userwünsche bedacht hast. :D dann wird hier und dort was dazugeflickt und schon wird aus deinen sauberen anfangszeilen eine zeilensammlung, überspitzt ausgedrückt.
aber ich bin kein programmierer, bis auf die urzeiten auf dem C64 mit basic, kann mir aber gut vorstellen wie das so ist.

[Tyantreides]

@da_woody
Tja einen Vorteil hat man wenn ein Projekt noch nicht ausgerollt ist.
Man muss nicht auf Userwünsche eingehen :)

Aber selbst wenn Sachen dazukommen sollen....
Ich bin was Abstraktion angeht schon selbst hart genug zu mir.
Ich arbeite wo immer es geht mit modularen Elementen, die durch Logikschichten miteinander verknüpft werden.
Einzelne Funktionalitäten können dadurch hinzugefügt oder entfernt werden ohne viel am rest der App ändern zu müssen.
Dadurch fallen mir sehr selten Dinge auf die Füße die ich nicht schon im Vorfeld bedacht habe.

Ich möchte allerdings auch in keinem Fall so explodieren wie iQontrol. Der junge Mann hat ja zum Teil täglich Features hinzugefügt. Die Zeit hätte ich gar nicht.
Andererseits schlägt sich dieser straffe Zyklus auch in seiner Codequalität nieder.
Mein Ansatz ist auch ein anderer. Ich möchte meine Oberfläche nicht so überladen.

Seine Menüführung ist für das was er implementiert hat auch nicht wirklich durchdacht. Er ist halt jung und seine Featurepalette hat seine Appstruktur bereits überholt.

[da_Woody]

@tyantreides ich bin da sehr wohl bei dir! genau das war das problem. täglich neue wünsche der user, vllt auch unerfahrenheit, ich kanns nicht wirklich beurteilen. aber, das kannst du ihm nicht absprechen, er bemüht sich echt.
ich glaube auch deinen ansatz zu verstehn. die grundsubstanz bleibt gleich erweiterungen kommen dazu. ala shelly adapter, soweit ich den behirnt habe. neues gerät, neue funktionen im eigenen bereich.
klar, die beste lösung, das teil neu schreiben. aber da sind wir wieder bei: freizeit, lust und laune... ;)

[Tyantreides]

@da_woody
Klar seine Bemühungen in allen Ehren. So ein Projekt auf die Strasse zu bringen Respekt.
Er ist offensichtlich sehr begabt was die Programmierung angeht. Allerdings fehlt ihm in bestimmten Bereichen die Erfahrung. Das sieht der erfahrene Entwickler an bestimmten Designentscheidungen, die er getroffen hat. (Meine damit nicht die Optik)
Ja un wie gesagt... manchmal ist es für ein Produkt schlicht besser, nicht gleich den ersten Ansatz zu implementieren, der einem als Lösung für ein Problem in den Sinn kommt.
Und ich behaupte mal, dass er diese goldene Regel bei der Featuredichte nicht immer berücksichtigt hat :)
Das ganze wirkt auf mich leider sehr überladen.

[da_Woody]

@tyantreides vllt schreibst du ihn mal an? möglicher weise kommt da noch was besseres raus?
ich will mich da nicht reinmischen, aber wenn jeder sein eigenes süppchen kocht, bringts im endeffekt nix. der eine kommt mit dem klar, der andere mit was anderem.
ok, ich schreib da jetzt pro iQontrol, weil ichs einfach gut finde und mit anderen visus nicht so ganz klar komme. iQontrol gestartet, bumzack hatte ich eine grundstruktur. das man dann latürnich tiefer gehn muss, ist klar. geräte kombinieren, zusammenfassen. mit vis hat man unendliche möglichkeiten, aber eben fehlt mir das CSS kenntniss und co.
gibt aber auch Jarvis und was weis ich noch für visus. sorry, wenn ich da nicht alle beim namen nenne. :)

diese goldene Regel bei der Featuredichte

das ist ja was ich meine, die userwünsche haben ihn überrannt. aber das ist nicht nur bei dem adapter so, das betrifft auch andere, die mit visu gar nichts zu tun haben... ;)

[Tyantreides]

@da_woody Ja mal sehen.
Überdenke im Moment erstmal meine Datenstruktur mit Hilfe der Informationen, die apollon mir gab.

[da_Woody]

@tyantreides :+1: gerade gelesen...