NEWS

@ingob
Ich hab jetzt nochmal was neues versucht, um den Aufbau ganz trivial einfach zu halten.
Habe eine neue Linux VM installiert, sie hat nur ein Netzwerkinterface, das steckt in einer Fritzbox.
Ein Shelly, ist am Wlan der Fritzbox. Beide sind im selben Subnet 192.168,178,0/24
Die Server IP steht im Shelly unter CoIoT peer.
Der Shelly Adapter bleibt gelb.

@asgothian vielen Dank für Deine Antwort.

Aber wie kann man denn das Problem am besten umgehen, d.h. den state dann in solchen Fällen korrigieren? trigger auf brightness change setzen und dann den state manuell auf true setzen? das erscheint mir schon eher die Brechstangenmethode zu sein, oder?

Anscheinend machen das alle meine Zigbee Lampen so. 😞

@chris299 sagte in [gelöst] Zigbee Ikea Styrbar Problem:

@holgerwolf evtl. habe ich dann das Konzept der Trigger noch nicht verstanden. Bisher dachte ich, dass Trigger sowieso nur bei Änderungen des Objekts ausgelöst werden. (die verfügbaren Optionen scheinen das zu untermauern)

Nein. Die Trigger werden aktiv wenn das Objekt 'beschrieben' wird - das kann eine Änderung oder eine Aktualisierung mit dem gleichen Wert sein.
Um die verschiedenen Optionen abzufangen gibt es die Einstellungen 'ist wahr', 'ist falsch' und so weiter.
Der Punkt 'auslösung durch hat mit dem "acknowledge" status zu tun. Um den zu erklären muss ich ausholen:

Wenn der ioBroker Hardware steuern will macht es sinn wenn die Software erkennt welche Änderungen von Werten eines Datenpunktes als "Aufforderung zum Schalten" interpretiert werden - im Gegensatz zu den Meldungen das ein Gerät seinen Status geändert hat. Dazu gibt es das "Acknowledge".
Steuerbefehle werden immer ohne Acknowledge (also als unbestätigte Änderung) gesetzt. In Blockly gibt es dazu beim SetState die Auswahl "steuere" (ohne acknowledge als unbestätigte Änderung) und "aktualisiere" (mit acknowledge, als bestätigte Änderung). Wenn der Adapter die information bekommen hat das der Steuerbefehl ausgeführt wurde aktualisiert dieser überlicherweise den Datenpunkt (mit acknowledge).

im Admin 5 wird dieses farblich dargestellt. Wertänderungen ohne acknowledge werden in rot dargestellt, Wertänderungen mit acknowledge in grün.

80415b2b-efc8-4fac-ac74-d08d87095044-grafik.png
Aber wenn ich Euch richtig verstehe, dann wird auch bei einer "Änderung" von "wahr" auf "wahr" ausgelöst, richtig?
wenn ja, was genau verursacht denn "Änderungen" von "wahr" auf "wahr"? der Wechsel von unbestätigt auf bestätigt?

Bisher hatte ich nicht den Eindruck, dass mein Skript zu oft auslöst... ☺

Fun fact: Bei JS (und vielen anderen Programmiersprachen) gilt: true > false.

Damit löst ein Trigger auf "ist grösser als" nur aus wenn sich der Wert von false auf true ändert.

Ein Trigger auf "true" wird immer dann aktiv wenn der Datenpunkt mit dem Wert true beschrieben wird (also bei Änderung UND Aktualisierung)

A.

@tom63 jetzt kann ich wieder kontrollieren wer zu lange duscht 😉
SC18-Visu.jpg
meine Visualisierungsseite mit den Statistiken ...

Evtl. falls auch andere dasselbe Problem haben.
Habe gerade IOB geupdatet und Node.js auf 16.16.0 gebracht -> selbes Problem wie oben beschrieben.

Aber auch hier hat die Lösung von @thomas-braun geklappt, ble läuft wieder 😉

@tilly

Theoretisch ja.
In der Praxis können Fallstricke lauern.

Je mehr am System 'rumgefrickelt' würde, umso höher die Wahrscheinlichkeit da in Stolperfallen zu laufen

Auch deswegen halt der Rat, das System nicht mutwillig auf links zu drehen
Das 'do-release-upgrade-Skript' geht nämlich von einem unverfummelten System aus.

Ich muss das nochmal hochholen.

Es liegt definitiv am 3.xx Adapter. Ich habe die Anzahl der Werte jetzt reduziert und schreibe nur noch einmal pro Minute. Trotzdem steigt die DB beim Abrufen der Werte aus. Egal ob mit einem echart Diagramm oder im Objekt Viewer:

Error in query "from(bucket: "iobroker") |> range(start: 2021-07-25T06:47:00.000Z, stop: 2022-07-25T06:46:59.999Z) |> filter(fn: (r) => r["_measurement"] == "javascript.0.Photovoltaik.Leistung_DC_komplett") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group() |> sort(columns: ["_time"], desc: true) |> limit(n: 1)": RequestTimedOutError: Request timed out

Irgendwas in dem Request passt der Datenbank nicht. Wenn ich die Abfrage auf der DB mache, zuckt die Leistung der VM noch nicht mal. Testweise nochmal 2.xx probiert. Hier läuft der Request durch.

@bananajoe war für mich bis jetzt nicht notwendig. COiOT mit der GEN1 ja alles ok.

(Standard MQTT ist 1833, der Sonoff oder der Shelly-Adapter greifen sich den aber dann schon gerne)

nuja, shelly verwendet 1882 als standard. mqtt adapter 1885. genau deswegen hab ich mqtt nicht verwendet. muss mich wohl mehr damit beschäftigen...

@homoran
@paul53

Danke euch für eure (wie immer) perfekte Hilfe!! Ich glaube da wäre ich in 100 Jahren nicht drauf gekommen den Wert zu verändern. Jetzt geht es wieder!
Danke!!

@mcu Perfekt! Vielen Dank! Das hat geholfen 😄

Ich kann das bestätigen.
Im Objektbaum geht es nicht.
Flot gehts hab ich gestern durch echart ersetzt klasse Teil.
In Echart geht es auch.

Welche Datenbank nimmt ihr? History oder eine andere und warum?

cu Deta

@glasfaser sagte in Adapterupdate schlägt fehl > Version dennoch hochgezogen:

Nicht Böse sein ....aber :

wenn man sich wie du im Beta -Zweig aufhält , kann es schon sein das es so zu diesem kommen kann .

Da muß man schon sein System kennen bzw. auch mal was einstecken das sowas kommen kann .

Danke für die Blumen, dessen bin ich mir durchaus bewusst und auch nicht böse. Diese Aussagen lassen sich sehr häufig hier im Forum lesen.

Kann ich deiner Aussage denn entnehmen bzw. würdest du diese so umformulieren?
"Wenn du NICHT im Beta-Zweig unterwegs gewesen wärst, dann wären diese Fehler NICHT aufgetaucht"?

Ich danke dir.

@int17

Dann passt doch alles.
Und trotzdem gibt es KEINEN Grund für ein login als root.

@haselchen

Ja genau. So siehts aus 🙂

Danke dir für deine Hilfe!

@schranzistor sagte in Zigbee DJT11LM Keine Verbindung:

Namen hatte er auch sofort den gleich wie bevor die Probleme angefangen haben.

ja da dieser nach der ieee id gespeichert werden...

@oliverio enter drücken! Die Vorschau ist grausam

@haselchen
meinte den Admin 🙂

Ich hatte die gleichen Probleme - habe auch viel rum probiert und mich letztendlich dafür entschieden ein Full-Back (Windows) aus dem Januar auf den ioB Rechner einzuspielen.

Von Januar bis jetzt, ist Adapter Versionsnummern mäßig schon ein Brett. Ich habe dann über die Konsole alles brav nacheinander aktualisiert, die aktuelle VIS eingespielt und nun läuft wieder alles.

Im Grunde ist jetzt alles auf genau dem gleichen Versionsstand wie mit der "kaputten" ioB Installation. Sowohl das Updaten, als auch das Speichern im VIS Editor (Verbindungsfehler) funktioniert nun wieder.

Was mich an der ganzen Sache nervt: Ok, das dass Vollbackup so lange zurück liegt, ist mein Problem - ohne Frage, ABER ich mach ja immer brav jeden Tag ein Backup mit Backitup. Mich nervt, das man dieses immer nur im ganzen wieder einspielen kann. D.h., man zieht sich die ganze Fehler evtl. wieder mit ins System.

Wenn man Adapter für Adapter aus diesem Backup einzeln wieder herstellen und danach durchtesten könnte, hätte man im Nachgang nicht soviel Arbeit mit dem anpassen von den diversen Änderungen. So ein super Kandidat ist z.B. Sourceanalytix. Bei einem so langen Zeitraum der dazwischen liegt, ist die komplette Datenbasis eigentlcih für die Tonne - da passt jetzt bei mir nix mehr und das bei vielen Adaptern auf die SA aufsetzt.