Ich habe bisher etliche FHT FS20 und Homatic-Geräte an einer Kombination aus CCU2 und FHZ2000 mittels der CL-Studio-Software betrieben. Bei dem Versuch dafür ein vernünftiges User-Interface mittels ioBroker auf einem separaten RPi3B zu erstellen, bin ich bei der Einbindung der alten FHT80b und der FS20 Devices gescheitert. Der Versuch, die FHZ2000 zu entfernen und statt dessen einen CUL direkt an die CCU2 anzuschließen klappt zwar über CUxD mit ioBroker und VIS ganz gut, nur leider funktionieren HPCL-gesteuerten FS20-Komponenten nicht mehr, weil es auch in der aktuellen Studio Software anscheinend kein FHZ interface für den CUL-Stick an der CCU2 gibt. Oder habe ich da eine Möglichkeit/Alternative übersehen?

Wenn jemand diesbezügliche Erfahrungen hat, wäre es super, wenn er mir mit einem Tip unter die Arme greifen könnte. Ich bin für jeden Hinweis dankbar.

Die primäre Fragestellung wäre: Gibt es irgend eine Möglichkeit (ggf. mit Klimmzug), um den CUL an der CCU in die Studio-Software einzubinden? Ich würde nur ungern alle Skripte auf das WebUI umbasteln. Es gibt etwa 40 FHT/FS20 Komponenten und nicht ganz die gleiche Menge an Homematic-Teilen die überwiegend automatisiert kliemabezogene Aufgaben mit zu Teil umfangreichen Skripten erfüllen. Von daher bin ich wirklich für jeden Ratschlag dankbar, der mir eine mögliche Lösung oder aber Alternativen für ein sinnvolles weiteres Vorgehen aufzeigt.

Viele Grüße und schon mal bestem Dank für die Mühe,

Werner

Hier ist noch die Consolmeldungen bei meinem Backup-Restoreversuch. Es wäre super, wenn jemand eine Idee hat, wo das Problem liegen könnte und was meinerseits nötig ist, es zu beheben. Ich bin für für jeden Rat / Hinweis dankbar.
Gruß, Werner

pi@iobroker-pi:~ $ iob validate /opt/iobroker/backups/iobroker_2022_07_23-18_35_33_backupiobroker.tar.gz
host.iobroker-pi Starting validation ...
host.iobroker-pi backup.json OK
host.iobroker-pi vis-views.json OK
host.iobroker-pi vis-views.json OK
host.iobroker-pi vis-views.json OK
Backup OK
pi@iobroker-pi:~ $ 




iobroker-pi:~ $ iob restore /opt/iobroker/backups/iobroker_2022_07_23-18_35_33_backupiobroker.tar.gz
iobroker controller daemon is not running
host.iobroker-pi OK.

<--- Last few GCs --->

[4763:0x23eb4c0]    20733 ms: Mark-sweep 245.0 (246.6) -> 245.0 (246.6) MB, 137.5 / 0.1 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 138 ms) (average mu = 0.153, current mu = 0.057) allocation failu[4763:0x23eb4c0]    20870 ms: Mark-sweep 245.0 (246.6) -> 245.0 (246.6) MB, 135.5 / 0.1 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 136 ms) (average mu = 0.086, current mu = 0.007) allocation failu

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x3140379d <JSObject>
    0: builtin exit frame: parse(this=0x31433259 <Object map = 0x58500a15>,0x23e01709 <Very long string[51499246]>,0x31433259 <Object map = 0x58500a15>)

    1: _restoreAfterStop [0x23a1e841] [/opt/iobroker/node_modules/iobroker.js-controller/lib/setup/setupBackup.js:685] [bytecode=0x5a3fa5bd offset=145](this=0x4f183ac9 <BackupRestore map = 0x3ec96d3d>,0x597c03c1 <false>,0x597c03c1 <false>,0x597c03c...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
/usr/bin/iob: Zeile 8:  4762 Abgebrochen             sudo -H -u iobroker node /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js "$@"
pi@iobroker-pi:~ $

@thomas-braun

Das Backup-File ist etwa 9 MB groß.

ich versuche gerade ein Testsystem auf einem Raspberry 3 zu erzeugen und dazu ein iobroker Backup aus einem Produktivsystem (NUC Proxmox LXC-Container) über ein iobroker-pi image auf den Raspi zu schieben, was leider nicht zum Erfolg geführt hat. Das Restore wird mit folgender Fehlermeldung im Log abgebrochen:

2022-07-23 21:31:55.433 - error: backitup.0 (685) [ERROR] [iobroker] FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory 

Die Meldungen während des Restore sind folgende:

[DEBUG] [iobroker] Start ioBroker Restore ...
[DEBUG] [iobroker] iobroker controller daemon is not running
[DEBUG] [iobroker] host.iobroker-pi OK.
[DEBUG] [iobroker] <--- Last few GCs --->
[DEBUG] [iobroker] [1596:0x383f588]    20572 ms: Mark-sweep 243.9 (244.9) -> 243.9 (245.4) MB, 126.0 / 0.1 ms  (average mu = 0.161, current mu = 0.075) allocation failure scavenge might not succeed
[DEBUG] [iobroker] [1596:0x383f588]    20708 ms: Mark-sweep 244.3 (245.4) -> 244.3 (245.7) MB, 126.9 / 0.1 ms  (average mu = 0.117, current mu = 0.070) allocation failure scavenge might not succeed
[DEBUG] [iobroker] <--- JS stacktrace --->
[DEBUG] [iobroker] ==== JS stack trace =========================================
[DEBUG] [iobroker] Security context: 0x298c19ed <JSObject>
[DEBUG] [iobroker] 0: builtin exit frame: parse(this=0x23e9e331 <Object map = 0x21ec0a15>,0x3b905a29 <Very long string[51499246]>,0x23e9e331 <Object map = 0x21ec0a15>)
[DEBUG] [iobroker] 1: _restoreAfterStop [0x431fe845] [/opt/iobroker/node_modules/iobroker.js-controller/lib/setup/setupBackup.js:685] [bytecode=0x4913a565 offset=145](this=0x741465c9 <BackupRestore map = 0x74196635>,0x4fe803c1 <false>,0x4fe80359 <true>,0x4fe803c1...
[ERROR] [iobroker] FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
[DEBUG] [iobroker] ioBroker Restore completed successfully
[EXIT] null **** Restore was canceled!! ****

Es hört sich nach einem Speicher Allocation Konflikt an. Leider habe ich keine Idee welche Bedeutung und Auswirkung er an dieser Stelle hat und vor allem, ob man irgend etwas tuen kann um das Problem zu lösen oder zu umgehen. Ich bin von daher für jede Hilfe dankbar. Der komplette Log ist im Anhang falls er benötigt wird.
iobroker.2022-07-23.log
Mit besten Grüßen, Werner

@homoran said in Probleme bei der Übertragung lokaler Backup-Dateien:

ist dein pi in der Gruppe iobroker?

sorry, dass ich diesem Einwand nicht genügend Beachtung geschenkt hatte. Ich war davon ausgegangen, war aber nicht sicher und hatte keine Idee, wie das zu prüfen und zu ändern wäre.
Habe meinen einzigen User jetzt explizit in die iobroker gruppe eingetragen und siehe da, es funktioniert.
Besten Dank für eure Unterstützung.

@thomas-braun said in Probleme bei der Übertragung lokaler Backup-Dateien:

!ACHTUNG! Da sind ACLs gesetzt, fummel da NICHT per chown oder chmod herum! Eigentlich fummelst du da überhaupt nicht dran rum.
Der user sollte in der Gruppe 'iobroker' sein, dann dürfte das auch funktionieren mit dem Schreiben.

Wenn ich das richtig sehe, scheint die Problemursache gefunden. Wenn ich aber die festgelegten Rechte des Verzeichnisses nicht manuell ändern soll, was kann ich alternativ tun, um ausreichende Schreibrechte zu erhalten?
Ich habe versucht, einen neuen User mit den Anmeldeparametern des rpi anzulegen und in die Gruppe Benutzer (system.group.user) zu schieben sowie eine neue Gruppe iobroker (system.group.iobroker) mit besagtem User anzulegen in der Hoffnung, der externe Zugriff würde dann als Gruppenzugehörigkeit betrachtet. Leider erfolglos.
Ist es so, dass externe Zugriffe immer in die Gruppe Andere fallen und somit hier keine Schreibrechte haben? Was kann ich tun?

@homoran sagte:
"und dein user vom filezilla muss berechtigt sein in dem Verzeichnis zu schreiben"

Verstehe ich das richtig? Wenn user + pw identisch sind, dürfte der Unterschied beim Zugriff auf das backups-Verzeichnis doch eigentlich nur aus einer unterschiedlichen Gruppenzugehörigkeitsbetrachtung herrühren.
Die Verzeichnisrechte von backups sind "d rwx rwx r-x +" für Eigentümer, Gruppe und Andere.
Sorry, ich bin nicht sicher in der Interpretation, aber könnte es sein, dass
ein externer Zugriff immer als Andere interpretiert wird und damit das letzte Päckchen r-x für den Zugriff von extern (Andere) zuständig ist? Wenn das stimmt, könnte ich ja die Verzeichnisrechte für den Zeitraum der Übertragung auf rwx setzen und das Problem sollte beseitigt sein. Werde ich morgen probieren.

FileZilla nutzt normalerweise sftp bzw. ssh und prüft natürlich vor dem Serverzugriff die Autorisierung durch Username und pw.

@Hormoran

sorry, aber die Frage verstehe ich nicht. Auf meinem PI läuft nur die aktuelle Image-Version von iobroker-pi. Der sollte ja wohl in der entsprechenden Gruppe sein. Der externe Rechner, von dem die Übertragung nicht klappt ist ein Windows-Client ohne einen Bezug zu ioBroker, abgesehen davon, dass darauf Speicherplatz für backitup-Dateien zur Verfügung steht.

Gibt es einen Unterschied bei den Rechten zwischen einem Zugriff auf den backups-Ordner von innerhalb von ioBroker oder aber von ausserhalb? Was kann ich dagegen tun, um das Problem zu umgehen?
Danke und Gruß, Werner

@homoran sagte "knapp daneben! root hat da nix zu suchen."

Genau das versuche ich ja, da in dieser Konstellation kein Root-User zur Verfügung steht.
FileZilla behauptet, die Dateien die Übertragung könnte nicht gestartet werden. Warum ist mir total unklar. Die bereits in dem Zielverzeichnis existierenden Dateien sind mit den gleichen Benutzerparametern von Backitup erzeugt worden. Eine Datei aus dem ioBroker-Verzeichnis konnte ich in das lokale Verzeichnis kopieren - die selbe Datei umbenant zurückzuschieben schlug fehl. Es scheint aber doch wohl ein Rechteproblem zu sein.
Siehe FileZilla-Meldungen unten.
Hat jemand noch eine Idee, wie man der Fehlerursache auf den Grund kommen könnte?

Status: Verbinde mit 192.168.2.119...
Status: Using username "pi".
Status: Connected to 192.168.2.119
Status: Starte Upload von C:\Users\wb\Desktop\ioBroker_Sicherung_2019\iobroker_2022_07_19-17_44_42_iob__backupiobroker.tar.gz
Befehl: cd "/opt/iobroker/backups"
Antwort: New directory is: "/opt/iobroker/backups"
Befehl: put "C:\Users\wb\Desktop\ioBroker_Sicherung_2019\iobroker_2022_07_19-17_44_42_iob__backupiobroker.tar.gz" "iobroker_2022_07_19-17_44_42_iob__backupiobroker.tar.gz(Copy)"
Fehler: /opt/iobroker/backups/iobroker_2022_07_19-17_44_42_iob__backupiobroker.tar.gz(Copy): open for write: permission denied
Fehler: Dateiübertragung fehlgeschlagen
Status: Starte Upload von C:\Users\wb\Desktop\ioBroker_Sicherung_2019\iobroker_2022_07_19-17_44_42_iob__backupiobroker.tar.gz
Status: Empfange Verzeichnisinhalt für "/opt/iobroker/backups"...
Status: Listing directory /opt/iobroker/backups
Befehl: put "C:\Users\wb\Desktop\ioBroker_Sicherung_2019\iobroker_2022_07_19-17_44_42_iob__backupiobroker.tar.gz" "iobroker_2022_07_19-17_44_42_iob__backupiobroker.tar.gz(Copy)"
Fehler: /opt/iobroker/backups/iobroker_2022_07_19-17_44_42_iob__backupiobroker.tar.gz(Copy): open for write: permission denied
Fehler: Dateiübertragung fehlgeschlagen
Status: Starte Upload von C:\Users\wb\Desktop\ioBroker_Sicherung_2019\iobroker_2022_07_19-17_44_42_iob__backupiobroker.tar.gz
Status: Empfange Verzeichnisinhalt für "/opt/iobroker/backups"...
Status: Listing directory /opt/iobroker/backups
Befehl: put "C:\Users\wb\Desktop\ioBroker_Sicherung_2019\iobroker_2022_07_19-17_44_42_iob__backupiobroker.tar.gz" "iobroker_2022_07_19-17_44_42_iob__backupiobroker.tar.gz(Copy)"
Fehler: /opt/iobroker/backups/iobroker_2022_07_19-17_44_42_iob__backupiobroker.tar.gz(Copy): open for write: permission denied
Fehler: Dateiübertragung fehlgeschlagen
Status: Empfange Verzeichnisinhalt für "/opt/iobroker/backups"...
Status: Listing directory /opt/iobroker/backups
Status: Anzeigen des Verzeichnisinhalts für "/opt/iobroker/backups" abgeschlossen
Status: Verbindung zum Server getrennt