@djmarc75 Richtig, Version: v7.8.0
Rest wird gepostet an der Stelle, die Du angegeben hast.
NEWS
Best posts made by iobroker2001
-
RE: Blockly: Bug bei neuem Multi-AND!?
Latest posts made by iobroker2001
-
RE: JavaScript 7.9.0 - Neue Objekt- und HTTP-Bausteine
Zusätzlicher Post, Original war hier:
https://forum.iobroker.net/topic/73807/blockly-bug-bei-neuem-multi-andGuten Tag,
ich vermute, einen Bug im Blockly-Adapter bei der neuen Multi-AND-Logik gefunden zu haben.Wenn eines der Elemente eines multiplen AND-Blocks einen (eigentlich untergeordneten) OR-Operator beinhaltet, wird dieser nicht als gleichberechtigt mit den anderen AND-Operatoren, sondern bevorzugt behandelt. Wenn die Logik des OR-Operators TRUE ist, werden die anderen AND-Blöcke ignoriert.
Ich vermute, dass in der Umsetzung eine Klammerebene nicht gesetzt wird.Einfach ausgedrückt am Beispiel:
Eigentlich müsste die Logik "FALSE" ergeben, sie ergibt aber "TRUE" wegen der 1. OR-Prüfung.
Version ist 7.8.0
Gruß,
Friedhelm -
RE: Blockly: Bug bei neuem Multi-AND!?
@djmarc75 Richtig, Version: v7.8.0
Rest wird gepostet an der Stelle, die Du angegeben hast. -
Blockly: Bug bei neuem Multi-AND!?
Guten Tag,
ich vermute, einen Bug im Blockly-Adapter bei der neuen Multi-AND-Logik gefunden zu haben.Wenn eines der Elemente eines multiplen AND-Blocks einen (eigentlich untergeordneten) OR-Operator beinhaltet, wird dieser nicht als gleichberechtigt mit den anderen AND-Operatoren, sondern bevorzugt behandelt. Wenn die Logik des OR-Operators TRUE ist, werden die anderen AND-Blöcke ignoriert.
Ich vermute, dass in der Umsetzung eine Klammerebene nicht gesetzt wird.Einfach ausgedrückt am Beispiel:
Eigentlich müsste die Logik "FALSE" ergeben, sie ergibt aber "TRUE" wegen der 1. OR-Prüfung.
Gruß,
Friedhelm -
RE: Gelöst. eCharts: X-Achsenbeschrift. zu dicht/nicht lesbar
@homoran Das war's, vielen Dank!!!
-
Gelöst. eCharts: X-Achsenbeschrift. zu dicht/nicht lesbar
Guten Tag,
wenn ich in eCharts bei kleinen Diagrammen für die X-Achsenbeschriftung in den Einstellungen unter "Zeit" die Einheit "HH:MM" verwende, werden die Zeiten viel zu eng nebeneinander geschrieben, s. Bild!
Ich muss also "HH" verwenden, um einigermaßen die Stunden lesen zu können. Sobald ich dieses Diagramm aber zoome, werden die Werte wieder zu eng beieinander geschrieben und sind unlesebar.
Gibt es eine Einstellung, die dies verhindert? Wie gesagt: Nur "HH" reicht nicht.
-
RE: [gelöst] BackItUp InfluxDB: 2 Buckets sichern/wiederherst.?
@marc-berg Danke für die Hilfe!
Dein vorgeschriebener Weg funktioniert, ich mache es jetzt so (und habe es für mich dokumentiert, für den Fall der Fälle):
Backup wie oben beschrieben, ergibt 2 TAR.GZ-Dateien täglich (je 1 für einen Bucket).
Restore:
- Beide InfluxDB-Adapter stoppen
- Beide Buckets in der InfluxDB löschen, z. B. sehr einfach über die GUI.
- Mit BackItUp-Adapter ein Restore der beiden Buckets nacheinander ausführen.
- Beide InfluxDB-Adapter wieder starten.
Danke!
-
RE: [gelöst] BackItUp InfluxDB: 2 Buckets sichern/wiederherst.?
@marc-berg Danke, dann mache ich das jetzt wohl richtig.
Meine 2 Influx-Instanzen haben auch 2 Backupdateien geliefert - entsprechend den 2 Buckets:
Ich wollte nun ein Restore der beiden Buckets machen, um den Ernstfall zu proben.
Habe dazu ein SD-Karten-Image von vor 5 Tagen im Raspi gestartet und beginne mit
influxDBxxxxLangzeitxxxx.tar.gz
und versuche es zu restaurieren.
Im Restore-Dialog erscheint dann:Started restore ... [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [DEBUG] [influxDB] - influxdb.0 is stopped [DEBUG] [influxDB] - influxdb.1 is stopped [ERROR] [influxDB] - 2024/02/21 11:30:46 INFO: Restoring bucket "ecd164dc8277c2c5" as "iobroker-Langzeit" Error: failed to restore bucket "iobroker-Langzeit": 422 Unprocessable Entity: bucket with name iobroker-Langzeit already exists [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore done [DEBUG] [influxDB] - influxdb.0 started [DEBUG] [influxDB] - influxdb.1 started
Die Daten wurden nicht restauriert, trotz der Meldung "infuxDB Restore completed successfully".
Das gleiche passiert bei der Restaurierung des Buckets "iobroker".
Was läuft da falsch? In den Einstellungen ist angekreuzt, die alten Daten vorher zu löschen:
-
RE: [gelöst] Zigbee-Adapter: Deaktiv. Device wieder aktivieren
@codierknecht Danke, da wäre ich nie drauf gekommen!
-
[gelöst] Zigbee-Adapter: Deaktiv. Device wieder aktivieren
Guten Morgen,
mein Aqara-Erschütterungssensor hatte sich einige Tage nicht mehr gemeldet, deshalb habe ich ihn noch einmal anlernen wollen ("Kopplung starten!", Gerät in Anlernmodus, später auch noch in Werkseinstellungsmodus) - ohne Erfolg.
Habe dann auf der Kachel auf den Button "Deactivate" gedrückt und "State Cleanup" gemacht.
Nun kann ich den Sensor gar nicht mehr anlernen, er steht nach wie vor als "Deactivated" (s. Screenshot).
Wie kann ich den wieder aktivieren? Danke für einen Tipp!Zigbee-Adapter: v1.10.1
Restl. ioBroker Stable, neuester Stand
-
[gelöst] BackItUp InfluxDB: 2 Buckets sichern/wiederherst.?
Guten Tag,
ich bin mit meiner ioBroker-Installation (Raspi 4, SD-Karte) gerade auf Bookworm umgezogen.
Dabei habe ich Probleme mit der InfluxDB-Restaurierung. Auf dem alten Raspi sind 2 Buckets ("iobroker" und "iobroker-Langzeit") vorhanden. Dementsprechend auch 2 Instanzen des InfluxDB-Adapters.
Beim Sichern per Backitup und anschließendem Restaurieren scheint aber nur der 1. Bucket wieder zurückgespielt zu sein. Die Daten im 2. Bucket sind leer.
Deshalb meine grundsätzliche Frage:
Werden standardmäßig automatisch alle Buckets gesichert, oder muss man dies im Backitup-Adapter separat aufführen? Das hat auch nicht geklappt.
Ich konnte die Daten nur durch ein manuellesinflux backup
und
influx restore
wiederherstellen.
InfluxDB v2.7.5, InfluxDB-Adapter 4.0.2
Update:
Die Daten sind jetzt alle wieder restauriert.
Die Frage bleibt aber, wie man 2 Buckets sichert/restauriert per Backitup-Adapter.