js-controller 3.3 jetzt im Beta

[Feuersturm]

@ide10 Hierfür muss ein Github issue beim entsprechenden Adapter erstellt werden (falls es nicht schon existiert)

[Asgothian]

Die bereichsprüfung bei states vom Typ Zahl bringt die folgende Meldung:

zigbee.0 (17015) State value to set for "zigbee.0.60a423fffeab479f.local_temperature_calibration" has value "-1" less than min "undefined"

Ein Check im code hat gezeigt das keine min/max Werte gesetzt werden.

• Sind diese in Zukunft führ zahlen Pflicht ?
• muss das im zigbee adapter Gefeixes werden, oder kann auf die Prüfung verzichtet werden wenn keine Werte gesetzt werden ?

A.

[da_Woody]

@ide10 wenns nur radar2 gewesen wäre...
alle betroffenen nach tip auf error gestellt, github nachegelesen, waren eigentlich schon überall issues dazu da.
jetzt liegts an den devs wann sie heit haben zum fixen...

[frana120500]

Moin zusammen,

Upgrade JS-Controller in einem Multihost System habe ich von der 3.1.6 zur 3.3.4 aufgrund des Hinweises erst den Master, dann den Slave.

Beim Upgrade von 3.3.4 auf 3.3.5 mache ich es auch so, oder erst den Slave und dann den Master (so wie sonst)?

[foxriver76]

@asgothian Wie meinst du ein Check im Code? Zeig doch mal das Raw vom DP. bei min wurde fehlerhaft max geloggt, weshalb ich annehme dass ein min definiert ist, max jedoch nicht.

[Tom Son]

Guten Tag...

Habe auch das update vollzogen und bei mir sind im Zigbee Adapter alle Geräte verschwunden, da ist nur mehr der Coordinator (habe den CC26x2R1) Unter Netzwerk sind alle noch zu sehen aber nicht mehr verbunden. Ich müsste jetzt alle 30 Geräte wieder neu pairen

Der Zigbee Adapter läuft bei mit V 1.5.3
nodejs -v && npm -v && iobroker -v
v12.22.1
6.14.12
3.3.5

Hat das sonst noch jemand? Was kann ich tun?
Edit:
Wenn ich das Pairing starte kommen im Log folgende Warnungen:

zigbee.0	2021-05-02 10:36:02.108	warn	Read-only state "zigbee.0.info.pairingCountdown" has been written without ack-flag with value "58"
zigbee.0	2021-05-02 10:36:01.111	warn	Read-only state "zigbee.0.info.pairingMessage" has been written without ack-flag with value "Pairing time left: 59"
zigbee.0	2021-05-02 10:36:01.109	warn	Read-only state "zigbee.0.info.pairingCountdown" has been written without ack-flag with value "59"
zigbee.0	2021-05-02 10:36:00.113	warn	Read-only state "zigbee.0.info.pairingMessage" has been written without ack-flag with value "Pairing time left: 60"
zigbee.0	2021-05-02 10:36:00.110	warn	Read-only state "zigbee.0.info.pairingCountdown" has been written without ack-flag with value "60"
zigbee.0	2021-05-02 10:35:58.880	warn	Read-only state "zigbee.0.info.pairingMessage" has been written without ack-flag with value "Pairing started "
zigbee.0	2021-05-02 10:35:58.870	info	Zigbee: allowing new devices to join.

Das geht so lange bis auf 0 runtergezählt ist...

[Homoran]

@apollon77 sagte in js-controller 3.3 jetzt im Latest:

Eine 3.3.5 kommt demnächst ins Latest.
Hauptänderung ist das wir den Loglevel der Meldungen auf info reduziert haben

ich habe mittlerweile auf 3.3.5 upgedated und bekomme noch immer warn - Meldungen von backitup:
u.a.:

backitup.0	2021-05-02 04:03:29.174	warn	Read-only state "backitup.0.output.line" has been written without ack-flag with value "[DEBUG] [cifs] - done"

ist das was anderes?
...without ack... ist wohl Bestandteil all dieser Meldungen.

[Thomas Braun]

@homoran
Mit Backitup 2.1.6 auch noch? Das kam eben ganz frisch bei mir rein.

[Homoran]

@thomas-braun sagte in js-controller 3.3 jetzt im Latest:

Mit Backitup 2.1.6 auch noch?

hann isch nit!

@thomas-braun sagte in js-controller 3.3 jetzt im Latest:

kam eben ganz frisch bei mir rein.

dann hat sich das bei dir zu lange aufgehalten.
Jetzt ist es endlich bei mir anegkommen

[Jan1]

@homoran
das rennt bei mir schon seit heute morgen

[Thomas Braun]

@homoran sagte in js-controller 3.3 jetzt im Latest:

dann hat sich das bei dir zu lange aufgehalten.

Hab es eben in die 16 gesetzt und in Richtung Kölner Süden geschickt.

Ist jedenfalls ganz brav und plappert jetzt das Log nicht mehr voll.
Hat @simatec gut gemacht!

[Homoran]

@thomas-braun sagte in js-controller 3.3 jetzt im Latest:

Hab es eben in die 16 gesetzt und in Richtung Kölner Süden geschickt.

Ach deswegen!
hättest es in die 132 setzen müssen

[Asgothian]

@foxriver76
Das ist denkbar. Es gibt 2 Code-stellen die relevant sein können. Im einen Fall wird min 0 und Max undefined gesetzt,

            state = {
                id: stateId,
                prop: propName,
                name: stateName,
                icon: undefined,
                role: role || 'state',
                write: write,
                read: true,
                type: 'number',
                min: expose.value_min || 0,
                max: expose.value_max,
                unit: expose.unit,
            };

im anderen Fall wird weder min noch Max gesetzt.

hvacThermostat_local_temp_calibration: {
        id: 'local_temp_calibration',
        prop: 'local_temperature_calibration',
        name: 'Temperature Calibration',
        icon: undefined,
        role: 'value.temperature',
        write: true,
        read: true,
        type: 'number',
        unit: '°C',
    },

Für mich stellt sich die Frage ob das im zigbee adapter korrigiert werden muss (immer beide Grenzen setzen) oder im jscontroller.

A.

[foxriver76]

@asgothian Ja, im DP kannst du doch direkt sehen was drin steht, da ich davon ausgehe, dass er auf deinem System existiert?

Der Zigbee Adapter sagt, hier werden nur States mit dem Wert größer als 0 reingeschrieben, schreibt dann aber -1 rein, daher klarer Fehler im Adapter. Wenn da Werte kleiner 0 drin stehen sollten, sollte das Minmium nicht mit 0 definiert werden. Ein Visu Adapter der z. B. einen Slider anzeigt und davon ausgeht, dass ein Wert zwischen 0 und 100 ist, da es so definiert wurde vom Adapter dann aber -50 drin steht, kann das beispielsweise dann nicht korrekt verarbeiten.

[foxriver76]

@homoran Bislang wurden nur die Typfehler runtergesetzt vom Loglevel. Sprich ack-flag und min/max ist weiterhin warn. Kann sich aber bis stable noch ändern, wobei die ack und min/max Geschichte wirklich schnell gefixt sein sollte im Vergleich zu den Type Mismatches wo der Dev mal bisschen tiefer in den Code schauen muss.

Backitup sollte das ack-Problem z. B. in der neuen Version gefixt haben.

[FredF]

@tom-son sagte in js-controller 3.3 jetzt im Latest:

Zigbee Adapter alle Geräte verschwunden

Der Zigbee Adapter läuft bei mit V 1.5.3

Falscher Thread? Schau mal hier. Hat bei mir geholfen

[Asgothian]

@foxriver76 sagte in js-controller 3.3 jetzt im Latest:

@asgothian Ja, im DP kannst du doch direkt sehen was drin steht, da ich davon ausgehe, dass er auf deinem System existiert?

Leider nicht da die Meldung aus einem issue am zigbee Adapter stammt. Ich habe weder den datenpunkt noch die Meldung. Wenn die Tatsache das Max undefined ist nicht Ursache der Warnmeldungen ist sondern das min=0 dann ist das klar ein issue für den zigbee Adapter. Erkennen kann ich das alleine aus der Meldung leider nicht - insbesondere auch deswegen da es 2 mögliche code stellen gibt.

A.

[apollon77]

@asgothian Es ist so. Wenn im Objekt min/max definiert ist dann prüfen wir jetzt mal ob der gesetzte Wert auch dazu passt. Ohne min/max gibts natürlich keine Prüfung (was jetzt aber bitte NICHT heissen soll alle min/max wegzulassen weil Sie sind für die ganzen Visus durchaus wichtig. Ohne min/max können die keine sinnvollen selektoren und so darstellen - ein teufelskreis )
Wenn nicht passt kommt aktuell nur der Wert weil am Ende kann es ja vom Adapter kommen der einen falschen Wert schreibt oder auch vom User.

Seit controller 3.3. gibt es auch "step" als neues Attribut für Objekte. Hier wird dann der zu setzende Wert nach dem angegebenen "step" automatisch gerundet (das gibt keine Fehlermeldung).

[apollon77]

@frana120500 In dem Fall ist nichts "Breaking"...geht also beides ...

[apollon77]

@asgothian Wenn es uneindeutig ist dann ggf beim User nachfragen nach nem Debug log ...