@Dr.Pie sagte in Woher kommen diue Schaltzeiten von "Sonnenuntergang" ?: Welche Infos fehlen dir denn noch ? sagte in Woher kommen diue Schaltzeiten von "Sonnenuntergang" ?: 2 verschiedene Scripte erstellt zeigen @paul53 sagte in Woher kommen diue Schaltzeiten von "Sonnenuntergang" ?: In unterschiedlichen JS-Instanzen?

Dann ist das zählen der Impulse und deren Auswertung von genau einem Gerät abhängig und funktioniert auch wenn das WLan oder der ioBroker mal nicht gehen. Das muss man sich aber bezüglich Entprellen schon Einlesen ... Das Zählen der Impulse des Gaszählers - geliefert von einem Node MCU mit Tasmota - habe ich mit einem Blockly-Script gemacht. Die integrierten Entprell-Mechanismen in Tasmota habe ich mir angeschaut, und damals verworfen - ButtonDebounce kann man nur bis 1000 ms hochstellen. https://tasmota.github.io/docs/Commands/#control In 3 Stunden Testzeitraum waren schon 40 Fehl-Impulse "im Kasten", trotz eingestellter 1000 ms ... Auch mit dem Sperr-Timeout von 10 Sekunden gibt es pro Tag ggfs mal 1...3 überzählige Impulse ... Alle paar Tage stelle ich mich mit der Smartphone Vis-App vor den Gaszähler und mache meinen Gaszähler-Korrektur-View auf, um die Fehl-Pulse zu eliminieren. Wenn ein Linux Neustart anfällt muss ich dann auch entsprechend die Pulse nachtragen, die verpasst wurden, während iobroker nicht lief ...

@CKassiopaia sagte: Vergleichbar mit dem import in Python oder dem include bei C. Man kann Node-Module per require importieren. Man kann außerdem oft benötigte Funktionen unter der Gruppe "global" erstellen, die allerdings nicht direkt aus Blockly aufgerufen werden können. Globale Skripte werden in alle anderen Skripte kopiert und dort ausgeführt.

Hallo Paul, you MADE MY DAY :-) Funktioniert einwandfrei. Vielen lieben Dank!!!!!!

Hallo Paul, beide Deiner Vorschläge funktionieren! Und auch Deine Beobachtung, dass, wenn man den Punkt vor UNREACH weglässt, auch STICKY_UNREACH mitgeliefert wird, stimmt. Ich könnte schwören, dass ich an dem Ausdruck seit Monaten nichts verändert habe. Vielen Dank!

@Rudi-Ment sagte: Wie kann ich im Selektor die beiden Funktionen -mit einer geht es zu schalten- verknüpfen ? Im Selektor selbst geht es nicht. Man kann die IDs der zweiten Funktion mittels einer Schleife hinzufügen: Siehe hier

Hi, hab downgrade gemacht, kommt aber immer noch leider :-)

ach herje, so einfach, ja das wars natürlich, danke!

@paul53 Vielen lieben Dank für Deine Hilfe. Mit GET läufts perfekt. Ich dachte das GET für "abholen" von Werten verwendet wird und POST für das Senden von Befehlen. Nochmal vielen Dank lg Michael

klappt, danke!!!

@Asgothian sagte in Farbe aus R/G/B rechnet falsch: ggf. erwartet dieser die farbwerte in %, nicht 0-255 Danke, das war's.

Super, der "Trick" ist, das du ob im "Falls .." als erstes wohl prüfst, ob ein Timeout läuft, wenn er läuft: "mach nix"

Ich hab das Problem gefunden. Wenn man das Preset abspeichert wenn die LED nicht eingeschalten sind funktioniert das natürlich nicht. Man muss das Preset speichern wenn der Effekt selektiert ist als auch die LED laufen. Manchmal kann es so simpel sein. Dennoch wieder etwas gelernt.

@Walter.O. sagte in finde in Trigger "Objekt ID" nicht: Aber es müsste doch im Bereich Trigger zu finden sein? Natürlich sagte in finde in Trigger "Objekt ID" nicht: Da steht ... Wert drin

... der Blick in das Protokoll brachte die "Erhellung"

@Codierknecht vielen Dank für die Hilfe und Info. werde ich mal so ausprobieren! Gruß Steve

@klixy23 sagte in Trigger werden im Script nicht ausgelöst: Wie kann ich das Problem weiter analysieren? Wie sieht das hier bei Dir aus:[image: 1763831819942-screenshot-2025-11-22-at-18.16.57.png] A.

ich probiere :-) danke dir :-)

@topsurfer sagte in PNG zum "blinken bringen", mittels Blockly-Pause ... (?): Also belastend für den Client, als Tablet oder Handy deiner Meinung nach? ja. Ro75.

@Homoran sagte in Wasserleck Blockly: @MartinP sagte in Wasserleck Blockly: Für den Alarmfall MUSS es alle 15 Minuten ein Telegramm geben. das ist nicht der Wunsch! @drapo sagte in Wasserleck Blockly: Ich hätte nun gerne dass wenn das Wasser während 2 Stunden immer läuft ... Die nächste Meldung hätte ich erst gerne 1h später falls das Problem immer noch auftritt. Wenn das Wasser während der 2 Stunden immer (=permanent) läuft, wird es auch alle 15 Minuten ein Telegramm von der Messuhr geben, da sich der Zählerstand geändert hat - die Telegramme bleiben nur aus, wenn es keinen Verbrauch gegeben hat, also kann man davon ausgehen, dass während einer Leckage die Wasseruhr alle 15 Minuten brav ein Telegramm schickt, so lange bis aus dem Leck kein Wasser mehr fließt, oder die Elektronik der Wasseruhr aufgrund geflutetem Keller abgesoffen ist ;-)