durchgestrichener Feldname

[legro]

Bei der Umstellung der Visualisierung zu unserem Fronius GEN24 Wechselrichter auf Modbus habe ich heute eine äußerst seltsame Erfahrung gemacht: Feldnamen werden (teilweise) durchgestrichen. Der nachfolgende Auszug aus meinem Skript zeigt ein solches Beispiel ..

//MPPT1 : Gartenhaus
on({ id: ['modbus.2.holdingRegisters.1.40272_module/1/DCA','modbus.2.holdingRegisters.1.40273_module/1/DCV',
    'modbus.2.holdingRegisters.1.40274_module/1/DCW'], change: 'ne' }, async (obj) => {
  console.log(obj.id + ' : ' + obj.newState.val)
})

Im Editor sieht das Ganze so aus ..

In dem Skript wird ein Trigger auf einem Array mit drei Datenpunkten (Strom, Spannung und Leistung eines Solarmoduls) definiert. Über die Selektion obj.newState.val kann ich erfolgreich auf den Wert in dem Objekt zugreifen.

Kann sich jemand einen Reim darauf machen?

[paul53]

@legro sagte: Kann sich jemand einen Reim darauf machen?

newState wurde vor langer Zeit durch state ersetzt. Aus Gründen der Abwärtskompatibilität funktioniert auch noch newState.

[ticaki]

@legro
Wenn etwas als veraltet markiert ist, wird es im Editor durchgestrichen angezeigt.

[legro]

@paul53 @ticaki

Vielen Dank für eure Antworten.

Das Ganze ist für mich (als immer noch Anfänger in Sachen JavaScript) sehr verwirrend. Gebe ich etwa mittels console.log(obj) den referenzierten Datenpunkt als Objekt aus, so steht dort der offenbar veraltete Feldname. Ist der Javascript-Adapter nicht auf dem neuesten Stand?

[haus-automatisierung]

@legro sagte in durchgestrichener Feldname:

Gebe ich etwa mittels console.log(obj) den referenzierten Datenpunkt als Objekt aus, so steht dort der offenbar veraltete Feldname.

Du kannst ja eventuell (?) auch noch darauf zugreifen. Nur ist das halt deprecated und wird ggf. bald rausfliegen. Und darauf will Dich der Editor hinweisen: Pass auf, Du verwendest hier Dinge, die bald ggf. nicht mehr so funktionieren. Guck lieber mal nach dem neuen Weg.

[paul53]

@legro sagte: so steht dort der offenbar veraltete Feldname

... und der neue (state).

@haus-automatisierung sagte in durchgestrichener Feldname:

wird ggf. bald rausfliegen.

Dann laufen Skripte, die ewig nicht angefasst wurden, nicht mehr!

[haus-automatisierung]

@paul53 sagte in durchgestrichener Feldname:

Dann laufen Skripte, die ewig nicht angefasst wurden, nicht mehr!

Richtig. Dann endet die Übergangsfrist. Die läuft (ich habe gerade mal nachgeschaut) seit 8 Jahren (newState ist seit 27.01.2018 auf deprecated).

[legro]

@haus-automatisierung sagte in durchgestrichener Feldname:

Richtig. Dann endet die Übergangsfrist. Die läuft (ich habe gerade mal nachgeschaut) seit 8 Jahren (newState ist seit 27.01.2018 auf deprecated).

Aber warum liefert dann die Ausgabe in dem heute erstellten JavaScript in console.log(obj) die uralte Feldbezeichnung?

//MPPT1 : Gartenhaus, Maximalwerte bestimmen
on({ id: ['modbus.2.holdingRegisters.1.40272_module/1/DCA','modbus.2.holdingRegisters.1.40273_module/1/DCV',
    'modbus.2.holdingRegisters.1.40274_module/1/DCW'], change: 'ne' }, async (obj) => {

    let tmp = 0
    
    switch(obj.id) {
        case 'modbus.2.holdingRegisters.1.40272_module/1/DCA' : //Strom
            tmp = getState('0_userdata.0.Fronius.VIS_GEN24_Betriebswerte.I1_Max').val
            if (obj.state.val > tmp) {setState('0_userdata.0.Fronius.VIS_GEN24_Betriebswerte.I1_Max', obj.state.val, true)}
            break
        case 'modbus.2.holdingRegisters.1.40273_module/1/DCV' : //Spannung
            tmp = getState('0_userdata.0.Fronius.VIS_GEN24_Betriebswerte.U1_Max').val
            if (obj.state.val > tmp) {setState('0_userdata.0.Fronius.VIS_GEN24_Betriebswerte.U1_Max', obj.state.val, true)}
            break
        case 'modbus.2.holdingRegisters.1.40274_module/1/DCW' : //Leistung
            tmp = getState('0_userdata.0.Fronius.VIS_GEN24_Betriebswerte.P1_Max').val
            if (obj.state.val > tmp) {setState('0_userdata.0.Fronius.VIS_GEN24_Betriebswerte.P1_Max', obj.state.val, true)}
    }

})

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