UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[mickym]

Ich habe langsam das Gefühl, dass neben den neuen Funktionalitäten des NodeRed Adapters teilweise Änderungen im Hintergrund erfolgen, die in meinen Augen unerwünscht sind.

Bestes Beispiel (Issue bereits eröffnet), ist dass die Systemconsolen Meldungen der Debug Nodes nicht mehr im Info Level des iobroker Logs auftauchen.

Nun habe ich wieder eine Nachricht, die es vor der Version 5.2.0 nicht gab:

node-red.0
2024-03-30 18:46:15.746	error	source in "alias.0.schalter.bu_maxlan.on" does not exist for "read" function: "val === 'on' ? true : false"

Dieses Fehlermeldung gabs vorher nicht und ist einfach falsch:

Natürlich gibt es diesen Datenpunkt

Nur ist das halt ein "Folder", der aber unter mqtt ein state ist, der weitere states enthält. Kann es sein, dass hier wieder auf Datentypen abgeprüft wird und man wieder Dinge verschlimmbessert, weil sich das mqtt Protokoll nicht an die iobroker Struktur hält?
Wieso überprüft der NodeRed Adapter plötzlich Dinge, die mit NodeRed in meinen Augen nichts mehr zu tun haben?

Auch scheinen die Meldung zur fehlerhaften NodeRed Adapter Konfig des Admin Adapters mit der Version 5.2.0 nicht vom Tisch zu sein.

admin.0
2024-03-30 19:33:44.257	warn	node-red has an invalid jsonConfig: [{"instancePath":"/items/_authentication/items/authExt/items/1","schemaPath":"#/definitions/passwordProps/additionalProperties","keyword":"additionalProperties","params":{"additionalProperty":"attr"},"message":"must NOT have additional properties"},{"instancePath":"/items/_authentication/items/authExt","schemaPath":"#/patternProperties/%5E.%2B/allOf/23/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match \"then\" schema"},{"instancePath":"/items/_authentication","schemaPath":"#/properties/items/patternProperties/%5E.%2B/allOf/8/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match \"then\" schema"},{"instancePath":"","schemaPath":"#/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match \"then\" schema"}

https://github.com/ioBroker/ioBroker.node-red/issues/460

https://github.com/ioBroker/ioBroker.node-red/issues/458

[mickym]

Nun ja - trotzdem ich eigentlich hier und nun mit Screenshots auch im Thread dokumentiert habe, dass die Definition und die Funktion korrekt ist - und die Fehlermeldung einfach falsch ist, wurde das Issue einfach zu gemacht.

Was soll ich dazu eigentlich noch sagen?

Wahrscheinlich irgendein timeout Problem - jedenfalls scheint der Fehler nicht nochmal aufzutreten und es wurde nichts an der Konfiguration geändert.

[haus-automatisierung]

@mickym sagte in Immer merkwürdigere Log-Einträge des NodeRed Adapters:

trotzdem ich eigentlich hier und nun mit Screenshots auch im Thread dokumentiert habe, dass die Definition und die Funktion korrekt ist - und die Fehlermeldung einfach falsch ist, wurde das Issue einfach zu gemacht.

• Es gab im Issue keinen Verweise auf den Foren-Thread
• Der Issue auf GitHub war ziemlich unvollständig dokumentiert und die Infos (Screenshots usw.) wurden ja erst hinzugefügt, nachdem der Issue geschlossen wurde.

Was soll man dazu sagen? :)

[mickym]

@haus-automatisierung Vielleicht mal nachfragen, anstatt einfach zu zumachen?? Aber lassen wir das der Fehler ist bislang nicht mehr aufgetreten und ich werde mir halt wieder 2 mal überlegen bevor ich was melde. Mein System läuft im Übrigen schon einige Monate/Jahre, sodass ich glaub schon beurteilen kann, wenn etwas auftritt, was vorher nicht auftrat.

[haus-automatisierung]

@mickym sagte in Immer merkwürdigere Log-Einträge des NodeRed Adapters:

und ich werde mir halt wieder 2 mal überlegen bevor ich was melde.

Die Frage ist halt, was jemand mit so einem Issue anfangen soll. Zwei Sätze und eine Fehlermeldung. Den Rest soll man sich dazu denken und erstmal fragen?! Ich mache mittlerweile Issues auch oft einfach zu, wenn die so halbherzig beschrieben sind.

Deinen Issue hatte ich auch in meinem Mailpostfach und hab die direkt als gelesen markiert, weil alles fehlt. Habe mich dann anderen Repos und Issues gewidmet. Sieh es doch mal von der anderen Seite...

@mickym sagte in Immer merkwürdigere Log-Einträge des NodeRed Adapters:

sodass ich glaub schon beurteilen kann, wenn etwas auftritt, was vorher nicht auftrat.

Dann ist es doch auch kein Problem den Issue vollständig zu beschreiben?! Keine Objekt-Definition, keine Angabe zum js-controller (welcher ja für die Alias-Geschichten verantwortlich ist) usw.

[apollon77]

@mickym Alias Fehler kommen vom js-controller und nicht vom Adapter in dem Fall.

Der Fehler bedeutet das node-red auff den alias alias.0.schalter.bu_maxlan.on zugreifen wollte und dort scheinbar kein "common" im Read object hinterlegt ist. Zeig btte mal wie das read object aussieht im json ... da scheint der "common" teil zu fehlen.

[mickym]

@apollon77 sagte in Immer merkwürdigere Log-Einträge des NodeRed Adapters:

@mickym Alias Fehler kommen vom js-controller und nicht vom Adapter in dem Fall.

Der Fehler bedeutet das node-red auff den alias alias.0.schalter.bu_maxlan.on zugreifen wollte und dort scheinbar kein "common" im Read object hinterlegt ist. Zeig btte mal wie das read object aussieht im json ... da scheint der "common" teil zu fehlen.

Ich hab es schon im Issue nachgetragen - wie gesagt es funktioniert alles und diese Fehlermeldung hatte ich noch nie gehabt vorher:

Hier die Definition des Alias:

{
  "_id": "alias.0.schalter.bu_maxlan.on",
  "type": "state",
  "common": {
    "name": "on",
    "role": "",
    "type": "boolean",
    "desc": "Manuell erzeugt",
    "read": true,
    "write": true,
    "def": false,
    "alias": {
      "id": {
        "read": "mqtt.1.shellies.steckdosen.buero.max.relay.0",
        "write": "mqtt.1.shellies.steckdosen.buero.max.relay.0.command"
      },
      "read": "val === 'on' ? true : false",
      "write": "val ? 'on' : 'off'"
    }
  },
  "native": {},
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1670913989857
}

Übersetzung des ts nach Realtime: 13.12.2022 - 07:46:29

Hier die Definition des mqtt Datenpunktes:

{
  "_id": "mqtt.1.shellies.steckdosen.buero.max.relay.0",
  "common": {
    "name": "shellies/steckdosen/buero/max/relay/0",
    "write": true,
    "read": true,
    "role": "variable",
    "desc": "mqtt client variable",
    "type": "string"
  },
  "native": {
    "topic": "shellies/steckdosen/buero/max/relay/0"
  },
  "type": "state",
  "from": "system.adapter.mqtt.1",
  "user": "system.user.admin",
  "ts": 1670913626765,
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Übersetzung des ts nach Realtime: 13.12.2022 - 07:40:26

und hier die Version des JS Adapters - also 5.0.19:

Anhand der Timestamps kann man ja gerne nachprüfen, dass die Definition und der Datenpunkt schon lange existieren.

Und ich verstehe immer noch nicht, warum wenn der JS Adapter ein Problem hat, das von NR reportet wird. Wie gesagt es ist bislang nur einmal aufgetreten und wenn das nicht weiter untersucht werden soll, ist für mich OK - nur die Art ist mir eben aufgestoßen.

[apollon77]

@mickym Aliasse werden nicht zentral vom js-controller verarbeitet sondern quasi jeder Adapter der einen Alias nutzt löst das auf. Das ist so am performantesten mit der verteilten Struktur von ioBroker. Daher erfolgen Alias Fehler (leider) Log technisch immer bei dem Adapter der darauf zugreifen will.

Ich würde es - vor allem wenn es nur einmal bisher aufgetreten ist - weiter beobachten. Falls es weiterhin passiert müsste man mal versuchen der ursache auf den Grund zu gehen. Sonst war es ein Glitch ... Komisch