Bin eben auf den Thread gestoßen und hab auch gleich mal nen Testanruf angestoßen - gleicher Fehler.

Kann jetzt natürlich nicht sagen seit wann. Ich erhalte die Anrufe nur bei Auslösung der Rauchmelder oder bei Einbruchmeldung - also nicht alle Tage.

Sicher dass es nicht an der Node-Version liegt? Ich wüsste sonst auch nicht, was ich noch so verändert hätte...

Ich schaue nächste Woche sonst mal ob ich noch ein ganz altes Backup finde...

Hat es schon jemand hinbekommen bzw. ist es überhaupt möglich, die Räume des zweiten Geschosses (bei neuer Firmware und Mehretagenmodus) auch integrieren zu können?

Ich habe bei mir über iobroker ein Reinigungsscript nach Anwesenheit erstellt, damit er jeden Tag ausgewählte Räume im Erdgeschoss säubert. Nachdem er einmal im Obergeschoss gewesen ist und dementsprechend die zweite Karte geladen war, ist er beim Reinigen über das Scrip nur umher geirrt und hat sich nicht mehr zurecht gefunden.
Es wäre daher zumindest gut, wenn man per Befehl eine bestimmte Karte laden könnte...

@Ralla66 Ach so - das hatte ich falsch verstanden.

Ist natürlich richtig - anlernen braucht man da nichts.
Man braucht quasi nur den Datenpunkt "RfReceived Data"

Ich habe auch zwei 433MHz RWM über die Sonoff Bridge über das Drücken der Test-Taste angelernt.
Geht allerdings nicht mit allen.
Einige verfügen über Rolling Code, da geht es dann nicht.

Bzgl. der Frage nach dem Sinn:
Abfangen des Signals und Mitteilung / Anruf aufs Handy.
Natürlich ist mir bewusst, dass das nur funktioniert, solange die Sicherungen noch drin sind und der Brandherd nicht die FritzBox selbst ist - aber besser als nix...

Eben ist mir noch etwas aufgefallen:
Offensichtlich hat auch mein history Adapter Probleme mit dem Löschen der Daten.
Ich logge etwa 4 Datenpunkte. In den Einstellungen der History.0 Instanz habe ich 1 Jahr Speicherdauer ausgewählt.
Trotzdem ist der älteste Eintrag unter /opt/iobroker/iobroker-data/history vom 03.01.2019.
Übrigens stammte von dem Tag auch die älteste states.json.gz.

Ob es also evtl. an einem Rechteproblem liegt?
Ich habe auch weiterhin das Problem, dass ich Adapter nicht auf dem regulären Weg löschen kann (s. hier)

Evtl. komme ich doch nicht um eine komplette Neuinstallation herum

@crunchip schon mal vielen Dank für die Auskunft! Dann warten wir mal ab...

Zumindest bin ich ja nicht alleine mit dem Problem

Edit: Musste aber gerade feststellen, dass mein Backup trotz des Löschens der etlichen Dateien noch größer ist als zuvor, was mich doch ein wenig verwundert...

@crunchip Es hakt ja alleine schon daran, dass seit letztem Jahr bereits keine states.json.gz mehr angelegt worden ist.
Ich habe jetzt erstmal den Inhalt von /opt/iobroker/iobroker-data/backup-objects/ komplett gelöscht und warte mal ab.

Wenn ich dich richtig verstanden habe, stehen die o.g. Einstellungen zu "backup" auch nur in der /opt/iobroker/node_modules/iobroker.js-controller/conf/iobroker-dist.json und nicht in der /opt/iobroker/iobroker-data/iobroker.json, richtig?
Erfolgt die Speicherung der .gz Dateien bei dir trotzdem unter /opt/iobroker/iobroker-data/backup-objects/ oder gibt es da dann auch einen anderen Pfad?

Ich habe bei einigen meiner Gosund SP1 das selbe Problem, allerdings nicht in der Häufung.
Es betrifft sowohl welche, die ich mit Tasmota 6.5 über Kabel geflasht habe (was bei der SP1 mit dem Löten wirklich kein Geschenk ist), als auch zwei, die ich erst wenige Tage habe und mit Tasmota 8.1 OTA geflasht habe.

Die Stecker haben manchmal Tage, an denen sie unterbrechungsfrei laufen, an anderen Tagen unterbrechen sie im niedrigen zweistelligen Bereich.

Was mich wundert ist, dass etliche Sonoff S20 problemfrei laufen.
Weiterhin scheint es auch nicht vom Standort abzuhängen, da sie im ganzen Haus verteilt sind.

Kann es sein, dass die WLAN-Verbindung der Gosund Stecker aus irgendeinem Grund einfach wesentlich schlechter sind als bei anderen Produkten??

@crunchip said in ordner in iobroker "explodiert" : backup-objects:

@paul53 sagte in ordner in iobroker "explodiert":

"backup": { "disabled": false, "files": 24, "filesComment": "Minimal number of backup files, after the deletion will be executed according to backupTime settings", "hours": 48, "hoursComment": "All backups older than 48 hours will be deleted. But only if the number of files is greater than of backupNumber", "period": 120, "periodComment": "by default backup every 2 hours. Time is in minutes. To disable backup set the value to 0", "path": "", "pathComment": "Absolute path to backup directory or empty to backup in data directory"

diesen Part habe ich bei mir gar nicht drin stehen

Moin!
Genau so sieht es bei mir ebenfalls aus.
Der Part fehlt bei mir in der iobroker-data/iobroker.json völlig.

Unter /opt/iobroker/node_modules/iobroker.js-controller/conf/iobroker-dist.json steht aber unter "backup" alles genau so drin wie beschrieben.

Und ich habe mich zuletzt auch immer gefragt, warum meine Backups in Proxmox immer größer und größer werden...

Unter /opt/iobroker/iobroker-data/backup-objects sammle ich offenbar seit 11/2019 munter die objects.json.gz, von den states.json.gz finden sich allerdings insgesamt nur drei Dateien aus Januar 2019. Warum das so ist, kann ich nicht sagen. Es scheint mir aber, als sei das bei euch nicht der Fall, oder?

Ich hab mir den Thread zwar durchgelesen und auch die anderen Verzeichnisse durchgeschaut, muss aber zugeben, dass ich mangels Fachkompetenz nicht alles verstanden habe

Was scheint Eurer Meinung nach jetzt zunächst erstmal sinnvoll zu sein?
Erstmal händisch löschen und/oder die Datei iobroker-data/iobroker.json anzupassen?

Grüße,
TemPeck

@AlCalzone Das Auskommentieren (später - bei mir Zeile 107 - muss dann in der Folge auch noch einmal ausgeklammert werden) sowie der Versuch, die HTTP-Authentifizierung zu aktivieren und die Zugangsdaten einzutragen, haben jeweils wieder das selbe Ergebnis erbracht...