Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[ticaki]

@codierknecht
mal abgesehen von dem schlechten Stil und dem hohen Ressourcenverbrauch(im Vergleich zu Variablen), wenn man einen Wert schreibt und unmittelbar wieder liest.

Bei 2000 Durchläufen war setState(wertA) == getState(wertA)

setState schreibt das afaik nur in den Cache und getState liest es daraus, oder? Das wirkliche schreiben läuft dann async ab.

offtopic: Womit hast du den screenshot gemacht, der gefällt mir. :)

[Codierknecht]

@ticaki sagte in Anfängerfrage: Reihenfolge von Skriptausführung:

Womit hast du den screenshot gemacht, der gefällt mir

SnagIt von TechSmith.
Ist aber nicht gerade billig (sponsored by company).

[arteck]

@ticaki sagte in Anfängerfrage: Reihenfolge von Skriptausführung:

Bei 2000 Durchläufen war setState(wertA) == getState(wertA)

bei eigen angelegten ja...

bei Geräten nicht.. da wird auf ack gewartet.. da kann schon mal passieren das das Gerät noch nicht das ok gesendet hat und du schon den mit getState abholst...

dafür gibts die

setStateAsync
getStateAsync

[Harald-ohne-Nummer]

Ich muss das Thema nochmal aufmachen. So ganz egal scheint die Anordnungs-Reihenfolge doch nicht zu sein.

Ich habe eine ZigBee-Steckdose. Diese sendet zyklisch irgendwelche Statusmeldungen (z.B. "LinkQuality") über ZigBee. Auf dem KNX-Bus will ich die Info haben, ob die ZigBee Steckdose grds. "da" ist, d.h. aktiv im ZigBee sendet. Das habe ich so gelöst wie unten dargestellt. Das klappt auch. Alle 10 Minuten kommt ein Telegram auf den KNX-Bus. Und wenn binnen der 10 Minuten von der ZigBee-Steckdose ein Signal gesendet wurde, ist das KNX-Telegram "wahr", sonst "falsch".

Wenn ich aber den Trigger und die Endlosschleife in Blocky tausche, wird zyklisch ein "falsch"-Telegram auf den KNX-Bus gesendet. Der Trigger wird nie ausgelöst, es gibt auch keinen Debug-Output.

Wenn in Blockly/Javascript die Anordnungs-Reihenfolge aber egal ist, dürfte das Verhalten doch nicht verschieden sein?

[ticaki]

@Harald-ohne-Nummer

Für Ereignisse und Zeitplan stimmt das alles, aber natürlich wird bei
a= 3+2
a = a * 3
die Reihenfolge eingehalten.

Dein while(1) blockiert alles was danach kommt und ist ganz schlechter Stil. Nimm dafür Zeitplan oder Intervall

Alles was du unter Trigger/Timeout findest läuft asynchron alles andere* synchron.

*Funktionen(Reiter Funktionen) ohne Rückgabe sind asynchron, die mit synchron

Aber natürlich laufen nur Programmfunktionen die aufgerufen werden und wenn du mit while (1) oder ähnlichem die Ausführung stoppst, werden sie nie gestartet.

Einfaches Beispiel:

1. Wenn es klingelt öffne die Tür
2. Warte bis die Tür sich öffnet und dann tue ...

jetzt drehe die unumstößlichen Befehle rum :)

Da wäre es doch besser:

1. Wenn es klingelt öffne die Tür
2. Wenn die Tür sich öffnet tue ....

[paul53]

@ticaki sagte: ist ganz schlechter Stil. Nimm dafür Zeitplan oder Intervall

Auch eine zyklische Abfrage ist kein guter Stil. Besser prüft man, ob mind. alle 10 Minuten getriggert wird:

[ticaki]

@paul53
Als Ersatz ist das guter Stil.

Auf das Problem bezogen würde ich bei Erstellung des Telegramms prüfen, ob einer der Zeitstempel jünger als now() -10 Minuten ist. Hätte ich die Zeit vom letzten Telegram würde ich between prüfen. Mit der jetzigen Version sollte die Erstellung oder Versand des Telegrams den Wert auf false setzen und nicht ein Timer.

[Harald-ohne-Nummer]

Vielen Dank für Eure Rückmeldungen! Von Stil habe ich keine Ahnung :blush: , aber auf Basis Eurer Infos habe ich jetzt zwei Varianten, die beide funktionieren...

oder

Das ist dann beides ok?

[ticaki]

@harald-ohne-nummer
Ich hab damit nur ein Problem die Zeitlinie:

0:00 Telegram nachricht
0:01 Skript check
0:08 Zigbee hat sich seit 10 Minuten nicht gemeldet
0:10 Telegammnachricht
0:01 Skript registriert Zigbee
0:20 Telegrammnachricht 12 Minuten zu spät.

nur zur Info: ein/dein Interval startet das erste mal nach 10 minuten und dann alle 10 Minuten

[Harald-ohne-Nummer]

@ticaki Für meinen Anwendungsfall ist es egal, ob der "Funkausfall" ein paar Minuten früher oder später bemerkt wird. Das ist ein Ereignis, das ohnehin nicht oder nur sehr selten vorkommen sollte und dessen Auswirkungen nicht kritisch sind. D.h. es reicht, wenn ich das dann ggf. ein paar Minuten "zu spät" bemerke.

[AXMLM]

Ich grabe das hier mal aus, da das Problem das gleiche ist. Die Reihenfolge der Aktionen unter einem Trigger läuft nicht sequenziell ab.

Ich habe einen Berechnungsscript in Blockly gebaut. Hier scheint es zu sein, dass die Berechnungsreihenfolge durcheinander läuft und der Volumetracker dadurch Fehlermeldungen produziert.

0_userdata.0.Benutzervariablen.Strom.Wert_Gespart wurde scheinbar resetet! Reset von 874.13 nach 874.11 passe alle Startwerte an

hier ist der Blockly Block.

kann ich irgendwie Blockly dazu zwingen die Berechnungen nacheinander zu machen, oder macht er das eh und der Fehler liegt woanders?

[paul53]

@axmlm sagte: kann ich irgendwie Blockly dazu zwingen die Berechnungen nacheinander zu machen

Ja, verwende Variablen für Werte, die später wieder verwendet werden, denn "aktualisiere" wird asynchron ausgeführt, ist also beim Wiedereinlesen noch nicht fertig.

[AXMLM]

@paul53 said in Anfängerfrage: Reihenfolge von Skriptausführung:

@axmlm sagte: kann ich irgendwie Blockly dazu zwingen die Berechnungen nacheinander zu machen
Ja, verwende Variablen für Werte, die später wieder verwendet werden, denn "aktualisiere" wird asynchron ausgeführt, ist also beim Wiedereinlesen noch nicht fertig.

Meinst Du so?

EDIT:

geht nicht:

javascript.0	10:33:08.705	error	script.js.Strom.PV-Ertragswerte: getState has been called with id of type "number" but expects a string
javascript.0	10:33:08.706	error	script.js.Strom.PV-Ertragswerte: TypeError: Cannot read properties of undefined (reading 'val')
javascript.0	10:33:08.707	error	at Object.<anonymous> (script.js.Strom.PV-Ertragswerte:9:62)

[AXMLM]

jetzt läufts

[AXMLM]

die Fehlermeldungen sind leider geblieben.

valuetrackerovertime.0
2025-04-30 11:10:49.694	warn	0_userdata.0.Benutzervariablen.Strom.PV-Eigenverbrauch wurde scheinbar resetet! Reset von 3250.42 nach 3250.33 passe alle Startwerte an

valuetrackerovertime.0
2025-04-30 11:10:49.693	warn	0_userdata.0.Benutzervariablen.Strom.Verbrauch_gesamt wurde scheinbar resetet! Reset von 9820.42 nach 9820.33 passe alle Startwerte an

valuetrackerovertime.0
2025-04-30 11:10:49.691	warn	0_userdata.0.Benutzervariablen.Strom.Wert_Gewinn wurde scheinbar resetet! Reset von 1216.99 nach 1216.97 passe alle Startwerte an

valuetrackerovertime.0
2025-04-30 11:10:49.689	warn	0_userdata.0.Benutzervariablen.Strom.Wert_Gespart wurde scheinbar resetet! Reset von 874.36 nach 874.34 passe alle Startwerte an

valuetrackerovertime.0
2025-04-30 11:09:39.804	warn	0_userdata.0.Benutzervariablen.Strom.PV-Eigenverbrauch wurde scheinbar resetet! Reset von 3250.41 nach 3250.32 passe alle Startwerte an

valuetrackerovertime.0
2025-04-30 11:09:39.801	warn	0_userdata.0.Benutzervariablen.Strom.Verbrauch_gesamt wurde scheinbar resetet! Reset von 9820.41 nach 9820.32 passe alle Startwerte an