Korrektur des Umgangs mit Preset-Variablen. Wenn in manchen Exposes zum Beispiel folgende Presets kamen:
„presets“:[{„name“:„coolest“,„value“:200,„description“:„Coolest temperature supported“},{„name“:„cool“,„value“:250,„description“:„Cool temperature (250 mireds / 4000 Kelvin)“},{„name“:„neutral“,„value“:370,„description“:„Neutral temperature (370 mireds / 2700 Kelvin)“},{„name“:„warm“,„value“:454,„description“:„Warm temperature (454 mireds / 2200 Kelvin)“},{„name“:„warmest“,„value“:454,„description“:„Warmest temperature supported“}]}
Gab es einen Fehler, da “Warm” und “Warmest” gleichwertig waren. Das modul rechnet jetzt aus “Neutral” und “Warmest” einen Zwischenbereich und nimmt diesen als “Warm”.
Die in der Fehlermeldung genannte Darstellung ist defekt.
Das kannst du meistens beheben, wenn du in der Konsole die einmal zum bearbeiten öffnest (eventuell mal die Intervalle oder Optionen durchgehen) und neu speicherst.
Vorher am besten schauen zu welchem Modul die Variable gehört und im passenden Thema die fehlerhafte Darstellung melden.
Michael
Danke für den Hinweis. Das scheint an der neuen Darstellung von Variablen zu liegen denn nachdem ich die erste Variable angepasst hatte kam die nächste mit der Meldung. Was mich wunderte war das die Variable eigentlich nicht so offensichtich im WebFront benutzt wurde da sie absolut keine Referenzen hatte. War learned_ir_code von einem Z2M-IR-Sender.
Das hatte ich auch schon mit Z2M und vielen VAR’s aus der neuen Version von Z2M(6.0), hab die alle gelöscht.
Waren Wochenwerte von Ventilen mit So-Sa usw. Ev muss Burki24 noch mal nachsehen, hatte ich aber nicht gemeldet.
Schade, da hätte ich mehr Infos gebrauchen können. Vielleicht kannst Du mir da noch was zu sagen. Oder aber ich lerne hier im Testsystem alle Thermostate die ich habe an und schaue selber.
Update ist raus.
Bitte testen und Rückmeldung geben. Das Modulupdate behebt den Fehler in den jeweiligen Variablen selber. Ausnahme, Ihr habt da schon händisch vorher was verändert. Variablen mit Änderungen von den Usern werden gemäß Symcon nicht angefasst.
Der Fehler war die falsche Darstellung VARIABLE_PRESENTATION_TEXT_BOX wird jetzt durch die korrekte VARIABLE_PRESENTATION_VALUE_INPUT ersetzt.
eine neue Version ist online mit folgenden Änderungen:
Numerisch indizierte Root-Payloads ohne Zigbee2MQTT-Property werden beim Payload-Import jetzt ignoriert. Dadurch lösen Geräte, die einzelne Werte oder Listenfragmente ohne Variablen-Ident senden, keinen TypeError in der Variablenverarbeitung mehr aus.
Lesbare Set-Aktionen wie Schalter, Helligkeit, Farbtemperatur und andere Statuswerte aktualisieren lokale Symcon-Werte erst nach einer Rueckmeldung von Zigbee2MQTT.
Reine Schreib- und Befehlswerte ohne eigene Rueckmeldung, zum Beispiel Szenen, Presets, Effekte oder andere access: 2-Funktionen, merken nach erfolgreichem Senden weiterhin den zuletzt gewaehlten Wert lokal.
Helligkeitsaktionen nutzen dieselbe Rueckmeldepruefung wie andere Standardaktionen und geben Sendefehler wieder korrekt an die Aktion zurueck.
Schreibgeschützte Textvariablen erhalten keine Darstellung mehr, die eine Variablenaktion voraussetzt. Dadurch entfallen die entsprechenden Kompatibilitätsfehler in der Variablenkonfiguration.
Beschreibbare Textvariablen verwenden die native mehrzeilige Werteingabe anstelle der nicht vom klassischen WebFront konvertierbaren Text-Box-Darstellung.
26 Übersetzungen wurden ergänzt und eine bestehende Übersetzung überarbeitet. Dies umfasst insbesondere Wetterwerte wie Wind, Böen, Niederschlag, Taupunkt, gefühlte Temperatur, Hitze- und Luftfeuchtigkeitsindex sowie zusätzliche Geräte-, Betriebs- und Zeitmodi.
Zugangsdaten, Installcodes, Tokens, Schlüssel und eingebettete URL-Zugangsdaten werden in Discovery-Debugausgaben rekursiv maskiert. Die unveränderte Übermittlung dieser Werte an Zigbee2MQTT bleibt davon unberührt.
Variablenaktionen werden vollständig mit den aktuellen Schreibrechten eines Exposes synchronisiert. Nicht mehr beschreibbare Variablen verlieren ihre Standardaktion; explizite Aktionskonfigurationen haben weiterhin Vorrang.
LastPayload führt partielle MQTT-Nachrichten nun korrekt zusammen: neue Werte ersetzen alte Werte, nicht erneut gesendete Felder verschachtelter Objekte bleiben erhalten und Listen werden vollständig ersetzt.
Die laufende OTA-Anzeige wird bei Statusänderungen wieder automatisch aktualisiert. Schutzprüfungen verhindern Fehler, wenn Formular oder Instanz während eines Reloads vorübergehend nicht erreichbar sind.
Die MQTT-Transaktionsverwaltung verhindert ID-Kollisionen und das Überschreiben offener Anfragen, validiert Antwort-IDs und schützt sämtliche Pufferzugriffe mit zuverlässig freigegebenen Sperren.
SendGetCommand() fordert nur noch Properties an, die laut Zigbee2MQTT-Expose tatsächlich per GET lesbar und nicht gefiltert sind. Leere oder ausschließlich schreibbare Anfragen werden nicht gesendet.
Änderungen am Variablenkatalog werden während Payload-, Expose-, Aktualisierungs- und Wiederaufbauvorgängen gesammelt und höchstens einmal persistiert. Unveränderte Kataloge verursachen keinen erneuten Attributschreibzugriff.
Die Discovery zeigt sofort den zuletzt bekannten Stand an und aktualisiert einen älter als 60 Sekunden gewordenen Cache asynchron. Eine zusätzliche Schaltfläche ermöglicht weiterhin eine manuelle Aktualisierung.
Die automatisierten Regressionstests wurden für die neuen Schutzmechanismen und für die bereits entfernte Profil-Diagnose des Bridge-Formulars angepasst und erweitert.
Umfangreiche Verantwortlichkeiten wurden ohne beabsichtigte Funktionsänderung aus Bridge/module.php und libs/ModulBase.php in spezialisierte Helper ausgelagert.
Die Bridge-Helper kapseln Konfiguration, Geräte, Gruppen und Szenen, Diagnose, Requests, OTA, Netzwerksicherheit, Installcodes, Backups, Pairing, veraltete Variablen und Touchlink.
Die Modul-Helper kapseln Gerätebefehle und -aktionen, Payload-Verarbeitung und -struktur, Expose-Registrierung, Variablenwerte, Variablenlaufzeit und sichere Runtime-Zugriffe.
Für eine einheitliche Verzeichnisstruktur liegen die Bridge-Helper unter Bridge/Helper und die Helper der Modulbasis unter libs/ModulHelper
Wurde wieder entfernt, da es User gibt, die Automationen nicht auf veränderete Werte auslösen, sondern auf Aktualisierung der Variable, was auch korrekt ist. Danke @Nall-chan für den Hinweis.
Und diese Änderung ändert ja nichts am Datenaufkommen von Z2M aus sondern nur die Belastung des Rechners, wo symcon drauf ist und bei meinem RPI5 merke ich keinen Unterschied. Von daher eher unnötig und ungünstig. Hatte auch ich mir mehr von versprochen.
Für eine bessere Fehlersuche wurde ein neues Helper-Tracing integriert. Im Symcon-Debug ist jetzt anhand von START, END und ERROR direkt erkennbar, welcher Helper einen Vorgang verarbeitet oder einen Fehler verursacht hat. Sensible Daten und vollständige Payloads werden dabei nicht protokolliert.
