Im Forum existieren mehrere Themen, wie man aus einem iCal-Kalender die Müllabfahrtzeiten extrahieren kann. Dafür werden immer wieder Blockly und JavaScript-Funktionen geteilt. Ich dachte mir, dass es doch viel schöner wäre, wenn das ein Adapter erledigen könnte.

Die Idee kommt aus dem FHEM-Umfeld, wo das ABFALL-Modul genau das gleiche macht. Auch dort wurden zuvor viele Funktionen bereitgestellt und jeder hat das Thema anders gelöst.

Dieser Adapter nimmt eine iCal-Instanz als Quelle und durchsucht die nächsten Events nach den vorher definierten "Abfall-Typen". Wird ein Typ gefunden, werden die Tage bis zur Abholung berechnet und in einem State bereitgestellt. So entsteht eine Struktur, welche als Basis für VIS o.ä. genutzt werden kann.

Weiterhin gibt es eine Zusammenfassung der nächsten Abholung, wenn mehrere "Abfall-Typen" auf einmal abgeholt werden. Diese kann man zum Beispiel für Pushover- oder Telegram-Nachrichten nutzen.

Konfiguration

Gelöscht. Bitte die aktuelle Doku nutzen: https://github.com/klein0r/ioBroker.trashschedule/blob/master/docs/de/README.md

Wichtige Änderung ab Version 1.1.0

Leider musste ich die Namen der Datenpunkte aufräumen, da immer wieder Quatsch dort reingeschrieben wurde. Solltest Du also Scripts oder eine Visualisierung auf den Datenpunkten der einzelnen Abfalltypen haben, müssen diese kontrolliert und ggf. angepasst werden.

Reihenfolge um ab Version 1.0.1 wieder Daten zu bekommen (in VIS)

1. Trashschedule Instanz stoppen
2. Alle Datenpunkte des Adapters löschen (also von trashschedule.0). Einfach in der Objektansicht auf die Mülltonne klicken und weg damit.
3. In der Expertenansicht der Adapterliste erst bei Trashschedule auf Upload klicken, dann bei VIS
4. iCal einmal Instanzliste neustarten, dann Trashschedule wieder starten
   Danach sollte alles wieder richtig sein.

Auch in dieser Version gibt es wieder viele neue Blöcke, Bugfixes und Features. Das wichtigste zuerst:

Besten Dank an alle Teilnehmer des ioBroker-Master-Kurses. Ihr habt die vielen Stunden Entwicklung (wie immer) finanziert. Natürlich werde ich die neuen Bausteine und Feature auch dort in neuen Lektionen noch ausführlich zeigen und erklären.

Blockly-Bausteine für Objekte

Ich konnte es nicht mehr sehen, wie hier einige mit Text-Bausteinen JSON-Strings zusammenbauen. Super lange Verkettungen von Text, und am Ende wurde ein Komma abgeschnitten, damit das JSON gültig ist. Schlimm - aber das war in Blockly leider bis dato die einzige Möglichkeit neue Objekte zu erstellen.

Das ist jetzt anders. Du kannst ein neues Objekt anlegen und die Attribute frei (im Blockly) definieren. Das klappt einfach über das "Zahnrad" des Bausteins (wie bei vielen anderen Blöcken auch).

Nachträglich weitere Attribute hinzufügen geht selbstverständlich auch:

Entfernen von Attributen funktioniert genauso per Block. Also alles, um endlich einige Strukturen abzulösen. Die Objekt zu JSON-Blöcke gibts ja schon länger. Und dann bekommst Du auch direkt "sauberes" JSON und kannst damit weiterarbeiten. Oder Du schreibst das Objekt direkt in einen Datenpunkt vom Typ object oder array - dann passiert die Konvertierung ganz automatisch. Aber das kennst Du ja wahrscheinlich schon und ist erstmal nix neues.

HTTP-Funktionen

request ist ja leider schon lange deprecated und die Blockly-Bautsteine generieren JavaScript-Code, welcher das Paket mit require direkt lädt. Das ist nicht so der Hit und wurde mal Zeit für eine Überarbeitung. Daher gibt es nun neue Blöcke. Nicht nur für GET, sondern auch für POST.

Der "alte" request Block erzeugt jetzt eine deprecated warning und wird irgendwann entfernt. Daher bitte auf die neuen Blöcke umstellen!

Intern unterstützt die Funktion auch Basic- und Digest-Authentication und eigene HTTP-Header - das ist nur noch nicht im Blockly-Baustein verfügbar. Ich muss mal schauen, wie das Thema angenommen wird und ob es dafür Bedarf gibt. Dann erweitere ich die Blöcke natürlich. Für die JavaScript-Varianten bitte in die Adapter-Doku schauen.

Installation des Adapters

Bitte ganz normal über das Beta-Repository oder das npm-Tab und NICHT über GitHub! Fragen dazu beantworte ich erstmal nicht. Absolute Grundlagen gibts an anderer Stelle ganz ausführlich.

Auch in dieser Version gibt es wieder viele neue Blöcke, Bugfixes und Features. Das wichtigste zuerst:

Besten Dank an alle Teilnehmer des ioBroker-Master-Kurses. Ihr habt die vielen Stunden Entwicklung und Support (wie immer) finanziert. Natürlich werden die neuen Bausteine und Feature auch im Kurs ausführlich gezeigt und erklärt.

Blockly-Trigger für Logs

Das Thema ist in JavaScript nicht neu. Es gab nur keine Blockly-Bausteine dafür. Also habe ich diese nun nachgereicht.

Damit kann man einen Trigger auf Log-Meldungen registrieren und ein Log-Level vorgeben. Das heißt, dass man z.B. alle Meldungen vom Level error bekommen kann und dann z.B. prüfen, welche Instanz (Quelle) die Meldung ausgelöst hat.

Blockly File-Events (Temporärer Dateipfad)

Das Datei-Thema kommt ja hier immer wieder auf - und viele schreiben und lesen direkt aus /opt/iobroker/iobroker-data/files/. Das man das nicht tun sollte und dafür IMMER die ioBroker-Funktionen nutzen sollte, habe ich ja mittlerweile rauf und runter erklärt.

Wenn man als Datenbank nicht jsonl sondern redis nutzt, dann liegen die Dateien ja nichtmal an dieser Stelle im Dateisystem, sondern in der Redis-Datenbank. Das Problem ist nun: Wenn sich eine Datei ändert, dann kann man damit in Blockly noch nicht viel machen. Bausteine wie Pushover, Mail, Telegram usw. wollen einen Pfad zu einer Datei haben. Das Thema habe ich auf GitHub auch schon platziert.

Nun gibt es aber bei einer Redis-Datenbank keinen Pfad im Dateisystem. Also habe ich eine neue Funktion gebaut, welche die Datei aus dem "ioBroker-Speicher" in das Temp-Verzeichnis des Betriebssystems (unter Linux /tmp) speichert und einen Pfad zurückgibt.

Sobald das Script gestoppt wird, wird in diesem Pfad wieder aufgeräumt und die temporären Dateien werden gelöscht!

Jedenfalls kann man auf diesem Weg aktuell weiterhin Bausteine wie Telegram bedienen und jedes Mal wenn sich eine Datei ändert diesen Pfad generieren und an andere Bausteine weiterreichen. Beispiel:

Warnungen

Eigentlich gibt es jetzt an jeder Stelle ein Ausrufezeichen im Block, wenn man etwas zusammenbaut, was so nicht gedacht ist (z.B. Trigger in Trigger). So sollte man eigentlich direkt während der "Programmierung" merken, dass da etwas falsch ist.

Solltet ihr noch Vorschläge für Validierungen haben (wo darf ein Block nicht in einem anderen enthalten sein): Her damit.

Request-Paket is deprecated

Request wird seit Jahren im Adapter genutzt und der Blockly-Baustein "request" nutzt ja genau dieses Paket. Der Block wurde ja bereits in den vorigen Versionen durch "http (GET)" ersetzt. Solltest Du noch die älteren Blöcke nutzen, bekommst Du eine Warnung im Log.

Ich möchte das Paket jetzt langsam aber sicher loswerden. Daher generiert jedes require('request'); im Log jetzt auch eine Warnung. Scheinbar werden die Changelogs ja nicht gelesen, weswegen man am Ende wohl in überraschte Gesichter schauen wird, warum ein Script nicht mehr läuft. Also: Migriert eure Scripts! Und wenn ihr hier im Forum jemanden seht, der Code mit require('request'); teilt: Bitte entsprechend darauf hinweisen.

In der Zukunft wird das Paket dann endlich aus dem Standard entfernt und nicht mehr mitinstalliert. Man kann es zwar in den Instanzeinstellungen dann manuell noch hinzufügen, aber das ist nicht zu empfehlen. request ist seit über 4 Jahren deprecated und wird nicht mehr weiter entwickelt! Einfach nicht mehr nutzen...

System-Variablen

Seit Version v8.0.0 gibt es unter "System" außerdem noch ein neuen Baustein. Über diese kann der Name des Scripts, der Standard-Verzeichnispfad oder der Status des Verbose-Modus des Scripts ausgegeben werden.

Damit könnte man z.B. verbose-Nachrichten schreiben oder Log-Meldungen ändern, wenn der verbose-Modus aktiv ist (hab ich im ioBroker-Master-Kurs auch erklärt, ...):

Vorbereitung auf js-controller 6.x

Das Abhängigkeitsmanagement (für zusätzliche Pakte in den Instanzeinstellungen) bringt in der aktuellen npm-Version ein paar Probleme mit sich. Diese werden im js-controller 6.x adressiert und es gibt auch schon die erste Implementierung der neuen Funktionen. Mehr dazu, sobald der js-controller 6 in einer beta verfügbar ist.

Oberfläche

Die Darstellung des Logs hat sich nun auch leicht geändert und wurde an den Admin angepasst. Die erste Spalte (Quelle) ist neu. Dafür wird in der Meldung selbst die Instanz nicht mehr angezeigt (wie im Admin halt).

Ansonsten habe ich aus den pixeligen Grafiken zum Umschalten von Blockly/JS und Rules/JS mal Vektorgrafiken gemacht die auch skalieren. Auf Retina-Displays sah das vorher ja schlimm aus

Der Adapter ist nun im Stable- und Beta-Repository - bitte NIE über GitHub installieren, sonst gibt es hier keinen Support...

YouTube-Video zum ioBroker-Adapter

Wichtig

• Admin-Adapter in Version 6.6.0 erforderlich!
• Erst die Dokumentation lesen, dann fragen: https://github.com/klein0r/ioBroker.awtrix-light/blob/master/docs/en/README.md
• Die Awtrix-Light-Doku ist ebenfalls sehr aufschlussreich: https://blueforcer.github.io/awtrix-light/#/README

Hier geht es um den Adapter. Nicht um Paket-Tracking, nicht um den verbauten Akku oder ob einem das Gerät gefällt oder nicht. Daher bitte beim Thema bleiben - ich bekomme für jeden Kommentar eine Notification (davon habe ich eh schon zu viele). Gerne einen weiteren Thread öffnen und über die Möglichkeiten, eigene Umsetzungen usw. diskutieren. Danke!

Warum?

Da ich ja schon seit einigen Jahren den Adapter für die LaMetric Time entwickle, möchte ich auch die relativ neue TC001 von Ulanzi (Affiliate-Link - AliExpress) in den ioBroker bringen. Damit das klappt, muss das Gerät mit einer alternativen Firmware geflasht werden: Awtrix Light. Das geht über den USB-Port aber super einfach.

Bisher habe ich schon einige Datenpunkte / Funktionen in den ioBroker gebracht. Wenn Du gar nicht weiß worum es geht, habe ich hier ein Video veröffentlicht: https://www.youtube.com/watch?v=Wr8fHErJI0o

Die Frage ist jetzt natürlich, wieviel Zeit ich in den Adapter investiere und wie groß das Interesse ist. Ich persönlich finde das Gerät richtig interessant und werde die für mich nötigen Funktionen integrieren.

Der Thread hier dient (wie immer) neben GitHub für das Bug-Tracking, Feature-Wünsche und Support bei Fragen.

Auch in dieser Version gibt es wieder viele neue Blöcke, Bugfixes und Features.

Anpassung der HTTP-Bausteine

Neben der Timeout-Option ist jetzt auch der Antwort-Typ dazu gekommen. In 99% der Fälle möchte man wahrscheinlich einfach nur Text haben - um damit im Blockly weiter zu arbeiten und z.B. JSON von einer API im Baustein weiter zu arbeiten / in ein Objekt zu wandeln usw. (hab ich ja ausführlich erklärt).

Aber jetzt kann auch ein arraybuffer angefordert werden. Also "Rohdaten".

Wozu das Ganze? Damit man das "Dateien-Feature" nutzen kann und z.B. eine neue Datei ablegen. Siehe nächster Punkt.

Datei schreiben / lesen

Trigger auf Dateien konnte man schon lange erstellen. Also reagieren, wenn eine Datei im Dateien-Tab angepasst wird. Nutzt aber wahrscheinlich kaum jemand, oder? Das liegt wahrscheinlich dran, dass man mit Blockly bisher keine Dateien erstellen konnte. Das hat sich in 7.11.0 geändert.

Angenommen Du möchtest regelmäßig ein Bild der Außenkamera holen und ablegen (oder bei Bewegung von einem Bewegungsmelder - was auch immer). Dann nimmst Du einfach den http-Baustein, holst das Bild und legst es in einen Meta-Speicher (das Konzept habe ich im ioBroker-Kurs ja auch erklärt... kennst Du als ioBroker-Profi und Beta-Tester längst).

Damit gehören die umständlichen exec -> wget -O ...-Befehle hoffentlich der Vergangenheit an Als nächstes möchte ich z.B. den Telegram-Adapter erweitern, damit auch diese Dateien versendet werden können.

Wie geht es dann weiter? Du könntest einen Trigger auf alle Kamera-Bilder registrieren und dann darauf reagieren. Wie gesagt, diesen Trigger gab es ja schon länger - nur hat den kaum jemand genutzt (glaube ich). Hier werden ja auch Wildcards usw. unterstützt.

Neu ist allerdings, dass ich dafür auch einen Baustein (wie bei den State-Triggern und http-Bausteinen) erstellt habe, um die Parameter direkt nutzen zu können und um nicht irgendwelche Variablen erstellen zu müssen (die genau den richtigen Namen haben müssen). Damit kommt man dann alle Infos aus dem Trigger:

Genaus könnte man natürlich json schreiben:

Oder irgendetwas anderes. Möglichst flexibel halt. Wünsche?

Lesen von Dateien klappt natürlich genauso:

Also einfach ein JSON lesen, etwas anfügen oder ändern und dann wieder speichern. Kein Problem mehr.

Fehlt Dir etwas?

Installation des Adapters

Bitte ganz normal über das Beta-Repository oder das npm-Tab und NICHT über GitHub! Fragen dazu beantworte ich erstmal nicht. Absolute Grundlagen gibts an anderer Stelle ganz ausführlich.

Ihr macht das möglich

Besten Dank an alle Teilnehmer des ioBroker-Master-Kurses. Ihr habt die vielen Stunden Entwicklung (schon wieder) finanziert. Natürlich werde ich die neuen Bausteine und Feature auch dort in neuen Lektionen noch ausführlich zeigen und erklären.

@markus84 sagte in Kostenpflichtige iobroker Adapter:

Darf jeder Entwickler für seinen Adapter verlangen was er will? Gibt es diesbezüglich irgendwelche Vorgaben bzw. beabsichtigt ihr welche?

Was spricht denn aus Deiner Sicht dagegen? Am Ende schafft man ein Angebot. Und wenn es eine Nachfrage gibt, ist doch super? Jeder entscheidet selbst, ob man das Angebot annehmen möchte. Du schreibst es ja selbst: seinen Adpater. Sollte z.B. wirklich eine Pro-Variante von Jarvis kommen: Why not? Stell Dir mal vor, dass dadurch jemand ein zweites Standbein aufbaut, mehr Zeit für diesen (und andere) Adapter hat, besseren Support bietet und die Entwicklung schneller wird. Gewinnen dann nicht am Ende alle? Und wem das nicht passt, der weicht auf einen der anderen Visualisierungs-Adapter aus.

Ich verstehe die Diskussion nicht. Momentan sprechen wir von 3 Adaptern von über 400. Also nichtmal 1%. Hier wird so getan, als ob man plötzlich 30€ pro Monat zahlen müsste, um den ioBroker überhaupt noch zu verwenden. Da ist absolut kein Trend zu erkennen.

Du könntest dem Ganzen ja auch entgegen wirken, indem Du einfach selbst einen KNX-Adapter programmierst und den besseren Support dafür bietest? Dann würde niemand mehr die kostenpflichtige Variante kaufen.

Komischerweise stößt niemand eine Diskussion an, ob die vielen tausend Stunden Entwicklung des Core-Teams nicht honoriert werden sollten. Oder wie man sich an den Kosten für Serverinfrastruktur (Forum, Webseite) beteiligen kann. Immerhin wird überall ständig damit geprahlt, wieviel Geld man doch z.B. spart, weil man ioBroker einsetzt und nicht so blöd war, 1000€+ für einen Gira HomeServer o.ä. auszugeben.

OT: Nimm doch mal WordPress, Shopware, Magento, Typo3, oder irgendeine andere Lösung. Für alle diese Projekte gibt es kostenpflichtige Module/Extensions von Dritten. Die Grundlage ist immer OpenSource. PHP, mySQL, nginx, apache, Linux, Docker, OpenSSL, ... die Liste ist unendlich lang. Selbst für PHP gibt es kostenpflichtige Extensions. Muss ich die nutzen? Nein. Stört es mich, dass es diese gibt? Nein. Über wen muss man sich jetzt in der Kette beschweren? Die Dienstleister, welche ihr komplettes Geschäftsmodell darauf aufbauen? Freelancer, Agenturen, Hosting-Provider, ... am besten allen erstmal erklären, wieviel € sie für ihre Dienstleistung so nehmen dürfen?

Mich hat es schon öfter genervt, dass ich Scripts immer beim Export kopieren muss (und in eine neue Datei einfügen + speichern). Klar, man kann alle Scripts als ZIP-Datei exportieren, aber das brauche ich persönlich eigentlich nie.

Adapter-Version >= 7.4.0 erforderlich!

Daher gibts beim Export jetzt diesen Button:

Und beim Import kann man die Datei einfach per Drag and Drop auf diese Fläche ziehen:

Gerne mal testen, ob das alles in allen Browsers funktioniert oder ob es komische Effekte gibt. Habe soetwas das erste mal in React umgesetzt

Ich habe gerade ein Blockly-Todo erledigt, welches schon lange auf meiner Liste stand: Die Frage-Möglichkeit für Telegram umsetzen. Per JavaScript ging das ja schon sehr lange.

Die Idee ist, dass man eine Frage definieren kann und darunter mehrere Antwortmöglichkeiten (über das Zahnrad kann man mehr Antworten hinzufügen). Und dann wird eben die Logik im jeweiligen Block ausgeführt, wenn man auf die Antwort klickt. Beispiel:

Sieht im Chat dann so aus:

Das ganz muss man logischerweise in einen Trigger packen, welcher die Frage zum richtigen Zeitpunkt versendet... Logisch.

Neu ist, dass nach einer Antwort die Tastatur ausgeblendet wird. Also die Nachricht wird nachträglich bearbeitet. Es gibt (wie vorher auch schon) einen Timeout, wenn man in x Sekunden nicht auf die Frage geantwortet hat. Das ist nicht neu. Aber auch dann wird die Tastatur ausgeblendet!

Ich bitte um Feedback für die neue Funktion! Bitte ausführlich testen!

Was ich mir noch vorstellen könnte: Ein weiterer Block, welcher eine einfache Antwort auf in den gleichen Chat ermöglicht. Dann muss man nicht den großen Telegram-Text-Block öfter einfügen und die Chat-ID ausfüllen usw.

Die Version landet zeitnah im Beta-Repo. Sonst per npm installieren (NICHT per GitHub-Url installieren!).

Da das letzte Mal nicht so klar wurde: BITTE TESTEN!!!

Das hier ist ein Beta-Test im Tester-Forum. Ich brauche Feedback und Rückmeldungen - nicht nur Fehlerberichte. Also auch positives Feedback, ob sich alles verhält wie erwartet!

1. Mit Version 8.5.x wurde Blockly intern auf Version 10.4.3 aktualisiert. Leider können wir noch nicht auf Version 11 gehen, da sonst kein einziger Block aus den ganzen anderen Adaptern mehr kompatibel wäre. Jedenfalls ist daher besonders darauf zu achten, ob es komische Seiteneffekte mit Blöcken gibt oder sich etwas anders verhält als vorher. Durch die neue Version wird auch ein anderen Theme genutzt, sodass die Blöcke ein wenig anders/moderner/flacher aussehen.
2. Da die meisten Blöcke falsch definiert waren, habe ich alles überarbeitet und sämtliche Blöcke-Definitionen angepasst. Jetzt sollte es keine Warnungen mehr in der Entwickler-Konsole geben (bis auf ein paar Deprecated-Meldungen zu Mutator-Blöcken).
3. Es gibt es ein Dark-Theme, welches direkt von Blockly kommt. Das sieht jetzt also etwas schöner aus als vorher.
4. Der generische sendTo-Block hatte ein paar Macken, dass die Attribute wild durchgetauscht wurden, wenn man weiter oben z.B. ein neues Attribut definiert hat. Auch das sollte behoben sein. Dieser verhält sich jetzt genauso wie der "Neues Objekt"-Baustein, sodass man direkt im Popup (Mutator-Block) die Namen der Eigenschaften definiert.

Werte direkt bestätigen per Block

Nach einem Feature-Request auf GitHub habe ich einen neuen Block-Typ im Trigger-Bereich hinzugefügt, welcher es etwas einfacher macht, eigene Datenpunkte zu bestätigen. Dann muss man nicht erst einen "Aktualisiere"-Block mit dem Wert des Triggers erstellen. Und es liest sich etwas schöner. Danke dafür, sehr gute Idee!

Neuer Text-Block "enthält"

Ich fand es immer etwas anstrengend den "suche erstes Vorkommen von Text, ... "-Block zu nutzen, nur um zu prüfen ob ein anderer Text enthalten ist. Daher jetzt diese Variante. Bitte ausführlich testen.

Mehr Prüfungen / Warnungen

Sollte man Blöcke irgendwo positionieren, wie es nicht gedacht ist, gibt es an immer mehr Blöcken ein kleines Ausrufezeichen mit einer Warnung. Sollten Euch da noch Kombinationen einfallen, welche man auf keinen Fall machen sollte -> immer her mit den Infos!

Weitere geplante Blöcke

• Once-Trigger (siehe GitHub-Request)
• sendTo-Rückgabe (wie in den anderen Blöcken, um direkt auf das Ergebnis zuzugreifen)
• getHistory-Rückgabe (wie in den anderen Blöcken, um direkt auf das Ergebnis zuzugreifen)
• sendToHost (hat keine Prio)

@bahnuhr sagte in Tasmota übers Internet mit ioBroker verbinden.:

kannst du das näher bechreiben.

Gern, habe das mal in ein Video gegossen: https://www.youtube.com/watch?v=U5JhnktnN14

Leider muss man eine eigene Version von Tasmota kompilieren, da im Standard TLS für MQTT nicht aktiv ist. Aber auch das ist kein Beinbruch - siehe Video.

@opa75 Achso, und der Screenshot mit den dicken orangen Pfeilen war nicht hilfreich? Wozu genau fehlt Dir ein Beispiel?

@opa75 Was ist denn ein Shelly Browser?

@opa75 sagte in Problem mit dem Shelly Adapter:

Ich habe mir nochmals die Einstellung bei den Instanzen, Browser und App angesehen und da steht jedesmal 1883.

Bitte beschreib mal ganz genau, was an der Dokumentation unvollständig ist und was dort fehlt. Würde das gerne ergänzen:

https://github.com/iobroker-community-adapters/ioBroker.shelly/blob/master/docs/de/protocol-mqtt.md

@denis-claß sagte in ESP Home ohne Home Assistant möglich?:

Es gibt ja einen ESPHome Adapter über Git. Reicht der aus?

https://github.com/DrozmotiX/ioBroker.esphome

@tasuanetrukiat sagte in Objekt(Id) in Variablen?:

Wie man vielleicht sehen kann ist im Objekt ein JSON welches ich dann mit der Funktion in einen eigenen Objektbaum speichere.

Du wirfst da glaube ich ein paar Begriffe durcheinander. Es gibt

• Die Objekt ID, welche erstmal nur ein String ist
• Das Object aus der Objekt-Datenbank, welches aber ein Objekt (und kein JSON) ist
• Das State-Objekt aus der Zustandsdatenbank, dessen Wert (val) auch JSON sein kann (also ein string)

@haselchen Eigentlich egal. Hauptsache gleich. 1883 ist der Standard-Port für MQTT. Da aber viele noch einen anderen Broker laufen, welcher den Port schon belegt, wird 1882 im Shelly Adapter als Standard empfohlen.

Steht auch so in der Adapter Doku

@accuface sagte in Shelly >= 6.6.0 mit BLU-Geräten (Bluetooth Low Energy):

Ich hab in dem Video nix gesehen dass du den Code aus meinem Bild irgendwo verwendet hast.

Na guck. Daher eben der Hinweis, dass das da nur zur Info steht (was genau intern ankommt).

Nur um sicher zu gehen, die Installation der Bluetooth Paket benötige ich NUR wenn ich über den Stick und den BLE Adapter gehe, richtig?

Richtig

@accuface Nur zur Info. Die Schritte im YouTube Video sind noch aktuell

@haselchen sagte in node-red-contrib-huemagic-fork Fehler:

Die Frage aller Fragen, wieso funktioniert es bei mir ohne Mucken

Weil ihr wahrscheinlich unterschiedliche Dinge mit den Nodes macht oder unterschiedliche Komponenten ansprecht. Man müsste also genauer vergleichen um das heraus zu bekommen.

Selbst wenn ihr die gleiche Version der Node installiert habt, könnten sich die Versionen der installierten Abhängigkeiten unterscheiden.

@bergjet sagte in node-red-contrib-huemagic-fork Fehler:

habe diesen Node "node-red-contrib-huemagic-fork" seit geraumer Zeit laufen.

Die Issues stapeln sich. Und Version 4.2.8 ist von April 2023.

Das Projekt scheint generell nicht mehr gepflegt zu werden: https://github.com/mauricedominic/node-red-contrib-huemagic

Und das ist ja schon der fork. Das "Hauptprojekt" liegt ja noch länger unberührt.