NEWS

@ofri2607 Ich glaube es nicht! Er funktioniert wieder.
Ich habe deinen Rat befolgt - wo vor ich gescheut habe.

Also: Reset auf Werkseinstellungen, Check im Objektbrowser dass keine DPs mehr vorhanden, Gerät für ein paar Sekunden stromlos gemacht, Zigbee-Adapter neu gestartet, Gerät neu angelernt Et voila - läuft wieder

Noch ein Hinweis bzgl Hue: Ich habe den Switch vor 2 Jahren gekauft (seitdem übrigens ohne Probleme gelaufen) und Konfig mit Hue und Zigbee probiert. Bei Hue wird er als Lampe eingerichtet, hat keinen DP für Linkqualität und keinen für angeschlossene Power. Darüber hinaus kann man an Hue keine Firmware Updates durchführen. Vor allem der letzte Punkt hat mich dann auf Zigbee gebracht. In den zwei Jahren hatte ich 4 Updates - vielleicht könnten sie dein System stabilisieren.

Danke für deinen Rat!

@mario-blass sagte in io broker update im container auf qnap:

Node.js v12.22.12 empfohlen 18....

Keine Ahnung, was du da gerade machst, zeigst ja auch nix. In einem 8.1.0 Image steckt ein Nodejs 18 drin. Was ist nun mit dem von @Glasfaser verlinkten Thread? Ist das jetzt ein neuer Versuch des gleichen Systems oder was anderes?

@karacho sagte in Adapter Energiefluss kein Datenpunkt Netz Bezug/Einspeisung:

Oder habe ich das übersehen?

nein!

aber der Netzbezug sollte gemessen werden.
Die Konstellation diesen aus dem Verbrauch und der Produktion zu betechnen, wird kaum ein anderer User haben.

Deswegen wird ja schon der Verbrauch berechnet.

Und aus dem berechneten Verbrauch nochmal den Netzbezug errechnen ist mathematisch nicht möglich.
Auch ein System benötigt den Netzbezug um den Verbrauch auszurechnen.

Also sollte dieser auch bei dir irgendwo vorliegen.

@smarthome2020

Die Nachricht wird mit vorgelesen. Etwas schwer zu verstehen, aber es geht.

@stealth sagte in ioBroker ständige restarts nach Debian upgrade:

Wo ich was auf meinem System zu melden habe, musst du mir schon überlassen.

Bei ordentlichem Umgang mit den usern und deren Rechten muss man nicht in /root herumstehen. Wozu auch?

In einem 'unverfummelten' System kommst du da auch gar nicht so ohne weiteres rein:

echad@chet:~ $ cd /root -bash: cd: /root: Permission denied echad@chet:~ $ ls -la /root ls: cannot open directory '/root': Permission denied

mit der sudo Option klappt es auf der Kommandozeile und auch mit dem BackItUp Adapter.

@mibr85

Bist du sicher dass da im Log nichts drum herum steht? Keine Meldungen von einem oder mehreren Adaptern?

Sieht für mich so aus als würde da irgendeine Code versuchen Schrottdaten durchs System zu senden.
Welcher Adapter servisiert diese Kamera?

In jedem Fall häng mal den output von iob diag (full) an. Ohne Versionsangaben sind die meisten Glaskugeln blind.

@ticaki sagte: mit dem ganzen Code des Blockly das hier:

Dieser Block hat schon immer eine 7 am Sonntag geliefert. Nur der Konvertierungs-Block wurde entsprechend geändert.

@thomas-braun sagte in iobroker updaten... geht nicht?:

@roelli

Das Skript mit dem hping3 anschauen. Das ist wohl krumm. Oder hping3 ist nicht installiert. Oder sonst irgendwas.

Das kann man löschen, meines funktioniert zumindest nicht mehr mit schlafenden iphones.

Das hat ja super geklappt vielen dank für eure Hilfe
Hawe

@markus-now

Hallo Markus,

über den Adapter 'b-control' scheint es in der Tat nicht zu klappen. Es funktioniert jedoch einwandfrei mit dem Modbus Adapter. Dazu von TQ die technische Dokumentation zum EM420 herunterladen und die Register (aktuell ab Seite 64) entsprechend in den Adapter übernehmen (einige sind im Screenshot unten angeführt).

Einstellungen:

auf dem EM420:

Screenshot 2023-12-16 at 10.24.41 AM.png

im Adapter (IP-Adresse des EM420 natürlich entsprechend anpassen):
Screenshot 2023-12-16 at 10.28.00 AM.png

Screenshot 2023-12-16 at 10.34.33 AM.png

Hinweise:

die Eingangsregister sind im 30000-er Bereich und werden um 1 erhöht, sprich, das Register '60' für 'Current (L1)' wird zu '30061'.

der Adapter verbindet sich erst, nachdem zumindest ein Register eingetragen worden ist.

Gutes Gelingen 🙂

Danke an alle für die ausführlichen Antworten.
VG
Sascha

@haus-automatisierung ja,
Glaube das was ist vor habe ist allerdings nicht wirklich so zu vergleichen wie es aktuell mit dem Adapter gehandhabt wird.
Es geht hier rein um livewerte und die ansprechend mit verschiedenen Funktionen geglättet wird.
Das wären ja Funktionen, die nicht auf historische Daten anwendbar wären.

@snopy_16 sagte in Adapter Fronius - Leistung / Strom pro Phase einlesen?:

@humidor
stehen diese Werte nicht eh im Fronius-Adapter??
fronius.0.meter.0.xxxxx

diesen meter habe ich nicht?

@thomas-braun sagte in iobroker Übersicht Kacheln:

Browser Refresh (F5) und der Hinweis ist weg.

Jawoll, hat geklappt.
Danke

@seb2010
Nachdem ich ich mich ein bisschen durch den Code gefräst habe, scheint es an der node-hue-api selbst zu liegen, die ein Delay von 1000ms zwischen dem Schalten von Lichtergruppen vorsieht.
Aus meiner Sicht ist der Wert hart in der API verdrahtet und kann nicht beim Aufbau der Verbdingung überschrieben werden.

Mein Workaround ist daher:
Das minTime-value als Delay für die Lichtergruppen in der Code-Datei "/opt/iobroker/node_modules/node-hue-api/lib/api/Groups.js" der node-hue-api lokal ändern. Es funktioniert damit und die Lichtergruppen werden nun fast synchron geschaltet (vorher war das Delay 1000ms).
Zusätzlich habe ich einen schedule-job angelegt, um robust gegen library updates zu sein:
exec("sed -i 's/minTime: 1000/minTime: 50/g' /opt/iobroker/node_modules/node-hue-api/lib/api/Groups.js")

VG
SEB

@homoran

Hallo homoran, hallo Community

mein Problem scheint erstmal gelöst.
Ich habe soweit alles richtig gemacht. Aber...

So habe ich es zum laufen bekommen; ist aber ganz schlecht:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Aber damit "ioBroker Adapter Modbus" aus dem LXD Container über den USB RS485 kommunizieren darf braucht
der User iobroker root Rechte obwohl der user iobroker in der Gruppe dialout ist.

Das ist ganz schlecht.

Offensichtlich werden bei Erstellung des Containers für die USB Schnittstelle höhere Rechte erwartet; warum auch immer.
Mir ist das erst aufgefallen als ich mir das ganze nochmal als Debian Container aufgesetzt habe.

Da hatte auch mein privater User erstmal keine root- Rechte.
Und da bin ich auch nicht mit dem modpoll CLI-Tool auf die Schnittstelle gekommen "Permission denied".
Erst als ich mir root-Rechte zugewiesen habe konnte ich wieder kommunizieren.

Bei Ubuntu weise ich dem installierenden User schon root-Rechte mit Passwortabfrage zu, daher hatte ich immer sofort root Rechte.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Ich hatte, wie im folgenden Chat beschrieben, auch den chmod... ausgeführt, aber nur einmal.
Das war mein Fehler.

So und nun noch ein Link für alle Interessierten, wie man einen USB-Stick einem QNAP LXD Container zugänglich macht:

Dieser "sudo chmod 777 /dev/ttyUSBx" muß wohl nach jeden Neustart des Containers ausgeführt werden.

LXD Container USB

21.12.2023 Ergänzung zum Durchreichen von USB-Schnittstellen in einen Container:
Die von mir verlinkte Beschreibung ist leider nicht vollständig, daher auch meine Probleme mit dem USB-Port:

Dieser Befehl stellt den Port /dev/ttyUSB0 gleich in die richtige Gruppe und mit den richtigen Schreibleserechten.

lxc config device add ubu2204-iobroker00 ttyUSB0 unix-char mode=0660 gid=20 path=/dev/ttyUSB0

Es gibt noch weitere Einstellungen:

LXD unix-char

Gruß Wolfgang

@djmarc75 Hatte das MQTT Passwort nicht korrekt eingetragen.

Das Problem ist gelöst!
Anscheinend ist die Klingelanlage abgestürzt und hat einige Werte anschließend zurückgesetzt.
Durch die Eingabe der richtigen Verbindungswerte in die Klingelanlage wurde das Problem beseitigt.

@arteck
@paul53
@foxriver76

@dg19222 ??