@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: [image: 1702718941579-screenshot-2023-12-16-at-10.24.41-am.png] im Adapter (IP-Adresse des EM420 natürlich entsprechend anpassen): [image: 1702718925907-screenshot-2023-12-16-at-10.28.00-am.png] [image: 1702719291033-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 ??

@marc-berg Hallo es hat etwas gedauert. Ich habe auf einem zweiten Raspberry, die iobroker.yml gestartet und in einem Leeren Container das Backup zurückgespielt. Leider hängt er sich wieder nach Zeit X mit dem selben Fehler weg :-/ Weiterhin kommt auch wieder TimeOut in der Webgui.

@marc-berg wie mounte ich denn manuell?

@berges01 gesehen https://forum.iobroker.net/topic/70834/zwave2-und-spirit-thermostat?_=1702381627707