@djmarc75 said in Backitup verschiebt täglich nächstes anstehendes Backup:

na das erklärt sich doch eigentlich damit, dass Du in der Instanz was änderst. wird immer um X-Tage verschoben.

Das hatte ich schon verstanden. Ich habe aber an den vorhergehenden Tagen nix an der Instanz geändert. Der iobroker hat gestern rebootet, die Zeit passt zum Timestamp des Next-DPs. Vielleicht ist tatsächlich das die Ursache (reboots).

Ich bilde mir aber ein, dass früher das Datum der nächsten Sicherung ausgehend von der letzten Sicherung berechnet wurde, was für mich auch ehrlich gesagt mehr Sinn macht.

Warum nicht daily ein Backup?
4 Tage am Stück vll fleissig was geändert und an Tag 5 was "verbogen" ... dann sind Deine Änderungen der fleissigen Arbeit weg... ein Backup (zumindest vom iobroker) frisst ja kein Brot.

Ich werde darüber nachdenken :-), ist ein Argument!

Gestern habe ich von Dimaiv das Gateway (Zigbee Coordinator) erhalten

Ich habe den Stick nun testweise als weitere Instanz parallel zu meinem (Noch-Stick) CC2531 eingebunden.
Hat prima nach Anleitung s.o. geklappt! Die Osram-Steckdose, die ich zum Testen angelernt habe, hat sich sofort verbunden. Also bisher alles bestens !

@dslraser Klar, gerne

Hm, wird angemeckert als zu lang. Ich hänge es als File an.

LED-Regenbogen-Steuerung.txt

Ich hätte auch noch eine Frage zur Formatierung:
Bei mir funzt das Widget, auch die Spaltenbreite habe ich einstellen können (geht über "Kolumnanzahl" einstellen, und dann tauchen drunter für jede Spalte eigene Abschnitte zur Formatierung auf).

Ich würde gerne einzelne Zeilen formatieren abhängig vom Wert in einer Spalte (ich stelle meine Wecker dar, und wenn einer an ist, hätte ich den gerne fett, mit grüner Schrift, rosa hinterlegt - what ever, also irgendwie hervorgehoben.

Geht das mit diesem Widget + CSS?

js-controller: Weil das eine größere Änderung war, seit dem ich das letzte Mal ein Device hinzugefügt habe.... war ja nur eine Vermutung von mir. Bin nicht tief genug in der Materie drin.

Ich habe den Fehler eben gefunden und muss zu meiner Schande gestehen, dass das Problem vor dem PC saß.... ich hatte den Smart Name nicht am State-Objekt eingetragen, sondern am device selbst.... ist mir allerdings eben erst aufgefallen
Nun habe ich es korrekt eingetragen, und es funktioniert.

Aber im Gegensatz zu dem von FredF verlinkten Beitrag steht bei mir als smartType drin: "smartplug", und funktioniert problemlos.

Jedenfalls bin ich froh, den Fehler gefunden zu haben.

@mike2712 Du kannst mehrere Alexa-Gerätenamen mit Komma getrennt angeben, das geht natürlich auch bei Gruppen.
Ich habe bspw. meine LED-Leuchte über dem Esstisch als "Esstisch" und "Esszimmer" eingetragen. Alexa-Name = Esstisch, Esszimmer

Das steht so auch in dem Dialog zur Angabe des Alexa-Namens.

@liv-in-sky
Danke Dir

Hier nun mein fertiges Script: (der Urpsprungscredit geht an @liv-in-sky , im Thread oben steht das Blockly mit dem Trigger)

var cacheSelector = $('[id=alexa2.0.Echo-Devices.*.*Alarm.*.enabled]');
//log("Ausgelesene Alarme: ");
//log(cacheSelector);

var count = 0;
var len = 0;
var weckerArray = [];
var str2 = "";
var weckerOnOff = "";

cacheSelector.each(function(id, i) {
    count++;

    //log("Alarm de_aktiviert: " + id);
    //var weckerOnOff = getState(id).val;    
    
    var str = id.substring(0,id.indexOf('enabled')-1);
    //log("Alarm: " + str + " ist aktiviert? " + weckerOnOff);

    if (id.indexOf('Music') > 0) {
        str2 = id.substring(0,id.indexOf('MusicAlarm')-1);
    } else {
        str2 = id.substring(0,id.indexOf('Alarm')-1);
    }

    var echoName = getObject(str2).common.name;
    var weckerName = getObject(str).common.name;

// aktiver Alarm?
if (getState(id).val) {
 
    log("Auf Gerät " + echoName + " ist Wecker " + weckerName + " aktiviert.");
    weckerOnOff="On";
    
} else {

    // deaktiver Alarm   
    log("Auf Gerät " + echoName + " ist Wecker " + weckerName + " inaktiv.");
    weckerOnOff="Off";

}
   var weckerEntry = {Echo:echoName, Wecker:weckerName, OnOff:weckerOnOff};
   // in len wird die neue Anzahl Elemente im Array geschrieben
    len = weckerArray.push(weckerEntry);
    log("Element " + len + " angefügt.");

});
    log("Insgesamt sind " + count + " Wecker definiert.");
    
    // JSON erstellen und in Datenpunkt schreiben
    var weckerJSON = JSON.stringify(weckerArray);
    setState("javascript.0.aw_sonstiges.ListeWecker", weckerJSON);
    log("JSON in Datenpunkt geschrieben.")

In der VIS wird das derzeit ganz simpel mittels einer JSON-Tabelle angezeigt.

Hier ebenfalls gleiches Issue.

It worked like a charm!!
Zigbee erfolgreich auf meiner neuen Installation restored. Adapter erfolgreich gestartet, Leuchte erfolgreich angeschaltet!

Allerdings ist wieder der mount (diesmal tatsächlich nfs) bestehen geblieben. Vielleicht war das ja auch ganz am Anfang die Ursache des Problems...
Ich muss korrigieren: erneutes ls -lhs ergab keinen mount mehr. Hat anscheinend einen Moment gedauert mit dem umount.

Na, jedenfalls Mission erfüllt: Raspberry erfolgreich auf Bullseye aktualisiert, iobroker running.

Danke Euch vielmals!!

Kuck mal hier, da gibts verschiedene Iconsets.
Die animierten Icons bestehen aus mehreren einzelnen Icons, es gibt u.a. diverse rund um Rollo, Rolladen etc.
Vielleicht ist da ja etwas dabei:

Icons for Fibaro

@bananajoe Danke für die Idee, das schau ich mir mal an, ob das mit dem logparser auch so geht.

Ich habe eine Frage zum Widget "Tabelle".

Ich möchte damit JSON-Tabellen anzeigen, die mit dem Logparser erstellt werden.
Dieser kann so konfiguriert werden, dass er via <span> CSS-Formatierungen bzw. Klassen mitgibt.

Beispiel:
{"date":"23.10. 18:10","severity":"<span class='logInfo logSeverity'>info</span>","from":"javascript.0","message":"<span class='logInfo logMessage'>*** Zigbee Connection auto-wiederhergestellt.</span>","ts":1761235814044}

In meiner VIS-1-Visualisierung habe ich hierfür das Widget "basic - table" verwendet. Es hat die <span>-Notation korrekt interpretiert, sprich als Klasse, und demzufolge in der Tabelle nicht als Text angezeigt.

Prinzipiell gefällt mir aber das Tabellen-Widget der inventwo design-Widgets von der Anpassbarkeit her besser.
Das funktioniert prinzipiell auch sehr schön, mit einer Ausnahme:

Kann ich das Widget irgendwie dazu "überreden", ebenfalls die <span>-Tags zu interpretieren und nicht im Tabelleninhalt auszugeben? Aktuell wird die Klassenangabe ignoriert und mein zugehöriges CSS nicht angewendet.

btw: die Angabe unter "CSS Ränder" wird ignoriert, es wird kein Rand angezeigt.

Overall konnte ich bereits mit den vis-2-inventwo-widgets eine toll aussehende Visualisierung bauen, herzlichen Dank dafür!! (Natürlich auch an BlueFox Denis für die VIS-2 generell!)

--- Ergänzung ---
Ich habe eine Spalte im JSON, die einen Bool-Wert enthält. Kann ich diesen schön formatiert anzeigen? Im Moment habe ich nur die Möglichkeit gesehen, die Spalte als Zahl zu formatieren, es wird dann 0 oder 1 anzeigt.
Im VIS1-Widget konnte ich angeben, dass der Wert als Checkbox angezeigt wird, das fand ich sehr gut.

--- Ergänzung 2 ---
Ich bekomme den Tabellenhintergrund nicht formatiert. Leider wird anscheinend die Angabe unter "CSS Hintergrund" nicht angewendet. Eine globale CSS-Formatierung (Tab "CSS") unter Angabe einer CSS-Klasse wird ebenfalls nicht berücksichtigt.

@asgothian said in Zigbee: kleine Frage zu Symbolen in Ver 3.1.5:

@alexathome sagte in Zigbee: kleine Frage zu Symbolen in Ver 3.1.5:

Auf einer Kartenseite wird die Batterie in gelb mit 50% angezeigt, auf der Rückseite in rot mit 40% (oben im Bild). Bei 2 Geräten habe ich solches gesehen, bei anderen Geräten ist die Anzeige konsistent.

Eines der beiden Symbole ist direkt mit der Batteriespannung verlinkt und wird aktualisiert wenn das Gerät diesen Wert anpasst. Das andere wird gelesen wenn die Daten vom Tab geholt werden, also nur 1x

Danke für die Erläuterung zur Batterieanzeige!

Was bewirkt das markierte Symbol mit dem grünen Pfeil auf einer Karte (unten im Bild)? In der Doku wird es leider nicht erklärt.

Dieser löst einen Device_Query aus. Das sollte der Tooltip auch sagen.

Leider kam bei mir kein Tooltip
Dito beim Symbol fürs Anstoßen des Pairings auf den Karten. Tooltip gibts bei mir nur auf der Kartenrückseite für die untere Symbolreihe.

Fachlich heißt das, es wird versucht, das Gerät anzusprechen?

Hi,

ich habe mich heute endlich dran gewagt, den Zigbee-Adapter von 2.0.5 auf 3.1.5 zu aktualisieren. Lief absolut problemlos, ich habe auch brav die Anleitung berücksichtigt.

Seitdem laufen auch meine beiden Tradfri-Fernbedienungen wieder, bin happy

Folgendes ist mir nun in V3.1.5 auf der Zigbee-Geräte-Ansicht aufgefallen:

Auf einer Kartenseite wird die Batterie in gelb mit 50% angezeigt, auf der Rückseite in rot mit 40% (oben im Bild). Bei 2 Geräten habe ich solches gesehen, bei anderen Geräten ist die Anzeige konsistent.

Dann noch eine Verständnisfrage:
Was bewirkt das markierte Symbol mit dem grünen Pfeil auf einer Karte (unten im Bild)? In der Doku wird es leider nicht erklärt.

VG Alex

@asgothian
Bei meiner zweiten, funktionierenden FB sehen die Cluster allerdings haargenauso aus. Das kann also nicht unbedingt das Problem sein.

Ein letzter Frust-Versuch heute - und auf einmal ging sie in den Pairing-Mode!

Ich habe leider noch nicht wirklich herausgefunden, wie schnell ich den Button drücken muss, mal geht sie ins Pairing, oftmals aber auch nicht. Das ist echt frustrierend. Wieso muß man das als Hersteller so kompliziert machen

Viel gebracht hat das allerdings bisher nicht: Es kam noch nicht zu einem Kopplungs-Interview und sie funktioniert nach wie vor nicht.

Auf der Zigbee-Kachel wird angezeigt, dass sie vor 14 Min das letzte Mal Kontakt hatte und mit einer Linkqualität von 36 verbunden sei (ich weiß, das ist sehr schlecht).

Frage: da sie dem Zigbee-Mesh ja bekannt zu sein scheint, würde dann überhaupt ein neues Interview gestartet?

@Asgothian @BananaJoe @pk68
Vielen Dank für Eure Tips.
Leider war ich bisher nicht erfolgreich. Ich bekomme die FB einfach nicht in den Pairing-Modus.

Ich habe es mit einer frischen Batterie versucht, mit x-mal schneller Drücken, mit 10sec Dauerdrücken (beide Varianten finden sich im Netz) - kein rotes Leuchten der LED.
Sie war mehrmals Batterielos, einmal sogar über Nacht.

Starte ich die Zigbee-Kopplung, so kommt recht schnell:

....
Pairing time left: 117
Pairing time left: 118
Pairing time left: 119
Device 'xxxx5fce' announced itself
Pairing time left: 120
Pairing started

Aber es findet nie ein Interview statt, geschweige denn, dass die FB funktionieren würde.
Ich bin ratlos

Ich frage mich allerdings auch: muss sie unbedingt in den Pairing Modus?
Die Kachel der FB sagt folgendes, also eigentlich ok?:

model: E1524/E1810
description: TRADFRI remote control
modelZigbee: TRADFRI remote control
type: EndDevice
nwk: 1964
manuf id: 4476
manufacturer: IKEA of Sweden
power: Battery
app version: 33
hard version: 1
zcl version: 3
stack version: 98
date code: 20190401
build: 24.4.5
interviewed: true
configured: true
endpoint: 1
profile: 260

input clusters:
genBasic (0)
genPowerCfg (1)
genIdentify (3)
genPollCtrl (32)
touchlink (4096)
64636

output clusters:
genIdentify (3)
genGroups (4)
genOnOff (6)
genLevelCtrl (8)
genOta (25)
touchlink (4096)

@asgothian said in Tester für Zigbee Adapter 2.0.x gesucht:

@pk68 Nein - deine Fernbedienung scheint nicht OK - sie meldet nicht die für die FB üblichen Cluster - das ist Ursache der Fehlermeldung. Ich empfehle Dir ein Firmware-Update für die FB durchführen.

A.

Nachtrag: so sollten sie aussehen.
(Screenshots für die Übersichtlichkeit entfernt)

Als Vorbereitung auf das Adapter-Update von V1.10.14 auf V2.0.5 habe ich bei meinen beiden Tradfri-Fernbedienungen die FW aktualisiert via der Option im Zigbee-Adapter (aus Anlaß des erwähnten Kommentars von asgothian).

Das Update ist bei beiden durchgelaufen und wurde als abgeschlossen gemeldet. Die eine FB funktioniert nun weiterhin wie gehabt, die andere macht jedoch keinen Mucks mehr

2025-04-25 14:45:49.303 - info: zigbee.0 (87394) Start firmware update for xxxxx5fce
....
2025-04-25 16:37:03.299 - info: zigbee.0 (87394) Update of 'xxxxx5fce' at 99.5%, +- 0 minutes remaining
2025-04-25 16:37:31.084 - info: zigbee.0 (87394) Update of 'xxxxx5fce' at 100%
2025-04-25 16:37:46.948 - info: zigbee.0 (87394) Device 'xxxxx5fce' announced itself
2025-04-25 16:37:46.949 - info: zigbee.0 (87394) Device 'xxxxx5fce' announced itself
2025-04-25 16:37:49.934 - info: zigbee.0 (87394) Finished update of 'xxxxx5fce', from '{"softwareBuildID":"2.3.014","dateCode":"20190401"}' to '{"softwareBuildID":"24.4.5","dateCode":"20190401"}'

Wenn ich einen Button drücke, kommt auf der entsprechenden Zigbee-Kachel nix an, im Objektbaum sieht man keine Statusänderung, meine Scripte triggern nicht - sprich tot.
Ich habe bisher folgendes ausprobiert:

• Neu zu pairen - ich bekomme sie nicht in den paring Modus, mehrfaches Drücken des Buttons auf der Rückseite bringt leider gar nichts

• Re-Configure über die Kachel im Zigbee-Adapter: bringt die Fehlermeldung, das Device könne nicht erreicht werden:

2025-04-25 16:42:59.728 - info: zigbee.0 (87394) -> Configuring xxxxx5fce TRADFRI remote control
2025-04-25 16:43:09.767 - warn: zigbee.0 (87394) DeviceConfigure: xxxxx5fce TRADFRI remote control Failed to configure. When device works is all fine when not wake up the device and check again

Gibt es weitere Ideen, woran es liegen könnte bzw. was ich tun könnte? Oder wäre nun das Update des Zigbee-Adapters der nächste sinnvolle Schritt? Davor habe ich aktuell noch etwas Bammel wg. der Breaking Changes....

VG Alex

Vielleicht müsste das eher in die Kategorie Fehler/ Bugs... ?

Hi,

ich wollte ein Blockly-Script anpassen. Dabei ist mir aufgefallen, dass plötzlich in allen meinen Blocklys für den Baustein "debug output" der Loglevel anstelle "Info" nun auf "Debug" steht (Loglevel "Warn" ist erhalten geblieben; "Error" habe ich nicht verwendet).

Mir ist weiterhin aufgefallen, dass im JavaScript-Code für den Loglevel "Info" bisher console.log verwendet wurde und nun console.info.

Kann dies die Ursache sein?

Die Scripte selbst funktionieren weiterhin, im Log erscheinen die erwarteten Meldungen mit Loglevel "Info".

Bei einem neu erstellten Blockly-Testscript war alles ok, der Loglevel blieb wie eingestellt. Dito für neue "debug output"-Blöcke in bestehenden Scripts.

Ändere ich jedoch ein bestehendes Blockly, werden die Loglevel falsch mit "Debug" überschrieben, sofern ich sie nicht explizit neu setze :-(.

Ich kann nun leider nicht in meinen Scripten im Javascript-Code console.log durch console.info ersetzen, da ich sie nicht dauerhaft von Blockly nach Javascript konvertieren möchte und der JavaScript-Code ansonsten read-only ist.

Den JavaScript-Code ansehen + rauskopieren, und im Blockly die Bausteine entsprechend anpassen funzt natürlich.

Dieser Beitrag soll daher neben der Fehler-Meldung auch ein Heads Up für andere sein, da hinzugucken.

Ich habe gestern mein System aktualisiert auf die neuesten Versionen. Es besteht dazu ein zeitlicher Zusammenhang.

Used repository: stable
Adapter "admin" : 7.0.22, installed 7.0.22
Adapter "alexa2": 3.26.5, installed 3.26.5
Adapter "alias-manager": 1.2.6, installed 1.2.6
Adapter "backitup": 3.0.16, installed 3.0.16
Adapter "email": 1.3.1, installed 1.3.1
Adapter "hmip": 1.23.3, installed 1.23.3
Adapter "iot": 3.3.0, installed 3.3.0
Adapter "javascript": 8.7.6, installed 8.7.6
Controller "js-controller": 6.0.9, installed 6.0.9
Adapter "logparser": 2.2.2, installed 2.2.2
Adapter "ping": 1.6.2, installed 1.6.2
Adapter "simple-api": 2.8.0, installed 2.8.0
Adapter "socketio": 6.7.1, installed 6.7.1
Adapter "vis": 1.5.6, installed 1.5.6
Adapter "web": 6.2.5, installed 6.2.5
Adapter "ws": 2.6.2, installed 2.6.2
Adapter "zigbee": 1.10.3, installed 1.10.3

NodeJS 20.16.0
npm 10.8.1
Debian Bookworm

Im Log stand halt einfach nur -nichts-. Wenn es dort eine Fehlermeldung gegeben hätte, hätte ich ja darauf aufsetzen können. Aber der Adapter scheint sich im Fehlerfall einfach "schlafen zu legen" und nichts mehr zu tun.

Ich löse das Problem derzeit folgendermaßen, indem ich mir jeden Morgen eine Mail schicken lasse mit dem Ergebnis des letzten Backups (erfolgreich/ Fehler). Bisher ist es zu keinem weiteren Fehler gekommen.