Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[paul53]

@legro sagte: warum liefert dann die Ausgabe in dem heute erstellten JavaScript in console.log(obj) die uralte Feldbezeichnung?

Weil sie auch noch existiert (Abwärtskompatibilität).

[legro]

@paul53 sagte in durchgestrichener Feldname:

@legro sagte: warum liefert dann die Ausgabe in dem heute erstellten JavaScript in console.log(obj) die uralte Feldbezeichnung?

Weil sie auch noch existiert (Abwärtskompatibilität).

Da ich mich in Sachen JavaScript noch immer als Anfänger fühle und die Objekte (noch) nicht kenne, gebe ich diese mir halt via console.log aus, um auf diese Weise die Feldnamen kennenzulernen. Ich verstehe nicht, warum mir hier das deprecated Zeugs angezeigt wird.

[Homoran]

@legro Was hat der "Feldname" mit der Info über deprecated zu tun?

Der durchgestrichene Begriff ist ein Javascript Befehl, der nicht mehr genutzt werden sollte, du ihn aber noch im Script verwendest

[legro]

@homoran sagte in durchgestrichener Feldname:

@legro Was hat der "Feldname" mit der Info über deprecated zu tun?

Der durchgestrichene Begriff ist ein Javascript Befehl, der nicht mehr genutzt werden sollte, du ihn aber noch im Script verwendest

Nicht ich verwende doch hier den uralt Befehl, sondern der wird doch von JavaScript geliefert! Und ich frage mich, warum?

[Homoran]

@legro sagte in durchgestrichener Feldname:

der wird doch von JavaScript geliefert!

nein, du hast ihn im Script

@legro sagte in durchgestrichener Feldname:

obj.newState.val)

den sollst du mit state ersetzen

[paul53]

@legro sagte: Nicht ich verwende doch hier den uralt Befehl

Doch (erster Post)

@legro sagte in durchgestrichener Feldname:

Der nachfolgende Auszug aus meinem Skript zeigt ein solches Beispiel ..

[haus-automatisierung]

@legro sagte in durchgestrichener Feldname:

Nicht ich verwende doch hier den uralt Befehl, sondern der wird doch von JavaScript geliefert! Und ich frage mich, warum?

Weil er existiert. Das sind halt Daten. Der muss ja existieren um noch verwendet zu werden zu können. Sonst würde das Script ja nicht mehr laufen. Wie sollte die Console denn darstellen, dass etwas deprecated ist?!

Wenn in der Zeitung steht, dass ab Montag die Auffahrt zur A1 gesperrt wird, beschwer Du Dich ja auch nicht am Sonntag, dass die Straße noch da ist?!

[legro]

@haus-automatisierung

@haus-automatisierung sagte in durchgestrichener Feldname:

@legro sagte in durchgestrichener Feldname:

Nicht ich verwende doch hier den uralt Befehl, sondern der wird doch von JavaScript geliefert! Und ich frage mich, warum?

Weil er existiert. Das sind halt Daten. Der muss ja existieren um noch verwendet zu werden zu können. Sonst würde das Script ja nicht mehr laufen. Wie sollte die Console denn darstellen, dass etwas deprecated ist?!

Irgendwie reden wir nach meinem Verständnis an dem Problem meilenweit vorbei. Ein letzter Versuch.

• Da ich nicht wusste, welche Felder die von mir verwendeten Datenpunkte besitzen, habe ich die Datenpunkte, die ich in dem Trigger verwenden möchte, als gesamtes Objekt mittels console.log ausgegeben.

• Das oben in Auszügen dargestellte Skript habe ich heute mit dem aktuellen JavaScript-Adapter erstellt. Es kann mithin nicht veraltet sein.

• Jetzt schreibst du, dass console.log natürlich nicht weiß, dass das Feld newState deprecated ist.

• Meine Schlussfolgerung: Hier ist nicht - wie die ganze Zeit ausgeführt - das Skript veraltet, es müssen mithin meine vor Jahren generierte Datenpunkte im Objektbaum sein.

• Konsequenz: Nicht nur Skripte können veraltet sein, auch die Deklarationen von Datenpunkten.

Die negativen Konsequenzen möchte ich mir lieber gar nicht ausmalen. Nein, ich muss es wohl doch. Wenn ich mein System mittels Updates aktuell halte, könnte es mir passieren, dass mein System dennoch abstirbt, weil alte Datenpunkte mit abgekündigten Feldnamen nicht mehr unterstützt werden.

Oder liege ich hiermit daneben?

[Homoran]

@legro sagte in durchgestrichener Feldname:

Irgendwie reden wir nach meinem Verständnis an dem Problem meilenweit vorbei

richtig!
Das geht schon bei deinem Threadtitel los.

Huer geht es nicht um einen "Feldnamen" der veraltet ist, sondern um den von dir verwendeten Befehl newState mit dem du die Konsolenausgabe des Wertes des Datenpunktes füllen willst

@legro sagte in durchgestrichener Feldname:

Oder liege ich hiermit daneben?

nochmal richtig!

[paul53]

@legro sagte: Oder liege ich hiermit daneben?

Ja, völlig.
Du verwendest im Skript (erster Post) eine veraltete Eigenschaft des DP-Objektes, die aber noch existiert. Suche in deinen Skripten nach newState und ersetze sie durch state. Das ist alles.

[haus-automatisierung]

@legro sagte in durchgestrichener Feldname:

Da ich nicht wusste, welche Felder die von mir verwendeten Datenpunkte besitzen, habe ich die Datenpunkte, die ich in dem Trigger verwenden möchte, als gesamtes Objekt mittels console.log ausgegeben.

Ja, kannst Du ja machen. Und dann gibt es state, newState und oldState. Das alles gilt nur für den JavaScript-Adapter. Die Infos werden im JavaScript-Adapter zusammengebaut, denn der ist ja die "Schicht" zwischen deinem Script und dem js-controller.

1. Da wird newState natürlich mit ausgegeben, um abwärtskompatibel zu alten Scripts zu bleiben.
2. Du denkst Dir "cool, da steht ja alles drin was ich brauche"
3. Du tippst obj.newState und das wird durchgestrichen

An genau diesem Punkt sollte Dir klar sein, dass Du das nicht benutzen sollst (obwohl es funktioniert), weil newState als deprecated markiert ist und man laut der Info dann obj.state nutzen sollte. Konsequenz:

Du änderst obj.newState in obj.state und weißt, dass obj.newState in einer der nächsten Versionen verschwinden könnte und Dein Script dann trotzdem weiterhin funktioniert.

Wo genau reden wir jetzt aneinander vorbei?!

@legro sagte in durchgestrichener Feldname:

Konsequenz: Nicht nur Skripte können veraltet sein, auch die Deklarationen von Datenpunkten.

Der Satz ergibt null Sinn. Was hat eine Deklaration von einem Datenpunkt damit zu tun?

@legro sagte in durchgestrichener Feldname:

Das oben in Auszügen dargestellte Skript habe ich heute mit dem aktuellen JavaScript-Adapter erstellt.

Ist ja auch nicht veraltet, sondern so aktuell, dass die Typdefinition im JavaScript Adapter weiß, dass newState bald entfallen wird. Das ist ja genau die relevante Info für Dich.

@legro sagte in durchgestrichener Feldname:

Die negativen Konsequenzen möchte ich mir lieber gar nicht ausmalen.

Wenn man die deprecated-Meldung ignoriert? Jo, dann geht es halt nach einem Update nicht mehr - aber mit Ansage und das hast Du dann bewusst in Kauf genommen...

Nochmal: newState wirst Du nirgendwo in der State-Datenbank finden. Das Objekt wird vom JavaScript-Adapter dynamisch zusammengebaut. Und mit einem Update (irgendwann) wird die Eigenschaft newState nicht mehr dazu gepackt. Weil ja alle längst über Entfall informiert wurden. Ganz normaler Prozess und überall so. Bei jeder Software. Der Zustand "deprecated" ist nur eine Meta-Info und ändert nichts an der Logik. Damit Du beim Bearbeiten der Scripts darauf aufmerksam wirst.

Nimm nochmal mein Beispiel mit der Straße. Die verschwindet nicht JETZT, weil die demnächst wegen Bauarbeiten geschlossen oder aufgerissen wird. Das ist eine Info für die Zukunft. Trotzdem kannst Du sie heute noch befahren und nutzen. Nur bald halt nicht mehr. Und Du beschwerst Dich jetzt, dass das Navi dir über diese Straße noch eine Routenplanung vorschlägt, obwohl es die bald nicht mehr gibt? :)

[legro]

@haus-automatisierung

Danke für deine ausführliche Antwort.:+1: Aber: Ich brauche keine Beispiele à la „Wie sag‘ ich‘s meinem Kind“. :slightly_smiling_face: Ich habe über Jahrzehnte große Projekte nicht nur geplant, sondern auch realisiert - allerdings in anderen Betriebssystemen und Programmiersprachen. Zuverlässigkeit und Langlebigkeit waren unverzichtbare Grundlagen. Leider nimmt deine Antwort mir nicht meine Sorgen, sondern vergrößert sie eher.

Wenn ich nicht auf die hier diskutierte Weise auf den Wegfall alter Bezeichnungen aufmerksam gemacht worden wäre, hieße dies doch im schlimmsten Fall, dass mein System aufgrund veralteter Datenpunkte irgendwann nicht mehr das tut, wofür es erstellt wurde. Oder kannst du mir diese Sorgen nehmen?:thinking_face:

[haus-automatisierung]

@legro Seit fast 8 Jahren erscheint diese Meldung im Editor, dass man das nicht mehr nutzen sollte. Wie lang sollte die Übergangsfrist deiner Meinung nach noch andauern?

[OliverIO]

@legro sagte in durchgestrichener Feldname:

Danke für deine ausführliche Antwort.👍 Aber: Ich brauche keine Beispiele à la „Wie sage ich meinem Kind“. 🙂 Ich habe über Jahrzehnte große Projekte nicht nur geplant, sondern auch realisiert

Aber dann sollte dir doch eigentlich auch der Begriff der systempflege geläufig sein. Klar hier ist man in einem Community Projekt und da laufen nicht alle Prozesse nicht immer so wie sie im Profi Umfeld laufen sollten. (Auch dort nicht immer perfekt)

Unternehmen wenden einiges an Zeit auf um changelogs / Release notes / Security bulltins / etc. zu lesen und dann Aktivitäten davon ableiten. Insbesondere bei major releases gibt es immer Dinge, die man beachten sollte, selbst ohne das es die eigene Funktionalität direkt betrifft.
Macht man das nicht veraltet die eigene Software und irgendwann ist das Drama groß. Für einige Dinge meldet der iobroker ja bereits selbst im log warnhinweise, das etwas nicht mehr verwendet werden soll.

[haus-automatisierung]

@legro sagte in durchgestrichener Feldname:

Wenn ich nicht auf die hier diskutierte Weise auf den Wegfall alter Bezeichnungen aufmerksam gemacht worden wäre, hieße dies doch im schlimmsten Fall, dass mein System aufgrund veralteter Datenpunkte irgendwann nicht mehr das tut, wofür es erstellt wurde.

Was für veraltete Datenpunkte? Die haben nichts damit zu tun. Das wird im Trigger zusammengebaut. Dynamisch zur Laufzeit. Es gibt nichts zu tun für dich und alles wird problemlos weiterlaufen, wenn Du in deinen Scripts nirgendwo . newState verwendest, sondern stattdessen .state. Fertig. Das ist alles. Das betrifft ausschließlich Scripts.

Was müssen die Nutzer ggf. tun und haben dazu jetzt fast 8 Jahre Zeit gehabt? In allen Triggern .newState durch .state ersetzen. Fertig. Nichts an Datenpunkten, an der Objekt-Datenbank oder State-Datenbank.

[Homoran]

@legro sagte in durchgestrichener Feldname:

dass mein System aufgrund veralteter Datenpunkte

Was hast du immer mit den Datenpunkten??

es geht um einen javascript Befehl den du nutzt um Datenpunkte abzufragen!
Der Befehl ist veraltet, nicht die Datenpunkte!!

[legro]

@haus-automatisierung sagte in durchgestrichener Feldname:

@legro Seit fast 8 Jahren erscheint diese Meldung im Editor, dass man das nicht mehr nutzen sollte. Wie lang sollte die Übergangsfrist deiner Meinung nach noch andauern?

Selbstverständlich lebenslang!:slightly_smiling_face:

Es wird ja nur allzu gerne über M$ gelästert, aber hier habe ich nie damit rechnen müssen, dass meine Algorithmen und Datenstrukturen von einem Verfallsdatum bedroht waren. Es mag ja sein, dass ich schon zu alt bin und die Welt ganz anders sehe - da kommen wir beide wohl nicht auf einen Nenner. Zum Glück hat dieser Thread mir die Augen geöffnet, mit was man heutzutage rechnen muss. Mit derartigem hätte ich nie und nimmer gerechnet. Ich tröste mich damit, dass ich das Ganze ja nur für den Hausgebrauch - Pardon: Hausautomatisierung - benötige.:wink:

[Homoran]

@legro sagte in durchgestrichener Feldname:

Es mag ja sein, dass ich schon zu alt bin und die Welt ganz anders sehe

so sieht es im Moment wirklich aus!
Du missverstehst hier anscheinend alle Aussagen, nur weil du auf einer falschen Fährte abgebogen vist, von der du dich nicht mehr zurückbringen lässt.

Deine Struktur und deine Datenpunkte haben nichts zu befürchten

[OliverIO]

@homoran

Oh du erinnerst mich. Ich muss meine Windows. 3.11 Anwendungen neu starten. Die wollen seit kurze, nicht mehr ganz so wie ich will.
Manchmal kann mir da auch die DunningKruger Hotline helfen.
Aber alles nur Spaß

[legro]

@oliverio

Ich sollte also das Ganze künftig nicht mit Bierernst, sondern besser bloß mit Bier ernst angehen.:joy: