JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen

[haus-automatisierung]

@liv-in-sky sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:

evtl knn man da was abfangen ?

Schwierig. Die Blöcke (im Text suche ...) kommen ja direkt von Google. Und der Trigger wird halt bei jeder Log-Meldung aufgerufen. Dadurch wird das sehr oft ausgewertet und entsprechen viele Fehler generiert.

Noch schlimmer könnte es werden, wenn der Block auf die selbst generierte Meldung wieder reagiert. Das könnte ich versuchen zu unterbinden.

[liv-in-sky]

@haus-automatisierung sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:

jeder Log-Meldung aufgerufen. Dadurch wird das sehr oft ausgewertet

das würde erklären, warum so viele meldungen - sind quasi in einer endlos-schleife - zuerst der fehler und dann die reaktion auf den fehler, auf den fehler, auf den fehler ..........

[liv-in-sky]

@haus-automatisierung

evtl. den trigger disablen, wenn in kurzer zeit immer wieder der selbe trigger kommt ?

[haselchen]

@haus-automatisierung
@Homoran
@paul53
@liv-in-sky
@DJMarc75

Huhu,
wollte nun auch mal den Request Block loswerden, auch weil das Log nervt
Tja. Was soll ich sagen. Ist nicht so einfach

Ausgangsblockly

Läuft tadellos. Wenn da nicht die Logeinträge wären

Mit dem gefährlichen Halbwissen umgestellt:

Das steht nun im DP

Das sollte normal drinstehen:

[liv-in-sky]

@haselchen

müßte am result baustein liegen - nimm den Data-baustein

[DJMarc75]

@haselchen

Wie @liv-in-sky schrieb, nimm diesen anstatt result:

zusätzlich:

[haus-automatisierung]

@haselchen sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:

Mit dem gefährlichen Halbwissen umgestellt:

1. Das ganze arbeitet wie vorher auch mit Callbacks. Also bitte die anderen Blöcke auch wieder da rein (wie bei Request).
2. Und deine result Variable löschen. Das war schon immer unschön gelöst, gerade wenn man mehrere Request-Bausteine im gleichen Script hatte (siehe Scope von var). Jedenfalls gibts dafür jetzt andere Bausteine, welche das Ergebnis direkt enthalten (so wie bei den Triggern). Keine Variablen mehr manuell anlegen! Und die merken dann auch, wenn sie falsch genutzt werden und sich gar nicht innerhalb eines httpGet oder Post Bausteines befinden.

[haselchen]

@haus-automatisierung

Wenn doch im Leben alles so einfach wäre

Das ist die Lösung.
Dankeschön an Alle!

Edit: eine kleeeeeeine Frage ist da noch.
Ich habe bei einem Blocky eine Variable gesetzt.
Result.

Nun gibt es ja den Data Baustein , wie muss dieser Block jetzt aussehen?

@Homoran
@paul53
@liv-in-sky
@DJMarc75

[paul53]

@haselchen sagte: Ich habe bei einem Blocky eine Variable gesetzt.

Wozu?

[liv-in-sky]

@haselchen verstehe das auch nicht ganz

vermutung - so rein theoretisch - du fragst beim resultat(data) nur auf ungleich null

wenn aber daten kommen, die inverter.ts_lastsuccess nicht enthalten, wird "blödsinn" in deinen datenpunkt geschrieben (falls das überhaupt vorkommen kann) bzw wird ein script fehler kommen

evtl müßte man das anders abfragen - eben nicht nach null und dann reagieren

das result zu setzen, macht hier keinen sinn

[haselchen]

@liv-in-sky

Das steht da noch drin , weil ich ja nicht weiß wie ich es ändern muss .
Die anderen Variabeln waren ja result.
Jetzt geändert auf Data.

@paul53

Das Ganze ist schon länger her.
Ich vermute auch , wenn keine Daten mehr kommen das da Blödsinn im DP steht . Deswegen hatte ich es so gelöst.

[paul53]

@haselchen sagte: Ich vermute auch , wenn keine Daten mehr kommen

Die Variable wird nur einmal bei Skriptstart mit dem JSON gefüllt.

[haselchen]

@paul53

Wird ja alle 2 min gestartet , siehe Cron Baustein

Edit : okay, sieht man nur wenn man drauf klickt
Aber es sind alle 2 min

[paul53]

@haselchen sagte: Wird ja alle 2 min gestartet

Die Variable wird außerhalb des Zeitplanes gefüllt.

[haselchen]

@paul53

Hm, irgendeinen Grund hatte das
Okay, ich lass diesen Baustein mal weg und beobachte.
Aber erstmal muss ich Betriebsfussball spielen

[liv-in-sky]

@haselchen sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:

keine Daten mehr kommen das da Blödsinn im DP

das wird so nicht mehr funktionieren - außerhalb der httpget function existiert data nicht bzw, wenn du es anlegst wird es innerhalb trotzdem neu gesetzt (wäre dann doppelt im script) (ist jetzt anders als mit dem result wert - soweit ich das verstanden habe)

wenn dann könntest du innerhalb von httpget noch ein sonst einfügen (im falls) dann dp direkt mit einem wert setzen - setstate ...HM-600_Rohdaten ist ...... - z.b. könntest du 999999 setzen und wenn das gesetzt wird durch einen anderen trigger einen alarm senden - dann weißt du, dass was nicht stimmt

[haselchen]

@liv-in-sky

Und das kommt nun raus
Muss gestehen, Skripte, Variablen, Javascript und dergleichen sind nicht so meins

[liv-in-sky]

@haselchen genau das meinte ich mit fehler wird erzeugt

probiermal den timeout im httpget auf 4000 zu setzen
ich bekomme auch öfter mal einen timeout, wenn ich mit 2000 arbeite - verstehe ich zwar nicht, aber evt ist der traffic im netz so hoch (backup), dass es länger wie 2 sekunden dauert, bis eine antwort kommt ???

ich nehme mal an, dass "data" nicht null war aber eben auch keine brauchbaren werte drin sind - wenn du den data baustein mal anklickst gibt es darunte die auswahl status-code

man müßte anstatt nach null abzufragen, den statuscode abfragen - mach mal in dein blockly noch ein debug mit rein

dann siehst du, was da kommt, wenn alles ok ist oder ein fehler kommt - und dann kannst du die abfrage ändern (lass dabei den timeout wieder klein gestellt, damit auch mal ein fehler kommt

[liv-in-sky]

@haselchen

habe es mal ausprobiert - wenn du einen timeout hast, kommt als statuscode null bei mir zurück - dann versucht dein script einen wert aus null (für den datenpunkt) zu generieren - dann kommt der fehler cannot get rx_.......

mit dieser abfrage

sollte das verhindert werden können

[haselchen]

@liv-in-sky

Danke für den Input.
Werde ich heute Abend sehen was passiert
Und was mache ich mit dem "setze".....Baustein?
Weglassen und gucken was passiert?
Gab mit Sicherheit nen Grund das so zu lösen damals...