Neues YouTube-Video: Visualisierung im Devices-Adapter

[Jey Cee]

@mcm1957 Hauptgrund war das angedacht war den Adapter auf eine library um zu bauen die bereits sehr viele Feiertage kennt und das Du Weltweit.

Das Hindernis ist und war das der Adapter dann als daemon laufen müsste, nur damit die Konfiguration möglich ist.
Der Aktuelle Workaround ist auch nicht so toll, da wird das Instanz Objekt geschrieben jedes mal wenn man in einem Dropdown was auswählt.

[mcm1957]

Hintergrund warum ich auf dieses Topic wieder gestoßen bin ist dass @krobi den Feiertagsadapter "neu schreiben" möchte. Zumindest hab ich das so verstanden. Welche konkreten Problem gefixed werden sollen weiß ich nicht. Macht aber nur bedingt Sinn da zwei gleichartige Adapter zu entwickeln / warten.

Was @krobi genau anders machen will - unter Beibehaltung der jetzigen Funktionalität und Schnittstelle für user müsste er selbst beschreiben. Ein reines ReWrite durch eine AI ohne Vorteile für Nutzer sehe ich nur bedingt als sinnvoll. Ev. könnt ihr euch ja mal austauschen ob es da Synergiene ergeben kann.

[krobi]

Da hier gerade mein Vorhaben angesprochen wurde, vielleicht kurz zur Einordnung, damit kein falscher Eindruck entsteht.

Mein Ziel war nie, einfach den bestehenden Feiertagsadapter durch einen AI-Rewrite zu ersetzen oder parallel Konkurrenz aufzubauen. Ich wollte eher ausprobieren, wie ein moderner Ansatz aussehen könnte und ob sich zusätzliche Funktionen ergeben, die für Nutzer praktisch sein könnten.

Repository:

ioBroker.feiertage (mein Repository)

Der Ansatz bringt aktuell u.a.:

• 206 Länder komplett offline über date-holidays
• automatische Brückentage (Do→Fr, Di→Mo)
• Filter nach Feiertagstypen (public, bank, school, optional, observance)
• einzelne Feiertage per ID ausschließbar
• Schedule-Mode (Berechnung einmal täglich um Mitternacht)
• zusätzliche States wie today, yesterday, tomorrow, dayAfterTomorrow und next
• mehrsprachiges Admin-UI + lokalisierte State-Namen
• TypeScript + jsonConfig + Tests/CI

Ich bin kein klassischer Entwickler und versuche einfach etwas beizutragen und zu helfen. Der Code wird sicher noch Verbesserungen und Reviews brauchen.

Durch die Diskussion hier bin ich jetzt auch erst auf frühere Ansätze bzw. Ideen wie public-holidays gestoßen – das hatte ich beim Start gar nicht auf dem Schirm. Ziel war also nie, bestehende Arbeit zu ignorieren oder bewusst etwas Doppeltes aufzubauen.

Falls sich daraus Synergien ergeben oder Teile davon sinnvoll in bestehende Projekte einfließen können, wäre mir das sogar lieber als langfristig mehrere parallele Lösungen zu pflegen.

[mcm1957]

Ist dieser Adapter mit dem bestehenden Adapter vollständig kompatibel?
Sprich - die Einstellungen der Benutzer werden bei einem Update übernommen?
Existierende States bleiben unverändert erhalten? (Neue zusätzliche States wären ok)?

So wie es für mich aussieht, sollte das ein NEUER Adapter werden und nicht eine neue Version von Feiertage. Da das Ganze auch internationaler zu sein scheint passt der deutsche Name auch nicht mehr.

[krobi]

@mcm1957, hier wird die Date-holidays als Datengrundlage verwendet. Die Änderungen betreffen hauptsächlich die sprachliche Anpassung. Der aktuelle Adapter ist hauptsächlich auf Deutsch ausgelegt, während meine Version international ist und daher die Datenpunkte auf Englisch mit Sprachvarianten in den Beschreibungen vorliegen. Ich werde mir die Einstellungen noch einmal genauer ansehen. Im aktuellen Adapter kann man Feiertage per An- oder Abhaken auswählen oder abwählen. In meiner Version müsste man die IDs angeben, was sicherlich noch verbesserungswürdig ist. Grundsätzlich ist dies eine Variante mit dem neuen Datensatz, anstatt die Feiertage selbst pflegen zu müssen.

[Jey Cee]

@krobi sagte:

Der aktuelle Adapter ist hauptsächlich auf Deutsch ausgelegt, während meine Version international ist und daher die Datenpunkte auf Englisch mit Sprachvarianten in den Beschreibungen vorliegen.

Das war auch der Grund warum ich den Adapter neu geschrieben habe und einen anderen Namen verwendet habe.

Läuft deine Version als Daemon oder Scheduled?

[mcm1957]

Ja seh ich auch so @krobi
Da der Adapter ja auch technisch abgekoppelt ist (kein fork) benenn ihn sinnvoll um (englisher Name) und stell ihn als neuen Adapter zur Verfügung. Bitte stimm dich mit @jey-cee ab ob es ev. Funktionalitäten gibt die sinnvoll in deinen Adapter aufgenommen werden sollten.

P.S. Die state IDs dürfen keinesfalls sprachspezifisch sein - die müssen fix english benannt werden. Namen mehrsprachlich ist ok, das geht aber trivial indem als name ein i18n Objekt übergeben wird. Dass Namensfeld sollte auch NICHT bei einem Adapterneustart überschieben werden, da es der User ändern darf. (Flag bei extend Object setzen)

[Jey Cee]

@krobi ich hab jetzt mal kurz in den Code bei dir geschaut, du hast ihn als Daemon umgesetzt. Edit: Keine Ahnung wo ich da geschaut habe, aber jetzt hab ich gerade am Laptop nochmal genauer geschaut und sehe das es Scheduled ist.

Warum ich das nicht wollte: Jeder Prozess der Dauerhaft läuft verbraucht RAM und das ist bei Nodejs mit 60+MB nicht gerade wenig. Im Falle des Originalen und meines Adapters braucht es das aber gar nicht weil die Eigentliche Logik nur einmal am Tag für 1 Minute ausgeführt werden muss.
Den Rest der Zeit läuft das dann nur um zu warten das der Benutzer etwas an den Einstellungen ändert.

Mein letzter Ansatz war es statt dem Workaround die Gesamte Logik die für die Konfiguration nötig ist, in die JSONConfig zu Quetschen. Das hab ich jedoch nicht zum laufen bekommen.

Alles andere scheint dem wie ich es umgesetzt habe sehr ähnlich zu sein. Da dein Adapter sonst im direkten vergleich deutlich weiter ist, würde ich vorschlagen du benennst ihn in public holidays um und ich archiviere meinen. Du bekommst rechte für npm auf das Paket, dann kannst du ihn unter dem Namen auch Veröffentlichen.

[mcm1957]

Wenn der Adapter nur was zu tun hat, wenn der User was ändert dann sollte das auch bei sheduled Adaptern gehen. Wenn das flag common.allowInit (https://github.com/ioBroker/ioBroker.js-controller/blob/a9d7fcfdd288a7f7e07bc1c175a89c12a11cfdfe/schemas/io-package.json#L1248) gesetzt ist, startet der Adapter einmal nach dem Abspeichern der Config zusätzlich zur normalen Konfiguration via schedule. Wäre das nicht das was du suchst?

P.S: Ich finde es toll dass / wie ihr miteinander kommuniziert und beide am Ziel "Adapater für User" kooperativ arbeitet. DDAANNKKEE

[krobi]

@Jey-Cee @Jey-Cee Hallo :-) also die Grundidee ist und war natürlich die selbe wie im aktuellen Adapter, einmal am Tag starten und fertig. da hast du vollkommen recht. Das sollte auch so implementiert sein. Was ich mich noch erinnern kann, musste man das beim Feiertagsadapter manuell eintragen, was mich damals verwirrte - vor Jahren, wo der iobroker noch ganz neu für mich war, war das mega überfordernd.

Daher hab ich Claude.ai direkt gesagt, er soll das quasi hardcoden und einfach immer Mitternacht direkt vor-eintragen, weniger Userinteraktion ist gut und ich habe die Philosophie, dass ein Adapter die Arbeit machen soll, nicht der User.

Zum Grundgedanken, nach der Recherche meinte Claude.ai eben, dass die Bibliothek ganz cool wäre, dann müsste man sich nicht selbst um die Daten kümmern und die Bibliothek wird ständig gepflegt - sehe ich in vielen Stellen als win-win - für den Nutzer echte und aktuelle Daten, für "uns" quasi extrem geringer Pflegebedarf und direkt international, aber dennoch bleiben wir im Fokus des Adapters.

@mcm1957 danke für den Hinweis mit den IDs werde ich direkt berücksichtigen.

[mcm1957]

Verwende bei den Namen einfach ein i18n object. Dann braucht der Adapter das auch bei einer Sprachumstellung nicht irgendwie zu bearbeiten. Macht dann alles admin. Also einfach common.name = {en:'today', de::'heute', ...) Den Block erzeugt dir der ioBroker webtranslator fix und fertig (translator_ui.iobroker.in). Den privaten Code zum Übersetzen kannst dann rauswerfen. Den gibts sowieso als i18n support im adaptercore.

[Jey Cee]

@krobi sagte:

ich habe die Philosophie, dass ein Adapter die Arbeit machen soll

Genau das ist auch meine Meinung. Am liebsten wäre mir wenn die Adapter (alle die Standort abhängig sind) auch den Standort aus der iobroker Config nehmen und anhand dessen das richtige Auswählen.
Das ist aber gar nicht mal so einfach ohne auf irgendeine API zurück zu greifen.

Gib mir mal deinen Namen auf npmjs, dann kann ich dich einladen.