Re: Externes node-RED und ioBroker. Wie verbinden ?

Hallo,

wie bereits mal in dem Parallelthread erwähnt, habe ich ein paar Nodes für die ioBroker-Anbindung für "Standalone Node-REDs" entwickelt. Nach dem ersten Entwurf auf Basis der REST-API wurde das ganze noch auf Websocket umgebaut.

Das Paket richtet sich an Nutzer (wie mich), die Node-RED unabhängig von ioBroker betreiben möchten (und nicht als Adapter).

Funktionen:

• WebSocket-Verbindung zu ioBroker (über Web-, WebSocket- oder Admin-Adapter)
• Bidirektionale Kommunikation (Lesen/Schreiben von States)
• Wildcard-Pattern für Subscriptions (z.B. system.adapter.*.alive)
• Interaktive State-Auswahl mit Suchfunktion
• OAuth2-Authentifizierung und "No-Auth"-Modus
• Automatische Wiederverbindung

Das Paket ist als "node-red-contrib-iobroker" über die Palette oder npm verfügbar und auf GitHub dokumentiert.

Falls jemand Interesse hat, das Paket zu testen oder Feedback zu geben, freue ich mich über Rückmeldungen. Besonders bei größeren ioBroker-Setups wäre Input hilfreich.
Vielen Dank!

Hinweis: Dies ist kein ioBroker-Adapter, sondern für externe Node-RED Installationen gedacht.

@mickym sagte in Warnung vor Linux update: udev/stable 247.3-7+deb11u2:

jedoch keine Ahnung wie man daraus nun die Teile installiert.

Zum Glück nutze ich Ubuntu Server, und bin damit nicht von diesem Problem betroffen, habe das Downgrade aber mal auf meinem Debian Testsystem durchgespielt:

wget https://snapshot.debian.org/archive/debian/20220829T032859Z/pool/main/s/systemd/libudev1_247.3-7%2Bdeb11u1_"$(dpkg --print-architecture)".deb
wget https://snapshot.debian.org/archive/debian/20220829T032859Z/pool/main/s/systemd/libudev-dev_247.3-7%2Bdeb11u1_"$(dpkg --print-architecture)".deb
wget https://snapshot.debian.org/archive/debian/20220829T032859Z/pool/main/s/systemd/udev_247.3-7%2Bdeb11u1_"$(dpkg --print-architecture)".deb

sudo dpkg -i libudev1_247.3-7+deb11u1_"$(dpkg --print-architecture)".deb
sudo dpkg -i libudev-dev_247.3-7+deb11u1_"$(dpkg --print-architecture)".deb
sudo dpkg -i udev_247.3-7+deb11u1_"$(dpkg --print-architecture)".deb

sudo apt install udev=247.3-7+deb11u1

hat es getan.

Das Ergebnis sieht dann so aus:

docker@debian11:~$ apt-cache policy udev
udev:
  Installed: 247.3-7+deb11u1
  Candidate: 247.3-7+deb11u2
  Version table:
     247.3-7+deb11u2 500
        500 http://debian.inf.tu-dresden.de/debian bullseye/main amd64 Packages
 *** 247.3-7+deb11u1 100
        100 /var/lib/dpkg/status

Um zu verhindern, dass beim nächsten Update die fehlerhafte Version wieder installiert wird, die Pakete auf "Hold" setzen:

sudo apt-mark hold udev
sudo apt-mark hold libudev1
sudo apt-mark hold libudev-dev

Und wenn ein bereinigtes Update zur Verfügung steht, das Ganze rückgängig machen:

sudo apt-mark unhold udev
sudo apt-mark unhold libudev1
sudo apt-mark unhold libudev-dev

@legro sagte in Raspberry Pi 4 startet nicht mehr:

Es sollte sich jeder selbst überlegen, ob er für die Entwickler den (kostenlosen) Betatester zu spielen bereit ist.

Entschuldige, aber mir geht dieser Anspruch etwas gegen den Keks. Wenn man nicht bereit ist, den kostenlosen Betatester zu "spielen", darf man einfach nicht die allerneueste Version einsetzen. Ganz einfach. Welches QS-Team soll denn all die neuen Funktionen in allen möglichen Konstellationen durchtesten? Das ist Teil der Idee hinter Open Source: Geben und nehmen (und auch ab und zu mal die Dokumentation lesen).

Umsonst ist offenbar nichts im Leben.

Doch, die Lebenszeit der Entwickler, die auch du ein Stück weit für deine Zwecke nutzt. Und die der Leute, die dich hier supporten.

@djmarc75
Ja, das kann ich auch nachvollziehen. Getoppt wird das Ganze dann noch von Usern, die massenweise hier nach Hilfe suchen, tausende Beiträge auf der Uhr haben und doch unfähig sind, sich auch mal etwas mitzuschreiben. Das führt dann dazu, dass sie (wenn sie ihr System schrotten) exakt gleiche Fragen NOCHMAL stellen, denn ein funktionierendes Backup liegt nicht vor.
Hey, wozu auch, ich bekomme doch hier jederzeit Hilfe von Menschen, die nichts anderes zu tun haben ...

Vielleicht führt dieser Thread dazu, dass sich der eine oder andere hier mal hinterfragt. Die Hoffung stirbt zuletzt.

@ps-neotrace sagte in ioBroker Raspberry OS Image v2:

Durch das Entfernen des Standard users wird dies natürlich für den reinen n
Neuanfänger deutlich erschwert.

Und dieser Text im Eingangspost hat nicht geholfen?

@andre sagte in ioBroker Raspberry OS Image v2:

Standard-User + Kennwort sind entweder mit dem Raspberry-Pi-Imager beim SD-Karte schreiben oder beim ersten Boot über die Konsole festzulegen

@glasfaser @mickym
Der Bug ist aber schon dokumentiert:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035094

@homoran sagte in Überspringen des "Erststart-Wizards":

die drehen sich immer mit der Rückseite nach vorne!

Verbesserungsvorschlag für 2034: Alle müssen sich ihren Foren-Namen und Avatar auf die Stirn kleben.

EDIT: auf den Stirnen der meisten Teilnehmer wäre genug Platz gewesen ...

@percy
Dann ist es aber kein iobroker - sondern ein Netzwerkproblem

@haselchen sagte in Usertreffen: Hannoveraner Raum -> 18.1.25, 16:00Uhr, Celle:

PN ist raus

... ich würde auch ungern von Tisch zu Tisch gehen und fragen, ob es hier die anonymen ioBroker sind ...

Falls noch Interesse an einer ioBroker Integration eines Standalone Node-RED besteht:

Ich habe mal drei einfache Nodes unter Nutzung des REST-API Adapters entwickelt und stelle gerade meine Flows alle um. Wenn ich persönlich weitere Funktionen benötige, werde ich die integrieren. Mir fehlt aber im Moment die Zeit, um auf Feature Requests oder Bug Reports einzugehen.

https://github.com/Marc-Berg/node-red-contrib-iobroker

Das Readme sollte soweit alles sagen, bitte unbedingt auch den Hinweis zur Web-Adapter Integration lesen.

EDIT: PRs natürlich willkommen!

EDIT2: https://forum.iobroker.net/topic/81449/node-red-nodes-für-externe-iobroker-integration

@martybr sagte in Node-RED Nodes für externe ioBroker Integration:

Planst du das Verhalten noch zu ändern?

Ich sehe im Moment keinen Grund dafür. Hier geht es ja lediglich darum, in welchem Format die Topics durch den Flow geschleust werden. Da es sich hier um ioBroker Nodes handelt, verwende ich natürlich die ioBroker Notation, und die ist mit Punkten.

Wo finde ich die Doku dazu?

Ich verstehe nicht. Die Nodes sind schon umfangreicher dokumentiert als 99,9% vergleichbarer Projekte. Soll ich jetzt auch noch dokumentieren, was ich NICHT mache?

Ich verwende eine Menge mqtt-Nodes. Wenn ich das richtig??? gelesen habe, betrifft es den in und den out-Node?

Ja. Beim "in" Node konnte man wählen, dass man statt der Punkte im Topic "/" hat. Und beim out-Node konnte man AUCH "/" als Trenner angeben. Das hat aber aus meiner Sicht Fehlerpotential, weil auch solche Bezeichner wie

möglich sind.

@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:

Das läuft mit den alten nodes ok. Nicht aber mit den neuen.
Hab dann irgendwann endlich gemerkt, dass die neuen nodes zwingend den "." als Property-Trenner verlangen.

Um ehrlich zu sein, habe ich mir nicht viel Mühe dabei gegeben, die Umstellung so einfach wie möglich zu gestalten. An dieser Stelle hatte ich eine Weile überlegt, wie ich es mache. Insbesondere beim "in" Node konnte man ja auch das "MQTT" Format mit "/" wählen. Ich hab's dann weggelassen weil ich es nicht verwendete (dachte ich). Bei der Umstellung hab ich dann gemerkt, dass ich doch eine Stelle drin hatte.

Will nur darauf hinweisen, falls noch jemand in diese Falle tappst;-)

So wie ich selbst.

@martybr sagte in Node-RED Nodes für externe ioBroker Integration:

Mein Problem ist folgendes:
Im Original-Node gibt es das Feld Attribut:

Hier gibt es Output Property.
Kann ich es so anwenden?

Das ist das Gleiche. Ich habe mich für den Begriff "property" entschieden, weil es besser in die Node-RED Konventionen passt.

@seide-th sagte in Zeitraum Datensätze:

@marc-berg Moin
ich muss leider noch mal nachfragen. Ich bekomme immer folgende Rückmeldung, nachden ich in der CLI von influx die Datenbank mit

USE <iobroker>

Die eckigen Klammern (größer als/kleiner als) dienen als Platzhalter und müssen weggelassen werden.

@seide-th sagte in Zeitraum Datensätze:

Zum Punkt Datensätze löschen ohne das Objekt zu löschen:
Ich habe noch die DB Version 1.x eingestellt und der Adapter hat die Version 4.0.2

Das Löschen alter Datensätze ist recht simpel.

• Per CLI auf die Datenbank verbinden: influx
• Datenbank auswählen: USE <datenbankname>
• Daten älter als ... löschen (in UTC):

DELETE FROM "<measurement>" WHERE time < '2024-12-31T23:00:00Z'

Das muss dann pro Measurement gemacht werden.

@seide-th sagte in Zeitraum Datensätze:

Da die Datenbanksicherung der InfluxDB bei mir inzwischen 17Gb ist....,

Bei der Größe stelle ich mal die Behauptung in den Raum, dass du schon bei der Aufzeichnung deutlich optimieren könntest.

kann ich denn die Datensätze die nicht solange vorgehalten werden sollen einzeln Löschen, ohne dass ich das Datenfeld unter Objekte komplett löschen muss?

Ja. Wie das geht, hängt von der Version der InfluxDB ab, die du noch nicht verraten hast.

Und wenn ich es dann richtig verstehe, würde ich eine oder zwei weitere Datenbanken (influxDB) anlegen und da dann die zeitlich begrenzten Datensätze aufzeichnen. Die Vorhaltezeit gebe ich dann in den „Instanzen“ und dann unter „Standardeinstellungen“ vor. Die Löschung erfolgt dann automatisch ohne dass ich noch was anstoßen muss.

Korrekt, ja.

@seide-th sagte in Zeitraum Datensätze:

Wie ich es hinbekomme, dass einzelene Datensätze unterschiedlich lange Vorhaltezeiten haben, ist mir egal.

Es gibt bei der InfluxDB keine Möglichkeit, die Vorhaltezeit auf "Datensatz"ebene einzustellen. Deshalb ist die Option ja auch rausgeflogen.

Stattdessen musst du mehrere Datenbanken/Buckets anlegen.

@martinp sagte in hinweis: zigbee2mqtt server unschöne Eigenschaft:

In den Logs im Volume des Containers werden auch debug-messages abgelegt ... Erscheinen in der Oberfläche zwar nicht, aber sind nervig, wenn man sich z. B. mit Portainer mal um seinen Container-Zoo kümmern möchte

Du kannst doch in den Einstellungen festlegen, ob die Meldungen in der console und/oder in Files ausgegeben werden

Da kannst du auch das Level angeben

@legro sagte in InfluxDB restore in Docker auf einer Synology 923+:

Nach dem Restore gilt das PW aus der InfluxDB-Installation, aus der das Backup stammt. Was für ein Durcheinander.

Genau dazu ist das Flag "--full" ja gedacht, dass es eine komplette Wiederherstellung der Datenbank mit allen Daten, Usern, Berechtigungen und Token macht. Verstehe nicht, was daran "durcheinander" sein soll. Wenn du das nicht willst, lass das "--full"-Flag weg und restore die Buckets einzeln.

@legro sagte in InfluxDB restore in Docker auf einer Synology 923+:

<hier steht mein Admin-Token>

Abgesehen davon, dass ich das Konstrukt mit dem Mapping per SSH noch nicht verstanden habe: Welchen Admin-Token verwendest du? Den des alten oder des neuen Servers?