durchgestrichener Feldname

[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. Aber: Ich brauche keine Beispiele à la „Wie sag‘ ich‘s meinem Kind“. 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?

[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!

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.

[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.

[ticaki]

@legro
Nochmal zurück zum eigentlichen Thema:

Wenn du kein Typescript benutzt sollten die Skripte über Jahre stabil und ohne Änderung laufen, solange du nichts einbaust das als veraltet markiert ist. Und halt changelog lesen, wenn der Javascript adapter ne 10, 11, 12 usw. vorne bekommt.

Bei Typescript kann die immer besser werdende Fehlererkennung, das transpilieren verhindern, in dem sie dich auf einen alten aber jetzt gefunden Fehler hinweist.

[haus-automatisierung]

@legro sagte in durchgestrichener Feldname:

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.

Welche Datenstruktur ist denn konkret bedroht?!

Hier übrigens noch die (sehr lange) Liste an Windows deprecated Features, welche bald rausfliegen: https://learn.microsoft.com/en-us/windows/whats-new/deprecated-features

[legro]

@haus-automatisierung

Danke, dass du nochmals nachfragst. Bedroht ist (hoffentlich) konkret nichts. Mir hat die hier im Thread gewonnene Erkenntnis, dass offenbar Teile von Objekten veralten können, einen gehörigen Schreck eingejagt. An so etwas hätte ich nicht im Traum gedacht.

Oh je, was habe ich hier losgetreten. Nun will ich hier keine Grundsatzdiskussion führen, dazu habe ich in Sachen JavaScript viel zu wenig Grundlagenwissen. Es ist müßig, die einzelnen Systeme gegeneinander aufrechnen zu wollen. So habe ich als Anfänger in JavaScript innerhalb eines guten halben Jahres dank der Mächtigkeit von JavaScript Lösungen umsetzen können, die ich mit den mir vertrauten Sprachen wohl kaum in so kurzer Zeit hinbekommen hätte. Ich habe mir nun vorgenommen, alles nicht so ernst zu nehmen, schließlich ist es ja nur ein Hobby für mich.

[Homoran]

@legro sagte in durchgestrichener Feldname:

dass offenbar Teile von Objekten veralten können,

Da bist du auf dem Holzweg!
Wo steht das???

es geht nur um den Befehl newState im Javascript. Nichts anderes.

mit den Objekten, oder Teilen davon, passiert gar nichts

Was, bitte, müssen wir tun, damit du dieses Missverständnis, auf das du deine Argumentationen aufbaust, erkennst, damit sich alle deine Bedenken in Wohlgefallen auflösen?

edit: korrigiert

[legro]

@homoran sagte in durchgestrichener Feldname:

es geht nur um den Befehl getState im Javascript. Nichts anderes.

getState(?) bzw. state sollte nach der hier verwendeten Syntax (obj.state.val) doch kein dynamischer Befehl/Funktion sein, sondern ein statisches Feld von obj.

Jetzt bin ich noch verwirrter. Lassen wir‘s gut sein. Ich weiß ja nun für den hier diskutierten Fall, was zu tun ist.

[haus-automatisierung]

@legro sagte in durchgestrichener Feldname:

Mir hat die hier im Thread gewonnene Erkenntnis, dass offenbar Teile von Objekten veralten können, einen gehörigen Schreck eingejagt.

Nochmal: Das Objekt, welches dynamisch zusammengebaut wird und zwei identische Eigenschaften hat (state und newState) wird dynamisch vom JavaScript Adapter zusammengebaut und dann an deine definierte Callback-Funktion übergeben.

Dass die eine Eigenschaft vor gut 8 Jahren umbenannt wurde und man deswegen den alten Namen nicht mehr verwenden sollte, sagt dir der Script Editor schon genau so lange.

Du müsstest dich jetzt also weiterhin weigern den „neuen“ Namen zu verwenden, dann irgendwann ein Upgrade vom JavaScript Adapter machen (wobei noch nichtmal klar ist, wann das Attribut wirklich entfällt), das Changelog ignorieren und das Upgrade trotzdem machen und dann ein Problem bekommen dass der Wert nicht mehr gelesen werden kann, wenn der Trigger auslöst.

Heißt: Viel Lärm um nichts. Du hängst das hier viel zu hoch auf. Das ist ein ganz normaler Prozess in jeder Software und man hat wirklich eine Ewigkeit Zeit um die Scripts anzupassen.